linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Santosh Y <santoshsy@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Vinayak Holikatti <vinholikatti@gmail.com>,
	James.Bottomley@hansenpartnership.com,
	linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
	patches@linaro.org, linux-samsung-soc@vger.kernel.org,
	saugata.das@linaro.org, venkat@linaro.org,
	girish.shivananjappa@linaro.org, vishak.g@samsung.com,
	k.rajesh@samsung.com, yejin.moon@samsung.com
Subject: Re: [PATCH 1/4] [SCSI] ufshcd: UFS Host controller driver
Date: Sat, 4 Feb 2012 12:28:27 +0530	[thread overview]
Message-ID: <CALMYJDvihhEojJMuohHDz3jXV7V3ty2BbgcJOxfXgckKyMas7w@mail.gmail.com> (raw)
In-Reply-To: <201202031519.02296.arnd@arndb.de>

On Fri, Feb 3, 2012 at 8:49 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 02 February 2012, Vinayak Holikatti wrote:
>> From: Santosh Yaraganavi <santoshsy@gmail.com>
>>
>> This patch adds support for Universal Flash Storage(UFS)
>> host controllers. The UFS host controller driver
>> includes host controller initialization method.
>>
>> The Initialization process involves following steps:
>>  - Initiate UFS Host Controller initialization process by writing
>>    to Host controller enable register
>>  - Configure UFS Host controller registers with host memory space
>>    datastructure offsets.
>>  - Unipro link startup procedure
>>  - Check for connected device
>>  - Configure UFS host controller to process requests
>>  - Enable required interrupts
>>  - Configure interrupt aggregation
>>
>> Signed-off-by: Santosh Yaraganavi <santoshsy@gmail.com>
>> Signed-off-by: Vinayak Holikatti <vinholikatti@gmail.com>
>> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
>> Reviewed-by: Saugata Das <saugata.das@linaro.org>
>> Reviewed-by: Vishak G <vishak.g@samsung.com>
>> Reviewed-by: Girish K S <girish.shivananjappa@linaro.org>
>
> Thanks for posting this here. Note that while I did review the patches
> in private email, I did not reply with a "Reviewed-by" tag, so you should
> not add it yourself.

Sure, we'll keep in mind.

>In particular, I had made some additional comments
> about the ufshcd_memory_alloc() function that have not been addressed.
>
> Getting the code changed will certainly not be a problem, but please
> be careful with assigning those tags in the future.
>
> The only major thing that I see missing is a review from James or
> someone else who is familiar with other scsi device drivers. Saugata
> and I have (in private) commented on a a number of more general issues
> and the comments were addressed before this patch set got sent out.
>
> Unless there are important concerns from the SCSI side, I believe this
> is going to be ready to get merged very soon, after the usual nitpicking
> is done ;-)
>
> Speaking of nitpicking:
>
>>--- /dev/null
>>+++ b/drivers/scsi/ufs/Kconfig
>>+
>>+#ifndef NULL
>>+#define NULL 0
>>+#endif  /* NULL */
>
> Please remove this #define, NULL is defined in <linux/stddef.h>
>
>>+#define BYTES_TO_DWORDS(p)     (p >> 2)
>>+#define UFSHCD_MMIO_BASE       (hba->mmio_base)
>
> Better remove these macros, too: The are clearly longer than the
> expanded text, and less clear.
>

Ok, we'll do so.

>>+struct ufs_hba {
>>+       /* Virtual memory reference */
>>+       void *ucdl_virt_addr;
>>+       void *utrdl_virt_addr;
>>+       void *utmrdl_virt_addr;
>>+       void *utrdl_virt_addr_aligned;
>>+       void *utmrdl_virt_addr_aligned;
>>+       void *ucdl_virt_addr_aligned;
>>+
>>+       size_t ucdl_size;
>>+       size_t utrdl_size;
>>+       size_t utmrdl_size;
>>+
>>+       /* DMA memory reference */
>>+       dma_addr_t ucdl_dma_addr;
>>+       dma_addr_t utrdl_dma_addr;
>>+       dma_addr_t utmrdl_dma_addr;
>>+       dma_addr_t utrdl_dma_addr_aligned;
>>+       dma_addr_t utmrdl_dma_addr_aligned;
>>+       dma_addr_t ucdl_dma_addr_aligned;
>
> You can remove most of these members by simplifying the allocation:
>
> - remove the _aligned variables and use WARN_ON to test that
>  the allocated buffers are aligned (they always are)
> - remove the sizes because they are computed from the number of
>  descriptors
> - if possible, remove the _dma_addr members by referencing them only
>  in the ufshcd_host_memory_configure() function that can get merged
>  into ufshcd_memory_alloc()
> - while you're here, change the type of the *_virt_addr to
>  struct utp_task_req_desc/utp_transfer_req_desc/utp_transfer_req_cmd_desc
>  and remove the _virt_addr postfix.
>

I tried,
if( !ucdl_dma_addr  || WARN_ON(ucdl_dma_addr & PAGE_SIZE))
        pr_err("Memory allocation failed\n");
but I was getting "memory allocation failed error".

Since we need ucdl 128 byte aligned,  utrdl and utmrdl 1kb aligned,
Currently I'm testing with the following code,

if( !ucdl_dma_addr  || WARN_ON(ucdl_dma_addr & (128 - 1))
        pr_err("Memory allocation failed\n");

if( !utrdl_dma_addr  || WARN_ON(utrdl_dma_addr & (1024 - 1))
        pr_err("Memory allocation failed\n");

and
if( !utmrdl_dma_addr  || WARN_ON(utmrdl_dma_addr & (1024 - 1))
        pr_err("Memory allocation failed\n");

also I'll make changes to the other things you pointed out.

>>+       if (NULL == hba->ucdl_virt_addr) {
>
> Here and in many other places, it's better to use the common kernel style
>
>        if (!hba->ucdl_virt_addr) {
>
> to check the validity of an object.
>

ok, we'll do so.

>>+static int ufshcd_make_hba_operational(struct ufs_hba *hba)
>>+{
>>+       u32 reg;
>>+
>>+       /* check if device present */
>>+       reg = readl((UFSHCD_MMIO_BASE + REG_CONTROLLER_STATUS));
>>+       if (ufshcd_is_device_present(reg)) {
>>+               dev_err(&hba->pdev->dev, "cc: Device not present\n");
>>+               return -EINVAL;
>>+       }
>>+
>>+       /*
>>+        * UCRDY, UTMRLDY and UTRLRDY bits must be 1
>>+        * DEI, HEI bits must be 0
>>+        */
>>+       if (!(ufshcd_get_lists_status(reg))) {
>>+               writel(UTP_TASK_REQ_LIST_RUN_STOP_BIT,
>>+                      (UFSHCD_MMIO_BASE +
>>+                       REG_UTP_TASK_REQ_LIST_RUN_STOP));
>>+               writel(UTP_TRANSFER_REQ_LIST_RUN_STOP_BIT,
>>+                      (UFSHCD_MMIO_BASE +
>>+                       REG_UTP_TRANSFER_REQ_LIST_RUN_STOP));
>>+       } else {
>>+               dev_err(&hba->pdev->dev,
>>+                       "Host controller not ready to process requests");
>>+               return -EINVAL;
>>+       }
>
> I guess ENXIO or EIO would be more fitting here than EINVAL, because you
> are not referring to incorrect user input.
>

ok, we'll update accordingly.

>>+#ifdef CONFIG_PM
>>+/**
>>+ * ufshcd_suspend - suspend power management function
>>+ * @pdev: pointer to PCI device handle
>>+ * @state: power state
>>+ *
>>+ * Returns -ENOSYS
>>+ */
>>+static int ufshcd_suspend(struct pci_dev *pdev, pm_message_t state)
>>+{
>>+       return -ENOSYS;
>>+}
>>+
>>+/**
>>+ * ufshcd_resume - resume power management function
>>+ * @pdev: pointer to PCI device handle
>>+ *
>>+ * Returns -ENOSYS
>>+ */
>>+static int ufshcd_resume(struct pci_dev *pdev)
>>+{
>>+       return -ENOSYS;
>>+}
>>+#endif /* CONFIG_PM */
>
> These look wrong. Are you planning to fill them in a later patch? If not,
> it's probably better to just remove these functions.
>

Yes, We'll implement power management in the next patch.
linux/Documentation/SubmittingDrivers suggested to define
.suspend and .resume methods returning -ENOSYS, if not yet implemented.
So it was added.

Thanks for your comments. Please let us know if you have any comments
on the other patches as well.

>        Arnd

-- 
~Santosh

  reply	other threads:[~2012-02-04  6:58 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-02  4:57 [PATCH 0/4] [SCSI] ufshcd: UFS Host Controller Driver Vinayak Holikatti
2012-02-02  4:57 ` [PATCH 1/4] [SCSI] ufshcd: UFS Host controller driver Vinayak Holikatti
2012-02-03 15:19   ` Arnd Bergmann
2012-02-04  6:58     ` Santosh Y [this message]
2012-02-07  7:16   ` Felipe Balbi
2012-02-07 15:10     ` Santosh Y
2012-02-09 19:15   ` Girish K S
2012-02-10  7:06     ` Santosh Y
2012-02-11 19:52       ` Arnd Bergmann
2012-02-02  4:57 ` [PATCH 2/4] [SCSI] ufshcd: UFS UTP Transfer requests handling Vinayak Holikatti
2012-02-05 12:51   ` Namjae Jeon
2012-02-05 14:36     ` Santosh Y
2012-02-08 19:48   ` Girish K S
2012-02-02  4:57 ` [PATCH 3/4] [SCSI] ufshcd: UFSHCI error handling Vinayak Holikatti
2012-02-02  4:57 ` [PATCH 4/4] [SCSI] ufshcd: SCSI " Vinayak Holikatti
2012-02-05  7:37   ` Namjae Jeon
2012-02-05  9:17     ` Santosh Y
2012-02-06  7:16   ` Amit Sahrawat
2012-02-06 19:00     ` Santosh Y
2012-02-11 17:39       ` Amit Sahrawat
2012-02-05  7:20 ` [PATCH 0/4] [SCSI] ufshcd: UFS Host Controller Driver Namjae Jeon
2012-02-05 22:45   ` Namjae Jeon
2012-02-06  7:17     ` Santosh Y
2012-02-09  4:34       ` Namjae Jeon
2012-02-09  7:53         ` Santosh Y

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=CALMYJDvihhEojJMuohHDz3jXV7V3ty2BbgcJOxfXgckKyMas7w@mail.gmail.com \
    --to=santoshsy@gmail.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=arnd@arndb.de \
    --cc=girish.shivananjappa@linaro.org \
    --cc=k.rajesh@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=patches@linaro.org \
    --cc=saugata.das@linaro.org \
    --cc=venkat@linaro.org \
    --cc=vinholikatti@gmail.com \
    --cc=vishak.g@samsung.com \
    --cc=yejin.moon@samsung.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 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).