Yes, Following options have to be enabled in the defconfig to enable cpufreq.
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_OMAP_SMARTREFLEX=y
CONFIG_OMAP_SMARTREFLEX_CLASS3=y
Vishwa
On Mon, Apr 4, 2011 at 1:52 PM, Amit Kucheria wrote:
> On Sat, Apr 2, 2011 at 6:21 AM, Nicolas Pitre
On Mon, 2011-04-04 at 17:49 -0700, john stultz wrote:
> On Fri, 2011-04-01 at 21:03 +0530, Vishwanath Sripathy wrote:
> > Hi Nicolas,
> >
> > Pls find rebased OMAP DVFS patches attached. Apologies for the delay
> > as I had to rework some of the patches because of kernel migration.
>
> I think so
Hi Nicolas,
Please take this cpuidle commit from the samsung tree needed for Linaro new
rebuilt tree.
http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git;a=commit;h=df7bf189d23ecd1c211c273de462b93d9e3e1fef
Thanks,
Amit Daniel
On 18 March 2011 08:51, Amit Daniel Kachhap wrote:
On Fri, Apr 01, 2011 at 03:49:16PM +0800, Shawn Guo wrote:
> On Thu, Mar 31, 2011 at 10:09:40AM -0600, Grant Likely wrote:
> > On Fri, Mar 25, 2011 at 03:13:58PM +0800, Shawn Guo wrote:
> > > After fec dt support is added, the following compile error will be
> > > seen when building a pure non-dt k
On Fri, 2011-04-01 at 21:03 +0530, Vishwanath Sripathy wrote:
> Hi Nicolas,
>
> Pls find rebased OMAP DVFS patches attached. Apologies for the delay
> as I had to rework some of the patches because of kernel migration.
I think something in the DVFS patch set broke usb on Pandaboard.
Building 7c4
If you haven't previously set the user's client.conf to turn autospawn off
then try running-> pulseaudio --daemonize
That should do the trick, thanks!
On 3 April 2011 09:45, Matt Sealey wrote:
> I'm trying to get this data from the Smarttop to show the SPDIF device
> but I get the same "No Pul
On Mon, 4 Apr 2011, Andy Green wrote:
> Well, in the iMX31 case there is only a 2KByte SRAM on-die that gets
> auto-filled by the ROM. In the case of SD Card boot which I implemented - the
> bootloader is on the SD Card at a defined place - it means you need to fit
> your SD init, "mmc stack" and
On Mon, Apr 4, 2011 at 8:50 AM, Nicolas Pitre wrote:
> On Mon, 4 Apr 2011, Eric Miao wrote:
>
>> >> * And very hardware specific code moved out to a controllable place,
>> >> i.e. something like BIOS
>> >
>> > Sorry, but I must vehemently disagree here. BIOSes are a problem for
>> > Open So
On 04/04/2011 11:53 AM, Amit Kucheria wrote:
Daniel,
I've now reviewed, tested and merged this entire series. Some minor changes
were made to a handful of commit messages.
Thanks for taking the time to make the changes self-contained, easily
bisectable and making sure they don't break builds (I
On Mon, 4 Apr 2011, Eric Miao wrote:
> >> * And very hardware specific code moved out to a controllable place,
> >> i.e. something like BIOS
> >
> > Sorry, but I must vehemently disagree here. BIOSes are a problem for
> > Open Source, not a solution. On X86 they use BIOS services only when
>> * And very hardware specific code moved out to a controllable place,
>> i.e. something like BIOS
>
> Sorry, but I must vehemently disagree here. BIOSes are a problem for
> Open Source, not a solution. On X86 they use BIOS services only when
> there is simply no other choice, because the
On 04/04/2011 12:12 PM, Somebody in the thread at some point said:
Hi -
Specifically: the bootloader prerequisites for accessing the DT data may
entirely mandate private bootloader knowledge of ALL the information it
would have required from DT. For example, bootloader must init SDRAM,
knowing
On Mon, Apr 4, 2011 at 4:54 AM, Andy Green wrote:
> Another way to solve it, would be to encode the set of device trees
> supported in a way that removes redundancy. Then the additional data needed
> to resolve a generic OMAP3 device table into overo or beagle or any similar
> board would be a sm
On Mon, Apr 4, 2011 at 4:21 AM, Andy Green wrote:
>> Matt and I may differ a little on the responsibilities of the
>> bootloader. I think it should do the bare minimum needed to get the
>> kernel loaded and to feed it a device tree. Matt has it doing more
>> like setting up all of the pin configur
Daniel,
I've now reviewed, tested and merged this entire series. Some minor changes
were made to a handful of commit messages.
Thanks for taking the time to make the changes self-contained, easily
bisectable and making sure they don't break builds (I checked with git
test-sequence).
One quick no
On Mon, Apr 4, 2011 at 1:38 PM, Bryan Wu wrote:
> On Fri, Apr 1, 2011 at 11:43 PM, Eric Miao wrote:
>> Just FYI - lengthy but very interesting read, Linus was really good at
>> wording, enjoy heh :-)
>>
>> https://lkml.org/lkml/2011/3/17/283
>>
>> So maybe it's just a right time to talk about usi
On 04/04/2011 03:22 AM, Somebody in the thread at some point said:
Hi -
In a perfect world, the DT data would be tied to the hardware and
provided by the bootloader to the kernel. It would be produced by
hardware vendors who would only have to describe their hardware in this
OS independent abst
On Sat, Apr 2, 2011 at 6:21 AM, Nicolas Pitre wrote:
> On Fri, 1 Apr 2011, Vishwanath Sripathy wrote:
>
>> Hi Nicolas,
>>
>> Pls find rebased OMAP DVFS patches attached. Apologies for the delay
>> as I had to rework some of the patches because of kernel migration.
>
> No problem.
>
> Merged, thank
On 04/03/2011 09:09 PM, Somebody in the thread at some point said:
Hi -
Can you describe why code in the bootloader is a better place than code in
the kernel early init? I mean if you go and look in say U-Boot sources,
it's a lot less beautiful and elegant than kernel code.
You shouldn't jus
19 matches
Mail list logo
