* Re: [PATCH] 8250_pci.c: Update NI specific devices class to multi serial
From: Andy Shevchenko @ 2019-01-23 16:06 UTC (permalink / raw)
To: Guan Yung Tseng
Cc: Greg Kroah-Hartman, open list:SERIAL DRIVERS,
Linux Kernel Mailing List
In-Reply-To: <CAHp75VcxtSi64qsK6tHx+vtEeRsX3ZVwfzRYOVuyS=qSTnK0qQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 817 bytes --]
On Wed, Jan 23, 2019 at 5:18 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Mon, Jan 14, 2019 at 4:13 PM Guan Yung Tseng <guan.yung.tseng@ni.com> wrote:
> >
> > Modified NI devices class to PCI_CLASS_COMMUNICATION_MULTISERIAL.
> > The reason of doing this is because all NI multi port serial cards
> > use PCI_CLASS_COMMUNICATION_OTHER class and thus fail the
> > serial_pci_is_class_communication test added in the commit 7d8905d06405
> > ("serial: 8250_pci: Enable device after we check black list").
>
> Guan, can you provide an output of the
>
> lspci -nk -xx -vv -s <BDF>
>
> of your device, where <BDF> is a PCI address in a form of bus:device.function?
While I'm still wondering of the above, can you also test the bellow
patch if it fixes your issue?
--
With Best Regards,
Andy Shevchenko
[-- Attachment #2: 8250-pci-1.diff --]
[-- Type: text/x-patch, Size: 805 bytes --]
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index f80a300b5d68..48bd694a5fa1 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -3420,6 +3420,11 @@ static int
serial_pci_guess_board(struct pci_dev *dev, struct pciserial_board *board)
{
int num_iomem, num_port, first_port = -1, i;
+ int rc;
+
+ rc = serial_pci_is_class_communication(dev);
+ if (rc)
+ return rc;
/*
* Should we try to make guesses for multiport serial devices later?
@@ -3647,10 +3652,6 @@ pciserial_init_one(struct pci_dev *dev, const struct pci_device_id *ent)
board = &pci_boards[ent->driver_data];
- rc = serial_pci_is_class_communication(dev);
- if (rc)
- return rc;
-
rc = serial_pci_is_blacklisted(dev);
if (rc)
return rc;
^ permalink raw reply related
* Re: [PATCH 4/6] spi: spi-geni-qcom: Add interconnect support
From: Mark Brown @ 2019-01-23 16:04 UTC (permalink / raw)
To: Alok Chauhan
Cc: linux-arm-msm, devicetree, linux-kernel, linux-i2c, linux-spi,
linux-serial, andy.gross, david.brown, georgi.djakov, dianders,
swboyd, bjorn.andersson
In-Reply-To: <1548138816-1149-5-git-send-email-alokc@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 234 bytes --]
On Tue, Jan 22, 2019 at 12:03:34PM +0530, Alok Chauhan wrote:
> Get the interconnect paths for SPI based Serial Engine device
> and vote accordingly based on maximum supported SPI frequency.
Acked-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] 8250_pci.c: Update NI specific devices class to multi serial
From: Andy Shevchenko @ 2019-01-23 15:18 UTC (permalink / raw)
To: Guan Yung Tseng
Cc: Greg Kroah-Hartman, open list:SERIAL DRIVERS,
Linux Kernel Mailing List
In-Reply-To: <1547475005-23435-1-git-send-email-guan.yung.tseng@ni.com>
On Mon, Jan 14, 2019 at 4:13 PM Guan Yung Tseng <guan.yung.tseng@ni.com> wrote:
>
> Modified NI devices class to PCI_CLASS_COMMUNICATION_MULTISERIAL.
> The reason of doing this is because all NI multi port serial cards
> use PCI_CLASS_COMMUNICATION_OTHER class and thus fail the
> serial_pci_is_class_communication test added in the commit 7d8905d06405
> ("serial: 8250_pci: Enable device after we check black list").
Guan, can you provide an output of the
lspci -nk -xx -vv -s <BDF>
of your device, where <BDF> is a PCI address in a form of bus:device.function?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] 8250_pci.c: Update NI specific devices class to multi serial
From: Andy Shevchenko @ 2019-01-23 14:11 UTC (permalink / raw)
To: Heikki Krogerus; +Cc: Guan Yung Tseng, gregkh, linux-serial, linux-kernel
In-Reply-To: <20190122115508.GB22960@kuha.fi.intel.com>
On Tue, Jan 22, 2019 at 01:55:08PM +0200, Heikki Krogerus wrote:
> On Mon, Jan 14, 2019 at 10:10:05PM +0800, Guan Yung Tseng wrote:
> > Modified NI devices class to PCI_CLASS_COMMUNICATION_MULTISERIAL.
> > The reason of doing this is because all NI multi port serial cards
> > use PCI_CLASS_COMMUNICATION_OTHER class and thus fail the
> > serial_pci_is_class_communication test added in the commit 7d8905d06405
> > ("serial: 8250_pci: Enable device after we check black list").
>
> OK, so commit 7d8905d06405 ("serial: 8250_pci: Enable device after we
> check black list") has created a regression. If the device does not
> use PCI_CLASS_COMMUNICATION*SERIAL class, probe will fail, and I
> don't think that is how the driver should function.
>
> If the device id is listed in serial_pci_tbl, we need to probe the
> device, regardless of the class id.
I need to check what should be a better fix.
> This is only working around the regression that 7d8905d064058 created,
> and only with your UART. There may be others.
>
> We need to fix the regression, not work around it. How about something
> like the attached diff?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 4/6] spi: spi-geni-qcom: Add interconnect support
From: Mark Brown @ 2019-01-23 10:58 UTC (permalink / raw)
To: alokc
Cc: linux-arm-msm, devicetree, linux-kernel, linux-i2c, linux-spi,
linux-serial, andy.gross, david.brown, georgi.djakov, dianders,
swboyd, bjorn.andersson, linux-serial-owner
In-Reply-To: <775cdd29a7d536772330a15a7013f251@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]
On Wed, Jan 23, 2019 at 12:45:30PM +0530, alokc@codeaurora.org wrote:
> On 2019-01-23 01:59, Mark Brown wrote:
> > Still not seeing anything except this patch here in my inbox - like I
> > said what's the story with dependencies?
> I've added linux-spi mailing list to all the patches sent as part of this
> series. Not sure why you didn't get other patches. Today I've explicitly
> added you in all the patches.
You really need to ensure that things end up in people's inboxes -
sending them to a mailing list usually means they'll go to a completely
different folder.
> This change series basically enabled interconnect (as per
> bindings/interconnect/interconnect.txt) support in GENI QUPs based drivers
> so appropriate BW request can be put based on SE usages.
> here is my complete change series: https://lore.kernel.org/lkml/1548069703-26595-1-git-send-email-alokc@codeaurora.org/
> I hope I answer to your question properly.
So it looks like there is a dependency on earlier patches in the series,
that's what I needed to know.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 4/6] spi: spi-geni-qcom: Add interconnect support
From: alokc @ 2019-01-23 7:15 UTC (permalink / raw)
To: Mark Brown
Cc: linux-arm-msm, devicetree, linux-kernel, linux-i2c, linux-spi,
linux-serial, andy.gross, david.brown, georgi.djakov, dianders,
swboyd, bjorn.andersson, linux-serial-owner
In-Reply-To: <20190122202924.GL7579@sirena.org.uk>
On 2019-01-23 01:59, Mark Brown wrote:
> On Tue, Jan 22, 2019 at 12:03:34PM +0530, Alok Chauhan wrote:
>
>> Get the interconnect paths for SPI based Serial Engine device
>> and vote accordingly based on maximum supported SPI frequency.
>
> Still not seeing anything except this patch here in my inbox - like I
> said what's the story with dependencies?
I've added linux-spi mailing list to all the patches sent as part of
this series. Not sure why you didn't get other patches. Today I've
explicitly added you in all the patches.
This change series basically enabled interconnect (as per
bindings/interconnect/interconnect.txt) support in GENI QUPs based
drivers so appropriate BW request can be put based on SE usages.
here is my complete change series:
https://lore.kernel.org/lkml/1548069703-26595-1-git-send-email-alokc@codeaurora.org/
I hope I answer to your question properly.
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 2/6] soc: qcom: Add wrapper to support for Interconnect path
From: alokc @ 2019-01-23 7:02 UTC (permalink / raw)
To: linux-arm-msm, devicetree, linux-kernel, linux-i2c, linux-spi,
linux-serial, Andy Gross, David Brown, Stephen Boyd,
Douglas Anderson, Bjorn Andersson, Karthikeyan Ramasubramanian,
Alok Chauhan, Mark Brown
Cc: georgi.djakov, linux-serial-owner
In-Reply-To: <1548138816-1149-3-git-send-email-alokc@codeaurora.org>
+Mark Brown
On 2019-01-22 12:03, Alok Chauhan wrote:
> Add the wrapper to support for interconnect path voting
> from GENI QUP. This wrapper provides the functionalities
> to individual Serial Engine device to get the interconnect
> path and to vote for bandwidth based on their need.
>
> This wrapper maintains bandwidth votes from each Serial Engine
> and send the aggregated vote from GENI QUP to interconnect
> framework.
>
> Signed-off-by: Alok Chauhan <alokc@codeaurora.org>
> ---
> drivers/soc/qcom/qcom-geni-se.c | 129
> ++++++++++++++++++++++++++++++++++++++++
> include/linux/qcom-geni-se.h | 11 ++++
> 2 files changed, 140 insertions(+)
>
> diff --git a/drivers/soc/qcom/qcom-geni-se.c
> b/drivers/soc/qcom/qcom-geni-se.c
> index 6b8ef01..1d8dcb1 100644
> --- a/drivers/soc/qcom/qcom-geni-se.c
> +++ b/drivers/soc/qcom/qcom-geni-se.c
> @@ -11,6 +11,7 @@
> #include <linux/pinctrl/consumer.h>
> #include <linux/platform_device.h>
> #include <linux/qcom-geni-se.h>
> +#include <linux/interconnect.h>
>
> /**
> * DOC: Overview
> @@ -84,11 +85,21 @@
> * @dev: Device pointer of the QUP wrapper core
> * @base: Base address of this instance of QUP wrapper core
> * @ahb_clks: Handle to the primary & secondary AHB clocks
> + * @icc_path: Array of interconnect path handles
> + * @geni_wrapper_lock: Lock to protect the bus bandwidth request
> + * @cur_avg_bw: Current Bus Average BW request value from GENI QUP
> + * @cur_peak_bw: Current Bus Peak BW request value from GENI QUP
> + * @peak_bw_list_head: Sorted resource list based on peak bus BW
> */
> struct geni_wrapper {
> struct device *dev;
> void __iomem *base;
> struct clk_bulk_data ahb_clks[NUM_AHB_CLKS];
> + struct icc_path *icc_path[2];
> + struct mutex geni_wrapper_lock;
> + u32 cur_avg_bw;
> + u32 cur_peak_bw;
> + struct list_head peak_bw_list_head;
> };
>
> #define QUP_HW_VER_REG 0x4
> @@ -440,6 +451,71 @@ static void geni_se_clks_off(struct geni_se *se)
> }
>
> /**
> + * geni_icc_update_bw() - Request to update bw vote on an interconnect
> path
> + * @se: Pointer to the concerned serial engine.
> + * @update: Flag to update bw vote.
> + *
> + * This function is used to request set bw vote on interconnect path
> handle.
> + */
> +void geni_icc_update_bw(struct geni_se *se, bool update)
> +{
> + struct geni_se *temp = NULL;
> + struct list_head *ins_list_head;
> + struct geni_wrapper *wrapper;
> +
> + mutex_lock(&se->wrapper->geni_wrapper_lock);
> +
> + wrapper = se->wrapper;
> +
> + if (update) {
> + wrapper->cur_avg_bw += se->avg_bw;
> + ins_list_head = &wrapper->peak_bw_list_head;
> + list_for_each_entry(temp, &wrapper->peak_bw_list_head,
> + peak_bw_list) {
> + if (temp->peak_bw < se->peak_bw)
> + break;
> + ins_list_head = &temp->peak_bw_list;
> + }
> +
> + list_add(&se->peak_bw_list, ins_list_head);
> +
> + if (ins_list_head == &wrapper->peak_bw_list_head)
> + wrapper->cur_peak_bw = se->peak_bw;
> + } else {
> + if (unlikely(list_empty(&se->peak_bw_list))) {
> + mutex_unlock(&wrapper->geni_wrapper_lock);
> + return;
> + }
> +
> + wrapper->cur_avg_bw -= se->avg_bw;
> +
> + list_del_init(&se->peak_bw_list);
> + temp = list_first_entry_or_null(&wrapper->peak_bw_list_head,
> + struct geni_se, peak_bw_list);
> + if (temp && temp->peak_bw != wrapper->cur_peak_bw)
> + wrapper->cur_peak_bw = temp->peak_bw;
> + else if (!temp && wrapper->cur_peak_bw)
> + wrapper->cur_peak_bw = 0;
> + }
> +
> + /*
> + * This bw vote is to enable internal QUP core clock as well as to
> + * enable path towards memory.
> + */
> + icc_set_bw(wrapper->icc_path[0], wrapper->cur_avg_bw,
> + wrapper->cur_peak_bw);
> +
> + /*
> + * This is just register configuration path so doesn't need avg bw.
> + * Set only peak bw to enable this path.
> + */
> + icc_set_bw(wrapper->icc_path[1], 0, wrapper->cur_peak_bw);
> +
> + mutex_unlock(&wrapper->geni_wrapper_lock);
> +}
> +EXPORT_SYMBOL(geni_icc_update_bw);
> +
> +/**
> * geni_se_resources_off() - Turn off resources associated with the
> serial
> * engine
> * @se: Pointer to the concerned serial engine.
> @@ -707,6 +783,47 @@ void geni_se_rx_dma_unprep(struct geni_se *se,
> dma_addr_t iova, size_t len)
> }
> EXPORT_SYMBOL(geni_se_rx_dma_unprep);
>
> +/**
> + * geni_interconnect_init() - Request to get interconnect path handle
> + * @se: Pointer to the concerned serial engine.
> + *
> + * This function is used to get interconnect path handle.
> + */
> +int geni_interconnect_init(struct geni_se *se)
> +{
> + struct geni_wrapper *wrapper_rsc;
> +
> + if (unlikely(!se || !se->wrapper))
> + return -EINVAL;
> +
> + wrapper_rsc = se->wrapper;
> +
> + if ((IS_ERR_OR_NULL(wrapper_rsc->icc_path[0]) ||
> + IS_ERR_OR_NULL(wrapper_rsc->icc_path[1]))) {
> +
> + wrapper_rsc->icc_path[0] = of_icc_get(wrapper_rsc->dev,
> + "qup-memory");
> + if (IS_ERR(wrapper_rsc->icc_path[0]))
> + return PTR_ERR(wrapper_rsc->icc_path[0]);
> +
> + wrapper_rsc->icc_path[1] = of_icc_get(wrapper_rsc->dev,
> + "qup-config");
> + if (IS_ERR(wrapper_rsc->icc_path[1])) {
> + icc_put(wrapper_rsc->icc_path[0]);
> + wrapper_rsc->icc_path[0] = NULL;
> + return PTR_ERR(wrapper_rsc->icc_path[1]);
> + }
> +
> + INIT_LIST_HEAD(&wrapper_rsc->peak_bw_list_head);
> + mutex_init(&wrapper_rsc->geni_wrapper_lock);
> + }
> +
> + INIT_LIST_HEAD(&se->peak_bw_list);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(geni_interconnect_init);
> +
> static int geni_se_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> @@ -737,6 +854,17 @@ static int geni_se_probe(struct platform_device
> *pdev)
> return devm_of_platform_populate(dev);
> }
>
> +static int geni_se_remove(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct geni_wrapper *wrapper = dev_get_drvdata(dev);
> +
> + icc_put(wrapper->icc_path[0]);
> + icc_put(wrapper->icc_path[1]);
> +
> + return 0;
> +}
> +
> static const struct of_device_id geni_se_dt_match[] = {
> { .compatible = "qcom,geni-se-qup", },
> {}
> @@ -749,6 +877,7 @@ static int geni_se_probe(struct platform_device
> *pdev)
> .of_match_table = geni_se_dt_match,
> },
> .probe = geni_se_probe,
> + .remove = geni_se_remove,
> };
> module_platform_driver(geni_se_driver);
>
> diff --git a/include/linux/qcom-geni-se.h
> b/include/linux/qcom-geni-se.h
> index 3bcd67f..9bf03e9 100644
> --- a/include/linux/qcom-geni-se.h
> +++ b/include/linux/qcom-geni-se.h
> @@ -33,6 +33,10 @@ enum geni_se_protocol_type {
> * @clk: Handle to the core serial engine clock
> * @num_clk_levels: Number of valid clock levels in clk_perf_tbl
> * @clk_perf_tbl: Table of clock frequency input to serial engine
> clock
> + * @avg_bw: Average bus bandwidth value for Serial Engine device
> + * @peak_bw: Peak bus bandwidth value for Serial Engine device
> + * @peak_bw_list: List Head of peak bus banwidth list for Serial
> Engine
> + * device
> */
> struct geni_se {
> void __iomem *base;
> @@ -41,6 +45,9 @@ struct geni_se {
> struct clk *clk;
> unsigned int num_clk_levels;
> unsigned long *clk_perf_tbl;
> + u32 avg_bw;
> + u32 peak_bw;
> + struct list_head peak_bw_list;
> };
>
> /* Common SE registers */
> @@ -416,5 +423,9 @@ int geni_se_rx_dma_prep(struct geni_se *se, void
> *buf, size_t len,
> void geni_se_tx_dma_unprep(struct geni_se *se, dma_addr_t iova, size_t
> len);
>
> void geni_se_rx_dma_unprep(struct geni_se *se, dma_addr_t iova, size_t
> len);
> +
> +int geni_interconnect_init(struct geni_se *se);
> +
> +void geni_icc_update_bw(struct geni_se *se, bool update);
> #endif
> #endif
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 6/6] arm64: dts: sdm845: Add interconnect for GENI QUP
From: alokc @ 2019-01-23 6:54 UTC (permalink / raw)
To: linux-arm-msm, devicetree, linux-kernel, linux-i2c, linux-spi,
linux-serial, Andy Gross, David Brown, Rob Herring, Mark Rutland,
Mark Brown
Cc: georgi.djakov, dianders, swboyd, bjorn.andersson,
linux-serial-owner
In-Reply-To: <1548138816-1149-7-git-send-email-alokc@codeaurora.org>
+Mark Brown
On 2019-01-22 12:03, Alok Chauhan wrote:
> Add interconnect ports for GENI QUPs to set bus
> capabilities.
>
> Signed-off-by: Alok Chauhan <alokc@codeaurora.org>
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index c27cbd3..fb0a8a7 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -374,6 +374,13 @@
> #address-cells = <1>;
> #size-cells = <1>;
> ranges;
> +
> + interconnects = <&rsc_hlos MASTER_BLSP_1
> + &rsc_hlos SLAVE_EBI1>,
> + <&rsc_hlos MASTER_APPSS_PROC
> + &rsc_hlos SLAVE_BLSP_1>;
> + interconnect-names = "qup-memory", "qup-config";
> +
> status = "disabled";
>
> i2c0: i2c@880000 {
> @@ -682,6 +689,13 @@
> #address-cells = <1>;
> #size-cells = <1>;
> ranges;
> +
> + interconnects = <&rsc_hlos MASTER_BLSP_2
> + &rsc_hlos SLAVE_EBI1>,
> + <&rsc_hlos MASTER_APPSS_PROC
> + &rsc_hlos SLAVE_BLSP_2>;
> + interconnect-names = "qup-memory", "qup-config";
> +
> status = "disabled";
>
> i2c8: i2c@a80000 {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 5/6] tty: serial: qcom_geni_serial: Add interconnect support
From: alokc @ 2019-01-23 6:53 UTC (permalink / raw)
To: linux-arm-msm, devicetree, linux-kernel, linux-i2c, linux-spi,
linux-serial, Greg Kroah-Hartman, Jiri Slaby, Mark Brown
Cc: andy.gross, david.brown, georgi.djakov, dianders, swboyd,
bjorn.andersson, linux-serial-owner
In-Reply-To: <1548138816-1149-6-git-send-email-alokc@codeaurora.org>
+Mark Brown
On 2019-01-22 12:03, Alok Chauhan wrote:
> Get the interconnect paths for Uart based Serial Engine device
> and vote accordingly based on maximum supported Uart frequency.
>
> Signed-off-by: Alok Chauhan <alokc@codeaurora.org>
> ---
> drivers/tty/serial/qcom_geni_serial.c | 27 ++++++++++++++++++++++++++-
> 1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/qcom_geni_serial.c
> b/drivers/tty/serial/qcom_geni_serial.c
> index a72d6d9..e2ea499 100644
> --- a/drivers/tty/serial/qcom_geni_serial.c
> +++ b/drivers/tty/serial/qcom_geni_serial.c
> @@ -19,6 +19,7 @@
> #include <linux/slab.h>
> #include <linux/tty.h>
> #include <linux/tty_flip.h>
> +#include <linux/interconnect.h>
>
> /* UART specific GENI registers */
> #define SE_UART_LOOPBACK_CFG 0x22c
> @@ -1348,6 +1349,22 @@ static int qcom_geni_serial_probe(struct
> platform_device *pdev)
> return ret;
> }
>
> + /* Set the bus quota to a reasonable value */
> + port->se.avg_bw = console ? Bps_to_icc(1000) : Bps_to_icc(2500);
> + port->se.peak_bw = Bps_to_icc(76800000);
> + ret = geni_interconnect_init(&port->se);
> + if (ret) {
> + dev_err(&pdev->dev, "interconnect_init failed %d\n", ret);
> + return ret;
> + }
> +
> + /*
> + * Vote for interconnect path early. This has to move as part of
> + * Runtime PM APIs when implemented for better control betwen
> + * console and non-console usecases
> + */
> + geni_icc_update_bw(&port->se, true);
> +
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!res)
> return -EINVAL;
> @@ -1385,8 +1402,15 @@ static int __maybe_unused
> qcom_geni_serial_sys_suspend(struct device *dev)
> {
> struct qcom_geni_serial_port *port = dev_get_drvdata(dev);
> struct uart_port *uport = &port->uport;
> + int ret;
> +
> + ret = uart_suspend_port(uport->private_data, uport);
> + if (ret)
> + return ret;
> +
> + geni_icc_update_bw(&port->se, false);
>
> - return uart_suspend_port(uport->private_data, uport);
> + return 0;
> }
>
> static int __maybe_unused qcom_geni_serial_sys_resume(struct device
> *dev)
> @@ -1394,6 +1418,7 @@ static int __maybe_unused
> qcom_geni_serial_sys_resume(struct device *dev)
> struct qcom_geni_serial_port *port = dev_get_drvdata(dev);
> struct uart_port *uport = &port->uport;
>
> + geni_icc_update_bw(&port->se, true);
> return uart_resume_port(uport->private_data, uport);
> }
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 3/6] i2c: i2c-qcom-geni: Add interconnect support
From: alokc @ 2019-01-23 6:51 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-arm-msm, devicetree, linux-kernel, linux-i2c, linux-spi,
linux-serial, Karthikeyan Ramasubramanian, andy.gross,
david.brown, georgi.djakov, dianders, swboyd, bjorn.andersson,
linux-arm-msm-owner, Mark Brown
In-Reply-To: <d44cdb5e-2408-493c-3f86-db97c224dc3f@axentia.se>
On 2019-01-22 14:43, Peter Rosin wrote:
> On 2019-01-22 07:33, Alok Chauhan wrote:
>> Get the interconnect paths for I2C based Serial Engine device
>> and vote accordingly based on maximum supported I2C frequency.
>>
>> Signed-off-by: Alok Chauhan <alokc@codeaurora.org>
>> ---
>> drivers/i2c/busses/i2c-qcom-geni.c | 13 +++++++++++++
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
>> b/drivers/i2c/busses/i2c-qcom-geni.c
>> index db075bc..e8fe63a 100644
>> --- a/drivers/i2c/busses/i2c-qcom-geni.c
>> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
>> @@ -14,6 +14,7 @@
>> #include <linux/pm_runtime.h>
>> #include <linux/qcom-geni-se.h>
>> #include <linux/spinlock.h>
>> +#include <linux/interconnect.h>
>
> Please keep the includes sorted. Probably applies for the other patches
> in the series as well?
>
> Cheers,
> Peter
Sure, will do. Thanks for your comment.
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 2/6] soc: qcom: Add wrapper to support for Interconnect path
From: alokc @ 2019-01-23 6:49 UTC (permalink / raw)
To: linux-arm-msm, devicetree, linux-kernel, linux-i2c, linux-spi,
linux-serial, Andy Gross, David Brown, Stephen Boyd,
Douglas Anderson, Bjorn Andersson, Karthikeyan Ramasubramanian,
Alok Chauhan, Mark Brown
Cc: georgi.djakov, linux-spi-owner
+Mark Brown
On 2019-01-22 12:03, Alok Chauhan wrote:
> Add the wrapper to support for interconnect path voting
> from GENI QUP. This wrapper provides the functionalities
> to individual Serial Engine device to get the interconnect
> path and to vote for bandwidth based on their need.
>
> This wrapper maintains bandwidth votes from each Serial Engine
> and send the aggregated vote from GENI QUP to interconnect
> framework.
>
> Signed-off-by: Alok Chauhan <alokc@codeaurora.org>
> ---
> drivers/soc/qcom/qcom-geni-se.c | 129
> ++++++++++++++++++++++++++++++++++++++++
> include/linux/qcom-geni-se.h | 11 ++++
> 2 files changed, 140 insertions(+)
>
> diff --git a/drivers/soc/qcom/qcom-geni-se.c
> b/drivers/soc/qcom/qcom-geni-se.c
> index 6b8ef01..1d8dcb1 100644
> --- a/drivers/soc/qcom/qcom-geni-se.c
> +++ b/drivers/soc/qcom/qcom-geni-se.c
> @@ -11,6 +11,7 @@
> #include <linux/pinctrl/consumer.h>
> #include <linux/platform_device.h>
> #include <linux/qcom-geni-se.h>
> +#include <linux/interconnect.h>
>
> /**
> * DOC: Overview
> @@ -84,11 +85,21 @@
> * @dev: Device pointer of the QUP wrapper core
> * @base: Base address of this instance of QUP wrapper core
> * @ahb_clks: Handle to the primary & secondary AHB clocks
> + * @icc_path: Array of interconnect path handles
> + * @geni_wrapper_lock: Lock to protect the bus bandwidth request
> + * @cur_avg_bw: Current Bus Average BW request value from GENI QUP
> + * @cur_peak_bw: Current Bus Peak BW request value from GENI QUP
> + * @peak_bw_list_head: Sorted resource list based on peak bus BW
> */
> struct geni_wrapper {
> struct device *dev;
> void __iomem *base;
> struct clk_bulk_data ahb_clks[NUM_AHB_CLKS];
> + struct icc_path *icc_path[2];
> + struct mutex geni_wrapper_lock;
> + u32 cur_avg_bw;
> + u32 cur_peak_bw;
> + struct list_head peak_bw_list_head;
> };
>
> #define QUP_HW_VER_REG 0x4
> @@ -440,6 +451,71 @@ static void geni_se_clks_off(struct geni_se *se)
> }
>
> /**
> + * geni_icc_update_bw() - Request to update bw vote on an interconnect
> path
> + * @se: Pointer to the concerned serial engine.
> + * @update: Flag to update bw vote.
> + *
> + * This function is used to request set bw vote on interconnect path
> handle.
> + */
> +void geni_icc_update_bw(struct geni_se *se, bool update)
> +{
> + struct geni_se *temp = NULL;
> + struct list_head *ins_list_head;
> + struct geni_wrapper *wrapper;
> +
> + mutex_lock(&se->wrapper->geni_wrapper_lock);
> +
> + wrapper = se->wrapper;
> +
> + if (update) {
> + wrapper->cur_avg_bw += se->avg_bw;
> + ins_list_head = &wrapper->peak_bw_list_head;
> + list_for_each_entry(temp, &wrapper->peak_bw_list_head,
> + peak_bw_list) {
> + if (temp->peak_bw < se->peak_bw)
> + break;
> + ins_list_head = &temp->peak_bw_list;
> + }
> +
> + list_add(&se->peak_bw_list, ins_list_head);
> +
> + if (ins_list_head == &wrapper->peak_bw_list_head)
> + wrapper->cur_peak_bw = se->peak_bw;
> + } else {
> + if (unlikely(list_empty(&se->peak_bw_list))) {
> + mutex_unlock(&wrapper->geni_wrapper_lock);
> + return;
> + }
> +
> + wrapper->cur_avg_bw -= se->avg_bw;
> +
> + list_del_init(&se->peak_bw_list);
> + temp = list_first_entry_or_null(&wrapper->peak_bw_list_head,
> + struct geni_se, peak_bw_list);
> + if (temp && temp->peak_bw != wrapper->cur_peak_bw)
> + wrapper->cur_peak_bw = temp->peak_bw;
> + else if (!temp && wrapper->cur_peak_bw)
> + wrapper->cur_peak_bw = 0;
> + }
> +
> + /*
> + * This bw vote is to enable internal QUP core clock as well as to
> + * enable path towards memory.
> + */
> + icc_set_bw(wrapper->icc_path[0], wrapper->cur_avg_bw,
> + wrapper->cur_peak_bw);
> +
> + /*
> + * This is just register configuration path so doesn't need avg bw.
> + * Set only peak bw to enable this path.
> + */
> + icc_set_bw(wrapper->icc_path[1], 0, wrapper->cur_peak_bw);
> +
> + mutex_unlock(&wrapper->geni_wrapper_lock);
> +}
> +EXPORT_SYMBOL(geni_icc_update_bw);
> +
> +/**
> * geni_se_resources_off() - Turn off resources associated with the
> serial
> * engine
> * @se: Pointer to the concerned serial engine.
> @@ -707,6 +783,47 @@ void geni_se_rx_dma_unprep(struct geni_se *se,
> dma_addr_t iova, size_t len)
> }
> EXPORT_SYMBOL(geni_se_rx_dma_unprep);
>
> +/**
> + * geni_interconnect_init() - Request to get interconnect path handle
> + * @se: Pointer to the concerned serial engine.
> + *
> + * This function is used to get interconnect path handle.
> + */
> +int geni_interconnect_init(struct geni_se *se)
> +{
> + struct geni_wrapper *wrapper_rsc;
> +
> + if (unlikely(!se || !se->wrapper))
> + return -EINVAL;
> +
> + wrapper_rsc = se->wrapper;
> +
> + if ((IS_ERR_OR_NULL(wrapper_rsc->icc_path[0]) ||
> + IS_ERR_OR_NULL(wrapper_rsc->icc_path[1]))) {
> +
> + wrapper_rsc->icc_path[0] = of_icc_get(wrapper_rsc->dev,
> + "qup-memory");
> + if (IS_ERR(wrapper_rsc->icc_path[0]))
> + return PTR_ERR(wrapper_rsc->icc_path[0]);
> +
> + wrapper_rsc->icc_path[1] = of_icc_get(wrapper_rsc->dev,
> + "qup-config");
> + if (IS_ERR(wrapper_rsc->icc_path[1])) {
> + icc_put(wrapper_rsc->icc_path[0]);
> + wrapper_rsc->icc_path[0] = NULL;
> + return PTR_ERR(wrapper_rsc->icc_path[1]);
> + }
> +
> + INIT_LIST_HEAD(&wrapper_rsc->peak_bw_list_head);
> + mutex_init(&wrapper_rsc->geni_wrapper_lock);
> + }
> +
> + INIT_LIST_HEAD(&se->peak_bw_list);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(geni_interconnect_init);
> +
> static int geni_se_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> @@ -737,6 +854,17 @@ static int geni_se_probe(struct platform_device
> *pdev)
> return devm_of_platform_populate(dev);
> }
>
> +static int geni_se_remove(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct geni_wrapper *wrapper = dev_get_drvdata(dev);
> +
> + icc_put(wrapper->icc_path[0]);
> + icc_put(wrapper->icc_path[1]);
> +
> + return 0;
> +}
> +
> static const struct of_device_id geni_se_dt_match[] = {
> { .compatible = "qcom,geni-se-qup", },
> {}
> @@ -749,6 +877,7 @@ static int geni_se_probe(struct platform_device
> *pdev)
> .of_match_table = geni_se_dt_match,
> },
> .probe = geni_se_probe,
> + .remove = geni_se_remove,
> };
> module_platform_driver(geni_se_driver);
>
> diff --git a/include/linux/qcom-geni-se.h
> b/include/linux/qcom-geni-se.h
> index 3bcd67f..9bf03e9 100644
> --- a/include/linux/qcom-geni-se.h
> +++ b/include/linux/qcom-geni-se.h
> @@ -33,6 +33,10 @@ enum geni_se_protocol_type {
> * @clk: Handle to the core serial engine clock
> * @num_clk_levels: Number of valid clock levels in clk_perf_tbl
> * @clk_perf_tbl: Table of clock frequency input to serial engine
> clock
> + * @avg_bw: Average bus bandwidth value for Serial Engine device
> + * @peak_bw: Peak bus bandwidth value for Serial Engine device
> + * @peak_bw_list: List Head of peak bus banwidth list for Serial
> Engine
> + * device
> */
> struct geni_se {
> void __iomem *base;
> @@ -41,6 +45,9 @@ struct geni_se {
> struct clk *clk;
> unsigned int num_clk_levels;
> unsigned long *clk_perf_tbl;
> + u32 avg_bw;
> + u32 peak_bw;
> + struct list_head peak_bw_list;
> };
>
> /* Common SE registers */
> @@ -416,5 +423,9 @@ int geni_se_rx_dma_prep(struct geni_se *se, void
> *buf, size_t len,
> void geni_se_tx_dma_unprep(struct geni_se *se, dma_addr_t iova, size_t
> len);
>
> void geni_se_rx_dma_unprep(struct geni_se *se, dma_addr_t iova, size_t
> len);
> +
> +int geni_interconnect_init(struct geni_se *se);
> +
> +void geni_icc_update_bw(struct geni_se *se, bool update);
> #endif
> #endif
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: soc: qcom: Add interconnect binding for GENI QUP
From: alokc @ 2019-01-23 6:48 UTC (permalink / raw)
To: linux-arm-msm, devicetree, linux-kernel, linux-i2c, linux-spi,
linux-serial, Andy Gross, David Brown, Rob Herring, Mark Rutland,
Mark Brown
Cc: georgi.djakov, dianders, swboyd, bjorn.andersson,
linux-serial-owner
In-Reply-To: <1548138816-1149-2-git-send-email-alokc@codeaurora.org>
+Mark Brown
On 2019-01-22 12:03, Alok Chauhan wrote:
> Add documentation for the interconnect and interconnect-names bindings
> for the GENI QUP as detailed by bindings/interconnect/interconnect.txt.
>
> Signed-off-by: Alok Chauhan <alokc@codeaurora.org>
> ---
> Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt | 10
> ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
> b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
> index dab7ca9..44d7e02 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
> @@ -17,6 +17,12 @@ Required properties if child node exists:
> - #address-cells: Must be <1> for Serial Engine Address
> - #size-cells: Must be <1> for Serial Engine Address Size
> - ranges: Must be present
> +- interconnects: phandle to a interconnect provider. Please refer
> + ../interconnect/interconnect.txt for details.
> + Must be 2 paths corresponding to 2 AXI ports.
> +- interconnect-names: Port names to differentiate between the
> + 2 interconnect paths defined with interconnect
> + specifier.
>
> Properties for children:
>
> @@ -67,6 +73,10 @@ Example:
> #size-cells = <1>;
> ranges;
>
> + interconnects = <&qnoc 11 &qnoc 512>,
> + <&qnoc 0 &qnoc 543>;
> + interconnect-names = "qup-memory", "qup-config";
> +
> i2c0: i2c@a94000 {
> compatible = "qcom,geni-i2c";
> reg = <0xa94000 0x4000>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 0/6] Add interconnect support for GENI QUPs
From: alokc @ 2019-01-23 6:45 UTC (permalink / raw)
To: linux-arm-msm, devicetree, linux-kernel, linux-i2c, linux-spi,
linux-serial, Mark Brown
Cc: andy.gross, david.brown, georgi.djakov, dianders, swboyd,
bjorn.andersson, linux-arm-msm-owner
In-Reply-To: <1548138816-1149-1-git-send-email-alokc@codeaurora.org>
+Mark Brown
On 2019-01-22 12:03, Alok Chauhan wrote:
> This patch series contains following:
> * Add wrapper framework to support interconnect path from GENI QUPs.
> This wrapper enabled and help individual SEs to put their BW request.
> Adding this wrapper make sense because we don't want individual SEs
> to request to interconnect driver separately and put individual bw
> votes from QUP.
>
> This wrapper framework does the following:
> - Request for interconnect path handle
> - Maintain record of individual SEs' avg/peak bw.
> - Aggregated avg/peak bw based on how many SE's are active and put
> single bw request from QUP
>
> * Interconnect wrapper API calling from I2C, SPI & Uart driver
> * dt binding in sdm845 soc for Interconnect path for GENI QUPs
> * dt binding documentation
>
>
> Alok Chauhan (6):
> dt-bindings: soc: qcom: Add interconnect binding for GENI QUP
> soc: qcom: Add wrapper to support for Interconnect path
> i2c: i2c-qcom-geni: Add interconnect support
> spi: spi-geni-qcom: Add interconnect support
> tty: serial: qcom_geni_serial: Add interconnect support
> arm64: dts: sdm845: Add interconnect for GENI QUP
>
> .../devicetree/bindings/soc/qcom/qcom,geni-se.txt | 10 ++
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 14 +++
> drivers/i2c/busses/i2c-qcom-geni.c | 13 +++
> drivers/soc/qcom/qcom-geni-se.c | 129
> +++++++++++++++++++++
> drivers/spi/spi-geni-qcom.c | 20 +++-
> drivers/tty/serial/qcom_geni_serial.c | 27 ++++-
> include/linux/qcom-geni-se.h | 11 ++
> 7 files changed, 222 insertions(+), 2 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH] tty: serial: lpc32xx_hs: fix missing console boot messages
From: Vladimir Zapolskiy @ 2019-01-22 22:38 UTC (permalink / raw)
To: Alexandre Belloni, Greg Kroah-Hartman
Cc: Roland Stigge, Sylvain Lemieux, linux-kernel, linux-serial,
Jiri Slaby, linux-arm-kernel
In-Reply-To: <20190115171814.21789-1-alexandre.belloni@bootlin.com>
Hi Alexandre,
On 01/15/2019 07:18 PM, Alexandre Belloni wrote:
> When probing the HSUART, it is put in loopback mode in order to prevent a
> potential issue that may happen on RX (Errata HSUART.1).
>
> serial_lpc32xx_startup() moves it out of loopback mode but this is too late
> to get the kernel boot messages before userspace opens the device.
>
> Also get out of loopback mode in lpc32xx_hsuart_console_setup().
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
the change looks good, thank you.
Acked-by: Vladimir Zapolskiy <vz@mleia.com>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH 4/6] spi: spi-geni-qcom: Add interconnect support
From: Mark Brown @ 2019-01-22 20:29 UTC (permalink / raw)
To: Alok Chauhan
Cc: linux-arm-msm, devicetree, linux-kernel, linux-i2c, linux-spi,
linux-serial, andy.gross, david.brown, georgi.djakov, dianders,
swboyd, bjorn.andersson
In-Reply-To: <1548138816-1149-5-git-send-email-alokc@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 304 bytes --]
On Tue, Jan 22, 2019 at 12:03:34PM +0530, Alok Chauhan wrote:
> Get the interconnect paths for SPI based Serial Engine device
> and vote accordingly based on maximum supported SPI frequency.
Still not seeing anything except this patch here in my inbox - like I
said what's the story with dependencies?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] tty: serial: 8250_mtk: Fix potential NULL pointer dereference
From: Gustavo A. R. Silva @ 2019-01-22 19:57 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Matthias Brugger
Cc: linux-serial, linux-arm-kernel, linux-mediatek, linux-kernel,
Gustavo A. R. Silva
There is a potential NULL pointer dereference in case devm_kzalloc()
fails and returns NULL.
Fix this by adding a NULL check on data->dma
This bug was detected with the help of Coccinelle.
Fixes: 85b5c1dd0456 ("serial: 8250-mtk: add uart DMA support")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/tty/serial/8250/8250_mtk.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c
index e2c407656fa6..c1fdbc0b6840 100644
--- a/drivers/tty/serial/8250/8250_mtk.c
+++ b/drivers/tty/serial/8250/8250_mtk.c
@@ -357,6 +357,9 @@ static int mtk8250_probe_of(struct platform_device *pdev, struct uart_port *p,
if (dmacnt == 2) {
data->dma = devm_kzalloc(&pdev->dev, sizeof(*data->dma),
GFP_KERNEL);
+ if (!data->dma)
+ return -ENOMEM;
+
data->dma->fn = mtk8250_dma_filter;
data->dma->rx_size = MTK_UART_RX_SIZE;
data->dma->rxconf.src_maxburst = MTK_UART_RX_TRIGGER;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] 8250_pci.c: Update NI specific devices class to multi serial
From: Heikki Krogerus @ 2019-01-22 11:55 UTC (permalink / raw)
To: Guan Yung Tseng, Andy Shevchenko; +Cc: gregkh, linux-serial, linux-kernel
In-Reply-To: <1547475005-23435-1-git-send-email-guan.yung.tseng@ni.com>
[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]
+Andy
On Mon, Jan 14, 2019 at 10:10:05PM +0800, Guan Yung Tseng wrote:
> Modified NI devices class to PCI_CLASS_COMMUNICATION_MULTISERIAL.
> The reason of doing this is because all NI multi port serial cards
> use PCI_CLASS_COMMUNICATION_OTHER class and thus fail the
> serial_pci_is_class_communication test added in the commit 7d8905d06405
> ("serial: 8250_pci: Enable device after we check black list").
OK, so commit 7d8905d06405 ("serial: 8250_pci: Enable device after we
check black list") has created a regression. If the device does not
use PCI_CLASS_COMMUNICATION*SERIAL class, probe will fail, and I
don't think that is how the driver should function.
If the device id is listed in serial_pci_tbl, we need to probe the
device, regardless of the class id.
> Signed-off-by: Guan Yung Tseng <guan.yung.tseng@ni.com>
> ---
> drivers/tty/serial/8250/8250_pci.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
> index 4986b4a..0949db1 100644
> --- a/drivers/tty/serial/8250/8250_pci.c
> +++ b/drivers/tty/serial/8250/8250_pci.c
> @@ -663,6 +663,13 @@ static int pci_xircom_init(struct pci_dev *dev)
> return 0;
> }
>
> +static int pci_ni_probe(struct pci_dev *dev)
> +{
> + dev->class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8 |
> + (dev->class & 0xff);
> + return 0;
> +}
This is only working around the regression that 7d8905d064058 created,
and only with your UART. There may be others.
We need to fix the regression, not work around it. How about something
like the attached diff?
thanks,
--
heikki
[-- Attachment #2: improved_7d8905d064058.diff --]
[-- Type: text/plain, Size: 2360 bytes --]
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index f80a300b5d68..8b555c3a3670 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -3375,10 +3375,22 @@ static const struct pci_device_id blacklist[] = {
/* Exar devices */
{ PCI_VDEVICE(EXAR, PCI_ANY_ID), },
{ PCI_VDEVICE(COMMTECH, PCI_ANY_ID), },
+ { }
};
-static int serial_pci_is_class_communication(struct pci_dev *dev)
+/*
+ * Given a complete unknown PCI device, try to use some heuristics to
+ * guess what the configuration might be, based on the pitiful PCI
+ * serial specs. Returns 0 on success, -ENODEV on failure.
+ */
+static int
+serial_pci_guess_board(struct pci_dev *dev, struct pciserial_board *board)
{
+ int first_port = -1;
+ int num_iomem;
+ int num_port;
+ int i;
+
/*
* If it is not a communications device or the programming
* interface is greater than 6, give up.
@@ -3389,38 +3401,6 @@ static int serial_pci_is_class_communication(struct pci_dev *dev)
(dev->class & 0xff) > 6)
return -ENODEV;
- return 0;
-}
-
-static int serial_pci_is_blacklisted(struct pci_dev *dev)
-{
- const struct pci_device_id *bldev;
-
- /*
- * Do not access blacklisted devices that are known not to
- * feature serial ports or are handled by other modules.
- */
- for (bldev = blacklist;
- bldev < blacklist + ARRAY_SIZE(blacklist);
- bldev++) {
- if (dev->vendor == bldev->vendor &&
- dev->device == bldev->device)
- return -ENODEV;
- }
-
- return 0;
-}
-
-/*
- * Given a complete unknown PCI device, try to use some heuristics to
- * guess what the configuration might be, based on the pitiful PCI
- * serial specs. Returns 0 on success, -ENODEV on failure.
- */
-static int
-serial_pci_guess_board(struct pci_dev *dev, struct pciserial_board *board)
-{
- int num_iomem, num_port, first_port = -1, i;
-
/*
* Should we try to make guesses for multiport serial devices later?
*/
@@ -3647,13 +3627,8 @@ pciserial_init_one(struct pci_dev *dev, const struct pci_device_id *ent)
board = &pci_boards[ent->driver_data];
- rc = serial_pci_is_class_communication(dev);
- if (rc)
- return rc;
-
- rc = serial_pci_is_blacklisted(dev);
- if (rc)
- return rc;
+ if (pci_match_id(blacklist, dev))
+ return -ENODEV;
rc = pcim_enable_device(dev);
pci_save_state(dev);
^ permalink raw reply related
* Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
From: Russell King - ARM Linux admin @ 2019-01-22 11:50 UTC (permalink / raw)
To: Sugaya, Taichi
Cc: Rob Herring, Stephen Boyd, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-clk, linux-kernel@vger.kernel.org, open list:SERIAL DRIVERS,
Michael Turquette, Mark Rutland, Greg Kroah-Hartman,
Daniel Lezcano, Thomas Gleixner, Jiri Slaby, Masami Hiramatsu,
Jassi Brar
In-Reply-To: <daa5f00a-1d9c-69b0-ed2d-8ff6a64251cc@socionext.com>
On Tue, Jan 22, 2019 at 08:36:03PM +0900, Sugaya, Taichi wrote:
> Hi
>
> On 2018/12/04 22:32, Rob Herring wrote:
> > On Tue, Dec 4, 2018 at 5:30 AM Sugaya, Taichi
> > <sugaya.taichi@socionext.com> wrote:
> > >
> > > Hi
> > >
> > > On 2018/12/04 0:49, Rob Herring wrote:
> > > > On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi
> > > > <sugaya.taichi@socionext.com> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > On 2018/11/30 17:16, Stephen Boyd wrote:
> > > > > > Quoting Sugaya, Taichi (2018-11-29 04:24:51)
> > > > > > > On 2018/11/28 11:01, Stephen Boyd wrote:
> > > > > > > > Quoting Sugaya Taichi (2018-11-18 17:01:07)
> > > > > > > > > create mode 100644 Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
> > > > > > > > >
> > > > > > > > > diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
> > > > > > > > > new file mode 100644
> > > > > > > > > index 0000000..f5d906c
> > > > > > > > > --- /dev/null
> > > > > > > > > +++ b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
> > > > > > > > > @@ -0,0 +1,12 @@
> > > > > > > > > +Socionext M10V SMP trampoline driver binding
> > > > > > > > > +
> > > > > > > > > +This is a driver to wait for sub-cores while boot process.
> > > > > > > > > +
> > > > > > > > > +- compatible: should be "socionext,smp-trampoline"
> > > > > > > > > +- reg: should be <0x4C000100 0x100>
> > > > > > > > > +
> > > > > > > > > +EXAMPLE
> > > > > > > > > + trampoline: trampoline@0x4C000100 {
> > > > > > > > Drop the 0x part of unit addresses.
> > > > > > >
> > > > > > > Okay.
> > > > > > >
> > > > > > >
> > > > > > > > > + compatible = "socionext,smp-trampoline";
> > > > > > > > > + reg = <0x4C000100 0x100>;
> > > > > > > > Looks like a software construct, which we wouldn't want to put into DT
> > > > > > > > this way. DT doesn't describe drivers.
> > > > > > > We would like to use this node only getting the address of the
> > > > > > > trampoline area
> > > > > > > in which sub-cores wait. (They have finished to go to this area in previous
> > > > > > > bootloader process.)
> > > > > >
> > > > > > Is this area part of memory, or a special SRAM? If it's part of memory,
> > > > > > I would expect this node to be under the reserved-memory node and
> > > > > > pointed to by some other node that uses this region. Could even be the
> > > > > > CPU nodes.
> > > > >
> > > > > Yes, 0x4C000100 is a part of memory under the reserved-memory node. So
> > > > > we would like to use the SRAM ( allocated 0x00000000 ) area instead.
> > > > > BTW, sorry, the trampoline address of this example is simply wrong. We
> > > > > were going to use a part of the SRAM from the beginning.
> > > > >
> > > > > >
> > > > > > >
> > > > > > > So should we embed the constant value in source codes instead of getting
> > > > > > > from
> > > > > > > DT because the address is constant at the moment? Or is there other
> > > > > > > approach?
> > > > > > >
> > > > > >
> > > > > > If it's constant then that also works. Why does it need to come from DT
> > > > > > at all then?
> > > > >
> > > > > We think it is not good to embed constant value in driver codes and do
> > > > > not have another way...
> > > > > Are there better ways?
> > > >
> > > > If this is just memory, can you use the standard spin-table binding in
> > > > the DT spec? There are some requirements like 64-bit values even on
> > > > 32-bit machines (though this gets violated).
> > >
> > > The spin-table seems to be used on only 64-bit arch. Have it ever worked
> > > on 32-bit machine?
> >
> > Yes.
> >
> > > And I would like not to use it because avoid violation.
> >
> > The issue now that I remember is cpu-release-addr is defined to always
> > be a 64-bit value while some platforms made it a 32-bit value.
> > 'cpu-release-addr' is also used for some other enable-methods.
>
> I have a question about the spin-table.
> The code "smp_spin_table.c" is only in "arch/arm64/kernel" directory so can
> not be compiled in arm-v7 arch. That means the spin-table can not be used
> arm-v7 arch..? , or is there the way to compile the code in arm-v7 arch?
Why do you think you need it? Do you have no way to control individual
CPUs?
We are going through a process in 32-bit eliminating the "spin table"
stuff from platforms.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
From: Sugaya, Taichi @ 2019-01-22 11:36 UTC (permalink / raw)
To: Rob Herring
Cc: Stephen Boyd, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-clk, linux-kernel@vger.kernel.org, open list:SERIAL DRIVERS,
Michael Turquette, Mark Rutland, Greg Kroah-Hartman,
Daniel Lezcano, Thomas Gleixner, Russell King, Jiri Slaby,
Masami Hiramatsu, Jassi Brar
In-Reply-To: <CAL_JsqJ=FRfzVFiOJ0wvoV5iZV+Gx3ft9pGyhb-GoKnOAQgPtQ@mail.gmail.com>
Hi
On 2018/12/04 22:32, Rob Herring wrote:
> On Tue, Dec 4, 2018 at 5:30 AM Sugaya, Taichi
> <sugaya.taichi@socionext.com> wrote:
>>
>> Hi
>>
>> On 2018/12/04 0:49, Rob Herring wrote:
>>> On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi
>>> <sugaya.taichi@socionext.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 2018/11/30 17:16, Stephen Boyd wrote:
>>>>> Quoting Sugaya, Taichi (2018-11-29 04:24:51)
>>>>>> On 2018/11/28 11:01, Stephen Boyd wrote:
>>>>>>> Quoting Sugaya Taichi (2018-11-18 17:01:07)
>>>>>>>> create mode 100644 Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
>>>>>>>> new file mode 100644
>>>>>>>> index 0000000..f5d906c
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
>>>>>>>> @@ -0,0 +1,12 @@
>>>>>>>> +Socionext M10V SMP trampoline driver binding
>>>>>>>> +
>>>>>>>> +This is a driver to wait for sub-cores while boot process.
>>>>>>>> +
>>>>>>>> +- compatible: should be "socionext,smp-trampoline"
>>>>>>>> +- reg: should be <0x4C000100 0x100>
>>>>>>>> +
>>>>>>>> +EXAMPLE
>>>>>>>> + trampoline: trampoline@0x4C000100 {
>>>>>>> Drop the 0x part of unit addresses.
>>>>>>
>>>>>> Okay.
>>>>>>
>>>>>>
>>>>>>>> + compatible = "socionext,smp-trampoline";
>>>>>>>> + reg = <0x4C000100 0x100>;
>>>>>>> Looks like a software construct, which we wouldn't want to put into DT
>>>>>>> this way. DT doesn't describe drivers.
>>>>>> We would like to use this node only getting the address of the
>>>>>> trampoline area
>>>>>> in which sub-cores wait. (They have finished to go to this area in previous
>>>>>> bootloader process.)
>>>>>
>>>>> Is this area part of memory, or a special SRAM? If it's part of memory,
>>>>> I would expect this node to be under the reserved-memory node and
>>>>> pointed to by some other node that uses this region. Could even be the
>>>>> CPU nodes.
>>>>
>>>> Yes, 0x4C000100 is a part of memory under the reserved-memory node. So
>>>> we would like to use the SRAM ( allocated 0x00000000 ) area instead.
>>>> BTW, sorry, the trampoline address of this example is simply wrong. We
>>>> were going to use a part of the SRAM from the beginning.
>>>>
>>>>>
>>>>>>
>>>>>> So should we embed the constant value in source codes instead of getting
>>>>>> from
>>>>>> DT because the address is constant at the moment? Or is there other
>>>>>> approach?
>>>>>>
>>>>>
>>>>> If it's constant then that also works. Why does it need to come from DT
>>>>> at all then?
>>>>
>>>> We think it is not good to embed constant value in driver codes and do
>>>> not have another way...
>>>> Are there better ways?
>>>
>>> If this is just memory, can you use the standard spin-table binding in
>>> the DT spec? There are some requirements like 64-bit values even on
>>> 32-bit machines (though this gets violated).
>>
>> The spin-table seems to be used on only 64-bit arch. Have it ever worked
>> on 32-bit machine?
>
> Yes.
>
>> And I would like not to use it because avoid violation.
>
> The issue now that I remember is cpu-release-addr is defined to always
> be a 64-bit value while some platforms made it a 32-bit value.
> 'cpu-release-addr' is also used for some other enable-methods.
I have a question about the spin-table.
The code "smp_spin_table.c" is only in "arch/arm64/kernel" directory so
can not be compiled in arm-v7 arch. That means the spin-table can not be
used arm-v7 arch..? , or is there the way to compile the code in arm-v7
arch?
Thanks,
Sugaya Taichi
>
> Rob
>
^ permalink raw reply
* [PATCH v2] 8250_pci.c: Update NI specific devices class to multi serial
From: Guan Yung Tseng @ 2019-01-22 9:19 UTC (permalink / raw)
To: gregkh, hch; +Cc: linux-serial, linux-kernel, Guan Yung Tseng
On, Jan 14, 2019 at 10:10:05PM +0800, Guan Yung Tseng wrote:
>> Modified NI devices class to PCI_CLASS_COMMUNICATION_MULTISERIAL.
>> The reason of doing this is because all NI multi port serial cards
>> use PCI_CLASS_COMMUNICATION_OTHER class and thus fail the
>> serial_pci_is_class_communication test added in the commit 7d8905d06405
>> ("serial: 8250_pci: Enable device after we check black list").
>>
>> Signed-off-by: Guan Yung Tseng <guan.yung.tseng@ni.com>
>> ---
>> drivers/tty/serial/8250/8250_pci.c | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
>> index 4986b4a..0949db1 100644
>> --- a/drivers/tty/serial/8250/8250_pci.c
>> +++ b/drivers/tty/serial/8250/8250_pci.c
>> @@ -663,6 +663,13 @@ static int pci_xircom_init(struct pci_dev *dev)
>> return 0;
>> }
>>
>> +static int pci_ni_probe(struct pci_dev *dev)
>> +{
>> + dev->class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8 |
>> + (dev->class & 0xff);
>
> As Christoph said, this looks really odd. This field comes from the
> PCI structure on the device, it should not be modified by the kernel.
>
> Unless the device is broken and needs to be fixed up in the kernel?
>
> Also, you have sent 2 different patches here for this type of issue, are
> both needed? If so, please resend both of them as a patch series, with
> more explainations in this one as to why you are modifying this field.
>
> I've dropped all pending patches from you from my queue now.
>
Hi Christoph and Greg,
Sorry for the confusion sending 2 different patches to solve the same
issue. I should have wait for your response before sending antoher
patch to solve the similar issue.
For some historical reason, NI serial devices use
PCI_CLASS_COMMUNICATION_OTHER class code. Yes, I understand that
the class code should read from config space instead modified from
kernel. But these devices are shipped to the market for many years.
That's why I am trying to fix the problem in the kernel.
I will send another simple patch again to fix the problem.
^ permalink raw reply
* Re: [PATCH 3/6] i2c: i2c-qcom-geni: Add interconnect support
From: Peter Rosin @ 2019-01-22 9:13 UTC (permalink / raw)
To: Alok Chauhan, linux-arm-msm@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-i2c@vger.kernel.org, linux-spi@vger.kernel.org,
linux-serial@vger.kernel.org, Karthikeyan Ramasubramanian
Cc: andy.gross@linaro.org, david.brown@linaro.org,
georgi.djakov@linaro.org, dianders@chromium.org,
swboyd@chromium.org, bjorn.andersson@linaro.org
In-Reply-To: <1548138816-1149-4-git-send-email-alokc@codeaurora.org>
On 2019-01-22 07:33, Alok Chauhan wrote:
> Get the interconnect paths for I2C based Serial Engine device
> and vote accordingly based on maximum supported I2C frequency.
>
> Signed-off-by: Alok Chauhan <alokc@codeaurora.org>
> ---
> drivers/i2c/busses/i2c-qcom-geni.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c
> index db075bc..e8fe63a 100644
> --- a/drivers/i2c/busses/i2c-qcom-geni.c
> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
> @@ -14,6 +14,7 @@
> #include <linux/pm_runtime.h>
> #include <linux/qcom-geni-se.h>
> #include <linux/spinlock.h>
> +#include <linux/interconnect.h>
Please keep the includes sorted. Probably applies for the other patches
in the series as well?
Cheers,
Peter
^ permalink raw reply
* Re: [PATCH 3/6] i2c: i2c-qcom-geni: Add interconnect support
From: Wolfram Sang @ 2019-01-22 9:07 UTC (permalink / raw)
To: Alok Chauhan
Cc: linux-arm-msm, devicetree, linux-kernel, linux-i2c, linux-spi,
linux-serial, Karthikeyan Ramasubramanian, andy.gross,
david.brown, georgi.djakov, dianders, swboyd, bjorn.andersson
In-Reply-To: <1548138816-1149-4-git-send-email-alokc@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 300 bytes --]
On Tue, Jan 22, 2019 at 12:03:33PM +0530, Alok Chauhan wrote:
> Get the interconnect paths for I2C based Serial Engine device
> and vote accordingly based on maximum supported I2C frequency.
>
> Signed-off-by: Alok Chauhan <alokc@codeaurora.org>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH 6/6] arm64: dts: sdm845: Add interconnect for GENI QUP
From: Alok Chauhan @ 2019-01-22 6:33 UTC (permalink / raw)
To: linux-arm-msm, devicetree, linux-kernel, linux-i2c, linux-spi,
linux-serial, Andy Gross, David Brown, Rob Herring, Mark Rutland
Cc: georgi.djakov, dianders, swboyd, bjorn.andersson, Alok Chauhan
In-Reply-To: <1548138816-1149-1-git-send-email-alokc@codeaurora.org>
Add interconnect ports for GENI QUPs to set bus
capabilities.
Signed-off-by: Alok Chauhan <alokc@codeaurora.org>
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index c27cbd3..fb0a8a7 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -374,6 +374,13 @@
#address-cells = <1>;
#size-cells = <1>;
ranges;
+
+ interconnects = <&rsc_hlos MASTER_BLSP_1
+ &rsc_hlos SLAVE_EBI1>,
+ <&rsc_hlos MASTER_APPSS_PROC
+ &rsc_hlos SLAVE_BLSP_1>;
+ interconnect-names = "qup-memory", "qup-config";
+
status = "disabled";
i2c0: i2c@880000 {
@@ -682,6 +689,13 @@
#address-cells = <1>;
#size-cells = <1>;
ranges;
+
+ interconnects = <&rsc_hlos MASTER_BLSP_2
+ &rsc_hlos SLAVE_EBI1>,
+ <&rsc_hlos MASTER_APPSS_PROC
+ &rsc_hlos SLAVE_BLSP_2>;
+ interconnect-names = "qup-memory", "qup-config";
+
status = "disabled";
i2c8: i2c@a80000 {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 5/6] tty: serial: qcom_geni_serial: Add interconnect support
From: Alok Chauhan @ 2019-01-22 6:33 UTC (permalink / raw)
To: linux-arm-msm, devicetree, linux-kernel, linux-i2c, linux-spi,
linux-serial, Greg Kroah-Hartman, Jiri Slaby
Cc: andy.gross, david.brown, georgi.djakov, dianders, swboyd,
bjorn.andersson, Alok Chauhan
In-Reply-To: <1548138816-1149-1-git-send-email-alokc@codeaurora.org>
Get the interconnect paths for Uart based Serial Engine device
and vote accordingly based on maximum supported Uart frequency.
Signed-off-by: Alok Chauhan <alokc@codeaurora.org>
---
drivers/tty/serial/qcom_geni_serial.c | 27 ++++++++++++++++++++++++++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
index a72d6d9..e2ea499 100644
--- a/drivers/tty/serial/qcom_geni_serial.c
+++ b/drivers/tty/serial/qcom_geni_serial.c
@@ -19,6 +19,7 @@
#include <linux/slab.h>
#include <linux/tty.h>
#include <linux/tty_flip.h>
+#include <linux/interconnect.h>
/* UART specific GENI registers */
#define SE_UART_LOOPBACK_CFG 0x22c
@@ -1348,6 +1349,22 @@ static int qcom_geni_serial_probe(struct platform_device *pdev)
return ret;
}
+ /* Set the bus quota to a reasonable value */
+ port->se.avg_bw = console ? Bps_to_icc(1000) : Bps_to_icc(2500);
+ port->se.peak_bw = Bps_to_icc(76800000);
+ ret = geni_interconnect_init(&port->se);
+ if (ret) {
+ dev_err(&pdev->dev, "interconnect_init failed %d\n", ret);
+ return ret;
+ }
+
+ /*
+ * Vote for interconnect path early. This has to move as part of
+ * Runtime PM APIs when implemented for better control betwen
+ * console and non-console usecases
+ */
+ geni_icc_update_bw(&port->se, true);
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
return -EINVAL;
@@ -1385,8 +1402,15 @@ static int __maybe_unused qcom_geni_serial_sys_suspend(struct device *dev)
{
struct qcom_geni_serial_port *port = dev_get_drvdata(dev);
struct uart_port *uport = &port->uport;
+ int ret;
+
+ ret = uart_suspend_port(uport->private_data, uport);
+ if (ret)
+ return ret;
+
+ geni_icc_update_bw(&port->se, false);
- return uart_suspend_port(uport->private_data, uport);
+ return 0;
}
static int __maybe_unused qcom_geni_serial_sys_resume(struct device *dev)
@@ -1394,6 +1418,7 @@ static int __maybe_unused qcom_geni_serial_sys_resume(struct device *dev)
struct qcom_geni_serial_port *port = dev_get_drvdata(dev);
struct uart_port *uport = &port->uport;
+ geni_icc_update_bw(&port->se, true);
return uart_resume_port(uport->private_data, uport);
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 4/6] spi: spi-geni-qcom: Add interconnect support
From: Alok Chauhan @ 2019-01-22 6:33 UTC (permalink / raw)
To: linux-arm-msm, devicetree, linux-kernel, linux-i2c, linux-spi,
linux-serial, Mark Brown
Cc: andy.gross, david.brown, georgi.djakov, dianders, swboyd,
bjorn.andersson, Alok Chauhan
In-Reply-To: <1548138816-1149-1-git-send-email-alokc@codeaurora.org>
Get the interconnect paths for SPI based Serial Engine device
and vote accordingly based on maximum supported SPI frequency.
Signed-off-by: Alok Chauhan <alokc@codeaurora.org>
---
drivers/spi/spi-geni-qcom.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
index fdb7cb88..7bbbe9d 100644
--- a/drivers/spi/spi-geni-qcom.c
+++ b/drivers/spi/spi-geni-qcom.c
@@ -12,6 +12,7 @@
#include <linux/qcom-geni-se.h>
#include <linux/spi/spi.h>
#include <linux/spinlock.h>
+#include <linux/interconnect.h>
/* SPI SE specific registers and respective register fields */
#define SE_SPI_CPHA 0x224
@@ -589,6 +590,15 @@ static int spi_geni_probe(struct platform_device *pdev)
spin_lock_init(&mas->lock);
pm_runtime_enable(&pdev->dev);
+ /* Set the bus quota to a reasonable value */
+ mas->se.avg_bw = Bps_to_icc(2500);
+ mas->se.peak_bw = Bps_to_icc(200000000);
+ ret = geni_interconnect_init(&mas->se);
+ if (ret) {
+ dev_err(&pdev->dev, "interconnect_init failed %d\n", ret);
+ return ret;
+ }
+
ret = spi_geni_init(mas);
if (ret)
goto spi_geni_probe_runtime_disable;
@@ -628,8 +638,15 @@ static int __maybe_unused spi_geni_runtime_suspend(struct device *dev)
{
struct spi_master *spi = dev_get_drvdata(dev);
struct spi_geni_master *mas = spi_master_get_devdata(spi);
+ int ret;
- return geni_se_resources_off(&mas->se);
+ ret = geni_se_resources_off(&mas->se);
+ if (ret)
+ return ret;
+
+ geni_icc_update_bw(&mas->se, false);
+
+ return 0;
}
static int __maybe_unused spi_geni_runtime_resume(struct device *dev)
@@ -637,6 +654,7 @@ static int __maybe_unused spi_geni_runtime_resume(struct device *dev)
struct spi_master *spi = dev_get_drvdata(dev);
struct spi_geni_master *mas = spi_master_get_devdata(spi);
+ geni_icc_update_bw(&mas->se, true);
return geni_se_resources_on(&mas->se);
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox