All of lore.kernel.org
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Taniya Das <tdas@codeaurora.org>
Cc: Stephen Boyd <sboyd@kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	Rajendra Nayak <rnayak@codeaurora.org>,
	devicetree@vger.kernel.org, robh@kernel.org,
	skannan@codeaurora.org, linux-arm-msm@vger.kernel.org,
	evgreen@google.com
Subject: Re: [PATCH v11 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver
Date: Wed, 12 Dec 2018 10:17:02 +0530	[thread overview]
Message-ID: <20181212044702.jp2r3mviq4ffal42@vireshk-i7> (raw)
In-Reply-To: <82b168d1-79bc-f454-8e19-4f7630a34069@codeaurora.org>

On 11-12-18, 19:05, Taniya Das wrote:
> The design here assumes that there would not be any per-cpu/per-cluster
> based SW requirement for the HW during frequency transitions, which again
> makes me think that we would require to re-introduce these structures again
> in case we have such requirements in near future.

Firstly, even in such cases we can go ahead with the design we proposed. And I
am not at all concerned about some hardware which we don't have right now. We
will see what to do when such hardware comes, maybe reintroduce the structures,
but that doesn't matter right now.

> Also I think leaving the structures also helps us debug any boot up issues
> looking at the ram contents of the per-(cpu/cluster) structures with the
> contents from the firmware.

I don't see how debugging would be hard without those structures in place.

> Hope these above helps us to go ahead with the current SW design.

Sorry, but I don't see any satisfactory reason on why you shouldn't make the
suggested changes. We are trying to make your (and any other developer who will
work on that driver) life simple by simplifying the code. Nothing beyond that :)

-- 
viresh

  reply	other threads:[~2018-12-12  4:47 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-02  3:55 [PATCH v11 0/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW Taniya Das
2018-12-02  3:55 ` [PATCH v11 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ Firmware bindings Taniya Das
2018-12-03 16:55   ` Stephen Boyd
2018-12-03 16:55     ` Stephen Boyd
2018-12-03 23:09   ` Rob Herring
2018-12-03 23:57     ` Stephen Boyd
2018-12-02  3:55 ` [PATCH v11 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver Taniya Das
2018-12-03 16:57   ` Stephen Boyd
2018-12-03 16:57     ` Stephen Boyd
2018-12-03 17:46   ` Matthias Kaehlcke
2018-12-04  5:12   ` Viresh Kumar
2018-12-04  9:27     ` Taniya Das
2018-12-04  9:29       ` Viresh Kumar
2018-12-04 22:28     ` Stephen Boyd
2018-12-04 23:05       ` Stephen Boyd
2018-12-05  3:37         ` Taniya Das
2018-12-05  6:16           ` Viresh Kumar
2018-12-05 17:00             ` Stephen Boyd
2018-12-06  4:22               ` Viresh Kumar
2018-12-11 13:35             ` Taniya Das
2018-12-12  4:47               ` Viresh Kumar [this message]
2018-12-13  7:48                 ` Taniya Das
2018-12-05  8:07           ` Stephen Boyd

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=20181212044702.jp2r3mviq4ffal42@vireshk-i7 \
    --to=viresh.kumar@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=evgreen@google.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=rnayak@codeaurora.org \
    --cc=robh@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=skannan@codeaurora.org \
    --cc=tdas@codeaurora.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 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.