From: Tomas Henzl <thenzl@redhat.com>
To: "Reddy, Sreekanth" <Sreekanth.Reddy@avagotech.com>,
jejb@kernel.org, JBottomley@Parallels.com
Cc: linux-scsi@vger.kernel.org, Sathya.Prakash@avagotech.com,
Nagalakshmi.Nandigama@avagotech.com,
linux-kernel@vger.kernel.org, hch@infradead.org,
martin.petersen@oracle.com
Subject: Re: [RESEND][PATCH 7/8][SCSI]mpt3sas: Added Reply Descriptor Post Queue (RDPQ) Array support
Date: Tue, 05 Aug 2014 17:24:20 +0200 [thread overview]
Message-ID: <53E0F724.7070500@redhat.com> (raw)
In-Reply-To: <20140625104135.GA13038@avagotech.com>
On 06/25/2014 12:41 PM, Reddy, Sreekanth wrote:
> Up to now, Driver allocates a single contiguous block of memory
> pool for all reply queues and passes down a single address in the
> ReplyDescriptorPostQueueAddress field of the IOC Init Request
> Message to the firmware.
>
> When firmware receives this address, it will program each of the
> Reply Descriptor Post Queue registers, as each reply queue has its
> own register. Thus the firmware, starting from a base address it
> determines the starting address of the subsequent reply queues
> through some simple arithmetic calculations.
>
> The size of this contiguous block of memory pool is directly proportional
> to number of MSI-X vectors and the HBA queue depth. For example higher
> MSIX vectors requires larger contiguous block of memory pool.
>
> But some of the OS kernels are unable to allocate this larger
> contiguous block of memory pool.
>
> So, the proposal is to allocate memory independently for each
> Reply Queue and pass down all of the addresses to the firmware.
> Then the firmware will just take each address and program the value
> into the correct register.
>
> When HBAs with older firmware(i.e. without RDPQ capability) is used
> with this new driver then the max_msix_vectors value would be set
> to 8 by default.
>
> Signed-off-by: Sreekanth Reddy <Sreekanth.Reddy@avagotech.com>
> ---
> drivers/scsi/mpt3sas/mpt3sas_base.c | 916 ++++++++++++++++++++---------------
> drivers/scsi/mpt3sas/mpt3sas_base.h | 19 +-
> 2 files changed, 543 insertions(+), 392 deletions(-)
>
...
> +static int
> +_base_handshake_req_reply_wait(struct MPT3SAS_ADAPTER *ioc, int request_bytes,
> + u32 *request, int reply_bytes, u16 *reply, int timeout, int sleep_flag)
> +{
> + MPI2DefaultReply_t *default_reply = (MPI2DefaultReply_t *)reply;
> + int i;
> + u8 failed;
> + u16 dummy;
> + __le32 *mfp;
> +
> + /* make sure doorbell is not in use */
> + if ((readl(&ioc->chip->Doorbell) & MPI2_DOORBELL_USED)) {
if (readl(&ioc->chip->Doorbell) & MPI2_DOORBELL_USED) {
I think it's equal and better looking with less parentheses, but
it's a personal preference so you can ignore it.
> + pr_err(MPT3SAS_FMT "doorbell is in use (line=%d)\n",
> + ioc->name, __LINE__);
> + return -EFAULT;
> + }
> +
> + /* clear pending doorbell interrupts from previous state changes */
> + if (readl(&ioc->chip->HostInterruptStatus) &
> + MPI2_HIS_IOC2SYS_DB_STATUS)
> + writel(0, &ioc->chip->HostInterruptStatus);
> +
> + /* send message to ioc */
> + writel(((MPI2_FUNCTION_HANDSHAKE<<MPI2_DOORBELL_FUNCTION_SHIFT) |
> + ((request_bytes/4)<<MPI2_DOORBELL_ADD_DWORDS_SHIFT)),
> + &ioc->chip->Doorbell);
> +
> + if ((_base_wait_for_doorbell_int(ioc, 5, NO_SLEEP))) {
Most likely not a problem, but why NO_SLEEP and not the sleep_flag ?
> + pr_err(MPT3SAS_FMT "doorbell handshake int failed (line=%d)\n",
> + ioc->name, __LINE__);
> + return -EFAULT;
> + }
> + writel(0, &ioc->chip->HostInterruptStatus);
> +
> + if ((_base_wait_for_doorbell_ack(ioc, 5, sleep_flag))) {
> + pr_err(MPT3SAS_FMT "doorbell handshake ack failed (line=%d)\n",
> + ioc->name, __LINE__);
> + return -EFAULT;
> + }
> +
> + /* send message 32-bits at a time */
> + for (i = 0, failed = 0; i < request_bytes/4 && !failed; i++) {
> + writel(cpu_to_le32(request[i]), &ioc->chip->Doorbell);
> + if ((_base_wait_for_doorbell_ack(ioc, 5, sleep_flag)))
> + failed = 1;
> + }
...
@@ -2945,39 +3307,82 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc, int sleep_flag)
ioc->name, (unsigned long long)ioc->reply_free_dma));
total_sz += sz;
- /* reply post queue, 16 byte align */
- reply_post_free_sz = ioc->reply_post_queue_depth *
- sizeof(Mpi2DefaultReplyDescriptor_t);
- if (_base_is_controller_msix_enabled(ioc))
- sz = reply_post_free_sz * ioc->reply_queue_count;
- else
+ if (ioc->rdpq_array_enable) {
+ ioc->reply_post = kcalloc(ioc->reply_queue_count,
+ sizeof(struct reply_post_struct), GFP_KERNEL);
+ /* reply post queue, 16 byte align */
+ reply_post_free_sz = ioc->reply_post_queue_depth *
+ sizeof(Mpi2DefaultReplyDescriptor_t);
sz = reply_post_free_sz;
- ioc->reply_post_free_dma_pool = pci_pool_create("reply_post_free pool",
- ioc->pdev, sz, 16, 0);
- if (!ioc->reply_post_free_dma_pool) {
- pr_err(MPT3SAS_FMT
- "reply_post_free pool: pci_pool_create failed\n",
- ioc->name);
- goto out;
- }
- ioc->reply_post_free = pci_pool_alloc(ioc->reply_post_free_dma_pool ,
- GFP_KERNEL, &ioc->reply_post_free_dma);
- if (!ioc->reply_post_free) {
- pr_err(MPT3SAS_FMT
- "reply_post_free pool: pci_pool_alloc failed\n",
- ioc->name);
- goto out;
+ ioc->reply_post_free_dma_pool =
+ pci_pool_create("reply_post_free pool", ioc->pdev, sz,
+ 16, 2147483648);
Few lines below with older firmware you don't need this rather
high boundary of 2^31, why is it needed here?
Besides that, checkpatch shows 11 warnings and some of them might be functional -
"WARNING: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers"
please clean your patch next time.
Cheers,
Tomas
next prev parent reply other threads:[~2014-08-05 15:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-25 10:41 [RESEND][PATCH 7/8][SCSI]mpt3sas: Added Reply Descriptor Post Queue (RDPQ) Array support Reddy, Sreekanth
2014-06-25 10:41 ` Reddy, Sreekanth
2014-08-05 15:24 ` Tomas Henzl [this message]
[not found] ` <CAK=zhgqBfFpUJ1FTQGNKoGnLBBsX=6AGwr14DZVNjdAjihY0sw@mail.gmail.com>
2014-08-06 15:56 ` Tomas Henzl
-- strict thread matches above, loose matches on Subject: below --
2014-08-12 9:34 Sreekanth Reddy
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=53E0F724.7070500@redhat.com \
--to=thenzl@redhat.com \
--cc=JBottomley@Parallels.com \
--cc=Nagalakshmi.Nandigama@avagotech.com \
--cc=Sathya.Prakash@avagotech.com \
--cc=Sreekanth.Reddy@avagotech.com \
--cc=hch@infradead.org \
--cc=jejb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.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: link
Be 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.