All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sinan Kaya <okaya@codeaurora.org>
To: Vinod Koul <vinod.koul@intel.com>
Cc: dmaengine@vger.kernel.org, timur@codeaurora.org,
	cov@codeaurora.org, jcm@redhat.com, agross@codeaurora.org,
	arnd@arndb.de, linux-arm-msm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH V7 2/3] dma: add Qualcomm Technologies HIDMA management driver
Date: Tue, 1 Dec 2015 23:57:34 -0500	[thread overview]
Message-ID: <565E7A3E.1070207@codeaurora.org> (raw)
In-Reply-To: <20151201031710.GK3901@localhost>

On 11/30/2015 10:17 PM, Vinod Koul wrote:
> On Mon, Nov 30, 2015 at 09:42:01AM -0500, Sinan Kaya wrote:
> 
>>>> +static int hidma_mgmt_probe(struct platform_device *pdev)
>>>> +{
>>>> +	struct hidma_mgmt_dev *mgmtdev;
>>>> +	struct resource *res;
>>>> +	void __iomem *virtaddr;
>>>> +	int irq;
>>>> +	int rc;
>>>> +	u32 val;
>>>> +
>>>> +	pm_runtime_set_autosuspend_delay(&pdev->dev, AUTOSUSPEND_TIMEOUT);
>>>> +	pm_runtime_use_autosuspend(&pdev->dev);
>>>> +	pm_runtime_set_active(&pdev->dev);
>>>> +	pm_runtime_enable(&pdev->dev);
>>>
>>> at this time pm core will treat device as fully enabled and pm methods can
>>> be invoked, but you are not ready yet right. Typically these are done at the
>>> end of the probe unless you have a reason... 
>>
>> I need it here because the clocks are declared as ACPI power resources.
>> The kernel is turning off all power resources during initialization. In
>> order for this code to touch the hardware, I need to call enable so that
>> clocks are enabled once again.
> 
> The question is are you ready in your driver routines to be invoked by pm
> core?
> 

I don't have any support for suspend and resume PM APIs. The only PM
interface I support is PM runtime. PM can turn on/off the clocks based
on the reference counts it maintains after get/set APIs. Since PM is
turning off the clocks during power up before my driver load, I do need
to grab this lock to re-enable it during HW initialization. Then, let PM
turn off the clocks again after the AUTOSUSPEND_TIMEOUT when I'm done.

Is there any other interaction with the PM that I'm not aware of?

>>
>>>
>>>> +static ssize_t show_values(struct device *dev, struct device_attribute *attr,
>>>> +				char *buf)
>>>
>>> Please fix the coding style here and other places as well. 
>>
>> what's the problem here?
>>
>>> Specifically
>>> please read Chapter 2
>>>
>>
>> Why is checkpatch not complaining about any of the coding style issues?
>> I'm checking my code with checkpatch before submitting. Is there any
>> other tool that would catch this?
> 
> So did you read the Chapter 2.. Quoting here
> 

I did read the chapter 2. Maybe, my lack of native english speaking but
I don't get from this sentence that function parameters need to be
aligned to the opening paranthesis.

> Descendants are always substantially shorter than the parent
> and are placed substantially to the right. The same applies to function headers
> with a long argument list. 
> 

I ran Lindent and manually cleaned up the junk it introduced. The result
is this

static ssize_t show_values(struct device *dev, struct device_attribute
*attr,
			   char *buf)


> Your breaking lines is not placed substantially to the right..
> I do not think checkpatch is checking this..
> 


-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

WARNING: multiple messages have this Message-ID (diff)
From: okaya@codeaurora.org (Sinan Kaya)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V7 2/3] dma: add Qualcomm Technologies HIDMA management driver
Date: Tue, 1 Dec 2015 23:57:34 -0500	[thread overview]
Message-ID: <565E7A3E.1070207@codeaurora.org> (raw)
In-Reply-To: <20151201031710.GK3901@localhost>

