On Wed, Oct 8, 2014 at 9:45 PM, Josh Cartwright wrote:
> This has bitten me more times than I care to admit, but have you checked
> that you've set CONFIG_MMC_BLOCK_MINORS higher than 16? Perhaps we
> should be doing that in qcom_defconfig if we aren't already.
ouch... i was using multi_v7_defco
On 9 October 2014 05:31, Mike Turquette wrote:
> Whether you merge the patches now or later is fine by me. I prefer to
> get my patches out early and often so I can avoid any surprises later
> on. If you have a fundamental objection to these patches then please let
> me know. Otherwise it would be
On 10/07/2014 02:41 PM, Lina Iyer wrote:
+
+static int qcom_cpuidle_probe(struct platform_device *pdev)
+{
+ struct cpuidle_driver *drv = &qcom_cpuidle_driver;
+ int ret;
+
+ qcom_idle_enter = pdev->dev.platform_data;
+ if (!qcom_idle_enter)
+ return -EFAULT;
On 10/07/2014 02:41 PM, Lina Iyer wrote:
+
+static struct platform_device qcom_cpuidle_device = {
+ .name = "qcom_cpuidle",
+ .id= -1,
+ .dev.platform_data = qcom_cpu_pm_enter_sleep,
+};
+
Same comment as last time, doesn't need to be static.
+s
On 10/07/2014 02:41 PM, Lina Iyer wrote:
diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
index 1505fb8..a18e8fc 100644
--- a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
+++ b/Documentation/devicetree/bindi
Quoting Viresh Kumar (2014-10-08 01:19:40)
> On 8 October 2014 13:41, Thomas Petazzoni
> wrote:
> > On Wed, 8 Oct 2014 13:24:30 +0530, Viresh Kumar wrote:
> >> On 8 October 2014 13:18, Mike Turquette wrote:
>
> >> > This series is partially in response to a discussion around DT bindings
> >> > f
On 9/30/2014 6:08 PM, Bjorn Andersson wrote:
On Tue 30 Sep 16:16 PDT 2014, Jeffrey Hugo wrote:
On 9/30/2014 8:37 AM, Bjorn Andersson wrote:
On Tue 30 Sep 06:46 PDT 2014, Kumar Gala wrote:
On Sep 29, 2014, at 7:34 PM, Bjorn Andersson
wrote:
diff --git a/Documentation/devicetree/bindings/
Here in my initial detailed pass. I still have some "issues" that I
want to clarify on my end, but I think I have plenty of comments to
start with.
On 9/29/2014 6:34 PM, Bjorn Andersson wrote:
The Shared Memory Manager driver implements an interface for allocating
and accessing items in the m
On Wed, Oct 08, 2014 at 09:04:26PM +0100, Mark Brown wrote:
> On Wed, Oct 08, 2014 at 11:20:58AM -0700, Stephen Boyd wrote:
> > On 10/08/2014 11:13 AM, Dmitry Torokhov wrote:
>
> > >>>Oops. struct regmap_field is opaque. It seems that the allocation
> > >>>is the only way that I could have instanc
On Wed, Oct 08, 2014 at 11:20:58AM -0700, Stephen Boyd wrote:
> On 10/08/2014 11:13 AM, Dmitry Torokhov wrote:
> >>>Oops. struct regmap_field is opaque. It seems that the allocation
> >>>is the only way that I could have instance of it.
> >>Maybe we can add an API to allocate an array of fields?
On Wed, Oct 08, 2014 at 09:18:44PM +0200, Nicolas Dechesne wrote:
> Georgi,
>
> On Tue, Sep 2, 2014 at 5:40 PM, Georgi Djakov wrote:
> > Enable support for the two SD host controllers on the APQ8084 platform
> > by adding the required nodes to the DT files.
> > On the IFC6540 board, the first con
Georgi,
On Tue, Sep 2, 2014 at 5:40 PM, Georgi Djakov wrote:
> Enable support for the two SD host controllers on the APQ8084 platform
> by adding the required nodes to the DT files.
> On the IFC6540 board, the first controller is connected to the onboard
> eMMC and the second is connected to a mi
Adding Mark and Srini
On 10/08/2014 11:13 AM, Dmitry Torokhov wrote:
On Wed, Oct 08, 2014 at 11:00:07AM -0700, Stephen Boyd wrote:
On 10/08/2014 02:30 AM, Ivan T. Ivanov wrote:
On Wed, 2014-10-08 at 12:13 +0300, Ivan T. Ivanov wrote:
On Tue, 2014-10-07 at 10:26 -0700, Dmitry Torokhov wrote:
On Wed, Oct 08, 2014 at 11:00:07AM -0700, Stephen Boyd wrote:
> On 10/08/2014 02:30 AM, Ivan T. Ivanov wrote:
> >On Wed, 2014-10-08 at 12:13 +0300, Ivan T. Ivanov wrote:
> >>On Tue, 2014-10-07 at 10:26 -0700, Dmitry Torokhov wrote:
> >>>Hi Ivan,
> >>>
> >>>On Tue, Oct 07, 2014 at 12:50:46PM +0300,
On 10/08/2014 02:30 AM, Ivan T. Ivanov wrote:
On Wed, 2014-10-08 at 12:13 +0300, Ivan T. Ivanov wrote:
On Tue, 2014-10-07 at 10:26 -0700, Dmitry Torokhov wrote:
Hi Ivan,
On Tue, Oct 07, 2014 at 12:50:46PM +0300, Ivan T. Ivanov wrote:
@@ -527,10 +538,55 @@ static int pmic8xxx_kp_probe(struct p
On Tue, Oct 07, 2014 at 04:07:43PM -0700, Stephen Boyd wrote:
> On 10/07/2014 03:10 PM, Josh Cartwright wrote:
> >On Thu, Oct 02, 2014 at 12:08:38PM -0700, Stephen Boyd wrote:
[..]
> >>I'm thinking:
> >>
> >> timer@200a000 {
> >> compatible = "qcom,kpss-timer
On 07/10/14 19:26, Stephen Boyd wrote:
On 10/07/2014 10:27 AM, Srinivas Kandagatla wrote:
Hi Stephen,
Just noticed this regression while testing the patch on Arndale board.
https://bugs.linaro.org/show_bug.cgi?id=740
If you return value it works correctly right?
I think you are right, ..
Hi all,
On Wed, Oct 01, 2014 at 06:54:18PM +0100, Stephen Boyd wrote:
> On 09/19/14 11:24, Stephen Boyd wrote:
> > On 09/18/14 15:46, Russell King - ARM Linux wrote:
> >> I know that you're changing this to conform with the ARM ARM, but we
> >> have to consider that before VFP was subsumed into th
On Fri, Sep 19, 2014 at 9:09 AM, Wang, Yalin wrote:
> this patch extend the start and end address of initrd to be page aligned,
> so that we can free all memory including the un-page aligned head or tail
> page of initrd, if the start or end address of initrd are not page
> aligned, the page can't
On Tue, 2014-10-07 at 11:46 -0700, Bjorn Andersson wrote:
> On Tue 07 Oct 02:01 PDT 2014, Ivan T. Ivanov wrote:
>
> >
> > Hi Bjorn,
> >
> > On Mon, 2014-10-06 at 18:11 -0700, Bjorn Andersson wrote:
> > > These patches add dt bindings and a device driver for the power key block
> > > in
> > > th
On Wed, 2014-10-08 at 12:13 +0300, Ivan T. Ivanov wrote:
> On Tue, 2014-10-07 at 10:26 -0700, Dmitry Torokhov wrote:
> > Hi Ivan,
> >
> > On Tue, Oct 07, 2014 at 12:50:46PM +0300, Ivan T. Ivanov wrote:
> > > @@ -527,10 +538,55 @@ static int pmic8xxx_kp_probe(struct platform_device
> > > *pdev)
>
On Tue, 2014-10-07 at 10:26 -0700, Dmitry Torokhov wrote:
> Hi Ivan,
>
> On Tue, Oct 07, 2014 at 12:50:46PM +0300, Ivan T. Ivanov wrote:
> > @@ -527,10 +538,55 @@ static int pmic8xxx_kp_probe(struct platform_device
> > *pdev)
> >
> > +
> > + kp->row_hold = devm_regmap_field_alloc(kp->dev, kp
On Mon, 29 Sep 2014, Bjorn Andersson wrote:
> Driver for the Resource Power Manager (RPM) found in Qualcomm 8974 based
> devices.
> The driver exposes resources that child drivers can operate on; to
> implementing regulator, clock and bus frequency drivers.
>
> Signed-off-by: Bjorn Andersson
> -
On 8 October 2014 13:41, Thomas Petazzoni
wrote:
> On Wed, 8 Oct 2014 13:24:30 +0530, Viresh Kumar wrote:
>> On 8 October 2014 13:18, Mike Turquette wrote:
>> > This series is partially in response to a discussion around DT bindings
>> > for CPUfreq drivers [0], but it is also needed for on-goin
Dear Viresh Kumar,
On Wed, 8 Oct 2014 13:24:30 +0530, Viresh Kumar wrote:
> On 8 October 2014 13:18, Mike Turquette wrote:
> > This series is partially in response to a discussion around DT bindings
> > for CPUfreq drivers [0], but it is also needed for on-going work to
> > integrate CPUfreq with
On 8 October 2014 13:18, Mike Turquette wrote:
> This series is partially in response to a discussion around DT bindings
> for CPUfreq drivers [0], but it is also needed for on-going work to
> integrate CPUfreq with the scheduler. In particular a scheduler-driven
> cpu frequency scaling policy wou
The CPUfreq core does not differentiate between .target & .target_index
callbacks that may sleep or block and callbacks that are fast and return
immediately. To date this has not mattered much since the typical
CPUfreq governor calls the .target callback from process context via a
workqueue.
When
There are cases for CPUfreq driver flags to be exposed outside of the
CPUfreq core code. In particular the CPUFREQ_NO_SLEEP flag can be used
by CPUfreq governors to optimize when and how they call that drivers
.target callback. In fact this knowledge is a requirement for the
on-going work to initia
This series is partially in response to a discussion around DT bindings
for CPUfreq drivers [0], but it is also needed for on-going work to
integrate CPUfreq with the scheduler. In particular a scheduler-driven
cpu frequency scaling policy would be well served to know if the
underlying CPUfreq driv
29 matches
Mail list logo
