1. 14 2月, 2007 1 次提交
  2. 13 2月, 2007 3 次提交
    • A
      [PATCH] mark struct file_operations const 5 · d54b1fdb
      Arjan van de Ven 提交于
      Many struct file_operations in the kernel can be "const".  Marking them const
      moves these to the .rodata section, which avoids false sharing with potential
      dirty data.  In addition it'll catch accidental writes at compile time to
      these shared resources.
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d54b1fdb
    • D
      [PATCH] RTC gets sysfs wakealarm attribute · 3925a5ce
      David Brownell 提交于
      This adds a new "wakealarm" sysfs attribute to RTC class devices which support
      alarm operations and are wakeup-capable:
      
       - It reads as either empty, or the scheduled alarm time as seconds
         since the POSIX epoch.  (That time may already have passed, since
         nothing currently enforces one-shot alarm semantics.)
      
       - It can be written with an alarm time in the future, again seconds
         since the POSIX epoch, which enables the alarm.
      
       - It can be written with an alarm time not in the future (such as 0,
         the start of the POSIX epoch) to disable the alarm.
      
      Usage examples (some need GNU date) after "cd /sys/class/rtc/rtcN":
      
          alarm after 10 minutes:
      	# echo $(( $(cat since_epoch) + 10 * 60 )) > wakealarm
          alarm tuesday evening 10pm:
      	# date -d '10pm tuesday' "+%s" > wakealarm
          disable alarm:
          	# echo 0 > wakealarm
      
      This resembles the /proc/acpi/alarm file in that nothing happens when the
      alarm triggers ...  except possibly waking the system from sleep.  It's also
      like that in a nasty way: not much can be done to prevent one task from
      clobbering another task's alarm settings.
      
      It differs from that file in that there's no in-kernel date parser.
      
      Note that a few RTCs ignore rtc_wkalrm.enabled when setting alarms, or aren't
      set up correctly, so they won't yet behave with this attribute.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3925a5ce
    • P
      [PATCH] change __init to __devinit in 2 rtc drivers · c239122d
      Prarit Bhargava 提交于
      Change __init to __devinit in rtc drivers' probe functions.
      
      Resolves MODPOST warnings:
      
      WARNING: drivers/rtc/rtc-ds1553.o - Section mismatch: reference to
      .init.text:ds1553_rtc_probe from .data.rel between 'ds1553_rtc_driver' (at
      offset 0x0) and 'ds1553_nvram_attr'
      WARNING: drivers/rtc/rtc-ds1742.o - Section mismatch: reference to
      .init.text:ds1742_rtc_probe from .data.rel between 'ds1742_rtc_driver' (at
      offset 0x0) and 'ds1742_nvram_attr'
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c239122d
  3. 12 2月, 2007 1 次提交
    • D
      [PATCH] RTC framework driver for CMOS RTCs · 7be2c7c9
      David Brownell 提交于
      This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
      PCs and some other platforms.  That's MC146818 compatible silicon.
      Advantages of this vs.  drivers/char/rtc.c (use one _or_ the other, only
      one will be able to claim the RTC irq) include:
      
       - This leverages both the new RTC framework and the driver model; both
         PNPACPI and platform device modes are supported.  (A separate patch
         creates a platform device on PCs where PNPACPI isn't configured.)
      
       - It supports common extensions like longer alarms.  (A separate patch
         exports that information from ACPI through platform_data.)
      
       - Likewise, system wakeup events use "real driver model support", with
         policy control via sysfs "wakeup" attributes and and using normal rtc
         ioctls to manage wakeup.  (Patch in the works.  The ACPI hooks are
         known; /proc/acpi/alarm can vanish.  Making it work with EFI will
         be a minor challenge to someone with e.g. a MiniMac.)
      
      It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
      And the RTC framework will surely have teething pains on "mainstream"
      PC-based systems (though must embedded Linux systems use it heavily), not
      limited to sorting out the "/dev/rtc0" issue (udev easily tweaked).  Also,
      the ALSA rtctimer code doesn't use the new RTC API.
      
      Otherwise, this should be a no-known-regressions replacement for the old
      drivers/char/rtc.c driver, and should help the non-embedded distros (and
      the new timekeeping code) start to switch to the framework.
      
      Note also that any systems using "rtc-m48t86" are candidates to switch over
      to this more functional driver; the platform data is different, and the way
      bytes are read is different, but otherwise those chips should be compatible.
      
      [akpm@osdl.org: sparc32 fix]
      [akpm@osdl.org: sparc64 fix]
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Cc: Woody Suwalski <woodys@xandros.com>
      Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7be2c7c9
  4. 10 2月, 2007 2 次提交
  5. 27 1月, 2007 1 次提交
  6. 23 1月, 2007 1 次提交
  7. 12 1月, 2007 1 次提交
  8. 06 1月, 2007 2 次提交
  9. 14 12月, 2006 2 次提交
  10. 12 12月, 2006 3 次提交
    • J
      rtc: rtc-sh: alarm support. · 1b73e6ae
      Jamie Lenehan 提交于
      This adds alarm support for the RTC_ALM_SET, RTC_ALM_READ,
      RTC_WKALM_SET and RTC_WKALM_RD operations to rtc-sh.
      
      The only unusual part is the handling of the alarm interrupt. If you
      clear the alarm flag (AF) while the time in the RTC still matches the
      time in the alarm registers than AF is immediately re-set, and if the
      alarm interrupt (AIE) is still enabled then it re-triggers. I was
      originally getting around 20k+ interrupts generated during the second
      when the RTC and alarm registers matches.
      
      The solution I've used is to clear AIE when the alarm goes off and
      then use the carry interrupt to re-enabled it. The carry interrupt
      will check AF and re-enabled AIE if it's clear. If AF is not clear
      it'll clear it and then the check will be repeated next carry
      interrupt. This a bit in rtc structure that indicates that it's
      waiting to have AIE re-enabled so it doesn't turn it on when it
      wasn't enabled anyway.
      Signed-off-by: NJamie Lenehan <lenehan@twibble.org>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      1b73e6ae
    • J
      rtc: rtc-sh: fix rtc for out-by-one for the month. · a1614796
      Jamie Lenehan 提交于
      The RMONCNT register, which holds the month in the RTC, takes a value
      between 1 and 12 while the tm_mon field in the time structures takes
      a value between 0 and 11. This wasn't being taken into account in
      rtc-sh resulting in the month being out by one.
      
      eg, on my board during boot the RTC is set to:
      
        RTC is set to Thu Jul 01 09:00:00 1999
      
      but "hwclock -r" immediately after logging in was showing:
      
        Sun Aug  1 09:01:43 1999  0.000000 seconds
      Signed-off-by: NJamie Lenehan <lenehan@twibble.org>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      a1614796
    • J
      rtc: rtc-sh: fix for period rtc interrupts. · 31ccb081
      Jamie Lenehan 提交于
      When testing the per second interrupt support (RTC_UIE_ON/RTC_UIE_OFF)
      of the new RTC system it would die in sh_rtc_interrupt due to a null
      ptr dereference. The following gets it working correctly.
      Signed-off-by: NJamie Lenehan <lenehan@twibble.org>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      31ccb081
  11. 11 12月, 2006 3 次提交
  12. 08 12月, 2006 4 次提交
  13. 26 11月, 2006 3 次提交
  14. 22 11月, 2006 1 次提交
  15. 17 10月, 2006 2 次提交
  16. 06 10月, 2006 1 次提交
  17. 05 10月, 2006 1 次提交
    • D
      IRQ: Maintain regs pointer globally rather than passing to IRQ handlers · 7d12e780
      David Howells 提交于
      Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
      of passing regs around manually through all ~1800 interrupt handlers in the
      Linux kernel.
      
      The regs pointer is used in few places, but it potentially costs both stack
      space and code to pass it around.  On the FRV arch, removing the regs parameter
      from all the genirq function results in a 20% speed up of the IRQ exit path
      (ie: from leaving timer_interrupt() to leaving do_IRQ()).
      
      Where appropriate, an arch may override the generic storage facility and do
      something different with the variable.  On FRV, for instance, the address is
      maintained in GR28 at all times inside the kernel as part of general exception
      handling.
      
      Having looked over the code, it appears that the parameter may be handed down
      through up to twenty or so layers of functions.  Consider a USB character
      device attached to a USB hub, attached to a USB controller that posts its
      interrupts through a cascaded auxiliary interrupt controller.  A character
      device driver may want to pass regs to the sysrq handler through the input
      layer which adds another few layers of parameter passing.
      
      I've build this code with allyesconfig for x86_64 and i386.  I've runtested the
      main part of the code on FRV and i386, though I can't test most of the drivers.
      I've also done partial conversion for powerpc and MIPS - these at least compile
      with minimal configurations.
      
      This will affect all archs.  Mostly the changes should be relatively easy.
      Take do_IRQ(), store the regs pointer at the beginning, saving the old one:
      
      	struct pt_regs *old_regs = set_irq_regs(regs);
      
      And put the old one back at the end:
      
      	set_irq_regs(old_regs);
      
      Don't pass regs through to generic_handle_irq() or __do_IRQ().
      
      In timer_interrupt(), this sort of change will be necessary:
      
      	-	update_process_times(user_mode(regs));
      	-	profile_tick(CPU_PROFILING, regs);
      	+	update_process_times(user_mode(get_irq_regs()));
      	+	profile_tick(CPU_PROFILING);
      
      I'd like to move update_process_times()'s use of get_irq_regs() into itself,
      except that i386, alone of the archs, uses something other than user_mode().
      
      Some notes on the interrupt handling in the drivers:
      
       (*) input_dev() is now gone entirely.  The regs pointer is no longer stored in
           the input_dev struct.
      
       (*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking.  It does
           something different depending on whether it's been supplied with a regs
           pointer or not.
      
       (*) Various IRQ handler function pointers have been moved to type
           irq_handler_t.
      Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      (cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
      7d12e780
  18. 04 10月, 2006 3 次提交
  19. 02 10月, 2006 1 次提交
  20. 01 10月, 2006 4 次提交