From: "Verma, Devendra" <devverma@amd.com>
To: Frank Li <Frank.li@oss.nxp.com>
Cc: mani@kernel.org, vkoul@kernel.org, frank.li@kernel.org,
den@valinux.co.jp, dmaengine@vger.kernel.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
michal.simek@amd.com, devverma@amd.com
Subject: Re: [PATCH v3 1/2] dmaengine: dw-edma: Enable Chan Separation via VSEC
Date: Fri, 14 Aug 2026 10:33:27 +0530 [thread overview]
Message-ID: <d2ba38d4-ef37-465f-a2cc-268c23a1bee1@amd.com> (raw)
In-Reply-To: <an3xf0TgbXhmYt96@SMW015318>
On 13-Aug-26 22:01, Frank Li wrote:
> On Thu, Aug 13, 2026 at 05:26:51PM +0530, Verma, Devendra wrote:
>> On 10-Aug-26 22:44, Frank Li wrote:
>>> On Mon, Aug 10, 2026 at 03:40:01PM +0530, Devendra K Verma wrote:
>>>> As per, 'Designware Cores PCI Express DM Controller - Reference
>>>> Manual', section 3.2.34.3, VSEC for DEVICE INFORMATION supports
>>>> the channel separation mechanisms. Basically, the HDMA IP allows
>>>> the user to configure the separation between DMA channel
>>>> registers and retrieve it via the VSEC capability mentioned
>>>> above.
>>>>
>>>> HDMA IP supports the channel register space separation from
>>>> 256B to 32KB. Default supported size is 256B.
>>>>
>>>> Signed-off-by: Devendra K Verma <devverma@amd.com>
>>>> ---
>>>> Changes in v2:
>>>> o Replaced 'ch_sep_sz' with 'ch_space_sz' wherever
>>>> applicable upon reviewer recommendation.
>>>> o Dropped 1/3 patch of this series, after review,
>>>> now the 2/3 is 1/2 of the current patch series.
>>>>
>>>> Changes in v1:
>>>> o Modified dw_edma_get_ch_sep_sz() as per review comment.
>>>> The function now supports ch_sep_sz up to 32KB.
>>>> o Updated to description to reflect the supported channel
>>>> separation sizes.
>>>> ---
>>>> drivers/dma/dw-edma/dw-edma-pcie.c | 20 +++++++++++++++++---
>>>> 1 file changed, 17 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
>>>> index 791c46e8ae4c..5d7507a64056 100644
>>>> --- a/drivers/dma/dw-edma/dw-edma-pcie.c
>>>> +++ b/drivers/dma/dw-edma/dw-edma-pcie.c
>>>> @@ -31,8 +31,10 @@
>>>>
>>>> #define DW_PCIE_XILINX_MDB_VSEC_DMA_ID 0x6
>>>> #define DW_PCIE_XILINX_MDB_VSEC_ID 0x20
>>>> -#define DW_PCIE_XILINX_MDB_VSEC_DMA_BAR GENMASK(10, 8)
>>>> #define DW_PCIE_XILINX_MDB_VSEC_DMA_MAP GENMASK(2, 0)
>>>> +#define DW_PCIE_XILINX_MDB_VSEC_DMA_BAR GENMASK(10, 8)
>>>
>>> Don't mix code cleanup or reorg into this improvement patches.
>>>
>>
>> It was recommended by you in the v1 of the same patch series that is
>> why pushed it.
>>
>> Ref: https://lore.kernel.org/all/amDbGHRbObX-lt5F@SMW015318/
>
> You can fix the order by using prep patch, which just fix order, typo
> or some cleanup.
>
> But not mixed into new feature patches.
>
>>
>>>> +/* AMD CPM6 (Xilinx) supported cap */
>>>> +#define DW_PCIE_XILINX_CPM6_VSEC_CH_SEP GENMASK(18, 16)
>>>> #define DW_PCIE_XILINX_MDB_VSEC_DMA_WR_CH GENMASK(9, 0)
>>>> #define DW_PCIE_XILINX_MDB_VSEC_DMA_RD_CH GENMASK(25, 16)
>>>>
>>>> @@ -73,6 +75,7 @@ struct dw_edma_pcie_data {
>>>> u16 wr_ch_cnt;
>>>> u16 rd_ch_cnt;
>>>> u64 devmem_phys_off;
>>>> + u32 ch_space_sz;
>>>> };
>>>>
>>>> static const struct dw_edma_pcie_data snps_edda_data = {
>>>> @@ -127,7 +130,7 @@ static const struct dw_edma_pcie_data xilinx_mdb_data = {
>>>> };
>>>>
>>>> static const struct dw_edma_pcie_data xilinx_cpm6_dma_data = {
>>>> - /* MDB registers location */
>>>> + /* CPM6 registers location */
>>>
>>> This typo fix have not mixed this patch.
>>
>> This is subtle change. Since the focus of this patch series is CPM6, the
>> namings and comments should align with the appropriate name.
>>
Can we take up this change along with this patch series as it is related
to CPM6 only?
>>>
>>>> .rg.bar = BAR_0,
>>>> .rg.off = SZ_4K, /* 4 Kbytes */
>>>> .rg.sz = SZ_8K, /* 8 Kbytes */
>>>> @@ -189,6 +192,13 @@ static int dw_edma_pcie_irq_vector(struct device *dev, unsigned int nr)
>>>> return pci_irq_vector(to_pci_dev(dev), nr);
>>>> }
>>>>
>>>> +static u32 dw_edma_get_ch_space_sz(u32 val)
>>>> +{
>>>> + if (val > 0 && val <= 7)
>>>> + return 256 << val;
>>>> + return 256;
>>>> +}
>>>> +
>>>> static u64 dw_edma_pcie_address(struct device *dev, phys_addr_t cpu_addr)
>>>> {
>>>> struct pci_dev *pdev = to_pci_dev(dev);
>>>> @@ -279,6 +289,10 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
>>>> pdata->mf = map;
>>>> pdata->rg.bar = FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_BAR, val);
>>>>
>>>> + if (pdev->device == PCI_DEVICE_ID_XILINX_B00F)
>>>> + pdata->ch_space_sz = dw_edma_get_ch_space_sz
>>>> + (FIELD_GET(DW_PCIE_XILINX_CPM6_VSEC_CH_SEP, val));
>>>> +
>>>> pci_read_config_dword(pdev, vsec + 0xc, &val);
>>>> pdata->wr_ch_cnt = min(pdata->wr_ch_cnt,
>>>> FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_WR_CH, val));
>>>> @@ -324,9 +338,9 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>>>> struct dw_edma_pcie_data *pdata = (void *)pid->driver_data;
>>>> struct device *dev = &pdev->dev;
>>>> struct dw_edma_chip *chip;
>>>> + bool non_ll = false;
>>>> int err, nr_irqs;
>>>> int i, mask;
>>>> - bool non_ll = false;
>>>
>>> unnecssary change here
>>>
>>
>> Yeah, this change was part of some patch series I pushed.
>> This change was breaking the inverted X-mas format that's why
>> made this change.
>
> But not related this patch. Use a small sperate patch to fix these small
> problem.
>
> Use a small patch to do clean up, for example
>
> reorder register bit defination
> fix commends about CPM6
> fix inverted X-mas format.
>
The 1st and 3rd can be taken in a separate patch series but the 2nd
is related to CPM6 only so having it is beneficial with this patch
series, removes the misleading comment.
I will push the changes after your response.
-Devendra
> > Frank
>
>>
>> -Devendra
>>
>>> Frank
>>>>
>>>> if (!pdata)
>>>> return -ENODEV;
>>>> --
>>>> 2.43.0
>>>>
>>
next prev parent reply other threads:[~2026-08-14 5:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 10:10 [PATCH v3 0/2] CPM6 Channel Separation Support Devendra K Verma
2026-08-10 10:10 ` [PATCH v3 1/2] dmaengine: dw-edma: Enable Chan Separation via VSEC Devendra K Verma
2026-08-10 10:36 ` sashiko-bot
2026-08-10 17:14 ` Frank Li
2026-08-13 11:56 ` Verma, Devendra
2026-08-13 16:31 ` Frank Li
2026-08-14 5:03 ` Verma, Devendra [this message]
2026-08-10 10:10 ` [PATCH v3 2/2] dmaengine: dw-edma: Add changes to support Channel Separation Devendra K Verma
2026-08-10 10:40 ` sashiko-bot
2026-08-10 17:18 ` Frank Li
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=d2ba38d4-ef37-465f-a2cc-268c23a1bee1@amd.com \
--to=devverma@amd.com \
--cc=Frank.li@oss.nxp.com \
--cc=den@valinux.co.jp \
--cc=dmaengine@vger.kernel.org \
--cc=frank.li@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mani@kernel.org \
--cc=michal.simek@amd.com \
--cc=vkoul@kernel.org \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox