Skip to content

L
linux-davinci-2.6.23
Switch branch/tag
  1. 19 Oct, 2005 5 commits
    • Tony Lindgren's avatar
      ARM: OMAP: Move second I2C init on 24xx to mach-omap2/devices.c · 99429063
      Tony Lindgren authored 
      Move second I2C init on 24xx to mach-omap2/devices.c
      99429063
    • Imre Deak's avatar
      [PATCH] ARM: OMAP: FB support for OMAP2 · c8d61d1b
      Imre Deak authored 
      included in this FB patch:
- OMAP2 support with overlay, colorkey handling
- the palmte patch posted by Romain Goyet. The palette loading is
  changed a bit, so that it works ok with other platforms as well.
- registering the FB device through plat-omap/devices.c instead of doing
  it from the driver itself. Boards have to specify the OMAP_TAG_LCD
  config in the related board-*.c with in order to have FB support.
- pixel clock divider calculation based on the panel->pixel_clock
  instead of the wired panel->pcd
- support for external controllers both on SOSSI (OMAP1) and
  RFBI (OMAP2), kudos to Juha for this
- removal of the OMAP1 2D gfx stuff, it didn't really improve the
  performance:(
- double buffering IOCTL API, as this can be done in a more standard
  way through FBIOPUT_VSCREENINFO
- update of the affected omap_*_defconfigs
- minor formatting changes and typo fixes

Still TODO:
- OMAP2 Rotation, scaling of video planes
- OMAP2 digit-out (aka tv-out)
- moving the frame buffer to an alternative locating (onchip SRAM)

I tested it with H2 and H4 but it might break on other OMAP1 boards as
there were changes also in the old parts.
      c8d61d1b
    • Deepak Saxena's avatar
      [PATCH] ARM: OMAP: Add RNG platform device · c6358b2c
      Deepak Saxena authored 
      The following patch adds a platform device for the OMAP RNG. I have
added support for using this to the RNG driver as part of a generic
RNG codebase I'm writing and will submit that for testing once
it is compiling.
Signed-off-by: default avatarDeepak Saxena <dsaxena@plexity.net>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      c6358b2c
    • Tony Lindgren's avatar
      ARM: OMAP: Add comment on why omap_gpio_init() is needed on some boards · 7813a4a7
      Tony Lindgren authored 
      Add comment on why omap_gpio_init() is needed on some boards
      7813a4a7
    • Tony Lindgren's avatar
      ARM: OMAP: Undo of adding early GPIO init to board specific files · e6f351b7
      Tony Lindgren authored 
      The early GPIO should only be needed in cases where some interrupts
are routed via FPGA. In most cases doing the init with arch_initcall()
should be fine.
      e6f351b7
  3. 18 Oct, 2005 6 commits
  5. 17 Oct, 2005 1 commit
  7. 14 Oct, 2005 1 commit
    • David Brownell's avatar
      [PATCH] ARM: OMAP: USB peripheral DMA update' · 3e709eac
      David Brownell authored 
      The change to make DMA work two bytes at a time omitted an important
tweak that affects the file_storage gadget:  it needs to recognize when
the host writes an odd number of bytes.  (The change was made to get
past a controller lockup that seemed to be caused by byte-at-a-time DMA
using too much bandwidth on one of the I/O busses during network stress
testing.  The network layer ignores such extra bytes.)

This patch resolves that issue by checking the relevant bit and adjusting
the rx byte count, so that for example a legal 13 byte request doesn't
morph into an illegal 14 byte one any more.
Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      3e709eac
  9. 12 Oct, 2005 5 commits
  11. 11 Oct, 2005 15 commits
  13. 10 Oct, 2005 7 commits
    • Andi Kleen's avatar
      [PATCH] i386: Don't discard upper 32bits of HWCR on K8 · 3c92c2ba
      Andi Kleen authored 
      Need to use long long, not long when RMWing a MSR. I think
it's harmless right now, but still should be better fixed
if AMD adds any bits in the upper 32bit of HWCR.

Bug was introduced with the TLB flush filter fix for i386
Signed-off-by: default avatarAndi Kleen <ak@suse.de>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      3c92c2ba
    • Andi Kleen's avatar
      [PATCH] x86_64: Allocate cpu local data for all possible CPUs · 421c7ce6
      Andi Kleen authored 
      CPU hotplug fills up the possible map to NR_CPUs, but it did that after
setting up per CPU data. This lead to CPU data not getting allocated
for all possible CPUs, which lead to various side effects.
Signed-off-by: default avatarAndi Kleen <ak@suse.de>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      421c7ce6
    • Linus Torvalds's avatar
      Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6 · af74c3a6
      Linus Torvalds authored
      af74c3a6
    • Linus Torvalds's avatar
      Use the new "kill_proc_info_as_uid()" for USB disconnect too · d7dd8a72
      Linus Torvalds authored 
      All the same issues - we can't just save the pointer to the thread, we
must save the pid/uid/euid combination.
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      d7dd8a72
    • Harald Welte's avatar
      [PATCH] Fix signal sending in usbdevio on async URB completion · 46113830
      Harald Welte authored 
      If a process issues an URB from userspace and (starts to) terminate
before the URB comes back, we run into the issue described above.  This
is because the urb saves a pointer to "current" when it is posted to the
device, but there's no guarantee that this pointer is still valid
afterwards.

In fact, there are three separate issues:

1) the pointer to "current" can become invalid, since the task could be
   completely gone when the URB completion comes back from the device.

2) Even if the saved task pointer is still pointing to a valid task_struct,
   task_struct->sighand could have gone meanwhile.

3) Even if the process is perfectly fine, permissions may have changed,
   and we can no longer send it a signal.

So what we do instead, is to save the PID and uid's of the process, and
introduce a new kill_proc_info_as_uid() function.
Signed-off-by: default avatarHarald Welte <laforge@gnumonks.org>
[ Fixed up types and added symbol exports ]
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      46113830
    • David S. Miller's avatar
      [SPARC64]: Fix Ultra5, Ultra60, et al. boot failures. · 5d8e1b18
      David S. Miller authored 
      On the boot processor, we need to do the move onto the Linux trap
table a little bit differently else we'll take unhandlable faults in
the firmware address space.

Previously we would do the following:

1) Disable PSTATE_IE in %pstate.
2) Set %tba by hand to sparc64_ttable_tl0
3) Initialize alternate, mmu, and interrupt global
   trap registers.
4) Call prom_set_traptable()

That doesn't work very well actually with the way we boot the kernel
VM these days.  It worked by luck on many systems because the firmware
accesses for the prom_set_traptable() call happened to be loaded into
the TLB already, something we cannot assume.

So the new scheme is this:

1) Clear PSTATE_IE in %pstate and set %pil to 15
2) Call prom_set_traptable()
3) Initialize alternate, mmu, and interrupt global
   trap registers.

and this works quite well.  This sequence has been moved into a
callable function in assembler named setup-trap_table().  The idea is
that eventually trampoline.S can use this code as well.  That isn't
possible currently due to some complications, but eventually we should
be able to do it.

Thanks to Meelis Roos for the Ultra5 boot failure report.
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5d8e1b18
    • Andi Kleen's avatar
      [PATCH] x86_64: Fix change_page_attr cache flushing · 094804c5
      Andi Kleen authored 
      Noticed by Terence Ripperda

Undo wrong change in global_flush_tlb. We need to flush the caches in all
cases, not just when pages were reverted. This was a bogus optimization
added earlier, but it was wrong.
Signed-off-by: default avatarAndi Kleen <ak@suse.de>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      094804c5