* Re: xennet: skb rides the rocket: 20 slots
From: Ian Campbell @ 2013-01-10 12:26 UTC (permalink / raw)
To: ANNIE LI; +Cc: Sander Eikelenboom, xen-devel, Konrad Rzeszutek Wilk
In-Reply-To: <50EEA46E.7000604@oracle.com>
On Thu, 2013-01-10 at 11:22 +0000, ANNIE LI wrote:
> I am thinking to do re-fragment in netfront for these skbs like following,
>
> Create a new skb, copy linear data and frag data from original skb into
> this one, and make every frags data size is PAGE_SIZE except for the
> last fragment. It is possible that the last fragment length is less than
> PAGE_SIZE, then free the original skb. The skb packet is large, and
> there will be lots of copys.
You don't need (or I suspect want) to copy, you can directly add pages
from the source skb's frags to the destination skb's frags, with
appropriate refcount frobbing. You can also share a page between two (or
more) skbs in the case where the boundary between two skbs happens to be
in the middle of a page.
But more importantly than all that you need to do more than just
refragment, you actually need to resegment i.e. you need to duplicate
the headers (Ethernet, IP, TCP) at the front of each new skb and adjust
the (psuedo-)checksums as appropriate (which will depend on whether the
SKB is GSO, or just has checksum offload or nothing).
So you need to go from
<Ether><IP><TCP><...data... ...data...>
to
<Ether><IP><TCP><...data...> <Ether><IP><TCP><...data...>
Where the headers are adjusted to cope with this. Some of data might be
in frags but equally some might be in skb->data.
I'm guessing that Linux already has code which can do this for you,
since it has a software fallback for GSO.
Ian.
>
> struct skbuff *xennet_refrag_skb(skb)
> {
> create newskb
> copying data and doing fragmentation
> return newskb
> }
>
> .......
>
> if (unlikely(slots> MAX_SKB_FRAGS + 1)) {
> net_alert_ratelimited(
> "xennet: skb rides the rocket: %d slots\n", slots);
> skb = xennet_refrag_skb(skb);
> }
> .....
>
> Thanks
> Annie
> >
> >> "netchannel vs MAX_SKB_FRAGS". Maybe these two mechanism are all
> >> necessary?
> > Lets see first if this is indeed the problem. Perhaps a simple debug
> > patch that just does:
> >
> > s/MAX_SKB_FRAGS/DEBUG_MAX_FRAGS/
> > #define DEBUG_MAX_FRAGS 21
> >
> > in both netback and netfront to set the maximum number of frags we can
> > handle to 21? If that works with Sander test - then yes, it looks like
> > we really need to get this 'feature-max-skb-frags' done.
> >
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] block: init bs->io_base correctly to avoid locking
From: Peter Lieven @ 2013-01-10 12:26 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: kwolf, Markus Armbruster, qemu-devel@nongnu.org
In-Reply-To: <50EEB0FB.80909@redhat.com>
Am 10.01.2013 um 13:15 schrieb Paolo Bonzini <pbonzini@redhat.com>:
> Il 10/01/2013 13:12, Peter Lieven ha scritto:
>>>>
>>>> But perhaps we do not need to start a slice at all when iolimits are
>>>> set. That is, do
>>>>
>>>> bs->slice_start = bs->slice_end = bs->slice_time = 0;
>>>>
>>>> or perhaps even nothing at all since bdrv_io_limits_disable should have
>>>> written those exact values.
>> Or it was set when the BlockDriverState was initialized.
>>
>> I am not familiar enough with the io limits code to decide if not starting a slice
>> is also correct.
>
> I haven't tested it, but if it works, I think it is better.
i will test and report.
Peter
>
> Think of it this way: it doesn't matter whether the first I/O operation
> comes immediately after limits are set, or 10 seconds later. In the
> latter case, bdrv_exceed_io_limits will _already_ start a new slice. It
> is better to be consistent and always delay the start of the slice.
>
> Paolo
^ permalink raw reply
* Re: [PATCH v2 repost] sched: cputime: avoid multiplication overflow (in common cases)
From: Stanislaw Gruszka @ 2013-01-10 12:26 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Peter Zijlstra, Ingo Molnar, linux-kernel, Oleg Nesterov, akpm,
Steven Rostedt
In-Reply-To: <20130109183248.GA8293@somewhere.redhat.com>
On Wed, Jan 09, 2013 at 07:33:03PM +0100, Frederic Weisbecker wrote:
> On Mon, Jan 07, 2013 at 12:31:45PM +0100, Stanislaw Gruszka wrote:
> > We scale stime, utime values based on rtime (sum_exec_runtime converted
> > to jiffies). During scaling we multiple rtime * utime, what seems to be
> > fine, since both values are converted to u64, but is not.
> >
> > Let assume HZ is 1000 - 1ms tick. Process consist of 64 threads, run
> > for 1 day, threads utilize 100% cpu on user space. Machine has 64 cpus.
> >
> > Process rtime = utime will be 64 * 24 * 60 * 60 * 1000 jiffies, what is
> > 0x149970000. Multiplication rtime * utime result is 0x1a855771100000000,
> > which can not be covered in 64 bits.
> >
> > Result of overflow is stall of utime values visible in user space
> > (prev_utime in kernel), even if application still consume lot of CPU
> > time.
> >
> > Probably good fix for the problem, will be using 128 bit variable and
> > proper mul128 and div_u128_u64 primitives. While mul128 is on it's
> > way to kernel, there is no 128 bit division yet. I'm not sure, if we
> > want to add it to kernel. Perhaps we could also change the way how
> > stime and utime are calculated, but I don't know how, so I come with
> > the below solution for the problem.
> >
> > To avoid overflow patch change value we scale to min(stime, utime). This
> > is more like workaround, but will work for processes, which perform
> > mostly on user space or mostly on kernel space. Unfortunately processes,
> > which perform on kernel and user space equally, and additionally utilize
> > lot of CPU time, still will hit this overflow pretty quickly. However
> > such processes seems to be uncommon.
> >
> > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
>
> I can easily imagine that overflow to happen with user time on intensive
> CPU bound loads, or may be guests.
>
> But can we easily reach the same for system time? Even on intensive I/O bound
> loads we shouldn't spend that much time in the kernel. Most of it probably goes
> to idle.
>
> What do you think?
I think you are right :-)
> If that assumption is right in most cases, the following patch should solve the
> issue:
I'm fine with this patch, it achives the same effect as my patch, but is simpler.
Thanks
Stanislaw
> diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
> index 293b202..0650dd4 100644
> --- a/kernel/sched/cputime.c
> +++ b/kernel/sched/cputime.c
> @@ -509,11 +509,11 @@ EXPORT_SYMBOL_GPL(vtime_account);
> # define nsecs_to_cputime(__nsecs) nsecs_to_jiffies(__nsecs)
> #endif
>
> -static cputime_t scale_utime(cputime_t utime, cputime_t rtime, cputime_t total)
> +static cputime_t scale_utime(cputime_t stime, cputime_t rtime, cputime_t total)
> {
> u64 temp = (__force u64) rtime;
>
> - temp *= (__force u64) utime;
> + temp *= (__force u64) stime;
>
> if (sizeof(cputime_t) == 4)
> temp = div_u64(temp, (__force u32) total);
> @@ -531,10 +531,10 @@ static void cputime_adjust(struct task_cputime *curr,
> struct cputime *prev,
> cputime_t *ut, cputime_t *st)
> {
> - cputime_t rtime, utime, total;
> + cputime_t rtime, stime, total;
>
> - utime = curr->utime;
> - total = utime + curr->stime;
> + stime = curr->stime;
> + total = stime + curr->utime;
>
> /*
> * Tick based cputime accounting depend on random scheduling
> @@ -549,17 +549,17 @@ static void cputime_adjust(struct task_cputime *curr,
> rtime = nsecs_to_cputime(curr->sum_exec_runtime);
>
> if (total)
> - utime = scale_utime(utime, rtime, total);
> + stime = scale_stime(stime, rtime, total);
> else
> - utime = rtime;
> + stime = rtime;
>
> /*
> * If the tick based count grows faster than the scheduler one,
> * the result of the scaling may go backward.
> * Let's enforce monotonicity.
> */
> - prev->utime = max(prev->utime, utime);
> - prev->stime = max(prev->stime, rtime - prev->utime);
> + prev->stime = max(prev->stime, stime);
> + prev->utime = max(prev->utime, rtime - prev->stime);
>
> *ut = prev->utime;
> *st = prev->stime;
^ permalink raw reply
* Re: [Qemu-devel] [RFC] updated e1000 mitigation patch
From: Stefan Hajnoczi @ 2013-01-10 12:25 UTC (permalink / raw)
To: Luigi Rizzo; +Cc: Giuseppe Lettieri, qemu-devel, v.maffione
In-Reply-To: <20121227100658.GB48891@onelab2.iet.unipi.it>
On Thu, Dec 27, 2012 at 11:06:58AM +0100, Luigi Rizzo wrote:
> diff -urp qemu-1.3.0-orig/hw/e1000.c qemu-1.3.0/hw/e1000.c
> --- qemu-1.3.0-orig/hw/e1000.c 2012-12-03 20:37:05.000000000 +0100
> +++ qemu-1.3.0/hw/e1000.c 2012-12-27 09:47:16.000000000 +0100
> @@ -35,6 +35,8 @@
>
> #include "e1000_hw.h"
>
> +static int mit_on = 1; /* interrupt mitigation enable */
If you want to make this optional then please put it inside E1000State
so it can be toggled per NIC.
If you don't want to make it optional then please post results for
recent Linux and Windows guests to show that out-of-the-box performance
is not degraded.
> #define E1000_DEBUG
>
> #ifdef E1000_DEBUG
> @@ -129,6 +131,9 @@ typedef struct E1000State_st {
> } eecd_state;
>
> QEMUTimer *autoneg_timer;
> + QEMUTimer *mit_timer; // handle for the timer
> + uint32_t mit_timer_on; // mitigation timer active
> + uint32_t mit_cause; // pending interrupt cause
Live migration support is required so that pending interrupts are
migrated. We cannot lose interrupts across live migration.
I would migrate mit_cause but not mit_timer_on. When loading (resuming
from live migration), look at mit_cause and raise any interrupts.
Stefan
^ permalink raw reply
* Re: Fix phy_init for Marvell network eth driver
From: Andrew Lunn @ 2013-01-10 12:24 UTC (permalink / raw)
To: Kosta Zertsekel
Cc: netdev, zertsekel, andrew, benavi, linux-arm-kernel, alior
In-Reply-To: <1357819234-27752-1-git-send-email-konszert@marvell.com>
On Thu, Jan 10, 2013 at 02:00:32PM +0200, Kosta Zertsekel wrote:
> Hi all,
> resubmitting the patch for Marvell mv643xx driver (patch 1/2) adding the below explanation (thanks to Florian F.):
> The D-Link DNS323_REV_C1 board has a specific PHY device fixup using the flag MARVELL_PHY_M1118_DNS323_LEDS which is set by the architecture code in arch/arm/mach-orion5x/dns323-setup.c. This flag is unfortunately lost during the call to phy_attach() in mv643xx_eth and therefore, the underlying Marvell PHY driver cannot make use of this flag to fixup the PHY device LEDs. This patch ensures the phy->dev_flags value is passed to the phy_attach() function such that the PHY device driver can
> actually use it.
>
> Also submitting new patch 2/2 using the same (or at least very close in meaning) explanation.
>
Hi Kosta
This comment is supposed to be in the header of the patch.
Since this comment is about a bug for the D-Link DNS323_REV_C1, the
fix to DSA should be in a separate patch, again with a comment about
the patch, why its needed, what if fixes etc.
I suggest you take a look at Documentation/SubmittingPatches
Thanks
Andrew
^ permalink raw reply
* Re: xennet: skb rides the rocket: 20 slots
From: Sander Eikelenboom @ 2013-01-10 12:24 UTC (permalink / raw)
To: ANNIE LI; +Cc: xen-devel, Ian Campbell, Konrad Rzeszutek Wilk
In-Reply-To: <50EEA46E.7000604@oracle.com>
Thursday, January 10, 2013, 12:22:22 PM, you wrote:
> On 2013-1-9 23:08, Konrad Rzeszutek Wilk wrote:
>> On Wed, Jan 09, 2013 at 03:10:56PM +0800, ANNIE LI wrote:
>>>
>>> On 2013-1-9 4:55, Sander Eikelenboom wrote:
>>>>> if (unlikely(frags>= MAX_SKB_FRAGS)) {
>>>>> netdev_dbg(vif->dev, "Too many frags\n");
>>>>> return -frags;
>>>>> }
>>>> I have added some rate limited warns in this function. However none seems to be triggered while the pv-guest reports the "skb rides the rocket" ..
>>> Oh, yes, "skb rides the rocket" is a protect mechanism in netfront,
>>> and it is not caused by netback checking code, but they all concern
>>> about the same thing(frags>= MAX_SKB_FRAGS ). I thought those
>>> packets were dropped by backend check, sorry for the confusion.
>>>
>>> In netfront, following code would check whether required slots
>>> exceed MAX_SKB_FRAGS, and drop skbs which does not meet this
>>> requirement directly.
>>>
>>> if (unlikely(slots> MAX_SKB_FRAGS + 1)) {
>>> net_alert_ratelimited(
>>> "xennet: skb rides the rocket: %d slots\n", slots);
>>> goto drop;
>>> }
>>>
>>> In netback, following code also compared frags with MAX_SKB_FRAGS,
>>> and create error response for netfront which does not meet this
>>> requirment. In this case, netfront will also drop corresponding
>>> skbs.
>>>
>>> if (unlikely(frags>= MAX_SKB_FRAGS)) {
>>> netdev_dbg(vif->dev, "Too many frags\n");
>>> return -frags;
>>> }
>>>
>>> So it is correct that netback log was not print out because those
>>> packets are drops directly by frontend check, not by backend check.
>>> Without the frontend check, it is likely that netback check would
>>> block these skbs and create error response for netfront.
>>>
>>> So two ways are available: workaround in netfront for those packets,
>>> doing re-fragment copying, but not sure how copying hurt
>>> performance. Another is to implement in netback, as discussed in
>> There is already some copying done (the copying of the socket data
>> from userspace to the kernel) - so the extra copy might not be that
>> bad as the data can be in the cache. This would probably be a way
>> to deal with old backends that cannot deal with this new feature-flag.
> I am thinking to do re-fragment in netfront for these skbs like following,
> Create a new skb, copy linear data and frag data from original skb into
> this one, and make every frags data size is PAGE_SIZE except for the
> last fragment. It is possible that the last fragment length is less than
> PAGE_SIZE, then free the original skb. The skb packet is large, and
> there will be lots of copys.
> struct skbuff *xennet_refrag_skb(skb)
> {
> create newskb
> copying data and doing fragmentation
> return newskb
> }
> .......
if (unlikely(slots>> MAX_SKB_FRAGS + 1)) {
> net_alert_ratelimited(
> "xennet: skb rides the rocket: %d slots\n", slots);
> skb = xennet_refrag_skb(skb);
> }
> .....
> Thanks
> Annie
>>
>>> "netchannel vs MAX_SKB_FRAGS". Maybe these two mechanism are all
>>> necessary?
>> Lets see first if this is indeed the problem. Perhaps a simple debug
>> patch that just does:
>>
>> s/MAX_SKB_FRAGS/DEBUG_MAX_FRAGS/
>> #define DEBUG_MAX_FRAGS 21
>>
>> in both netback and netfront to set the maximum number of frags we can
>> handle to 21? If that works with Sander test - then yes, it looks like
>> we really need to get this 'feature-max-skb-frags' done.
>>
What i'm wondering about (without any knowledge about the innerworkings of the network stack):
- Why can't netfront handle the largers packets in the first place ?
- Would it be right to do something like xennet_get_responses() does for rx:
int max = MAX_SKB_FRAGS + (rx->status <= RX_COPY_THRESHOLD);
if (unlikely(frags > max)) {
net_warn_ratelimited("%s: Too many frags max:%d, frags:%d \n",skb->dev->name, max, frags);
err = -E2BIG;
}
Instead of dropping the packet ?
Don't know if this propagates via network protocols and will cause clients to reduce the packetsize and by that way avoid the need to copying in the first place ?
--
Sander
^ permalink raw reply
* Fix phy_init for Marvell network eth driver
From: Andrew Lunn @ 2013-01-10 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357819234-27752-1-git-send-email-konszert@marvell.com>
On Thu, Jan 10, 2013 at 02:00:32PM +0200, Kosta Zertsekel wrote:
> Hi all,
> resubmitting the patch for Marvell mv643xx driver (patch 1/2) adding the below explanation (thanks to Florian F.):
> The D-Link DNS323_REV_C1 board has a specific PHY device fixup using the flag MARVELL_PHY_M1118_DNS323_LEDS which is set by the architecture code in arch/arm/mach-orion5x/dns323-setup.c. This flag is unfortunately lost during the call to phy_attach() in mv643xx_eth and therefore, the underlying Marvell PHY driver cannot make use of this flag to fixup the PHY device LEDs. This patch ensures the phy->dev_flags value is passed to the phy_attach() function such that the PHY device driver can
> actually use it.
>
> Also submitting new patch 2/2 using the same (or at least very close in meaning) explanation.
>
Hi Kosta
This comment is supposed to be in the header of the patch.
Since this comment is about a bug for the D-Link DNS323_REV_C1, the
fix to DSA should be in a separate patch, again with a comment about
the patch, why its needed, what if fixes etc.
I suggest you take a look at Documentation/SubmittingPatches
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH V3 0/3] ARM: davinci: da850: add pinctrl support
From: Sekhar Nori @ 2013-01-10 12:23 UTC (permalink / raw)
To: Kumar, Anil
Cc: linux-arm-kernel, linux-kernel, davinci-linux-open-source, linux,
Kevin Hilman, hs
In-Reply-To: <1357813838-26511-1-git-send-email-anilkumar.v@ti.com>
On 1/10/2013 4:00 PM, Kumar, Anil wrote:
> This set of patches adds:
>
> * Add pinctrl-single for handling Padconf registers.
> * Add NAND node to export NAND functionality on da850 EVM.
> * Add NAND pinctrl node to do pin mux according to pinctrl-single driver.
Please do not spin versions so fast. Give some reasonable time for
discussion to close before you send a new version. Dont want to see a
flood of versions. It creates confusion.
Thanks,
Sekhar
PS: New address of Kevin Hilman per MAINTAINERS is
khilman@deeprootsystems.com
^ permalink raw reply
* RE: [PATCH v9 2/3] x86, apicv: add virtual x2apic support
From: Zhang, Yang Z @ 2013-01-10 12:22 UTC (permalink / raw)
To: Gleb Natapov
Cc: kvm@vger.kernel.org, Shan, Haitao, mtosatti@redhat.com,
Tian, Kevin
In-Reply-To: <20130110121627.GA11529@redhat.com>
Gleb Natapov wrote on 2013-01-10:
> On Thu, Jan 10, 2013 at 11:54:21AM +0000, Zhang, Yang Z wrote:
>>>> The right logic should be:
>>>> When register virtualization enabled, read all apic msr(except apic id reg and
>>> tmcct which have the hook) not cause vmexit and only write TPR not cause
>>> vmexit.
>>>> When vid enabled, write to TPR, EOI and SELF IPI not cause vmexit.
>>>> It's better to put the patch of envirtualize x2apic mode as first patch.
>>>>
>>> There is no point whatsoever to enable virtualize x2apic without
>>> allowing at least one non intercepted access to x2apic MSR range and
>>> this is what your patch is doing when run on cpu without vid capability.
>> No, at least read/write TPR will not cause vmexit if virtualize x2apic mode is
> enabled.
> For that you need to disable 808H MSR intercept, which your patch does not do.
I want to do this in next patch.
>> I am not sure whether I understand your comments right in previous
>> discussion, here is my thinking: 1. enable virtualize x2apic mode if
>> guest is really using x2apic and clear TPR in msr read and write
>> bitmap. This will benefit reading TPR. 2. If APIC registers
>> virtualization is enabled, clear all bit in rang
> 0x800-0x8ff(except apic id reg and tmcct).
> Clear all read bits in the range.
>
>> 3. If vid is enabled, clear EOI and SELF IPI in msr write map.
>>
> Looks OK.
>
>> One concern you mentioned is that vid enabled and virtualize x2apic is disabled
> but guest still use x2apic. In this case, we still use MSR bitmap to intercept x2apic.
> This means the vEOI update will never happen. But we still can benefit from
> interrupt window.
>>
> What interrupt windows? Without virtualized x2apic TPR/EOI
> virtualization will not happen and we rely on that in the code.
Yes, but we can eliminate vmexit of interrupt window. Interrupt still can delivery to guest without vmexit when guest enables interrupt if vid is enabled. See SDM vol 3, 29.2.2.
Best regards,
Yang
^ permalink raw reply
* [PATCH V3 0/3] ARM: davinci: da850: add pinctrl support
From: Sekhar Nori @ 2013-01-10 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357813838-26511-1-git-send-email-anilkumar.v@ti.com>
On 1/10/2013 4:00 PM, Kumar, Anil wrote:
> This set of patches adds:
>
> * Add pinctrl-single for handling Padconf registers.
> * Add NAND node to export NAND functionality on da850 EVM.
> * Add NAND pinctrl node to do pin mux according to pinctrl-single driver.
Please do not spin versions so fast. Give some reasonable time for
discussion to close before you send a new version. Dont want to see a
flood of versions. It creates confusion.
Thanks,
Sekhar
PS: New address of Kevin Hilman per MAINTAINERS is
khilman at deeprootsystems.com
^ permalink raw reply
* [PATCH 3/9] mfd: arizona: Register MICVDD supply first to ensure no retries
From: Mark Brown @ 2013-01-10 12:18 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: patches, linux-kernel, Mark Brown
In-Reply-To: <1357820332-14586-1-git-send-email-broonie@opensource.wolfsonmicro.com>
Not strictly required as probe deferral will take care of everything but
it makes boot a little smoother.
Reported-by: Ryo Tsutsui <Ryo.Tsutsui@wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
drivers/mfd/arizona-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index bc8a3ed..a8b8a7b 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -270,19 +270,19 @@ static struct mfd_cell early_devs[] = {
};
static struct mfd_cell wm5102_devs[] = {
+ { .name = "arizona-micsupp" },
{ .name = "arizona-extcon" },
{ .name = "arizona-gpio" },
{ .name = "arizona-haptics" },
- { .name = "arizona-micsupp" },
{ .name = "arizona-pwm" },
{ .name = "wm5102-codec" },
};
static struct mfd_cell wm5110_devs[] = {
+ { .name = "arizona-micsupp" },
{ .name = "arizona-extcon" },
{ .name = "arizona-gpio" },
{ .name = "arizona-haptics" },
- { .name = "arizona-micsupp" },
{ .name = "arizona-pwm" },
{ .name = "wm5110-codec" },
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH 4/9] mfd: arizona: Disable control interface reporting for WM5102 and WM5110
From: Mark Brown @ 2013-01-10 12:18 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: patches, linux-kernel, Mark Brown
In-Reply-To: <1357820332-14586-1-git-send-email-broonie@opensource.wolfsonmicro.com>
Rather than disabling the error reporting only for earlier revisions
unconditionally disable it.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
drivers/mfd/arizona-irq.c | 18 ++----------------
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/mfd/arizona-irq.c b/drivers/mfd/arizona-irq.c
index 74713bf..2bec5f0 100644
--- a/drivers/mfd/arizona-irq.c
+++ b/drivers/mfd/arizona-irq.c
@@ -176,14 +176,7 @@ int arizona_irq_init(struct arizona *arizona)
aod = &wm5102_aod;
irq = &wm5102_irq;
- switch (arizona->rev) {
- case 0:
- case 1:
- ctrlif_error = false;
- break;
- default:
- break;
- }
+ ctrlif_error = false;
break;
#endif
#ifdef CONFIG_MFD_WM5110
@@ -191,14 +184,7 @@ int arizona_irq_init(struct arizona *arizona)
aod = &wm5110_aod;
irq = &wm5110_irq;
- switch (arizona->rev) {
- case 0:
- case 1:
- ctrlif_error = false;
- break;
- default:
- break;
- }
+ ctrlif_error = false;
break;
#endif
default:
--
1.7.10.4
^ permalink raw reply related
* [PATCH] libxl: don't continue to create the domain if the device model is not spawned
From: Julien Grall @ 2013-01-10 12:21 UTC (permalink / raw)
To: xen-devel; +Cc: Julien Grall, ian.jackson
When the device model can't be spawned, rc variable is cleared in
device_model_spawn_outcome (libxl_dm.c).
In this case libxl will continue to create the domain and let it between life
and death.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
---
tools/libxl/libxl_dm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index c036dc1..51f9914 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1215,8 +1215,6 @@ static void device_model_spawn_outcome(libxl__egc *egc,
}
}
- rc = 0;
-
out:
dmss->callback(egc, dmss, rc);
}
--
Julien Grall
^ permalink raw reply related
* [PATCH 2/9] mfd: wm5102: Mark only extant DSP registers volatile
From: Mark Brown @ 2013-01-10 12:18 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: patches, linux-kernel, Mark Brown
In-Reply-To: <1357820332-14586-1-git-send-email-broonie@opensource.wolfsonmicro.com>
Since regmap sometimes uses volatile as a proxy for readable simply
having a blanket condition can mark too many registers as readable.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
drivers/mfd/wm5102-tables.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/wm5102-tables.c b/drivers/mfd/wm5102-tables.c
index 4a01192..0317d11 100644
--- a/drivers/mfd/wm5102-tables.c
+++ b/drivers/mfd/wm5102-tables.c
@@ -1837,9 +1837,6 @@ static bool wm5102_readable_register(struct device *dev, unsigned int reg)
static bool wm5102_volatile_register(struct device *dev, unsigned int reg)
{
- if (reg > 0xffff)
- return true;
-
switch (reg) {
case ARIZONA_SOFTWARE_RESET:
case ARIZONA_DEVICE_REVISION:
@@ -1884,7 +1881,13 @@ static bool wm5102_volatile_register(struct device *dev, unsigned int reg)
case ARIZONA_MIC_DETECT_3:
return true;
default:
- return false;
+ if ((reg >= 0x100000 && reg < 0x106000) ||
+ (reg >= 0x180000 && reg < 0x180800) ||
+ (reg >= 0x190000 && reg < 0x194800) ||
+ (reg >= 0x1a8000 && reg < 0x1a9800))
+ return true;
+ else
+ return false;
}
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 9/9] mfd: wm5102: Update rev B patch for latest evaluation
From: Mark Brown @ 2013-01-10 12:18 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: patches, linux-kernel, Mark Brown
In-Reply-To: <1357820332-14586-1-git-send-email-broonie@opensource.wolfsonmicro.com>
The latest evaluation of the revision B silicon suggests some changes to
the tuning applied for optimal performance.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
drivers/mfd/wm5102-tables.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/wm5102-tables.c b/drivers/mfd/wm5102-tables.c
index edee1da..a687901 100644
--- a/drivers/mfd/wm5102-tables.c
+++ b/drivers/mfd/wm5102-tables.c
@@ -59,12 +59,14 @@ static const struct reg_default wm5102_reva_patch[] = {
static const struct reg_default wm5102_revb_patch[] = {
{ 0x80, 0x0003 },
{ 0x081, 0xE022 },
- { 0x410, 0x6080 },
- { 0x418, 0x6080 },
- { 0x420, 0x6080 },
+ { 0x410, 0x4080 },
+ { 0x418, 0x4080 },
+ { 0x420, 0x4080 },
{ 0x428, 0xC000 },
- { 0x441, 0x8014 },
+ { 0x4B0, 0x0066 },
{ 0x458, 0x000b },
+ { 0x212, 0x0000 },
+ { 0x171, 0x0000 },
{ 0x80, 0x0000 },
};
@@ -274,7 +276,7 @@ static const struct reg_default wm5102_reg_default[] = {
{ 0x00000155, 0x0000 }, /* R341 - Rate Estimator 4 */
{ 0x00000156, 0x0000 }, /* R342 - Rate Estimator 5 */
{ 0x00000161, 0x0000 }, /* R353 - Dynamic Frequency Scaling 1 */
- { 0x00000171, 0x0002 }, /* R369 - FLL1 Control 1 */
+ { 0x00000171, 0x0000 }, /* R369 - FLL1 Control 1 */
{ 0x00000172, 0x0008 }, /* R370 - FLL1 Control 2 */
{ 0x00000173, 0x0018 }, /* R371 - FLL1 Control 3 */
{ 0x00000174, 0x007D }, /* R372 - FLL1 Control 4 */
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] ASoC: ak4642: add Device Tree support
From: Mark Brown @ 2013-01-10 12:20 UTC (permalink / raw)
To: Kuninori Morimoto; +Cc: Linux-ALSA, Simon, Liam Girdwood, Kuninori Morimoto
In-Reply-To: <871udt4f1n.wl%kuninori.morimoto.gx@renesas.com>
[-- Attachment #1.1: Type: text/plain, Size: 147 bytes --]
On Thu, Jan 10, 2013 at 12:29:11AM -0800, Kuninori Morimoto wrote:
> Support for loading the ak4642 codec module via devicetree.
Applied, thanks.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [PATCH 8/9] mfd: wm5102: Refresh register defaults
From: Mark Brown @ 2013-01-10 12:18 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: patches, linux-kernel, Mark Brown
In-Reply-To: <1357820332-14586-1-git-send-email-broonie@opensource.wolfsonmicro.com>
The WM5102 register defaults are not up to date with the current register
map, synchronise them with those for current devices.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
drivers/mfd/wm5102-tables.c | 95 +++++++++++++++----------------------------
1 file changed, 33 insertions(+), 62 deletions(-)
diff --git a/drivers/mfd/wm5102-tables.c b/drivers/mfd/wm5102-tables.c
index 167e6c4..edee1da 100644
--- a/drivers/mfd/wm5102-tables.c
+++ b/drivers/mfd/wm5102-tables.c
@@ -224,11 +224,9 @@ const struct regmap_irq_chip wm5102_irq = {
static const struct reg_default wm5102_reg_default[] = {
{ 0x00000008, 0x0019 }, /* R8 - Ctrl IF SPI CFG 1 */
{ 0x00000009, 0x0001 }, /* R9 - Ctrl IF I2C1 CFG 1 */
- { 0x0000000D, 0x0000 }, /* R13 - Ctrl IF Status 1 */
{ 0x00000016, 0x0000 }, /* R22 - Write Sequencer Ctrl 0 */
{ 0x00000017, 0x0000 }, /* R23 - Write Sequencer Ctrl 1 */
{ 0x00000018, 0x0000 }, /* R24 - Write Sequencer Ctrl 2 */
- { 0x0000001A, 0x0000 }, /* R26 - Write Sequencer PROM */
{ 0x00000020, 0x0000 }, /* R32 - Tone Generator 1 */
{ 0x00000021, 0x1000 }, /* R33 - Tone Generator 2 */
{ 0x00000022, 0x0000 }, /* R34 - Tone Generator 3 */
@@ -243,12 +241,14 @@ static const struct reg_default wm5102_reg_default[] = {
{ 0x00000062, 0x01FF }, /* R98 - Sample Rate Sequence Select 2 */
{ 0x00000063, 0x01FF }, /* R99 - Sample Rate Sequence Select 3 */
{ 0x00000064, 0x01FF }, /* R100 - Sample Rate Sequence Select 4 */
- { 0x00000068, 0x01FF }, /* R104 - Always On Triggers Sequence Select 1 */
- { 0x00000069, 0x01FF }, /* R105 - Always On Triggers Sequence Select 2 */
- { 0x0000006A, 0x01FF }, /* R106 - Always On Triggers Sequence Select 3 */
- { 0x0000006B, 0x01FF }, /* R107 - Always On Triggers Sequence Select 4 */
- { 0x0000006C, 0x01FF }, /* R108 - Always On Triggers Sequence Select 5 */
- { 0x0000006D, 0x01FF }, /* R109 - Always On Triggers Sequence Select 6 */
+ { 0x00000066, 0x01FF }, /* R102 - Always On Triggers Sequence Select 1 */
+ { 0x00000067, 0x01FF }, /* R103 - Always On Triggers Sequence Select 2 */
+ { 0x00000068, 0x01FF }, /* R104 - Always On Triggers Sequence Select 3 */
+ { 0x00000069, 0x01FF }, /* R105 - Always On Triggers Sequence Select 4 */
+ { 0x0000006A, 0x01FF }, /* R106 - Always On Triggers Sequence Select 5 */
+ { 0x0000006B, 0x01FF }, /* R107 - Always On Triggers Sequence Select 6 */
+ { 0x0000006E, 0x01FF }, /* R110 - Trigger Sequence Select 32 */
+ { 0x0000006F, 0x01FF }, /* R111 - Trigger Sequence Select 33 */
{ 0x00000070, 0x0000 }, /* R112 - Comfort Noise Generator */
{ 0x00000090, 0x0000 }, /* R144 - Haptics Control 1 */
{ 0x00000091, 0x7FFF }, /* R145 - Haptics Control 2 */
@@ -258,13 +258,14 @@ static const struct reg_default wm5102_reg_default[] = {
{ 0x00000095, 0x0000 }, /* R149 - Haptics phase 2 duration */
{ 0x00000096, 0x0000 }, /* R150 - Haptics phase 3 intensity */
{ 0x00000097, 0x0000 }, /* R151 - Haptics phase 3 duration */
- { 0x00000100, 0x0001 }, /* R256 - Clock 32k 1 */
+ { 0x00000100, 0x0002 }, /* R256 - Clock 32k 1 */
{ 0x00000101, 0x0304 }, /* R257 - System Clock 1 */
{ 0x00000102, 0x0011 }, /* R258 - Sample rate 1 */
{ 0x00000103, 0x0011 }, /* R259 - Sample rate 2 */
{ 0x00000104, 0x0011 }, /* R260 - Sample rate 3 */
{ 0x00000112, 0x0305 }, /* R274 - Async clock 1 */
{ 0x00000113, 0x0011 }, /* R275 - Async sample rate 1 */
+ { 0x00000114, 0x0011 }, /* R276 - Async sample rate 2 */
{ 0x00000149, 0x0000 }, /* R329 - Output system clock */
{ 0x0000014A, 0x0000 }, /* R330 - Output async clock */
{ 0x00000152, 0x0000 }, /* R338 - Rate Estimator 1 */
@@ -273,13 +274,14 @@ static const struct reg_default wm5102_reg_default[] = {
{ 0x00000155, 0x0000 }, /* R341 - Rate Estimator 4 */
{ 0x00000156, 0x0000 }, /* R342 - Rate Estimator 5 */
{ 0x00000161, 0x0000 }, /* R353 - Dynamic Frequency Scaling 1 */
- { 0x00000171, 0x0000 }, /* R369 - FLL1 Control 1 */
+ { 0x00000171, 0x0002 }, /* R369 - FLL1 Control 1 */
{ 0x00000172, 0x0008 }, /* R370 - FLL1 Control 2 */
{ 0x00000173, 0x0018 }, /* R371 - FLL1 Control 3 */
{ 0x00000174, 0x007D }, /* R372 - FLL1 Control 4 */
{ 0x00000175, 0x0004 }, /* R373 - FLL1 Control 5 */
{ 0x00000176, 0x0000 }, /* R374 - FLL1 Control 6 */
{ 0x00000177, 0x0181 }, /* R375 - FLL1 Loop Filter Test 1 */
+ { 0x00000178, 0x0000 }, /* R376 - FLL1 NCO Test 0 */
{ 0x00000181, 0x0000 }, /* R385 - FLL1 Synchroniser 1 */
{ 0x00000182, 0x0000 }, /* R386 - FLL1 Synchroniser 2 */
{ 0x00000183, 0x0000 }, /* R387 - FLL1 Synchroniser 3 */
@@ -295,6 +297,7 @@ static const struct reg_default wm5102_reg_default[] = {
{ 0x00000195, 0x0004 }, /* R405 - FLL2 Control 5 */
{ 0x00000196, 0x0000 }, /* R406 - FLL2 Control 6 */
{ 0x00000197, 0x0000 }, /* R407 - FLL2 Loop Filter Test 1 */
+ { 0x00000198, 0x0000 }, /* R408 - FLL2 NCO Test 0 */
{ 0x000001A1, 0x0000 }, /* R417 - FLL2 Synchroniser 1 */
{ 0x000001A2, 0x0000 }, /* R418 - FLL2 Synchroniser 2 */
{ 0x000001A3, 0x0000 }, /* R419 - FLL2 Synchroniser 3 */
@@ -310,8 +313,13 @@ static const struct reg_default wm5102_reg_default[] = {
{ 0x00000218, 0x01A6 }, /* R536 - Mic Bias Ctrl 1 */
{ 0x00000219, 0x01A6 }, /* R537 - Mic Bias Ctrl 2 */
{ 0x0000021A, 0x01A6 }, /* R538 - Mic Bias Ctrl 3 */
+ { 0x00000225, 0x0400 }, /* R549 - HP Ctrl 1L */
+ { 0x00000226, 0x0400 }, /* R550 - HP Ctrl 1R */
{ 0x00000293, 0x0000 }, /* R659 - Accessory Detect Mode 1 */
{ 0x0000029B, 0x0020 }, /* R667 - Headphone Detect 1 */
+ { 0x0000029C, 0x0000 }, /* R668 - Headphone Detect 2 */
+ { 0x0000029F, 0x0000 }, /* R671 - Headphone Detect Test */
+ { 0x000002A2, 0x0000 }, /* R674 - Micd Clamp control */
{ 0x000002A3, 0x1102 }, /* R675 - Mic Detect 1 */
{ 0x000002A4, 0x009F }, /* R676 - Mic Detect 2 */
{ 0x000002A5, 0x0000 }, /* R677 - Mic Detect 3 */
@@ -346,53 +354,44 @@ static const struct reg_default wm5102_reg_default[] = {
{ 0x00000400, 0x0000 }, /* R1024 - Output Enables 1 */
{ 0x00000408, 0x0000 }, /* R1032 - Output Rate 1 */
{ 0x00000409, 0x0022 }, /* R1033 - Output Volume Ramp */
- { 0x00000410, 0x0080 }, /* R1040 - Output Path Config 1L */
+ { 0x00000410, 0x4080 }, /* R1040 - Output Path Config 1L */
{ 0x00000411, 0x0180 }, /* R1041 - DAC Digital Volume 1L */
- { 0x00000412, 0x0080 }, /* R1042 - DAC Volume Limit 1L */
+ { 0x00000412, 0x0081 }, /* R1042 - DAC Volume Limit 1L */
{ 0x00000413, 0x0001 }, /* R1043 - Noise Gate Select 1L */
{ 0x00000414, 0x0080 }, /* R1044 - Output Path Config 1R */
{ 0x00000415, 0x0180 }, /* R1045 - DAC Digital Volume 1R */
- { 0x00000416, 0x0080 }, /* R1046 - DAC Volume Limit 1R */
+ { 0x00000416, 0x0081 }, /* R1046 - DAC Volume Limit 1R */
{ 0x00000417, 0x0002 }, /* R1047 - Noise Gate Select 1R */
- { 0x00000418, 0x0080 }, /* R1048 - Output Path Config 2L */
+ { 0x00000418, 0x4080 }, /* R1048 - Output Path Config 2L */
{ 0x00000419, 0x0180 }, /* R1049 - DAC Digital Volume 2L */
- { 0x0000041A, 0x0080 }, /* R1050 - DAC Volume Limit 2L */
+ { 0x0000041A, 0x0081 }, /* R1050 - DAC Volume Limit 2L */
{ 0x0000041B, 0x0004 }, /* R1051 - Noise Gate Select 2L */
{ 0x0000041C, 0x0080 }, /* R1052 - Output Path Config 2R */
{ 0x0000041D, 0x0180 }, /* R1053 - DAC Digital Volume 2R */
- { 0x0000041E, 0x0080 }, /* R1054 - DAC Volume Limit 2R */
+ { 0x0000041E, 0x0081 }, /* R1054 - DAC Volume Limit 2R */
{ 0x0000041F, 0x0008 }, /* R1055 - Noise Gate Select 2R */
- { 0x00000420, 0x0080 }, /* R1056 - Output Path Config 3L */
+ { 0x00000420, 0x4080 }, /* R1056 - Output Path Config 3L */
{ 0x00000421, 0x0180 }, /* R1057 - DAC Digital Volume 3L */
- { 0x00000422, 0x0080 }, /* R1058 - DAC Volume Limit 3L */
+ { 0x00000422, 0x0081 }, /* R1058 - DAC Volume Limit 3L */
{ 0x00000423, 0x0010 }, /* R1059 - Noise Gate Select 3L */
- { 0x00000424, 0x0080 }, /* R1060 - Output Path Config 3R */
- { 0x00000425, 0x0180 }, /* R1061 - DAC Digital Volume 3R */
- { 0x00000426, 0x0080 }, /* R1062 - DAC Volume Limit 3R */
- { 0x00000428, 0x0000 }, /* R1064 - Output Path Config 4L */
+ { 0x00000428, 0xC000 }, /* R1064 - Output Path Config 4L */
{ 0x00000429, 0x0180 }, /* R1065 - DAC Digital Volume 4L */
- { 0x0000042A, 0x0080 }, /* R1066 - Out Volume 4L */
+ { 0x0000042A, 0x0081 }, /* R1066 - Out Volume 4L */
{ 0x0000042B, 0x0040 }, /* R1067 - Noise Gate Select 4L */
- { 0x0000042C, 0x0000 }, /* R1068 - Output Path Config 4R */
{ 0x0000042D, 0x0180 }, /* R1069 - DAC Digital Volume 4R */
- { 0x0000042E, 0x0080 }, /* R1070 - Out Volume 4R */
+ { 0x0000042E, 0x0081 }, /* R1070 - Out Volume 4R */
{ 0x0000042F, 0x0080 }, /* R1071 - Noise Gate Select 4R */
{ 0x00000430, 0x0000 }, /* R1072 - Output Path Config 5L */
{ 0x00000431, 0x0180 }, /* R1073 - DAC Digital Volume 5L */
- { 0x00000432, 0x0080 }, /* R1074 - DAC Volume Limit 5L */
+ { 0x00000432, 0x0081 }, /* R1074 - DAC Volume Limit 5L */
{ 0x00000433, 0x0100 }, /* R1075 - Noise Gate Select 5L */
- { 0x00000434, 0x0000 }, /* R1076 - Output Path Config 5R */
{ 0x00000435, 0x0180 }, /* R1077 - DAC Digital Volume 5R */
- { 0x00000436, 0x0080 }, /* R1078 - DAC Volume Limit 5R */
- { 0x00000437, 0x0200 }, /* R1079 - Noise Gate Select 5R */
+ { 0x00000436, 0x0081 }, /* R1078 - DAC Volume Limit 5R */
+ { 0x00000437, 0x0200 }, /* R1079 - Noise Gate Select 5R */
{ 0x00000450, 0x0000 }, /* R1104 - DAC AEC Control 1 */
{ 0x00000458, 0x0001 }, /* R1112 - Noise Gate Control */
{ 0x00000490, 0x0069 }, /* R1168 - PDM SPK1 CTRL 1 */
{ 0x00000491, 0x0000 }, /* R1169 - PDM SPK1 CTRL 2 */
- { 0x000004DC, 0x0000 }, /* R1244 - DAC comp 1 */
- { 0x000004DD, 0x0000 }, /* R1245 - DAC comp 2 */
- { 0x000004DE, 0x0000 }, /* R1246 - DAC comp 3 */
- { 0x000004DF, 0x0000 }, /* R1247 - DAC comp 4 */
{ 0x00000500, 0x000C }, /* R1280 - AIF1 BCLK Ctrl */
{ 0x00000501, 0x0008 }, /* R1281 - AIF1 Tx Pin Ctrl */
{ 0x00000502, 0x0000 }, /* R1282 - AIF1 Rx Pin Ctrl */
@@ -420,7 +419,6 @@ static const struct reg_default wm5102_reg_default[] = {
{ 0x00000518, 0x0007 }, /* R1304 - AIF1 Frame Ctrl 18 */
{ 0x00000519, 0x0000 }, /* R1305 - AIF1 Tx Enables */
{ 0x0000051A, 0x0000 }, /* R1306 - AIF1 Rx Enables */
- { 0x0000051B, 0x0000 }, /* R1307 - AIF1 Force Write */
{ 0x00000540, 0x000C }, /* R1344 - AIF2 BCLK Ctrl */
{ 0x00000541, 0x0008 }, /* R1345 - AIF2 Tx Pin Ctrl */
{ 0x00000542, 0x0000 }, /* R1346 - AIF2 Rx Pin Ctrl */
@@ -436,7 +434,6 @@ static const struct reg_default wm5102_reg_default[] = {
{ 0x00000552, 0x0001 }, /* R1362 - AIF2 Frame Ctrl 12 */
{ 0x00000559, 0x0000 }, /* R1369 - AIF2 Tx Enables */
{ 0x0000055A, 0x0000 }, /* R1370 - AIF2 Rx Enables */
- { 0x0000055B, 0x0000 }, /* R1371 - AIF2 Force Write */
{ 0x00000580, 0x000C }, /* R1408 - AIF3 BCLK Ctrl */
{ 0x00000581, 0x0008 }, /* R1409 - AIF3 Tx Pin Ctrl */
{ 0x00000582, 0x0000 }, /* R1410 - AIF3 Rx Pin Ctrl */
@@ -452,7 +449,6 @@ static const struct reg_default wm5102_reg_default[] = {
{ 0x00000592, 0x0001 }, /* R1426 - AIF3 Frame Ctrl 12 */
{ 0x00000599, 0x0000 }, /* R1433 - AIF3 Tx Enables */
{ 0x0000059A, 0x0000 }, /* R1434 - AIF3 Rx Enables */
- { 0x0000059B, 0x0000 }, /* R1435 - AIF3 Force Write */
{ 0x000005E3, 0x0004 }, /* R1507 - SLIMbus Framer Ref Gear */
{ 0x000005E5, 0x0000 }, /* R1509 - SLIMbus Rates 1 */
{ 0x000005E6, 0x0000 }, /* R1510 - SLIMbus Rates 2 */
@@ -776,22 +772,6 @@ static const struct reg_default wm5102_reg_default[] = {
{ 0x000008CD, 0x0080 }, /* R2253 - DRC1RMIX Input 3 Volume */
{ 0x000008CE, 0x0000 }, /* R2254 - DRC1RMIX Input 4 Source */
{ 0x000008CF, 0x0080 }, /* R2255 - DRC1RMIX Input 4 Volume */
- { 0x000008D0, 0x0000 }, /* R2256 - DRC2LMIX Input 1 Source */
- { 0x000008D1, 0x0080 }, /* R2257 - DRC2LMIX Input 1 Volume */
- { 0x000008D2, 0x0000 }, /* R2258 - DRC2LMIX Input 2 Source */
- { 0x000008D3, 0x0080 }, /* R2259 - DRC2LMIX Input 2 Volume */
- { 0x000008D4, 0x0000 }, /* R2260 - DRC2LMIX Input 3 Source */
- { 0x000008D5, 0x0080 }, /* R2261 - DRC2LMIX Input 3 Volume */
- { 0x000008D6, 0x0000 }, /* R2262 - DRC2LMIX Input 4 Source */
- { 0x000008D7, 0x0080 }, /* R2263 - DRC2LMIX Input 4 Volume */
- { 0x000008D8, 0x0000 }, /* R2264 - DRC2RMIX Input 1 Source */
- { 0x000008D9, 0x0080 }, /* R2265 - DRC2RMIX Input 1 Volume */
- { 0x000008DA, 0x0000 }, /* R2266 - DRC2RMIX Input 2 Source */
- { 0x000008DB, 0x0080 }, /* R2267 - DRC2RMIX Input 2 Volume */
- { 0x000008DC, 0x0000 }, /* R2268 - DRC2RMIX Input 3 Source */
- { 0x000008DD, 0x0080 }, /* R2269 - DRC2RMIX Input 3 Volume */
- { 0x000008DE, 0x0000 }, /* R2270 - DRC2RMIX Input 4 Source */
- { 0x000008DF, 0x0080 }, /* R2271 - DRC2RMIX Input 4 Volume */
{ 0x00000900, 0x0000 }, /* R2304 - HPLP1MIX Input 1 Source */
{ 0x00000901, 0x0080 }, /* R2305 - HPLP1MIX Input 1 Volume */
{ 0x00000902, 0x0000 }, /* R2306 - HPLP1MIX Input 2 Source */
@@ -883,7 +863,7 @@ static const struct reg_default wm5102_reg_default[] = {
{ 0x00000D1B, 0xFFFF }, /* R3355 - IRQ2 Status 4 Mask */
{ 0x00000D1C, 0xFFFF }, /* R3356 - IRQ2 Status 5 Mask */
{ 0x00000D1F, 0x0000 }, /* R3359 - IRQ2 Control */
- { 0x00000D41, 0x0000 }, /* R3393 - ADSP2 IRQ0 */
+ { 0x00000D50, 0x0000 }, /* R3408 - AOD wkup and trig */
{ 0x00000D53, 0xFFFF }, /* R3411 - AOD IRQ Mask IRQ1 */
{ 0x00000D54, 0xFFFF }, /* R3412 - AOD IRQ Mask IRQ2 */
{ 0x00000D56, 0x0000 }, /* R3414 - Jack detect debounce */
@@ -978,11 +958,6 @@ static const struct reg_default wm5102_reg_default[] = {
{ 0x00000E82, 0x0018 }, /* R3714 - DRC1 ctrl3 */
{ 0x00000E83, 0x0000 }, /* R3715 - DRC1 ctrl4 */
{ 0x00000E84, 0x0000 }, /* R3716 - DRC1 ctrl5 */
- { 0x00000E89, 0x0018 }, /* R3721 - DRC2 ctrl1 */
- { 0x00000E8A, 0x0933 }, /* R3722 - DRC2 ctrl2 */
- { 0x00000E8B, 0x0018 }, /* R3723 - DRC2 ctrl3 */
- { 0x00000E8C, 0x0000 }, /* R3724 - DRC2 ctrl4 */
- { 0x00000E8D, 0x0000 }, /* R3725 - DRC2 ctrl5 */
{ 0x00000EC0, 0x0000 }, /* R3776 - HPLPF1_1 */
{ 0x00000EC1, 0x0000 }, /* R3777 - HPLPF1_2 */
{ 0x00000EC4, 0x0000 }, /* R3780 - HPLPF2_1 */
@@ -993,16 +968,12 @@ static const struct reg_default wm5102_reg_default[] = {
{ 0x00000ECD, 0x0000 }, /* R3789 - HPLPF4_2 */
{ 0x00000EE0, 0x0000 }, /* R3808 - ASRC_ENABLE */
{ 0x00000EE2, 0x0000 }, /* R3810 - ASRC_RATE1 */
- { 0x00000EE3, 0x4000 }, /* R3811 - ASRC_RATE2 */
{ 0x00000EF0, 0x0000 }, /* R3824 - ISRC 1 CTRL 1 */
{ 0x00000EF1, 0x0000 }, /* R3825 - ISRC 1 CTRL 2 */
{ 0x00000EF2, 0x0000 }, /* R3826 - ISRC 1 CTRL 3 */
{ 0x00000EF3, 0x0000 }, /* R3827 - ISRC 2 CTRL 1 */
{ 0x00000EF4, 0x0000 }, /* R3828 - ISRC 2 CTRL 2 */
{ 0x00000EF5, 0x0000 }, /* R3829 - ISRC 2 CTRL 3 */
- { 0x00000EF6, 0x0000 }, /* R3830 - ISRC 3 CTRL 1 */
- { 0x00000EF7, 0x0000 }, /* R3831 - ISRC 3 CTRL 2 */
- { 0x00000EF8, 0x0000 }, /* R3832 - ISRC 3 CTRL 3 */
{ 0x00001100, 0x0010 }, /* R4352 - DSP1 Control 1 */
{ 0x00001101, 0x0000 }, /* R4353 - DSP1 Clocking 1 */
};
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH V2 3/3] ARM: davinci: da850: add NAND driver entries
From: Sekhar Nori @ 2013-01-10 12:19 UTC (permalink / raw)
To: Kumar, Anil
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
davinci-linux-open-source@linux.davincidsp.com,
linux@arm.linux.org.uk, Kevin Hilman, hs@denx.de
In-Reply-To: <F3DBB1B3EF102E4994C89758CFCA32412B80CA@DBDE01.ent.ti.com>
On 1/10/2013 1:07 PM, Kumar, Anil wrote:
> On Wed, Jan 09, 2013 at 18:17:46, Nori, Sekhar wrote:
> I do not think that it is good idea to move NAND pin mux information
> into da850.dtsi because this information is evm specific.
> if we will use this approach then we must use the same approach for
> other modules also as ASoC etc.
Why do you consider this EVM specific. IOW, which pins do you see
changing on another board? BTW, if there are additional pins needed than
what are listed, we can always add more pinux entries in the .dts files.
The pins present in dtsi file should the base case.
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH v7u1 08/31] x86, 64bit: early #PF handler set page table
From: Borislav Petkov @ 2013-01-10 12:19 UTC (permalink / raw)
To: Yinghai Lu
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Eric W. Biederman,
Andrew Morton, Jan Kiszka, Jason Wessel, linux-kernel
In-Reply-To: <CAE9FiQXcP9E-RXre_NKf-SU454nT9K39f1GsVVroV1TFxPgQ7g@mail.gmail.com>
On Wed, Jan 09, 2013 at 05:56:07PM -0800, Yinghai Lu wrote:
> On Mon, Jan 7, 2013 at 7:55 AM, Borislav Petkov <bp@alien8.de> wrote:
> > Those -vXX version lines need to go under the "---" line. Alternatively,
> > you might want to add some of them to the commit message with a proper
> > explanation since they are not that trivial at a first glance, for
> > example the -v5, -v6, -v8, -v9 with a better explanation.
>
> mostly they are for tracking version.
I know that! Please read my suggestion again.
> > This needs hpa's S-O-B.
>
> he will add later when he put the in the tip.
This is not how SOB chaining works:
SOB: Author
SOB: Handler - this is you, who has added it to the patchset
SOB: Committer - maintainer
You need to read Documentation/SubmittingPatches if there's still things
unclear.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply
* [PATCH V2 3/3] ARM: davinci: da850: add NAND driver entries
From: Sekhar Nori @ 2013-01-10 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <F3DBB1B3EF102E4994C89758CFCA32412B80CA@DBDE01.ent.ti.com>
On 1/10/2013 1:07 PM, Kumar, Anil wrote:
> On Wed, Jan 09, 2013 at 18:17:46, Nori, Sekhar wrote:
> I do not think that it is good idea to move NAND pin mux information
> into da850.dtsi because this information is evm specific.
> if we will use this approach then we must use the same approach for
> other modules also as ASoC etc.
Why do you consider this EVM specific. IOW, which pins do you see
changing on another board? BTW, if there are additional pins needed than
what are listed, we can always add more pinux entries in the .dts files.
The pins present in dtsi file should the base case.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 5/9] mfd: arizona: Check errors from regcache_sync()
From: Mark Brown @ 2013-01-10 12:18 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: patches, linux-kernel, Mark Brown
In-Reply-To: <1357820332-14586-1-git-send-email-broonie@opensource.wolfsonmicro.com>
If the control bus is unrelabile we may hit errors during regcache_sync(),
especially given that it tends to be one the most dense bursts of I/O in
many systems.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
drivers/mfd/arizona-core.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index a8b8a7b..1ab02a7 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -239,7 +239,12 @@ static int arizona_runtime_resume(struct device *dev)
return ret;
}
- regcache_sync(arizona->regmap);
+ ret = regcache_sync(arizona->regmap);
+ if (ret != 0) {
+ dev_err(arizona->dev, "Failed to restore register cache\n");
+ regulator_disable(arizona->dcvdd);
+ return ret;
+ }
return 0;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 6/9] mfd: arizona: Allow customisation of microphone detection levels
From: Mark Brown @ 2013-01-10 12:18 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: patches, linux-kernel, Mark Brown
In-Reply-To: <1357820332-14586-1-git-send-email-broonie@opensource.wolfsonmicro.com>
The microphone detection levels for Arizona parts can be customised.
Allow this to be done via platform data, the values chosen will depend
on the system design and determined in discussion with Wolfson.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
drivers/mfd/arizona-core.c | 8 ++++++++
include/linux/mfd/arizona/pdata.h | 5 +++++
include/linux/mfd/arizona/registers.h | 4 ++++
3 files changed, 17 insertions(+)
diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index 1ab02a7..5f0de90 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -458,6 +458,14 @@ int arizona_dev_init(struct arizona *arizona)
arizona->pdata.gpio_defaults[i]);
}
+ for (i = 0; i < ARRAY_SIZE(arizona->pdata.micd_level); i++) {
+ if (!arizona->pdata.micd_level[i])
+ continue;
+
+ regmap_write(arizona->regmap, ARIZONA_MIC_DETECT_LEVEL_1 + i,
+ arizona->pdata.micd_level[i]);
+ }
+
pm_runtime_set_autosuspend_delay(arizona->dev, 100);
pm_runtime_use_autosuspend(arizona->dev);
pm_runtime_enable(arizona->dev);
diff --git a/include/linux/mfd/arizona/pdata.h b/include/linux/mfd/arizona/pdata.h
index 8b1d1da..73822bd 100644
--- a/include/linux/mfd/arizona/pdata.h
+++ b/include/linux/mfd/arizona/pdata.h
@@ -67,6 +67,8 @@
#define ARIZONA_MAX_PDM_SPK 2
+#define ARIZONA_NUM_MICD_LEVEL 4
+
struct regulator_init_data;
struct arizona_micd_config {
@@ -99,6 +101,9 @@ struct arizona_pdata {
/** GPIO for mic detection polarity */
int micd_pol_gpio;
+ /** Mic detect level parameters */
+ int micd_level[ARIZONA_NUM_MICD_LEVEL];
+
/** Headset polarity configurations */
struct arizona_micd_config *micd_configs;
int num_micd_configs;
diff --git a/include/linux/mfd/arizona/registers.h b/include/linux/mfd/arizona/registers.h
index 1f6fe31..fb3a1b8 100644
--- a/include/linux/mfd/arizona/registers.h
+++ b/include/linux/mfd/arizona/registers.h
@@ -122,6 +122,10 @@
#define ARIZONA_MIC_DETECT_1 0x2A3
#define ARIZONA_MIC_DETECT_2 0x2A4
#define ARIZONA_MIC_DETECT_3 0x2A5
+#define ARIZONA_MIC_DETECT_LEVEL_1 0x2A6
+#define ARIZONA_MIC_DETECT_LEVEL_2 0x2A7
+#define ARIZONA_MIC_DETECT_LEVEL_3 0x2A8
+#define ARIZONA_MIC_DETECT_LEVEL_4 0x2A9
#define ARIZONA_MIC_NOISE_MIX_CONTROL_1 0x2C3
#define ARIZONA_ISOLATION_CONTROL 0x2CB
#define ARIZONA_JACK_DETECT_ANALOGUE 0x2D3
--
1.7.10.4
^ permalink raw reply related
* [PATCH 7/9] mfd: wm5102: Add registers for microphone detection level configuration
From: Mark Brown @ 2013-01-10 12:18 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: patches, linux-kernel, Mark Brown
In-Reply-To: <1357820332-14586-1-git-send-email-broonie@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
drivers/mfd/wm5102-tables.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/mfd/wm5102-tables.c b/drivers/mfd/wm5102-tables.c
index 0317d11..167e6c4 100644
--- a/drivers/mfd/wm5102-tables.c
+++ b/drivers/mfd/wm5102-tables.c
@@ -315,6 +315,10 @@ static const struct reg_default wm5102_reg_default[] = {
{ 0x000002A3, 0x1102 }, /* R675 - Mic Detect 1 */
{ 0x000002A4, 0x009F }, /* R676 - Mic Detect 2 */
{ 0x000002A5, 0x0000 }, /* R677 - Mic Detect 3 */
+ { 0x000002A6, 0x3737 }, /* R678 - Mic Detect Level 1 */
+ { 0x000002A7, 0x372C }, /* R679 - Mic Detect Level 2 */
+ { 0x000002A8, 0x1422 }, /* R680 - Mic Detect Level 3 */
+ { 0x000002A9, 0x300A }, /* R681 - Mic Detect Level 4 */
{ 0x000002C3, 0x0000 }, /* R707 - Mic noise mix control 1 */
{ 0x000002CB, 0x0000 }, /* R715 - Isolation control */
{ 0x000002D3, 0x0000 }, /* R723 - Jack detect analogue */
@@ -1109,6 +1113,10 @@ static bool wm5102_readable_register(struct device *dev, unsigned int reg)
case ARIZONA_MIC_DETECT_1:
case ARIZONA_MIC_DETECT_2:
case ARIZONA_MIC_DETECT_3:
+ case ARIZONA_MIC_DETECT_LEVEL_1:
+ case ARIZONA_MIC_DETECT_LEVEL_2:
+ case ARIZONA_MIC_DETECT_LEVEL_3:
+ case ARIZONA_MIC_DETECT_LEVEL_4:
case ARIZONA_MIC_NOISE_MIX_CONTROL_1:
case ARIZONA_ISOLATION_CONTROL:
case ARIZONA_JACK_DETECT_ANALOGUE:
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] Add a check avoid segfault.
From: Jens Axboe @ 2013-01-10 12:18 UTC (permalink / raw)
To: majianpeng; +Cc: fio
In-Reply-To: <201301101936131638895@gmail.com>
On 2013-01-10 12:36, majianpeng wrote:
> If new_size was zero or realloc failed, it would be segment fault.
> So add a check.
It's a drop in the bucket, fio basically does not alloc failure
checking. It'd be nice to improve on that, but you'd need a lot more
than the below to get near fixing that.
--
Jens Axboe
^ permalink raw reply
* [PATCH 1/9] mfd: wm5102: Mark DSP memory regions as volatile and readable
From: Mark Brown @ 2013-01-10 12:18 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: patches, linux-kernel, Mark Brown
In-Reply-To: <20130110121828.GN20956@opensource.wolfsonmicro.com>
We can cache some of them but this is simpler for now.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
drivers/mfd/wm5102-tables.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/wm5102-tables.c b/drivers/mfd/wm5102-tables.c
index 088872a..4a01192 100644
--- a/drivers/mfd/wm5102-tables.c
+++ b/drivers/mfd/wm5102-tables.c
@@ -1825,7 +1825,13 @@ static bool wm5102_readable_register(struct device *dev, unsigned int reg)
case ARIZONA_DSP1_STATUS_3:
return true;
default:
- return false;
+ if ((reg >= 0x100000 && reg < 0x106000) ||
+ (reg >= 0x180000 && reg < 0x180800) ||
+ (reg >= 0x190000 && reg < 0x194800) ||
+ (reg >= 0x1a8000 && reg < 0x1a9800))
+ return true;
+ else
+ return false;
}
}
--
1.7.10.4
^ permalink raw reply related
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.