Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 12 1月, 2010 2 次提交
  3. 09 1月, 2010 1 次提交
  5. 08 1月, 2010 3 次提交
  7. 07 1月, 2010 11 次提交
    • B
      ARM: S3C64XX: Fix possible clock look in EPLL and MPLL clock chains · 87d26d2d
      由 Ben Dooks 提交于 
      There is a possibility of a loop happening in the PLL output clock
chain on the S3C64XX series. clk_mpll's parent was set to be
clk_mout_mpll, but this is fed from clk_fout_epll (which is also
clk_mpll).

clk_mpll is meant to be the output from the MPLL, and clk_mout_mpll
is a seperate clock derived from the mux of clk_mpll and clk_fin_mpll
and thus should be considered a seperate clock.

Anything using clk_mpll directly really should not be relying on this
being the clock that is eventually routed to a peripheral, so remove the
loop and ensure that the clocks accurately represent the clock chain
in the device.

The clk_mpll is not being used outside of the s3c6400-clock.c code, so
this change should not break anything else.

Do the same for the EPLL.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      87d26d2d
    • M
      FDPIC: Respect PT_GNU_STACK exec protection markings when creating NOMMU stack · 04e4f2b1
      由 Mike Frysinger 提交于 
      The current code will load the stack size and protection markings, but
then only use the markings in the MMU code path.  The NOMMU code path
always passes PROT_EXEC to the mmap() call.  While this doesn't matter
to most people whilst the code is running, it will cause a pointless
icache flush when starting every FDPIC application.  Typically this
icache flush will be of a region on the order of 128KB in size, or may
be the entire icache, depending on the facilities available on the CPU.

In the case where the arch default behaviour seems to be desired
(EXSTACK_DEFAULT), we probe VM_STACK_FLAGS for VM_EXEC to determine
whether we should be setting PROT_EXEC or not.

For arches that support an MPU (Memory Protection Unit - an MMU without
the virtual mapping capability), setting PROT_EXEC or not will make an
important difference.

It should be noted that this change also affects the executability of
the brk region, since ELF-FDPIC has that share with the stack.  However,
this is probably irrelevant as NOMMU programs aren't likely to use the
brk region, preferring instead allocation via mmap().
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      04e4f2b1
    • T
      [IA64] sanity in #include files. Move fnptr to types.h · 410dc0aa
      由 Tony Luck 提交于 
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      410dc0aa
    • J
      [IA64] use helpers for rlimits · 02b763b8
      由 Jiri Slaby 提交于 
      Make sure compiler won't do weird things with limits. E.g. fetching
them twice may return 2 different values after writable limits are
implemented.

I.e. either use rlimit helpers added in
3e10e716
or ACCESS_ONCE if not applicable.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      02b763b8
    • A
      [IA64] cpumask_of_node() should handle -1 as a node · 1d1e9f04
      由 Anton Blanchard 提交于 
      pcibus_to_node can return -1 if we cannot determine which node a pci bus
is on. If passed -1, cpumask_of_node will negatively index the lookup array
and pull in random data:

# cat /sys/devices/pci0000:00/0000:00:01.0/local_cpus
00000000,00000003,00000000,00000000
# cat /sys/devices/pci0000:00/0000:00:01.0/local_cpulist
64-65

Change cpumask_of_node to check for -1 and return cpu_all_mask in this
case:

# cat /sys/devices/pci0000:00/0000:00:01.0/local_cpus
ffffffff,ffffffff,ffffffff,ffffffff
# cat /sys/devices/pci0000:00/0000:00:01.0/local_cpulist
0-127
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      1d1e9f04
    • S
      x86, irq: Check move_in_progress before freeing the vector mapping · 7f41c2e1
      由 Suresh Siddha 提交于 
      With the recent irq migration fixes (post 2.6.32), Gary Hade has noticed
"No IRQ handler for vector" messages during the 2.6.33-rc1 kernel boot on IBM
AMD platforms and root caused the issue to this commit:

> commit 23359a88
> Author: Suresh Siddha <suresh.b.siddha@intel.com>
> Date:   Mon Oct 26 14:24:33 2009 -0800
>
>    x86: Remove move_cleanup_count from irq_cfg

As part of this patch, we have removed the move_cleanup_count check
in smp_irq_move_cleanup_interrupt(). With this change, we can run into a
situation where an irq cleanup interrupt on a cpu can cleanup the vector
mappings associated with multiple irqs, of which one of the irq's migration
might be still in progress. As such when that irq hits the old cpu, we get
the "No IRQ handler" messages.

Fix this by checking for the irq_cfg's move_in_progress and if the move
is still in progress delay the vector cleanup to another irq cleanup
interrupt request (which will happen when the irq starts arriving at the
new cpu destination).
Reported-and-tested-by: NGary Hade <garyhade@us.ibm.com>
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
LKML-Reference: <1262804191.2732.7.camel@sbs-t61.sc.intel.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      7f41c2e1
    • M
      DaVinci: DM365: Add the device_enable for the DaVinci Keyscan · c92b29ec
      由 Miguel Aguilar 提交于 
      Adds the device_enable function to the DaVinci Keyscan platform data
to setup the PINMUX configuration.

It also removes #ifdef from the DM365 EVM board in order to load it
properly as a module.
Signed-off-by: NMiguel Aguilar <miguel.aguilar@ridgerun.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      c92b29ec
    • S
      davinci: enable ARCH_HAS_HOLES_MEMORYMODEL for DaVinci · ae88e05a
      由 Sekhar Nori 提交于 
      All DaVinci platforms include a DSP or co-processor for
audio/video acceleration.

While creating memory for the DSP/co-processor, system
integrator can end up creating a hole in the memory map
of the sort:

<kernel memory> <hole (memory for DSP)> <kernel memory>

This sort of configuration needs ARCH_HAS_HOLES_MEMORYMODEL
enabled. See further details see this discussion on ARM
linux mailing list:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg15262.html

The patch is boot tested on OMAP-L138, DM6446 and DM355 EVMs
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
CC: Sriramakrishnan <srk@ti.com>
CC: Khasim Syed Mohammed <khasim@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      ae88e05a
    • S
      davinci: da8xx/omap-l1: mark RTC as a wakeup source · 75c99bb0
      由 Sekhar Nori 提交于 
      On da850, RTC alarm is a wakeup source from deep sleep.
Mark it as a wakeup source after the rtc platform device
is registered.

Without this patch, the rtc-omap driver suspends the RTC
during the suspend sequence and hence it cannot wakeup the
SoC.
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      75c99bb0
    • S
      davinci: cp_intc: provide set_wake function · 2d3f5950
      由 Sekhar Nori 提交于 
      There is nothing special to be done for interrupts
which can wakeup the device from sleep on CP-INTC,
but not having a set_wake implemented prevents use
of common drivers which expect this function to be
implemented for all wakeup interrupt sources.

This patch fixes the issue encountered when using the
omap-rtc driver on DA850. On DA850 the RTC alarm
interrupt is used to wake up the SoC from deep sleep
mode. Without this patch, the disable_irq_wake throws
an unbalanced wake disable warning while resuming
because the previous enable call fails for lack of
set_wake implementation.
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      2d3f5950
    • V
      Davinci VPFE Capture: Take i2c adapter id through platform data · 077639f4
      由 Vaibhav Hiremath 提交于 
      The I2C adapter ID is actually depends on Board and may vary, Davinci
uses id=1, but in case of AM3517 id=3.

So modified respective davinci board files.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      077639f4
  9. 06 1月, 2010 5 次提交
  11. 05 1月, 2010 5 次提交
  13. 04 1月, 2010 13 次提交