* Re: [PATCH 2/8] dmaengine: Add flow controller information to dma_slave_config
From: Viresh Kumar @ 2012-01-17 9:07 UTC (permalink / raw)
To: Linus Walleij
Cc: vinod.koul@intel.com, dan.j.williams@intel.com,
linux@arm.linux.org.uk, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Armando VISCONTI,
Shiraz HASHIM, Vipin KUMAR, Rajeev KUMAR, Deepak SIKRI,
Vipul Kumar SAMAR, Amit VIRDI, Pratyush ANAND, Bhupesh SHARMA,
viresh.linux@gmail.com, Bhavna YADAV, Vincenzo FRASCINO,
Mirko GARDI
In-Reply-To: <CACRpkdY4QQK6wtB5aPU+FwdyyGq-owsDxMmxdwJVnkzdJTRs_Q@mail.gmail.com>
On 1/17/2012 2:07 PM, Linus Walleij wrote:
>> > Perhaps, this should be a part of struct dma_slave_config. This patch adds
>> > another field device_fc to this structure. User drivers must pass this as true
>> > if they want to be flow controller of certain transfers.
> I dma_slave_config is supposed to be about info that
>
> 1) Must to be set-up at runtime
Hmmm.. Currently if i check the comments in dmaengine.h, it is written
as you said. But i believe its usage could be more than that.
For example, how amba-pl011 use it today. Nothing dynamic, all static.
Actually the problem scenario is: pl011 is going to use separate DMA drivers
(for ex: dw_dmac and pl08x) for separate platforms. Now, pl011's code shouldn't
be dependent at all on these controllers. So, we have to pass separate data to
these drivers using dma driver specific platform data.
DMA driver's platform data contains two type of stuff: platform specific
(request line, master, etc) and user driver specific (like pl011) (reg address,
burst, width, direction, flow_controller, etc)
Now, its better to have some common struct in dmaengine which can fulfill
requirement of various DMA driver's data.
I find struct dma_slave_config fitting there. All user driver (pl011) specific
data can be passed using this structure. You can call dma_slave_config()
onetime after you got the channel. And after that just submit transfers.
With this i get rid of half of the dw_dmac specific platform data struct and
used already defined struct dma_slave_config.
> 2) All DMA controllers need to know
>
Sorry i didn't understood it well.
One more thing. I missed few things in this patch:
- Need to update all instances of struct dma_slave_config with
.device_fc = false
If, this field is not getting initialized to false by default, then these users
will find their code not working atleast with dw_dmac and amba-pl08x.
Can't say about other drivers.
- Also i need to fixup few atmel drivers which are using dw_dmac.
> So if it doesn't *have* to be set up by drivers at runtime, please keep it in
> platform data.
>
> If it is (1), so you have a use case where you have to switch a certain channel
> between DMA master and device flow control at run-time it looks like it could
> be useful for others as well, but I doubt this so I'd like some back-up on
> that.
I don't have that crazy usecase :)
--
viresh
^ permalink raw reply
* Re: Updated btrfs/crypto snappy interface ready for merging
From: David Sterba @ 2012-01-17 9:07 UTC (permalink / raw)
To: Andi Kleen; +Cc: chris.mason, linux-kernel, linux-btrfs
In-Reply-To: <1326414530-10789-1-git-send-email-andi@firstfloor.org>
On Thu, Jan 12, 2012 at 04:28:47PM -0800, Andi Kleen wrote:
> Here's a slightly updated version of the BTRFS snappy interface.
> snappy is a faster compression algorithm that provides similar
> compression as LZO, but generally better performance.
Recently the LZ4 method showed up on the real-time compression scene
http://fastcompression.blogspot.com/p/lz4.html (homepage)
http://code.google.com/p/lz4/ (source repo)
it has comparable performance and compression ratio to snappy. Quoting
from the source repo main page:
Name Ratio C.speed D.speed
LZ4 (r41) 2.08 319 1070
LZO 2.05 1x_1 2.07 318 466
Snappy 1.0.4 2.02 242 683
My own benchmarking confirms that lz4 is has a bit faster decompression,
but what is a big difference from snappy is it's memory consumption for
compression:
* 32kb for unbounded chunksize
* 16kb for chunksize < 64k (a tuned compression)
No additional memory is needed for decompression in both snappy and lz4.
With a minor tweak and chunksize < 4G the context size could be reduced
to 16k as well.
There is also LZ4HC, "high compression" mode, which maintains same
binary format, but the compression ratio is better.
http://code.google.com/p/lz4hc/
Usecase:
There could be the fast version used transparently and the -hc version
could be allowed for the 'fi defrag' command in order to recompress
selected files.
LZ4 is written in C and it's BSD, LZ4HC is L-GPL. There is some space
for improvements in the code, but as it's good already as it stands now.
david
^ permalink raw reply
* [xen-unstable test] 10781: regressions - FAIL
From: xen.org @ 2012-01-17 9:07 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
flight 10781 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10781/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rhel6hvm-intel 7 redhat-install fail REGR. vs. 10649
test-amd64-i386-xl-multivcpu 11 guest-localmigrate fail REGR. vs. 10649
test-i386-i386-xl 11 guest-localmigrate fail REGR. vs. 10649
test-amd64-i386-xl 11 guest-localmigrate fail REGR. vs. 10649
test-amd64-i386-xl-credit2 11 guest-localmigrate fail REGR. vs. 10649
test-amd64-amd64-win 7 windows-install fail REGR. vs. 10649
test-amd64-i386-xend-winxpsp3 7 windows-install fail REGR. vs. 10649
test-amd64-amd64-xl-winxpsp3 7 windows-install fail REGR. vs. 10649
test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 10649
test-i386-i386-xl-win 7 windows-install fail REGR. vs. 10649
test-amd64-i386-win-vcpus1 7 windows-install fail REGR. vs. 10649
test-amd64-i386-win 7 windows-install fail REGR. vs. 10649
test-i386-i386-win 7 windows-install fail REGR. vs. 10649
test-i386-i386-xl-winxpsp3 7 windows-install fail REGR. vs. 10649
test-amd64-amd64-xl-win 8 guest-saverestore fail in 10776 REGR. vs. 10649
test-amd64-i386-xl-win-vcpus1 8 guest-saverestore fail in 10776 REGR. vs. 10649
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-win 7 windows-install fail pass in 10776
test-amd64-i386-xl-win-vcpus1 7 windows-install fail pass in 10776
test-amd64-amd64-xl-win7-amd64 7 windows-install fail pass in 10776
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-credit2 7 debian-install fail in 10776 like 10645
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass
test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass
test-amd64-amd64-xl-win7-amd64 13 guest-stop fail in 10776 never pass
version targeted for testing:
xen 2913ccc6d70f
baseline version:
xen 5b2676ac1321
------------------------------------------------------------
People who touched revisions under test:
Adin Scannell <adin@scannell.ca>
Andres Lagar-Cavilla <andres@lagarcavilla.org>
Christoph Egger <Christoph.Egger@amd.com>
Daniel De Graaf <dgdegra@tycho.nsa.gov>
Dario Faggioli <dario.faggioli@citrix.com>
Gang Wei <gang.wei@intel.com>
George Dunlap <george.dunlap@eu.citrix.com>
Ian Campbell <ian.campbell@citrix.com>
Ian Jackson <ian.jackson.citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Joseph Cihula <joseph.cihula@intel.com>
Keir Fraser <keir@xen.org>
Olaf Hering <olaf@aepfle.de>
Paul Durrant <paul.durrant@citrix.com>
Roger Pau Monne <roger.pau@entel.upc.edu>
Shane Wang <shane.wang@intel.com>
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tim Deegan <tim@xen.org>
Wei Wang <wei.wang2@amd.com>
Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------
jobs:
build-amd64 pass
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-amd64-i386-xl fail
test-i386-i386-xl fail
test-amd64-i386-rhel6hvm-amd fail
test-amd64-amd64-xl-win7-amd64 fail
test-amd64-i386-xl-win7-amd64 fail
test-amd64-i386-xl-credit2 fail
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel fail
test-amd64-i386-xl-multivcpu fail
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-i386-i386-pair pass
test-amd64-amd64-xl-sedf-pin pass
test-amd64-amd64-pv pass
test-amd64-i386-pv pass
test-i386-i386-pv pass
test-amd64-amd64-xl-sedf pass
test-amd64-i386-win-vcpus1 fail
test-amd64-i386-xl-win-vcpus1 fail
test-amd64-i386-xl-winxpsp3-vcpus1 fail
test-amd64-amd64-win fail
test-amd64-i386-win fail
test-i386-i386-win fail
test-amd64-amd64-xl-win fail
test-i386-i386-xl-win fail
test-amd64-i386-xend-winxpsp3 fail
test-amd64-amd64-xl-winxpsp3 fail
test-i386-i386-xl-winxpsp3 fail
------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Not pushing.
(No revision log; it would be 815 lines long.)
^ permalink raw reply
* [PATCH] Btrfs: fix decompressing of snappy-compressed inline extents
From: Li Zefan @ 2012-01-17 9:07 UTC (permalink / raw)
To: Chris Mason; +Cc: Andi Kleen, linux-btrfs@vger.kernel.org
The first four bytes is the length of all data chunks, and the first
four bytes of each chunk is the length of compressed chunk data,
even when there's only one chunk, which is the case for inline
extents.
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
---
fs/btrfs/snappy.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/snappy.c b/fs/btrfs/snappy.c
index d6bd607..35b877e 100644
--- a/fs/btrfs/snappy.c
+++ b/fs/btrfs/snappy.c
@@ -392,12 +392,16 @@ static int btrfs_snappy_decompress(struct list_head *ws, unsigned char *data_in,
struct workspace *workspace = list_entry(ws, struct workspace, list);
size_t in_len;
size_t out_len;
+ size_t tot_len;
int ret = 0;
char *kaddr;
unsigned long bytes;
BUG_ON(srclen < SNAPPY_LEN);
+ tot_len = read_compress_length(data_in);
+ data_in += SNAPPY_LEN;
+
in_len = read_compress_length(data_in);
data_in += SNAPPY_LEN;
--
1.7.3.1
^ permalink raw reply related
* [PATCH 7/8] dmaengine/dw_dmac: Unmap all memory buffers after completion of slave transfers
From: Viresh Kumar @ 2012-01-17 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdY-4wWeD=3mJiChi6+4=iBMcd3kVh3h4JmDZ5ySXY3KCA@mail.gmail.com>
On 1/17/2012 2:22 PM, Linus Walleij wrote:
> Basically the driver using the dmaengine shall map/unmap buffers
> used for slave transfers, not the driver.
>
> I usually map them before setting up a transfer and unmaps them
> when egtting the callback from the DMA engine that the transfer is
> complete.
>
You implemented similar stuff in amba-pl08x :) .
if (!plchan->slave)
pl08x_unmap_buffers(txd);
> Why do you want to do this?
This is because people can pass in flags which are
DMA_COMPL_SKIP_SRC_UNMAP, etc.
If they are not passed, then DMA driver must do it for them.
Sorry if i am understanding the DMA logic incorrectly.
--
viresh
^ permalink raw reply
* [PATCH 2/8] dmaengine: Add flow controller information to dma_slave_config
From: Viresh Kumar @ 2012-01-17 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdY4QQK6wtB5aPU+FwdyyGq-owsDxMmxdwJVnkzdJTRs_Q@mail.gmail.com>
On 1/17/2012 2:07 PM, Linus Walleij wrote:
>> > Perhaps, this should be a part of struct dma_slave_config. This patch adds
>> > another field device_fc to this structure. User drivers must pass this as true
>> > if they want to be flow controller of certain transfers.
> I dma_slave_config is supposed to be about info that
>
> 1) Must to be set-up at runtime
Hmmm.. Currently if i check the comments in dmaengine.h, it is written
as you said. But i believe its usage could be more than that.
For example, how amba-pl011 use it today. Nothing dynamic, all static.
Actually the problem scenario is: pl011 is going to use separate DMA drivers
(for ex: dw_dmac and pl08x) for separate platforms. Now, pl011's code shouldn't
be dependent at all on these controllers. So, we have to pass separate data to
these drivers using dma driver specific platform data.
DMA driver's platform data contains two type of stuff: platform specific
(request line, master, etc) and user driver specific (like pl011) (reg address,
burst, width, direction, flow_controller, etc)
Now, its better to have some common struct in dmaengine which can fulfill
requirement of various DMA driver's data.
I find struct dma_slave_config fitting there. All user driver (pl011) specific
data can be passed using this structure. You can call dma_slave_config()
onetime after you got the channel. And after that just submit transfers.
With this i get rid of half of the dw_dmac specific platform data struct and
used already defined struct dma_slave_config.
> 2) All DMA controllers need to know
>
Sorry i didn't understood it well.
One more thing. I missed few things in this patch:
- Need to update all instances of struct dma_slave_config with
.device_fc = false
If, this field is not getting initialized to false by default, then these users
will find their code not working atleast with dw_dmac and amba-pl08x.
Can't say about other drivers.
- Also i need to fixup few atmel drivers which are using dw_dmac.
> So if it doesn't *have* to be set up by drivers at runtime, please keep it in
> platform data.
>
> If it is (1), so you have a use case where you have to switch a certain channel
> between DMA master and device flow control at run-time it looks like it could
> be useful for others as well, but I doubt this so I'd like some back-up on
> that.
I don't have that crazy usecase :)
--
viresh
^ permalink raw reply
* Re: [Qemu-devel] [PULL 00/17] usb patch queue: audio, xhci, usbredir
From: Gerd Hoffmann @ 2012-01-17 9:06 UTC (permalink / raw)
To: Anthony Liguori; +Cc: qemu-devel
In-Reply-To: <4F104B96.1020707@codemonkey.ws>
[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]
On 01/13/12 16:19, Anthony Liguori wrote:
> On 01/13/2012 04:18 AM, Gerd Hoffmann wrote:
>> Hi,
>>
>> Here comes the usb patch queue. It features the patches posted a week
>> ago for review with some minor tweaks according to the review comments:
>> The comment in usb-audio was fixed and xhci got a codestyle cleanup. No
>> actual code changes. I've also included the usb-redir patches posted by
>> Hans earlier this week.
>>
>
> cc1: warnings being treated as errors
> /home/anthony/git/qemu/hw/usb-xhci.c: In function ‘xhci_process_commands’:
> /home/anthony/git/qemu/hw/usb-xhci.c:2143:9: error: case value ‘48’ not
> in enumerated type ‘TRBType’
> /home/anthony/git/qemu/hw/usb-xhci.c:2147:9: error: case value ‘49’ not
> in enumerated type ‘TRBType’
> /home/anthony/git/qemu/hw/usb-xhci.c:2152:9: error: case value ‘50’ not
> in enumerated type ‘TRBType’
> make[1]: *** [usb-xhci.o] Error 1
Fixed & pushed to git://git.kraxel.org/qemu usb.37
diff between usb.36 and usb.37 attached for reference.
cheers,
Gerd
[-- Attachment #2: xhci-warnfix.diff --]
[-- Type: text/plain, Size: 1331 bytes --]
diff --git a/hw/usb-xhci.c b/hw/usb-xhci.c
index 0c5007b..28fe9de 100644
--- a/hw/usb-xhci.c
+++ b/hw/usb-xhci.c
@@ -177,7 +177,11 @@ typedef enum TRBType {
ER_DOORBELL,
ER_HOST_CONTROLLER,
ER_DEVICE_NOTIFICATION,
- ER_MFINDEX_WRAP
+ ER_MFINDEX_WRAP,
+ /* vendor specific bits */
+ CR_VENDOR_VIA_CHALLENGE_RESPONSE = 48,
+ CR_VENDOR_NEC_FIRMWARE_REVISION = 49,
+ CR_VENDOR_NEC_CHALLENGE_RESPONSE = 50,
} TRBType;
#define CR_LINK TR_LINK
@@ -2140,18 +2144,15 @@ static void xhci_process_commands(XHCIState *xhci)
case CR_GET_PORT_BANDWIDTH:
event.ccode = xhci_get_port_bandwidth(xhci, trb.parameter);
break;
- case 48:
- /* VIA challenge response */
+ case CR_VENDOR_VIA_CHALLENGE_RESPONSE:
xhci_via_challenge(trb.parameter);
break;
- case 49:
- /* NEC get FW revision */
+ case CR_VENDOR_NEC_FIRMWARE_REVISION:
event.type = 48; /* NEC reply */
event.length = 0x3025;
break;
- case 50:
+ case CR_VENDOR_NEC_CHALLENGE_RESPONSE:
{
- /* NEC challenge response */
uint32_t chi = trb.parameter >> 32;
uint32_t clo = trb.parameter;
uint32_t val = xhci_nec_challenge(chi, clo);
^ permalink raw reply related
* [Bug 44848] OpenArena brightness control does not work
From: bugzilla-daemon @ 2012-01-17 9:06 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-44848-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=44848
Michel Dänzer <michel@daenzer.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE
--- Comment #1 from Michel Dänzer <michel@daenzer.net> 2012-01-17 01:06:45 PST ---
*** This bug has been marked as a duplicate of bug 27222 ***
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [BUG] TASK_DEAD task is able to be woken up in special condition
From: Ingo Molnar @ 2012-01-17 9:06 UTC (permalink / raw)
To: Yasunori Goto, Thomas Gleixner
Cc: Peter Zijlstra, Oleg Nesterov, Hiroyuki KAMEZAWA, Motohiro Kosaki,
Linux Kernel ML
In-Reply-To: <20120117174031.3118.E1E9C6FF@jp.fujitsu.com>
* Yasunori Goto <y-goto@jp.fujitsu.com> wrote:
> --- linux-3.2.orig/kernel/exit.c
> +++ linux-3.2/kernel/exit.c
> @@ -1038,6 +1038,22 @@ NORET_TYPE void do_exit(long code)
>
> preempt_disable();
> exit_rcu();
> +
> + /*
> + * The setting of TASK_RUNNING by try_to_wake_up() may be delayed
> + * when the following two conditions become true.
> + * - There is race condition of mmap_sem (It is acquired by
> + * exit_mm()), and
> + * - SMI occurs before setting TASK_RUNINNG.
> + * (or hypervisor of virtual machine switches to other guest)
> + * As a result, we may become TASK_RUNNING after becoming TASK_DEAD
> + *
> + * To avoid it, we have to wait for releasing tsk->pi_lock which
> + * is held by try_to_wake_up()
> + */
> + smp_mb();
> + raw_spin_unlock_wait(&tsk->pi_lock);
Hm, unlock_wait() is really nasty. Wouldnt the adoption of the
-rt kernel's delayed task put logic solve most of these races?
It's the patch below - we could get rid of the
CONFIG_PREEMPT_RT_BASE and make it unconditional.
[ The -rt kernel is facing similar "sudden outbreak of large
delays" constraints as hypervisors or SMI victims do, so even
if the delayed-task-put patch does not solve the race, some
other -rt patch might :-) ]
Thanks,
Ingo
-------------------->
Subject: sched-delay-put-task.patch
From: Thomas Gleixner <tglx@linutronix.de>
Date: Tue, 31 May 2011 16:59:16 +0200
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
include/linux/sched.h | 13 +++++++++++++
kernel/fork.c | 11 +++++++++++
2 files changed, 24 insertions(+)
Index: linux-3.2/include/linux/sched.h
===================================================================
--- linux-3.2.orig/include/linux/sched.h
+++ linux-3.2/include/linux/sched.h
@@ -1588,6 +1588,9 @@ struct task_struct {
#ifdef CONFIG_HAVE_HW_BREAKPOINT
atomic_t ptrace_bp_refcnt;
#endif
+#ifdef CONFIG_PREEMPT_RT_BASE
+ struct rcu_head put_rcu;
+#endif
};
/* Future-safe accessor for struct task_struct's cpus_allowed. */
@@ -1772,6 +1775,15 @@ extern struct pid *cad_pid;
extern void free_task(struct task_struct *tsk);
#define get_task_struct(tsk) do { atomic_inc(&(tsk)->usage); } while(0)
+#ifdef CONFIG_PREEMPT_RT_BASE
+extern void __put_task_struct_cb(struct rcu_head *rhp);
+
+static inline void put_task_struct(struct task_struct *t)
+{
+ if (atomic_dec_and_test(&t->usage))
+ call_rcu(&t->put_rcu, __put_task_struct_cb);
+}
+#else
extern void __put_task_struct(struct task_struct *t);
static inline void put_task_struct(struct task_struct *t)
@@ -1779,6 +1791,7 @@ static inline void put_task_struct(struc
if (atomic_dec_and_test(&t->usage))
__put_task_struct(t);
}
+#endif
extern void task_times(struct task_struct *p, cputime_t *ut, cputime_t *st);
extern void thread_group_times(struct task_struct *p, cputime_t *ut, cputime_t *st);
Index: linux-3.2/kernel/fork.c
===================================================================
--- linux-3.2.orig/kernel/fork.c
+++ linux-3.2/kernel/fork.c
@@ -197,7 +197,18 @@ void __put_task_struct(struct task_struc
if (!profile_handoff_task(tsk))
free_task(tsk);
}
+#ifndef CONFIG_PREEMPT_RT_BASE
EXPORT_SYMBOL_GPL(__put_task_struct);
+#else
+void __put_task_struct_cb(struct rcu_head *rhp)
+{
+ struct task_struct *tsk = container_of(rhp, struct task_struct, rcu);
+
+ __put_task_struct(tsk);
+
+}
+EXPORT_SYMBOL_GPL(__put_task_struct_cb);
+#endif
/*
* macro override instead of weak attribute alias, to workaround
^ permalink raw reply
* Re: [RFC] mmc: core: add the capability for broken voltage
From: Kyungmin Park @ 2012-01-17 9:05 UTC (permalink / raw)
To: Adrian Hunter; +Cc: Jaehoon Chung, linux-mmc, Chris Ball, Mark Brown
In-Reply-To: <4F152A8F.5070506@intel.com>
On 1/17/12, Adrian Hunter <adrian.hunter@intel.com> wrote:
> On 16/01/12 10:49, Jaehoon Chung wrote:
>> This patch is added the MMC_CAP2_BROKEN_VOLTAGE.
>>
>> if the voltage didn't satisfy between min_uV and max_uV,
>
> Why is the fixed voltage not in the acceptable range for the card?
> Doesn't that risk breaking the card?
Hi Adrian,
I don't know, they uses the not supported voltage. but it's worked
properly for long time.
Galaxy S2 also uses the same voltage as ours.
I also think the modify the regulator framework to support voltage
change at fixed regulator. but it's not good idea and doesn't match
the regulator concept. so modify the sdhci codes to support our
boards.
Thank you,
Kyungmin Park
>
>> try to change the voltage in core.c.
>> When change the voltage, maybe use the regulator_set_voltage().
>>
>> In regulator_set_voltage(), check the below condition.
>>
>> /* sanity check */
>> if (!rdev->desc->ops->set_voltage &&
>> !rdev->desc->ops->set_voltage_sel) {
>> ret = -EINVAL;
>> goto out;
>> }
>>
>> If Some-board should use the fixed-regulator, always return -EINVAL.
>> Then, eMMC didn't initialize always.
>>
>> So if use the fixed-regulator or etc, we need to add the
>> MMC_CAP2_BROKEN_VOLTAGE.
>>
>> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
>> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
>> ---
>> drivers/mmc/core/core.c | 4 ++++
>> include/linux/mmc/host.h | 1 +
>> 2 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>> index bec0bf2..6848789 100644
>> --- a/drivers/mmc/core/core.c
>> +++ b/drivers/mmc/core/core.c
>> @@ -1121,6 +1121,10 @@ int mmc_regulator_set_ocr(struct mmc_host *mmc,
>> * might not allow this operation
>> */
>> voltage = regulator_get_voltage(supply);
>> +
>> + if (mmc->caps2 & MMC_CAP2_BROKEN_VOLTAGE)
>> + min_uV = max_uV = voltage;
>> +
>> if (voltage < 0)
>> result = voltage;
>> else if (voltage < min_uV || voltage > max_uV)
>> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
>> index dd13e05..5659aee 100644
>> --- a/include/linux/mmc/host.h
>> +++ b/include/linux/mmc/host.h
>> @@ -257,6 +257,7 @@ struct mmc_host {
>> #define MMC_CAP2_HS200_1_2V_SDR (1 << 6) /* can support */
>> #define MMC_CAP2_HS200 (MMC_CAP2_HS200_1_8V_SDR | \
>> MMC_CAP2_HS200_1_2V_SDR)
>> +#define MMC_CAP2_BROKEN_VOLTAGE (1 << 7) /* Use the broken voltage */
>>
>> mmc_pm_flag_t pm_caps; /* supported pm features */
>> unsigned int power_notify_type;
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v2] NFC: Export new attributes sensb_res and sensf_res
From: ilanelias78 @ 2012-01-17 9:06 UTC (permalink / raw)
To: samuel, lauro.venancio, aloisio.almeida, linville
Cc: linux-wireless, Ilan Elias
From: Ilan Elias <ilane@ti.com>
Export new attributes sensb_res for tech B and sensf_res
for tech F in the target info (returned as a response to
NFC_CMD_GET_TARGET).
The max size of the attributes nfcid1, sensb_res and sensf_res
is exported to user space though include/linux/nfc.
Signed-off-by: Ilan Elias <ilane@ti.com>
---
v2: export max size of attributes to user space (Thanks Samuel)
include/linux/nfc.h | 7 +++
include/net/nfc/nci.h | 19 ++++++++
include/net/nfc/nfc.h | 8 +++-
net/nfc/nci/ntf.c | 111 +++++++++++++++++++++++++++++++++++++++++++------
net/nfc/netlink.c | 6 +++
5 files changed, 136 insertions(+), 15 deletions(-)
diff --git a/include/linux/nfc.h b/include/linux/nfc.h
index 01d4e5d..b4999ab 100644
--- a/include/linux/nfc.h
+++ b/include/linux/nfc.h
@@ -89,6 +89,8 @@ enum nfc_commands {
* @NFC_ATTR_TARGET_SEL_RES: NFC-A targets extra information (useful if the
* target is not NFC-Forum compliant)
* @NFC_ATTR_TARGET_NFCID1: NFC-A targets identifier, max 10 bytes
+ * @NFC_ATTR_TARGET_SENSB_RES: NFC-B targets extra information, max 12 bytes
+ * @NFC_ATTR_TARGET_SENSF_RES: NFC-F targets extra information, max 18 bytes
* @NFC_ATTR_COMM_MODE: Passive or active mode
* @NFC_ATTR_RF_MODE: Initiator or target
*/
@@ -101,6 +103,8 @@ enum nfc_attrs {
NFC_ATTR_TARGET_SENS_RES,
NFC_ATTR_TARGET_SEL_RES,
NFC_ATTR_TARGET_NFCID1,
+ NFC_ATTR_TARGET_SENSB_RES,
+ NFC_ATTR_TARGET_SENSF_RES,
NFC_ATTR_COMM_MODE,
NFC_ATTR_RF_MODE,
/* private: internal use only */
@@ -109,6 +113,9 @@ enum nfc_attrs {
#define NFC_ATTR_MAX (__NFC_ATTR_AFTER_LAST - 1)
#define NFC_DEVICE_NAME_MAXSIZE 8
+#define NFC_NFCID1_MAXSIZE 10
+#define NFC_SENSB_RES_MAXSIZE 12
+#define NFC_SENSF_RES_MAXSIZE 18
/* NFC protocols */
#define NFC_PROTO_JEWEL 1
diff --git a/include/net/nfc/nci.h b/include/net/nfc/nci.h
index 2be95e2..34f5ed2 100644
--- a/include/net/nfc/nci.h
+++ b/include/net/nfc/nci.h
@@ -275,11 +275,27 @@ struct rf_tech_specific_params_nfca_poll {
__u8 sel_res;
} __packed;
+struct rf_tech_specific_params_nfcb_poll {
+ __u8 sensb_res_len;
+ __u8 sensb_res[12]; /* 11 or 12 Bytes */
+} __packed;
+
+struct rf_tech_specific_params_nfcf_poll {
+ __u8 bit_rate;
+ __u8 sensf_res_len;
+ __u8 sensf_res[18]; /* 16 or 18 Bytes */
+} __packed;
+
struct activation_params_nfca_poll_iso_dep {
__u8 rats_res_len;
__u8 rats_res[20];
};
+struct activation_params_nfcb_poll_iso_dep {
+ __u8 attrib_res_len;
+ __u8 attrib_res[50];
+};
+
struct nci_rf_intf_activated_ntf {
__u8 rf_discovery_id;
__u8 rf_interface;
@@ -291,6 +307,8 @@ struct nci_rf_intf_activated_ntf {
union {
struct rf_tech_specific_params_nfca_poll nfca_poll;
+ struct rf_tech_specific_params_nfcb_poll nfcb_poll;
+ struct rf_tech_specific_params_nfcf_poll nfcf_poll;
} rf_tech_specific_params;
__u8 data_exch_rf_tech_and_mode;
@@ -300,6 +318,7 @@ struct nci_rf_intf_activated_ntf {
union {
struct activation_params_nfca_poll_iso_dep nfca_poll_iso_dep;
+ struct activation_params_nfcb_poll_iso_dep nfcb_poll_iso_dep;
} activation_params;
} __packed;
diff --git a/include/net/nfc/nfc.h b/include/net/nfc/nfc.h
index 8696b77..819530d 100644
--- a/include/net/nfc/nfc.h
+++ b/include/net/nfc/nfc.h
@@ -24,6 +24,7 @@
#ifndef __NET_NFC_H
#define __NET_NFC_H
+#include <linux/nfc.h>
#include <linux/device.h>
#include <linux/skbuff.h>
@@ -65,7 +66,6 @@ struct nfc_ops {
#define NFC_TARGET_IDX_ANY -1
#define NFC_MAX_GT_LEN 48
-#define NFC_MAX_NFCID1_LEN 10
struct nfc_target {
u32 idx;
@@ -73,7 +73,11 @@ struct nfc_target {
u16 sens_res;
u8 sel_res;
u8 nfcid1_len;
- u8 nfcid1[NFC_MAX_NFCID1_LEN];
+ u8 nfcid1[NFC_NFCID1_MAXSIZE];
+ u8 sensb_res_len;
+ u8 sensb_res[NFC_SENSB_RES_MAXSIZE];
+ u8 sensf_res_len;
+ u8 sensf_res[NFC_SENSF_RES_MAXSIZE];
};
struct nfc_genl_data {
diff --git a/net/nfc/nci/ntf.c b/net/nfc/nci/ntf.c
index b16a8dc..5b2b013 100644
--- a/net/nfc/nci/ntf.c
+++ b/net/nfc/nci/ntf.c
@@ -115,15 +115,53 @@ static __u8 *nci_extract_rf_params_nfca_passive_poll(struct nci_dev *ndev,
return data;
}
+static __u8 *nci_extract_rf_params_nfcb_passive_poll(struct nci_dev *ndev,
+ struct nci_rf_intf_activated_ntf *ntf, __u8 *data)
+{
+ struct rf_tech_specific_params_nfcb_poll *nfcb_poll;
+
+ nfcb_poll = &ntf->rf_tech_specific_params.nfcb_poll;
+
+ nfcb_poll->sensb_res_len = *data++;
+
+ pr_debug("sensb_res_len %d\n", nfcb_poll->sensb_res_len);
+
+ memcpy(nfcb_poll->sensb_res, data, nfcb_poll->sensb_res_len);
+ data += nfcb_poll->sensb_res_len;
+
+ return data;
+}
+
+static __u8 *nci_extract_rf_params_nfcf_passive_poll(struct nci_dev *ndev,
+ struct nci_rf_intf_activated_ntf *ntf, __u8 *data)
+{
+ struct rf_tech_specific_params_nfcf_poll *nfcf_poll;
+
+ nfcf_poll = &ntf->rf_tech_specific_params.nfcf_poll;
+
+ nfcf_poll->bit_rate = *data++;
+ nfcf_poll->sensf_res_len = *data++;
+
+ pr_debug("bit_rate %d, sensf_res_len %d\n",
+ nfcf_poll->bit_rate, nfcf_poll->sensf_res_len);
+
+ memcpy(nfcf_poll->sensf_res, data, nfcf_poll->sensf_res_len);
+ data += nfcf_poll->sensf_res_len;
+
+ return data;
+}
+
static int nci_extract_activation_params_iso_dep(struct nci_dev *ndev,
struct nci_rf_intf_activated_ntf *ntf, __u8 *data)
{
struct activation_params_nfca_poll_iso_dep *nfca_poll;
+ struct activation_params_nfcb_poll_iso_dep *nfcb_poll;
switch (ntf->activation_rf_tech_and_mode) {
case NCI_NFC_A_PASSIVE_POLL_MODE:
nfca_poll = &ntf->activation_params.nfca_poll_iso_dep;
nfca_poll->rats_res_len = *data++;
+ pr_debug("rats_res_len %d\n", nfca_poll->rats_res_len);
if (nfca_poll->rats_res_len > 0) {
memcpy(nfca_poll->rats_res,
data,
@@ -131,6 +169,18 @@ static int nci_extract_activation_params_iso_dep(struct nci_dev *ndev,
}
break;
+ case NCI_NFC_B_PASSIVE_POLL_MODE:
+ nfcb_poll = &ntf->activation_params.nfcb_poll_iso_dep;
+ nfcb_poll->attrib_res_len = *data++;
+ pr_debug("attrib_res_len %d\n",
+ nfcb_poll->attrib_res_len);
+ if (nfcb_poll->attrib_res_len > 0) {
+ memcpy(nfcb_poll->attrib_res,
+ data,
+ nfcb_poll->attrib_res_len);
+ }
+ break;
+
default:
pr_err("unsupported activation_rf_tech_and_mode 0x%x\n",
ntf->activation_rf_tech_and_mode);
@@ -145,21 +195,14 @@ static void nci_target_found(struct nci_dev *ndev,
{
struct nfc_target nfc_tgt;
- if (ntf->rf_protocol == NCI_RF_PROTOCOL_T2T) /* T2T MifareUL */
+ memset(&nfc_tgt, 0, sizeof(nfc_tgt));
+
+ if (ntf->rf_protocol == NCI_RF_PROTOCOL_T2T)
nfc_tgt.supported_protocols = NFC_PROTO_MIFARE_MASK;
- else if (ntf->rf_protocol == NCI_RF_PROTOCOL_ISO_DEP) /* 4A */
+ else if (ntf->rf_protocol == NCI_RF_PROTOCOL_ISO_DEP)
nfc_tgt.supported_protocols = NFC_PROTO_ISO14443_MASK;
- else
- nfc_tgt.supported_protocols = 0;
-
- nfc_tgt.sens_res = ntf->rf_tech_specific_params.nfca_poll.sens_res;
- nfc_tgt.sel_res = ntf->rf_tech_specific_params.nfca_poll.sel_res;
- nfc_tgt.nfcid1_len = ntf->rf_tech_specific_params.nfca_poll.nfcid1_len;
- if (nfc_tgt.nfcid1_len > 0) {
- memcpy(nfc_tgt.nfcid1,
- ntf->rf_tech_specific_params.nfca_poll.nfcid1,
- nfc_tgt.nfcid1_len);
- }
+ else if (ntf->rf_protocol == NCI_RF_PROTOCOL_T3T)
+ nfc_tgt.supported_protocols = NFC_PROTO_FELICA_MASK;
if (!(nfc_tgt.supported_protocols & ndev->poll_prots)) {
pr_debug("the target found does not have the desired protocol\n");
@@ -169,6 +212,38 @@ static void nci_target_found(struct nci_dev *ndev,
pr_debug("new target found, supported_protocols 0x%x\n",
nfc_tgt.supported_protocols);
+ if (ntf->activation_rf_tech_and_mode == NCI_NFC_A_PASSIVE_POLL_MODE) {
+ nfc_tgt.sens_res =
+ ntf->rf_tech_specific_params.nfca_poll.sens_res;
+ nfc_tgt.sel_res =
+ ntf->rf_tech_specific_params.nfca_poll.sel_res;
+ nfc_tgt.nfcid1_len =
+ ntf->rf_tech_specific_params.nfca_poll.nfcid1_len;
+ if (nfc_tgt.nfcid1_len > 0) {
+ memcpy(nfc_tgt.nfcid1,
+ ntf->rf_tech_specific_params.nfca_poll.nfcid1,
+ nfc_tgt.nfcid1_len);
+ }
+ } else if (ntf->activation_rf_tech_and_mode ==
+ NCI_NFC_B_PASSIVE_POLL_MODE) {
+ nfc_tgt.sensb_res_len =
+ ntf->rf_tech_specific_params.nfcb_poll.sensb_res_len;
+ if (nfc_tgt.sensb_res_len > 0) {
+ memcpy(nfc_tgt.sensb_res,
+ ntf->rf_tech_specific_params.nfcb_poll.sensb_res,
+ nfc_tgt.sensb_res_len);
+ }
+ } else if (ntf->activation_rf_tech_and_mode ==
+ NCI_NFC_F_PASSIVE_POLL_MODE) {
+ nfc_tgt.sensf_res_len =
+ ntf->rf_tech_specific_params.nfcf_poll.sensf_res_len;
+ if (nfc_tgt.sensf_res_len > 0) {
+ memcpy(nfc_tgt.sensf_res,
+ ntf->rf_tech_specific_params.nfcf_poll.sensf_res,
+ nfc_tgt.sensf_res_len);
+ }
+ }
+
ndev->target_available_prots = nfc_tgt.supported_protocols;
ndev->max_data_pkt_payload_size = ntf->max_data_pkt_payload_size;
ndev->initial_num_credits = ntf->initial_num_credits;
@@ -215,6 +290,16 @@ static void nci_rf_intf_activated_ntf_packet(struct nci_dev *ndev,
&ntf, data);
break;
+ case NCI_NFC_B_PASSIVE_POLL_MODE:
+ data = nci_extract_rf_params_nfcb_passive_poll(ndev,
+ &ntf, data);
+ break;
+
+ case NCI_NFC_F_PASSIVE_POLL_MODE:
+ data = nci_extract_rf_params_nfcf_passive_poll(ndev,
+ &ntf, data);
+ break;
+
default:
pr_err("unsupported activation_rf_tech_and_mode 0x%x\n",
ntf.activation_rf_tech_and_mode);
diff --git a/net/nfc/netlink.c b/net/nfc/netlink.c
index 6989dfa..07f0348 100644
--- a/net/nfc/netlink.c
+++ b/net/nfc/netlink.c
@@ -70,6 +70,12 @@ static int nfc_genl_send_target(struct sk_buff *msg, struct nfc_target *target,
if (target->nfcid1_len > 0)
NLA_PUT(msg, NFC_ATTR_TARGET_NFCID1, target->nfcid1_len,
target->nfcid1);
+ if (target->sensb_res_len > 0)
+ NLA_PUT(msg, NFC_ATTR_TARGET_SENSB_RES, target->sensb_res_len,
+ target->sensb_res);
+ if (target->sensf_res_len > 0)
+ NLA_PUT(msg, NFC_ATTR_TARGET_SENSF_RES, target->sensf_res_len,
+ target->sensf_res);
return genlmsg_end(msg, hdr);
--
1.7.0.4
^ permalink raw reply related
* PULL request: remove superfluous DTV_CMDs
From: Patrick Boettcher @ 2012-01-17 9:02 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-media, Dan Carpenter
Hi Mauro
I fixed a warning caused by a commit made a long time ago in
dvb_frontend.c .
Thanks to Dan Carpenter for pointing this one out.
-----------------
The following changes since commit
1e73fa5d56333230854ae9460579eb2fcee8af02:
Mauro Carvalho Chehab (1):
[media] stb6100: Properly retrieve symbol rate
are available in the git repository at:
http://linuxtv.org/git/pb/media_tree.git staging/for_v3.3
Patrick Boettcher (1):
[media] DVB-CORE: remove superfluous DTV_CMDs
drivers/media/dvb/dvb-core/dvb_frontend.c | 19 -------------------
1 files changed, 0 insertions(+), 19 deletions(-)
best regards,
--
Patrick Boettcher
Kernel Labs Inc.
http://www.kernellabs.com/
^ permalink raw reply
* Re: [PATCH] gpio: Add missing spin_lock_init in gpio-pch driver
From: Linus Walleij @ 2012-01-17 9:02 UTC (permalink / raw)
To: Axel Lin; +Cc: linux-kernel, Tomoya MORINAGA, Grant Likely, Linus Walleij
In-Reply-To: <1326789637.7383.1.camel@phoenix>
On Tue, Jan 17, 2012 at 9:40 AM, Axel Lin <axel.lin@gmail.com> wrote:
> This bug was introduced by commit d568a681
> "gpio-pch: add spinlock in suspend/resume processing"
> which adds a spinlock to struct pch_gpio but never init the spinlock.
>
> Reported-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [RFC 0/3]block: An IOPS based ioscheduler
From: Vivek Goyal @ 2012-01-17 9:02 UTC (permalink / raw)
To: Shaohua Li; +Cc: Dave Chinner, linux-kernel, axboe, jmoyer, zhu.yanhai
In-Reply-To: <1326762388.22361.613.camel@sli10-conroe>
On Tue, Jan 17, 2012 at 09:06:28AM +0800, Shaohua Li wrote:
> On Mon, 2012-01-16 at 03:29 -0500, Vivek Goyal wrote:
> > On Mon, Jan 16, 2012 at 03:55:41PM +0800, Shaohua Li wrote:
> > > On Mon, 2012-01-16 at 02:11 -0500, Vivek Goyal wrote:
> > > > On Mon, Jan 16, 2012 at 12:36:30PM +0800, Shaohua Li wrote:
> > > > > On Sun, 2012-01-15 at 17:45 -0500, Vivek Goyal wrote:
> > > > > > On Mon, Jan 09, 2012 at 09:09:35AM +0800, Shaohua Li wrote:
> > > > > >
> > > > > > [..]
> > > > > > > > You need to present raw numbers and give us some idea of how close
> > > > > > > > those numbers are to raw hardware capability for us to have any idea
> > > > > > > > what improvements these numbers actually demonstrate.
> > > > > > > Yes, your guess is right. The hardware has limitation. 12 SSD exceeds
> > > > > > > the jbod capability, for both throughput and IOPS, that's why only
> > > > > > > read/write mixed workload impacts. I'll use less SSD in later tests,
> > > > > > > which will demonstrate the performance better. I'll report both raw
> > > > > > > numbers and fiops/cfq numbers later.
> > > > > >
> > > > > > If fiops number are better please explain why those numbers are better.
> > > > > > If you cut down on idling, it is obivious that you will get higher
> > > > > > throughput on these flash devices. CFQ does disable queue idling for
> > > > > > non rotational NCQ devices. If higher throughput is due to driving
> > > > > > deeper queue depths, then CFQ can do that too just by changing quantum
> > > > > > and disabling idling.
> > > > > it's because of quantum. Surely you can change the quantum, and CFQ
> > > > > performance will increase, but you will find CFQ is very unfair then.
> > > >
> > > > Why increasing quantum leads to CFQ being unfair? In terms of time it
> > > > still tries to be fair.
> > > we can dispatch a lot of requests to NCQ SSD with very small time
> > > interval. The disk can finish a lot of requests in small time interval
> > > too. The time is much smaller than 1 jiffy. Increasing quantum can lead
> > > a task dispatches request more faster and makes the accounting worse,
> > > because with small quantum the task needs wait to dispatch. you can
> > > easily verify this with a simple fio test.
> > >
> > > > That's a different thing that with NCQ, right
> > > > time measurement is not possible with requests from multiple queues
> > > > being in the driver/disk at the same time. So accouting in terms of
> > > > iops per queue might make sense.
> > > yes.
> > >
> > > > > > So I really don't understand that what are you doing fundamentally
> > > > > > different in FIOPS ioscheduler.
> > > > > >
> > > > > > The only thing I can think of more accurate accounting per queue in
> > > > > > terms of number of IOs instead of time. Which can just serve to improve
> > > > > > fairness a bit for certain workloads. In practice, I think it might
> > > > > > not matter much.
> > > > > If quantum is big, CFQ will have better performance, but it actually
> > > > > fallbacks to Noop, no any fairness. fairness is important and is why we
> > > > > introduce CFQ.
> > > >
> > > > It is not exactly noop. It still preempts writes and prioritizes reads
> > > > and direct writes.
> > > sure, I mean fairness mostly here.
> > >
> > > > Also, what's the real life workload where you face issues with using
> > > > say deadline with these flash based storage.
> > > deadline doesn't provide fairness. mainly cgroup workload. workload with
> > > different ioprio has issues too, but I don't know which real workload
> > > uses ioprio.
> >
> > Personally I have not run into any workload which provides deep queue depths
> > constantly for a very long time. I had to run fio to create such
> > scnearios.
> >
> > Not running deep queue depths will lead to expiration of queue (Otherwise
> > idling will kill performance on these fast devices). And without idling
> > most of the logic of slice and accounting does not help. A queue
> > dispatches some requests and expires (irrespective of what time slice
> > you had allocated it based on ioprio).
> That's true, if workload doesn't drive deep queue depths, any accounting
> can't help for NCQ disks as far as I tried. Idling is the only method to
> make accounting correct, but it impacts performance too much.
Idiling will kill performance and faster the device, more prominent are
the effects of idling. So to me using CFQ on these fast devices is not
a very good idea and deadline might just serve well.
>
> > That's why I am insisting that it would be nice that any move in this
> > direction should be driven by some real workload instead of just coming
> > up with synthetic workloads.
> I thought yanhai from taobao (cc-ed) has real workload and he found cfq
> performance suffers a lot.
Can we run that real workload with "deadline" and see what kind of
concerns do we have. Is anybody getting starved for long time. If not,
then we don't have to do anything.
I think trying to make to make CFQ work (Or trying to come up with CFQ
like IOPS scheduler) on these fast devices might not lead us anywhere.
Thanks
Vivek
^ permalink raw reply
* Re: [PATCH 1/2] gpio-pch: cleanup __iomem annotation usage
From: Linus Walleij @ 2012-01-17 9:01 UTC (permalink / raw)
To: Németh Márton; +Cc: Grant Likely, Linus Walleij, LKML
In-Reply-To: <4F153221.3080509@freemail.hu>
2012/1/17 Németh Márton <nm127@freemail.hu>:
> Hi Linux,
:-)
Common mistake, as are our brother Kubys who also
appear on the lists sometimes...
> You are right, the correct one should be "void __iomem *im_reg;" .
>
> Should I resend a patch for this?
Yep just send it with subject [PATCH 1/2 v2] atleast
that's what I usually do.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] ACPI: kernel-parameters.txt : Add intel_idle.max_cstate
From: Len Brown @ 2012-01-17 9:00 UTC (permalink / raw)
To: Masanari Iida; +Cc: Thomas Renninger, linux-kernel, linux-acpi, rdunlap
In-Reply-To: <CALLJCT3hwYhCzrqbfeXG-C4t+PTG8fu_uJP=+S3H=tt4yX+D9w@mail.gmail.com>
you're both right.
document reality now,
make reality better later.
applied.
thanks,
-Len
^ permalink raw reply
* [PATCH] [media] s5p-fimc: Remove linux/version.h include from fimc-mdevice.c
From: Sachin Kamat @ 2012-01-17 8:55 UTC (permalink / raw)
To: linux-media; +Cc: mchehab, s.nawrocki, kyungmin.park, sachin.kamat, patches
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/media/video/s5p-fimc/fimc-mdevice.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-mdevice.c b/drivers/media/video/s5p-fimc/fimc-mdevice.c
index 615c862..8ea4ee1 100644
--- a/drivers/media/video/s5p-fimc/fimc-mdevice.c
+++ b/drivers/media/video/s5p-fimc/fimc-mdevice.c
@@ -21,7 +21,6 @@
#include <linux/pm_runtime.h>
#include <linux/types.h>
#include <linux/slab.h>
-#include <linux/version.h>
#include <media/v4l2-ctrls.h>
#include <media/media-device.h>
--
1.7.4.1
^ permalink raw reply related
* Re: V4L/DVB (12892): DVB-API: add support for ISDB-T and ISDB-Tsb (version 5.1)
From: Patrick Boettcher @ 2012-01-17 8:58 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linux-media
In-Reply-To: <20120113123757.GA21686@elgon.mountain>
On Friday 13 January 2012 13:37:57 Dan Carpenter wrote:
> Hello Patrick Boettcher,
>
> I know this patch is really old but I was hoping you still might be
> able to take a look at it.
>
> The patch b6e760f30975: "V4L/DVB (12892): DVB-API: add support for
> ISDB-T and ISDB-Tsb (version 5.1)" from Aug 3, 2009, leads to the
> following warning:
> drivers/media/dvb/dvb-core/dvb_frontend.c:993:9: warning: Initializer
> entry defined twice
> drivers/media/dvb/dvb-core/dvb_frontend.c:1012:9: also defined
> here
How does this thing has lived such a long time without being noticed by
anyone? Very strange.
Of course this is wrong and it should be fixed by removing the second
section. IOW, we should keep the section with the 1s.
> drivers/media/dvb/dvb-core/dvb_frontend.c
>
> + _DTV_CMD(DTV_ISDBT_PARTIAL_RECEPTION, 1, 0),
> + _DTV_CMD(DTV_ISDBT_SOUND_BROADCASTING, 1, 0),
> + _DTV_CMD(DTV_ISDBT_SB_SUBCHANNEL_ID, 1, 0),
> + _DTV_CMD(DTV_ISDBT_SB_SEGMENT_IDX, 1, 0),
> + _DTV_CMD(DTV_ISDBT_SB_SEGMENT_COUNT, 1, 0),
> + _DTV_CMD(DTV_ISDBT_LAYERA_FEC, 1, 0),
> + _DTV_CMD(DTV_ISDBT_LAYERA_MODULATION, 1, 0),
> + _DTV_CMD(DTV_ISDBT_LAYERA_SEGMENT_COUNT, 1, 0),
> + _DTV_CMD(DTV_ISDBT_LAYERA_TIME_INTERLEAVING, 1, 0),
> + _DTV_CMD(DTV_ISDBT_LAYERB_FEC, 1, 0),
> + _DTV_CMD(DTV_ISDBT_LAYERB_MODULATION, 1, 0),
> + _DTV_CMD(DTV_ISDBT_LAYERB_SEGMENT_COUNT, 1, 0),
> + _DTV_CMD(DTV_ISDBT_LAYERB_TIME_INTERLEAVING, 1, 0),
> + _DTV_CMD(DTV_ISDBT_LAYERC_FEC, 1, 0),
> + _DTV_CMD(DTV_ISDBT_LAYERC_MODULATION, 1, 0),
> + _DTV_CMD(DTV_ISDBT_LAYERC_SEGMENT_COUNT, 1, 0),
> + _DTV_CMD(DTV_ISDBT_LAYERC_TIME_INTERLEAVING, 1, 0),
I prepared a patch for this in my repo. I will send a pull-request right
away.
Thanks for pointing this out.
regards,
--
Patrick.
^ permalink raw reply
* Re: Reboot hangs on VersaLogic Ocelot
From: Ingo Molnar @ 2012-01-17 8:57 UTC (permalink / raw)
To: Matthew Garrett
Cc: Michael D Labriola, H. Peter Anvin, Kushal Koolwal, linux-kernel,
michael.d.labriola, support, Thomas Gleixner, x86
In-Reply-To: <20120116212938.GB6313@srcf.ucam.org>
* Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Mon, Jan 16, 2012 at 12:20:45PM -0500, Michael D Labriola wrote:
> > Actually, assuming we fix the bios= argument ignored by DMI
> > scan problem, would it be better to change the VersaLogic
> > quirk to acpi even though it's not necessary right now? If
> > the default reboot method ever switches from acpi to kbd or
> > bios, these boards will hang on reboot again...
>
> A lot of hardware relies on the acpi method being used. I
> don't see us changing the default for x86 when booted via
> BIOS.
Yeah, i don't think we'll ever again switch away from ACPI being
the default for currently existing hardware.
(Far-)future hardware might have different defaults, but that
won't affect hardware that exists today.
Thanks,
Ingo
^ permalink raw reply
* shutdown/migration stop working on paravirt domU
From: Vasiliy Tolstov @ 2012-01-17 8:58 UTC (permalink / raw)
To: xen-devel
Hello. Today i'm try to research, why most of our vm (pvm) not
shutdown correctly (we use shutdown with timeout, then it arrives we
destroy vm), and write simple test case to check that domU watches
works correctly:
xenstore write /local/domain/DOMID/control/shutdown testflag;
xenstore read /local/domain/DOMID/control/shutdown
If userspace watches works correctly - xenstore read returns empty,
becouse domU kernel respond only to known actions and printk and clean
path on unknown actions.
I can't see difference in various kernel versions
(centos/opensuse/debian and other), we use oxenstored old version
(that shipped with 4.0.1_21326_06-0.4.1 on sles)
How can i debug this issue and get more info on this problem?
P.S. Some domains, that has small uptime respond to my check and
shutdown/migrate correctly.
--
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru
^ permalink raw reply
* SOLDES : vos chaussures jusqu'à moins 60%
From: Spartoo.com @ 2012-01-17 8:57 UTC (permalink / raw)
To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
SOLDES jusqu'à -60% ! Toute la mode à vos pieds
Si ce message ne s'affiche pas correctement, visualisez la version en ligne.
Spartoo.com
SOLDES
Cliquez ici Jusqu'* -60% Cliquez ici
Plus de 400 marques & 15 000 mod*les
Kickers - Converse - Timberland - Geox - Palladium - Pataugas - Dr.
Martens - Bensimon - Asics - Feiyue - Nike - Victoria - Adidas - Clarks
- Le Coq Sportif
Livraison gratuite en 5 jours garantis + Retour gratuit jusqu'* 30
jours
Pour ne plus recevoir de courriels de notre part, il vous suffit de vous rendre
sur cette page.
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
^ permalink raw reply
* [PATCH] [media] s5p-mfc: Remove linux/version.h include from s5p_mfc.c
From: Sachin Kamat @ 2012-01-17 8:52 UTC (permalink / raw)
To: linux-media
Cc: chehab, k.debski, kyungmin.park, jtp.park, sachin.kamat, patches
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/media/video/s5p-mfc/s5p_mfc.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc.c b/drivers/media/video/s5p-mfc/s5p_mfc.c
index e43e128..ec7f000 100644
--- a/drivers/media/video/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/video/s5p-mfc/s5p_mfc.c
@@ -18,7 +18,6 @@
#include <linux/platform_device.h>
#include <linux/sched.h>
#include <linux/slab.h>
-#include <linux/version.h>
#include <linux/videodev2.h>
#include <linux/workqueue.h>
#include <media/videobuf2-core.h>
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 1/2] ASoC: Allow drivers to specify how many bits are significant on a DAI
From: Peter Ujfalusi @ 2012-01-17 8:56 UTC (permalink / raw)
To: Mark Brown; +Cc: alsa-devel, patches, Girdwood, Liam
In-Reply-To: <20120116224238.GA2859@opensource.wolfsonmicro.com>
On 01/16/2012 11:42 PM, Mark Brown wrote:
> On Mon, Jan 16, 2012 at 10:26:11PM +0000, Girdwood, Liam wrote:
>
>> Btw, will you be reworking Peter's patch ?
>
> Probably if he doesn't get around to it, though I figured that the patch
> is so tiny it's probably going to be less work to just write it when
> testing rather than to apply a patch from mail so it'd be easier for him
> to let him do it.
I'll update the drivers (cpu dais, and codecs I know have this feature).
--
Péter
^ permalink raw reply
* Re: Updated btrfs/crypto snappy interface ready for merging
From: Li Zefan @ 2012-01-17 8:56 UTC (permalink / raw)
To: Andi Kleen; +Cc: Chris Mason, linux-kernel, linux-btrfs
In-Reply-To: <20120117084650.GP11715@one.firstfloor.org>
Andi Kleen wrote:
>> It's because decompressing inline extents always fails. I've fixed it
>> and will send the patch out in a new mail thread.
>
> Thanks for fixing.
>
>>
>> But seems there's bug in lib snappy code, which makes the decompressed
>> data doesn't quite match the original data.
>>
>> Simply copy a file to a btrfs filesystem with snappy enabled, and clear
>> page cache, and check the file:
>
> Hmm weird, I have never seen this. Do you have a reproducer?
>
Just use some randomly chosen text files. For example:
# mount -t btrfs -o compress=snappy /dev/xxx /mnt
# cp -r btrfs-progs-unstable/ /mnt
# sync
# echo 3 > /proc/sys/vm/drop_caches
# diff -Nurp btrfs-progs-unstable /mnt/btrfs-progs-unstable
I've tested on both x86_32 and x86_64.
> The basic compression code is quite well tested, I have a reasonable
> unit test.
>
^ permalink raw reply
* Re: [PATCH 1/2] ASoC: Allow drivers to specify how many bits are significant on a DAI
From: Peter Ujfalusi @ 2012-01-17 8:55 UTC (permalink / raw)
To: Mark Brown; +Cc: alsa-devel, patches, Liam Girdwood
In-Reply-To: <1326739267-9678-1-git-send-email-broonie@opensource.wolfsonmicro.com>
On 01/16/2012 07:41 PM, Mark Brown wrote:
> /*
> + * List of sample sizes that might go over the bus for parameter
> + * application. There ought to be a wildcard sample size for things
> + * like the DAC/ADC resolution to use but there isn't right now.
> + */
> +static int sample_sizes[] = {
> + 8, 16, 24, 32,
> +};
> +
> +static void soc_pcm_apply_msb(struct snd_pcm_substream *substream,
> + struct snd_soc_dai *dai)
> +{
> + int ret, i, bits;
> +
> + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
> + bits = dai->driver->playback.sig_bits;
> + else
> + bits = dai->driver->capture.sig_bits;
> +
> + if (!bits)
> + return;
> +
> + for (i = 0; i < ARRAY_SIZE(sample_sizes); i++) {
> + ret = snd_pcm_hw_constraint_msbits(substream->runtime,
> + 0, sample_sizes[i],
> + bits);
Should we apply the constraint only if the sample size is bigger than
the msbit request:
if (sample_sizes[i] > bits) {
ret = snd_pcm_hw_constraint_msbits();
}
Might be not an issue to say that we have 24msbit on the 8bit sample,
but it does not sound right.
> + if (ret != 0)
> + dev_warn(dai->dev,
> + "Failed to set MSB %d/%d: %d\n",
> + bits, sample_sizes[i], ret);
> + }
> +}
> +
> +/*
> * Called by ALSA when a PCM substream is opened, the runtime->hw record is
> * then initialized and any private data can be allocated. This also calls
> * startup for the cpu DAI, platform, machine and codec DAI.
> @@ -187,6 +220,9 @@ static int soc_pcm_open(struct snd_pcm_substream *substream)
> goto config_err;
> }
>
> + soc_pcm_apply_msb(substream, codec_dai);
> + soc_pcm_apply_msb(substream, cpu_dai);
> +
> /* Symmetry only applies if we've already got an active stream. */
> if (cpu_dai->active) {
> ret = soc_pcm_apply_symmetry(substream, cpu_dai);
--
Péter
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.