Re: [PATCH] cpuidle: arm_big_little: pass target residency to mcpm
Hi Guys, Sorry, I think the conversation went pretty far from my patch. Concerning my original patch, do you have any more ideas or concerns? I'm not sure I have a clear idea what, if anything, needs to be changed. I was able to verify it on the TC2 platform without issue. Thanks again for all of your time. Sebastian On 22 May 2013 11:51, Sebastian Capella wrote: > Quoting Dave Martin (2013-05-22 11:22:36) > > Currently not. This partly depends on whether the target residency is > > supposed to be a hint about the rough order of magnitude of the expected > > idle period, or whether it's supposed to be a strict contract. > > > > In effect, I think it's a hint which steers the choice of powerdown > > state, rather than soemthing with a strong real-time guarantee attached > > to it. In that case shaving the firmware latency off this value before > > using it may not be worth it. If the specified target residency is > > small enough that this makes a significant difference, this suggests a > > very short period of actual powerdown, which may not outweigh its own > > overheads in terms of power-saving. > > > > Thanks Dave, Liviu, > > Sorry, you've caught me mixing terms and concepts. > > I agree, target residency to me also is more an estimate of the cost vs. > benefit for a state. > > The cstates also define a latency parameter that is used for limiting > selection of certain states by the governor. This is affected by QoS > constraints, which we use alot in embedded. This is the one needed for > realtime use that is tricky with host os' additional latency. > > Both latency and target residency would need some adjustment for > embedded mobile if we have additional overhead as it becomes very > important to squeeze this as much as possible. For latency, > microseconds count as we cannot allow a cstate which will fail to meet > our qos constraints. > > Thanks, > > Sebastian > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V8 0/3] USB: OHCI: Start splitting up the driver
On Tue, 28 May 2013, Arnd Bergmann wrote: > Seems to basically work now, but I'm getting run-time errors after > loading the driver, with patch 1/3 applied: > > [15916.438452] input: Logitech USB-PS/2 Optical Mouse as > /devices/pci:00/:00:12.0/usb3/3-1/3-1:1.0/input/input26 > [15916.438584] hid-generic 0003:046D:C050.0017: input,hidraw0: USB HID v1.10 > Mouse [Logitech USB-PS/2 Optical Mouse] on usb-:00:12.0-1/input0 > [15917.465597] usb 3-3: new full-speed USB device number 3 using ohci-pci > [15917.636712] usb 3-3: New USB device found, idVendor=0ccd, idProduct=0077 > [15917.636717] usb 3-3: New USB device strings: Mfr=1, Product=2, > SerialNumber=0 > [15917.636721] usb 3-3: Product: USB PnP Sound Device > [15917.636724] usb 3-3: Manufacturer: C-Media Electronics Inc. > [15917.812827] input: C-Media Electronics Inc. USB PnP Sound Device as > /devices/pci:00/:00:12.0/usb3/3-3/3-3:1.3/input/input27 > [15917.812919] hid-generic 0003:0CCD:0077.0018: input,hidraw1: USB HID v1.00 > Device [C-Media Electronics Inc. USB PnP Sound Device] on > usb-:00:12.0-3/input3 > [15918.789906] cannot submit urb (err = -18) > [15918.790163] cannot submit urb (err = -18) > [15918.842095] usb 7-1: new full-speed USB device number 2 using ohci-pci > [15919.883135] cannot submit urb (err = -18) > [15919.883604] cannot submit urb (err = -18) > [15919.883613] cannot submit urb (err = -18) > [15919.883616] cannot submit urb (err = -18) > [15919.883619] cannot submit urb (err = -18) Those error messages are annoying; they don't use dev_err(), so they don't include the device and driver names. There's no way to know what they refer to. I rather suspect they come from the usbaudio driver. When you ran this test, did you have commit 815fa7b91761 applied? Does the same problem occur without Manjunath's changes? Alan Stern ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V8 0/3] USB: OHCI: Start splitting up the driver
On Wednesday 29 May 2013 12:21:02 Alan Stern wrote: > > Those error messages are annoying; they don't use dev_err(), so they > don't include the device and driver names. There's no way to know what > they refer to. I rather suspect they come from the usbaudio driver. That makes sense. I have a usb audio device, and I don't actually recall getting any sound from my speakers while testing it. I only checked that the mouse was working and assumed that the usb-audio was driven by ehci, but upon closer inspection, they are both on the same OHCI. > When you ran this test, did you have commit 815fa7b91761 applied? Yes. > Does the same problem occur without Manjunath's changes? No, it was introduced by the first patch, as I found later. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V8 0/3] USB: OHCI: Start splitting up the driver
On Wed, 29 May 2013, Arnd Bergmann wrote: > On Wednesday 29 May 2013 12:21:02 Alan Stern wrote: > > > > Those error messages are annoying; they don't use dev_err(), so they > > don't include the device and driver names. There's no way to know what > > they refer to. I rather suspect they come from the usbaudio driver. > > That makes sense. I have a usb audio device, and I don't actually recall > getting any sound from my speakers while testing it. I only checked > that the mouse was working and assumed that the usb-audio was driven > by ehci, but upon closer inspection, they are both on the same OHCI. > > > When you ran this test, did you have commit 815fa7b91761 applied? > > Yes. > > > Does the same problem occur without Manjunath's changes? > > No, it was introduced by the first patch, as I found later. I'll try to replicate your result. I don't have my USB audio device here today, so it will have to wait until tomorrow. Alan Stern ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V8 0/3] USB: OHCI: Start splitting up the driver
On Wednesday 29 May 2013, Alan Stern wrote: > > On Wed, 29 May 2013, Arnd Bergmann wrote: > > > On Wednesday 29 May 2013 12:21:02 Alan Stern wrote: > > > > > > Those error messages are annoying; they don't use dev_err(), so they > > > don't include the device and driver names. There's no way to know what > > > they refer to. I rather suspect they come from the usbaudio driver. > > > > That makes sense. I have a usb audio device, and I don't actually recall > > getting any sound from my speakers while testing it. I only checked > > that the mouse was working and assumed that the usb-audio was driven > > by ehci, but upon closer inspection, they are both on the same OHCI. > > > > > When you ran this test, did you have commit 815fa7b91761 applied? > > > > Yes. > > > > > Does the same problem occur without Manjunath's changes? > > > > No, it was introduced by the first patch, as I found later. > > I'll try to replicate your result. I don't have my USB audio device > here today, so it will have to wait until tomorrow. Strange enough, it seems to be working now, on a different base. The kernel I tried last (based on yesterday's linux-next) also had other issues and was very slow, so it may have been something different. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Tiny BL switcher compatibility issue with PMU on non-BL SoC
Hi -
We're using one kernel binary with BL Switcher enabled in config, but
able to work on SoC without Big Little.
This is OK except where the BL patches touch the PMU driver. It makes
an assumption about BL configured == in use which is not true. PMU init
fails and when you try to use perf list later, it blows chunks.
I worked around it with the hack below, so it can fail out from the
bigLITTLE path when it doesn't see the cluster property in DT, but
there's presumably a better way to do that which more directly checks if
we care about BL in this execution environment.
-Andy
Author: Andy Green
Date: Thu May 30 09:44:17 2013 +0800
bl switcher fix dont assume bl active in pmu probe
Signed-off-by: Andy Green
diff --git a/arch/arm/kernel/perf_event_cpu.c
b/arch/arm/kernel/perf_event_cpu.c
index b3ae24f..c02ea21 100644
--- a/arch/arm/kernel/perf_event_cpu.c
+++ b/arch/arm/kernel/perf_event_cpu.c
@@ -440,6 +440,9 @@ static int cpu_pmu_device_probe(struct
platform_device *pdev)
hwid = of_get_property(ncluster, "reg", &len);
if (hwid && len == 4)
cluster = be32_to_cpup(hwid);
+ } else {
+ ret = probe_current_pmu(pmu);
+ goto bail;
}
/* set sibling mask to all cpu mask if socket is not
specified */
/*
@@ -501,7 +504,7 @@ static int cpu_pmu_device_probe(struct
platform_device *pdev)
} else {
ret = probe_current_pmu(pmu);
}
-
+bail:
if (ret)
goto error;
--
Andy Green | Fujitsu Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V8 0/3] USB: OHCI: Start splitting up the driver
On 30 May 2013 03:32, Arnd Bergmann wrote: > On Wednesday 29 May 2013, Alan Stern wrote: > > > > On Wed, 29 May 2013, Arnd Bergmann wrote: > > > > > On Wednesday 29 May 2013 12:21:02 Alan Stern wrote: > > > > > > > > Those error messages are annoying; they don't use dev_err(), so they > > > > don't include the device and driver names. There's no way to know > what > > > > they refer to. I rather suspect they come from the usbaudio driver. > > > > > > That makes sense. I have a usb audio device, and I don't actually > recall > > > getting any sound from my speakers while testing it. I only checked > > > that the mouse was working and assumed that the usb-audio was driven > > > by ehci, but upon closer inspection, they are both on the same OHCI. > > > > > > > When you ran this test, did you have commit 815fa7b91761 applied? > > > > > > Yes. > > > > > > > Does the same problem occur without Manjunath's changes? > > > > > > No, it was introduced by the first patch, as I found later. > > > > I'll try to replicate your result. I don't have my USB audio device > > here today, so it will have to wait until tomorrow. > > Strange enough, it seems to be working now, on a different base. > > The kernel I tried last (based on yesterday's linux-next) also > had other issues and was very slow, so it may have been something > different. > > Arnd > > > As I understand by Alan reply,1/3 patch is working properly,if any concerned regarding this patch let me know. Manjunath Goudar ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Tiny BL switcher compatibility issue with PMU on non-BL SoC
On Thu, May 30, 2013 at 7:36 AM, Andy Green wrote:
> Hi -
>
> We're using one kernel binary with BL Switcher enabled in config, but able
> to work on SoC without Big Little.
>
> This is OK except where the BL patches touch the PMU driver. It makes an
> assumption about BL configured == in use which is not true. PMU init fails
> and when you try to use perf list later, it blows chunks.
>
> I worked around it with the hack below, so it can fail out from the
> bigLITTLE path when it doesn't see the cluster property in DT, but there's
> presumably a better way to do that which more directly checks if we care
> about BL in this execution environment.
>
> -Andy
>
This is Dave's area but Nico ought to weigh in whether the presence of
the DT property is the best place for this. It seems OK to me.
>
> Author: Andy Green
> Date: Thu May 30 09:44:17 2013 +0800
>
> bl switcher fix dont assume bl active in pmu probe
>
> Signed-off-by: Andy Green
>
> diff --git a/arch/arm/kernel/perf_event_cpu.c
> b/arch/arm/kernel/perf_event_cpu.c
> index b3ae24f..c02ea21 100644
> --- a/arch/arm/kernel/perf_event_cpu.c
> +++ b/arch/arm/kernel/perf_event_cpu.c
> @@ -440,6 +440,9 @@ static int cpu_pmu_device_probe(struct platform_device
> *pdev)
> hwid = of_get_property(ncluster, "reg", &len);
> if (hwid && len == 4)
> cluster = be32_to_cpup(hwid);
> + } else {
> + ret = probe_current_pmu(pmu);
> + goto bail;
> }
> /* set sibling mask to all cpu mask if socket is not
> specified */
> /*
> @@ -501,7 +504,7 @@ static int cpu_pmu_device_probe(struct platform_device
> *pdev)
> } else {
> ret = probe_current_pmu(pmu);
> }
> -
> +bail:
> if (ret)
> goto error;
>
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