On 11/30/2015 10:17 PM, Vinod Koul wrote:
> On Mon, Nov 30, 2015 at 09:42:01AM -0500, Sinan Kaya wrote:
> 
>>>> +static int hidma_mgmt_probe(struct platform_device *pdev)
>>>> +{
>>>> +	struct hidma_mgmt_dev *mgmtdev;
>>>> +	struct resource *res;
>>>> +	void __iomem *virtaddr;
>>>> +	int irq;
>>>> +	int rc;
>>>> +	u32 val;
>>>> +
>>>> +	pm_runtime_set_autosuspend_delay(&pdev->dev, AUTOSUSPEND_TIMEOUT);
>>>> +	pm_runtime_use_autosuspend(&pdev->dev);
>>>> +	pm_runtime_set_active(&pdev->dev);
>>>> +	pm_runtime_enable(&pdev->dev);
>>>
>>> at this time pm core will treat device as fully enabled and pm methods can
>>> be invoked, but you are not ready yet right. Typically these are done at the
>>> end of the probe unless you have a reason... 
>>
>> I need it here because the clocks are declared as ACPI power resources.
>> The kernel is turning off all power resources during initialization. In
>> order for this code to touch the hardware, I need to call enable so that
>> clocks are enabled once again.
> 
> The question is are you ready in your driver routines to be invoked by pm
> core?
> 

I don't have any support for suspend and resume PM APIs. The only PM
interface I support is PM runtime. PM can turn on/off the clocks based
on the reference counts it maintains after get/set APIs. Since PM is
turning off the clocks during power up before my driver load, I do need
to grab this lock to re-enable it during HW initialization. Then, let PM
turn off the clocks again after the AUTOSUSPEND_TIMEOUT when I'm done.

Is there any other interaction with the PM that I'm not aware of?

>>
>>>
>>>> +static ssize_t show_values(struct device *dev, struct device_attribute *attr,
>>>> +				char *buf)
>>>
>>> Please fix the coding style here and other places as well. 
>>
>> what's the problem here?
>>
>>> Specifically
>>> please read Chapter 2
>>>
>>
>> Why is checkpatch not complaining about any of the coding style issues?
>> I'm checking my code with checkpatch before submitting. Is there any
>> other tool that would catch this?
> 
> So did you read the Chapter 2.. Quoting here
> 

I did read the chapter 2. Maybe, my lack of native english speaking but
I don't get from this sentence that function parameters need to be
aligned to the opening paranthesis.

> Descendants are always substantially shorter than the parent
> and are placed substantially to the right. The same applies to function headers
> with a long argument list. 
> 

I ran Lindent and manually cleaned up the junk it introduced. The result
is this

static ssize_t show_values(struct device *dev, struct device_attribute
*attr,
			   char *buf)


> Your breaking lines is not placed substantially to the right..
> I do not think checkpatch is checking this..
> 


-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

  reply	other threads:[~2015-12-02  4:57 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-23  2:28 [PATCH V7 0/3] dma: add Qualcomm Technologies HIDMA driver Sinan Kaya
2015-11-23  2:28 ` Sinan Kaya
2015-11-23  2:28 ` [PATCH V7 1/3] dma: qcom_bam_dma: move to qcom directory Sinan Kaya
2015-11-23  2:28   ` Sinan Kaya
2015-11-25 21:42   ` Andy Gross
2015-11-25 21:42     ` Andy Gross
2015-11-28 15:06     ` Sinan Kaya
2015-11-28 15:06       ` Sinan Kaya
2015-11-23  2:28 ` [PATCH V7 2/3] dma: add Qualcomm Technologies HIDMA management driver Sinan Kaya
2015-11-23  2:28   ` Sinan Kaya
2015-11-23 18:06   ` Andy Shevchenko
2015-11-23 18:06     ` Andy Shevchenko
2015-11-23 18:49     ` Sinan Kaya
2015-11-23 18:49       ` Sinan Kaya
2015-11-30  8:21   ` Vinod Koul
2015-11-30  8:21     ` Vinod Koul
2015-11-30 14:42     ` Sinan Kaya
2015-11-30 14:42       ` Sinan Kaya
2015-12-01  3:17       ` Vinod Koul
2015-12-01  3:17         ` Vinod Koul
2015-12-01  3:17         ` Vinod Koul
2015-12-02  4:57         ` Sinan Kaya [this message]
2015-12-02  4:57           ` Sinan Kaya
2015-12-05  7:58           ` Vinod Koul
2015-12-05  7:58             ` Vinod Koul
2015-12-08 14:36             ` Sinan Kaya
2015-12-08 14:36               ` Sinan Kaya
2015-11-23  2:28 ` [PATCH V7 3/3] dma: add Qualcomm Technologies HIDMA channel driver Sinan Kaya
2015-11-23  2:28   ` Sinan Kaya
2015-11-30  8:59   ` Vinod Koul
2015-11-30  8:59     ` Vinod Koul
2015-11-30 20:06     ` Sinan Kaya
2015-11-30 20:06       ` Sinan Kaya
2015-12-01 11:34       ` Vinod Koul
2015-12-01 11:34         ` Vinod Koul
2015-12-01 21:16         ` Sinan Kaya
2015-12-01 21:16           ` Sinan Kaya
2015-12-02 19:04           ` Sinan Kaya
2015-12-02 19:04             ` Sinan Kaya
2015-12-05  8:00             ` Vinod Koul
2015-12-05  8:00               ` Vinod Koul
2015-12-08 14:33               ` Sinan Kaya
2015-12-08 14:33                 ` Sinan Kaya
2015-12-10 20:10               ` Sinan Kaya
2015-12-10 20:10                 ` Sinan Kaya
2015-12-11  9:35                 ` Vinod Koul
2015-12-11  9:35                   ` Vinod Koul
2015-12-17 23:52                   ` Sinan Kaya
2015-12-17 23:52                     ` Sinan Kaya

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=565E7A3E.1070207@codeaurora.org \
    --to=okaya@codeaurora.org \
    --cc=agross@codeaurora.org \
    --cc=arnd@arndb.de \
    --cc=cov@codeaurora.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=jcm@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=timur@codeaurora.org \
    --cc=vinod.koul@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: 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.