Re: [PATCH] Staging: olpc_dcon: more big endian conformity
> > What happened to patch 1/3, I never got that. > You never got it, okay I'll resend it to you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/12] edma: Add support for SG lists of any length
Following offline discussions with Sekhar, we discussed some ideas to change a few things in this patch series to make it fail-safe. As such, the only changes we are making for v4 will be to not cyclically link immediately but doing so only once the ISR has finished setup (apart from other style cleanups). Any conditions where we are not able to modify the link in time (due to heavily loaded system) will be detected and reported by the use of linking to a NULL set. The new approach will be fast because of no requirement to stall or wait, and any DMA issues with heavily loaded systems can be detected as error conditions. This should architecturally be the final version of the patch series to add DMA support for SG lists of any length. Thanks, -Joel On 08/05/2013 11:14 AM, Joel Fernandes wrote: > Here is a more improved approach for DMA support of SG lists of any length > in the EDMA DMA Engine driver. > > In the previous approach [1] we depended on error interrupts to detect > missed events and manually retrigger them, however as discussed in [2], > there are concerns this can be trouble some for high speed peripherals > which may need a more real-time response from the DMA controller. > > In this approach, we divide the total no of MAX slots per channel, into > 2 linked sets which are cyclically linked to each other (the cyclic > link between the 2 sets make sure that the DMA is continuous till the whole > SG list has exhausted). We then enable completion interrupts on both linked > sets which results in recyling/preparing respective linked set with the > next set of SG entries. The interrupt handler executes in parallel while > the EDMA controller DMA's the next list. This results in no interruption. > > Special handling is done for first linked set (as we set up both linked > sets initially before starting with the DMA), and last one where the cyclic > link has to be broken and a link to the Dummy slot has to be created. > Also we keep track of whether all pending DMA operations have completed > before we can mark it as complete. > > [1] https://lkml.org/lkml/2013/7/29/312 > [2] https://lkml.org/lkml/2013/7/30/54 > > Joel Fernandes (12): > dma: edma: Setup parameters to DMA MAX_NR_SG at a time > ARM: edma: Don't clear EMR of channel in edma_stop > dma: edma: remove limits on number of slots > dma: edma: Write out and handle MAX_NR_SG at a given time > ARM: edma: Add function to enable interrupt for a PaRAM slot > ARM: edma: Add pr_debug in edma_link > dma: edma: Add function to dump a PaRAM set from PaRAM > dma: edma: Add one more required slot to MAX slots > dma: edma: Implement multiple linked sets for continuity > dma: edma: Check if MAX_NR_SG is even in prep function > dma: edma: Keep tracking of Pending interrupts (pending_acks) > dma: edma: Return if nothing left todo in edma_execute > > arch/arm/common/edma.c | 18 ++- > drivers/dma/edma.c | 279 > +--- > include/linux/platform_data/edma.h |1 + > 3 files changed, 243 insertions(+), 55 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v2 1/3] net/usb/r8152: support aggregation
hayeswang : > Francois Romieu [mailto:rom...@fr.zoreil.com] [...] > > The forward declaration is not needed. > > The r8152_submit_rx() need the declaration of read_bulk_callback(), and the > read_bulk_callback() need the declaration of r8152_submit_rx(), too. It likes > a dead lock, so I have no idea how to do it without another declaration. Ok, send me a brain for Xmas. [...] > > How is it related to the subject of the patch ? > > When link down, the driver would cancel all bulks. This avoid the > re-submitting > bulk. It's quite orthogonal to aggregation and could thus had been done in its own patch for readability sake. [...] > > It should be possible to retrieve more items in the spinlocked section > > so as to have a chance to batch more work. I have not thought > > too deeply > > about it. > > I only lock when I want to remove or inser the agg list, and unlock as soon as > possible. I don't think I keep locking for a long time. Sure. It doesn't make a difference if tp->rx_done doesn't grow much. Thanks. -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] at91: fixes for 3.11 #1
On Wed, Aug 14, 2013 at 10:33:33AM +0200, Nicolas Ferre wrote: > Arnd, Olof, Kevin, > > This is the first (late) fixes pull-reqest for AT91. I would understand if > you refuse it because we are already at -rc5 ;-) ... > > On the other hand, the line count is very low and all patches are pretty > obvious. Thanks, pulled and will be sent up for 3.11. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On Thu, Aug 15, 2013 at 01:46:16PM +0400, Max Filippov wrote: > Yes, xtensa compiler/linker is known to have issues with link-time > relaxation; e.g. it may fail to build linux image without CONFIG_LD_NO_RELAX. Is there something I can do at linker build time to help with this? Yours Tony pgpfaHO3TmWlK.pgp Description: PGP signature
Re: Linux kernel cross-compilers
On Thu, Aug 15, 2013 at 02:07:05AM -0700, Guenter Roeck wrote: > Hi Tony, > > would it be possible to provide an arm64 cross-compiler on > https://www.kernel.org/pub/tools/crosstool/ ? I have one built I just need to upload it. I'll try and do it this weekend. > Also, the xtensa compiler fails for me with an odd error message on one of my > servers. > Have you heard about any problems with it from others ? Nope. Sorry, but it looks like you're being looked after there. > c6x is supposed to be supported by gcc now. No idea if that helps anything, > though. Thanks. I have tried to build a 4.8.1 cx6 toolchain but It hasn't worked todate. I'll keep trying as time permits. > > Thanks, > Guenter > Yours Tony pgpbYYVRdMEZ2.pgp Description: PGP signature
[PATCH] workqueue: Fix manage_workers() RETURNS description
No functional change. The comment of function manage_workers()
RETURNS description is obvious wrong, same as the CONTEXT.
Fix it.
Signed-off-by: Libin
---
kernel/workqueue.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 7f5d4be..e8ee7a4 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -2033,8 +2033,8 @@ static bool maybe_destroy_workers(struct worker_pool
*pool)
* multiple times. Does GFP_KERNEL allocations.
*
* RETURNS:
- * spin_lock_irq(pool->lock) which may be released and regrabbed
- * multiple times. Does GFP_KERNEL allocations.
+ * %false if the poll don't need management and the caller can safely
+ * start processing works, %true otherwise.
*/
static bool manage_workers(struct worker *worker)
{
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] workqueue: Correct/Drop references to gcwq in Documentation
No functional changes. This patch fixes the post gcwq comments in Documentation/workqueue.txt. Signed-off-by: Libin --- Documentation/workqueue.txt | 60 ++--- 1 file changed, 29 insertions(+), 31 deletions(-) diff --git a/Documentation/workqueue.txt b/Documentation/workqueue.txt index a6ab4b6..64adaaf 100644 --- a/Documentation/workqueue.txt +++ b/Documentation/workqueue.txt @@ -85,16 +85,15 @@ workqueue. Special purpose threads, called worker threads, execute the functions off of the queue, one after the other. If no work is queued, the worker threads become idle. These worker threads are managed in so -called thread-pools. +called worker-pools. The cmwq design differentiates between the user-facing workqueues that subsystems and drivers queue work items on and the backend mechanism -which manages thread-pools and processes the queued work items. +which manages worker-pools and processes the queued work items. -The backend is called gcwq. There is one gcwq for each possible CPU -and one gcwq to serve work items queued on unbound workqueues. Each -gcwq has two thread-pools - one for normal work items and the other -for high priority ones. +There are two worker-pools, one for normal work items and the other +for high priority ones, for each possible CPU and two worker-pools +to serve work items queued on unbound workqueues. Subsystems and drivers can create and queue work items through special workqueue API functions as they see fit. They can influence some @@ -104,13 +103,12 @@ things like CPU locality, reentrancy, concurrency limits, priority and more. To get a detailed overview refer to the API description of alloc_workqueue() below. -When a work item is queued to a workqueue, the target gcwq and -thread-pool is determined according to the queue parameters and -workqueue attributes and appended on the shared worklist of the -thread-pool. For example, unless specifically overridden, a work item -of a bound workqueue will be queued on the worklist of either normal -or highpri thread-pool of the gcwq that is associated to the CPU the -issuer is running on. +When a work item is queued to a workqueue, the target worker-pool is +determined according to the queue parameters and workqueue attributes +and appended on the shared worklist of the worker-pool. For example, +unless specifically overridden, a work item of a bound workqueue will +be queued on the worklist of either normal or highpri worker-pool that +is associated to the CPU the issuer is running on. For any worker pool implementation, managing the concurrency level (how many execution contexts are active) is an important issue. cmwq @@ -118,14 +116,14 @@ tries to keep the concurrency at a minimal but sufficient level. Minimal to save resources and sufficient in that the system is used at its full capacity. -Each thread-pool bound to an actual CPU implements concurrency -management by hooking into the scheduler. The thread-pool is notified +Each worker-pool bound to an actual CPU implements concurrency +management by hooking into the scheduler. The worker-pool is notified whenever an active worker wakes up or sleeps and keeps track of the number of the currently runnable workers. Generally, work items are not expected to hog a CPU and consume many cycles. That means maintaining just enough concurrency to prevent work processing from stalling should be optimal. As long as there are one or more runnable -workers on the CPU, the thread-pool doesn't start execution of a new +workers on the CPU, the worker-pool doesn't start execution of a new work, but, when the last running worker goes to sleep, it immediately schedules a new worker so that the CPU doesn't sit idle while there are pending work items. This allows using a minimal number of workers @@ -136,7 +134,7 @@ for kthreads, so cmwq holds onto idle ones for a while before killing them. For an unbound wq, the above concurrency management doesn't apply and -the thread-pools for the pseudo unbound CPU try to start executing all +the worker-pools for the pseudo unbound CPU try to start executing all work items as soon as possible. The responsibility of regulating concurrency level is on the users. There is also a flag to mark a bound wq to ignore the concurrency management. Please refer to the @@ -147,7 +145,7 @@ more execution contexts are necessary, which in turn is guaranteed through the use of rescue workers. All work items which might be used on code paths that handle memory reclaim are required to be queued on wq's that have a rescue-worker reserved for execution under memory -pressure. Else it is possible that the thread-pool deadlocks waiting +pressure. Else it is possible that the worker-pool deadlocks waiting for execution contexts to free up. @@ -178,13 +176,13 @@ resources, scheduled and executed. WQ_UNBOUND - Work items queued to an unbound wq are served by a
[PATCH] workqueue: Comment correction in file header
No functional change. There are two worker pools for each cpu in current implementation(one for normal work items and the other for high priority ones). Signed-off-by: Libin --- kernel/workqueue.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index e8ee7a4..904ec00 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -16,8 +16,9 @@ * * This is the generic async execution mechanism. Work items as are * executed in process context. The worker pool is shared and - * automatically managed. There is one worker pool for each CPU and - * one extra for works which are better served by workers which are + * automatically managed. There are two worker pools for each CPU(one + * for normal work items and the other for high priority ones) and + * two extra for works which are better served by workers which are * not bound to any specific CPU. * * Please read Documentation/workqueue.txt for details. -- 1.8.2.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] vhost_net: poll vhost queue after marking DMA is done
We used to poll vhost queue before making DMA is done, this is racy if vhost thread were waked up before marking DMA is done which can result the signal to be missed. Fix this by always poll the vhost thread before DMA is done. Signed-off-by: Jason Wang --- drivers/vhost/net.c |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index 70cab75..a035a89 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c @@ -308,6 +308,11 @@ static void vhost_zerocopy_callback(struct ubuf_info *ubuf, bool success) struct vhost_virtqueue *vq = ubufs->vq; int cnt = atomic_read(>kref.refcount); + /* set len to mark this desc buffers done DMA */ + vq->heads[ubuf->desc].len = success ? + VHOST_DMA_DONE_LEN : VHOST_DMA_FAILED_LEN; + vhost_net_ubuf_put(ubufs); + /* * Trigger polling thread if guest stopped submitting new buffers: * in this case, the refcount after decrement will eventually reach 1 @@ -318,10 +323,6 @@ static void vhost_zerocopy_callback(struct ubuf_info *ubuf, bool success) */ if (cnt <= 2 || !(cnt % 16)) vhost_poll_queue(>poll); - /* set len to mark this desc buffers done DMA */ - vq->heads[ubuf->desc].len = success ? - VHOST_DMA_DONE_LEN : VHOST_DMA_FAILED_LEN; - vhost_net_ubuf_put(ubufs); } /* Expects to be always run from workqueue - which acts as -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] vhost_net: determine whether or not to use zerocopy at one time
Currently, even if the packet length is smaller than VHOST_GOODCOPY_LEN, if
upend_idx != done_idx we still set zcopy_used to true and rollback this choice
later. This could be avoided by determine zerocopy once by checking all
conditions at one time before.
Signed-off-by: Jason Wang
---
drivers/vhost/net.c | 46 +++---
1 files changed, 19 insertions(+), 27 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 8a6dd0d..70cab75 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -404,43 +404,35 @@ static void handle_tx(struct vhost_net *net)
iov_length(nvq->hdr, s), hdr_size);
break;
}
- zcopy_used = zcopy && (len >= VHOST_GOODCOPY_LEN ||
- nvq->upend_idx != nvq->done_idx);
+
+ zcopy_used = zcopy && len >= VHOST_GOODCOPY_LEN
+ && nvq->upend_idx != nvq->done_idx
+ && vhost_net_tx_select_zcopy(net);
/* use msg_control to pass vhost zerocopy ubuf info to skb */
if (zcopy_used) {
+ struct ubuf_info *ubuf;
+ ubuf = nvq->ubuf_info + nvq->upend_idx;
+
vq->heads[nvq->upend_idx].id = head;
- if (!vhost_net_tx_select_zcopy(net) ||
- len < VHOST_GOODCOPY_LEN) {
- /* copy don't need to wait for DMA done */
- vq->heads[nvq->upend_idx].len =
- VHOST_DMA_DONE_LEN;
- msg.msg_control = NULL;
- msg.msg_controllen = 0;
- ubufs = NULL;
- } else {
- struct ubuf_info *ubuf;
- ubuf = nvq->ubuf_info + nvq->upend_idx;
-
- vq->heads[nvq->upend_idx].len =
- VHOST_DMA_IN_PROGRESS;
- ubuf->callback = vhost_zerocopy_callback;
- ubuf->ctx = nvq->ubufs;
- ubuf->desc = nvq->upend_idx;
- msg.msg_control = ubuf;
- msg.msg_controllen = sizeof(ubuf);
- ubufs = nvq->ubufs;
- kref_get(>kref);
- }
+ vq->heads[nvq->upend_idx].len = VHOST_DMA_IN_PROGRESS;
+ ubuf->callback = vhost_zerocopy_callback;
+ ubuf->ctx = nvq->ubufs;
+ ubuf->desc = nvq->upend_idx;
+ msg.msg_control = ubuf;
+ msg.msg_controllen = sizeof(ubuf);
+ ubufs = nvq->ubufs;
+ kref_get(>kref);
nvq->upend_idx = (nvq->upend_idx + 1) % UIO_MAXIOV;
- } else
+ } else {
msg.msg_control = NULL;
+ ubufs = NULL;
+ }
/* TODO: Check specific error and bomb out unless ENOBUFS? */
err = sock->ops->sendmsg(NULL, sock, , len);
if (unlikely(err < 0)) {
if (zcopy_used) {
- if (ubufs)
- vhost_net_ubuf_put(ubufs);
+ vhost_net_ubuf_put(ubufs);
nvq->upend_idx = ((unsigned)nvq->upend_idx - 1)
% UIO_MAXIOV;
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] vhost_net: use vhost_add_used_and_signal_n() in vhost_zerocopy_signal_used()
Switch to use vhost_add_used_and_signal_n() to avoid multiple calls to
vhost_add_used_and_signal(). With the patch we will call at most 2 times
(consider done_idx warp around) compared to N times w/o this patch.
Signed-off-by: Jason Wang
---
drivers/vhost/net.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 280ee66..8a6dd0d 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -281,7 +281,7 @@ static void vhost_zerocopy_signal_used(struct vhost_net
*net,
{
struct vhost_net_virtqueue *nvq =
container_of(vq, struct vhost_net_virtqueue, vq);
- int i;
+ int i, add;
int j = 0;
for (i = nvq->done_idx; i != nvq->upend_idx; i = (i + 1) % UIO_MAXIOV) {
@@ -289,14 +289,17 @@ static void vhost_zerocopy_signal_used(struct vhost_net
*net,
vhost_net_tx_err(net);
if (VHOST_DMA_IS_DONE(vq->heads[i].len)) {
vq->heads[i].len = VHOST_DMA_CLEAR_LEN;
- vhost_add_used_and_signal(vq->dev, vq,
- vq->heads[i].id, 0);
++j;
} else
break;
}
- if (j)
- nvq->done_idx = i;
+ while (j) {
+ add = min(UIO_MAXIOV - nvq->done_idx, j);
+ vhost_add_used_and_signal_n(vq->dev, vq,
+ >heads[nvq->done_idx], add);
+ nvq->done_idx = (nvq->done_idx + add) % UIO_MAXIOV;
+ j -= add;
+ }
}
static void vhost_zerocopy_callback(struct ubuf_info *ubuf, bool success)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] vhost_net: remove the max pending check
We used to limit the max pending DMAs to prevent guest from pinning too many
pages. But this could be removed since:
- We have the sk_wmem_alloc check in both tun/macvtap to do the same work
- This max pending check were almost useless since it was one done when there's
no new buffers coming from guest. Guest can easily exceeds the limitation.
- We've already check upend_idx != done_idx and switch to non zerocopy then. So
even if all vq->heads were used, we can still does the packet transmission.
So remove this check completely.
Signed-off-by: Jason Wang
---
drivers/vhost/net.c | 13 -
1 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index a035a89..ed3f165 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -38,8 +38,6 @@ MODULE_PARM_DESC(experimental_zcopytx, "Enable Zero Copy TX;"
* Using this limit prevents one virtqueue from starving others. */
#define VHOST_NET_WEIGHT 0x8
-/* MAX number of TX used buffers for outstanding zerocopy */
-#define VHOST_MAX_PEND 128
#define VHOST_GOODCOPY_LEN 256
/*
@@ -372,17 +370,6 @@ static void handle_tx(struct vhost_net *net)
break;
/* Nothing new? Wait for eventfd to tell us they refilled. */
if (head == vq->num) {
- int num_pends;
-
- /* If more outstanding DMAs, queue the work.
-* Handle upend_idx wrap around
-*/
- num_pends = likely(nvq->upend_idx >= nvq->done_idx) ?
- (nvq->upend_idx - nvq->done_idx) :
- (nvq->upend_idx + UIO_MAXIOV -
-nvq->done_idx);
- if (unlikely(num_pends > VHOST_MAX_PEND))
- break;
if (unlikely(vhost_enable_notify(>dev, vq))) {
vhost_disable_notify(>dev, vq);
continue;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] vhost: switch to use vhost_add_used_n()
Let vhost_add_used() to use vhost_add_used_n() to reduce the code duplication.
Signed-off-by: Jason Wang
---
drivers/vhost/vhost.c | 43 ++-
1 files changed, 2 insertions(+), 41 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index e58cf00..c479452 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1332,48 +1332,9 @@ EXPORT_SYMBOL_GPL(vhost_discard_vq_desc);
* want to notify the guest, using eventfd. */
int vhost_add_used(struct vhost_virtqueue *vq, unsigned int head, int len)
{
- struct vring_used_elem __user *used;
+ struct vring_used_elem heads = { head, len };
- /* The virtqueue contains a ring of used buffers. Get a pointer to the
-* next entry in that used ring. */
- used = >used->ring[vq->last_used_idx % vq->num];
- if (__put_user(head, >id)) {
- vq_err(vq, "Failed to write used id");
- return -EFAULT;
- }
- if (__put_user(len, >len)) {
- vq_err(vq, "Failed to write used len");
- return -EFAULT;
- }
- /* Make sure buffer is written before we update index. */
- smp_wmb();
- if (__put_user(vq->last_used_idx + 1, >used->idx)) {
- vq_err(vq, "Failed to increment used idx");
- return -EFAULT;
- }
- if (unlikely(vq->log_used)) {
- /* Make sure data is seen before log. */
- smp_wmb();
- /* Log used ring entry write. */
- log_write(vq->log_base,
- vq->log_addr +
- ((void __user *)used - (void __user *)vq->used),
- sizeof *used);
- /* Log used index update. */
- log_write(vq->log_base,
- vq->log_addr + offsetof(struct vring_used, idx),
- sizeof vq->used->idx);
- if (vq->log_ctx)
- eventfd_signal(vq->log_ctx, 1);
- }
- vq->last_used_idx++;
- /* If the driver never bothers to signal in a very long while,
-* used index might wrap around. If that happens, invalidate
-* signalled_used index we stored. TODO: make sure driver
-* signals at least once in 2^16 and remove this. */
- if (unlikely(vq->last_used_idx == vq->signalled_used))
- vq->signalled_used_valid = false;
- return 0;
+ return vhost_add_used_n(vq, , 1);
}
EXPORT_SYMBOL_GPL(vhost_add_used);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/6] vhost code cleanup and minor enhancement
Hi all: This series tries to unify and simplify vhost codes especially for zerocopy. Plase review. Thanks Jason Wang (6): vhost_net: make vhost_zerocopy_signal_used() returns void vhost_net: use vhost_add_used_and_signal_n() in vhost_zerocopy_signal_used() vhost: switch to use vhost_add_used_n() vhost_net: determine whether or not to use zerocopy at one time vhost_net: poll vhost queue after marking DMA is done vhost_net: remove the max pending check drivers/vhost/net.c | 86 +++- drivers/vhost/vhost.c | 43 +--- 2 files changed, 36 insertions(+), 93 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] vhost_net: make vhost_zerocopy_signal_used() returns void
None of its caller use its return value, so let it return void.
Signed-off-by: Jason Wang
---
drivers/vhost/net.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 969a859..280ee66 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -276,8 +276,8 @@ static void copy_iovec_hdr(const struct iovec *from, struct
iovec *to,
* of used idx. Once lower device DMA done contiguously, we will signal KVM
* guest used idx.
*/
-static int vhost_zerocopy_signal_used(struct vhost_net *net,
- struct vhost_virtqueue *vq)
+static void vhost_zerocopy_signal_used(struct vhost_net *net,
+ struct vhost_virtqueue *vq)
{
struct vhost_net_virtqueue *nvq =
container_of(vq, struct vhost_net_virtqueue, vq);
@@ -297,7 +297,6 @@ static int vhost_zerocopy_signal_used(struct vhost_net *net,
}
if (j)
nvq->done_idx = i;
- return j;
}
static void vhost_zerocopy_callback(struct ubuf_info *ubuf, bool success)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm: omap5: dts: split SMPS10 dt node
Hi Benoit, On Tuesday 13 August 2013 08:18 PM, Benoit Cousson wrote: > On 13/08/2013 16:45, Kishon Vijay Abraham I wrote: >> Hi, >> >> On Tuesday 13 August 2013 06:51 PM, Benoit Cousson wrote: >>> Hi Kishon, >>> >>> On 12/08/2013 11:37, Kishon Vijay Abraham I wrote: SMPS10 has two outputs OUT1 and OUT2. Hence SMPS10 is modeled as two regulators. The dt node is split to reflect it. >>> >>> Mmm, I'm curious. How is it supposed to work? >>> >>> Do you have dedicated control on each output? >> >> Yes. It can be controlled by setting different values to the same bit fields. >> You can refer [1] where we actually implement SMPS10 as two different >> regulators. >> >> [1] -> http://permalink.gmane.org/gmane.linux.kernel/1542521 > > Great, thanks. > > Can we merge that one safely if the driver changed are not done yet? I think it shouldn't cause any issues. However Mark has already merged the driver changes. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/17] 3.4.58-stable review
On Thu, Aug 15, 2013 at 09:53:25PM -0700, Guenter Roeck wrote:
> On 08/15/2013 12:55 AM, Geert Uytterhoeven wrote:
> > On Thu, Aug 15, 2013 at 9:43 AM, Guenter Roeck wrote:
> >> I screwed up my stable repo clone again :(, so the full build will take a
> >> bit.
> >>
> >> mips builds on on 3.4 with all patches applied now fail with:
> >> arch/mips/include/asm/page.h: Assembler messages:
> >> arch/mips/include/asm/page.h:178: Error: Unrecognized opcode `static inline
> >> int pfn_valid(unsigned long pfn)'
> >> arch/mips/include/asm/page.h:179: Error: junk at end of line, first
> >> unrecognized character is `{'
> >> arch/mips/include/asm/page.h:181: Error: Unrecognized opcode `extern
> >> unsigned long max_mapnr'
> >> arch/mips/include/asm/page.h:183: Error: Unrecognized opcode `return
> >> pfn>=ARCH_PFN_OFFSET& >> arch/mips/include/asm/page.h:184: Error: junk at end of line, first
> >> unrecognized character is `}'
> >>
> >> This is the error I referred to above. Reverting above pfn rework patch
> >> fixes that problem,
> >> so you might want to remove that patch from the patch queue for now.
> >
> > Perhaps this one got applied too soon?
> >
> > commit 730b8dfe016dd1e91f73d8d3e6724da91397171c
> > Author: Ralf Baechle
> > Date: Fri Dec 28 15:18:02 2012 +0100
> >
> > MIPS: page.h: Remove now unnecessary #ifndef __ASSEMBLY__ wrapper.
> >
> > Signed-off-by: Ralf Baechle
> >
>
> Actually, you are on the right track, only in the opposite direction.
> The problem is that commit 8b9232141b changed
> #define pfn_valid ...
> to
> static inline pfn_valid()
> in arch/mips/include/asm/page.h. In the 3.4 kernel the file _is_
> still included from assembler code. This obviously doesn't work.
>
> Fix would be to surround the new static inline function with #ifndef
> __ASSEMBLY__.
> With this change, "mips allmodconfig" compiles with the 3.4 kernel.
> It should be a safe change, since the static inline will never be used
> from assembler code.
>
> Question is if that would be acceptable as back-port of 8b9232141b to 3.4.
> Greg, any comments ? If it is ok I can submit a back-port request with
> the modified patch to -stable. That would be one more build fixed,
> three to go (arm:allmodconfig, sparc32:defconfig, and sparc64:allmodconfig).
That sounds reasonable to me, as it is a valid fix, and I do know of
some MIPS people using 3.4 (although their versions all seem to be
heavily patched, perhaps for issues like this, I don't really know...)
So, feel free to send such a backport on to me.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] Ceph: Punch hole support for kernel client
I've applied this to the testing branch and moved to the better fsx in the
qa suite.
The ceph-fuse patches are still in wip-fallocate until I can run the fs
test suite against them.
Thanks!
sage
On Thu, 15 Aug 2013, Li Wang wrote:
> This patch implements fallocate and punch hole support for Ceph kernel client.
>
> Signed-off-by: Li Wang
> Signed-off-by: Yunchuan Wen
> ---
> Against v3:
>
> Passed the fsx test from xfstests.
>
> Truncate rather than delete the first object. Thanks go to Sage and Zheng for
> the explanation.
>
> Silence the OSD ENOENT complaints.
> ---
> fs/ceph/file.c| 196
> +
> net/ceph/osd_client.c | 11 ++-
> 2 files changed, 205 insertions(+), 2 deletions(-)
>
> diff --git a/fs/ceph/file.c b/fs/ceph/file.c
> index 2ddf061..e2bcd5c 100644
> --- a/fs/ceph/file.c
> +++ b/fs/ceph/file.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
>
> #include "super.h"
> #include "mds_client.h"
> @@ -871,6 +872,200 @@ out:
> return offset;
> }
>
> +static inline void ceph_zero_partial_page(
> + struct inode *inode, loff_t offset, unsigned size)
> +{
> + struct page *page;
> + pgoff_t index = offset >> PAGE_CACHE_SHIFT;
> +
> + page = find_lock_page(inode->i_mapping, index);
> + if (page) {
> + wait_on_page_writeback(page);
> + zero_user(page, offset & (PAGE_CACHE_SIZE - 1), size);
> + unlock_page(page);
> + page_cache_release(page);
> + }
> +}
> +
> +static void ceph_zero_pagecache_range(struct inode *inode, loff_t offset,
> + loff_t length)
> +{
> + loff_t nearly = round_up(offset, PAGE_CACHE_SIZE);
> + if (offset < nearly) {
> + loff_t size = nearly - offset;
> + if (length < size)
> + size = length;
> + ceph_zero_partial_page(inode, offset, size);
> + offset += size;
> + length -= size;
> + }
> + if (length >= PAGE_CACHE_SIZE) {
> + loff_t size = round_down(length, PAGE_CACHE_SIZE);
> + truncate_pagecache_range(inode, offset, offset + size - 1);
> + offset += size;
> + length -= size;
> + }
> + if (length)
> + ceph_zero_partial_page(inode, offset, length);
> +}
> +
> +static int ceph_zero_partial_object(struct inode *inode,
> + loff_t offset, loff_t *length)
> +{
> + struct ceph_inode_info *ci = ceph_inode(inode);
> + struct ceph_fs_client *fsc = ceph_inode_to_client(inode);
> + struct ceph_osd_request *req;
> + int ret = 0;
> + loff_t zero = 0;
> + int op;
> +
> + if (!length) {
> + op = offset ? CEPH_OSD_OP_DELETE : CEPH_OSD_OP_TRUNCATE;
> + length =
> + } else {
> + op = CEPH_OSD_OP_ZERO;
> + }
> +
> + req = ceph_osdc_new_request(>client->osdc, >i_layout,
> + ceph_vino(inode),
> + offset, length,
> + 1, op,
> + CEPH_OSD_FLAG_WRITE |
> + CEPH_OSD_FLAG_ONDISK,
> + NULL, 0, 0, false);
> + if (IS_ERR(req)) {
> + ret = PTR_ERR(req);
> + goto out;
> + }
> +
> + ceph_osdc_build_request(req, offset, NULL, ceph_vino(inode).snap,
> + >i_mtime);
> +
> + ret = ceph_osdc_start_request(>client->osdc, req, false);
> + if (!ret) {
> + ret = ceph_osdc_wait_request(>client->osdc, req);
> + if (ret == -ENOENT)
> + ret = 0;
> + }
> + ceph_osdc_put_request(req);
> +
> +out:
> + return ret;
> +}
> +
> +static int ceph_zero_objects(struct inode *inode, loff_t offset, loff_t
> length)
> +{
> + int ret = 0;
> + struct ceph_inode_info *ci = ceph_inode(inode);
> + __s32 stripe_unit = ceph_file_layout_su(ci->i_layout);
> + __s32 stripe_count = ceph_file_layout_stripe_count(ci->i_layout);
> + __s32 object_size = ceph_file_layout_object_size(ci->i_layout);
> + loff_t object_set_size = (loff_t)object_size * stripe_count;
> +
> + loff_t nearly = (offset + object_set_size - 1)
> + / object_set_size * object_set_size;
> + while (length && offset < nearly) {
> + loff_t size = length;
> + ret = ceph_zero_partial_object(inode, offset, );
> + if (ret < 0)
> + return ret;
> + offset += size;
> + length -= size;
> + }
> + while (length >= object_set_size) {
> + int i;
> + loff_t pos = offset;
> + for (i = 0; i < stripe_count; ++i) {
> + ret = ceph_zero_partial_object(inode, pos, NULL);
> + if (ret < 0)
>
Re: [PATCH v10] i2c: exynos5: add High Speed I2C controller driver
On 15 August 2013 18:42, Wolfram Sang wrote: > On Mon, Jul 01, 2013 at 12:25:19PM +0200, Tomasz Figa wrote: >> Hi Naveen, >> >> Looks mostly good, but see some comments inline. > > Ping? Hello Wolfram, I made a patch fixing your comments and from Thomas Figa as well. Meanwhile, we hit a random crash in exynos5_i2c_irq function. The "len" variable being is still being near the FIFO_MAX after this condition len = HSI2C_FIFO_MAX - fifo_level; + if (len > i2c->msg->len) + len = i2c->msg->len; Once, we fix this problem. i planned to rebase and submit. Is it okey with you? Thanks, Naveen > -- Shine bright, (: Nav :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 3/4] powerpc: refactor of_get_cpu_node to support other architectures
On Thu, 2013-08-15 at 18:09 +0100, Sudeep KarkadaNagesha wrote: >/* Check for ibm,ppc-interrupt-server#s. If it doesn't exist > * fallback to "reg" property and assume no threads > */ > - Oh and I forgot ... that comment is now wrong, since your code handles threads in the "reg" case... Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/5] zram/zsmalloc promotion
Hi Minchan, On Fri, Aug 16, 2013 at 12:26 PM, Minchan Kim wrote: > Hi Mel, > > On Thu, Aug 15, 2013 at 06:12:50PM +0100, Mel Gorman wrote: >> On Thu, Aug 15, 2013 at 03:58:20AM +0900, Minchan Kim wrote: >> > > >> > > >> > > I do not believe this is a problem for zram as such because I do not >> > > think it ever writes back to disk and is immune from the unpredictable >> > > performance characteristics problem. The problem for zram using zsmalloc >> > > is OOM killing. If it's used for swap then there is no guarantee that >> > > killing processes frees memory and that could result in an OOM storm. >> > > Of course there is no guarantee that memory is freed with zbud either but >> > > you are guaranteed that freeing 50%+1 of the compressed pages will free a >> > > single physical page. The characteristics for zsmalloc are much more >> > > severe. >> > > This might be managable in an applicance with very careful control of the >> > > applications that are running but not for general servers or desktops. >> > >> > Fair enough but let's think of current usecase for zram. >> > As I said in description, most of user for zram are embedded products. >> > So, most of them has no swap storage and hate OOM kill because OOM is >> > already very very slow path so system slow response is really thing >> > we want to avoid. We prefer early process kill to slow response. >> > That's why custom low memory killer/notifier is popular in embedded side. >> > so actually, OOM storm problem shouldn't be a big problem under >> > well-control limited system. >> > >> >> Which zswap could also do if >> >> a) it had a pseudo block device that failed all writes >> b) zsmalloc was pluggable >> >> I recognise this sucks because zram is already in the field but if zram >> is promoted then zram and zswap will continue to diverge further with no >> reconcilation in sight. >> >> Part of the point of using zswap was that potentially zcache could be >> implemented on top of it and so all file cache could be stored compressed >> in memory. AFAIK, it's not possible to do the same thing for zram because >> of the lack of writeback capabilities. Maybe it could be done if zram >> could be configured to write to an underlying storage device but it may >> be very clumsy to configure. I don't know as I never investigated it and >> to be honest, I'm struggling to remember how I got involved anywhere near >> zswap/zcache/zram/zwtf in the first place. >> >> > > If it's used for something like tmpfs then it becomes much worse. Normal >> > > tmpfs without swap can lockup if tmpfs is allowed to fill memory. In a >> > > sane configuration, lockups will be avoided and deleting a tmpfs file is >> > > guaranteed to free memory. When zram is used to back tmpfs, there is no >> > > guarantee that any memory is freed due to fragmentation of the compressed >> > > pages. The only way to recover the memory may be to kill applications >> > > holding tmpfs files open and then delete them which is fairly drastic >> > > action in a normal server environment. >> > >> > Indeed. >> > Actually, I had a plan to support zsmalloc compaction. The zsmalloc exposes >> > handle instead of pure pointer so it could migrate some zpages to somewhere >> > to pack in. Then, it could help above problem and OOM storm problem. >> > Anyway, it's a totally new feature and requires many changes and >> > experiement. >> > Although we don't have such feature, zram is still good for many people. >> > >> >> And is zsmalloc was pluggable for zswap then it would also benefit. > > But zswap isn't pseudo block device so it couldn't be used for block device. > Let say one usecase for using zram-blk. > But maybe we can make zswap creating some pseudo block devices. All data will be stored in zswap memory pool instead of real device. If zswap pool gets full, refuse to accept any new pages(no wirte back will happen). That's all the same as zram. In this case, zswap can be used to replace zram! > 1) Many embedded system don't have swap so although tmpfs can support swapout > it's pointless still so such systems should have sane configuration to limit > memory space so it's not only zram problem. > > 2) Many embedded system don't have enough memory. Let's assume short-lived > file growing up until half of system memory once in a while. We don't want > to write it on flash by wear-leveing issue and very slowness so we want to use > in-memory but if we uses tmpfs, it should evict half of working set to cover > them when the size reach peak. zram would be better choice. > >> >> > > These are the sort of reason why I feel that zram has limited cases where >> > > it is safe to use and zswap has a wider range of applications. At least >> > > I would be very unhappy to try supporting zram in the field for normal >> > > servers. zswap should be able to replace the functionality of zram+swap >> > > by backing zswap with a pseudo block device that rejects all writes. I >> > >> > One of difference between
Re: [RFC PATCH 3/4] powerpc: refactor of_get_cpu_node to support other architectures
On Thu, 2013-08-15 at 18:09 +0100, Sudeep KarkadaNagesha wrote:
> From: Sudeep KarkadaNagesha
>
> Currently different drivers requiring to access cpu device node are
> parsing the device tree themselves. Since the ordering in the DT need
> not match the logical cpu ordering, the parsing logic needs to consider
> that. However, this has resulted in lots of code duplication and in some
> cases even incorrect logic.
.../...
>
> +bool arch_match_cpu_phys_id(int cpu, u64 phys_id)
> +{
> + return (int)phys_id == get_hard_smp_processor_id(cpu);
> +}
Naming is a bit gross. You might want to make it clearer that
we are talking about CPU IDs in the device-tree here.
> +static bool __of_find_n_match_cpu_property(struct device_node *cpun,
> + const char *prop_name, int cpu, unsigned int *thread)
> +{
> + const __be32 *cell;
> + int ac, prop_len, tid;
> + u64 hwid;
> +
> + ac = of_n_addr_cells(cpun);
> + cell = of_get_property(cpun, prop_name, _len);
> + if (!cell)
> + return false;
> + prop_len /= sizeof(*cell);
> + for (tid = 0; tid < prop_len; tid++) {
> + hwid = of_read_number(cell, ac);
> + if (arch_match_cpu_phys_id(cpu, hwid)) {
> + if (thread)
> + *thread = tid;
> + return true;
> + }
Missing: cell += ac;
> + }
> + return false;
> +}
> +
> /* Find the device node for a given logical cpu number, also returns the cpu
> * local thread number (index in ibm,interrupt-server#s) if relevant and
> * asked for (non NULL)
> */
> struct device_node *of_get_cpu_node(int cpu, unsigned int *thread)
> {
> - int hardid;
> - struct device_node *np;
> + struct device_node *cpun, *cpus;
>
> - hardid = get_hard_smp_processor_id(cpu);
> + cpus = of_find_node_by_path("/cpus");
> + if (!cpus) {
> + pr_warn("Missing cpus node, bailing out\n");
> + return NULL;
> + }
>
> - for_each_node_by_type(np, "cpu") {
> - const u32 *intserv;
> - unsigned int plen, t;
> + for_each_child_of_node(cpus, cpun) {
> + if (of_node_cmp(cpun->type, "cpu"))
> + continue;
>
> /* Check for ibm,ppc-interrupt-server#s. If it doesn't exist
>* fallback to "reg" property and assume no threads
>*/
> - intserv = of_get_property(np, "ibm,ppc-interrupt-server#s",
> - );
> - if (intserv == NULL) {
> - const u32 *reg = of_get_property(np, "reg", NULL);
> - if (reg == NULL)
> - continue;
> - if (*reg == hardid) {
> - if (thread)
> - *thread = 0;
> - return np;
> - }
> - } else {
> - plen /= sizeof(u32);
> - for (t = 0; t < plen; t++) {
> - if (hardid == intserv[t]) {
> - if (thread)
> - *thread = t;
> - return np;
> - }
> - }
> - }
> + if (__of_find_n_match_cpu_property(cpun,
> + "ibm,ppc-interrupt-server#s", cpu, thread))
> + return cpun;
> +
> + if (__of_find_n_match_cpu_property(cpun, "reg", cpu, thread))
> + return cpun;
> }
> return NULL;
> }
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/17] 3.4.58-stable review
On 08/15/2013 12:55 AM, Geert Uytterhoeven wrote:
On Thu, Aug 15, 2013 at 9:43 AM, Guenter Roeck wrote:
I screwed up my stable repo clone again :(, so the full build will take a
bit.
mips builds on on 3.4 with all patches applied now fail with:
arch/mips/include/asm/page.h: Assembler messages:
arch/mips/include/asm/page.h:178: Error: Unrecognized opcode `static inline
int pfn_valid(unsigned long pfn)'
arch/mips/include/asm/page.h:179: Error: junk at end of line, first
unrecognized character is `{'
arch/mips/include/asm/page.h:181: Error: Unrecognized opcode `extern
unsigned long max_mapnr'
arch/mips/include/asm/page.h:183: Error: Unrecognized opcode `return
pfn>=ARCH_PFN_OFFSET&
Perhaps this one got applied too soon?
commit 730b8dfe016dd1e91f73d8d3e6724da91397171c
Author: Ralf Baechle
Date: Fri Dec 28 15:18:02 2012 +0100
MIPS: page.h: Remove now unnecessary #ifndef __ASSEMBLY__ wrapper.
Signed-off-by: Ralf Baechle
Actually, you are on the right track, only in the opposite direction.
The problem is that commit 8b9232141b changed
#define pfn_valid ...
to
static inline pfn_valid()
in arch/mips/include/asm/page.h. In the 3.4 kernel the file _is_
still included from assembler code. This obviously doesn't work.
Fix would be to surround the new static inline function with #ifndef
__ASSEMBLY__.
With this change, "mips allmodconfig" compiles with the 3.4 kernel.
It should be a safe change, since the static inline will never be used
from assembler code.
Question is if that would be acceptable as back-port of 8b9232141b to 3.4.
Greg, any comments ? If it is ok I can submit a back-port request with
the modified patch to -stable. That would be one more build fixed,
three to go (arm:allmodconfig, sparc32:defconfig, and sparc64:allmodconfig).
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: compaction: Do not compact pgdat for order-0
On Thu, Aug 15, 2013 at 04:39:27PM +0100, Mel Gorman wrote: > If kswapd was reclaiming for a high order and resets it to 0 due to > fragmentation it will still call compact_pgdat. For the most part, this will > fail a compaction_suitable() test and not compact but it is unnecessarily > sloppy. It could be fixed in the caller but fix it in the API instead. > > [dhi...@gmail.com: Pointed out that it was a potential problem] > Signed-off-by: Mel Gorman Acked-by: Minchan Kim -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/5] zram/zsmalloc promotion
Hi, On Fri, Aug 16, 2013 at 10:02:08AM +0800, Wanpeng Li wrote: > Hi Minchan, > On Thu, Aug 15, 2013 at 01:17:53AM +0900, Minchan Kim wrote: > >Hi Luigi, > > > >On Wed, Aug 14, 2013 at 08:53:31AM -0700, Luigi Semenzato wrote: > >> During earlier discussions of zswap there was a plan to make it work > >> with zsmalloc as an option instead of zbud. Does zbud work for > > > >AFAIR, it was not an optoin but zsmalloc was must but there were > >several objections because zswap's notable feature is to dump > >compressed object to real swap storage. For that, zswap needs to > >store bounded objects in a zpage so that dumping could be bounded, too. > >Otherwise, it could encounter OOM easily. > > > >> compression factors better than 2:1? I have the impression (maybe > >> wrong) that it does not. In our use of zram (Chrome OS) typical > > > >Since zswap changed allocator from zsmalloc to zbud, I didn't follow > >because I had no interest of low compressoin ratio allocator so > >I have no idea of status of zswap at a moment but I guess it would be > >still 2:1. > > > >> overall compression ratios are between 2.5:1 and 3:1. We would hate > >> to waste that memory if we switch to zswap. > > > >If you have real swap storage, zswap might be better although I have > >no number but real swap is money for embedded system and it has sudden > >garbage collection on firmware side if we use eMMC or SSD so that it > >could affect system latency. Morever, if we start to use real swap, > >maybe we should encrypt the data and it would be severe overhead(CPU > >and Power). > > > > Why real swap for embedded system need encrypt the data? I think there > is no encrypt for data against server and desktop. I have used some portable device but suddenly, I lost it or was stolen. A hacker can pick it up and read my swap and found my precious information. I don't want it. I guess it's one of reason ChromeOS don't want to use real swap. https://groups.google.com/a/chromium.org/forum/#!msg/chromium-os-discuss/92Fvi4Ezego/ZvbrC3L2FG4J > > >And what I am considering after promoting for zram feature is > >asynchronous I/O and it's possible because zram is block device. > > > >Thanks! > >-- > >Kind regards, > >Minchan Kim > > > >-- > >To unsubscribe, send a message with 'unsubscribe linux-mm' in > >the body to majord...@kvack.org. For more info on Linux MM, > >see: http://www.linux-mm.org/ . > >Don't email: mailto:"d...@kvack.org;> em...@kvack.org > -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/5] zram/zsmalloc promotion
Hi Mel, On Thu, Aug 15, 2013 at 06:12:50PM +0100, Mel Gorman wrote: > On Thu, Aug 15, 2013 at 03:58:20AM +0900, Minchan Kim wrote: > > > > > > > > > I do not believe this is a problem for zram as such because I do not > > > think it ever writes back to disk and is immune from the unpredictable > > > performance characteristics problem. The problem for zram using zsmalloc > > > is OOM killing. If it's used for swap then there is no guarantee that > > > killing processes frees memory and that could result in an OOM storm. > > > Of course there is no guarantee that memory is freed with zbud either but > > > you are guaranteed that freeing 50%+1 of the compressed pages will free a > > > single physical page. The characteristics for zsmalloc are much more > > > severe. > > > This might be managable in an applicance with very careful control of the > > > applications that are running but not for general servers or desktops. > > > > Fair enough but let's think of current usecase for zram. > > As I said in description, most of user for zram are embedded products. > > So, most of them has no swap storage and hate OOM kill because OOM is > > already very very slow path so system slow response is really thing > > we want to avoid. We prefer early process kill to slow response. > > That's why custom low memory killer/notifier is popular in embedded side. > > so actually, OOM storm problem shouldn't be a big problem under > > well-control limited system. > > > > Which zswap could also do if > > a) it had a pseudo block device that failed all writes > b) zsmalloc was pluggable > > I recognise this sucks because zram is already in the field but if zram > is promoted then zram and zswap will continue to diverge further with no > reconcilation in sight. > > Part of the point of using zswap was that potentially zcache could be > implemented on top of it and so all file cache could be stored compressed > in memory. AFAIK, it's not possible to do the same thing for zram because > of the lack of writeback capabilities. Maybe it could be done if zram > could be configured to write to an underlying storage device but it may > be very clumsy to configure. I don't know as I never investigated it and > to be honest, I'm struggling to remember how I got involved anywhere near > zswap/zcache/zram/zwtf in the first place. > > > > If it's used for something like tmpfs then it becomes much worse. Normal > > > tmpfs without swap can lockup if tmpfs is allowed to fill memory. In a > > > sane configuration, lockups will be avoided and deleting a tmpfs file is > > > guaranteed to free memory. When zram is used to back tmpfs, there is no > > > guarantee that any memory is freed due to fragmentation of the compressed > > > pages. The only way to recover the memory may be to kill applications > > > holding tmpfs files open and then delete them which is fairly drastic > > > action in a normal server environment. > > > > Indeed. > > Actually, I had a plan to support zsmalloc compaction. The zsmalloc exposes > > handle instead of pure pointer so it could migrate some zpages to somewhere > > to pack in. Then, it could help above problem and OOM storm problem. > > Anyway, it's a totally new feature and requires many changes and > > experiement. > > Although we don't have such feature, zram is still good for many people. > > > > And is zsmalloc was pluggable for zswap then it would also benefit. But zswap isn't pseudo block device so it couldn't be used for block device. Let say one usecase for using zram-blk. 1) Many embedded system don't have swap so although tmpfs can support swapout it's pointless still so such systems should have sane configuration to limit memory space so it's not only zram problem. 2) Many embedded system don't have enough memory. Let's assume short-lived file growing up until half of system memory once in a while. We don't want to write it on flash by wear-leveing issue and very slowness so we want to use in-memory but if we uses tmpfs, it should evict half of working set to cover them when the size reach peak. zram would be better choice. > > > > These are the sort of reason why I feel that zram has limited cases where > > > it is safe to use and zswap has a wider range of applications. At least > > > I would be very unhappy to try supporting zram in the field for normal > > > servers. zswap should be able to replace the functionality of zram+swap > > > by backing zswap with a pseudo block device that rejects all writes. I > > > > One of difference between zswap and zram is asynchronous I/O support. > > As zram is not writing to disk, how compelling is asynchronous IO? If > zswap was backed by the pseudo device is there a measurable bottleneck? Compression. It was really bottlneck point. I had an internal patch which can make zram use various compressor, not only LZO. The better good compressor was, the more bottlenck compressor was. > > > I guess frontswap is synchronous by semantic while zram
[PATCH 2/2] staging: gdm7240: a TTY rewrite according to the latest TTY APIs
Fixed mis-use of mutex for gdm_table. gdm_table is refered to only
inside tty_install and port destrcut, and usb callbacks use internal
reference which was saved during urb submission
Signed-off-by: Won Kang
---
drivers/staging/gdm724x/gdm_mux.c |9
drivers/staging/gdm724x/gdm_mux.h | 14 +---
drivers/staging/gdm724x/gdm_tty.c | 45 -
drivers/staging/gdm724x/gdm_tty.h | 33 ++-
4 files changed, 56 insertions(+), 45 deletions(-)
diff --git a/drivers/staging/gdm724x/gdm_mux.c
b/drivers/staging/gdm724x/gdm_mux.c
index b630bab..9e217ff 100644
--- a/drivers/staging/gdm724x/gdm_mux.c
+++ b/drivers/staging/gdm724x/gdm_mux.c
@@ -25,7 +25,6 @@
#include
#include "gdm_mux.h"
-#include "gdm_tty.h"
struct workqueue_struct *mux_rx_wq;
@@ -196,7 +195,7 @@ static int up_to_host(struct mux_rx *r)
ret = r->callback(mux_header->data,
payload_size,
index,
- mux_dev->minor[index],
+ mux_dev->tty_dev,
RECV_PACKET_PROCESS_CONTINUE
);
if (ret == TO_HOST_BUFFER_REQUEST_FAIL) {
@@ -209,7 +208,7 @@ static int up_to_host(struct mux_rx *r)
ret = r->callback(NULL,
0,
index,
- mux_dev->minor[index],
+ mux_dev->tty_dev,
RECV_PACKET_PROCESS_COMPLETE
);
break;
@@ -283,7 +282,7 @@ static void gdm_mux_rcv_complete(struct urb *urb)
}
static int gdm_mux_recv(void *priv_dev,
- int (*cb)(void *data, int len, int tty_index, int
minor, int complete)
+ int (*cb)(void *data, int len, int tty_index, struct
tty_dev *tty_dev, int complete)
)
{
struct mux_dev *mux_dev = priv_dev;
@@ -562,7 +561,7 @@ static int gdm_mux_probe(struct usb_interface *intf, const
struct usb_device_id
goto out;
}
for (i = 0; i < TTY_MAX_COUNT; i++)
- mux_dev->minor[i] = tty_dev->minor[i];
+ mux_dev->tty_dev = tty_dev;
out:
if (ret < 0) {
diff --git a/drivers/staging/gdm724x/gdm_mux.h
b/drivers/staging/gdm724x/gdm_mux.h
index d5b0b54..0163b24 100644
--- a/drivers/staging/gdm724x/gdm_mux.h
+++ b/drivers/staging/gdm724x/gdm_mux.h
@@ -18,6 +18,8 @@
#include
#include
+#include "gdm_tty.h"
+
#define PM_NORMAL 0
#define PM_SUSPEND 1
@@ -57,7 +59,10 @@ struct mux_rx {
void *mux_dev;
u32 offset;
u32 len;
- int (*callback)(void *data, int len, int tty_index, int minor,
+ int (*callback)(void *data,
+ int len,
+ int tty_index,
+ struct tty_dev *tty_dev,
int complete);
};
@@ -78,10 +83,13 @@ struct mux_dev {
struct delayed_work work_rx;
struct usb_interface *intf;
int usb_state;
- int (*rx_cb)(void *data, int len, int tty_index, int minor,
+ int (*rx_cb)(void *data,
+int len,
+int tty_index,
+struct tty_dev *tty_dev,
int complete);
spinlock_t write_lock;
- u8 minor[2];
+ struct tty_dev *tty_dev;
};
#endif /* _GDM_MUX_H_ */
diff --git a/drivers/staging/gdm724x/gdm_tty.c
b/drivers/staging/gdm724x/gdm_tty.c
index 5bcf882..c1530b7 100644
--- a/drivers/staging/gdm724x/gdm_tty.c
+++ b/drivers/staging/gdm724x/gdm_tty.c
@@ -89,19 +89,22 @@ static int gdm_tty_install(struct tty_driver *driver,
struct tty_struct *tty)
mutex_lock(_table_lock);
gdm = gdm_table[i][j];
- mutex_unlock(_table_lock);
- if (gdm == NULL)
+ if (gdm == NULL) {
+ mutex_unlock(_table_lock);
return -ENODEV;
+ }
tty_port_get(>port);
ret = tty_standard_install(driver, tty);
if (ret) {
tty_port_put(>port);
+ mutex_unlock(_table_lock);
return ret;
}
tty->driver_data = gdm;
+ mutex_unlock(_table_lock);
return 0;
}
@@ -130,14 +133,13 @@ static void gdm_tty_close(struct tty_struct *tty, struct
file *filp)
tty_port_close(>port, tty, filp);
}
-static int gdm_tty_recv_complete(void *data, int len, int index, int minor,
int complete)
+static int gdm_tty_recv_complete(void *data,
+int len,
+int index,
+struct tty_dev *tty_dev,
+int complete)
{
- struct gdm *gdm;
-
-
[PATCH 1/2] staging: gdm7240: a TTY rewrite according to the latest TTY APIs
Removed the old style reference countings and termios.
Renamed variables to meaninful ones.
Signed-off-by: Won Kang
---
drivers/staging/gdm724x/gdm_tty.c | 294 ++---
drivers/staging/gdm724x/gdm_tty.h |5 +-
2 files changed, 142 insertions(+), 157 deletions(-)
diff --git a/drivers/staging/gdm724x/gdm_tty.c
b/drivers/staging/gdm724x/gdm_tty.c
index 912022b..5bcf882 100644
--- a/drivers/staging/gdm724x/gdm_tty.c
+++ b/drivers/staging/gdm724x/gdm_tty.c
@@ -45,141 +45,138 @@
#define gdm_tty_send_control(n, r, v, d, l) (\
n->tty_dev->send_control(n->tty_dev->priv_dev, r, v, d, l))
-#define acm_set_comm_feature(n, v) \
- gdm_tty_send_control(n, 0x02, v, NULL, 0)
+#define GDM_TTY_READY(gdm) (gdm && gdm->tty_dev && gdm->port.count)
-#define GDM_TTY_READY(tty_str) (tty_str && tty_str->tty_dev &&
tty_str->port.count)
-
-struct tty_driver *g_tty_drv[TTY_MAX_COUNT] = {NULL, };
-struct tty_str *g_tty_str[TTY_MAX_COUNT][GDM_TTY_MINOR] = {{NULL, }, };
+struct tty_driver *gdm_driver[TTY_MAX_COUNT];
+struct gdm *gdm_table[TTY_MAX_COUNT][GDM_TTY_MINOR];
+static DEFINE_MUTEX(gdm_table_lock);
static char *DRIVER_STRING[TTY_MAX_COUNT] = {"GCTATC", "GCTDM"};
static char *DEVICE_STRING[TTY_MAX_COUNT] = {"GCT-ATC", "GCT-DM"};
-static DEFINE_MUTEX(open_mutex);
+static void gdm_port_destruct(struct tty_port *port)
+{
+ struct gdm *gdm = container_of(port, struct gdm, port);
+
+ mutex_lock(_table_lock);
+ gdm_table[gdm->index][gdm->minor] = NULL;
+ mutex_unlock(_table_lock);
+
+ kfree(gdm);
+}
-static struct tty_port_operations gdm_tty_port_ops = {
+static struct tty_port_operations gdm_port_ops = {
+ .destruct = gdm_port_destruct,
};
-static int gdm_tty_open(struct tty_struct *tty, struct file *filp)
+static int gdm_tty_install(struct tty_driver *driver, struct tty_struct *tty)
{
- struct tty_str *tty_str = NULL;
+ struct gdm *gdm = NULL;
+ int ret;
int i;
- int ret = 0;
-
- mutex_lock(_mutex);
+ int j;
+ j = GDM_TTY_MINOR;
for (i = 0; i < TTY_MAX_COUNT; i++) {
if (!strcmp(tty->driver->driver_name, DRIVER_STRING[i])) {
- tty_str = g_tty_str[i][tty->index];
+ j = tty->index;
break;
}
}
- if (!tty_str) {
- pr_info("no tty device\n");
- mutex_unlock(_mutex);
+ if (j == GDM_TTY_MINOR)
return -ENODEV;
- }
- set_bit(TTY_NO_WRITE_SPLIT, >flags);
+ mutex_lock(_table_lock);
+ gdm = gdm_table[i][j];
+ mutex_unlock(_table_lock);
+ if (gdm == NULL)
+ return -ENODEV;
- tty->driver_data = tty_str;
- tty_port_tty_set(_str->port, tty);
- tty_str->port.count++;
- set_bit(ASYNCB_INITIALIZED, _str->port.flags);
- ret = tty_port_block_til_ready(_str->port, tty, filp);
+ tty_port_get(>port);
- mutex_unlock(_mutex);
+ ret = tty_standard_install(driver, tty);
+ if (ret) {
+ tty_port_put(>port);
+ return ret;
+ }
- return ret;
+ tty->driver_data = gdm;
+
+ return 0;
}
-static void gdm_tty_close(struct tty_struct *tty, struct file *filp)
+static int gdm_tty_open(struct tty_struct *tty, struct file *filp)
{
- struct tty_str *tty_str = tty->driver_data;
- int i;
-
- if (!tty_str) {
- pr_info("tty device already closed\n");
- return;
- }
-
- if (tty_str->port.count != 0) {
- tty_port_close_start(_str->port, tty, filp);
- tty_port_close_end(_str->port, tty);
+ struct gdm *gdm = tty->driver_data;
+ return tty_port_open(>port, tty, filp);
+}
- if (tty_str->port.count == 0)
- tty_port_tty_set(_str->port, NULL);
- tty_str->port.tty = NULL;
- }
+static void gdm_tty_cleanup(struct tty_struct *tty)
+{
+ struct gdm *gdm = tty->driver_data;
+ tty_port_put(>port);
+}
- if (!tty_str->tty_dev) {
- for (i = 0; i < TTY_MAX_COUNT; i++) {
- if (!strcmp(tty->driver->driver_name, DRIVER_STRING[i]))
- break;
- }
+static void gdm_tty_hangup(struct tty_struct *tty)
+{
+ struct gdm *gdm = tty->driver_data;
+ tty_port_hangup(>port);
+}
- if (i < TTY_MAX_COUNT) {
- tty_unregister_device(g_tty_drv[i], tty->index);
- tty_port_tty_set(_str->port, NULL);
- kfree(tty_str);
- g_tty_str[i][tty->index] = NULL;
- }
- }
+static void gdm_tty_close(struct tty_struct *tty, struct file *filp)
+{
+ struct gdm *gdm = tty->driver_data;
+ tty_port_close(>port, tty, filp);
}
static int
Re: [PATCH v4 5/5] ARM: davinci: da850: add OF_DEV_AUXDATA entry for eth0.
Hi Sergei,
On Fri, Aug 16, 2013 at 1:01 AM, Sergei Shtylyov
wrote:
> Hello.
>
>
> On 15-08-2013 10:01, Lad, Prabhakar wrote:
>
>> From: "Lad, Prabhakar"
>
>
>> Add OF_DEV_AUXDATA for eth0 driver in da850 board dt
>> file to use emac clock.
>
>
>> Signed-off-by: Lad, Prabhakar
>
> [...]
>
>
>> diff --git a/arch/arm/mach-davinci/da8xx-dt.c
>> b/arch/arm/mach-davinci/da8xx-dt.c
>> index d172563..caa9202 100644
>> --- a/arch/arm/mach-davinci/da8xx-dt.c
>> +++ b/arch/arm/mach-davinci/da8xx-dt.c
>> @@ -44,6 +44,9 @@ static struct of_dev_auxdata da850_auxdata_lookup[]
>> __initdata = {
>> OF_DEV_AUXDATA("ns16550a", 0x01d0c000, "serial8250.1", NULL),
>> OF_DEV_AUXDATA("ns16550a", 0x01d0d000, "serial8250.2", NULL),
>> OF_DEV_AUXDATA("ti,davinci_mdio", 0x01e24000, "davinci_mdio.0",
>> NULL),
>> + OF_DEV_AUXDATA("ti,davinci-dm6467-emac", 0x01e2,
>> "davinci_emac.1",
>> + NULL),
>> +
>
>
>Empty line hardly needed here.
>
Ah my bad, will fix and repost.
Regards,
--Prabhakar Lad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/5] ARM: davinci: da850: add DT node for eth0.
Hi Sergei,
On Fri, Aug 16, 2013 at 1:00 AM, Sergei Shtylyov
wrote:
> Hello.
>
>
> On 15-08-2013 10:01, Lad, Prabhakar wrote:
>
>> From: "Lad, Prabhakar"
>
>
>> Add eth0 device tree node information and pinmux for mii to da850 by
>> providing interrupt details and local mac address of eth0.
>
>
>> Signed-off-by: Lad, Prabhakar
>
> [...]
>
>
>> @@ -226,6 +242,20 @@
>> #size-cells = <0>;
>> reg = <0x224000 0x1000>;
>> };
>> + eth0: emac@1e2 {
>
>
>According to the ePAPR spec[1] section 2.2.2, the node should be named
> "ethernet".
>
Thanks for pointing it, I'll fix and repost it.
Regards,
--Prabhakar Lad
> [1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf
>
> WBR, Sergei
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [RFC v2] drivers: xen NUMA-aware balloon driver
Hi all,
This small patch introduce NUMA awaness to xen balloon driver.
It could be apply to
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
as far as I send this email.
And it's version 2, since the first version is too urgly.
Full docs could be found under
xensource/docs/misc/numa-aware-ballooning.markdown
which belongs to another patch, which contains the patches to
libxl, and, which is sent together with this one
in xen-devel. This patch is only for Linux.
Please forgive me for the stupid version 1. I have tried to make
this one a readable patch, so that it could be possible for you
to review my code, and give me more suggestions :-)
Also, guest virtual NUMA topology is required for this work.
it's not something that we have now, but I know that it's been
working on. I declare some interfaces in this code (which we
have some kind of a deal on it). Anyway, this code is almost
working, so I publish it here as an RFC to get some early
feedback.
about the code architechure:
Modification is mainly on linux-kernel/drivers/xen/balloon.c .
There are several interface functions:
unsigned long long xen_mnid_to_vnidmask(int mnid);
int xen_vnid_to_mnid(int vnid);
int balloon_page_to_vnid(struct page *page);
struct page* xen_alloc_pages_node(int vnid);
Now they are marked "todo" for debuging and interface waiting.
The original increase/decrease reservation function:
increase_reservation(unsigned long nr_pages),
decrease_reservation(unsigned long nr_pages, gfp_t gfp)
now come to :
__increase_reservation(int vnid, unsigned long nr_pages),
__decrease_reservation(int vnid, unsigned long nr_pages, gfp_t
gfp),
These two functions used to be designed as a batcher. Since we have
a best-effort request, add another layer on top of them:
static struct bp_rt
increase_reservatin_nodeonly(...)
decrease_reservatin_nodeonly(...)
They will use a while loop to call __increase_reservation_node(..)/
__decrease_reservation_node(..) until it
couldn't get more pages from this v-node.
Also, we have to know how many pages are settled in
__increase_reservation_node() and __decrease_reservation_node(),
a new return struct type is required.
The struct bp_rt includes the new return message of balloon, so that
when comes to uppest level:
increase_reservation_numa(vnidmask, nodeexact, nr_pages)
decrease_reservation_numa(vnidmask, nodeexact, nr_pages, gfp)
balloon can decide whether it should go on to the next node or not.
These two function loops the node according to vnidmask. If pages on
the first v-node does not meet the requirement, go on to the second,
etc..
/* XXX:there is still some code dumplicate here. It could be
optimized in a later version */
In the old balloon, when current does not meet target, the balloon
process runs an infinited loop, reschedule the task until requirement
meets. But now we may have a danger that we might not get enough pages
FOREVER if node specified and nodeexact=true. In this case,
Define NUMA_BALLOON_RETRY_MAX: the maximun balloon_process()
reschedule time when nodeexact=true.
Balloon will exit if nodeexact=true and the retry counter exceed this
NUMA_BALLOON_RETRY_MAX limitation.
Signed-off-by: Yechen Li
---
drivers/xen/balloon.c | 355 --
drivers/xen/xen-balloon.c | 20 ++-
include/xen/balloon.h | 19 +++
3 files changed, 351 insertions(+), 43 deletions(-)
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 2a2ef97..92f5cd9 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -53,6 +53,8 @@
#include
#include
+#include
+
#include
#include
#include
@@ -81,10 +83,26 @@ enum bp_state {
BP_EAGAIN,
BP_ECANCELED
};
+/*
+ * balloon increase/decerase return message
+ * donepages: increase/decrease page number the function does
+ * always initial to 0
+ * state: bp_state that return to balloon_process()
+ */
+struct bp_rt {
+ unsigned long donepages;
+ enum bp_state state;
+};
+#define DECLARE_BP_RT(bp_rt) \
+ struct bp_rt bp_rt = { \
+ .donepages = 0, \
+ .state = BP_DONE\
+ }
static DEFINE_MUTEX(balloon_mutex);
+/*todo: should this balloon_stats change to
RE: [PATCH net-next v2 1/3] net/usb/r8152: support aggregation
Francois Romieu [mailto:rom...@fr.zoreil.com]
> Sent: Thursday, August 15, 2013 8:26 PM
> To: Hayeswang
> Cc: net...@vger.kernel.org; nic_swsd;
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; David Miller
> Subject: Re: [PATCH net-next v2 1/3] net/usb/r8152: support
> aggregation
>
[...]
> > +static
> > +int r8152_submit_rx(struct r8152 *tp, struct rx_agg *agg,
> gfp_t mem_flags);
> > +
>
> It's a new, less than 10 lines function without driver
> internal dependencies.
>
> The forward declaration is not needed.
The r8152_submit_rx() need the declaration of read_bulk_callback(), and the
read_bulk_callback() need the declaration of r8152_submit_rx(), too. It likes
a dead lock, so I have no idea how to do it without another declaration.
[...]
> > - if (!netif_device_present(netdev))
> > + if (!netif_carrier_ok(netdev))
> > return;
>
> How is it related to the subject of the patch ?
When link down, the driver would cancel all bulks. This avoid the re-submitting
bulk.
> [...]
> > +static void rx_bottom(struct r8152 *tp)
> > +{
> > + struct net_device_stats *stats;
> > + struct net_device *netdev;
> > + struct rx_agg *agg;
> > + struct rx_desc *rx_desc;
> > + unsigned long lockflags;
>
> Idiom: 'flags'.
>
> > + struct list_head *cursor, *next;
> > + struct sk_buff *skb;
> > + struct urb *urb;
> > + unsigned pkt_len;
> > + int len_used;
> > + u8 *rx_data;
> > + int ret;
>
> The scope of these variables is needlessly wide.
>
> > +
> > + netdev = tp->netdev;
> > +
> > + stats = rtl8152_get_stats(netdev);
> > +
> > + spin_lock_irqsave(>rx_lock, lockflags);
> > + list_for_each_safe(cursor, next, >rx_done) {
> > + list_del_init(cursor);
> > + spin_unlock_irqrestore(>rx_lock, lockflags);
> > +
> > + agg = list_entry(cursor, struct rx_agg, list);
> > + urb = agg->urb;
> > + if (urb->actual_length < ETH_ZLEN) {
>
> goto submit;
>
> > + ret = r8152_submit_rx(tp, agg, GFP_ATOMIC);
> > + spin_lock_irqsave(>rx_lock, lockflags);
> > + if (ret && ret != -ENODEV) {
> > + list_add_tail(>list, next);
> > + tasklet_schedule(>tl);
> > + }
> > + continue;
> > + }
>
> (remove the line above)
>
> [...]
> > + rx_data = rx_agg_align(rx_data + pkt_len + 4);
> > + rx_desc = (struct rx_desc *)rx_data;
> > + pkt_len = le32_to_cpu(rx_desc->opts1) &
> RX_LEN_MASK;
> > + len_used = (int)(rx_data - (u8 *)agg->head);
> > + len_used += sizeof(struct rx_desc) + pkt_len;
> > + }
> > +
>
> submit:
>
> > + ret = r8152_submit_rx(tp, agg, GFP_ATOMIC);
> > + spin_lock_irqsave(>rx_lock, lockflags);
> > + if (ret && ret != -ENODEV) {
> > + list_add_tail(>list, next);
> > + tasklet_schedule(>tl);
> > + }
> > + }
> > + spin_unlock_irqrestore(>rx_lock, lockflags);
> > +}
>
> It should be possible to retrieve more items in the spinlocked section
> so as to have a chance to batch more work. I have not thought
> too deeply
> about it.
I only lock when I want to remove or inser the agg list, and unlock as soon as
possible. I don't think I keep locking for a long time.
Best Regards,
Hayes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] arm: dts: AM43x: Add usb DT nodes for AM4372
Hi Benoit ,
Thanks for your review.
On 8/14/2013 8:04 PM, Benoit Cousson wrote:
+ Roger
Hi George,
Yes, I had some comment about the "ti'type" in Roger's series that
will be applicable here as well.
On 14/08/2013 16:16, George Cherian wrote:
+Benoit
If you dont have any comments, can you take this for 3.12?
Regards
-George
On 7/10/2013 1:44 PM, George Cherian wrote:
This patch adds
- HS USB nodes
- phy nodes
- usb control module nodes.
Signed-off-by: George Cherian
---
changes from v2
change synopsis to snps
use simple node names
add both USB and PHY instances
add usbctrl node
changes from v1
renamed synopsis to snps
removed flag tx-fifo-resize
arch/arm/boot/dts/am4372.dtsi | 58
+++
1 file changed, 58 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi
b/arch/arm/boot/dts/am4372.dtsi
index ddc1df7..37f196f 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -64,5 +64,63 @@
compatible = "ti,am4372-counter32k","ti,omap-counter32k";
reg = <0x44e86000 0x40>;
};
+
+phy1: usbphy1 {
+compatible = "ti,am4372-usb2";
That's not a very good name for a phy? It looks like a usb module.
The bindings specify only ti,omap-usb2 or ti,omap-usb3 for USB2 or USB3.
I guess it should be one of them and potentially the binding should be
updated with ti,omap-usb2-phy and ti,omap-usb3-phy names while we can
still do it.
+#phy-cells = <0>;
+id = <0>;
+status = "disabled";
+};
+
+phy2: usbphy2 {
Why do you need a different node name here? It should be a generic
name to identify the function, so usbphy or usb-phy seems good enough.
There are 2 instances of usb controllers and these instances for those 2
phys, which essentially dont have any reg property. So I named it as
usbphy1 and usbphy2.
+compatible = "ti,am4372-usb2";
+#phy-cells = <0>;
+id = <1>;
+status = "disabled";
+};
+
+usbctrl: omap-control-usb@44e10620 {
+compatible = "ti,omap-control-usb";
+reg = <0x44e10620 0x10>;
+reg-names = "control_dev_conf";
+ti,type = <3>;
+status = "disabled";
+};
+
+usb1: am4372_dwc3@4838 {
+status = "disabled";
+compatible = "ti,am4372-dwc3";
+reg = <0x4838 0x200>;
+interrupts = ;
+#address-cells = <1>;
+#size-cells = <1>;
+utmi-mode = <1>;
+ranges;
A blank line here will be nice.
okay
+dwc3@4839 {
+compatible = "snps,dwc3";
+reg = <0x4839 0xd000>;
+interrupts = ;
+phys = <>;
+phy-names = "am4372-usb1";
What is the purpose of the phy-names? Is it relevant to add the SoC
name in something that usually, at least for the clocks and IRQs, is
IP specific?
The current documentation does not explain it and does not support
phys property either.
synopsys DWC3 CORE
DWC3- USB3 CONTROLLER
Required properties:
- compatible: must be "synopsys,dwc3"
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
- usb-phy : array of phandle for the PHY device
Is there some binding update ongoing for 3.12?
The phy part, especially was added with the generic phy framework in
mind. The generic phy framework uses phys and phy-names instead of usb-phy.
Also all synopsys references for compatible are being replaced with snps.
+};
+};
+
+usb2: am4372_dwc3@483c {
+status = "disabled";
+compatible = "ti,am4372-dwc3";
+reg = <0x483c 0x200>;
+interrupts = ;
+#address-cells = <1>;
+#size-cells = <1>;
+utmi-mode = <1>;
+ranges;
A blank line here will be nice.
okay
+dwc3@483d {
+compatible = "snps,dwc3";
+reg = <0x483d 0xd000>;
+interrupts = ;
+phys = <>;
+phy-names = "am4372-usb2";
+};
+};
};
};
Regards,
Benoit
--
-George
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: My Will of $10,000,000.00 (Contact My Lawyer on i...@nobelchb.org)
I am Mrs. Rachael Tims. I have Cancer of the Lungs. I would like to share a secret with you. Contact my Attorney Thomas Belford with this specified email: i...@nobelchb.org kindly state that I have WILLED $10,000,000.00 to you -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] block: support embedded device command line partition
> > +blkdevparts=[;] > > + := :[,] > > + := [@](part-name) > > + > > + > > +block device disk name, embedded device used fixed block device, > > +it's disk name also fixed. such as: mmcblk0, mmcblk1, mmcblk0boot0. > > The device-name isn't always fixed. > > For example, what if there are multiple SDHCI controllers, one hosting a > fixed eMMC device and the other an SD card? It's quite typical for the > eMMC's device name (which is likely what should be affected by this > feature) to be mmcblk0 when no SD card is present, yet be mmcblk1 when > an SD card is present. Is there a more precise/stable way to define > which device the command-line option applies to? Yes. Fixed is for single controller. For multiple controllers, currently, there is not a simple way. I tend to do something in the eMMC driver, such as initialize order, but I have not tried. > > For the root= command-line option, we use UUID= or PARTUUID= to work > around this issue, but that won't work for naming the whole device. > > What about using the MMIO address of the controller hosting the device, > or something like that? > MMIO may be not a good idea, it is not intuitive. > > + > > +partition size, in bytes, such as: 512, 1m, 1G. > > s/m/M/? > > I assume M/G are MiB/GiB? > > Does it make sense to allow specifying the sizes in units of > sectors/blocks? If so, which specific block/sector size in the case of > things like NAND flash which IIRC have multiple types/levels of sectors; > perhaps this is a bad idea. I guess we could easily add this feature > later by introducing a new suffix, so no need to solve the issue now. > > > + > > + > > +partition start address, in bytes. > > + > > +(part-name) > > +partition name, kernel send uevent with "PARTNAME". application can > > create > > +a link to block device partition with the name "PARTNAME". > > +user space application can access partition by partition name. > > Do partitions usually have a PARTNAME attribute when probed through > normal mechanisms like MBR? If so, I guess this is fine. > > Perhaps we can just use , as the delimiter for all fields, rather than > special-casing part-name to use (), so: > > size,offset,partname,size,offset,partname,... > > The partname field could easily be empty if not needed. > If no need partname, your bootargs are mmcblk0:1G,1G,1G,... > > +Example: > > +eMMC disk name is "mmcblk0" and "mmcblk0boot0" > > + > > + bootargs: > > + > 'blkdevparts=mmcblk0:1G(data0),1G(data1),-;mmcblk0boot0:1m(boot),-(kernel)' > > + > > + dmesg: > > +mmcblk0: p1(data0) p2(data1) p3() > > +mmcblk0boot0: p1(boot) p2(kernel) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/34] cpufreq: at32ap: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Cc: Hans-Christian Egtvedt
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/at32ap-cpufreq.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/cpufreq/at32ap-cpufreq.c b/drivers/cpufreq/at32ap-cpufreq.c
index 81d0752..856ad80 100644
--- a/drivers/cpufreq/at32ap-cpufreq.c
+++ b/drivers/cpufreq/at32ap-cpufreq.c
@@ -37,27 +37,23 @@ static unsigned longloops_per_jiffy_ref;
static int at32_set_target(struct cpufreq_policy *policy, unsigned int index)
{
- struct cpufreq_freqs freqs;
+ unsigned int old_freq, new_freq;
- freqs.old = at32_get_speed(0);
- freqs.new = freq_table[index].frequency;
+ old_freq = at32_get_speed(0);
+ new_freq = freq_table[index].frequency;
if (!ref_freq) {
- ref_freq = freqs.old;
+ ref_freq = old_freq;
loops_per_jiffy_ref = boot_cpu_data.loops_per_jiffy;
}
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
- if (freqs.old < freqs.new)
+ if (old_freq < new_freq)
boot_cpu_data.loops_per_jiffy = cpufreq_scale(
- loops_per_jiffy_ref, ref_freq, freqs.new);
- clk_set_rate(cpuclk, freqs.new * 1000);
- if (freqs.new < freqs.old)
+ loops_per_jiffy_ref, ref_freq, new_freq);
+ clk_set_rate(cpuclk, new_freq * 1000);
+ if (new_freq < old_freq)
boot_cpu_data.loops_per_jiffy = cpufreq_scale(
- loops_per_jiffy_ref, ref_freq, freqs.new);
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
- pr_debug("cpufreq: set frequency %u Hz\n", freqs.new * 1000);
+ loops_per_jiffy_ref, ref_freq, new_freq);
return 0;
}
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/34] cpufreq: e_powersaver: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/e_powersaver.c | 23 +++
1 file changed, 3 insertions(+), 20 deletions(-)
diff --git a/drivers/cpufreq/e_powersaver.c b/drivers/cpufreq/e_powersaver.c
index b39c4ef..9012b8b 100644
--- a/drivers/cpufreq/e_powersaver.c
+++ b/drivers/cpufreq/e_powersaver.c
@@ -107,15 +107,9 @@ static int eps_set_state(struct eps_cpu_data *centaur,
struct cpufreq_policy *policy,
u32 dest_state)
{
- struct cpufreq_freqs freqs;
u32 lo, hi;
- int err = 0;
int i;
- freqs.old = eps_get(policy->cpu);
- freqs.new = centaur->fsb * ((dest_state >> 8) & 0xff);
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
/* Wait while CPU is busy */
rdmsr(MSR_IA32_PERF_STATUS, lo, hi);
i = 0;
@@ -124,8 +118,7 @@ static int eps_set_state(struct eps_cpu_data *centaur,
rdmsr(MSR_IA32_PERF_STATUS, lo, hi);
i++;
if (unlikely(i > 64)) {
- err = -ENODEV;
- goto postchange;
+ return -ENODEV;
}
}
/* Set new multiplier and voltage */
@@ -137,16 +130,10 @@ static int eps_set_state(struct eps_cpu_data *centaur,
rdmsr(MSR_IA32_PERF_STATUS, lo, hi);
i++;
if (unlikely(i > 64)) {
- err = -ENODEV;
- goto postchange;
+ return -ENODEV;
}
} while (lo & ((1 << 16) | (1 << 17)));
- /* Return current frequency */
-postchange:
- rdmsr(MSR_IA32_PERF_STATUS, lo, hi);
- freqs.new = centaur->fsb * ((lo >> 8) & 0xff);
-
#ifdef DEBUG
{
u8 current_multiplier, current_voltage;
@@ -161,11 +148,7 @@ postchange:
current_multiplier);
}
#endif
- if (err)
- freqs.new = freqs.old;
-
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
- return err;
+ return 0;
}
static int eps_target(struct cpufreq_policy *policy, unsigned int index)
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 RESEND 5/7] net: sunhme: use platform_{get,set}_drvdata()
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with _dev->dev,
so we can directly pass a struct platform_device.
changelog:
remove modify about happy_meal_pci_probe && happy_meal_pci_remove
Signed-off-by: Libo Chen
---
drivers/net/ethernet/sun/sunhme.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/sun/sunhme.c
b/drivers/net/ethernet/sun/sunhme.c
index 171f5b0..b90d311 100644
--- a/drivers/net/ethernet/sun/sunhme.c
+++ b/drivers/net/ethernet/sun/sunhme.c
@@ -3231,7 +3231,7 @@ static int hme_sbus_probe(struct platform_device *op)
static int hme_sbus_remove(struct platform_device *op)
{
- struct happy_meal *hp = dev_get_drvdata(>dev);
+ struct happy_meal *hp = platform_get_drvdata(op);
struct net_device *net_dev = hp->dev;
unregister_netdev(net_dev);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 32/34] cpufreq: SPEAr: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Cc: spear-de...@list.st.com
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/spear-cpufreq.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/cpufreq/spear-cpufreq.c b/drivers/cpufreq/spear-cpufreq.c
index efacfa1..4ad35a5 100644
--- a/drivers/cpufreq/spear-cpufreq.c
+++ b/drivers/cpufreq/spear-cpufreq.c
@@ -107,12 +107,10 @@ static int spear1340_set_cpu_rate(struct clk *sys_pclk,
unsigned long newfreq)
static int spear_cpufreq_target(struct cpufreq_policy *policy,
unsigned int index)
{
- struct cpufreq_freqs freqs;
unsigned long newfreq;
struct clk *srcclk;
int ret, mult = 1;
- freqs.old = spear_cpufreq_get(0);
newfreq = spear_cpufreq.freq_tbl[index].frequency * 1000;
if (of_machine_is_compatible("st,spear1340")) {
@@ -145,23 +143,14 @@ static int spear_cpufreq_target(struct cpufreq_policy
*policy,
return newfreq;
}
- freqs.new = newfreq / 1000;
- freqs.new /= mult;
-
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
if (mult == 2)
ret = spear1340_set_cpu_rate(srcclk, newfreq);
else
ret = clk_set_rate(spear_cpufreq.clk, newfreq);
- /* Get current rate after clk_set_rate, in case of failure */
- if (ret) {
+ if (ret)
pr_err("CPU Freq: cpu clk_set_rate failed: %d\n", ret);
- freqs.new = clk_get_rate(spear_cpufreq.clk) / 1000;
- }
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
return ret;
}
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 29/34] cpufreq: sa11x0: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Cc: Russell King
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/sa1100-cpufreq.c | 17 ++---
drivers/cpufreq/sa1110-cpufreq.c | 12 ++--
2 files changed, 8 insertions(+), 21 deletions(-)
diff --git a/drivers/cpufreq/sa1100-cpufreq.c b/drivers/cpufreq/sa1100-cpufreq.c
index aa49a08..a89c47b 100644
--- a/drivers/cpufreq/sa1100-cpufreq.c
+++ b/drivers/cpufreq/sa1100-cpufreq.c
@@ -180,22 +180,17 @@ static void sa1100_update_dram_timings(int current_speed,
int new_speed)
static int sa1100_target(struct cpufreq_policy *policy, unsigned int ppcr)
{
unsigned int cur = sa11x0_getspeed(0);
- struct cpufreq_freqs freqs;
+ unsigned int new_freq;
- freqs.old = cur;
- freqs.new = sa11x0_freq_table[ppcr].frequency;
+ new_freq = sa11x0_freq_table[ppcr].frequency;
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
- if (freqs.new > cur)
- sa1100_update_dram_timings(cur, freqs.new);
+ if (new_freq > cur)
+ sa1100_update_dram_timings(cur, new_freq);
PPCR = ppcr;
- if (freqs.new < cur)
- sa1100_update_dram_timings(cur, freqs.new);
-
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
+ if (new_freq < cur)
+ sa1100_update_dram_timings(cur, new_freq);
return 0;
}
diff --git a/drivers/cpufreq/sa1110-cpufreq.c b/drivers/cpufreq/sa1110-cpufreq.c
index c00cf2b..0e52e80 100644
--- a/drivers/cpufreq/sa1110-cpufreq.c
+++ b/drivers/cpufreq/sa1110-cpufreq.c
@@ -232,15 +232,11 @@ sdram_update_refresh(u_int cpu_khz, struct sdram_params
*sdram)
static int sa1110_target(struct cpufreq_policy *policy, unsigned int ppcr)
{
struct sdram_params *sdram = _params;
- struct cpufreq_freqs freqs;
struct sdram_info sd;
unsigned long flags;
unsigned int unused;
- freqs.old = sa11x0_getspeed(0);
- freqs.new = sa11x0_freq_table[ppcr].frequency;
-
- sdram_calculate_timing(, freqs.new, sdram);
+ sdram_calculate_timing(, sa11x0_freq_table[ppcr].frequency, sdram);
#if 0
/*
@@ -259,8 +255,6 @@ static int sa1110_target(struct cpufreq_policy *policy,
unsigned int ppcr)
sd.mdcas[2] = 0x;
#endif
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
/*
* The clock could be going away for some time. Set the SDRAMs
* to refresh rapidly (every 64 memory clock cycles). To get
@@ -305,9 +299,7 @@ static int sa1110_target(struct cpufreq_policy *policy,
unsigned int ppcr)
/*
* Now, return the SDRAM refresh back to normal.
*/
- sdram_update_refresh(freqs.new, sdram);
-
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
+ sdram_update_refresh(sa11x0_freq_table[ppcr].frequency, sdram);
return 0;
}
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 34/34] cpufreq: tegra: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Cc: Stephen Warren
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/tegra-cpufreq.c | 25 +
1 file changed, 5 insertions(+), 20 deletions(-)
diff --git a/drivers/cpufreq/tegra-cpufreq.c b/drivers/cpufreq/tegra-cpufreq.c
index 3c2b12b..b376b67 100644
--- a/drivers/cpufreq/tegra-cpufreq.c
+++ b/drivers/cpufreq/tegra-cpufreq.c
@@ -102,12 +102,8 @@ static int tegra_update_cpu_speed(struct cpufreq_policy
*policy,
unsigned long rate)
{
int ret = 0;
- struct cpufreq_freqs freqs;
- freqs.old = tegra_getspeed(0);
- freqs.new = rate;
-
- if (freqs.old == freqs.new)
+ if (tegra_getspeed(0) == rate)
return ret;
/*
@@ -121,21 +117,10 @@ static int tegra_update_cpu_speed(struct cpufreq_policy
*policy,
else
clk_set_rate(emc_clk, 1); /* emc 50Mhz */
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
-#ifdef CONFIG_CPU_FREQ_DEBUG
- printk(KERN_DEBUG "cpufreq-tegra: transition: %u --> %u\n",
- freqs.old, freqs.new);
-#endif
-
- ret = tegra_cpu_clk_set_rate(freqs.new * 1000);
- if (ret) {
- pr_err("cpu-tegra: Failed to set cpu frequency to %d kHz\n",
- freqs.new);
- freqs.new = freqs.old;
- }
-
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
+ ret = tegra_cpu_clk_set_rate(rate * 1000);
+ if (ret)
+ pr_err("cpu-tegra: Failed to set cpu frequency to %lu kHz\n",
+ rate);
return ret;
}
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 33/34] cpufreq: speedstep: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Cc: David S. Miller
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/speedstep-centrino.c | 20 +---
drivers/cpufreq/speedstep-ich.c | 9 -
drivers/cpufreq/speedstep-smi.c | 7 ---
3 files changed, 1 insertion(+), 35 deletions(-)
diff --git a/drivers/cpufreq/speedstep-centrino.c
b/drivers/cpufreq/speedstep-centrino.c
index b7a2f8d..90b4581 100644
--- a/drivers/cpufreq/speedstep-centrino.c
+++ b/drivers/cpufreq/speedstep-centrino.c
@@ -424,9 +424,8 @@ static int centrino_cpu_exit(struct cpufreq_policy *policy)
static int centrino_target(struct cpufreq_policy *policy, unsigned int index)
{
unsigned intmsr, oldmsr = 0, h = 0, cpu = policy->cpu;
- struct cpufreq_freqsfreqs;
int retval = 0;
- unsigned intj, first_cpu, tmp;
+ unsigned intj, first_cpu;
struct cpufreq_frequency_table *op_points;
cpumask_var_t covered_cpus;
@@ -474,15 +473,6 @@ static int centrino_target(struct cpufreq_policy *policy,
unsigned int index)
goto out;
}
- freqs.old = extract_clock(oldmsr, cpu, 0);
- freqs.new = extract_clock(msr, cpu, 0);
-
- pr_debug("target=%dkHz old=%d new=%d msr=%04x\n",
- op_points->frequency, freqs.old, freqs.new,
msr);
-
- cpufreq_notify_transition(policy, ,
- CPUFREQ_PRECHANGE);
-
first_cpu = 0;
/* all but 16 LSB are reserved, treat them with care */
oldmsr &= ~0x;
@@ -497,8 +487,6 @@ static int centrino_target(struct cpufreq_policy *policy,
unsigned int index)
cpumask_set_cpu(j, covered_cpus);
}
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
if (unlikely(retval)) {
/*
* We have failed halfway through the frequency change.
@@ -509,12 +497,6 @@ static int centrino_target(struct cpufreq_policy *policy,
unsigned int index)
for_each_cpu(j, covered_cpus)
wrmsr_on_cpu(j, MSR_IA32_PERF_CTL, oldmsr, h);
-
- tmp = freqs.new;
- freqs.new = freqs.old;
- freqs.old = tmp;
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
}
retval = 0;
diff --git a/drivers/cpufreq/speedstep-ich.c b/drivers/cpufreq/speedstep-ich.c
index 707721e..7639b2b 100644
--- a/drivers/cpufreq/speedstep-ich.c
+++ b/drivers/cpufreq/speedstep-ich.c
@@ -258,21 +258,12 @@ static unsigned int speedstep_get(unsigned int cpu)
static int speedstep_target(struct cpufreq_policy *policy, unsigned int index)
{
unsigned int policy_cpu;
- struct cpufreq_freqs freqs;
policy_cpu = cpumask_any_and(policy->cpus, cpu_online_mask);
- freqs.old = speedstep_get(policy_cpu);
- freqs.new = speedstep_freqs[index].frequency;
-
- pr_debug("transiting from %u to %u kHz\n", freqs.old, freqs.new);
-
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
smp_call_function_single(policy_cpu, _speedstep_set_state, ,
true);
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
return 0;
}
diff --git a/drivers/cpufreq/speedstep-smi.c b/drivers/cpufreq/speedstep-smi.c
index 19446e4..0f5326d 100644
--- a/drivers/cpufreq/speedstep-smi.c
+++ b/drivers/cpufreq/speedstep-smi.c
@@ -241,14 +241,7 @@ static void speedstep_set_state(unsigned int state)
*/
static int speedstep_target(struct cpufreq_policy *policy, unsigned int index)
{
- struct cpufreq_freqs freqs;
-
- freqs.old = speedstep_freqs[speedstep_get_state()].frequency;
- freqs.new = speedstep_freqs[index].frequency;
-
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
speedstep_set_state(index);
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
return 0;
}
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
[PATCH 21/34] cpufreq: p4-clockmod: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Cc: David S. Miller
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/p4-clockmod.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/cpufreq/p4-clockmod.c b/drivers/cpufreq/p4-clockmod.c
index 3c23053..3d1cba9 100644
--- a/drivers/cpufreq/p4-clockmod.c
+++ b/drivers/cpufreq/p4-clockmod.c
@@ -107,15 +107,8 @@ static struct cpufreq_frequency_table p4clockmod_table[] =
{
static int cpufreq_p4_target(struct cpufreq_policy *policy, unsigned int index)
{
- struct cpufreq_freqs freqs;
int i;
- freqs.old = cpufreq_p4_get(policy->cpu);
- freqs.new = stock_freq * p4clockmod_table[index].driver_data / 8;
-
- /* notifiers */
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
/* run on each logical CPU,
* see section 13.15.3 of IA32 Intel Architecture Software
* Developer's Manual, Volume 3
@@ -123,9 +116,6 @@ static int cpufreq_p4_target(struct cpufreq_policy *policy,
unsigned int index)
for_each_cpu(i, policy->cpus)
cpufreq_p4_setdc(i, p4clockmod_table[index].driver_data);
- /* notifiers */
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
return 0;
}
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 20/34] cpufreq: omap: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Cc: Santosh Shilimkar
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/omap-cpufreq.c | 39 ++-
1 file changed, 14 insertions(+), 25 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 92d45e6..97610a3 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -53,15 +53,15 @@ static unsigned int omap_getspeed(unsigned int cpu)
static int omap_target(struct cpufreq_policy *policy, unsigned int index)
{
- int r, ret = 0;
- struct cpufreq_freqs freqs;
+ int r, ret;
struct opp *opp;
unsigned long freq, volt = 0, volt_old = 0, tol = 0;
+ unsigned int old_freq, new_freq;
- freqs.old = omap_getspeed(policy->cpu);
- freqs.new = freq_table[index].frequency;
+ old_freq = omap_getspeed(policy->cpu);
+ new_freq = freq_table[index].frequency;
- freq = freqs.new * 1000;
+ freq = new_freq * 1000;
ret = clk_round_rate(mpu_clk, freq);
if (IS_ERR_VALUE(ret)) {
dev_warn(mpu_dev,
@@ -77,7 +77,7 @@ static int omap_target(struct cpufreq_policy *policy,
unsigned int index)
if (IS_ERR(opp)) {
rcu_read_unlock();
dev_err(mpu_dev, "%s: unable to find MPU OPP for %d\n",
- __func__, freqs.new);
+ __func__, new_freq);
return -EINVAL;
}
volt = opp_get_voltage(opp);
@@ -87,43 +87,32 @@ static int omap_target(struct cpufreq_policy *policy,
unsigned int index)
}
dev_dbg(mpu_dev, "cpufreq-omap: %u MHz, %ld mV --> %u MHz, %ld mV\n",
- freqs.old / 1000, volt_old ? volt_old / 1000 : -1,
- freqs.new / 1000, volt ? volt / 1000 : -1);
-
- /* notifiers */
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
+ old_freq / 1000, volt_old ? volt_old / 1000 : -1,
+ new_freq / 1000, volt ? volt / 1000 : -1);
/* scaling up? scale voltage before frequency */
- if (mpu_reg && (freqs.new > freqs.old)) {
+ if (mpu_reg && (new_freq > old_freq)) {
r = regulator_set_voltage(mpu_reg, volt - tol, volt + tol);
if (r < 0) {
dev_warn(mpu_dev, "%s: unable to scale voltage up.\n",
__func__);
- freqs.new = freqs.old;
- goto done;
+ return r;
}
}
- ret = clk_set_rate(mpu_clk, freqs.new * 1000);
+ ret = clk_set_rate(mpu_clk, new_freq * 1000);
/* scaling down? scale voltage after frequency */
- if (mpu_reg && (freqs.new < freqs.old)) {
+ if (mpu_reg && (new_freq < old_freq)) {
r = regulator_set_voltage(mpu_reg, volt - tol, volt + tol);
if (r < 0) {
dev_warn(mpu_dev, "%s: unable to scale voltage down.\n",
__func__);
- ret = clk_set_rate(mpu_clk, freqs.old * 1000);
- freqs.new = freqs.old;
- goto done;
+ clk_set_rate(mpu_clk, old_freq * 1000);
+ return r;
}
}
- freqs.new = omap_getspeed(policy->cpu);
-
-done:
- /* notifiers */
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
return ret;
}
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 28/34] cpufreq: s5pv210: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Cc: Kukjin Kim
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/s5pv210-cpufreq.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/cpufreq/s5pv210-cpufreq.c
b/drivers/cpufreq/s5pv210-cpufreq.c
index 76a4177..efa1080 100644
--- a/drivers/cpufreq/s5pv210-cpufreq.c
+++ b/drivers/cpufreq/s5pv210-cpufreq.c
@@ -26,7 +26,6 @@
static struct clk *cpu_clk;
static struct clk *dmc0_clk;
static struct clk *dmc1_clk;
-static struct cpufreq_freqs freqs;
static DEFINE_MUTEX(set_freq_lock);
/* APLL M,P,S values for 1G/800Mhz */
@@ -179,6 +178,7 @@ static int s5pv210_target(struct cpufreq_policy *policy,
unsigned int index)
unsigned int priv_index;
unsigned int pll_changing = 0;
unsigned int bus_speed_changing = 0;
+ unsigned int old_freq, new_freq;
int arm_volt, int_volt;
int ret = 0;
@@ -193,12 +193,12 @@ static int s5pv210_target(struct cpufreq_policy *policy,
unsigned int index)
goto exit;
}
- freqs.old = s5pv210_getspeed(0);
- freqs.new = s5pv210_freq_table[index].frequency;
+ old_freq = s5pv210_getspeed(0);
+ new_freq = s5pv210_freq_table[index].frequency;
/* Finding current running level index */
if (cpufreq_frequency_table_target(policy, s5pv210_freq_table,
- freqs.old, CPUFREQ_RELATION_H,
+ old_freq, CPUFREQ_RELATION_H,
_index)) {
ret = -EINVAL;
goto exit;
@@ -207,7 +207,7 @@ static int s5pv210_target(struct cpufreq_policy *policy,
unsigned int index)
arm_volt = dvs_conf[index].arm_volt;
int_volt = dvs_conf[index].int_volt;
- if (freqs.new > freqs.old) {
+ if (new_freq > old_freq) {
ret = regulator_set_voltage(arm_regulator,
arm_volt, arm_volt_max);
if (ret)
@@ -219,8 +219,6 @@ static int s5pv210_target(struct cpufreq_policy *policy,
unsigned int index)
goto exit;
}
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
/* Check if there need to change PLL */
if ((index == L0) || (priv_index == L0))
pll_changing = 1;
@@ -431,9 +429,7 @@ static int s5pv210_target(struct cpufreq_policy *policy,
unsigned int index)
}
}
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
- if (freqs.new < freqs.old) {
+ if (new_freq < old_freq) {
regulator_set_voltage(int_regulator,
int_volt, int_volt_max);
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 31/34] cpufreq: sparc: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines: struct cpufreq_freqs freqs; freqs.old = old freq... freqs.new = new freq... cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE); /* Change rate here */ cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE); This is replicated over all cpufreq drivers today and there doesn't exists a good enough reason why this shouldn't be moved to cpufreq core instead. Earlier patches have added support in cpufreq core to do cpufreq notification on frequency change, this one removes it from this driver. Some related minor cleanups are also done along with it. Cc: David S. Miller Cc: sparcli...@vger.kernel.org Signed-off-by: Viresh Kumar --- drivers/cpufreq/sparc-us2e-cpufreq.c | 7 --- drivers/cpufreq/sparc-us3-cpufreq.c | 7 --- 2 files changed, 14 deletions(-) diff --git a/drivers/cpufreq/sparc-us2e-cpufreq.c b/drivers/cpufreq/sparc-us2e-cpufreq.c index 3bf5b8f..62aa23e 100644 --- a/drivers/cpufreq/sparc-us2e-cpufreq.c +++ b/drivers/cpufreq/sparc-us2e-cpufreq.c @@ -251,7 +251,6 @@ static int us2e_freq_target(struct cpufreq_policy *policy, unsigned int index) unsigned long new_bits, new_freq; unsigned long clock_tick, divisor, old_divisor, estar; cpumask_t cpus_allowed; - struct cpufreq_freqs freqs; cpumask_copy(_allowed, tsk_cpus_allowed(current)); set_cpus_allowed_ptr(current, cpumask_of(cpu)); @@ -265,16 +264,10 @@ static int us2e_freq_target(struct cpufreq_policy *policy, unsigned int index) old_divisor = estar_to_divisor(estar); - freqs.old = clock_tick / old_divisor; - freqs.new = new_freq; - cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE); - if (old_divisor != divisor) us2e_transition(estar, new_bits, clock_tick * 1000, old_divisor, divisor); - cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE); - set_cpus_allowed_ptr(current, _allowed); return 0; diff --git a/drivers/cpufreq/sparc-us3-cpufreq.c b/drivers/cpufreq/sparc-us3-cpufreq.c index 2e54d55..724ffbd 100644 --- a/drivers/cpufreq/sparc-us3-cpufreq.c +++ b/drivers/cpufreq/sparc-us3-cpufreq.c @@ -98,7 +98,6 @@ static int us3_freq_target(struct cpufreq_policy *policy, unsigned int index) unsigned int cpu = policy->cpu; unsigned long new_bits, new_freq, reg; cpumask_t cpus_allowed; - struct cpufreq_freqs freqs; cpumask_copy(_allowed, tsk_cpus_allowed(current)); set_cpus_allowed_ptr(current, cpumask_of(cpu)); @@ -124,16 +123,10 @@ static int us3_freq_target(struct cpufreq_policy *policy, unsigned int index) reg = read_safari_cfg(); - freqs.old = get_current_freq(cpu, reg); - freqs.new = new_freq; - cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE); - reg &= ~SAFARI_CFG_DIV_MASK; reg |= new_bits; write_safari_cfg(reg); - cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE); - set_cpus_allowed_ptr(current, _allowed); return 0; -- 1.7.12.rc2.18.g61b472e -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 17/34] cpufreq: longhaul: set CPUFREQ_NO_NOTIFICATION flag
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, but this drivers needs to do this notification itself and so
it sets its CPUFREQ_NO_NOTIFICATION flag.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/longhaul.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/longhaul.c b/drivers/cpufreq/longhaul.c
index 45bafdd..7359043 100644
--- a/drivers/cpufreq/longhaul.c
+++ b/drivers/cpufreq/longhaul.c
@@ -909,6 +909,7 @@ static int longhaul_cpu_init(struct cpufreq_policy *policy)
}
static struct cpufreq_driver longhaul_driver = {
+ .flags = CPUFREQ_NO_NOTIFICATION,
.verify = cpufreq_generic_frequency_table_verify,
.target_index = longhaul_target,
.get= longhaul_get,
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 26/34] cpufreq: pxa: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Cc: Eric Miao
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/pxa2xx-cpufreq.c | 27 ++-
drivers/cpufreq/pxa3xx-cpufreq.c | 12
2 files changed, 6 insertions(+), 33 deletions(-)
diff --git a/drivers/cpufreq/pxa2xx-cpufreq.c b/drivers/cpufreq/pxa2xx-cpufreq.c
index 183bc13..0a0f436 100644
--- a/drivers/cpufreq/pxa2xx-cpufreq.c
+++ b/drivers/cpufreq/pxa2xx-cpufreq.c
@@ -271,7 +271,6 @@ static int pxa_set_target(struct cpufreq_policy *policy,
unsigned int idx)
{
struct cpufreq_frequency_table *pxa_freqs_table;
pxa_freqs_t *pxa_freq_settings;
- struct cpufreq_freqs freqs;
unsigned long flags;
unsigned int new_freq_cpu, new_freq_mem;
unsigned int unused, preset_mdrefr, postset_mdrefr, cclkcfg;
@@ -282,24 +281,17 @@ static int pxa_set_target(struct cpufreq_policy *policy,
unsigned int idx)
new_freq_cpu = pxa_freq_settings[idx].khz;
new_freq_mem = pxa_freq_settings[idx].membus;
- freqs.old = policy->cur;
- freqs.new = new_freq_cpu;
if (freq_debug)
pr_debug("Changing CPU frequency to %d Mhz, (SDRAM %d Mhz)\n",
-freqs.new / 1000, (pxa_freq_settings[idx].div2) ?
+new_freq_cpu / 1000, (pxa_freq_settings[idx].div2) ?
(new_freq_mem / 2000) : (new_freq_mem / 1000));
- if (vcc_core && freqs.new > freqs.old)
+ if (vcc_core && new_freq_cpu > policy->cur) {
ret = pxa_cpufreq_change_voltage(_freq_settings[idx]);
- if (ret)
- return ret;
- /*
-* Tell everyone what we're about to do...
-* you should add a notify client with any platform specific
-* Vcc changing capability
-*/
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
+ if (ret)
+ return ret;
+ }
/* Calculate the next MDREFR. If we're slowing down the SDRAM clock
* we need to preset the smaller DRI before the change. If we're
@@ -350,13 +342,6 @@ static int pxa_set_target(struct cpufreq_policy *policy,
unsigned int idx)
local_irq_restore(flags);
/*
-* Tell everyone what we've just done...
-* you should add a notify client with any platform specific
-* SDRAM refresh timer adjustments
-*/
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
- /*
* Even if voltage setting fails, we don't report it, as the frequency
* change succeeded. The voltage reduction is not a critical failure,
* only power savings will suffer from this.
@@ -365,7 +350,7 @@ static int pxa_set_target(struct cpufreq_policy *policy,
unsigned int idx)
* bug is triggered (seems a deadlock). Should anybody find out where,
* the "return 0" should become a "return ret".
*/
- if (vcc_core && freqs.new < freqs.old)
+ if (vcc_core && new_freq_cpu < policy->cur)
ret = pxa_cpufreq_change_voltage(_freq_settings[idx]);
return 0;
diff --git a/drivers/cpufreq/pxa3xx-cpufreq.c b/drivers/cpufreq/pxa3xx-cpufreq.c
index 132e37d..9384004 100644
--- a/drivers/cpufreq/pxa3xx-cpufreq.c
+++ b/drivers/cpufreq/pxa3xx-cpufreq.c
@@ -158,7 +158,6 @@ static unsigned int pxa3xx_cpufreq_get(unsigned int cpu)
static int pxa3xx_cpufreq_set(struct cpufreq_policy *policy, unsigned int
index)
{
struct pxa3xx_freq_info *next;
- struct cpufreq_freqs freqs;
unsigned long flags;
if (policy->cpu != 0)
@@ -166,22 +165,11 @@ static int pxa3xx_cpufreq_set(struct cpufreq_policy
*policy, unsigned int index)
next = _freqs[index];
- freqs.old = policy->cur;
- freqs.new = next->cpufreq_mhz * 1000;
-
- pr_debug("CPU frequency from %d MHz to %d MHz%s\n",
- freqs.old / 1000, freqs.new / 1000,
- (freqs.old == freqs.new) ? " (skipped)" : "");
-
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
local_irq_save(flags);
__update_core_freq(next);
__update_bus_freq(next);
local_irq_restore(flags);
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
return 0;
}
--
[PATCH 15/34] cpufreq: imx6q: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Cc: Shawn Guo
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/imx6q-cpufreq.c | 39 ---
1 file changed, 16 insertions(+), 23 deletions(-)
diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
index 04a32fb..f35c674 100644
--- a/drivers/cpufreq/imx6q-cpufreq.c
+++ b/drivers/cpufreq/imx6q-cpufreq.c
@@ -41,14 +41,14 @@ static unsigned int imx6q_get_speed(unsigned int cpu)
static int imx6q_set_target(struct cpufreq_policy *policy, unsigned int index)
{
- struct cpufreq_freqs freqs;
struct opp *opp;
unsigned long freq_hz, volt, volt_old;
+ unsigned int old_freq, new_freq;
int ret;
- freqs.new = freq_table[index].frequency;
- freq_hz = freqs.new * 1000;
- freqs.old = clk_get_rate(arm_clk) / 1000;
+ new_freq = freq_table[index].frequency;
+ freq_hz = new_freq * 1000;
+ old_freq = clk_get_rate(arm_clk) / 1000;
rcu_read_lock();
opp = opp_find_freq_ceil(cpu_dev, _hz);
@@ -63,26 +63,23 @@ static int imx6q_set_target(struct cpufreq_policy *policy,
unsigned int index)
volt_old = regulator_get_voltage(arm_reg);
dev_dbg(cpu_dev, "%u MHz, %ld mV --> %u MHz, %ld mV\n",
- freqs.old / 1000, volt_old / 1000,
- freqs.new / 1000, volt / 1000);
-
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
+ old_freq / 1000, volt_old / 1000,
+ new_freq / 1000, volt / 1000);
/* scaling up? scale voltage before frequency */
- if (freqs.new > freqs.old) {
+ if (new_freq > old_freq) {
ret = regulator_set_voltage_tol(arm_reg, volt, 0);
if (ret) {
dev_err(cpu_dev,
"failed to scale vddarm up: %d\n", ret);
- freqs.new = freqs.old;
- goto post_notify;
+ return ret;
}
/*
* Need to increase vddpu and vddsoc for safety
* if we are about to run at 1.2 GHz.
*/
- if (freqs.new == FREQ_1P2_GHZ / 1000) {
+ if (new_freq == FREQ_1P2_GHZ / 1000) {
regulator_set_voltage_tol(pu_reg,
PU_SOC_VOLTAGE_HIGH, 0);
regulator_set_voltage_tol(soc_reg,
@@ -103,13 +100,13 @@ static int imx6q_set_target(struct cpufreq_policy
*policy, unsigned int index)
clk_set_parent(step_clk, pll2_pfd2_396m_clk);
clk_set_parent(pll1_sw_clk, step_clk);
if (freq_hz > clk_get_rate(pll2_pfd2_396m_clk)) {
- clk_set_rate(pll1_sys_clk, freqs.new * 1000);
+ clk_set_rate(pll1_sys_clk, new_freq * 1000);
/*
* If we are leaving 396 MHz set-point, we need to enable
* pll1_sys_clk and disable pll2_pfd2_396m_clk to keep
* their use count correct.
*/
- if (freqs.old * 1000 <= clk_get_rate(pll2_pfd2_396m_clk)) {
+ if (old_freq * 1000 <= clk_get_rate(pll2_pfd2_396m_clk)) {
clk_prepare_enable(pll1_sys_clk);
clk_disable_unprepare(pll2_pfd2_396m_clk);
}
@@ -124,16 +121,15 @@ static int imx6q_set_target(struct cpufreq_policy
*policy, unsigned int index)
}
/* Ensure the arm clock divider is what we expect */
- ret = clk_set_rate(arm_clk, freqs.new * 1000);
+ ret = clk_set_rate(arm_clk, new_freq * 1000);
if (ret) {
dev_err(cpu_dev, "failed to set clock rate: %d\n", ret);
regulator_set_voltage_tol(arm_reg, volt_old, 0);
- freqs.new = freqs.old;
- goto post_notify;
+ return ret;
}
/* scaling down? scale voltage after frequency */
- if (freqs.new < freqs.old) {
+ if (new_freq < old_freq) {
ret = regulator_set_voltage_tol(arm_reg, volt, 0);
if (ret) {
dev_warn(cpu_dev,
@@ -141,7 +137,7 @@ static int imx6q_set_target(struct cpufreq_policy *policy,
unsigned int index)
ret = 0;
[PATCH 18/34] cpufreq: loongson2: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Cc: John Crispin
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/loongson2_cpufreq.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/cpufreq/loongson2_cpufreq.c
b/drivers/cpufreq/loongson2_cpufreq.c
index c33347c..6232d29 100644
--- a/drivers/cpufreq/loongson2_cpufreq.c
+++ b/drivers/cpufreq/loongson2_cpufreq.c
@@ -57,7 +57,6 @@ static int loongson2_cpufreq_target(struct cpufreq_policy
*policy,
{
unsigned int cpu = policy->cpu;
cpumask_t cpus_allowed;
- struct cpufreq_freqs freqs;
unsigned int freq;
cpus_allowed = current->cpus_allowed;
@@ -67,26 +66,11 @@ static int loongson2_cpufreq_target(struct cpufreq_policy
*policy,
((cpu_clock_freq / 1000) *
loongson2_clockmod_table[index].driver_data) / 8;
- pr_debug("cpufreq: requested frequency %u Hz\n",
- loongson2_clockmod_table[index].frequency * 1000);
-
- freqs.old = loongson2_cpufreq_get(cpu);
- freqs.new = freq;
- freqs.flags = 0;
-
- /* notifiers */
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
set_cpus_allowed_ptr(current, _allowed);
/* setting the cpu frequency */
clk_set_rate(cpuclk, freq);
- /* notifiers */
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
- pr_debug("cpufreq: set frequency %u kHz\n", freq);
-
return 0;
}
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 16/34] cpufreq: kirkwood: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Cc: Andrew Lunn
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/kirkwood-cpufreq.c | 54 ++
1 file changed, 20 insertions(+), 34 deletions(-)
diff --git a/drivers/cpufreq/kirkwood-cpufreq.c
b/drivers/cpufreq/kirkwood-cpufreq.c
index c3d6987..fcf461e 100644
--- a/drivers/cpufreq/kirkwood-cpufreq.c
+++ b/drivers/cpufreq/kirkwood-cpufreq.c
@@ -58,48 +58,34 @@ static unsigned int
kirkwood_cpufreq_get_cpu_frequency(unsigned int cpu)
static int kirkwood_cpufreq_target(struct cpufreq_policy *policy,
unsigned int index)
{
- struct cpufreq_freqs freqs;
unsigned int state = kirkwood_freq_table[index].driver_data;
unsigned long reg;
- freqs.old = kirkwood_cpufreq_get_cpu_frequency(0);
- freqs.new = kirkwood_freq_table[index].frequency;
+ local_irq_disable();
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
+ /* Disable interrupts to the CPU */
+ reg = readl_relaxed(priv.base);
+ reg |= CPU_SW_INT_BLK;
+ writel_relaxed(reg, priv.base);
- dev_dbg(priv.dev, "Attempting to set frequency to %i KHz\n",
- kirkwood_freq_table[index].frequency);
- dev_dbg(priv.dev, "old frequency was %i KHz\n",
- kirkwood_cpufreq_get_cpu_frequency(0));
-
- if (freqs.old != freqs.new) {
- local_irq_disable();
-
- /* Disable interrupts to the CPU */
- reg = readl_relaxed(priv.base);
- reg |= CPU_SW_INT_BLK;
- writel_relaxed(reg, priv.base);
-
- switch (state) {
- case STATE_CPU_FREQ:
- clk_disable(priv.powersave_clk);
- break;
- case STATE_DDR_FREQ:
- clk_enable(priv.powersave_clk);
- break;
- }
+ switch (state) {
+ case STATE_CPU_FREQ:
+ clk_disable(priv.powersave_clk);
+ break;
+ case STATE_DDR_FREQ:
+ clk_enable(priv.powersave_clk);
+ break;
+ }
- /* Wait-for-Interrupt, while the hardware changes frequency */
- cpu_do_idle();
+ /* Wait-for-Interrupt, while the hardware changes frequency */
+ cpu_do_idle();
- /* Enable interrupts to the CPU */
- reg = readl_relaxed(priv.base);
- reg &= ~CPU_SW_INT_BLK;
- writel_relaxed(reg, priv.base);
+ /* Enable interrupts to the CPU */
+ reg = readl_relaxed(priv.base);
+ reg &= ~CPU_SW_INT_BLK;
+ writel_relaxed(reg, priv.base);
- local_irq_enable();
- }
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
+ local_irq_enable();
return 0;
}
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 22/34] cpufreq: pasemi: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/pasemi-cpufreq.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/cpufreq/pasemi-cpufreq.c b/drivers/cpufreq/pasemi-cpufreq.c
index aaee5fa..4d69958 100644
--- a/drivers/cpufreq/pasemi-cpufreq.c
+++ b/drivers/cpufreq/pasemi-cpufreq.c
@@ -51,8 +51,6 @@
static void __iomem *sdcpwr_mapbase;
static void __iomem *sdcasr_mapbase;
-static DEFINE_MUTEX(pas_switch_mutex);
-
/* Current astate, is used when waking up from power savings on
* one core, in case the other core has switched states during
* the idle time.
@@ -249,15 +247,8 @@ static int pas_cpufreq_cpu_exit(struct cpufreq_policy
*policy)
static int pas_cpufreq_target(struct cpufreq_policy *policy,
unsigned int pas_astate_new)
{
- struct cpufreq_freqs freqs;
int i;
- freqs.old = policy->cur;
- freqs.new = pas_freqs[pas_astate_new].frequency;
-
- mutex_lock(_switch_mutex);
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
pr_debug("setting frequency for cpu %d to %d kHz, 1/%d of max
frequency\n",
policy->cpu,
pas_freqs[pas_astate_new].frequency,
@@ -268,10 +259,7 @@ static int pas_cpufreq_target(struct cpufreq_policy
*policy,
for_each_online_cpu(i)
set_astate(i, pas_astate_new);
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
- mutex_unlock(_switch_mutex);
-
- ppc_proc_freq = freqs.new * 1000ul;
+ ppc_proc_freq = pas_freqs[pas_astate_new].frequency * 1000ul;
return 0;
}
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 24/34] cpufreq: powernow: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/powernow-k6.c | 8
drivers/cpufreq/powernow-k7.c | 11 +--
drivers/cpufreq/powernow-k8.c | 15 +--
3 files changed, 2 insertions(+), 32 deletions(-)
diff --git a/drivers/cpufreq/powernow-k6.c b/drivers/cpufreq/powernow-k6.c
index 643e795..fedbe87 100644
--- a/drivers/cpufreq/powernow-k6.c
+++ b/drivers/cpufreq/powernow-k6.c
@@ -73,18 +73,12 @@ static int powernow_k6_target(struct cpufreq_policy *policy,
{
unsigned long outvalue = 0, invalue = 0;
unsigned long msrval;
- struct cpufreq_freqs freqs;
if (clock_ratio[best_i].driver_data > max_multiplier) {
printk(KERN_ERR PFX "invalid target frequency\n");
return -EINVAL;
}
- freqs.old = busfreq * powernow_k6_get_cpu_multiplier();
- freqs.new = busfreq * clock_ratio[best_i].driver_data;
-
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
/* we now need to transform best_i to the BVC format, see AMD#23446 */
outvalue = (1<<12) | (1<<10) | (1<<9) | (best_i<<5);
@@ -98,8 +92,6 @@ static int powernow_k6_target(struct cpufreq_policy *policy,
msrval = POWERNOW_IOPORT + 0x0;
wrmsr(MSR_K6_EPMR, msrval, 0); /* disable it again */
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
return 0;
}
diff --git a/drivers/cpufreq/powernow-k7.c b/drivers/cpufreq/powernow-k7.c
index 946708a..8e52463 100644
--- a/drivers/cpufreq/powernow-k7.c
+++ b/drivers/cpufreq/powernow-k7.c
@@ -251,7 +251,6 @@ static void change_VID(int vid)
static int powernow_target(struct cpufreq_policy *policy, unsigned int index)
{
u8 fid, vid;
- struct cpufreq_freqs freqs;
union msr_fidvidstatus fidvidstatus;
int cfid;
@@ -265,18 +264,13 @@ static int powernow_target(struct cpufreq_policy *policy,
unsigned int index)
rdmsrl(MSR_K7_FID_VID_STATUS, fidvidstatus.val);
cfid = fidvidstatus.bits.CFID;
- freqs.old = fsb * fid_codes[cfid] / 10;
-
- freqs.new = powernow_table[index].frequency;
-
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Now do the magic poking into the MSRs. */
if (have_a0 == 1) /* A0 errata 5 */
local_irq_disable();
- if (freqs.old > freqs.new) {
+ if (fsb * fid_codes[cfid] / 10 > powernow_table[index].frequency) {
/* Going down, so change FID first */
change_FID(fid);
change_VID(vid);
@@ -286,12 +280,9 @@ static int powernow_target(struct cpufreq_policy *policy,
unsigned int index)
change_FID(fid);
}
-
if (have_a0 == 1)
local_irq_enable();
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
return 0;
}
diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow-k8.c
index 62a1ce4..b00eabe 100644
--- a/drivers/cpufreq/powernow-k8.c
+++ b/drivers/cpufreq/powernow-k8.c
@@ -931,8 +931,6 @@ static int transition_frequency_fidvid(struct
powernow_k8_data *data,
struct cpufreq_policy *policy;
u32 fid = 0;
u32 vid = 0;
- int res;
- struct cpufreq_freqs freqs;
pr_debug("cpu %d transition to index %u\n", smp_processor_id(), index);
@@ -957,22 +955,11 @@ static int transition_frequency_fidvid(struct
powernow_k8_data *data,
pr_debug("cpu %d, changing to fid 0x%x, vid 0x%x\n",
smp_processor_id(), fid, vid);
- freqs.old = find_khz_freq_from_fid(data->currfid);
- freqs.new = find_khz_freq_from_fid(fid);
policy = cpufreq_cpu_get(smp_processor_id());
cpufreq_cpu_put(policy);
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
- res = transition_fid_vid(data, fid, vid);
- if (res)
- freqs.new = freqs.old;
- else
- freqs.new = find_khz_freq_from_fid(data->currfid);
-
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
- return res;
+ return transition_fid_vid(data, fid, vid);
}
struct powernowk8_target_arg {
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
[PATCH 19/34] cpufreq: maple: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Cc: Dmitry Eremin-Solenikov
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/maple-cpufreq.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/drivers/cpufreq/maple-cpufreq.c b/drivers/cpufreq/maple-cpufreq.c
index b508147..45db7a2 100644
--- a/drivers/cpufreq/maple-cpufreq.c
+++ b/drivers/cpufreq/maple-cpufreq.c
@@ -69,8 +69,6 @@ static struct cpufreq_frequency_table maple_cpu_freqs[] = {
*/
static int maple_pmode_cur;
-static DEFINE_MUTEX(maple_switch_mutex);
-
static const u32 *maple_pmode_data;
static int maple_pmode_max;
@@ -133,21 +131,7 @@ static int maple_scom_query_freq(void)
static int maple_cpufreq_target(struct cpufreq_policy *policy,
unsigned int index)
{
- struct cpufreq_freqs freqs;
- int rc;
-
- mutex_lock(_switch_mutex);
-
- freqs.old = maple_cpu_freqs[maple_pmode_cur].frequency;
- freqs.new = maple_cpu_freqs[index].frequency;
-
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
- rc = maple_scom_switch_freq(index);
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
- mutex_unlock(_switch_mutex);
-
- return rc;
+ return maple_scom_switch_freq(index);
}
static unsigned int maple_cpufreq_get_speed(unsigned int cpu)
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 23/34] cpufreq: pmac: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/pmac32-cpufreq.c | 20
drivers/cpufreq/pmac64-cpufreq.c | 18 +-
2 files changed, 5 insertions(+), 33 deletions(-)
diff --git a/drivers/cpufreq/pmac32-cpufreq.c b/drivers/cpufreq/pmac32-cpufreq.c
index 47c227c..c8f5d2c 100644
--- a/drivers/cpufreq/pmac32-cpufreq.c
+++ b/drivers/cpufreq/pmac32-cpufreq.c
@@ -330,21 +330,11 @@ static int pmu_set_cpu_speed(int low_speed)
return 0;
}
-static int do_set_cpu_speed(struct cpufreq_policy *policy, int speed_mode,
- int notify)
+static int do_set_cpu_speed(struct cpufreq_policy *policy, int speed_mode)
{
- struct cpufreq_freqs freqs;
unsigned long l3cr;
static unsigned long prev_l3cr;
- freqs.old = cur_freq;
- freqs.new = (speed_mode == CPUFREQ_HIGH) ? hi_freq : low_freq;
-
- if (freqs.old == freqs.new)
- return 0;
-
- if (notify)
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
if (speed_mode == CPUFREQ_LOW &&
cpu_has_feature(CPU_FTR_L3CR)) {
l3cr = _get_L3CR();
@@ -360,8 +350,6 @@ static int do_set_cpu_speed(struct cpufreq_policy *policy,
int speed_mode,
if ((prev_l3cr & L3CR_L3E) && l3cr != prev_l3cr)
_set_L3CR(prev_l3cr);
}
- if (notify)
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
cur_freq = (speed_mode == CPUFREQ_HIGH) ? hi_freq : low_freq;
return 0;
@@ -377,7 +365,7 @@ static int pmac_cpufreq_target( struct cpufreq_policy
*policy,
{
int rc;
- rc = do_set_cpu_speed(policy, index, 1);
+ rc = do_set_cpu_speed(policy, index);
ppc_proc_freq = cur_freq * 1000ul;
return rc;
@@ -424,7 +412,7 @@ static int pmac_cpufreq_suspend(struct cpufreq_policy
*policy)
no_schedule = 1;
sleep_freq = cur_freq;
if (cur_freq == low_freq && !is_pmu_based)
- do_set_cpu_speed(policy, CPUFREQ_HIGH, 0);
+ do_set_cpu_speed(policy, CPUFREQ_HIGH);
return 0;
}
@@ -441,7 +429,7 @@ static int pmac_cpufreq_resume(struct cpufreq_policy
*policy)
* probably high speed due to our suspend() routine
*/
do_set_cpu_speed(policy, sleep_freq == low_freq ?
-CPUFREQ_LOW : CPUFREQ_HIGH, 0);
+CPUFREQ_LOW : CPUFREQ_HIGH);
ppc_proc_freq = cur_freq * 1000ul;
diff --git a/drivers/cpufreq/pmac64-cpufreq.c b/drivers/cpufreq/pmac64-cpufreq.c
index 63f9642..2557f16 100644
--- a/drivers/cpufreq/pmac64-cpufreq.c
+++ b/drivers/cpufreq/pmac64-cpufreq.c
@@ -78,8 +78,6 @@ static void (*g5_switch_volt)(int speed_mode);
static int (*g5_switch_freq)(int speed_mode);
static int (*g5_query_freq)(void);
-static DEFINE_MUTEX(g5_switch_mutex);
-
static unsigned long transition_latency;
#ifdef CONFIG_PMAC_SMU
@@ -313,21 +311,7 @@ static int g5_pfunc_query_freq(void)
static int g5_cpufreq_target(struct cpufreq_policy *policy, unsigned int index)
{
- struct cpufreq_freqs freqs;
- int rc;
-
- mutex_lock(_switch_mutex);
-
- freqs.old = g5_cpu_freqs[g5_pmode_cur].frequency;
- freqs.new = g5_cpu_freqs[index].frequency;
-
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
- rc = g5_switch_freq(index);
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
- mutex_unlock(_switch_mutex);
-
- return rc;
+ return g5_switch_freq(index);
}
static unsigned int g5_cpufreq_get_speed(unsigned int cpu)
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 27/34] cpufreq: s3c: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Cc: Kukjin Kim
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/s3c2416-cpufreq.c | 21 -
drivers/cpufreq/s3c64xx-cpufreq.c | 48 +--
2 files changed, 20 insertions(+), 49 deletions(-)
diff --git a/drivers/cpufreq/s3c2416-cpufreq.c
b/drivers/cpufreq/s3c2416-cpufreq.c
index 9b22cc4..0e13914 100644
--- a/drivers/cpufreq/s3c2416-cpufreq.c
+++ b/drivers/cpufreq/s3c2416-cpufreq.c
@@ -220,7 +220,7 @@ static int s3c2416_cpufreq_set_target(struct cpufreq_policy
*policy,
unsigned int index)
{
struct s3c2416_data *s3c_freq = _cpufreq;
- struct cpufreq_freqs freqs;
+ unsigned int new_freq;
int idx, ret, to_dvs = 0;
mutex_lock(_lock);
@@ -237,25 +237,14 @@ static int s3c2416_cpufreq_set_target(struct
cpufreq_policy *policy,
goto out;
}
- freqs.flags = 0;
- freqs.old = s3c_freq->is_dvs ? FREQ_DVS
-: clk_get_rate(s3c_freq->armclk) / 1000;
-
/* When leavin dvs mode, always switch the armdiv to the hclk rate
* The S3C2416 has stability issues when switching directly to
* higher frequencies.
*/
- freqs.new = (s3c_freq->is_dvs && !to_dvs)
+ new_freq = (s3c_freq->is_dvs && !to_dvs)
? clk_get_rate(s3c_freq->hclk) / 1000
: s3c_freq->freq_table[index].frequency;
- pr_debug("cpufreq: Transition %d-%dkHz\n", freqs.old, freqs.new);
-
- if (!to_dvs && freqs.old == freqs.new)
- goto out;
-
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
if (to_dvs) {
pr_debug("cpufreq: enter dvs\n");
ret = s3c2416_cpufreq_enter_dvs(s3c_freq, idx);
@@ -263,12 +252,10 @@ static int s3c2416_cpufreq_set_target(struct
cpufreq_policy *policy,
pr_debug("cpufreq: leave dvs\n");
ret = s3c2416_cpufreq_leave_dvs(s3c_freq, idx);
} else {
- pr_debug("cpufreq: change armdiv to %dkHz\n", freqs.new);
- ret = s3c2416_cpufreq_set_armdiv(s3c_freq, freqs.new);
+ pr_debug("cpufreq: change armdiv to %dkHz\n", new_freq);
+ ret = s3c2416_cpufreq_set_armdiv(s3c_freq, new_freq);
}
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
out:
mutex_unlock(_lock);
diff --git a/drivers/cpufreq/s3c64xx-cpufreq.c
b/drivers/cpufreq/s3c64xx-cpufreq.c
index 5357dc4..a983559 100644
--- a/drivers/cpufreq/s3c64xx-cpufreq.c
+++ b/drivers/cpufreq/s3c64xx-cpufreq.c
@@ -65,54 +65,46 @@ static unsigned int s3c64xx_cpufreq_get_speed(unsigned int
cpu)
static int s3c64xx_cpufreq_set_target(struct cpufreq_policy *policy,
unsigned int index)
{
- int ret;
- struct cpufreq_freqs freqs;
struct s3c64xx_dvfs *dvfs;
+ unsigned int old_freq, new_freq;
+ int ret;
- freqs.old = clk_get_rate(armclk) / 1000;
- freqs.new = s3c64xx_freq_table[index].frequency;
- freqs.flags = 0;
+ old_freq = clk_get_rate(armclk) / 1000;
+ new_freq = s3c64xx_freq_table[index].frequency;
dvfs = _dvfs_table[s3c64xx_freq_table[index].driver_data];
- pr_debug("Transition %d-%dkHz\n", freqs.old, freqs.new);
-
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
#ifdef CONFIG_REGULATOR
- if (vddarm && freqs.new > freqs.old) {
+ if (vddarm && new_freq > old_freq) {
ret = regulator_set_voltage(vddarm,
dvfs->vddarm_min,
dvfs->vddarm_max);
if (ret != 0) {
pr_err("Failed to set VDDARM for %dkHz: %d\n",
- freqs.new, ret);
- freqs.new = freqs.old;
- goto post_notify;
+ new_freq, ret);
+ return ret;
}
}
#endif
- ret = clk_set_rate(armclk, freqs.new * 1000);
+ ret = clk_set_rate(armclk, new_freq * 1000);
if (ret < 0) {
pr_err("Failed to set rate %dkHz: %d\n",
-
[PATCH 30/34] cpufreq: sc520: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/sc520_freq.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/cpufreq/sc520_freq.c b/drivers/cpufreq/sc520_freq.c
index 6c86452..6adb354 100644
--- a/drivers/cpufreq/sc520_freq.c
+++ b/drivers/cpufreq/sc520_freq.c
@@ -56,17 +56,8 @@ static unsigned int sc520_freq_get_cpu_frequency(unsigned
int cpu)
static int sc520_freq_target(struct cpufreq_policy *policy, unsigned int state)
{
- struct cpufreq_freqsfreqs;
u8 clockspeed_reg;
- freqs.old = sc520_freq_get_cpu_frequency(0);
- freqs.new = sc520_freq_table[state].frequency;
-
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
- pr_debug("attempting to set frequency to %i kHz\n",
- sc520_freq_table[state].frequency);
-
local_irq_disable();
clockspeed_reg = *cpuctl & ~0x03;
@@ -74,8 +65,6 @@ static int sc520_freq_target(struct cpufreq_policy *policy,
unsigned int state)
local_irq_enable();
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
return 0;
}
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 25/34] cpufreq: ppc: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/ppc-corenet-cpufreq.c | 19 +--
drivers/cpufreq/ppc_cbe_cpufreq.c | 19 +--
2 files changed, 2 insertions(+), 36 deletions(-)
diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c
b/drivers/cpufreq/ppc-corenet-cpufreq.c
index 79d8e9c..3f7be46 100644
--- a/drivers/cpufreq/ppc-corenet-cpufreq.c
+++ b/drivers/cpufreq/ppc-corenet-cpufreq.c
@@ -69,8 +69,6 @@ static const struct soc_data sdata[] = {
static u32 min_cpufreq;
static const u32 *fmask;
-/* serialize frequency changes */
-static DEFINE_MUTEX(cpufreq_lock);
static DEFINE_PER_CPU(struct cpu_data *, cpu_data);
/* cpumask in a cluster */
@@ -253,26 +251,11 @@ static int __exit corenet_cpufreq_cpu_exit(struct
cpufreq_policy *policy)
static int corenet_cpufreq_target(struct cpufreq_policy *policy,
unsigned int index)
{
- struct cpufreq_freqs freqs;
struct clk *parent;
- int ret;
struct cpu_data *data = per_cpu(cpu_data, policy->cpu);
- freqs.old = policy->cur;
- freqs.new = data->table[index].frequency;
-
- mutex_lock(_lock);
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
parent = of_clk_get(data->parent, data->table[index].driver_data);
- ret = clk_set_parent(data->clk, parent);
- if (ret)
- freqs.new = freqs.old;
-
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
- mutex_unlock(_lock);
-
- return ret;
+ return clk_set_parent(data->clk, parent);
}
static struct cpufreq_driver ppc_corenet_cpufreq_driver = {
diff --git a/drivers/cpufreq/ppc_cbe_cpufreq.c
b/drivers/cpufreq/ppc_cbe_cpufreq.c
index 52f707d..e42ca9c 100644
--- a/drivers/cpufreq/ppc_cbe_cpufreq.c
+++ b/drivers/cpufreq/ppc_cbe_cpufreq.c
@@ -30,9 +30,6 @@
#include "ppc_cbe_cpufreq.h"
-static DEFINE_MUTEX(cbe_switch_mutex);
-
-
/* the CBE supports an 8 step frequency scaling */
static struct cpufreq_frequency_table cbe_freqs[] = {
{1, 0},
@@ -131,27 +128,13 @@ static int cbe_cpufreq_cpu_init(struct cpufreq_policy
*policy)
static int cbe_cpufreq_target(struct cpufreq_policy *policy,
unsigned int cbe_pmode_new)
{
- int rc;
- struct cpufreq_freqs freqs;
-
- freqs.old = policy->cur;
- freqs.new = cbe_freqs[cbe_pmode_new].frequency;
-
- mutex_lock(_switch_mutex);
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
pr_debug("setting frequency for cpu %d to %d kHz, " \
"1/%d of max frequency\n",
policy->cpu,
cbe_freqs[cbe_pmode_new].frequency,
cbe_freqs[cbe_pmode_new].driver_data);
- rc = set_pmode(policy->cpu, cbe_pmode_new);
-
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
- mutex_unlock(_switch_mutex);
-
- return rc;
+ return set_pmode(policy->cpu, cbe_pmode_new);
}
static struct cpufreq_driver cbe_cpufreq_driver = {
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/34] cpufreq: elanfreq: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/elanfreq.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/cpufreq/elanfreq.c b/drivers/cpufreq/elanfreq.c
index 4ab4153..de08acf 100644
--- a/drivers/cpufreq/elanfreq.c
+++ b/drivers/cpufreq/elanfreq.c
@@ -108,17 +108,6 @@ static unsigned int elanfreq_get_cpu_frequency(unsigned
int cpu)
static int elanfreq_target(struct cpufreq_policy *policy,
unsigned int state)
{
- struct cpufreq_freqsfreqs;
-
- freqs.old = elanfreq_get_cpu_frequency(0);
- freqs.new = elan_multiplier[state].clock;
-
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
- printk(KERN_INFO "elanfreq: attempting to set frequency to %i kHz\n",
- elan_multiplier[state].clock);
-
-
/*
* Access to the Elan's internal registers is indexed via
* 0x22: Chip Setup & Control Register Index Register (CSCI)
@@ -149,8 +138,6 @@ static int elanfreq_target(struct cpufreq_policy *policy,
udelay(1);
local_irq_enable();
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
return 0;
}
/*
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/34] cpufreq: dbx500: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Cc: Linus Walleij
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/dbx500-cpufreq.c | 22 +-
1 file changed, 1 insertion(+), 21 deletions(-)
diff --git a/drivers/cpufreq/dbx500-cpufreq.c b/drivers/cpufreq/dbx500-cpufreq.c
index d6d6b8c..060430c 100644
--- a/drivers/cpufreq/dbx500-cpufreq.c
+++ b/drivers/cpufreq/dbx500-cpufreq.c
@@ -22,28 +22,8 @@ static struct clk *armss_clk;
static int dbx500_cpufreq_target(struct cpufreq_policy *policy,
unsigned int index)
{
- struct cpufreq_freqs freqs;
- int ret;
-
- freqs.old = policy->cur;
- freqs.new = freq_table[index].frequency;
-
- /* pre-change notification */
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
/* update armss clk frequency */
- ret = clk_set_rate(armss_clk, freqs.new * 1000);
-
- if (ret) {
- pr_err("dbx500-cpufreq: Failed to set armss_clk to %d Hz: error
%d\n",
- freqs.new * 1000, ret);
- freqs.new = freqs.old;
- }
-
- /* post change notification */
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
- return ret;
+ return clk_set_rate(armss_clk, freq_table[index].frequency * 1000);
}
static unsigned int dbx500_cpufreq_getspeed(unsigned int cpu)
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/34] cpufreq: cris: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Cc: Jesper Nilsson
Cc: Mikael Starvik
Cc: linux-cris-ker...@axis.com
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cris-artpec3-cpufreq.c | 8
drivers/cpufreq/cris-etraxfs-cpufreq.c | 8
2 files changed, 16 deletions(-)
diff --git a/drivers/cpufreq/cris-artpec3-cpufreq.c
b/drivers/cpufreq/cris-artpec3-cpufreq.c
index dace19d..e31e1e5 100644
--- a/drivers/cpufreq/cris-artpec3-cpufreq.c
+++ b/drivers/cpufreq/cris-artpec3-cpufreq.c
@@ -29,15 +29,9 @@ static unsigned int cris_freq_get_cpu_frequency(unsigned int
cpu)
static int cris_freq_target(struct cpufreq_policy *policy, unsigned int state)
{
- struct cpufreq_freqs freqs;
reg_clkgen_rw_clk_ctrl clk_ctrl;
clk_ctrl = REG_RD(clkgen, regi_clkgen, rw_clk_ctrl);
- freqs.old = cris_freq_get_cpu_frequency(policy->cpu);
- freqs.new = cris_freq_table[state].frequency;
-
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
local_irq_disable();
/* Even though we may be SMP they will share the same clock
@@ -50,8 +44,6 @@ static int cris_freq_target(struct cpufreq_policy *policy,
unsigned int state)
local_irq_enable();
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
return 0;
}
diff --git a/drivers/cpufreq/cris-etraxfs-cpufreq.c
b/drivers/cpufreq/cris-etraxfs-cpufreq.c
index 4d40d9df..9d577d0 100644
--- a/drivers/cpufreq/cris-etraxfs-cpufreq.c
+++ b/drivers/cpufreq/cris-etraxfs-cpufreq.c
@@ -29,15 +29,9 @@ static unsigned int cris_freq_get_cpu_frequency(unsigned int
cpu)
static int cris_freq_target(struct cpufreq_policy *policy, unsigned int state)
{
- struct cpufreq_freqs freqs;
reg_config_rw_clk_ctrl clk_ctrl;
clk_ctrl = REG_RD(config, regi_config, rw_clk_ctrl);
- freqs.old = cris_freq_get_cpu_frequency(policy->cpu);
- freqs.new = cris_freq_table[state].frequency;
-
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
local_irq_disable();
/* Even though we may be SMP they will share the same clock
@@ -50,8 +44,6 @@ static int cris_freq_target(struct cpufreq_policy *policy,
unsigned int state)
local_irq_enable();
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
return 0;
}
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/34] cpufreq: cpu0: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Cc: Shawn Guo
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq-cpu0.c | 33 -
1 file changed, 12 insertions(+), 21 deletions(-)
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 4014925..ddd9010 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -36,20 +36,19 @@ static unsigned int cpu0_get_speed(unsigned int cpu)
static int cpu0_set_target(struct cpufreq_policy *policy, unsigned int index)
{
- struct cpufreq_freqs freqs;
struct opp *opp;
unsigned long volt = 0, volt_old = 0, tol = 0;
+ unsigned int old_freq, new_freq;
long freq_Hz, freq_exact;
int ret;
freq_Hz = clk_round_rate(cpu_clk, freq_table[index].frequency * 1000);
if (freq_Hz < 0)
freq_Hz = freq_table[index].frequency * 1000;
- freq_exact = freq_Hz;
- freqs.new = freq_Hz / 1000;
- freqs.old = clk_get_rate(cpu_clk) / 1000;
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
+ freq_exact = freq_Hz;
+ new_freq = freq_Hz / 1000;
+ old_freq = clk_get_rate(cpu_clk) / 1000;
if (!IS_ERR(cpu_reg)) {
rcu_read_lock();
@@ -57,9 +56,7 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
unsigned int index)
if (IS_ERR(opp)) {
rcu_read_unlock();
pr_err("failed to find OPP for %ld\n", freq_Hz);
- freqs.new = freqs.old;
- ret = PTR_ERR(opp);
- goto post_notify;
+ return PTR_ERR(opp);
}
volt = opp_get_voltage(opp);
rcu_read_unlock();
@@ -68,16 +65,15 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
unsigned int index)
}
pr_debug("%u MHz, %ld mV --> %u MHz, %ld mV\n",
-freqs.old / 1000, volt_old ? volt_old / 1000 : -1,
-freqs.new / 1000, volt ? volt / 1000 : -1);
+old_freq / 1000, volt_old ? volt_old / 1000 : -1,
+new_freq / 1000, volt ? volt / 1000 : -1);
/* scaling up? scale voltage before frequency */
- if (!IS_ERR(cpu_reg) && freqs.new > freqs.old) {
+ if (!IS_ERR(cpu_reg) && new_freq > old_freq) {
ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
if (ret) {
pr_err("failed to scale voltage up: %d\n", ret);
- freqs.new = freqs.old;
- goto post_notify;
+ return ret;
}
}
@@ -86,23 +82,18 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
unsigned int index)
pr_err("failed to set clock rate: %d\n", ret);
if (!IS_ERR(cpu_reg))
regulator_set_voltage_tol(cpu_reg, volt_old, tol);
- freqs.new = freqs.old;
- goto post_notify;
+ return ret;
}
/* scaling down? scale voltage after frequency */
- if (!IS_ERR(cpu_reg) && freqs.new < freqs.old) {
+ if (!IS_ERR(cpu_reg) && new_freq < old_freq) {
ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
if (ret) {
pr_err("failed to scale voltage down: %d\n", ret);
- clk_set_rate(cpu_clk, freqs.old * 1000);
- freqs.new = freqs.old;
+ clk_set_rate(cpu_clk, old_freq * 1000);
}
}
-post_notify:
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
return ret;
}
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/34] cpufreq: davinci: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Cc: Sekhar Nori
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/davinci-cpufreq.c | 30 ++
1 file changed, 10 insertions(+), 20 deletions(-)
diff --git a/drivers/cpufreq/davinci-cpufreq.c
b/drivers/cpufreq/davinci-cpufreq.c
index 07ea6c0..7fcae0c 100644
--- a/drivers/cpufreq/davinci-cpufreq.c
+++ b/drivers/cpufreq/davinci-cpufreq.c
@@ -70,46 +70,36 @@ static unsigned int davinci_getspeed(unsigned int cpu)
static int davinci_target(struct cpufreq_policy *policy, unsigned int idx)
{
- int ret = 0;
- struct cpufreq_freqs freqs;
struct davinci_cpufreq_config *pdata = cpufreq.dev->platform_data;
struct clk *armclk = cpufreq.armclk;
+ unsigned int old_freq, new_freq;
+ int ret = 0;
- freqs.old = davinci_getspeed(0);
- freqs.new = pdata->freq_table[idx].frequency;
-
- dev_dbg(cpufreq.dev, "transition: %u --> %u\n", freqs.old, freqs.new);
-
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
+ old_freq = davinci_getspeed(0);
+ new_freq = pdata->freq_table[idx].frequency;
/* if moving to higher frequency, up the voltage beforehand */
- if (pdata->set_voltage && freqs.new > freqs.old) {
+ if (pdata->set_voltage && new_freq > old_freq) {
ret = pdata->set_voltage(idx);
if (ret)
- goto out;
+ return ret;
}
ret = clk_set_rate(armclk, idx);
if (ret)
- goto out;
+ return ret;
if (cpufreq.asyncclk) {
ret = clk_set_rate(cpufreq.asyncclk, cpufreq.asyncrate);
if (ret)
- goto out;
+ return ret;
}
/* if moving to lower freq, lower the voltage after lowering freq */
- if (pdata->set_voltage && freqs.new < freqs.old)
+ if (pdata->set_voltage && new_freq < old_freq)
pdata->set_voltage(idx);
-out:
- if (ret)
- freqs.new = freqs.old;
-
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
- return ret;
+ return 0;
}
static int davinci_cpu_init(struct cpufreq_policy *policy)
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/34] cpufreq: blackfin: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Cc: Steven Miao
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/blackfin-cpufreq.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/cpufreq/blackfin-cpufreq.c
b/drivers/cpufreq/blackfin-cpufreq.c
index 12528b2..e9e63fc 100644
--- a/drivers/cpufreq/blackfin-cpufreq.c
+++ b/drivers/cpufreq/blackfin-cpufreq.c
@@ -132,27 +132,23 @@ static int bfin_target(struct cpufreq_policy *policy,
unsigned int index)
#ifndef CONFIG_BF60x
unsigned int plldiv;
#endif
- struct cpufreq_freqs freqs;
static unsigned long lpj_ref;
static unsigned int lpj_ref_freq;
+ unsigned int old_freq, new_freq;
int ret = 0;
#if defined(CONFIG_CYCLES_CLOCKSOURCE)
cycles_t cycles;
#endif
- freqs.old = bfin_getfreq_khz(0);
- freqs.new = bfin_freq_table[index].frequency;
+ old_freq = bfin_getfreq_khz(0);
+ new_freq = bfin_freq_table[index].frequency;
- pr_debug("cpufreq: changing cclk to %lu; target = %u, oldfreq = %u\n",
- freqs.new, freqs.new, freqs.old);
-
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
#ifndef CONFIG_BF60x
plldiv = (bfin_read_PLL_DIV() & SSEL) | dpm_state_table[index].csel;
bfin_write_PLL_DIV(plldiv);
#else
- ret = cpu_set_cclk(policy->cpu, freqs.new * 1000);
+ ret = cpu_set_cclk(policy->cpu, new_freq * 1000);
if (ret != 0) {
WARN_ONCE(ret, "cpufreq set freq failed %d\n", ret);
return ret;
@@ -168,17 +164,13 @@ static int bfin_target(struct cpufreq_policy *policy,
unsigned int index)
#endif
if (!lpj_ref_freq) {
lpj_ref = loops_per_jiffy;
- lpj_ref_freq = freqs.old;
+ lpj_ref_freq = old_freq;
}
- if (freqs.new != freqs.old) {
+ if (new_freq != old_freq) {
loops_per_jiffy = cpufreq_scale(lpj_ref,
- lpj_ref_freq, freqs.new);
+ lpj_ref_freq, new_freq);
}
- /* TODO: just test case for cycles clock source, remove later */
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
- pr_debug("cpufreq: done\n");
return ret;
}
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/34] cpufreq: exynos: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Cc: Kukjin Kim
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/exynos-cpufreq.c | 28
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index b1db082..0f87a29 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -25,7 +25,6 @@
static struct exynos_dvfs_info *exynos_info;
static struct regulator *arm_regulator;
-static struct cpufreq_freqs freqs;
static unsigned int locking_frequency;
static bool frequency_locked;
@@ -59,18 +58,18 @@ static int exynos_cpufreq_scale(unsigned int target_freq)
struct cpufreq_policy *policy = cpufreq_cpu_get(0);
unsigned int arm_volt, safe_arm_volt = 0;
unsigned int mpll_freq_khz = exynos_info->mpll_freq_khz;
+ unsigned int old_freq;
int index, old_index;
int ret = 0;
- freqs.old = policy->cur;
- freqs.new = target_freq;
+ old_freq = policy->cur;
/*
* The policy max have been changed so that we cannot get proper
* old_index with cpufreq_frequency_table_target(). Thus, ignore
* policy and get the index from the raw freqeuncy table.
*/
- old_index = exynos_cpufreq_get_index(freqs.old);
+ old_index = exynos_cpufreq_get_index(old_freq);
if (old_index < 0) {
ret = old_index;
goto out;
@@ -95,17 +94,14 @@ static int exynos_cpufreq_scale(unsigned int target_freq)
}
arm_volt = volt_table[index];
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
/* When the new frequency is higher than current frequency */
- if ((freqs.new > freqs.old) && !safe_arm_volt) {
+ if ((target_freq > old_freq) && !safe_arm_volt) {
/* Firstly, voltage up to increase frequency */
ret = regulator_set_voltage(arm_regulator, arm_volt, arm_volt);
if (ret) {
pr_err("%s: failed to set cpu voltage to %d\n",
__func__, arm_volt);
- freqs.new = freqs.old;
- goto post_notify;
+ return ret;
}
}
@@ -115,22 +111,15 @@ static int exynos_cpufreq_scale(unsigned int target_freq)
if (ret) {
pr_err("%s: failed to set cpu voltage to %d\n",
__func__, safe_arm_volt);
- freqs.new = freqs.old;
- goto post_notify;
+ return ret;
}
}
exynos_info->set_freq(old_index, index);
-post_notify:
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
- if (ret)
- goto out;
-
/* When the new frequency is lower than current frequency */
- if ((freqs.new < freqs.old) ||
- ((freqs.new > freqs.old) && safe_arm_volt)) {
+ if ((target_freq < old_freq) ||
+ ((target_freq > old_freq) && safe_arm_volt)) {
/* down the voltage after frequency change */
regulator_set_voltage(arm_regulator, arm_volt,
arm_volt);
@@ -142,7 +131,6 @@ post_notify:
}
out:
-
cpufreq_cpu_put(policy);
return ret;
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 14/34] cpufreq: ia64-acpi: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Cc: Tony Luck
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/ia64-acpi-cpufreq.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a/drivers/cpufreq/ia64-acpi-cpufreq.c
b/drivers/cpufreq/ia64-acpi-cpufreq.c
index 4695fa2..53c6ac6 100644
--- a/drivers/cpufreq/ia64-acpi-cpufreq.c
+++ b/drivers/cpufreq/ia64-acpi-cpufreq.c
@@ -141,7 +141,6 @@ processor_set_freq (
{
int ret = 0;
u32 value = 0;
- struct cpufreq_freqscpufreq_freqs;
cpumask_t saved_mask;
int retval;
@@ -168,13 +167,6 @@ processor_set_freq (
pr_debug("Transitioning from P%d to P%d\n",
data->acpi_data.state, state);
- /* cpufreq frequency struct */
- cpufreq_freqs.old = data->freq_table[data->acpi_data.state].frequency;
- cpufreq_freqs.new = data->freq_table[state].frequency;
-
- /* notify cpufreq */
- cpufreq_notify_transition(policy, _freqs, CPUFREQ_PRECHANGE);
-
/*
* First we write the target state's 'control' value to the
* control_register.
@@ -186,22 +178,11 @@ processor_set_freq (
ret = processor_set_pstate(value);
if (ret) {
- unsigned int tmp = cpufreq_freqs.new;
- cpufreq_notify_transition(policy, _freqs,
- CPUFREQ_POSTCHANGE);
- cpufreq_freqs.new = cpufreq_freqs.old;
- cpufreq_freqs.old = tmp;
- cpufreq_notify_transition(policy, _freqs,
- CPUFREQ_PRECHANGE);
- cpufreq_notify_transition(policy, _freqs,
- CPUFREQ_POSTCHANGE);
printk(KERN_WARNING "Transition failed with error %d\n", ret);
retval = -ENODEV;
goto migrate_end;
}
- cpufreq_notify_transition(policy, _freqs, CPUFREQ_POSTCHANGE);
-
data->acpi_data.state = state;
retval = 0;
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/34] cpufreq: exynos5440: set CPUFREQ_NO_NOTIFICATION flag
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, but this drivers needs to do this notification itself and so
it sets its CPUFREQ_NO_NOTIFICATION flag.
Cc: Kukjin Kim
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/exynos5440-cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
b/drivers/cpufreq/exynos5440-cpufreq.c
index 91a64d6..8fb6183 100644
--- a/drivers/cpufreq/exynos5440-cpufreq.c
+++ b/drivers/cpufreq/exynos5440-cpufreq.c
@@ -323,7 +323,7 @@ static int exynos_cpufreq_cpu_init(struct cpufreq_policy
*policy)
}
static struct cpufreq_driver exynos_driver = {
- .flags = CPUFREQ_STICKY,
+ .flags = CPUFREQ_STICKY | CPUFREQ_NO_NOTIFICATION,
.verify = cpufreq_generic_frequency_table_verify,
.target_index = exynos_target,
.get= exynos_getspeed,
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/34] cpufreq: arm_big_little: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/arm_big_little.c | 25 +++--
1 file changed, 3 insertions(+), 22 deletions(-)
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index daf4423..e3e8f25 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -51,30 +51,11 @@ static unsigned int bL_cpufreq_get(unsigned int cpu)
static int bL_cpufreq_set_target(struct cpufreq_policy *policy,
unsigned int index)
{
- struct cpufreq_freqs freqs;
- u32 cpu = policy->cpu, cur_cluster;
- int ret = 0;
+ u32 cur_cluster;
cur_cluster = cpu_to_cluster(policy->cpu);
-
- freqs.old = bL_cpufreq_get(policy->cpu);
- freqs.new = freq_table[cur_cluster][index].frequency;
-
- pr_debug("%s: cpu: %d, cluster: %d, oldfreq: %d, target freq: %d, new
freq: %d\n",
- __func__, cpu, cur_cluster, freqs.old, freqs.new,
- freqs.new);
-
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
- ret = clk_set_rate(clk[cur_cluster], freqs.new * 1000);
- if (ret) {
- pr_err("clk_set_rate failed: %d\n", ret);
- freqs.new = freqs.old;
- }
-
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
- return ret;
+ return clk_set_rate(clk[cur_cluster],
+ freq_table[cur_cluster][index].frequency * 1000);
}
static void put_cluster_clk_and_freq_table(struct device *cpu_dev)
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/34] cpufreq: acpi: remove calls to cpufreq_notify_transition()
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
Earlier patches have added support in cpufreq core to do cpufreq notification on
frequency change, this one removes it from this driver.
Some related minor cleanups are also done along with it.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/acpi-cpufreq.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 7536e7d..6b00cd8 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -428,14 +428,10 @@ static int acpi_cpufreq_target(struct cpufreq_policy
*policy,
{
struct acpi_cpufreq_data *data = per_cpu(acfreq_data, policy->cpu);
struct acpi_processor_performance *perf;
- struct cpufreq_freqs freqs;
struct drv_cmd cmd;
unsigned int next_perf_state = 0; /* Index into perf table */
int result = 0;
- pr_debug("acpi_cpufreq_target %d (%d)\n",
- data->freq_table[index].frequency, policy->cpu);
-
if (unlikely(data == NULL ||
data->acpi_data == NULL || data->freq_table == NULL)) {
return -ENODEV;
@@ -483,23 +479,17 @@ static int acpi_cpufreq_target(struct cpufreq_policy
*policy,
else
cmd.mask = cpumask_of(policy->cpu);
- freqs.old = perf->states[perf->state].core_frequency * 1000;
- freqs.new = data->freq_table[index].frequency;
- cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
-
drv_write();
if (acpi_pstate_strict) {
- if (!check_freqs(cmd.mask, freqs.new, data)) {
+ if (!check_freqs(cmd.mask, data->freq_table[index].frequency,
+ data)) {
pr_debug("acpi_cpufreq_target failed (%d)\n",
policy->cpu);
result = -EAGAIN;
- freqs.new = freqs.old;
}
}
- cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
-
if (!result)
perf->state = next_perf_state;
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/34] cpufreq: move freq change notifications to cpufreq core
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...
cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.
There are few special cases though, like exynos5440, which doesn't do everything
on the call to ->target_index() routine and call some kind of bottom halves for
doing this work, work/tasklet/etc..
They may continue doing notification from their own code and so this patch
introduces another flag: CPUFREQ_NO_NOTIFICATION, which will be set by such
drivers.
Cc: Andrew Lunn
Cc: David S. Miller
Cc: Dmitry Eremin-Solenikov
Cc: Eric Miao
Cc: Hans-Christian Egtvedt
Cc: Jesper Nilsson
Cc: John Crispin
Cc: Kukjin Kim
Cc: Linus Walleij
Cc: linux-cris-ker...@axis.com
Cc: Mikael Starvik
Cc: Russell King
Cc: Santosh Shilimkar
Cc: Sekhar Nori
Cc: Shawn Guo
Cc: sparcli...@vger.kernel.org
Cc: spear-de...@list.st.com
Cc: Stephen Warren
Cc: Steven Miao
Cc: Tony Luck
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 34 ++
include/linux/cpufreq.h | 6 ++
2 files changed, 40 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index a7a1d3e..2782949 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1673,6 +1673,9 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
retval = cpufreq_driver->target(policy, target_freq, relation);
else if (cpufreq_driver->target_index) {
struct cpufreq_frequency_table *freq_table;
+ struct cpufreq_freqs freqs;
+ unsigned long flags;
+ bool notify;
int index;
freq_table = cpufreq_frequency_get_table(policy->cpu);
@@ -1691,7 +1694,38 @@ int __cpufreq_driver_target(struct cpufreq_policy
*policy,
if (freq_table[index].frequency == policy->cur)
return 0;
+ read_lock_irqsave(_driver_lock, flags);
+ notify = !(cpufreq_driver->flags | CPUFREQ_NO_NOTIFICATION);
+ read_unlock_irqrestore(_driver_lock, flags);
+
+ if (notify) {
+ freqs.old = policy->cur;
+ freqs.new = freq_table[index].frequency;
+
+ pr_debug("%s: cpu: %d, oldfreq: %u, new freq: %u\n",
+ __func__, policy->cpu, freqs.old,
+ freqs.new);
+
+ cpufreq_notify_transition(policy, ,
+ CPUFREQ_PRECHANGE);
+ }
+
retval = cpufreq_driver->target_index(policy, index);
+ if (retval)
+ pr_err("%s: Failed to change cpu frequency: %d\n",
+ __func__, retval);
+
+ if (notify) {
+ /*
+* Notify with old freq in case we failed to change
+* frequency
+*/
+ if (retval)
+ freqs.new = freqs.old;
+
+ cpufreq_notify_transition(policy, ,
+ CPUFREQ_POSTCHANGE);
+ }
}
return retval;
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index ff9c8df..62ce478 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -221,6 +221,12 @@ struct cpufreq_driver {
* frequency transitions */
#define CPUFREQ_PM_NO_WARN 0x04/* don't warn on suspend/resume speed
* mismatches */
+/*
+ * Driver will call cpufreq_notify_transition() in its target_index() routine
+ * and so cpufreq core must not call it. Only useful for drivers that implement
+ * target_index(), unused otherwise.
+ */
+#define CPUFREQ_NO_NOTIFICATION0x08
int cpufreq_register_driver(struct cpufreq_driver *driver_data);
int cpufreq_unregister_driver(struct cpufreq_driver *driver_data);
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/34] CPUFreq: Move freq change notifications out of drivers
Another 452 lines gone :) Total stats upto now for all the 5 patchsets: Viresh Kumar (186): ... 69 files changed, 700 insertions(+), 2451 deletions(-) Net: 1751 lines gone.. -x-x Most of the drivers do following in their ->target_index() routines: struct cpufreq_freqs freqs; freqs.old = old freq... freqs.new = new freq... cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE); /* Change rate here */ cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE); This is replicated over all cpufreq drivers today and there doesn't exists a good enough reason why this shouldn't be moved to cpufreq core instead. There are few special cases though, like exynos5440, which doesn't do everything on the call to ->target_index() routine and call some kind of bottom halves for doing this work, work/tasklet/etc.. They may continue doing notification from their own code and so this patch introduces another flag: CPUFREQ_NO_NOTIFICATION, which will be set by such drivers. This is Fifth part of my cleanup work for CPUFreq, first three are (And obviously its rebased over them): 1: cpufreq: Introduce cpufreq_table_validate_and_show() https://lkml.org/lkml/2013/8/8/263 2: cpufreq: define generic routines for cpufreq drivers https://lkml.org/lkml/2013/8/10/48 3. CPUFreq: Implement light weight ->target(): for 3.13 https://lkml.org/lkml/2013/8/13/349 4. CPUFreq: set policy->cur in cpufreq core instead of drivers https://lkml.org/lkml/2013/8/14/288 All these are pushed here: https://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/for-v3.13 -- viresh Cc: Andrew Lunn Cc: David S. Miller Cc: Dmitry Eremin-Solenikov Cc: Eric Miao Cc: Hans-Christian Egtvedt Cc: Jesper Nilsson Cc: John Crispin Cc: Kukjin Kim Cc: Linus Walleij Cc: linux-cris-ker...@axis.com Cc: Mikael Starvik Cc: Russell King Cc: Santosh Shilimkar Cc: Sekhar Nori Cc: Shawn Guo Cc: sparcli...@vger.kernel.org Cc: spear-de...@list.st.com Cc: Stephen Warren Cc: Steven Miao Cc: Tony Luck Viresh Kumar (34): cpufreq: move freq change notifications to cpufreq core cpufreq: acpi: remove calls to cpufreq_notify_transition() cpufreq: arm_big_little: remove calls to cpufreq_notify_transition() cpufreq: at32ap: remove calls to cpufreq_notify_transition() cpufreq: blackfin: remove calls to cpufreq_notify_transition() cpufreq: cpu0: remove calls to cpufreq_notify_transition() cpufreq: cris: remove calls to cpufreq_notify_transition() cpufreq: davinci: remove calls to cpufreq_notify_transition() cpufreq: dbx500: remove calls to cpufreq_notify_transition() cpufreq: e_powersaver: remove calls to cpufreq_notify_transition() cpufreq: elanfreq: remove calls to cpufreq_notify_transition() cpufreq: exynos: remove calls to cpufreq_notify_transition() cpufreq: exynos5440: set CPUFREQ_NO_NOTIFICATION flag cpufreq: ia64-acpi: remove calls to cpufreq_notify_transition() cpufreq: imx6q: remove calls to cpufreq_notify_transition() cpufreq: kirkwood: remove calls to cpufreq_notify_transition() cpufreq: longhaul: set CPUFREQ_NO_NOTIFICATION flag cpufreq: loongson2: remove calls to cpufreq_notify_transition() cpufreq: maple: remove calls to cpufreq_notify_transition() cpufreq: omap: remove calls to cpufreq_notify_transition() cpufreq: p4-clockmod: remove calls to cpufreq_notify_transition() cpufreq: pasemi: remove calls to cpufreq_notify_transition() cpufreq: pmac: remove calls to cpufreq_notify_transition() cpufreq: powernow: remove calls to cpufreq_notify_transition() cpufreq: ppc: remove calls to cpufreq_notify_transition() cpufreq: pxa: remove calls to cpufreq_notify_transition() cpufreq: s3c: remove calls to cpufreq_notify_transition() cpufreq: s5pv210: remove calls to cpufreq_notify_transition() cpufreq: sa11x0: remove calls to cpufreq_notify_transition() cpufreq: sc520: remove calls to cpufreq_notify_transition() cpufreq: sparc: remove calls to cpufreq_notify_transition() cpufreq: SPEAr: remove calls to cpufreq_notify_transition() cpufreq: speedstep: remove calls to cpufreq_notify_transition() cpufreq: tegra: remove calls to cpufreq_notify_transition() drivers/cpufreq/acpi-cpufreq.c | 14 ++--- drivers/cpufreq/arm_big_little.c | 25 ++-- drivers/cpufreq/at32ap-cpufreq.c | 22 ++ drivers/cpufreq/blackfin-cpufreq.c | 22 +- drivers/cpufreq/cpufreq-cpu0.c | 33 - drivers/cpufreq/cpufreq.c | 34 + drivers/cpufreq/cris-artpec3-cpufreq.c | 8 - drivers/cpufreq/cris-etraxfs-cpufreq.c | 8 - drivers/cpufreq/davinci-cpufreq.c | 30 +++ drivers/cpufreq/dbx500-cpufreq.c | 22 +- drivers/cpufreq/e_powersaver.c | 23 ++- drivers/cpufreq/elanfreq.c | 13 drivers/cpufreq/exynos-cpufreq.c
Why are BSD-licensed LZ4 symbols GPL exported?
Why are the LZ4 symbols being GPL-exported when the LZ4 code is BSD-licensed and no substantial changes appear to have been made when it was merged? Also, why is the module license GPL when the code itself is clearly under a BSD license? signature.asc Description: OpenPGP digital signature
[PATCH] clk: export fixed-factor, gate & mux registration
These registration calls may be used by loadable modules. Export them. Signed-off-by: Mike Turquette --- drivers/clk/clk-fixed-factor.c | 2 ++ drivers/clk/clk-gate.c | 1 + drivers/clk/clk-mux.c | 2 ++ 3 files changed, 5 insertions(+) diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c index 9ff7d51..0e1d89b 100644 --- a/drivers/clk/clk-fixed-factor.c +++ b/drivers/clk/clk-fixed-factor.c @@ -97,6 +97,8 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name, return clk; } +EXPORT_SYMBOL_GPL(clk_register_fixed_factor); + #ifdef CONFIG_OF /** * of_fixed_factor_clk_setup() - Setup function for simple fixed factor clock diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c index 790306e..2b28a00 100644 --- a/drivers/clk/clk-gate.c +++ b/drivers/clk/clk-gate.c @@ -161,3 +161,4 @@ struct clk *clk_register_gate(struct device *dev, const char *name, return clk; } +EXPORT_SYMBOL_GPL(clk_register_gate); diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c index 92f1a1b..b918dc3 100644 --- a/drivers/clk/clk-mux.c +++ b/drivers/clk/clk-mux.c @@ -162,6 +162,7 @@ struct clk *clk_register_mux_table(struct device *dev, const char *name, return clk; } +EXPORT_SYMBOL_GPL(clk_register_mux_table); struct clk *clk_register_mux(struct device *dev, const char *name, const char **parent_names, u8 num_parents, unsigned long flags, @@ -174,3 +175,4 @@ struct clk *clk_register_mux(struct device *dev, const char *name, flags, reg, shift, mask, clk_mux_flags, NULL, lock); } +EXPORT_SYMBOL_GPL(clk_register_mux); -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] USB fixes for 3.11-rc6
The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8: Linux 3.11-rc5 (2013-08-11 18:04:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.11-rc6 for you to fetch changes up to ff8a43c10f1440f07a5faca0c1556921259f7f76: USB: keyspan: fix null-deref at disconnect and release (2013-08-14 12:49:27 -0700) USB fixes for 3.11-rc6 Here are some small USB fixes for 3.11-rc6 that have accumulated. Nothing huge, a EHCI fix that solves a much-reported audio USB problem, some usb-serial driver endian fixes and other minor fixes, a wireless USB oops fix, and two new quirks. Signed-off-by: Greg Kroah-Hartman Alan Stern (1): USB: EHCI: accept very late isochronous URBs Johan Hovold (6): USB: mos7840: fix big-endian probe USB: usbtmc: fix big-endian probe of Rigol devices USB: adutux: fix big-endian device-type reporting USB: ti_usb_3410_5052: fix big-endian firmware handling USB: mos7720: fix broken control requests USB: keyspan: fix null-deref at disconnect and release Matt Burtch (1): USB-Serial: Fix error handling of usb_wwan Oliver Neukum (1): usb: add two quirky touchscreen Thomas Pugliese (1): wusbcore: fix kernel panic when disconnecting a wireless USB->serial device drivers/usb/class/usbtmc.c| 8 drivers/usb/core/quirks.c | 6 ++ drivers/usb/host/ehci-sched.c | 13 ++--- drivers/usb/misc/adutux.c | 2 +- drivers/usb/serial/keyspan.c | 2 +- drivers/usb/serial/mos7720.c | 21 ++--- drivers/usb/serial/mos7840.c | 2 +- drivers/usb/serial/ti_usb_3410_5052.c | 9 + drivers/usb/serial/usb_wwan.c | 20 ++-- drivers/usb/wusbcore/wa-xfer.c| 9 +++-- 10 files changed, 55 insertions(+), 37 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] Staging driver fixes for 3.11-rc6
On Thu, Aug 15, 2013 at 07:07:10PM -0700, Greg KH wrote: > The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8: > > Linux 3.11-rc5 (2013-08-11 18:04:20 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ > tags/usb-3.11-rc6 > > for you to fetch changes up to ff8a43c10f1440f07a5faca0c1556921259f7f76: > > USB: keyspan: fix null-deref at disconnect and release (2013-08-14 12:49:27 > -0700) > > > USB fixes for 3.11-rc6 This really was the USB fixes, I don't know where the "Staging" subject line came from, sorry about that. I'll resend with the proper subject and mailing lists copied... greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] i2c-designware: make *CNT values configurable
Hi, On 8/5/13 6:31 PM, Christian Ruppert wrote:> On Wed, Jul 24, 2013 at 11:31:44PM +0900, Shinya Kuribayashi wrote: As said before, all t_SCL things should go away. Please forget about 100kbps, 400kbps, and so on. Bus/clock speed is totally pointless concept for the I2C bus systems. For example, as long as tr/tf, tHIGH/tLOW, tHD;STA, etc. are met by _all_ devices in a certain I2C bus, it doesn't matter that the resulting clock speed is, say 120 kbps with Standard-mode, or even 800 kbps for Fast-mode. Nobody in the I2C bus doesn't care about actual bus/clock speed. We don't have to care about the resulting bus speed, or rather we should/must not check to see if it's within the proper range. Actually, the I2C specification clearly defines f_SCL;max (and thus implies t_SCL;min), both in the tables and the timing diagrams. Why can we ignore this constraint while having to meet all the others? If we meet t_r, t_f, t_HIGH, t_LOW (and t_HIGH in this DW case), f_SCL;max will be met by itself. And again, all I2C master and slave devices in the bus don't care about f_SCL; what they do care are t_f, t_r, t_HIGH, t_LOW, and so on. That's why I'm saying f_SCL is pointless and has no value for HCNT/LCNT calculations. Is that clear? What is the point to make sure whether f_SCL constraint is met or not? Is there any combination where t_f, t_r, t_HIGH, t_LOW, t_HD;SATA are met, but f_SCL is out of range? I don't think there is. I'd make a compromise proposal; it's fine to make sure whether the resulting f_SCL is within a supported range, but should not make a correction of HCNT/LCNT values. Just report warning messages that some parameters/calculations might be mis-configured an/or wrong. Shinya -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 0/1] AHCI: Optimize interrupt processing
On Thu, 2013-08-15 at 18:23 +0200, Alexander Gordeev wrote:
> On Fri, Aug 09, 2013 at 01:17:37PM -0700, Nicholas A. Bellinger wrote:
> > On Fri, 2013-08-09 at 21:15 +0200, Alexander Gordeev wrote:
> > Mmmm, I'm able to reproduce over here with ahci + scsi-mq, and it
> > appears to be a bug related with using sdev->sdev_md_req.queue_depth=1,
> > that ends up causing the blkdev_issue_flush() to wait forever because
> > blk_mq_wait_for_tags() never ends up getting the single tag back for the
> > WRITE_FLUSH bio -> SYNCHRONIZE_CACHE cdb.
>
> It turns out this way - blkdev_issue_flush() claims the only tag, submits
> the bio and waits for the completion. But because blk_mq_make_request()
> does not mark any context in blk_mq_hw_ctx::ctx_map (nor enslists the request
> into blk_mq_ctx::rq_list) it never gets processed from blk_mq_work_fn->
> __blk_mq_run_hw_queue() and blkdev_issue_flush() waits endlessly. All other
> requests are just waiting for the tag availability as result.
>
Ok, here's a bit better idea of what is going on now..
The problem is that blkdev_issue_flush() -> blk_mq_make_request() ->
__blk_mq_alloc_request() allocates the first tag, which calls
blk_insert_flush() -> blk_flush_complete_seq() -> blk_flush_kick() ->
mq_flush_work() -> blk_mq_alloc_request() to allocate a second tag for
the struct request that actually gets dispatched into scsi-mq as a
SYCHRONIZE_CACHE command..
I'm not exactly sure why this double tag usage of struct request is
occurring, but AFAICT it does happen for every flush, and is not
specific to the blkdev_issue_flush() codepath.. I'm sure that Jens can
fill us in on that bit. ;)
So, assuming that this double tag usage is necessary and not a bug,
perhaps using a reserved tag for the first tag (eg: the one that's not
dispatched into scsi_mq_queue_rq) makes sense..?
I'm playing with a patch to do this, but am currently getting hung-up on
what appear to be some separate blk-mq reserved_tags > 0 bugs, the first
of which is passing queue_depth=1 + reserved_tags=1 is broken, and
results in tags->nr_free = 0.
Here's the quick fix:
diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index 6718007..ffdf686 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -470,7 +470,7 @@ struct blk_mq_tags *blk_mq_init_tags(unsigned int nr_tags,
* Rest of the tags start at the queue list
*/
tags->nr_free = 0;
- while (nr_tags - tags->nr_reserved) {
+ while (nr_tags) {
tags->freelist[tags->nr_free] = tags->nr_free +
tags->nr_reserved;
nr_tags--;
Anyways, before digging further into reserved tags logic, Jens, what are
your thoughts for addressing this special queue_depth=1 case for libata
+ the like..?
--nab
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] Staging driver fixes for 3.11-rc6
The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8: Linux 3.11-rc5 (2013-08-11 18:04:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.11-rc6 for you to fetch changes up to ff8a43c10f1440f07a5faca0c1556921259f7f76: USB: keyspan: fix null-deref at disconnect and release (2013-08-14 12:49:27 -0700) USB fixes for 3.11-rc6 Here are some small USB fixes for 3.11-rc6 that have accumulated. Nothing huge, a EHCI fix that solves a much-reported audio USB problem, some usb-serial driver endian fixes and other minor fixes, a wireless USB oops fix, and two new quirks. Signed-off-by: Greg Kroah-Hartman Alan Stern (1): USB: EHCI: accept very late isochronous URBs Johan Hovold (6): USB: mos7840: fix big-endian probe USB: usbtmc: fix big-endian probe of Rigol devices USB: adutux: fix big-endian device-type reporting USB: ti_usb_3410_5052: fix big-endian firmware handling USB: mos7720: fix broken control requests USB: keyspan: fix null-deref at disconnect and release Matt Burtch (1): USB-Serial: Fix error handling of usb_wwan Oliver Neukum (1): usb: add two quirky touchscreen Thomas Pugliese (1): wusbcore: fix kernel panic when disconnecting a wireless USB->serial device drivers/usb/class/usbtmc.c| 8 drivers/usb/core/quirks.c | 6 ++ drivers/usb/host/ehci-sched.c | 13 ++--- drivers/usb/misc/adutux.c | 2 +- drivers/usb/serial/keyspan.c | 2 +- drivers/usb/serial/mos7720.c | 21 ++--- drivers/usb/serial/mos7840.c | 2 +- drivers/usb/serial/ti_usb_3410_5052.c | 9 + drivers/usb/serial/usb_wwan.c | 20 ++-- drivers/usb/wusbcore/wa-xfer.c| 9 +++-- 10 files changed, 55 insertions(+), 37 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/5] zram/zsmalloc promotion
Hi Mel, On 08/16/2013 01:12 AM, Mel Gorman wrote: > On Thu, Aug 15, 2013 at 03:58:20AM +0900, Minchan Kim wrote: >>> >>> >>> I do not believe this is a problem for zram as such because I do not >>> think it ever writes back to disk and is immune from the unpredictable >>> performance characteristics problem. The problem for zram using zsmalloc >>> is OOM killing. If it's used for swap then there is no guarantee that >>> killing processes frees memory and that could result in an OOM storm. >>> Of course there is no guarantee that memory is freed with zbud either but >>> you are guaranteed that freeing 50%+1 of the compressed pages will free a >>> single physical page. The characteristics for zsmalloc are much more severe. >>> This might be managable in an applicance with very careful control of the >>> applications that are running but not for general servers or desktops. >> >> Fair enough but let's think of current usecase for zram. >> As I said in description, most of user for zram are embedded products. >> So, most of them has no swap storage and hate OOM kill because OOM is >> already very very slow path so system slow response is really thing >> we want to avoid. We prefer early process kill to slow response. >> That's why custom low memory killer/notifier is popular in embedded side. >> so actually, OOM storm problem shouldn't be a big problem under >> well-control limited system. >> > > Which zswap could also do if > > a) it had a pseudo block device that failed all writes > b) zsmalloc was pluggable > I'll take a try soon! > I recognise this sucks because zram is already in the field but if zram > is promoted then zram and zswap will continue to diverge further with no > reconcilation in sight. > > Part of the point of using zswap was that potentially zcache could be > implemented on top of it and so all file cache could be stored compressed > in memory. AFAIK, it's not possible to do the same thing for zram because > of the lack of writeback capabilities. Maybe it could be done if zram > could be configured to write to an underlying storage device but it may > be very clumsy to configure. I don't know as I never investigated it and > to be honest, I'm struggling to remember how I got involved anywhere near > zswap/zcache/zram/zwtf in the first place. > >>> If it's used for something like tmpfs then it becomes much worse. Normal >>> tmpfs without swap can lockup if tmpfs is allowed to fill memory. In a >>> sane configuration, lockups will be avoided and deleting a tmpfs file is >>> guaranteed to free memory. When zram is used to back tmpfs, there is no >>> guarantee that any memory is freed due to fragmentation of the compressed >>> pages. The only way to recover the memory may be to kill applications >>> holding tmpfs files open and then delete them which is fairly drastic >>> action in a normal server environment. >> >> Indeed. >> Actually, I had a plan to support zsmalloc compaction. The zsmalloc exposes >> handle instead of pure pointer so it could migrate some zpages to somewhere >> to pack in. Then, it could help above problem and OOM storm problem. >> Anyway, it's a totally new feature and requires many changes and experiement. >> Although we don't have such feature, zram is still good for many people. >> > > And is zsmalloc was pluggable for zswap then it would also benefit. > >>> These are the sort of reason why I feel that zram has limited cases where >>> it is safe to use and zswap has a wider range of applications. At least >>> I would be very unhappy to try supporting zram in the field for normal >>> servers. zswap should be able to replace the functionality of zram+swap >>> by backing zswap with a pseudo block device that rejects all writes. I >> >> One of difference between zswap and zram is asynchronous I/O support. > > As zram is not writing to disk, how compelling is asynchronous IO? If > zswap was backed by the pseudo device is there a measurable bottleneck? > >> I guess frontswap is synchronous by semantic while zram could support >> asynchronous I/O. >> >>> do not know why this never happened but guess the zswap people never were >>> interested and the zram people never tried. Why was the pseudo device >>> to avoid writebacks never implemented? Why was the underlying allocator >>> not made pluggable to optionally use zsmalloc when the user did not care >>> that it had terrible writeback characteristics? >> >> I remember you suggested to make zsmalloc with pluggable for zswap. >> But I don't know why zswap people didn't implement it. >> >>> >>> zswap cannot replicate zram+tmpfs but I also think that such a configuration >>> is a bad idea anyway. As zram is already being deployed then it might get >> >> It seems your big concern of zsmalloc is fragmentaion so if zsmalloc can >> support compaction, it would mitigate the concern. >> > > Even if it supported zsmalloc I would still wonder why zswap is not using > it as a pluggable option :( > >>> promoted anyway but
Re: [PATCH v6 0/5] zram/zsmalloc promotion
Hi Mel, On 08/16/2013 01:12 AM, Mel Gorman wrote: > On Thu, Aug 15, 2013 at 03:58:20AM +0900, Minchan Kim wrote: >>> >>> >>> I do not believe this is a problem for zram as such because I do not >>> think it ever writes back to disk and is immune from the unpredictable >>> performance characteristics problem. The problem for zram using zsmalloc >>> is OOM killing. If it's used for swap then there is no guarantee that >>> killing processes frees memory and that could result in an OOM storm. >>> Of course there is no guarantee that memory is freed with zbud either but >>> you are guaranteed that freeing 50%+1 of the compressed pages will free a >>> single physical page. The characteristics for zsmalloc are much more severe. >>> This might be managable in an applicance with very careful control of the >>> applications that are running but not for general servers or desktops. >> >> Fair enough but let's think of current usecase for zram. >> As I said in description, most of user for zram are embedded products. >> So, most of them has no swap storage and hate OOM kill because OOM is >> already very very slow path so system slow response is really thing >> we want to avoid. We prefer early process kill to slow response. >> That's why custom low memory killer/notifier is popular in embedded side. >> so actually, OOM storm problem shouldn't be a big problem under >> well-control limited system. >> > > Which zswap could also do if > > a) it had a pseudo block device that failed all writes > b) zsmalloc was pluggable > I'll take a try soon! > I recognise this sucks because zram is already in the field but if zram > is promoted then zram and zswap will continue to diverge further with no > reconcilation in sight. > > Part of the point of using zswap was that potentially zcache could be > implemented on top of it and so all file cache could be stored compressed > in memory. AFAIK, it's not possible to do the same thing for zram because > of the lack of writeback capabilities. Maybe it could be done if zram > could be configured to write to an underlying storage device but it may > be very clumsy to configure. I don't know as I never investigated it and > to be honest, I'm struggling to remember how I got involved anywhere near > zswap/zcache/zram/zwtf in the first place. > >>> If it's used for something like tmpfs then it becomes much worse. Normal >>> tmpfs without swap can lockup if tmpfs is allowed to fill memory. In a >>> sane configuration, lockups will be avoided and deleting a tmpfs file is >>> guaranteed to free memory. When zram is used to back tmpfs, there is no >>> guarantee that any memory is freed due to fragmentation of the compressed >>> pages. The only way to recover the memory may be to kill applications >>> holding tmpfs files open and then delete them which is fairly drastic >>> action in a normal server environment. >> >> Indeed. >> Actually, I had a plan to support zsmalloc compaction. The zsmalloc exposes >> handle instead of pure pointer so it could migrate some zpages to somewhere >> to pack in. Then, it could help above problem and OOM storm problem. >> Anyway, it's a totally new feature and requires many changes and experiement. >> Although we don't have such feature, zram is still good for many people. >> > > And is zsmalloc was pluggable for zswap then it would also benefit. > >>> These are the sort of reason why I feel that zram has limited cases where >>> it is safe to use and zswap has a wider range of applications. At least >>> I would be very unhappy to try supporting zram in the field for normal >>> servers. zswap should be able to replace the functionality of zram+swap >>> by backing zswap with a pseudo block device that rejects all writes. I >> >> One of difference between zswap and zram is asynchronous I/O support. > > As zram is not writing to disk, how compelling is asynchronous IO? If > zswap was backed by the pseudo device is there a measurable bottleneck? > >> I guess frontswap is synchronous by semantic while zram could support >> asynchronous I/O. >> >>> do not know why this never happened but guess the zswap people never were >>> interested and the zram people never tried. Why was the pseudo device >>> to avoid writebacks never implemented? Why was the underlying allocator >>> not made pluggable to optionally use zsmalloc when the user did not care >>> that it had terrible writeback characteristics? >> >> I remember you suggested to make zsmalloc with pluggable for zswap. >> But I don't know why zswap people didn't implement it. >> >>> >>> zswap cannot replicate zram+tmpfs but I also think that such a configuration >>> is a bad idea anyway. As zram is already being deployed then it might get >> >> It seems your big concern of zsmalloc is fragmentaion so if zsmalloc can >> support compaction, it would mitigate the concern. >> > > Even if it supported zsmalloc I would still wonder why zswap is not using > it as a pluggable option :( > >>> promoted anyway but
linux-next: manual merge of the dlm tree with Linus' tree
Hi David,
Today's linux-next merge of the dlm tree got a conflict in fs/dlm/user.c
between commit 201d3dfa4da1 ("dlm: kill the unnecessary and wrong
device_close()->recalc_sigpending()") from Linus' tree and commit
c6ca7bc91d51 ("dlm: remove signal blocking") from the dlm tree.
I fixed it up (the latter is a superset of the former, so I just used it)
and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpLc76N7ZnCZ.pgp
Description: PGP signature
Re: [PATCH 0/8] partitions/efi: detect hybrid mbrs
On Thu, 2013-08-15 at 12:29 -0700, Andrew Morton wrote: > On Thu, 15 Aug 2013 09:59:42 -0700 Davidlohr Bueso wrote: > > > On Tue, 2013-08-06 at 14:16 -0700, Andrew Morton wrote: > > > On Mon, 5 Aug 2013 22:21:08 -0700 Davidlohr Bueso > > > wrote: > > > > > > > This patchset teaches the kernel about hybrid master boot records > > > > (MBRs), one of > > > > the most common issues with GUID partition tables, as a workaround to > > > > layout > > > > disk partitions to be compatible with both EFI and legacy MBR based > > > > systems. > > > > Except for adding more pmbr checks, to better comply with the UEFI/GPT > > > > specs, the > > > > functionality is left unchanged - we only inform (through debug) the > > > > user about > > > > the used MBR scheme. While it is true that these restrictions can be > > > > bypassed when > > > > forcing gpt, this is not the correct or default way of doing things, > > > > complicating > > > > users furthermore. More details are in the individual patches. > > > > > > Patches look nice, although I'll cheerily admit to not having a clue > > > what they do. What is a "hybrid MBR" anyway? > > > > > > Someone's editor seems to replace tabs with spaces so the patches > > > generate quite a checkpatch storm. Please use checkpatch. > > > > > > > Andrew, any chance of getting this in for 3.12? > > gee, I didn't review the patches because I simply have no useful > knowledge in the area. I can check the whitespace and code comments, > but that has the downside of creating the false impression that someone > actually reviewed the code :( > > I'm struggling to think who might be better situated. Matt Fleming or > Matt Domsch, maybe? > Cc'ing Matt Fleming. Karel, I believe you took a look at these, any thoughts? Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/17] 3.4.58-stable review
On Thu, Aug 15, 2013 at 06:28:34PM -0700, Guenter Roeck wrote: > On 08/15/2013 06:22 PM, Greg Kroah-Hartman wrote: > >> That was "fixed" by a complete arm Kconfig overhaul. I don't think you want > >> that in 3.4. > >> -- > > > > Not a "complete" overhaul, no. But getting a default allmodconfig > > building for arm would be nice, if possible. > > > > I agree. I'll look into it a bit further. Thanks, much appreciated. > Also, to keep you busy: > > cd8d2331 alpha: makefile: don't enforce small data model for kernel builds > > fixes the alpha defconfig build for 3.4. Nice, now applied. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 03/14] clk: Add of_clk_match() for device drivers
On 08/14, Mike Turquette wrote: > Quoting Stephen Boyd (2013-08-12 22:48:39) > > On 08/12, Mike Turquette wrote: > > > Quoting Stephen Boyd (2013-07-24 17:43:31) > > > > In similar fashion as of_regulator_match() add an of_clk_match() > > > > function that finds an initializes clock init_data structs from > > > > devicetree. Drivers should use this API to find clocks that their > > > > device is providing and then iterate over their match table > > > > registering the clocks with the init data parsed. > > > > > > > > Signed-off-by: Stephen Boyd > > > > > > Stephen, > > > > > > In general I like this approach. Writing real device drivers for clock > > > controllers is The Right Way and of_clk_match helps. > > > > > > Am I reading this correctly that the base register addresses/offsets for > > > the clock nodes still come from C files? For example I still see > > > pll8_desc defining reg stuff in drivers/clk/msm/gcc-8960.c. > > > > I think we may be able to put the registers in DT but I don't > > know why we need to do that if we're already matching up nodes > > with C structs. > > The reason to do so is to remove the per-clock data from the kernel > sources entirely. Separating logic and data. Ok. > > > It also made me want to introduce devm_of_iomap() > > which just seemed wrong (if you have a dev struct why can't you > > use devm_ioremap()). > > [snip] > > > > This is great for making the kernel DT-data-driven, but I > > couldn't find any other driver that was describing register level > > details in DT. > > Yeah, this sucks. Building a binding from a C struct is a bad idea. How > many permutations are there? Hopefully some clocks use the same bit > shifts and have reliable register offsets, with the only difference > being base address. If this is the case then a compatible string could > be done for each permutation assuming that number is low and manageable. In the multimedia controller almost every clock has a different register layout. Making a compatible string for each clock is pretty much what I've done if you consider that I match up the name of the node to a struct instead of matching a compatible string to a struct. In the global controller it's more sane, following a single register layout per compatible string. Remember though, all the single bit clocks (gates or what we call branches) have a completely random location for their on/off bit and status bit. > > > > > The good news is that newer clock controllers follow a standard > > and so we can specify one or two register properties and the type > > of clock and we're pretty much done. The software interface > > hasn't been randomized like on earlier controllers and bits > > within registers are always the same. > > This does not suck. Just for the sake of argument let's say that you > only had to deal with this new and improved register layout and not the > old (current) stuff. Do you still see a reason to match DT data up with > C struct data objects in the kernel? I would still need to match up frequency tables unless I figure out a way to put that in DT too. > > > We still have some clocks > > that are just on/off switches though and so we'll have to put > > register level details like which bit turns that clock on in DT > > (which I believe is not preferred/allowed?). I don't see any way > > to avoid that if we want it to be entirely DT driven. > > This is what I'm doing for the generic clock bindings. No one has > screamed over that stuff so I guess rules were meant to be broken. > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/17] 3.4.58-stable review
On 08/15/2013 06:22 PM, Greg Kroah-Hartman wrote: On Thu, Aug 15, 2013 at 07:45:12AM -0700, Guenter Roeck wrote: On 08/14/2013 11:36 PM, Greg Kroah-Hartman wrote: On Wed, Aug 14, 2013 at 03:14:11AM -0700, Guenter Roeck wrote: On 08/14/2013 01:26 AM, Geert Uytterhoeven wrote: On Wed, Aug 14, 2013 at 12:36 AM, Guenter Roeck wrote: cris/...: In file included from include/linux/page-flags.h:8:0, from kernel/bounds.c:9: include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t' include/linux/types.h:29:1: error: unknown type name '__kernel_off_t' include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t' include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t' include/linux/types.h:33:1: error: unknown type name '__kernel_suseconds_t' That one might be tricky (or simple if someone knows what is wrong). Fixed in v3.5-rc1: commit 74f077d2a7651409c44bb323471f219a4b0d2aab Author: Jiri Slaby Date: Mon Apr 2 13:40:17 2012 +0200 cris: posix_types.h, include asm-generic/posix_types.h It does fix above error, but then there is another error: AS arch/cris/arch-v10/lib/checksum.o In file included from :4:0: /home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1 make[1]: *** Waiting for unfinished jobs AS arch/cris/arch-v10/lib/checksumcopy.o In file included from :4:0: /home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksumcopy.o] Error 1 commit 7b91747d42a1012e3781dd09fa638d113809e3fd Author: Paul Gortmaker Date: Wed Apr 18 21:58:43 2012 +0200 cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile Great, thanks for tracking this down. With both patches applied, we are almost there. Next error: kernel/built-in.o: In function `core_kernel_data': (.text+0x12e38): undefined reference to `_sdata' make: *** [vmlinux] Error 1 This has been fixed with commit 473e162e (CRIS: Add _sdata to vmlinux.lds.S). So, in summary, we have 473e162e CRIS: Add _sdata to vmlinux.lds.S 69349c2d cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile 7b91747d cris: posix_types.h, include asm-generic/posix_types.h With those three patches applied, cris targets build in 3.4.y. Wonderful, I've now applied all of these. Anything else I'm missing for 3.4? Besides the now failing mips buids; Building arm:allmodconfig ... failed -- Error log: .config:25:warning: symbol value '' invalid for PHYS_OFFSET make[2]: *** [silentoldconfig] Error 1 make[1]: *** [silentoldconfig] Error 2 make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'. Stop. That was "fixed" by a complete arm Kconfig overhaul. I don't think you want that in 3.4. -- Not a "complete" overhaul, no. But getting a default allmodconfig building for arm would be nice, if possible. I agree. I'll look into it a bit further. Also, to keep you busy: cd8d2331 alpha: makefile: don't enforce small data model for kernel builds fixes the alpha defconfig build for 3.4. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] mfd: 88pm800: add device tree support
On Thu, Aug 15, 2013 at 6:07 PM, Lee Jones wrote:
>> >> +Optional parent device properties:
>> >> +- marvell,88pm800-irq-write-clear: inicates whether interrupt status is
>> >> cleared by write
>> >> +- marvell,88pm800-battery-detection: indicats whether need 88pm800 to
>> >> support battery
>> >> + detection or not.
>> >
>> > Not sure what these are. This is why you need to CC the Device Tree
>> > guys.
>> >
>> It is the 88pm805's own configuration.
>> 88pm800-irq-write-clear: when irq happens, the status register is
>> write clear or read clear.
>> 88pm800-battery-detection: whether the battery is connected to chip.
>> It means that whether
>> the chip be aware of battery or not.
>
> As you are adding vendor specific bindings, you need to Cc the Device
> Tree mailing list.
>
>> >> + if (IS_ENABLED(CONFIG_OF)) {
>> >> + if (!pdata) {
>> >> + pdata = devm_kzalloc(>dev,
>> >> + sizeof(*pdata), GFP_KERNEL);
>> >> + if (!pdata)
>> >> + return -ENOMEM;
>> >> + }
>> >> + ret = pm800_dt_init(node, >dev, pdata);
>> >> + if (ret)
>> >> + return ret;
>> >> + } else if (!pdata) {
>> >> + return -EINVAL;
>> >> + }
>> >
>> > Replace with:
>> >
>> > if (!pdata) {
>> > if (node)
>> > /* populate pdata with DT */
>> > else
>> > return -EINVAL;
>> > }
>> >
>> The orignial code will cover the following situation.
>> 1. DT enabled, and user pass pdata
>> 2. DT enabled, but user do not pass pdata
>> 3. DT disabled, user pass pdata
>> 4. DT disabled, user do not pass pdata.
>>
>> 88pm805 has a callback for config the it based on platform requirment.
>> I do not want to remove this callback now, because it includes so many
>> configurations.
>> So i allow user can pass pdata with callback if the platform needs to
>> configure the chip.
>
> Mixing DT with pdata is a bad idea. If you need to pass a call-back
> pointer, then _only_ use pdata i.e. get all of your platform specific
> information from pdata, rather than just over-writing sections of it
> with information retrieved from Device Tree.
>
> So:
>
> If pdata - use pdata and ignore DT completely
> If !pdata:
>If DT - use DT
>If !DT - return -EINVAL
>
> Out of interest, what does your call-back do?
>
Without the callback, the soc still can work.
The callback does job relates to power saving and CP's requirment.
1. LPM configure for the chip based on AP/CP's requriment.
2. 88pm800 OSC configuration
3. Some output pin configuration of 88pm800, for example reset_out_n pin
I want to abstract the callback step by step, so the first step are the patches
that enable DT first.
For the patch 0001 and 0002 are fixes, so if these two patches are all
right, can you
merge them? Then i will submit the 2 DT related patches again with cc
to device tree maillist.
Thanks.
> --
> Lee Jones
> Linaro ST-Ericsson Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/17] 3.4.58-stable review
On Thu, Aug 15, 2013 at 07:45:12AM -0700, Guenter Roeck wrote: > On 08/14/2013 11:36 PM, Greg Kroah-Hartman wrote: > > On Wed, Aug 14, 2013 at 03:14:11AM -0700, Guenter Roeck wrote: > >> On 08/14/2013 01:26 AM, Geert Uytterhoeven wrote: > >>> On Wed, Aug 14, 2013 at 12:36 AM, Guenter Roeck > >>> wrote: > >> cris/...: > >> In file included from include/linux/page-flags.h:8:0, > >>from kernel/bounds.c:9: > >> include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t' > >> include/linux/types.h:29:1: error: unknown type name '__kernel_off_t' > >> include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t' > >> include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t' > >> include/linux/types.h:33:1: error: unknown type name > >> '__kernel_suseconds_t' > >> > >> That one might be tricky (or simple if someone knows what is wrong). > > > > Fixed in v3.5-rc1: > > > > commit 74f077d2a7651409c44bb323471f219a4b0d2aab > > Author: Jiri Slaby > > Date: Mon Apr 2 13:40:17 2012 +0200 > > > > cris: posix_types.h, include asm-generic/posix_types.h > > > It does fix above error, but then there is another error: > > AS arch/cris/arch-v10/lib/checksum.o > In file included from :4:0: > /home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: > syntax error in macro parameter list > make[1]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1 > make[1]: *** Waiting for unfinished jobs > AS arch/cris/arch-v10/lib/checksumcopy.o > In file included from :4:0: > /home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: > syntax error in macro parameter list > make[1]: *** [arch/cris/arch-v10/lib/checksumcopy.o] Error 1 > >>> > >>> commit 7b91747d42a1012e3781dd09fa638d113809e3fd > >>> Author: Paul Gortmaker > >>> Date: Wed Apr 18 21:58:43 2012 +0200 > >>> > >>> cris: Remove old legacy "-traditional" flag from > >>> arch-v10/lib/Makefile > >>> > >> > >> Great, thanks for tracking this down. > >> > >> With both patches applied, we are almost there. Next error: > >> > >> kernel/built-in.o: In function `core_kernel_data': > >> (.text+0x12e38): undefined reference to `_sdata' > >> make: *** [vmlinux] Error 1 > >> > >> This has been fixed with commit 473e162e (CRIS: Add _sdata to > >> vmlinux.lds.S). > >> > >> So, in summary, we have > >> > >> 473e162e CRIS: Add _sdata to vmlinux.lds.S > >> 69349c2d cris: Remove old legacy "-traditional" flag from > >> arch-v10/lib/Makefile > >> 7b91747d cris: posix_types.h, include asm-generic/posix_types.h > >> > >> With those three patches applied, cris targets build in 3.4.y. > > > > Wonderful, I've now applied all of these. > > > > Anything else I'm missing for 3.4? > > > Besides the now failing mips buids; > > Building arm:allmodconfig ... failed > -- > Error log: > .config:25:warning: symbol value '' invalid for PHYS_OFFSET > make[2]: *** [silentoldconfig] Error 1 > make[1]: *** [silentoldconfig] Error 2 > make: *** No rule to make target `include/config/auto.conf', needed by > `include/config/kernel.release'. Stop. > > That was "fixed" by a complete arm Kconfig overhaul. I don't think you want > that in 3.4. > -- Not a "complete" overhaul, no. But getting a default allmodconfig building for arm would be nice, if possible. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/17] 3.4.58-stable review
On Thu, Aug 15, 2013 at 08:12:10AM -0700, Guenter Roeck wrote: > On 08/14/2013 11:36 PM, Greg Kroah-Hartman wrote: > > On Wed, Aug 14, 2013 at 03:14:11AM -0700, Guenter Roeck wrote: > >> On 08/14/2013 01:26 AM, Geert Uytterhoeven wrote: > >>> On Wed, Aug 14, 2013 at 12:36 AM, Guenter Roeck > >>> wrote: > >> cris/...: > >> In file included from include/linux/page-flags.h:8:0, > >>from kernel/bounds.c:9: > >> include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t' > >> include/linux/types.h:29:1: error: unknown type name '__kernel_off_t' > >> include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t' > >> include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t' > >> include/linux/types.h:33:1: error: unknown type name > >> '__kernel_suseconds_t' > >> > >> That one might be tricky (or simple if someone knows what is wrong). > > > > Fixed in v3.5-rc1: > > > > commit 74f077d2a7651409c44bb323471f219a4b0d2aab > > Author: Jiri Slaby > > Date: Mon Apr 2 13:40:17 2012 +0200 > > > > cris: posix_types.h, include asm-generic/posix_types.h > > > It does fix above error, but then there is another error: > > AS arch/cris/arch-v10/lib/checksum.o > In file included from :4:0: > /home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: > syntax error in macro parameter list > make[1]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1 > make[1]: *** Waiting for unfinished jobs > AS arch/cris/arch-v10/lib/checksumcopy.o > In file included from :4:0: > /home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: > syntax error in macro parameter list > make[1]: *** [arch/cris/arch-v10/lib/checksumcopy.o] Error 1 > >>> > >>> commit 7b91747d42a1012e3781dd09fa638d113809e3fd > >>> Author: Paul Gortmaker > >>> Date: Wed Apr 18 21:58:43 2012 +0200 > >>> > >>> cris: Remove old legacy "-traditional" flag from > >>> arch-v10/lib/Makefile > >>> > >> > >> Great, thanks for tracking this down. > >> > >> With both patches applied, we are almost there. Next error: > >> > >> kernel/built-in.o: In function `core_kernel_data': > >> (.text+0x12e38): undefined reference to `_sdata' > >> make: *** [vmlinux] Error 1 > >> > >> This has been fixed with commit 473e162e (CRIS: Add _sdata to > >> vmlinux.lds.S). > >> > >> So, in summary, we have > >> > >> 473e162e CRIS: Add _sdata to vmlinux.lds.S > >> 69349c2d cris: Remove old legacy "-traditional" flag from > >> arch-v10/lib/Makefile > >> 7b91747d cris: posix_types.h, include asm-generic/posix_types.h > >> > >> With those three patches applied, cris targets build in 3.4.y. > > > > Wonderful, I've now applied all of these. > > > > Anything else I'm missing for 3.4? > > > One more patch to apply to 3.4: > > aa709f3bc powerpc/numa: Avoid stupid uninitialized warning from gcc Now applied, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 6/7] net: xilinx_emaclite: use platform_{get,set}_drvdata()
On 2013/8/16 6:23, David Miller wrote:
> From: Libo Chen
> Date: Thu, 15 Aug 2013 21:01:47 +0800
>
>> Use the wrapper functions for getting and setting the driver data using
>> platform_device instead of using dev_{get,set}_drvdata() with _dev->dev,
>> so we can directly pass a struct platform_device.
>>
>> Signed-off-by: Libo Chen
>
> Why did you not CC: netdev on this patch?
>
oh, my script doesn`t work well!
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/17] 3.4.58-stable review
On 08/15/2013 05:58 PM, Greg Kroah-Hartman wrote: On Thu, Aug 15, 2013 at 02:07:35AM -0700, Guenter Roeck wrote: On 08/14/2013 11:36 PM, Greg Kroah-Hartman wrote: On Wed, Aug 14, 2013 at 03:14:11AM -0700, Guenter Roeck wrote: On 08/14/2013 01:26 AM, Geert Uytterhoeven wrote: On Wed, Aug 14, 2013 at 12:36 AM, Guenter Roeck wrote: cris/...: In file included from include/linux/page-flags.h:8:0, from kernel/bounds.c:9: include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t' include/linux/types.h:29:1: error: unknown type name '__kernel_off_t' include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t' include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t' include/linux/types.h:33:1: error: unknown type name '__kernel_suseconds_t' That one might be tricky (or simple if someone knows what is wrong). Fixed in v3.5-rc1: commit 74f077d2a7651409c44bb323471f219a4b0d2aab Author: Jiri Slaby Date: Mon Apr 2 13:40:17 2012 +0200 cris: posix_types.h, include asm-generic/posix_types.h It does fix above error, but then there is another error: AS arch/cris/arch-v10/lib/checksum.o In file included from :4:0: /home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1 make[1]: *** Waiting for unfinished jobs AS arch/cris/arch-v10/lib/checksumcopy.o In file included from :4:0: /home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksumcopy.o] Error 1 commit 7b91747d42a1012e3781dd09fa638d113809e3fd Author: Paul Gortmaker Date: Wed Apr 18 21:58:43 2012 +0200 cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile Great, thanks for tracking this down. With both patches applied, we are almost there. Next error: kernel/built-in.o: In function `core_kernel_data': (.text+0x12e38): undefined reference to `_sdata' make: *** [vmlinux] Error 1 This has been fixed with commit 473e162e (CRIS: Add _sdata to vmlinux.lds.S). So, in summary, we have 473e162e CRIS: Add _sdata to vmlinux.lds.S 69349c2d cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile 7b91747d cris: posix_types.h, include asm-generic/posix_types.h With those three patches applied, cris targets build in 3.4.y. Wonderful, I've now applied all of these. Anything else I'm missing for 3.4? frv build in 3.4 is fixed with b9e892f frv: Use core allocator for task_struct 25d0c52 frv: Use correct size for task_struct allocation 25d0c52 must be applied first. Where did you get those git ids from? cce4517f33384c3794c759e206cc8e1bb6df146b is frv: Use correct size for task_struct allocation. c6ae063aaf3786b9db7f19a90bf4ed8aaebb7f90 is frv: Use core allocator for task_struct. I'll queue them up, but you might want to check your git tree... I screwed up - those are the IDs I got after cherry-picking the patches into my tree. Sorry for that. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/17] 3.4.58-stable review
On Thu, Aug 15, 2013 at 02:07:35AM -0700, Guenter Roeck wrote: > On 08/14/2013 11:36 PM, Greg Kroah-Hartman wrote: > > On Wed, Aug 14, 2013 at 03:14:11AM -0700, Guenter Roeck wrote: > >> On 08/14/2013 01:26 AM, Geert Uytterhoeven wrote: > >>> On Wed, Aug 14, 2013 at 12:36 AM, Guenter Roeck > >>> wrote: > >> cris/...: > >> In file included from include/linux/page-flags.h:8:0, > >>from kernel/bounds.c:9: > >> include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t' > >> include/linux/types.h:29:1: error: unknown type name '__kernel_off_t' > >> include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t' > >> include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t' > >> include/linux/types.h:33:1: error: unknown type name > >> '__kernel_suseconds_t' > >> > >> That one might be tricky (or simple if someone knows what is wrong). > > > > Fixed in v3.5-rc1: > > > > commit 74f077d2a7651409c44bb323471f219a4b0d2aab > > Author: Jiri Slaby > > Date: Mon Apr 2 13:40:17 2012 +0200 > > > > cris: posix_types.h, include asm-generic/posix_types.h > > > It does fix above error, but then there is another error: > > AS arch/cris/arch-v10/lib/checksum.o > In file included from :4:0: > /home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: > syntax error in macro parameter list > make[1]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1 > make[1]: *** Waiting for unfinished jobs > AS arch/cris/arch-v10/lib/checksumcopy.o > In file included from :4:0: > /home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: > syntax error in macro parameter list > make[1]: *** [arch/cris/arch-v10/lib/checksumcopy.o] Error 1 > >>> > >>> commit 7b91747d42a1012e3781dd09fa638d113809e3fd > >>> Author: Paul Gortmaker > >>> Date: Wed Apr 18 21:58:43 2012 +0200 > >>> > >>> cris: Remove old legacy "-traditional" flag from > >>> arch-v10/lib/Makefile > >>> > >> > >> Great, thanks for tracking this down. > >> > >> With both patches applied, we are almost there. Next error: > >> > >> kernel/built-in.o: In function `core_kernel_data': > >> (.text+0x12e38): undefined reference to `_sdata' > >> make: *** [vmlinux] Error 1 > >> > >> This has been fixed with commit 473e162e (CRIS: Add _sdata to > >> vmlinux.lds.S). > >> > >> So, in summary, we have > >> > >> 473e162e CRIS: Add _sdata to vmlinux.lds.S > >> 69349c2d cris: Remove old legacy "-traditional" flag from > >> arch-v10/lib/Makefile > >> 7b91747d cris: posix_types.h, include asm-generic/posix_types.h > >> > >> With those three patches applied, cris targets build in 3.4.y. > > > > Wonderful, I've now applied all of these. > > > > Anything else I'm missing for 3.4? > > > > frv build in 3.4 is fixed with > > b9e892f frv: Use core allocator for task_struct > 25d0c52 frv: Use correct size for task_struct allocation > > 25d0c52 must be applied first. Where did you get those git ids from? cce4517f33384c3794c759e206cc8e1bb6df146b is frv: Use correct size for task_struct allocation. c6ae063aaf3786b9db7f19a90bf4ed8aaebb7f90 is frv: Use core allocator for task_struct. I'll queue them up, but you might want to check your git tree... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/17] 3.4.58-stable review
On Thu, Aug 15, 2013 at 01:40:08AM -0700, Guenter Roeck wrote: > On 08/14/2013 11:36 PM, Greg Kroah-Hartman wrote: > > On Wed, Aug 14, 2013 at 03:14:11AM -0700, Guenter Roeck wrote: > >> On 08/14/2013 01:26 AM, Geert Uytterhoeven wrote: > >>> On Wed, Aug 14, 2013 at 12:36 AM, Guenter Roeck > >>> wrote: > >> cris/...: > >> In file included from include/linux/page-flags.h:8:0, > >>from kernel/bounds.c:9: > >> include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t' > >> include/linux/types.h:29:1: error: unknown type name '__kernel_off_t' > >> include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t' > >> include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t' > >> include/linux/types.h:33:1: error: unknown type name > >> '__kernel_suseconds_t' > >> > >> That one might be tricky (or simple if someone knows what is wrong). > > > > Fixed in v3.5-rc1: > > > > commit 74f077d2a7651409c44bb323471f219a4b0d2aab > > Author: Jiri Slaby > > Date: Mon Apr 2 13:40:17 2012 +0200 > > > > cris: posix_types.h, include asm-generic/posix_types.h > > > It does fix above error, but then there is another error: > > AS arch/cris/arch-v10/lib/checksum.o > In file included from :4:0: > /home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: > syntax error in macro parameter list > make[1]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1 > make[1]: *** Waiting for unfinished jobs > AS arch/cris/arch-v10/lib/checksumcopy.o > In file included from :4:0: > /home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: > syntax error in macro parameter list > make[1]: *** [arch/cris/arch-v10/lib/checksumcopy.o] Error 1 > >>> > >>> commit 7b91747d42a1012e3781dd09fa638d113809e3fd > >>> Author: Paul Gortmaker > >>> Date: Wed Apr 18 21:58:43 2012 +0200 > >>> > >>> cris: Remove old legacy "-traditional" flag from > >>> arch-v10/lib/Makefile > >>> > >> > >> Great, thanks for tracking this down. > >> > >> With both patches applied, we are almost there. Next error: > >> > >> kernel/built-in.o: In function `core_kernel_data': > >> (.text+0x12e38): undefined reference to `_sdata' > >> make: *** [vmlinux] Error 1 > >> > >> This has been fixed with commit 473e162e (CRIS: Add _sdata to > >> vmlinux.lds.S). > >> > >> So, in summary, we have > >> > >> 473e162e CRIS: Add _sdata to vmlinux.lds.S > > 473e162e also fixes the cris builds in 3.0, so it might make sense to apply > it there as well, > at least if 3.0 has some lifetime left. It's easy enough, I've queued it up now. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/17] 3.4.58-stable review
On Thu, Aug 15, 2013 at 12:43:57AM -0700, Guenter Roeck wrote:
> On 08/14/2013 11:31 PM, Greg Kroah-Hartman wrote:
> > On Tue, Aug 13, 2013 at 01:19:36PM -0700, Guenter Roeck wrote:
> >> I copied the individual log files for the 3.4 build to
> >> http://roeck-us.net/linux/logs
> >> in case you want to browse through it.
> >>
> >> Here is a summary.
> >>
> >> mips/allmodconfig:
> >> drivers/net/ethernet/3com/3c59x.c: In function 'vortex_init_one':
> >> drivers/net/ethernet/3com/3c59x.c:1031:2: error: implicit declaration of
> >> function 'pci_iomap'
> >>
> >> We have seen that before in 3.10. Commit 78857614104 (MIPS: Expose
> >> missing pci_io{map,unmap} declarations) fixes it.
> >
> > Now applied.
> >
> >> sound/oss/soundcard.c:69:31: error: 'MAX_DMA_CHANNELS' undeclared here
> >> (not in a function)
> >>
> >> This requires
> >> d4702b189c sound: Fix make allmodconfig on MIPS
> >> a62ee234a5 sound: Fix make allmodconfig on MIPS correctly
> >
> > Now applied.
> >
> >> Unfortunately, after applying those patches the build still fails with
> >>
> >> ERROR: "min_low_pfn" [drivers/net/wireless/ath/ath6kl/ath6kl_sdio.ko]
> >> undefined!
> >>
> >> This has been fixed upstream with commit 8b9232141b (MIPS: Rewrite
> >> pfn_valid to work
> >> in modules, too), which applies but results in build failures.
> >
> > What failures? I've applied this now, as it makes sense.
> >
> >> There is a patch from Ben Hutchings which removes the use of
> >> virt_addr_valid() (which causes the problem) from the ath6kl driver,
> >> but that is not in mainline.
> >
> > Ok, I think I'll stop there for MIPS, that's a good start...
> >
>
> I screwed up my stable repo clone again :(, so the full build will take a bit.
>
> mips builds on on 3.4 with all patches applied now fail with:
> arch/mips/include/asm/page.h: Assembler messages:
> arch/mips/include/asm/page.h:178: Error: Unrecognized opcode `static inline
> int pfn_valid(unsigned long pfn)'
> arch/mips/include/asm/page.h:179: Error: junk at end of line, first
> unrecognized character is `{'
> arch/mips/include/asm/page.h:181: Error: Unrecognized opcode `extern unsigned
> long max_mapnr'
> arch/mips/include/asm/page.h:183: Error: Unrecognized opcode `return
> pfn>=ARCH_PFN_OFFSET& arch/mips/include/asm/page.h:184: Error: junk at end of line, first
> unrecognized character is `}'
>
> This is the error I referred to above. Reverting above pfn rework patch fixes
> that problem,
> so you might want to remove that patch from the patch queue for now.
Ok, now removed, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug] Reproducible data corruption on i5-3340M: Please continue your great work! :-)
On Thu, Aug 15, 2013 at 4:05 PM, Ben Tebulin wrote: > >> Ben, please test. I'm worried that the problem you see is something >> even more fundamentally wrong with the whole "oops, must flush in the >> middle" logic, but I'm _hoping_ this fixes it. > > It's gone. > > Really! > > I git-fsck'ed successfully around 30 times in a row. > And even all the other things still seem to work ;-) Goodie. I think I'm just going to commit it (with the speling fixes for other architectures) asap. It's bigger than I'd like, but it's a lot simpler than the alternatives of trying to figure out exactly which call chain got things wrong with the previous confusing model. Thanks for bisecting and testing. > Honestly I have to confess that I'm deeply impressed how this finally > worked out: I just threw a particular, innocent-looking commit hash and > nothing more into the round. Being able to bisect the exact commit that introduced the bad behavior is *very* powerful debugging aid, and in fact the smaller and more innocent-looking the bisected commit is, the easier it generally is to then say "ok, it must be related to this one particular issue". So the bisection really pinpointed the area. After that it was just a matter of reading the source code and seeing what looked suspicious. I'll probably delay committing it until tomorrow, in the hope that somebody using one of the other architectures will at least ack that it compiles. I'm re-attaching the patch (with the two "logn" -> "long" fixes) just to encourage that. Hint hint, everybody.. Linus patch.diff Description: Binary data
Re: page fault scalability (ext3, ext4, xfs)
On Thu, Aug 15, 2013 at 5:14 PM, Dave Chinner wrote: > On Thu, Aug 15, 2013 at 03:26:09PM -0700, Andy Lutomirski wrote: >> On Thu, Aug 15, 2013 at 3:18 PM, Dave Chinner wrote: >> > On Thu, Aug 15, 2013 at 02:43:09PM -0700, Andy Lutomirski wrote: >> >> On Thu, Aug 15, 2013 at 2:37 PM, Dave Chinner >> >> wrote: >> >> > On Thu, Aug 15, 2013 at 08:17:18AM -0700, Andy Lutomirski wrote: > >> >> In current kernels, this chain of events won't work: >> >> >> >> - Server goes down >> >> - Server comes up >> >> - Userspace on server calls mmap and writes something >> >> - Client reconnects and invalidates its cache >> >> - Userspace on server writes something else *to the same page* >> >> >> >> The client will never notice the second write, because it won't update >> >> any inode state. >> > >> > That's wrong. The server wrote the dirty page before the client >> > reconnected, therefore it got marked clean. >> >> Why would it write the dirty page? > > Terminology mismatch - you said it "writes something", not "dirties > the page". So, it's easy to take that as "does writeback" as opposed > to "dirties memory". When I say "writes something" I mean literally performs a store to memory. That is: ptr[offset] = value; In my example, the client will *never* catch up. > >> > The second write to the >> > server page marks it dirty again, causing page_mkwrite to be >> > called, thereby updating the timestamp/i_version field. So, the NFS >> > client will notice the second change on the server, and it will >> > notice it immediately after the second access has occurred, not some >> > time later when: >> > >> >> With my patches, the client will as soon as the >> >> server starts writeback. >> > >> > Your patches introduce a 30+ second window where a file can be dirty >> > on the server but the NFS server doesn't know about it and can't >> > tell the clients about it because i_version doesn't get bumped until >> > writeback. >> >> I claim that there's an infinite window right now, and that 30 seconds >> is therefore an improvement. > > You're talking about after the second change is made. I'm talking > about the difference in behaviour after the *initial change* is > made. Your changes will result in the client not doing an > invalidation because timestamps don't get changed for 30s with your > patches. That's the problem - the first change of a file needs to > bump the i_version immediately, not in 30s time. > > That's why delaying timestamp updates doesn't fix the scalability > problem that was reported. It might fix a different problem, but it > doesn't void the *requirment* that filesystems need to do > transactional updates during page faults > And this is why I'm unconvinced that your requirement is sensible. It's attempting to make sure that every mmaped write results in a some kind of FS update, but it actually only results in an FS update *before* the *first* mmapped write after writeback. It's racy as hell. My approach is slow but not racy. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: olpc_dcon: more big endian conformity
On Thu, Aug 15, 2013 at 09:54:05PM +0200, Jens Frederich wrote: > On Mon, Aug 12, 2013 at 11:07 PM, Greg KH wrote: > > On Sun, Aug 04, 2013 at 11:04:16PM +0200, Jens Frederich wrote: > >> Using an int which is casted to unsigned char as inbuf is messy. > >> The code won't work on big endian systems. The patch should fix > >> this. > >> > >> Signed-off-by: Jens Frederich > > > > This patch doesn't apply at all, can you refresh it against my > > staging-next branch and resend it so that I can apply it? > > > > Sorry for the duplicated patch 3. The subject: > [PATCH] Staging: olpc_dcon: more big endian conformity and > [PATCH 3/3] Staging: olpc_dcon: more big endian conformity > is equal for the Google mail client and lands in the same > thread. I'd use Mutt. I do use mutt, and see two copies of this patch sent. What happened to patch 1/3, I never got that. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging:BCM:DDRInit.c:Replacing __FUNCTION__
On Thu, Aug 15, 2013 at 10:21:29PM +0100, paulmcq...@gmail.com wrote:
>
> __Function__ gets replaced with __func__
>
> Signed-Off-By: Paul McQuade
> ---
> drivers/staging/bcm/DDRInit.c | 54
> -
> 1 file changed, 27 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/staging/bcm/DDRInit.c b/drivers/staging/bcm/DDRInit.c
> index 8c696b6..f5eda96 100644
> --- a/drivers/staging/bcm/DDRInit.c
> +++ b/drivers/staging/bcm/DDRInit.c
> @@ -828,13 +828,13 @@ int ddr_init(struct bcm_mini_adapter *Adapter)
> {
> retval= rdmalt(Adapter,(UINT)0x0f000830,
> , sizeof(uiResetValue));
> if(retval < 0) {
> - BCM_DEBUG_PRINT(Adapter,CMHOST,
> RDM, DBG_LVL_ALL, "%s:%d RDM failed\n", __FUNCTION__, __LINE__);
> + BCM_DEBUG_PRINT(Adapter, CMHOST,
> RDM, DBG_LVL_ALL, "%s:%d RDM failed\n", __func__, __LINE__);
This patch is line-wrapped, and can't be applied :(
Can you take a look at the file, Documentation/email_clients.txt and fix
up your email client so that you can send patches properly?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: page fault scalability (ext3, ext4, xfs)
On Thu, Aug 15, 2013 at 03:26:09PM -0700, Andy Lutomirski wrote: > On Thu, Aug 15, 2013 at 3:18 PM, Dave Chinner wrote: > > On Thu, Aug 15, 2013 at 02:43:09PM -0700, Andy Lutomirski wrote: > >> On Thu, Aug 15, 2013 at 2:37 PM, Dave Chinner > >> wrote: > >> > On Thu, Aug 15, 2013 at 08:17:18AM -0700, Andy Lutomirski wrote: > >> >> My behavior also means that, if an NFS > >> >> client reads and caches the file between the two writes, then it will > >> >> eventually find out that the data is stale. > >> > > >> > "eventually" is very different behaviour to the current behaviour. > >> > > >> > My understanding is that NFS v4 delegations require the underlying > >> > filesystem to bump the version count on *any* modification made to > >> > the file so that delegations can be recalled appropriately. So not > >> > informing the filesystem that the file data has been changed is > >> > going to cause problems. > >> > >> We don't do that right now (and we can't without utterly destroying > >> performance) because we don't trap on every modification. See > >> below... > > > > We don't trap every mmap modification. We trap every modification > > that the filesystem is informed about. That includes a c/mtime > > update on every write page fault. It's as fine grained as we can get > > without introducing serious performance killing overhead. > > > > And nobody has made any compelling argument that what we do now is > > problematic - all we've got is a microbenchmark doesn't quite scale > > linearly because filesystem updates through a global filesystem > > structure (the journal) don't scale linearly. > > I don't personally care about scaling. I care about sleeping in write > faults, and starting journal transactions sleeps, and this is an > absolute show-stopper for me. (It's a real-time latency problem, not > a throughput or scalability thing.) Different problem, then. And one that does actaully have a solution that is already implemented but not exposed to userspace - O_NOCMTIME. i.e. we actually support turning off c/mtime updates on a per file basis - the XFS open-by-handle interface sets this flag by default on files opened that way. Expose that to open/fcntl and your problem is solved without impacting anyone else or default behaviours of filesystems. > >> In current kernels, this chain of events won't work: > >> > >> - Server goes down > >> - Server comes up > >> - Userspace on server calls mmap and writes something > >> - Client reconnects and invalidates its cache > >> - Userspace on server writes something else *to the same page* > >> > >> The client will never notice the second write, because it won't update > >> any inode state. > > > > That's wrong. The server wrote the dirty page before the client > > reconnected, therefore it got marked clean. > > Why would it write the dirty page? Terminology mismatch - you said it "writes something", not "dirties the page". So, it's easy to take that as "does writeback" as opposed to "dirties memory". As to what woudl write it? Memory pressure, a user running sync, ENOSPC conditions, all sorts of things that you can't control. You cannot rely on writeback only happening periodically and therefore being predictable and deterministic. > > The second write to the > > server page marks it dirty again, causing page_mkwrite to be > > called, thereby updating the timestamp/i_version field. So, the NFS > > client will notice the second change on the server, and it will > > notice it immediately after the second access has occurred, not some > > time later when: > > > >> With my patches, the client will as soon as the > >> server starts writeback. > > > > Your patches introduce a 30+ second window where a file can be dirty > > on the server but the NFS server doesn't know about it and can't > > tell the clients about it because i_version doesn't get bumped until > > writeback. > > I claim that there's an infinite window right now, and that 30 seconds > is therefore an improvement. You're talking about after the second change is made. I'm talking about the difference in behaviour after the *initial change* is made. Your changes will result in the client not doing an invalidation because timestamps don't get changed for 30s with your patches. That's the problem - the first change of a file needs to bump the i_version immediately, not in 30s time. That's why delaying timestamp updates doesn't fix the scalability problem that was reported. It might fix a different problem, but it doesn't void the *requirment* that filesystems need to do transactional updates during page faults Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] xhci:prevent "callbacks suppressed" when debug is not enabled
On Thu, Aug 15, 2013 at 07:04:55PM +0300, Dmitry Kasatkin wrote:
> When debug is not enabled and dev_dbg() will expand to nothing,
> log might be flooded with "callbacks suppressed". If it was not
> done on purpose, better to use dev_dbg_ratelimited() instead.
>
> Signed-off-by: Dmitry Kasatkin
> ---
> drivers/usb/host/xhci-ring.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
Sarah, does this patch conflict with the trace debug patches being
worked on? I'll hold off on applying it for now, let me know if it's ok
or not.
thanks,
greg k-h
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index 5b08cd8..5298232 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -3060,8 +3060,7 @@ int xhci_queue_intr_tx(struct xhci_hcd *xhci, gfp_t
> mem_flags,
>* to set the polling interval (once the API is added).
>*/
> if (xhci_interval != ep_interval) {
> - if (printk_ratelimit())
> - dev_dbg(>dev->dev, "Driver uses different interval"
> + dev_dbg_ratelimited(>dev->dev, "Driver uses different
> interval"
> " (%d microframe%s) than xHCI "
> "(%d microframe%s)\n",
> ep_interval,
> @@ -3849,8 +3848,7 @@ int xhci_queue_isoc_tx_prepare(struct xhci_hcd *xhci,
> gfp_t mem_flags,
>* to set the polling interval (once the API is added).
>*/
> if (xhci_interval != ep_interval) {
> - if (printk_ratelimit())
> - dev_dbg(>dev->dev, "Driver uses different interval"
> + dev_dbg_ratelimited(>dev->dev, "Driver uses different
> interval"
> " (%d microframe%s) than xHCI "
> "(%d microframe%s)\n",
> ep_interval,
> --
> 1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
