On 10/16/2014 05:21 PM, Enric Balletbo Serra wrote:
Hi,
2014-10-10 16:06 GMT+02:00 Tero Kristo :
Hi,
Seems like MPU DVFS does not scale the voltages currently with DT boot,
due to missing mapping between regulator -> VCVP. Fixed this by adding
support for platform data in the TWL regulator DT
On Thu, 16 Oct 2014, Russell King - ARM Linux wrote:
> So, let me put this another way: a compiler with this bug is _completely_
> unsuitable for use for compiling programs for use under the Linux
> kernel _as well_ as the Linux kernel itself.
>
> The difference is that the Linaro compilers come
On Thu, Oct 16, 2014 at 10:30:30AM +, David Laight wrote:
> > +#ifdef __GNUC__
> > #if (__GNUC__ == 3 && __GNUC_MINOR__ < 3)
> > #error Your compiler is too buggy; it is known to miscompile kernels.
> > -#errorKnown good compilers: 3.3
> > +#errorKnown good compilers: 3.3, 4.x
>
> Ex
Hi,
2014-10-10 16:06 GMT+02:00 Tero Kristo :
> Hi,
>
> Seems like MPU DVFS does not scale the voltages currently with DT boot,
> due to missing mapping between regulator -> VCVP. Fixed this by adding
> support for platform data in the TWL regulator DT case + adding platform
> data quirk for the sa
On 16/10/14 16:19, Felipe Balbi wrote:
> On Thu, Oct 16, 2014 at 12:39:44PM +0300, Tomi Valkeinen wrote:
>> omapfb device can be unbound, so using __exit_p() for the driver's
>> remove callback is wrong.
>>
>> Remove __exit_p() and __exit from the driver's remove.
>>
>> Signed-off-by: Tomi Valkeine
On Thu, Oct 16, 2014 at 12:39:44PM +0300, Tomi Valkeinen wrote:
> omapfb device can be unbound, so using __exit_p() for the driver's
> remove callback is wrong.
>
> Remove __exit_p() and __exit from the driver's remove.
>
> Signed-off-by: Tomi Valkeinen
and why was my version dropped ?
http://
From: Russell King
> These stock GCC versions miscompile the kernel by incorrectly optimising
> the function epilogue code - by first increasing the stack pointer, and
> then loading entries from below the stack. This means that an opportune
> interrupt or exception will corrupt the current functi
omapfb device can be unbound, so using __exit_p() for the driver's
remove callback is wrong.
Remove __exit_p() and __exit from the driver's remove.
Signed-off-by: Tomi Valkeinen
---
drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --
omapdss drivers cannot handle devices being unbound while the devices
are part of a connected display pipeline. Module refcounts are used to
prevent unloading the modules, but one can still manually unbind the
devices via sysfs, causing crash.
Set suppress_bind_attrs to disable the bind/unbind sup
We should wait for any pending updates when an overlay manager is
about to be disabled, because the updates will never be finished if the
manager is disabled too early.
Signed-off-by: Tomi Valkeinen
---
drivers/video/fbdev/omap2/dss/apply.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/d
omapfb disables all the overlays when freeing resources, but it should
also remove those overlays from overlay managers.
Not doing so causes a crash if omapfb is unbound and bound, or omapfb
module is removed and loaded, while keeping omapdss around.
Fix this by calling unset_manager() for all ov
When omapfb is shutting down, it will disable all the overlays. However,
instead of actually disabling all the overlays, it disables only all the
overlays that are currently attached to framebuffers.
On OMAP4+, this leaves the fourth overlay left enabled.
Fix the loop so that we actually go throu
Hello,
I try to understand the cpuidle main concept but have some
difficulties. I could not find any documentation to explain the
cpuidle.
what does it mean that it enters idle when "no thread to run" ?if I
have only one process which does only
while(1)
{
printf("C");
mdelay(1000);
}
Can I expec
13 matches
Mail list logo
