linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sanjay R Mehta <sanmehta@amd.com>
To: Vinod Koul <vkoul@kernel.org>, Sanjay R Mehta <Sanju.Mehta@amd.com>
Cc: gregkh@linuxfoundation.org, dan.j.williams@intel.com,
	Thomas.Lendacky@amd.com, Shyam-sundar.S-k@amd.com,
	Nehal-bakulchandra.Shah@amd.com, robh@kernel.org,
	mchehab+samsung@kernel.org, davem@davemloft.net,
	linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org
Subject: Re: [PATCH v4 1/3] dmaengine: ptdma: Initial driver for the AMD PTDMA controller
Date: Tue, 26 May 2020 11:35:02 +0530	[thread overview]
Message-ID: <f016a02b-ebc4-6280-dff4-25e189ff2d49@amd.com> (raw)
In-Reply-To: <20200504055539.GJ1375924@vkoul-mobl>

Apologies for my delayed response.

>> +#include <linux/module.h>
>> +#include <linux/kernel.h>
>> +#include <linux/pci.h>
>> +#include <linux/dma-mapping.h>
>> +#include <linux/interrupt.h>
>> +
>> +#include "ptdma.h"
>> +
>> +static int cmd_queue_length = 32;
>> +module_param(cmd_queue_length, uint, 0644);
>> +MODULE_PARM_DESC(cmd_queue_length,
>> +              " length of the command queue, a power of 2 (2 <= val <= 128)");
> 
> Any reason for this as module param? who will configure this and how?
> 
The command queue length can be from 2 to 64K command.
Therefore added as module parameter to allow the length of the queue to be specified at load time.

>> + * List of PTDMAs, PTDMA count, read-write access lock, and access functions
>> + *
>> + * Lock structure: get pt_unit_lock for reading whenever we need to
>> + * examine the PTDMA list. While holding it for reading we can acquire
>> + * the RR lock to update the round-robin next-PTDMA pointer. The unit lock
>> + * must be acquired before the RR lock.
>> + *
>> + * If the unit-lock is acquired for writing, we have total control over
>> + * the list, so there's no value in getting the RR lock.
>> + */
>> +static DEFINE_RWLOCK(pt_unit_lock);
>> +static LIST_HEAD(pt_units);
>> +
>> +static struct pt_device *pt_rr;
> 
> why do we need these globals and not in driver context?
> 
The AMD SOC has multiple PT controller's with the same PCI device ID and hence the same driver is probed for each instance.
The driver stores the pt_device context of each PT controller in this global list.

>> +static void pt_add_device(struct pt_device *pt)
>> +{
>> +     unsigned long flags;
>> +
>> +     write_lock_irqsave(&pt_unit_lock, flags);
>> +     list_add_tail(&pt->entry, &pt_units);
>> +     if (!pt_rr)
>> +             /*
>> +              * We already have the list lock (we're first) so this
>> +              * pointer can't change on us. Set its initial value.
>> +              */
>> +             pt_rr = pt;
>> +     write_unlock_irqrestore(&pt_unit_lock, flags);
>> +}
> 
> Can you please explain what do you mean by having a list of devices and
> why are we adding/removing dynamically?
> 
Since AMD SOC has many PT controller's with the same PCI device ID and
hence the same driver probed for initialization of each PT controller device instance.
Also, the number of PT controller varies for different AMD SOC's.
Therefore the dynamic adding/removing of each PT controller context to global device list implemented.
> --
> ~Vinod
> 

  reply	other threads:[~2020-05-26  6:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-28 21:13 [PATCH v4 0/3] Add support for AMD PTDMA controller driver Sanjay R Mehta
2020-04-28 21:13 ` [PATCH v4 1/3] dmaengine: ptdma: Initial driver for the AMD PTDMA controller Sanjay R Mehta
2020-05-04  5:55   ` Vinod Koul
2020-05-26  6:05     ` Sanjay R Mehta [this message]
2020-05-26  6:29       ` Greg KH
2020-05-26  6:36         ` Sanjay R Mehta
2020-04-28 21:13 ` [PATCH v4 2/3] dmaengine: ptdma: register PTDMA controller as a DMA resource Sanjay R Mehta
2020-05-04  6:14   ` Vinod Koul
2020-05-26  6:48     ` Sanjay R Mehta
2020-04-28 21:13 ` [PATCH v4 3/3] dmaengine: ptdma: Add debugfs entries for PTDMA information Sanjay R Mehta
2020-05-04  6:20   ` Vinod Koul
2020-05-26  6:10     ` Sanjay R Mehta

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=f016a02b-ebc4-6280-dff4-25e189ff2d49@amd.com \
    --to=sanmehta@amd.com \
    --cc=Nehal-bakulchandra.Shah@amd.com \
    --cc=Sanju.Mehta@amd.com \
    --cc=Shyam-sundar.S-k@amd.com \
    --cc=Thomas.Lendacky@amd.com \
    --cc=dan.j.williams@intel.com \
    --cc=davem@davemloft.net \
    --cc=dmaengine@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab+samsung@kernel.org \
    --cc=robh@kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).