From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>, vkoul@kernel.org Cc: yung-chuan.liao@linux.intel.com, sanyog.r.kale@intel.com, linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org Subject: Re: [PATCH 5/6] soundwire: qcom: update register read/write routine Date: Mon, 1 Feb 2021 15:50:44 +0000 [thread overview] Message-ID: <3a2b5c2d-21aa-2bf5-62df-ef85c7c9293c@linaro.org> (raw) In-Reply-To: <5c69ed09-60be-2f3d-ed25-f6dbfcb9d62f@linux.intel.com> On 29/01/2021 19:33, Pierre-Louis Bossart wrote: > > > On 1/29/21 11:32 AM, Srinivas Kandagatla wrote: >> In the existing code every soundwire register read and register write >> are kinda blocked. Each of these are using a special command id that > > what does 'kinda blocked' mean? I meant read/writes are waiting for completion interrupt! > >> generates interrupt after it successfully finishes. This is really >> overhead, limiting and not really necessary unless we are doing >> something special. >> >> We can simply read/write the fifo that should also give exactly >> what we need! This will also allow to read/write registers in >> interrupt context, which was not possible with the special >> command approach. > > This is really unclear, sorry. If read/writes are waiting for an interrupt, it becomes difficult to read or write to any registers from same interrupt handler! > >> + if (id != SWR_BROADCAST_CMD_ID) { >> + if (id < 14) >> + id += 1; >> + else >> + id = 0; > > that is really odd. if id=13 (group2) then id becomes 14 (master > address). A comment is really needed here. This is magic value for each fifo read or write, so that we can verify that them by comparing with this magic value! This has nothing to do with device number! > >> + if (cmd_id == SWR_BROADCAST_CMD_ID) { >> + /* >> + * sleep for 10ms for MSM soundwire variant to allow broadcast >> + * command to complete. > > that's also super-odd. There is nothing in SoundWire that makes any > difference between a regular and a broadcast command. they all complete > in the same time (a frame). >> + */ >> + ret = wait_for_completion_timeout(&swrm->broadcast, (2 * >> HZ/10)); > > is this 10ms really or dependent on CONFIG_HZ? > >> + if (!ret) >> + ret = SDW_CMD_IGNORED; >> + else >> + ret = SDW_CMD_OK; > > no CMD_FAILED support? Qcom controllers does not provide that information if the command is ignored or failed by any means! That was the behavior from the starting of this driver. > >> +static int qcom_swrm_cmd_fifo_rd_cmd(struct qcom_swrm_ctrl *swrm, >> + u8 dev_addr, u16 reg_addr, >> + u32 len, u8 *rval) >> +{ >> + u32 val; >> + u32 retry_attempt = 0; >> + u32 cmd_data; >> + int ret = SDW_CMD_OK; >> + >> + mutex_lock(&swrm->io_lock); >> + val = swrm_get_packed_reg_val(&swrm->rcmd_id, len, dev_addr, >> reg_addr); >> + >> + /* wait for FIFO RD to complete to avoid overflow */ >> + usleep_range(100, 105); >> + swrm->reg_write(swrm, SWRM_CMD_FIFO_RD_CMD, val); >> + /* wait for FIFO RD CMD complete to avoid overflow */ >> + usleep_range(250, 255); >> + >> +retry_read: >> + >> + swrm->reg_read(swrm, SWRM_CMD_FIFO_RD_FIFO_ADDR, &cmd_data); >> + rval[0] = cmd_data & 0xFF; >> + >> + if ((((cmd_data) & 0xF00) >> 8) != swrm->rcmd_id) { >> + if (retry_attempt < MAX_FIFO_RD_FAIL_RETRY) { >> + /* wait 500 us before retry on fifo read failure */ >> + usleep_range(500, 505); >> + if (retry_attempt == (MAX_FIFO_RD_FAIL_RETRY - 1)) { >> + swrm->reg_write(swrm, SWRM_CMD_FIFO_CMD, 0x1); >> + swrm->reg_write(swrm, SWRM_CMD_FIFO_RD_CMD, val); >> + } >> + retry_attempt++; >> + goto retry_read; >> + } else { >> + dev_err(swrm->dev, >> + "failed to read fifo: reg: 0x%x, \ >> + rcmd_id: 0x%x, dev_num: 0x%x, cmd_data: 0x%x\n", >> + reg_addr, swrm->rcmd_id, >> + dev_addr, cmd_data); >> + ret = SDW_CMD_IGNORED; >> + } >> } > > the flow seems complicated with multiple tests and goto? Can this be > simplified? I will try to simplify this in next version!
WARNING: multiple messages have this Message-ID (diff)
From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>, vkoul@kernel.org Cc: sanyog.r.kale@intel.com, yung-chuan.liao@linux.intel.com, linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org Subject: Re: [PATCH 5/6] soundwire: qcom: update register read/write routine Date: Mon, 1 Feb 2021 15:50:44 +0000 [thread overview] Message-ID: <3a2b5c2d-21aa-2bf5-62df-ef85c7c9293c@linaro.org> (raw) In-Reply-To: <5c69ed09-60be-2f3d-ed25-f6dbfcb9d62f@linux.intel.com> On 29/01/2021 19:33, Pierre-Louis Bossart wrote: > > > On 1/29/21 11:32 AM, Srinivas Kandagatla wrote: >> In the existing code every soundwire register read and register write >> are kinda blocked. Each of these are using a special command id that > > what does 'kinda blocked' mean? I meant read/writes are waiting for completion interrupt! > >> generates interrupt after it successfully finishes. This is really >> overhead, limiting and not really necessary unless we are doing >> something special. >> >> We can simply read/write the fifo that should also give exactly >> what we need! This will also allow to read/write registers in >> interrupt context, which was not possible with the special >> command approach. > > This is really unclear, sorry. If read/writes are waiting for an interrupt, it becomes difficult to read or write to any registers from same interrupt handler! > >> + if (id != SWR_BROADCAST_CMD_ID) { >> + if (id < 14) >> + id += 1; >> + else >> + id = 0; > > that is really odd. if id=13 (group2) then id becomes 14 (master > address). A comment is really needed here. This is magic value for each fifo read or write, so that we can verify that them by comparing with this magic value! This has nothing to do with device number! > >> + if (cmd_id == SWR_BROADCAST_CMD_ID) { >> + /* >> + * sleep for 10ms for MSM soundwire variant to allow broadcast >> + * command to complete. > > that's also super-odd. There is nothing in SoundWire that makes any > difference between a regular and a broadcast command. they all complete > in the same time (a frame). >> + */ >> + ret = wait_for_completion_timeout(&swrm->broadcast, (2 * >> HZ/10)); > > is this 10ms really or dependent on CONFIG_HZ? > >> + if (!ret) >> + ret = SDW_CMD_IGNORED; >> + else >> + ret = SDW_CMD_OK; > > no CMD_FAILED support? Qcom controllers does not provide that information if the command is ignored or failed by any means! That was the behavior from the starting of this driver. > >> +static int qcom_swrm_cmd_fifo_rd_cmd(struct qcom_swrm_ctrl *swrm, >> + u8 dev_addr, u16 reg_addr, >> + u32 len, u8 *rval) >> +{ >> + u32 val; >> + u32 retry_attempt = 0; >> + u32 cmd_data; >> + int ret = SDW_CMD_OK; >> + >> + mutex_lock(&swrm->io_lock); >> + val = swrm_get_packed_reg_val(&swrm->rcmd_id, len, dev_addr, >> reg_addr); >> + >> + /* wait for FIFO RD to complete to avoid overflow */ >> + usleep_range(100, 105); >> + swrm->reg_write(swrm, SWRM_CMD_FIFO_RD_CMD, val); >> + /* wait for FIFO RD CMD complete to avoid overflow */ >> + usleep_range(250, 255); >> + >> +retry_read: >> + >> + swrm->reg_read(swrm, SWRM_CMD_FIFO_RD_FIFO_ADDR, &cmd_data); >> + rval[0] = cmd_data & 0xFF; >> + >> + if ((((cmd_data) & 0xF00) >> 8) != swrm->rcmd_id) { >> + if (retry_attempt < MAX_FIFO_RD_FAIL_RETRY) { >> + /* wait 500 us before retry on fifo read failure */ >> + usleep_range(500, 505); >> + if (retry_attempt == (MAX_FIFO_RD_FAIL_RETRY - 1)) { >> + swrm->reg_write(swrm, SWRM_CMD_FIFO_CMD, 0x1); >> + swrm->reg_write(swrm, SWRM_CMD_FIFO_RD_CMD, val); >> + } >> + retry_attempt++; >> + goto retry_read; >> + } else { >> + dev_err(swrm->dev, >> + "failed to read fifo: reg: 0x%x, \ >> + rcmd_id: 0x%x, dev_num: 0x%x, cmd_data: 0x%x\n", >> + reg_addr, swrm->rcmd_id, >> + dev_addr, cmd_data); >> + ret = SDW_CMD_IGNORED; >> + } >> } > > the flow seems complicated with multiple tests and goto? Can this be > simplified? I will try to simplify this in next version!
next prev parent reply other threads:[~2021-02-01 15:52 UTC|newest] Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-29 17:32 [PATCH 0/6] soundwire: qcom: various improvements Srinivas Kandagatla 2021-01-29 17:32 ` Srinivas Kandagatla 2021-01-29 17:32 ` [PATCH 1/6] soundwire: qcom: add support to missing transport params Srinivas Kandagatla 2021-01-29 17:32 ` Srinivas Kandagatla 2021-01-29 19:20 ` Pierre-Louis Bossart 2021-01-29 19:20 ` Pierre-Louis Bossart 2021-02-01 15:50 ` Srinivas Kandagatla 2021-02-01 15:50 ` Srinivas Kandagatla 2021-02-01 16:33 ` Pierre-Louis Bossart 2021-02-01 16:33 ` Pierre-Louis Bossart 2021-02-01 14:13 ` Vinod Koul 2021-02-01 14:13 ` Vinod Koul 2021-02-01 15:50 ` Srinivas Kandagatla 2021-02-01 15:50 ` Srinivas Kandagatla 2021-01-29 17:32 ` [PATCH 2/6] soundwire: qcom: extract version field Srinivas Kandagatla 2021-01-29 17:32 ` Srinivas Kandagatla 2021-01-29 17:32 ` [PATCH 3/6] soundwire: qcom: set continue execution flag for ignored commands Srinivas Kandagatla 2021-01-29 17:32 ` Srinivas Kandagatla 2021-01-29 19:21 ` Pierre-Louis Bossart 2021-01-29 19:21 ` Pierre-Louis Bossart 2021-02-01 14:16 ` Vinod Koul 2021-02-01 14:16 ` Vinod Koul 2021-02-01 15:50 ` Srinivas Kandagatla 2021-02-01 15:50 ` Srinivas Kandagatla 2021-02-02 4:46 ` Vinod Koul 2021-02-02 4:46 ` Vinod Koul 2021-01-29 17:32 ` [PATCH 4/6] soundwire: qcom: start the clock during initialization Srinivas Kandagatla 2021-01-29 17:32 ` Srinivas Kandagatla 2021-02-01 14:21 ` Vinod Koul 2021-02-01 14:21 ` Vinod Koul 2021-02-01 15:50 ` Srinivas Kandagatla 2021-02-01 15:50 ` Srinivas Kandagatla 2021-02-02 4:46 ` Vinod Koul 2021-02-02 4:46 ` Vinod Koul 2021-01-29 17:32 ` [PATCH 5/6] soundwire: qcom: update register read/write routine Srinivas Kandagatla 2021-01-29 17:32 ` Srinivas Kandagatla 2021-01-29 19:33 ` Pierre-Louis Bossart 2021-01-29 19:33 ` Pierre-Louis Bossart 2021-02-01 15:50 ` Srinivas Kandagatla [this message] 2021-02-01 15:50 ` Srinivas Kandagatla 2021-02-01 16:42 ` Pierre-Louis Bossart 2021-02-01 16:42 ` Pierre-Louis Bossart 2021-02-02 10:19 ` Srinivas Kandagatla 2021-02-02 10:19 ` Srinivas Kandagatla 2021-02-02 16:58 ` Pierre-Louis Bossart 2021-02-02 16:58 ` Pierre-Louis Bossart 2021-02-01 14:26 ` Vinod Koul 2021-02-01 14:26 ` Vinod Koul 2021-02-01 15:50 ` Srinivas Kandagatla 2021-02-01 15:50 ` Srinivas Kandagatla 2021-01-29 17:32 ` [PATCH 6/6] soundwire: qcom: add support to new interrupts Srinivas Kandagatla 2021-01-29 17:32 ` Srinivas Kandagatla 2021-01-29 19:38 ` Pierre-Louis Bossart 2021-01-29 19:38 ` Pierre-Louis Bossart 2021-02-01 15:51 ` Srinivas Kandagatla 2021-02-01 15:51 ` Srinivas Kandagatla 2021-02-01 14:31 ` Vinod Koul 2021-02-01 14:31 ` Vinod Koul 2021-02-01 15:51 ` Srinivas Kandagatla 2021-02-01 15:51 ` Srinivas Kandagatla
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=3a2b5c2d-21aa-2bf5-62df-ef85c7c9293c@linaro.org \ --to=srinivas.kandagatla@linaro.org \ --cc=alsa-devel@alsa-project.org \ --cc=linux-kernel@vger.kernel.org \ --cc=pierre-louis.bossart@linux.intel.com \ --cc=sanyog.r.kale@intel.com \ --cc=vkoul@kernel.org \ --cc=yung-chuan.liao@linux.intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.