* [PATCH 06/33] Staging: cx25821: Makefile: replace the use of <module>-objs with <module>-y
From: Tracey Dent @ 2010-10-08 0:01 UTC (permalink / raw)
To: greg; +Cc: linux-kernel, kernel-janitors, sam, linux-kbuild, Tracey Dent
In-Reply-To: <1286496113-11897-1-git-send-email-tdent48227@gmail.com>
Changed <module>-objs to <module>-y in Makefile.
Signed-off-by: Tracey Dent <tdent48227@gmail.com>
---
drivers/staging/cx25821/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/cx25821/Makefile b/drivers/staging/cx25821/Makefile
index 6448364..aedde18 100644
--- a/drivers/staging/cx25821/Makefile
+++ b/drivers/staging/cx25821/Makefile
@@ -1,4 +1,4 @@
-cx25821-objs := cx25821-core.o cx25821-cards.o cx25821-i2c.o \
+cx25821-y := cx25821-core.o cx25821-cards.o cx25821-i2c.o \
cx25821-gpio.o cx25821-medusa-video.o \
cx25821-video.o cx25821-video-upstream.o \
cx25821-video-upstream-ch2.o \
--
1.7.3.1.50.g1e633
^ permalink raw reply related
* [PATCH 05/33] Staging: crystalhd: Makefile: replace the use of <module>-objs with <module>-y
From: Tracey Dent @ 2010-10-08 0:01 UTC (permalink / raw)
To: greg; +Cc: linux-kernel, kernel-janitors, sam, linux-kbuild, Tracey Dent
In-Reply-To: <1286496113-11897-1-git-send-email-tdent48227@gmail.com>
Changed <module>-objs to <module>-y in Makefile.
Signed-off-by: Tracey Dent <tdent48227@gmail.com>
---
drivers/staging/crystalhd/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/crystalhd/Makefile b/drivers/staging/crystalhd/Makefile
index e2af0ce..c31657a 100644
--- a/drivers/staging/crystalhd/Makefile
+++ b/drivers/staging/crystalhd/Makefile
@@ -1,6 +1,6 @@
obj-$(CONFIG_CRYSTALHD) += crystalhd.o
-crystalhd-objs := crystalhd_cmds.o \
+crystalhd-y := crystalhd_cmds.o \
crystalhd_hw.o \
crystalhd_lnx.o \
crystalhd_misc.o
--
1.7.3.1.50.g1e633
^ permalink raw reply related
* [PATCH 04/33] Staging: comedi: Makefile: replace the use of <module>-objs with <module>-y
From: Tracey Dent @ 2010-10-08 0:01 UTC (permalink / raw)
To: greg; +Cc: linux-kernel, kernel-janitors, sam, linux-kbuild, Tracey Dent
In-Reply-To: <1286496113-11897-1-git-send-email-tdent48227@gmail.com>
Changed <module>-objs to <module>-y in Makefile.
Signed-off-by: Tracey Dent <tdent48227@gmail.com>
---
drivers/staging/comedi/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/comedi/Makefile b/drivers/staging/comedi/Makefile
index 20afea3..8dbd306 100644
--- a/drivers/staging/comedi/Makefile
+++ b/drivers/staging/comedi/Makefile
@@ -3,7 +3,7 @@ obj-$(CONFIG_COMEDI) += comedi.o
obj-$(CONFIG_COMEDI) += kcomedilib/
obj-$(CONFIG_COMEDI) += drivers/
-comedi-objs := \
+comedi-y := \
comedi_fops.o \
proc.o \
range.o \
--
1.7.3.1.50.g1e633
^ permalink raw reply related
* [PATCH 03/33] Staging: bcm: Makefile: replace the use of <module>-objs with <module>-y
From: Tracey Dent @ 2010-10-08 0:01 UTC (permalink / raw)
To: greg; +Cc: linux-kernel, kernel-janitors, sam, linux-kbuild, Tracey Dent
In-Reply-To: <1286496113-11897-1-git-send-email-tdent48227@gmail.com>
Changed <module>-objs to <module>-y in Makefile.
Signed-off-by: Tracey Dent <tdent48227@gmail.com>
---
drivers/staging/bcm/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/bcm/Makefile b/drivers/staging/bcm/Makefile
index 3fdec2e..c3ae25a 100644
--- a/drivers/staging/bcm/Makefile
+++ b/drivers/staging/bcm/Makefile
@@ -4,7 +4,7 @@
obj-$(CONFIG_BCM_WIMAX) += bcm_wimax.o
-bcm_wimax-objs := InterfaceDld.o InterfaceIdleMode.o InterfaceInit.o InterfaceRx.o \
+bcm_wimax-y := InterfaceDld.o InterfaceIdleMode.o InterfaceInit.o InterfaceRx.o \
InterfaceIsr.o InterfaceMisc.o InterfaceTx.o \
Arp.o CmHost.o Debug.o IPv6Protocol.o Qos.o Transmit.o\
Bcmnet.o DDRInit.o HandleControlPacket.o\
--
1.7.3.1.50.g1e633
^ permalink raw reply related
* [PATCH 02/33] Staging: batman-adv: Makefile: replace the use of <module>-objs with <module>-y
From: Tracey Dent @ 2010-10-08 0:01 UTC (permalink / raw)
To: greg; +Cc: linux-kernel, kernel-janitors, sam, linux-kbuild, Tracey Dent
In-Reply-To: <1286496113-11897-1-git-send-email-tdent48227@gmail.com>
Changed <module>-objs to <module>-y n Makefile.
Signed-off-by: Tracey Dent <tdent48227@gmail.com>
---
drivers/staging/batman-adv/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/batman-adv/Makefile b/drivers/staging/batman-adv/Makefile
index 4b5c434..7892428 100644
--- a/drivers/staging/batman-adv/Makefile
+++ b/drivers/staging/batman-adv/Makefile
@@ -19,4 +19,4 @@
#
obj-$(CONFIG_BATMAN_ADV) += batman-adv.o
-batman-adv-objs := main.o bat_debugfs.o bat_sysfs.o send.o routing.o soft-interface.o icmp_socket.o translation-table.o bitarray.o hash.o ring_buffer.o vis.o hard-interface.o aggregation.o originator.o unicast.o
+batman-adv-y := main.o bat_debugfs.o bat_sysfs.o send.o routing.o soft-interface.o icmp_socket.o translation-table.o bitarray.o hash.o ring_buffer.o vis.o hard-interface.o aggregation.o originator.o unicast.o
--
1.7.3.1.50.g1e633
^ permalink raw reply related
* [PATCH 01/33] Staging: autofs: Makefile: replace the use of <module>-objs with <module>-y
From: Tracey Dent @ 2010-10-08 0:01 UTC (permalink / raw)
To: greg; +Cc: linux-kernel, kernel-janitors, sam, linux-kbuild, Tracey Dent
Changed Makefile <module>-objs to <module>-y lines.
Signed-off-by: Tracey Dent <tdent48227@gmail.com>
---
drivers/staging/autofs/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/autofs/Makefile b/drivers/staging/autofs/Makefile
index 453a60f..f48781c 100644
--- a/drivers/staging/autofs/Makefile
+++ b/drivers/staging/autofs/Makefile
@@ -4,4 +4,4 @@
obj-$(CONFIG_AUTOFS_FS) += autofs.o
-autofs-objs := dirhash.o init.o inode.o root.o symlink.o waitq.o
+autofs-y := dirhash.o init.o inode.o root.o symlink.o waitq.o
--
1.7.3.1.50.g1e633
^ permalink raw reply related
* Re: [PATCH] sdhci: allow for eMMC 74 clock generation by controller
From: Chris Ball @ 2010-10-07 23:58 UTC (permalink / raw)
To: Philip Rakity
Cc: Wolfram Sang, linux-mmc@vger.kernel.org, Adrian Hunter,
Mark Brown
In-Reply-To: <55175F2E-72DD-4BB2-8EDD-70D8B553F7B6@marvell.com>
Hi Philip,
On Thu, Sep 23, 2010 at 08:24:32AM -0700, Philip Rakity wrote:
> From: Philip Rakity <prakity@marvell.com>
> Date: Thu, 23 Sep 2010 08:15:03 -0700
> Subject: [PATCH] sdhci: allow for initial eMMC 74 clock generation by controller
>
> resend of patch to fit into 80 char line lengths:
>
> snippet of code for how adaption layer should handle the call.
>
>
> /*
> * eMMC spec calls for the host to send 74 clocks to the card
> * during initialization, right after voltage stabilization.
> * create the clocks manually right here.
> */
> void generate_init_clocks_A0(struct sdhci_host *host, u8 power_mode)
> {
> struct sdhci_mmc_slot *slot = sdhci_priv(host);
>
> DBG ("%s: ENTER %s: slot->power_mode = %d, ios->power_mode = %d\n",
> __func__,
> mmc_hostname(host->mmc),
> slot->power_mode,
> power_mode);
>
> if (slot->power_mode == MMC_POWER_UP
> && power_mode == MMC_POWER_ON) {
>
> /* controller specific code here */
> /* slot->power_mode holds previous power setting */
> }
> slot->power_mode = power_mode;
> }
>
>
> Signed-off-by: Philip Rakity <prakity@marvell.com>
> ---
> drivers/mmc/host/sdhci.c | 3 +++
> drivers/mmc/host/sdhci.h | 2 ++
> 2 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 6b8ca32..ba8f9a0 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1169,6 +1169,9 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> else
> sdhci_set_power(host, ios->vdd);
>
> + if (host->ops->platform_send_init_74_clocks)
> + host->ops->platform_send_init_74_clocks(host, ios->power_mode);
> +
> ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
>
> if (ios->bus_width == MMC_BUS_WIDTH_8)
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index 290b5a8..d73685a 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -325,6 +325,8 @@ struct sdhci_ops {
> unsigned int (*get_max_clock)(struct sdhci_host *host);
> unsigned int (*get_min_clock)(struct sdhci_host *host);
> unsigned int (*get_timeout_clock)(struct sdhci_host *host);
> + void (*platform_send_init_74_clocks)(struct sdhci_host *host,
> + u8 power_mode);
> };
>
> #ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
> --
Thanks, applied to mmc-next.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* RE: [RFC][QEMU] ATI graphics VBIOS passthru support
From: Kay, Allen M @ 2010-10-07 23:57 UTC (permalink / raw)
To: Huang2, Wei, Ian Jackson; +Cc: Xen-devel
In-Reply-To: <EE335F95F28A664DB4A21289D2AA053B8E1E9B35@SAUSEXMBP01.amd.com>
[-- Attachment #1.1: Type: text/plain, Size: 1024 bytes --]
Hi Wei,
This patch did not cause any problems with Intel IGD passthrough for me. However, the monitor remained blank if I pass through ATI Firepro V3750 either as the primary display device or the secondary device (gfx_passthru=1/0). Passing it through as the secondary device used to work.
Have you tested the patch with this graphics card?
Allen
From: Huang2, Wei [mailto:Wei.Huang2@amd.com]
Sent: Thursday, October 07, 2010 9:57 AM
To: Ian Jackson
Cc: Xen-devel; Kay, Allen M
Subject: [RFC][QEMU] ATI graphics VBIOS passthru support
Hi Ian,
There have been a lot of interest on gfx passthru recently. This patch enables ATI VBIOS in passthru mode. The guest VM system BIOS (including Windows boot logo) can now show in passthru screen. We have tested with various Windows and Linux guest VMs. Please help review it. We are also looking forward to comments and suggestions from Xen community users.
Signed-off-by: Wei Huang <wei.huang2@amd.com>
Signed-off-by: Wei Wang <wei.wang2@amd.com>
[-- Attachment #1.2: Type: text/html, Size: 4129 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: 2.6.36-rc7: kernel panic with SECURITY_TOMOYO=y
From: Christian Kujau @ 2010-10-07 23:57 UTC (permalink / raw)
To: LKML; +Cc: takedakn, penguin-kernel
In-Reply-To: <alpine.DEB.2.01.1010071534370.21082@trent.utfs.org>
On Thu, 7 Oct 2010 at 15:43, Christian Kujau wrote:
> Kernel panic - not syncing: Profile uersion 0 is not supported
OK, I just saw that security/tomoyo/common.c panics when:
if (tomoyo_profile_version != 20090903)
panic("Profile version %u is not supported.\n",
tomoyo_profile_version);
If it's imperative that the profile version is somewhat current (mine was
not, I had old tomoyo-ccstools installed), I would have expected a
slightly more descriptive error messages (apart from that panic), but now
I know. Upgraded to tomoyo-tools-2.3.0-20100820 did the trick.
Sorry for the noise...
Christian.
--
BOFH excuse #86:
Runt packets
^ permalink raw reply
* Re: [PATCH] PM: add synchronous runtime interface for interrupt handlers
From: Kevin Hilman @ 2010-10-07 23:55 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Alan Stern, Linux-pm mailing list, Partha Basak, linux-omap
In-Reply-To: <201010080137.38422.rjw@sisk.pl>
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> On Friday, October 08, 2010, Kevin Hilman wrote:
>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>>
>> > On Thursday, October 07, 2010, Alan Stern wrote:
>> >> On Thu, 7 Oct 2010, Kevin Hilman wrote:
>> >>
>> >> > My confusion is not about the use of spinlocks, it's a question of what
>> >> > is being busy-waited for, and the thread that is being waited for is
>> >> > going to complete when interrupts are disabled.
>> >> >
>> >> > Sorry to be dense, but can you (re)summarize what you're proposing as I
>> >> > think I'm getting mixed up with all the various options we've been
>> >> > tossing around.
>> >> >
>> >> > If it can work, I'm certainly in favor of a busy-wait approach as it
>> >> > really ensures that sync requests are handled quickly.
>> >>
>> >> Okay, here's the story in a nutshell. Allowing a subsystem's or
>> >> driver's runtime-PM callbacks to run with interrupts disabled faces two
>> >> obstacles:
>> >>
>> >> (1): We don't want two different CPUs to run callbacks for the
>> >> same device at the same time. So if a callback is already
>> >> running on one CPU (i.e., if the device's runtime status is
>> >> either SUSPENDING or RESUMING) then another CPU can't be
>> >> allowed to invoke a callback.
>> >>
>> >> Thus, you can't do a synchronous pm_runtime_resume_irq()
>> >> if the device is in the middle of a suspend or resume
>> >> operation. We're left with two choices: Fail the synchronous
>> >> call and force the driver to defer matters to a workqueue
>> >> (possibly masking an IRQ line in the meantime), or busy-wait
>> >> until the concurrent operation finishes.
>> >>
>> >> If the PM core simply avoids releasing dev->power.lock before
>> >> invoking the runtime_suspend or runtime_resume callback, the
>> >> end result is almost the same as with busy-waiting.
>> >
>> > This is slightly more complicated, because suspend is a bit different from
>> > resume. I think it's generally acceptable to refuse to do a "fast path" suspend
>> > if the device state is not RPM_ACTIVE at the moment, but refusing to do
>> > a "fast path" resume may be more problematic (more on that later).
>> >
>> >> (2): In general we can't resume a device if its parent is suspended.
>> >> If the parent's runtime_resume routine needs to run with
>> >> interrupts enabled then there's no way to resume the device
>> >> while keeping interrupts disabled.
>> >>
>> >> Possible solutions involve, again, deferring matters to a
>> >> workqueue, or else simply not allowing the situation to arise
>> >> in the first place (forbid a device to have interrupt-disabled
>> >> callbacks unless its parent does too or the parent doesn't use
>> >> runtime PM at all).
>> >>
>> >> In general I'm against the solutions that require a workqueue.
>> >
>> > OK
>> >
>> >> Raphael appears to favor workqueues for (1) and be against them for (2).
>> >
>> > The particular case we need to handle (I think) is that some devices need to be
>> > resumed "atomically" as a part of bringing a CPU package out of a C-like-state
>> > (Kevin, is that correct?).
>>
>> Correct, but there is more than one problematic case.
>>
>> Another problem is in devices that are not atomic with C-states, but
>> receive wakeup IRQs while they're suspended and thus need to
>> pm_runtime_get() from their ISRs, without having an essentially
>> unbounded interrupt latency before the ISR can be handled.
>>
>> Consider the following sequence for a given device
>>
>> - device: ->runtime_suspend() /* registers not accessible */
>> - pm_idle
>> - IRQs disabled
>> - idle
>> - wakeup event
>> - idle loop finishes
>> - IRQs enabled
>> - device: ->runtime_resume()
>>
>> Now, consider the 'wakeup event' is an IRQ for that device. That means
>> as soon as IRQs are (re)enabled (and before some other activity has
>> triggered a ->runtime_resume), the device's ISR is called. Since it is
>> RPM_SUSPENDED, it's registers are not accessible so it needs to do a
>> pm_runtime_get().
>>
>> The case that raised this initially was a GPIO IRQ demux, where the
>> initial ISR is just a chained handler whichfigures out which GPIO
>> fired and then call genirq for that IRQ.
>>
>> All that being said, while I've currently described these as two
>> different problems, the second one could be solved by converting it to
>> the first one. IOW, make GPIO be one of those devices that are
>> suspended/resumed atomically with the CPU so that it is guaranteed to be
>> awake when IRQs are re-enabled.
>>
>> While that would work, I've been trying to move in the opposite
>> direction by trying to dis-connect them from CPU idle.
>>
>> > In that case not only we can't defer the resume (by
>> > using a workqueue), but also we have to finish the resume within strict time
>> > constraints (the time to leave the given C-like-state is one of the parameters
>> > used by cpuidle governors to decide which state to choose).
>> >
>> > On the other hand, busy waiting (by looping) in the case the state is
>> > RPM_RESUMING is as though the callbacks were executed under a spinlock and we
>> > happened to wait on it. I'd prefer to avoid that. Moreover, if the state is
>> > RPM_SUSPENDING at the time a "fast path" resume is started, we are almost
>> > guaranteed to violate the time constraints (by busy waiting for the suspend to
>> > complete and carrying out the resume).
>> >
>> > So, here's an idea:
>> >
>> > First, let's introduce two flags in struct dev_pm_info, irq_safe and
>> > fast_resume. The former has to be set so that the things above work.
>> >
>> > Second, let's add a new flag to pass to __pm_runtime_{suspend|resume}(),
>> > RPM_FAST_RESUME such that if it is passed to __pm_runtime_suspend(), it
>> > causes fast_resume to be set for the given device (if the status is already
>> > RPM_SUSPENDED, it just sets the flag, otherwise it suspends the device
>> > normally and then sets the flag). Now, if fast_resume is set,
>> > __pm_runtime_resume() has to be passed RPM_FAST_RESUME, or it will
>> > fail (it also will fail if passed RPM_FAST_RESUME and fast_resume isn't
>> > set). In that case the status has to be RPM_SUSPENDED or RPM_RESUMING
>> > (otherwise fast_resume won't be set) and if it is RPM_RESUMING, this means
>> > that the other resume has been called with RPM_FAST_RESUME too (it would
>> > fail otherwise), so it's fine to busy loop until the status is RPM_SUSPENDED
>> > (it's the caller's problem to avoid that). RPM_FAST_RESUME causes
>> > __pm_runtime_resume() to avod turning interrupts on.
>> >
>> > If necessary, there may be a flag for __pm_runtime_suspend() that will
>> > carry out "atomic" suspend, but I'm not sure if that's necessary. Kevin?
>>
>> I think we'll need both "atomic" suspend & resume.
>>
>> One of the devices I'm currently managing in this atomic fashion (inside
>> pm_idle) is the UARTs (of course, I'm not currently using runtime PM for
>> this, I'm calling platform-specific hooks directly since IRQs are
>> disabled.) For the UARTs I'm using both atomic suspend and resume,
>> primarily for debug so I am sure UARTs are awake to see any panics
>> during the last parts of the suspend/idle process and the early parts of
>> the resume path. This UART case is a bit of a hack until the driver is
>> converted to runtime PM, but illustrates some debug related reasons we
>> might also need atomic suspend and resume.
>>
>> We also have some workarounds for hardware errata that require
>> putting certain devices in a specific state just before (and after)
>> idle. The drivers for these devices will need both suspend and resume.
>
> OK, thanks for the info.
>
> Do you need "normal" resume to work after "atomic" suspend, or is it
> sufficient that "atomic" suspend will require "atomic" resume?
hmm... while I'm definitely needing an "atomic" resume after a "normal"
suspend, for now I can't think of a case where a "normal" resume would
be needed after an "atomic" suspend. All the cases where I'm currently
using an atomic suspend also have a corresponding atomic resume.
As I write this, it wouldn't surprise me down the road to find some HW
errata that requires the device in a specific state only before idle,
but not caring about the state after idle. That would be a case where
an atomic suspend would be needed, but the resume would be "normal"
sometime later when the device is next needed.
Kevin
^ permalink raw reply
* Re: [PATCH] PM: add synchronous runtime interface for interrupt handlers
From: Kevin Hilman @ 2010-10-07 23:55 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Partha Basak, Linux-pm mailing list, linux-omap
In-Reply-To: <201010080137.38422.rjw@sisk.pl>
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> On Friday, October 08, 2010, Kevin Hilman wrote:
>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>>
>> > On Thursday, October 07, 2010, Alan Stern wrote:
>> >> On Thu, 7 Oct 2010, Kevin Hilman wrote:
>> >>
>> >> > My confusion is not about the use of spinlocks, it's a question of what
>> >> > is being busy-waited for, and the thread that is being waited for is
>> >> > going to complete when interrupts are disabled.
>> >> >
>> >> > Sorry to be dense, but can you (re)summarize what you're proposing as I
>> >> > think I'm getting mixed up with all the various options we've been
>> >> > tossing around.
>> >> >
>> >> > If it can work, I'm certainly in favor of a busy-wait approach as it
>> >> > really ensures that sync requests are handled quickly.
>> >>
>> >> Okay, here's the story in a nutshell. Allowing a subsystem's or
>> >> driver's runtime-PM callbacks to run with interrupts disabled faces two
>> >> obstacles:
>> >>
>> >> (1): We don't want two different CPUs to run callbacks for the
>> >> same device at the same time. So if a callback is already
>> >> running on one CPU (i.e., if the device's runtime status is
>> >> either SUSPENDING or RESUMING) then another CPU can't be
>> >> allowed to invoke a callback.
>> >>
>> >> Thus, you can't do a synchronous pm_runtime_resume_irq()
>> >> if the device is in the middle of a suspend or resume
>> >> operation. We're left with two choices: Fail the synchronous
>> >> call and force the driver to defer matters to a workqueue
>> >> (possibly masking an IRQ line in the meantime), or busy-wait
>> >> until the concurrent operation finishes.
>> >>
>> >> If the PM core simply avoids releasing dev->power.lock before
>> >> invoking the runtime_suspend or runtime_resume callback, the
>> >> end result is almost the same as with busy-waiting.
>> >
>> > This is slightly more complicated, because suspend is a bit different from
>> > resume. I think it's generally acceptable to refuse to do a "fast path" suspend
>> > if the device state is not RPM_ACTIVE at the moment, but refusing to do
>> > a "fast path" resume may be more problematic (more on that later).
>> >
>> >> (2): In general we can't resume a device if its parent is suspended.
>> >> If the parent's runtime_resume routine needs to run with
>> >> interrupts enabled then there's no way to resume the device
>> >> while keeping interrupts disabled.
>> >>
>> >> Possible solutions involve, again, deferring matters to a
>> >> workqueue, or else simply not allowing the situation to arise
>> >> in the first place (forbid a device to have interrupt-disabled
>> >> callbacks unless its parent does too or the parent doesn't use
>> >> runtime PM at all).
>> >>
>> >> In general I'm against the solutions that require a workqueue.
>> >
>> > OK
>> >
>> >> Raphael appears to favor workqueues for (1) and be against them for (2).
>> >
>> > The particular case we need to handle (I think) is that some devices need to be
>> > resumed "atomically" as a part of bringing a CPU package out of a C-like-state
>> > (Kevin, is that correct?).
>>
>> Correct, but there is more than one problematic case.
>>
>> Another problem is in devices that are not atomic with C-states, but
>> receive wakeup IRQs while they're suspended and thus need to
>> pm_runtime_get() from their ISRs, without having an essentially
>> unbounded interrupt latency before the ISR can be handled.
>>
>> Consider the following sequence for a given device
>>
>> - device: ->runtime_suspend() /* registers not accessible */
>> - pm_idle
>> - IRQs disabled
>> - idle
>> - wakeup event
>> - idle loop finishes
>> - IRQs enabled
>> - device: ->runtime_resume()
>>
>> Now, consider the 'wakeup event' is an IRQ for that device. That means
>> as soon as IRQs are (re)enabled (and before some other activity has
>> triggered a ->runtime_resume), the device's ISR is called. Since it is
>> RPM_SUSPENDED, it's registers are not accessible so it needs to do a
>> pm_runtime_get().
>>
>> The case that raised this initially was a GPIO IRQ demux, where the
>> initial ISR is just a chained handler whichfigures out which GPIO
>> fired and then call genirq for that IRQ.
>>
>> All that being said, while I've currently described these as two
>> different problems, the second one could be solved by converting it to
>> the first one. IOW, make GPIO be one of those devices that are
>> suspended/resumed atomically with the CPU so that it is guaranteed to be
>> awake when IRQs are re-enabled.
>>
>> While that would work, I've been trying to move in the opposite
>> direction by trying to dis-connect them from CPU idle.
>>
>> > In that case not only we can't defer the resume (by
>> > using a workqueue), but also we have to finish the resume within strict time
>> > constraints (the time to leave the given C-like-state is one of the parameters
>> > used by cpuidle governors to decide which state to choose).
>> >
>> > On the other hand, busy waiting (by looping) in the case the state is
>> > RPM_RESUMING is as though the callbacks were executed under a spinlock and we
>> > happened to wait on it. I'd prefer to avoid that. Moreover, if the state is
>> > RPM_SUSPENDING at the time a "fast path" resume is started, we are almost
>> > guaranteed to violate the time constraints (by busy waiting for the suspend to
>> > complete and carrying out the resume).
>> >
>> > So, here's an idea:
>> >
>> > First, let's introduce two flags in struct dev_pm_info, irq_safe and
>> > fast_resume. The former has to be set so that the things above work.
>> >
>> > Second, let's add a new flag to pass to __pm_runtime_{suspend|resume}(),
>> > RPM_FAST_RESUME such that if it is passed to __pm_runtime_suspend(), it
>> > causes fast_resume to be set for the given device (if the status is already
>> > RPM_SUSPENDED, it just sets the flag, otherwise it suspends the device
>> > normally and then sets the flag). Now, if fast_resume is set,
>> > __pm_runtime_resume() has to be passed RPM_FAST_RESUME, or it will
>> > fail (it also will fail if passed RPM_FAST_RESUME and fast_resume isn't
>> > set). In that case the status has to be RPM_SUSPENDED or RPM_RESUMING
>> > (otherwise fast_resume won't be set) and if it is RPM_RESUMING, this means
>> > that the other resume has been called with RPM_FAST_RESUME too (it would
>> > fail otherwise), so it's fine to busy loop until the status is RPM_SUSPENDED
>> > (it's the caller's problem to avoid that). RPM_FAST_RESUME causes
>> > __pm_runtime_resume() to avod turning interrupts on.
>> >
>> > If necessary, there may be a flag for __pm_runtime_suspend() that will
>> > carry out "atomic" suspend, but I'm not sure if that's necessary. Kevin?
>>
>> I think we'll need both "atomic" suspend & resume.
>>
>> One of the devices I'm currently managing in this atomic fashion (inside
>> pm_idle) is the UARTs (of course, I'm not currently using runtime PM for
>> this, I'm calling platform-specific hooks directly since IRQs are
>> disabled.) For the UARTs I'm using both atomic suspend and resume,
>> primarily for debug so I am sure UARTs are awake to see any panics
>> during the last parts of the suspend/idle process and the early parts of
>> the resume path. This UART case is a bit of a hack until the driver is
>> converted to runtime PM, but illustrates some debug related reasons we
>> might also need atomic suspend and resume.
>>
>> We also have some workarounds for hardware errata that require
>> putting certain devices in a specific state just before (and after)
>> idle. The drivers for these devices will need both suspend and resume.
>
> OK, thanks for the info.
>
> Do you need "normal" resume to work after "atomic" suspend, or is it
> sufficient that "atomic" suspend will require "atomic" resume?
hmm... while I'm definitely needing an "atomic" resume after a "normal"
suspend, for now I can't think of a case where a "normal" resume would
be needed after an "atomic" suspend. All the cases where I'm currently
using an atomic suspend also have a corresponding atomic resume.
As I write this, it wouldn't surprise me down the road to find some HW
errata that requires the device in a specific state only before idle,
but not caring about the state after idle. That would be a case where
an atomic suspend would be needed, but the resume would be "normal"
sometime later when the device is next needed.
Kevin
^ permalink raw reply
* Re: [PATCH] fast-import: Allow filemodify to set the root
From: Sverre Rabbelier @ 2010-10-07 23:55 UTC (permalink / raw)
To: David Barr; +Cc: Git Mailing List, Jonathan Nieder, Ramkumar Ramachandra
In-Reply-To: <1286495219-14414-1-git-send-email-david.barr@cordelta.com>
Heya,
On Fri, Oct 8, 2010 at 01:46, David Barr <david.barr@cordelta.com> wrote:
> Commit-message-by: Jonathan Nieder <jrnieder@gmail.com>
> Signed-off-by: David Barr <david.barr@cordelta.com>
I like it, FWIW:
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] sdhci: highspeed: check for mmc as well as sd cards
From: Chris Ball @ 2010-10-07 23:52 UTC (permalink / raw)
To: Philip Rakity; +Cc: linux-mmc@vger.kernel.org
In-Reply-To: <41A82D88-6200-469C-986D-EF46B0C6A773@marvell.com>
Hi Philip,
On Wed, Oct 06, 2010 at 11:57:23AM -0700, Philip Rakity wrote:
>
> when examining the code in the mmc directory the SD and MMC code
> set highspeed using a different constant. Change the sd driver
> to recognize this and switch to high speed.
>
> Signed-off-by: Philip Rakity <prakity@marvell.com>
> ---
> drivers/mmc/host/sdhci.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index d3f924b..1d3f4d8 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1194,8 +1194,9 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> else
> ctrl &= ~SDHCI_CTRL_4BITBUS;
>
> - if (ios->timing == MMC_TIMING_SD_HS &&
> - !(host->quirks & SDHCI_QUIRK_NO_HISPD_BIT))
> + if ((ios->timing == MMC_TIMING_SD_HS
> + || ios->timing == MMC_TIMING_MMC_HS)
> + && !(host->quirks & SDHCI_QUIRK_NO_HISPD_BIT))
> ctrl |= SDHCI_CTRL_HISPD;
> else
> ctrl &= ~SDHCI_CTRL_HISPD;
> --
Thanks, applied to mmc-next.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* [tip:x86/mrst] x86, mrst: A function in a header file needs to be marked "inline"
From: tip-bot for H. Peter Anvin @ 2010-10-07 23:52 UTC (permalink / raw)
To: linux-tip-commits; +Cc: linux-kernel, hpa, mingo, tglx, jacob.jun.pan, hpa
In-Reply-To: <1274295685-6774-3-git-send-email-jacob.jun.pan@linux.intel.com>
Commit-ID: 55572b293b3a5929e8c54bc91d14ae6264186bf6
Gitweb: http://git.kernel.org/tip/55572b293b3a5929e8c54bc91d14ae6264186bf6
Author: H. Peter Anvin <hpa@linux.intel.com>
AuthorDate: Thu, 7 Oct 2010 16:42:54 -0700
Committer: H. Peter Anvin <hpa@linux.intel.com>
CommitDate: Thu, 7 Oct 2010 16:45:18 -0700
x86, mrst: A function in a header file needs to be marked "inline"
A function in a header file needs to be explicitly marked "inline", or
gcc will complain if it is not used.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: <stable@kernel.org> v2.6.36
LKML-Reference: <1274295685-6774-3-git-send-email-jacob.jun.pan@linux.intel.com>
---
arch/x86/include/asm/mrst.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/mrst.h b/arch/x86/include/asm/mrst.h
index 1635074..33fc296 100644
--- a/arch/x86/include/asm/mrst.h
+++ b/arch/x86/include/asm/mrst.h
@@ -26,7 +26,7 @@ enum mrst_cpu_type {
};
extern enum mrst_cpu_type __mrst_cpu_chip;
-static enum mrst_cpu_type mrst_identify_cpu(void)
+static inline enum mrst_cpu_type mrst_identify_cpu(void)
{
return __mrst_cpu_chip;
}
^ permalink raw reply related
* [tip:x86/mm] x86-32: Fix sparse warning for the __PHYSICAL_MASK calculation
From: tip-bot for Namhyung Kim @ 2010-10-07 23:52 UTC (permalink / raw)
To: linux-tip-commits; +Cc: linux-kernel, hpa, mingo, tglx, hpa, namhyung
In-Reply-To: <1285770588-14065-1-git-send-email-namhyung@gmail.com>
Commit-ID: a416e9e1dde0fbcf20cda59df284cc0dcf2aadc4
Gitweb: http://git.kernel.org/tip/a416e9e1dde0fbcf20cda59df284cc0dcf2aadc4
Author: Namhyung Kim <namhyung@gmail.com>
AuthorDate: Wed, 29 Sep 2010 23:29:48 +0900
Committer: H. Peter Anvin <hpa@linux.intel.com>
CommitDate: Thu, 7 Oct 2010 16:36:17 -0700
x86-32: Fix sparse warning for the __PHYSICAL_MASK calculation
On 32-bit non-PAE system, cast to 'phys_addr_t' truncates value
before subtraction. Subtracting before cast produce same result
but remove following warnings from sparse:
arch/x86/include/asm/pgtable_types.h:255:38: warning: cast truncates bits from constant value (100000000 becomes 0)
arch/x86/include/asm/pgtable_types.h:270:38: warning: cast truncates bits from constant value (100000000 becomes 0)
arch/x86/include/asm/pgtable.h:127:32: warning: cast truncates bits from constant value (100000000 becomes 0)
arch/x86/include/asm/pgtable.h:132:32: warning: cast truncates bits from constant value (100000000 becomes 0)
arch/x86/include/asm/pgtable.h:344:31: warning: cast truncates bits from constant value (100000000 becomes 0)
64-bit or PAE machines will not be affected by this change.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
LKML-Reference: <1285770588-14065-1-git-send-email-namhyung@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
---
arch/x86/include/asm/page_types.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/page_types.h b/arch/x86/include/asm/page_types.h
index a667f24..1df6621 100644
--- a/arch/x86/include/asm/page_types.h
+++ b/arch/x86/include/asm/page_types.h
@@ -8,7 +8,7 @@
#define PAGE_SIZE (_AC(1,UL) << PAGE_SHIFT)
#define PAGE_MASK (~(PAGE_SIZE-1))
-#define __PHYSICAL_MASK ((phys_addr_t)(1ULL << __PHYSICAL_MASK_SHIFT) - 1)
+#define __PHYSICAL_MASK ((phys_addr_t)((1ULL << __PHYSICAL_MASK_SHIFT) - 1))
#define __VIRTUAL_MASK ((1UL << __VIRTUAL_MASK_SHIFT) - 1)
/* Cast PAGE_MASK to a signed type so that it is sign-extended if
^ permalink raw reply related
* Re: [PATCH] CHROMIUM: i915: Initialize panel timing registers if VBIOS did not.
From: Jesse Barnes @ 2010-10-07 23:52 UTC (permalink / raw)
To: Bryan Freed; +Cc: intel-gfx, Mandeep Baines, Olof Johansson
In-Reply-To: <AANLkTimrOpY7n9Hi3NRKZVPekg1gNxLLxr1di_cMvf9J@mail.gmail.com>
I don't think 0 is a reasonable value for any of those fields, so
checking them against 0 should be fine.
Jesse
On Thu, 7 Oct 2010 16:48:51 -0700
Bryan Freed <bfreed@chromium.org> wrote:
> My change tries to detect the lack of initialization by A) finding no VBT,
> and B) finding 0 values in these registers.
>
> But what if there is a VBIOS out there that really wants these values to be
> 0? I provide for that case by checking for VBT.
>
> Is this a reasonable case? If not, I have no problem moving the check
> to init_vbt_default().
>
> bryan.
>
> On Thu, Oct 7, 2010 at 3:55 PM, Chris Wilson <chris@chris-wilson.co.uk>wrote:
>
> > On Thu, 7 Oct 2010 15:48:14 -0700, Bryan Freed <bfreed@chromium.org>
> > wrote:
> > > The time between start of the pixel clock and backlight enable is a basic
> > > panel timing constraint. If no VBIOS Table is found, and the Panel Power
> > > On/Off registers are found to be 0, assume we are booting without VBIOS
> > > initialization and set these registers to something reasonable.
> >
> > IIRC, the panel sequence registers are meant to be stored in the VBIOS. So
> > if we add the parsing of those to the driver and add the defaults to
> > init_vbt_default() then we can check whether PP_ON_DELAYS is valid upon
> > device init (module load and resume) and fixup in case the BIOS does not.
> > -Chris
> >
> > --
> > Chris Wilson, Intel Open Source Technology Centre
> >
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* [PATCH 6/6] rtc: rtc-s3c: Add rtc_valid_tm in s3c_rtc_gettime()
From: Kukjin Kim @ 2010-10-07 23:41 UTC (permalink / raw)
To: linux-arm-kernel, linux-samsung-soc, rtc-linux
Cc: ben-linux, p_gortmaker, a.zummo, akpm, Kukjin Kim
In-Reply-To: <1286494879-2932-1-git-send-email-kgene.kim@samsung.com>
This patch adds "rtc_valid_tm" in s3c_rtc_gettime()
as per Wan ZongShun's suggestion.
Suggested-by: Wan ZongShun <mcuos.com@gmail.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
drivers/rtc/rtc-s3c.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 51e7b25..7c7db81 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -185,7 +185,7 @@ static int s3c_rtc_gettime(struct device *dev, struct rtc_time *rtc_tm)
rtc_tm->tm_year += 100;
rtc_tm->tm_mon -= 1;
- return 0;
+ return rtc_valid_tm(rtc_tm);
}
static int s3c_rtc_settime(struct device *dev, struct rtc_time *tm)
--
1.6.2.5
^ permalink raw reply related
* [PATCH 4/6] rtc: rtc-s3c: Fix debug message format on RTC
From: Kukjin Kim @ 2010-10-07 23:41 UTC (permalink / raw)
To: linux-arm-kernel, linux-samsung-soc, rtc-linux
Cc: ben-linux, p_gortmaker, a.zummo, akpm, Kukjin Kim
In-Reply-To: <1286494879-2932-1-git-send-email-kgene.kim@samsung.com>
This patch fixes debug message format on rtc-s3c.
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Ben Dooks <ben-linux@fluff.org>
---
drivers/rtc/rtc-s3c.c | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 39fa5b0..276b7c1 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -171,8 +171,8 @@ static int s3c_rtc_gettime(struct device *dev, struct rtc_time *rtc_tm)
goto retry_get_time;
}
- pr_debug("read time %02x.%02x.%02x %02x/%02x/%02x\n",
- rtc_tm->tm_year, rtc_tm->tm_mon, rtc_tm->tm_mday,
+ pr_debug("read time %04d.%02d.%02d %02d:%02d:%02d\n",
+ 1900 + rtc_tm->tm_year, rtc_tm->tm_mon, rtc_tm->tm_mday,
rtc_tm->tm_hour, rtc_tm->tm_min, rtc_tm->tm_sec);
rtc_tm->tm_sec = bcd2bin(rtc_tm->tm_sec);
@@ -193,8 +193,8 @@ static int s3c_rtc_settime(struct device *dev, struct rtc_time *tm)
void __iomem *base = s3c_rtc_base;
int year = tm->tm_year - 100;
- pr_debug("set time %02d.%02d.%02d %02d/%02d/%02d\n",
- tm->tm_year, tm->tm_mon, tm->tm_mday,
+ pr_debug("set time %04d.%02d.%02d %02d:%02d:%02d\n",
+ 1900 + tm->tm_year, tm->tm_mon, tm->tm_mday,
tm->tm_hour, tm->tm_min, tm->tm_sec);
/* we get around y2k by simply not supporting it */
@@ -231,9 +231,9 @@ static int s3c_rtc_getalarm(struct device *dev, struct rtc_wkalrm *alrm)
alrm->enabled = (alm_en & S3C2410_RTCALM_ALMEN) ? 1 : 0;
- pr_debug("read alarm %02x %02x.%02x.%02x %02x/%02x/%02x\n",
+ pr_debug("read alarm %d, %04d.%02d.%02d %02d:%02d:%02d\n",
alm_en,
- alm_tm->tm_year, alm_tm->tm_mon, alm_tm->tm_mday,
+ 1900 + alm_tm->tm_year, alm_tm->tm_mon, alm_tm->tm_mday,
alm_tm->tm_hour, alm_tm->tm_min, alm_tm->tm_sec);
@@ -280,10 +280,10 @@ static int s3c_rtc_setalarm(struct device *dev, struct rtc_wkalrm *alrm)
void __iomem *base = s3c_rtc_base;
unsigned int alrm_en;
- pr_debug("s3c_rtc_setalarm: %d, %02x/%02x/%02x %02x.%02x.%02x\n",
+ pr_debug("s3c_rtc_setalarm: %d, %04d.%02d.%02d %02d:%02d:%02d\n",
alrm->enabled,
- tm->tm_mday & 0xff, tm->tm_mon & 0xff, tm->tm_year & 0xff,
- tm->tm_hour & 0xff, tm->tm_min & 0xff, tm->tm_sec);
+ 1900 + tm->tm_year, tm->tm_mon, tm->tm_mday,
+ tm->tm_hour, tm->tm_min, tm->tm_sec);
alrm_en = readb(base + S3C2410_RTCALM) & S3C2410_RTCALM_ALMEN;
--
1.6.2.5
^ permalink raw reply related
* [PATCH 1/6] rtc: rtc-s3c: Fix access unit from byte to word on RTCCON
From: Kukjin Kim @ 2010-10-07 23:41 UTC (permalink / raw)
To: linux-arm-kernel, linux-samsung-soc, rtc-linux
Cc: ben-linux, p_gortmaker, a.zummo, akpm, Changhwan Youn, Kukjin Kim
In-Reply-To: <1286494879-2932-1-git-send-email-kgene.kim@samsung.com>
From: Changhwan Youn <chaos.youn@samsung.com>
S3C2410_RTCCON of TYPE_S3C64XX RTC should be read/written by
readw and writew, because TYPE_S3C64XX RTC uses bit 8 and 9.
And TYPE_S3C2410 RTC also can access it by readw and writew.
Signed-off-by: Changhwan Youn <chaos.youn@samsung.com>
[atul.dahiya@samsung.com: tested on smdk2416]
Tested-by: Atul Dahiya <atul.dahiya@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
drivers/rtc/rtc-s3c.c | 36 ++++++++++++++++++------------------
1 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index f57a87f..4a0b875 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -100,7 +100,7 @@ static int s3c_rtc_setpie(struct device *dev, int enabled)
spin_lock_irq(&s3c_rtc_pie_lock);
if (s3c_rtc_cpu_type == TYPE_S3C64XX) {
- tmp = readb(s3c_rtc_base + S3C2410_RTCCON);
+ tmp = readw(s3c_rtc_base + S3C2410_RTCCON);
tmp &= ~S3C64XX_RTCCON_TICEN;
if (enabled)
@@ -318,7 +318,7 @@ static int s3c_rtc_proc(struct device *dev, struct seq_file *seq)
unsigned int ticnt;
if (s3c_rtc_cpu_type == TYPE_S3C64XX) {
- ticnt = readb(s3c_rtc_base + S3C2410_RTCCON);
+ ticnt = readw(s3c_rtc_base + S3C2410_RTCCON);
ticnt &= S3C64XX_RTCCON_TICEN;
} else {
ticnt = readb(s3c_rtc_base + S3C2410_TICNT);
@@ -391,11 +391,11 @@ static void s3c_rtc_enable(struct platform_device *pdev, int en)
return;
if (!en) {
- tmp = readb(base + S3C2410_RTCCON);
+ tmp = readw(base + S3C2410_RTCCON);
if (s3c_rtc_cpu_type == TYPE_S3C64XX)
tmp &= ~S3C64XX_RTCCON_TICEN;
tmp &= ~S3C2410_RTCCON_RTCEN;
- writeb(tmp, base + S3C2410_RTCCON);
+ writew(tmp, base + S3C2410_RTCCON);
if (s3c_rtc_cpu_type == TYPE_S3C2410) {
tmp = readb(base + S3C2410_TICNT);
@@ -405,25 +405,25 @@ static void s3c_rtc_enable(struct platform_device *pdev, int en)
} else {
/* re-enable the device, and check it is ok */
- if ((readb(base+S3C2410_RTCCON) & S3C2410_RTCCON_RTCEN) == 0){
+ if ((readw(base+S3C2410_RTCCON) & S3C2410_RTCCON_RTCEN) == 0){
dev_info(&pdev->dev, "rtc disabled, re-enabling\n");
- tmp = readb(base + S3C2410_RTCCON);
- writeb(tmp|S3C2410_RTCCON_RTCEN, base+S3C2410_RTCCON);
+ tmp = readw(base + S3C2410_RTCCON);
+ writew(tmp|S3C2410_RTCCON_RTCEN, base+S3C2410_RTCCON);
}
- if ((readb(base + S3C2410_RTCCON) & S3C2410_RTCCON_CNTSEL)){
+ if ((readw(base + S3C2410_RTCCON) & S3C2410_RTCCON_CNTSEL)){
dev_info(&pdev->dev, "removing RTCCON_CNTSEL\n");
- tmp = readb(base + S3C2410_RTCCON);
- writeb(tmp& ~S3C2410_RTCCON_CNTSEL, base+S3C2410_RTCCON);
+ tmp = readw(base + S3C2410_RTCCON);
+ writew(tmp& ~S3C2410_RTCCON_CNTSEL, base+S3C2410_RTCCON);
}
- if ((readb(base + S3C2410_RTCCON) & S3C2410_RTCCON_CLKRST)){
+ if ((readw(base + S3C2410_RTCCON) & S3C2410_RTCCON_CLKRST)){
dev_info(&pdev->dev, "removing RTCCON_CLKRST\n");
- tmp = readb(base + S3C2410_RTCCON);
- writeb(tmp & ~S3C2410_RTCCON_CLKRST, base+S3C2410_RTCCON);
+ tmp = readw(base + S3C2410_RTCCON);
+ writew(tmp & ~S3C2410_RTCCON_CLKRST, base+S3C2410_RTCCON);
}
}
}
@@ -514,8 +514,8 @@ static int __devinit s3c_rtc_probe(struct platform_device *pdev)
s3c_rtc_enable(pdev, 1);
- pr_debug("s3c2410_rtc: RTCCON=%02x\n",
- readb(s3c_rtc_base + S3C2410_RTCCON));
+ pr_debug("s3c2410_rtc: RTCCON=%02x\n",
+ readw(s3c_rtc_base + S3C2410_RTCCON));
device_init_wakeup(&pdev->dev, 1);
@@ -578,7 +578,7 @@ static int s3c_rtc_suspend(struct platform_device *pdev, pm_message_t state)
/* save TICNT for anyone using periodic interrupts */
ticnt_save = readb(s3c_rtc_base + S3C2410_TICNT);
if (s3c_rtc_cpu_type == TYPE_S3C64XX) {
- ticnt_en_save = readb(s3c_rtc_base + S3C2410_RTCCON);
+ ticnt_en_save = readw(s3c_rtc_base + S3C2410_RTCCON);
ticnt_en_save &= S3C64XX_RTCCON_TICEN;
}
s3c_rtc_enable(pdev, 0);
@@ -596,8 +596,8 @@ static int s3c_rtc_resume(struct platform_device *pdev)
s3c_rtc_enable(pdev, 1);
writeb(ticnt_save, s3c_rtc_base + S3C2410_TICNT);
if (s3c_rtc_cpu_type == TYPE_S3C64XX && ticnt_en_save) {
- tmp = readb(s3c_rtc_base + S3C2410_RTCCON);
- writeb(tmp | ticnt_en_save, s3c_rtc_base + S3C2410_RTCCON);
+ tmp = readw(s3c_rtc_base + S3C2410_RTCCON);
+ writew(tmp | ticnt_en_save, s3c_rtc_base + S3C2410_RTCCON);
}
if (device_may_wakeup(&pdev->dev))
--
1.6.2.5
^ permalink raw reply related
* [PATCH RE-SEND 0/6] rtc: rtc-s3c: Fix rtc-s3c
From: Kukjin Kim @ 2010-10-07 23:41 UTC (permalink / raw)
To: linux-arm-kernel, linux-samsung-soc, rtc-linux
Cc: ben-linux, p_gortmaker, a.zummo, akpm
This patches already have been submitted regarding mailing list.
Now...I'm re-sending this for handling by Andrew Morton.
Thanks.
[PATCH 1/6] rtc: rtc-s3c: Fix access unit from byte to word on RTCCON
[PATCH 2/6] rtc: rtc-s3c: Fix setting missing field of getalarm
[PATCH 3/6] rtc: rtc-s3c: Fix on support RTC Alarm
[PATCH 4/6] rtc: rtc-s3c: Fix debug message format on RTC
[PATCH 5/6] rtc: rtc-s3c: Fix on RTC initialization method
[PATCH 6/6] rtc: rtc-s3c: Add rtc_valid_tm in s3c_rtc_gettime()
^ permalink raw reply
* [PATCH 5/6] rtc: rtc-s3c: Fix on RTC initialization method
From: Kukjin Kim @ 2010-10-07 23:41 UTC (permalink / raw)
To: linux-arm-kernel, linux-samsung-soc, rtc-linux
Cc: ben-linux, p_gortmaker, a.zummo, akpm, Changhwan Youn, Kukjin Kim
In-Reply-To: <1286494879-2932-1-git-send-email-kgene.kim@samsung.com>
From: Changhwan Youn <chaos.youn@samsung.com>
This patch changes RTC initialization method on probe(). The
'rtc_valid_tm(tm)' can check whether RTC BCD is valid or not.
And should be changed the method of check because previous
method cannot validate RTC BCD registers properly.
Signed-off-by: Changhwan Youn <chaos.youn@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
drivers/rtc/rtc-s3c.c | 18 +++++++++++++-----
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 276b7c1..51e7b25 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -453,8 +453,8 @@ static int __devexit s3c_rtc_remove(struct platform_device *dev)
static int __devinit s3c_rtc_probe(struct platform_device *pdev)
{
struct rtc_device *rtc;
+ struct rtc_time rtc_tm;
struct resource *res;
- unsigned int tmp, i;
int ret;
pr_debug("%s: probe=%p\n", __func__, pdev);
@@ -535,11 +535,19 @@ static int __devinit s3c_rtc_probe(struct platform_device *pdev)
/* Check RTC Time */
- for (i = S3C2410_RTCSEC; i <= S3C2410_RTCYEAR; i += 0x4) {
- tmp = readb(s3c_rtc_base + i);
+ s3c_rtc_gettime(NULL, &rtc_tm);
- if ((tmp & 0xf) > 0x9 || ((tmp >> 4) & 0xf) > 0x9)
- writeb(0, s3c_rtc_base + i);
+ if (rtc_valid_tm(&rtc_tm)) {
+ rtc_tm.tm_year = 100;
+ rtc_tm.tm_mon = 0;
+ rtc_tm.tm_mday = 1;
+ rtc_tm.tm_hour = 0;
+ rtc_tm.tm_min = 0;
+ rtc_tm.tm_sec = 0;
+
+ s3c_rtc_settime(NULL, &rtc_tm);
+
+ dev_warn(&pdev->dev, "warning: invalid RTC value so initializing it\n");
}
if (s3c_rtc_cpu_type == TYPE_S3C64XX)
--
1.6.2.5
^ permalink raw reply related
* [PATCH 3/6] rtc: rtc-s3c: Fix on support RTC Alarm
From: Kukjin Kim @ 2010-10-07 23:41 UTC (permalink / raw)
To: linux-arm-kernel, linux-samsung-soc, rtc-linux
Cc: ben-linux, p_gortmaker, a.zummo, akpm, Changhwan Youn, Kukjin Kim
In-Reply-To: <1286494879-2932-1-git-send-email-kgene.kim@samsung.com>
From: Changhwan Youn <chaos.youn@samsung.com>
The alarm_irq_enable function should be implemented to support RTC alarm.
And fixes tab instead of white space abound proc field.
Signed-off-by: Changhwan Youn <chaos.youn@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Ben Dooks <ben-linux@fluff.org>
---
drivers/rtc/rtc-s3c.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index fd08876..39fa5b0 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -379,7 +379,8 @@ static const struct rtc_class_ops s3c_rtcops = {
.set_alarm = s3c_rtc_setalarm,
.irq_set_freq = s3c_rtc_setfreq,
.irq_set_state = s3c_rtc_setpie,
- .proc = s3c_rtc_proc,
+ .proc = s3c_rtc_proc,
+ .alarm_irq_enable = s3c_rtc_setaie,
};
static void s3c_rtc_enable(struct platform_device *pdev, int en)
--
1.6.2.5
^ permalink raw reply related
* [PATCH 2/6] rtc: rtc-s3c: Fix setting missing field of getalarm
From: Kukjin Kim @ 2010-10-07 23:41 UTC (permalink / raw)
To: linux-arm-kernel, linux-samsung-soc, rtc-linux
Cc: ben-linux, p_gortmaker, a.zummo, akpm, Changhwan Youn, Kukjin Kim
In-Reply-To: <1286494879-2932-1-git-send-email-kgene.kim@samsung.com>
From: Changhwan Youn <chaos.youn@samsung.com>
Current s3c_rtc_getalarm() sets missing field of alarm time with 0xff.
But this value should be -1 according to drivers/rtc/interface.c.
Signed-off-by: Changhwan Youn <chaos.youn@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Ben Dooks <ben-linux@fluff.org>
---
drivers/rtc/rtc-s3c.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 4a0b875..fd08876 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -242,34 +242,34 @@ static int s3c_rtc_getalarm(struct device *dev, struct rtc_wkalrm *alrm)
if (alm_en & S3C2410_RTCALM_SECEN)
alm_tm->tm_sec = bcd2bin(alm_tm->tm_sec);
else
- alm_tm->tm_sec = 0xff;
+ alm_tm->tm_sec = -1;
if (alm_en & S3C2410_RTCALM_MINEN)
alm_tm->tm_min = bcd2bin(alm_tm->tm_min);
else
- alm_tm->tm_min = 0xff;
+ alm_tm->tm_min = -1;
if (alm_en & S3C2410_RTCALM_HOUREN)
alm_tm->tm_hour = bcd2bin(alm_tm->tm_hour);
else
- alm_tm->tm_hour = 0xff;
+ alm_tm->tm_hour = -1;
if (alm_en & S3C2410_RTCALM_DAYEN)
alm_tm->tm_mday = bcd2bin(alm_tm->tm_mday);
else
- alm_tm->tm_mday = 0xff;
+ alm_tm->tm_mday = -1;
if (alm_en & S3C2410_RTCALM_MONEN) {
alm_tm->tm_mon = bcd2bin(alm_tm->tm_mon);
alm_tm->tm_mon -= 1;
} else {
- alm_tm->tm_mon = 0xff;
+ alm_tm->tm_mon = -1;
}
if (alm_en & S3C2410_RTCALM_YEAREN)
alm_tm->tm_year = bcd2bin(alm_tm->tm_year);
else
- alm_tm->tm_year = 0xffff;
+ alm_tm->tm_year = -1;
return 0;
}
--
1.6.2.5
^ permalink raw reply related
* Strange raid device numbering
From: J.A. Magallón @ 2010-10-07 23:43 UTC (permalink / raw)
To: Linux Kernel
Hi...
I'm running kernel 2.6.36-rc6.
I have just built a simple raid0 array with two disks, and I followed what I
had always done:
raid=/dev/md0
ndisk=2
disks="/dev/sda1 /dev/sdb1"
block=4
chunk=256
stride=$((chunk/block))
stripe=$((stride*ndisk))
for i in $disks
do
mdadm --zero-superblock --force $i
done
mdadm -C -f -v $raid --level=0 --chunk=$chunk -n $ndisk $disks
sleep 5
mdadm -S $raid
mdadm --assemble $raid $disks
mkfs.ext4 -b $((block*1024)) -E stride=$stride,stripe-width=$stripe $raid
Strangely, after I reboot, the system insists in numbering it as
md127, instead of md0.
Why ?
How can I force it to be md0 ? (its half aesthetics, half curiosity...)
TIA
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
^ permalink raw reply
* Re: [PATCH] ehea: simplify conditional
From: Breno Leitao @ 2010-10-07 23:49 UTC (permalink / raw)
To: Nicolas Kaiser; +Cc: netdev, linux-kernel
In-Reply-To: <20101008011450.0126ffc0@absol.kitzblitz>
On 10/07/2010 08:14 PM, Nicolas Kaiser wrote:
> Simplify: ((a&& b) || (!a&& !b)) => (a == b)
>
> Signed-off-by: Nicolas Kaiser<nikai@nikai.net>
Acked-by: Breno Leitao <leitao@linux.vnet.ibm.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.