* Re: [Qemu-devel] [PATCH] target-arm: Tidy up ARM1136 CPUID naming
From: Andreas Färber @ 2011-10-22 9:22 UTC (permalink / raw)
To: Andrzej Zaborowski, Peter Maydell; +Cc: qemu-devel
In-Reply-To: <1317637971-19296-1-git-send-email-andreas.faerber@web.de>
Am 03.10.2011 12:32, schrieb Andreas Färber:
> -cpu arm1136-r2 is commented to in fact be ARM1136 r0p2, whereas
> -cpu arm1136 seems to be ARM1136 r1p3 according to the MIDR value.
>
> The CPUID values contain major and minor revision numbers (rnpn) and
> are never used with a mask, so are specific to the chosen revision.
> Rename the CPUID preprocessor defines to reflect this, but leave the
> CPU model names unchanged for command line compatibility.
>
> Cc: Andrzej Zaborowski <andrew@openedhand.com>
> Cc: Peter Maydell <peter.maydell@linaro.org>
> Signed-off-by: Andreas Färber <andreas.faerber@web.de>
> ---
Ping?
Andreas
> target-arm/cpu.h | 4 ++--
> target-arm/helper.c | 12 ++++++------
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/target-arm/cpu.h b/target-arm/cpu.h
> index 6ab780d..783989f 100644
> --- a/target-arm/cpu.h
> +++ b/target-arm/cpu.h
> @@ -419,8 +419,8 @@ void cpu_arm_set_cp_io(CPUARMState *env, int cpnum,
> #define ARM_CPUID_PXA270_B1 0x69054113
> #define ARM_CPUID_PXA270_C0 0x69054114
> #define ARM_CPUID_PXA270_C5 0x69054117
> -#define ARM_CPUID_ARM1136 0x4117b363
> -#define ARM_CPUID_ARM1136_R2 0x4107b362
> +#define ARM_CPUID_ARM1136_R1P3 0x4117b363
> +#define ARM_CPUID_ARM1136_R0P2 0x4107b362
> #define ARM_CPUID_ARM1176 0x410fb767
> #define ARM_CPUID_ARM11MPCORE 0x410fb022
> #define ARM_CPUID_CORTEXA8 0x410fc080
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index e2428eb..0d342ba 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -76,11 +76,11 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
> env->cp15.c0_cachetype = 0x1dd20d2;
> env->cp15.c1_sys = 0x00090078;
> break;
> - case ARM_CPUID_ARM1136:
> + case ARM_CPUID_ARM1136_R1P3:
> /* This is the 1136 r1, which is a v6K core */
> set_feature(env, ARM_FEATURE_V6K);
> /* Fall through */
> - case ARM_CPUID_ARM1136_R2:
> + case ARM_CPUID_ARM1136_R0P2:
> /* What qemu calls "arm1136_r2" is actually the 1136 r0p2, ie an
> * older core than plain "arm1136". In particular this does not
> * have the v6K features.
> @@ -417,8 +417,8 @@ static const struct arm_cpu_t arm_cpu_names[] = {
> { ARM_CPUID_ARM926, "arm926"},
> { ARM_CPUID_ARM946, "arm946"},
> { ARM_CPUID_ARM1026, "arm1026"},
> - { ARM_CPUID_ARM1136, "arm1136"},
> - { ARM_CPUID_ARM1136_R2, "arm1136-r2"},
> + { ARM_CPUID_ARM1136_R1P3, "arm1136" },
> + { ARM_CPUID_ARM1136_R0P2, "arm1136-r2" },
> { ARM_CPUID_ARM1176, "arm1176"},
> { ARM_CPUID_ARM11MPCORE, "arm11mpcore"},
> { ARM_CPUID_CORTEXM3, "cortex-m3"},
> @@ -1886,8 +1886,8 @@ uint32_t HELPER(get_cp15)(CPUState *env, uint32_t insn)
> switch (ARM_CPUID(env)) {
> case ARM_CPUID_ARM1026:
> return 1;
> - case ARM_CPUID_ARM1136:
> - case ARM_CPUID_ARM1136_R2:
> + case ARM_CPUID_ARM1136_R1P3:
> + case ARM_CPUID_ARM1136_R0P2:
> case ARM_CPUID_ARM1176:
> return 7;
> case ARM_CPUID_ARM11MPCORE:
^ permalink raw reply
* Re: [RFD] Isolated memory cgroups again
From: Michal Hocko @ 2011-10-22 9:26 UTC (permalink / raw)
To: Balbir Singh
Cc: KAMEZAWA Hiroyuki, linux-mm, LKML, Johannes Weiner,
Daisuke Nishimura, Hugh Dickins, Ying Han, Andrew Morton,
Glauber Costa, Kir Kolyshkin, Pavel Emelianov, GregThelen,
pjt@google.com, Tim Hockin, Dave Hansen, Paul Menage,
James Bottomley
In-Reply-To: <CAKTCnz=iZp37sBfY++HUU0oscskFF_UWYeFYtAujtQh4_B=vHQ@mail.gmail.com>
On Fri 21-10-11 21:34:06, Balbir Singh wrote:
> On Thu, Oct 20, 2011 at 7:29 AM, KAMEZAWA Hiroyuki
> <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > On Wed, 19 Oct 2011 18:33:09 -0700
> > Michal Hocko <mhocko@suse.cz> wrote:
> >
> >> Hi all,
> >> this is a request for discussion (I hope we can touch this during memcg
> >> meeting during the upcoming KS). I have brought this up earlier this
> >> year before LSF (http://thread.gmane.org/gmane.linux.kernel.mm/60464).
> >> The patch got much smaller since then due to excellent Johannes' memcg
> >> naturalization work (http://thread.gmane.org/gmane.linux.kernel.mm/68724)
> >> which this is based on.
> >
>
> Hi, Michal
Hi Balbir,
>
> I'd like to understand, what the isolation is for?
>
> 1. Is it an alternative to memory guarantees?
Not really, it is more about resident working set guarantee and workload
isolations wrt. memory.
> 2. How is this different from doing cpusets (fake NUMA) and isolating them?
Yes this would work. I have not many experiences in this area but I
guess the primary stopper for fake NUMA is that it is x86_64 only,
configuration is static and little bit awkward to use (nodes of the same
size e.g.).
I understood that google is moving out of fake NUMA towards memcg for those
reasons.
>
> Just trying to catch up,
> Balbir
--
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
^ permalink raw reply
* Re: [RFD] Isolated memory cgroups again
From: Michal Hocko @ 2011-10-22 9:26 UTC (permalink / raw)
To: Balbir Singh
Cc: KAMEZAWA Hiroyuki, linux-mm, LKML, Johannes Weiner,
Daisuke Nishimura, Hugh Dickins, Ying Han, Andrew Morton,
Glauber Costa, Kir Kolyshkin, Pavel Emelianov, GregThelen,
pjt@google.com, Tim Hockin, Dave Hansen, Paul Menage,
James Bottomley
In-Reply-To: <CAKTCnz=iZp37sBfY++HUU0oscskFF_UWYeFYtAujtQh4_B=vHQ@mail.gmail.com>
On Fri 21-10-11 21:34:06, Balbir Singh wrote:
> On Thu, Oct 20, 2011 at 7:29 AM, KAMEZAWA Hiroyuki
> <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > On Wed, 19 Oct 2011 18:33:09 -0700
> > Michal Hocko <mhocko@suse.cz> wrote:
> >
> >> Hi all,
> >> this is a request for discussion (I hope we can touch this during memcg
> >> meeting during the upcoming KS). I have brought this up earlier this
> >> year before LSF (http://thread.gmane.org/gmane.linux.kernel.mm/60464).
> >> The patch got much smaller since then due to excellent Johannes' memcg
> >> naturalization work (http://thread.gmane.org/gmane.linux.kernel.mm/68724)
> >> which this is based on.
> >
>
> Hi, Michal
Hi Balbir,
>
> I'd like to understand, what the isolation is for?
>
> 1. Is it an alternative to memory guarantees?
Not really, it is more about resident working set guarantee and workload
isolations wrt. memory.
> 2. How is this different from doing cpusets (fake NUMA) and isolating them?
Yes this would work. I have not many experiences in this area but I
guess the primary stopper for fake NUMA is that it is x86_64 only,
configuration is static and little bit awkward to use (nodes of the same
size e.g.).
I understood that google is moving out of fake NUMA towards memcg for those
reasons.
>
> Just trying to catch up,
> Balbir
--
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFD] Isolated memory cgroups again
From: Michal Hocko @ 2011-10-22 9:31 UTC (permalink / raw)
To: Ying Han
Cc: KAMEZAWA Hiroyuki, linux-mm@kvack.org, LKML, Johannes Weiner,
Daisuke Nishimura, Hugh Dickins, Andrew Morton, Glauber Costa,
Kir Kolyshkin, Pavel Emelianov, GregThelen, pjt@google.com,
Tim Hockin, Dave Hansen, Paul Menage, James Bottomley
In-Reply-To: <CALWz4iw9OGUNKjD5y2xGDGaesTjwUT5TOL2A7wDd5apy4M5fnw@mail.gmail.com>
On Fri 21-10-11 13:00:18, Ying Han wrote:
[...]
> The logic is based on reclaim priority, and we skip reclaim from certain
> memcg(under soft limit) before getting down to DEF_PRIORITY - 3.
OK, I guess I remember something from the earlier memcg naturalization
patch set discussions. This will still not help much for my case as the
bigger memory pressure would cause reclaim also from the soft unlimited
group which I would like to prevent.
The other thing about soft limit only reclaim from the global reclaim is
that currently all created memcgs are soft unlimited by default which
might lead to unexpected results. Can we come up with a reasonable soft
limit default?
[...]
--
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
^ permalink raw reply
* Re: [RFD] Isolated memory cgroups again
From: Michal Hocko @ 2011-10-22 9:31 UTC (permalink / raw)
To: Ying Han
Cc: KAMEZAWA Hiroyuki, linux-mm@kvack.org, LKML, Johannes Weiner,
Daisuke Nishimura, Hugh Dickins, Andrew Morton, Glauber Costa,
Kir Kolyshkin, Pavel Emelianov, GregThelen, pjt@google.com,
Tim Hockin, Dave Hansen, Paul Menage, James Bottomley
In-Reply-To: <CALWz4iw9OGUNKjD5y2xGDGaesTjwUT5TOL2A7wDd5apy4M5fnw@mail.gmail.com>
On Fri 21-10-11 13:00:18, Ying Han wrote:
[...]
> The logic is based on reclaim priority, and we skip reclaim from certain
> memcg(under soft limit) before getting down to DEF_PRIORITY - 3.
OK, I guess I remember something from the earlier memcg naturalization
patch set discussions. This will still not help much for my case as the
bigger memory pressure would cause reclaim also from the soft unlimited
group which I would like to prevent.
The other thing about soft limit only reclaim from the global reclaim is
that currently all created memcgs are soft unlimited by default which
might lead to unexpected results. Can we come up with a reasonable soft
limit default?
[...]
--
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Bug In ext4 in kernels > 2.6.39 - Not mounting with arguments/options I specify in fstab on root remount
From: Ted Ts'o @ 2011-10-22 9:32 UTC (permalink / raw)
To: Matt Parnell; +Cc: Eric Sandeen, linux-ext4
In-Reply-To: <4EA27607.20407@gmail.com>
On Sat, Oct 22, 2011 at 02:51:35AM -0500, Matt Parnell wrote:
> That doesn't really help me at all, it's not
> rootflags=data=writeback causing this, it's starting to make me
> think that arch's init may be to blame, although I previously ruled
> it out...
Well, it looks like rootflags=data=writeback is not making it to the
file system. That's why it's not showing up in /proc/mounts, from you
showed us. Can you look at the kernel dmesg?
You should see something like this:
[ 1.421146] EXT3-fs (vda): error: couldn't mount because of unsupported optional features (240)
[ 1.434057] EXT4-fs (vda): couldn't mount as ext2 due to feature incompatibilities
[ 1.454631] EXT4-fs (vda): mounted filesystem with writeback data mode. Opts: data=writeback
[ 1.455966] VFS: Mounted root (ext4 filesystem) readonly on device 254:0.
The first line is the failure to mount the root file system as ext3.
The 2nd is the failure to mount the file system as ext2, using the
ext4 file system driver. The last two lines show the options show the
mount as ext4.
What do those two lines look to you. If you don't see "Opts:
data=writeback", then somehow the rootflags option isn't getting passed
down to the file system. Then when you try to remount the file system
read/write, the fact that you have "data=writeback" in your /etc/fstab
causes the failure to remount.
If you simply remove that from /etc/fstab, things should work better.
The remount will preserve whatever data=journalling mode was in use
when the root file system was originallymounted as. If rootflags is
non-functional, then the file system won't be mounted as
data=writeback, but at least the boot sequence will continue without
blowing out.
- Ted
^ permalink raw reply
* Re: [Qemu-devel] Multi heterogenous CPU archs for SoC sim?
From: Peter Maydell @ 2011-10-22 9:32 UTC (permalink / raw)
To: Andreas Färber; +Cc: Blue Swirl, Lluís, qemu-devel Developers
In-Reply-To: <4EA1EC91.6050705@web.de>
On 21 October 2011 23:05, Andreas Färber <andreas.faerber@web.de> wrote:
> Am 21.10.2011 08:58, schrieb Peter Maydell:
>> (For several
>> of the ARM boards we currently just ignore the fact that the real
>> h/w has a Cortex-M3 doing power management type stuff.)
>
> Mind to share which boards? I'm only aware of the NXP LPC43xx asymmetric
> SoC (Cortex-M4 + Cortex-M0), which still is in development stage.
I had in mind the Versatile Express -- the main core is an A9x4
but there is also an M3 on the board. (There are some other
interestng ARM based heterogeneous architectures coming
up too, like the nVidia Tegra3 with 4xA9+1xA9, and the ARM
big.LITTLE systems with 4xA7+4xA15.)
> The
> datasheet doesn't really enlighten me how such a combo is supposed to
> work in shared memory: Do all ARM cores share a reset vector (or what
> you call it on arm) so that one has to branch based on CPUID to do
> different tasks on different cores?
In general a multicore bootup will use the core ID to figure out
what it is at reset. I don't know what a multicluster system
would do, but probably the same thing. The other approach I've
seen is that you can give the two CPUs different memory maps
so they share most things but have different memory layouts
where the vector table/startup code is. Or you could have
the power controller hold the secondary core in reset until
the primary core has booted, and have your boot code work
differently for first and second execution, I guess.
(The reset architecture on M profile and AR profiles is different,
but I don't think the differences are important for these purposes.)
-- PMM
^ permalink raw reply
* Re: [PATCH v2 1/2] ASoC: core: Add flag to ignore pmdown_time at pcm_close
From: Mark Brown @ 2011-10-22 9:33 UTC (permalink / raw)
To: Nallasellan, Singaravelan
Cc: Peter Ujfalusi, alsa-devel@alsa-project.org, Liam Girdwood,
Babu, Ramesh, Misael Lopez Cruz
In-Reply-To: <3CA6C6D9F70D314CA34352990B57DA1507C8CB9611@bgsmsx502.gar.corp.intel.com>
On Sat, Oct 22, 2011 at 01:54:23AM +0530, Nallasellan, Singaravelan wrote:
When I said you shouldn't top post that's exactly what I meant! This is
basic mailing list etiquette for public Linux lists because for
example...
> Agree. System integrator may not like to delay closing modem ports for 6 seconds either. Need to close the ports immediately or delay.
...not having any context quoted means the reader can't easily tell wht
it is that you are agreeing with. You should also fix your mail client
to word wrap within paragraphs as I also mentioned.
> Do you suggest that we shouldn't delay in the driver and introduce delay in the user pace?
> I prefer to remove the delay altogether from the driver. Do you see any issue which might cause glitches?
The delay is very important for CPU use cases as brief gaps in playback
are extremely common there. The power up and power down are generally
noticable and to be avoided.
^ permalink raw reply
* Question about: linux-linaro-2.6.38.7 booting the ubuntu 10.10 filesystem
From: David Yang @ 2011-10-22 9:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALQsFOLjbBmvPC5iU_cY3LrEe03Z8q90mm5UsS2KoqVQsLjivA@mail.gmail.com>
hi,all
I found in my timer driver,I didn't implement the "init_sched_clock" function.
Is this the root reason?
Best Regards,
David
On 10/22/11, David Yang <david.yangshuai@gmail.com> wrote:
> hi,all
>
> when I config the Preemptible Kernel .
>
> These is the futext_wake crash every booting.
>
>
>
>
> Best Regards,
> David
>
> On 10/22/11, David Yang <david.yangshuai@gmail.com> wrote:
>> hi,all
>>
>> Does anyone know the issue?
>>
>> Thanks!
>>
>>
>>
>> Best Regards,
>> David
>>
>>
>> On 10/20/11, David Yang <david.yangshuai@gmail.com> wrote:
>>> hi,Afzal
>>>
>>> It's not zero.
>>>
>>>
>>>
>>> Best Regards,
>>> Shuai
>>>
>>> On 10/20/11, Mohammed, Afzal <afzal@ti.com> wrote:
>>>> Hi David,
>>>>
>>>> On Thu, Oct 20, 2011 at 17:32:25, David Yang wrote:
>>>>> another log when booting ubuntu10.10:
>>>>>
>>>>>
>>>>> the PC stopped at futex_wake() again!
>>>>>
>>>>
>>>> Please pass "printk.time=1" from commandline, and check the
>>>> Kernel logs whether timing shown are zero.
>>>>
>>>> Regards
>>>> Afzal
>>>>
>>>
>>
>
^ permalink raw reply
* Re: [PATCH] ASoC: sgtl5000: Fix wrong mask in some snd_soc_update_bits calls
From: Mark Brown @ 2011-10-22 9:36 UTC (permalink / raw)
To: Axel Lin
Cc: alsa-devel, Liam Girdwood, Dong Aisheng, linux-kernel,
Wolfram Sang
In-Reply-To: <1319162083.4352.2.camel@phoenix>
On Fri, Oct 21, 2011 at 09:54:43AM +0800, Axel Lin wrote:
> Ensure all mask bits are clear before setting new value.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ASoC: sgtl5000: Fix wrong mask in some snd_soc_update_bits calls
From: Mark Brown @ 2011-10-22 9:36 UTC (permalink / raw)
To: Axel Lin
Cc: linux-kernel, Dong Aisheng, Wolfram Sang, Liam Girdwood,
alsa-devel
In-Reply-To: <1319162083.4352.2.camel@phoenix>
On Fri, Oct 21, 2011 at 09:54:43AM +0800, Axel Lin wrote:
> Ensure all mask bits are clear before setting new value.
Applied, thanks.
^ permalink raw reply
* Re: [alsa-devel] [PATCH v8 1/3] ASoC: da7210: Add support for DAPM
From: Mark Brown @ 2011-10-22 9:37 UTC (permalink / raw)
To: Ashish Chavan
Cc: lrg, alsa-devel, David Dajun Chen, kuninori.morimoto.gx,
linux-kernel
In-Reply-To: <1319201168.24621.210.camel@matrix>
On Fri, Oct 21, 2011 at 06:16:08PM +0530, Ashish Chavan wrote:
> This patch adds support for DAPM covering all inputs and outputs
> as well as ADC and DAC.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v8 2/3] ASoC: da7210: Add support for line out and DAC
From: Mark Brown @ 2011-10-22 9:37 UTC (permalink / raw)
To: Ashish Chavan
Cc: linux-kernel, alsa-devel, lrg, kuninori.morimoto.gx,
David Dajun Chen
In-Reply-To: <1319204183.24621.265.camel@matrix>
On Fri, Oct 21, 2011 at 07:06:23PM +0530, Ashish Chavan wrote:
> DA7210 has three line outputs. OUT1 Left, OUT1 Right and OUT2 (mono).
> This patch adds support for gain controls for these three line outs.
> It also adds support for overall DAC gain control.
Applied, thanks.
^ permalink raw reply
* Re: [alsa-devel] [PATCH v8 2/3] ASoC: da7210: Add support for line out and DAC
From: Mark Brown @ 2011-10-22 9:37 UTC (permalink / raw)
To: Ashish Chavan
Cc: lrg, alsa-devel, David Dajun Chen, kuninori.morimoto.gx,
linux-kernel
In-Reply-To: <1319204183.24621.265.camel@matrix>
On Fri, Oct 21, 2011 at 07:06:23PM +0530, Ashish Chavan wrote:
> DA7210 has three line outputs. OUT1 Left, OUT1 Right and OUT2 (mono).
> This patch adds support for gain controls for these three line outs.
> It also adds support for overall DAC gain control.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v8 3/3] ASoC: da7210: Add support for line input and mic
From: Mark Brown @ 2011-10-22 9:38 UTC (permalink / raw)
To: Ashish Chavan
Cc: linux-kernel, alsa-devel, lrg, kuninori.morimoto.gx,
David Dajun Chen
In-Reply-To: <1319204398.24621.274.camel@matrix>
On Fri, Oct 21, 2011 at 07:09:58PM +0530, Ashish Chavan wrote:
> DA7210 has three line inputs (AUX1 Left, AUX1 Right and AUX2) and
> a stereo MIC. This patch adds gain controls for MIC, AUX1, AUX2 as
> well as INPGA. It also adds a control to set MIC BIAS voltage.
Applied, though the last comment is inaccurate (the micbias should be
managed by kernel code, you removed the control in an earlier revision).
^ permalink raw reply
* Re: [alsa-devel] [PATCH v8 3/3] ASoC: da7210: Add support for line input and mic
From: Mark Brown @ 2011-10-22 9:38 UTC (permalink / raw)
To: Ashish Chavan
Cc: lrg, alsa-devel, David Dajun Chen, kuninori.morimoto.gx,
linux-kernel
In-Reply-To: <1319204398.24621.274.camel@matrix>
On Fri, Oct 21, 2011 at 07:09:58PM +0530, Ashish Chavan wrote:
> DA7210 has three line inputs (AUX1 Left, AUX1 Right and AUX2) and
> a stereo MIC. This patch adds gain controls for MIC, AUX1, AUX2 as
> well as INPGA. It also adds a control to set MIC BIAS voltage.
Applied, though the last comment is inaccurate (the micbias should be
managed by kernel code, you removed the control in an earlier revision).
^ permalink raw reply
* Re: [PATCH] ASoC: wm8996: Fix wrong mask for setting WM8996_AIF_CLOCKING_2
From: Mark Brown @ 2011-10-22 9:40 UTC (permalink / raw)
To: Axel Lin; +Cc: Dimitris Papastamos, alsa-devel, linux-kernel, Liam Girdwood
In-Reply-To: <1319165047.4352.4.camel@phoenix>
On Fri, Oct 21, 2011 at 10:44:07AM +0800, Axel Lin wrote:
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ASoC: wm8996: Fix wrong mask for setting WM8996_AIF_CLOCKING_2
From: Mark Brown @ 2011-10-22 9:40 UTC (permalink / raw)
To: Axel Lin; +Cc: linux-kernel, Dimitris Papastamos, Liam Girdwood, alsa-devel
In-Reply-To: <1319165047.4352.4.camel@phoenix>
On Fri, Oct 21, 2011 at 10:44:07AM +0800, Axel Lin wrote:
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 06/11] ttm/driver: Expand ttm_backend_func to include two overrides for TTM page pool.
From: Thomas Hellstrom @ 2011-10-22 9:40 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: thellstrom, xen-devel, linux-kernel, dri-devel, j.glisse, airlied,
bskeggs
In-Reply-To: <1319062772-2793-7-git-send-email-konrad.wilk@oracle.com>
Konrad,
I was hoping that we could get rid of the dma_address shuffling into
core TTM,
like I mentioned in the review. From what I can tell it's now only used
in the backend and
core ttm doesn't care about it.
Is there a particular reason we're still passing it around?
Thanks,
/Thomas
On 10/20/2011 12:19 AM, Konrad Rzeszutek Wilk wrote:
> The two overrides will be choosen by the backends whether they
> want to use a different TTM page pool than the default.
>
> If the backend does not choose a new override, the default one
> will be used.
>
> Signed-off-by: Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 10 +++++++---
> include/drm/ttm/ttm_bo_driver.h | 31 +++++++++++++++++++++++++++++++
> 2 files changed, 38 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> index 24c0340..360afb3 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> @@ -861,13 +861,17 @@ EXPORT_SYMBOL(ttm_page_alloc_debugfs);
> int ttm_get_pages(struct ttm_tt *ttm, struct list_head *pages,
> unsigned count, dma_addr_t *dma_address)
> {
> + if (ttm->be&& ttm->be->func&& ttm->be->func->get_pages)
> + return ttm->be->func->get_pages(ttm, pages, count, dma_address);
> return __ttm_get_pages(pages, ttm->page_flags, ttm->caching_state,
> count, dma_address);
> }
> -{
> void ttm_put_pages(struct ttm_tt *ttm, struct list_head *pages,
> unsigned page_count, dma_addr_t *dma_address)
> {
> - __ttm_put_pages(pages, page_count, ttm->page_flags, ttm->caching_state,
> - dma_address);
> + if (ttm->be&& ttm->be->func&& ttm->be->func->put_pages)
> + ttm->be->func->put_pages(ttm, pages, page_count, dma_address);
> + else
> + __ttm_put_pages(pages, page_count, ttm->page_flags,
> + ttm->caching_state, dma_address);
> }
> diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
> index 09af2d7..1826c3b 100644
> --- a/include/drm/ttm/ttm_bo_driver.h
> +++ b/include/drm/ttm/ttm_bo_driver.h
> @@ -100,6 +100,34 @@ struct ttm_backend_func {
> * Destroy the backend.
> */
> void (*destroy) (struct ttm_backend *backend);
> +
> + /**
> + * ttm_get_pages override. The backend can override the default
> + * TTM page pool code with a different one.
> + *
> + * Get count number of pages from pool to pages list.
> + *
> + * @ttm: ttm which contains flags for page allocation and caching state.
> + * @pages: head of empty linked list where pages are filled.
> + * @dma_address: The DMA (bus) address of pages
> + */
> + int (*get_pages) (struct ttm_tt *ttm, struct list_head *pages,
> + unsigned count, dma_addr_t *dma_address);
> +
> + /**
> + * ttm_put_pages override. The backend can override the default
> + * TTM page pool code with a different implementation.
> + *
> + * Put linked list of pages to pool.
> + *
> + * @ttm: ttm which contains flags for page allocation and caching state.
> + * @pages: list of pages to free.
> + * @page_count: number of pages in the list. Zero can be passed for
> + * unknown count.
> + * @dma_address: The DMA (bus) address of pages
> + */
> + void (*put_pages) (struct ttm_tt *ttm, struct list_head *pages,
> + unsigned page_count, dma_addr_t *dma_address);
> };
>
> /**
> @@ -109,6 +137,8 @@ struct ttm_backend_func {
> * @flags: For driver use.
> * @func: Pointer to a struct ttm_backend_func that describes
> * the backend methods.
> + * @dev: Pointer to a struct device which can be used by the TTM
> + * [get|put)_pages overrides in 'struct ttm_backend_func'.
> *
> */
>
> @@ -116,6 +146,7 @@ struct ttm_backend {
> struct ttm_bo_device *bdev;
> uint32_t flags;
> struct ttm_backend_func *func;
> + struct device *dev;
> };
>
> #define TTM_PAGE_FLAG_USER (1<< 1)
>
^ permalink raw reply
* Re: longjmp question
From: Jurij Smakov @ 2011-10-22 9:43 UTC (permalink / raw)
To: sparclinux
In-Reply-To: <20111007232209.GA11892@wooyd.org>
On Sat, Oct 22, 2011 at 05:05:05AM -0400, David Miller wrote:
> From: Jurij Smakov <jurij@wooyd.org>
> Date: Sat, 22 Oct 2011 10:00:24 +0100
>
> > Is something conceptually wrong with just doing this:
> >
> > asm volatile ("save; flush; restore");
> >
> > It fixes the problem for freebsd (will test on linux later today), and
> > does not rely on compiler doing (or not doing) the "right"
> > optimization.
>
> I would not do a "naked" save here, please just use the construct
> I showed you with the %o7 register clobber.
Yes, I missed that save is not allocating any memory, which is
wrong. What I actually had in mind was this:
asm volatile ("save %sp, -96, %sp; flushw; restore");
My concern with the approach you are proposing is that compiler
may (in the future, perhaps) just optimize out the helper function,
making arrangements to save %o7 in one of the unused registers, thus
removing allocation of another register window and breaking it again.
Best regards,
--
Jurij Smakov jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
^ permalink raw reply
* Re: [PATCH v2 1/2] ASoC: core: Add flag to ignore pmdown_time at pcm_close
From: Mark Brown @ 2011-10-22 9:45 UTC (permalink / raw)
To: Babu, Ramesh
Cc: Peter Ujfalusi, alsa-devel@alsa-project.org, Liam Girdwood,
Misael Lopez Cruz
In-Reply-To: <12D0C12AF19E15409D57F22566E88EF50A813D504E@bgsmsx501.gar.corp.intel.com>
On Fri, Oct 21, 2011 at 04:28:44PM +0530, Babu, Ramesh wrote:
> If it is a board specific requirement, then would it make sense to have it in
> dai_link as per Peter Ujfaulsi's RFC [1].
Possibly for your case - the case this was originally written for was
rather different, the CODEC has issues which mean it always needs to
skip the delay so having to specify this for every single board is going
to be repetitive.
> In general, how this kind of situation is handled?
Usually by keeping the clocks available.
^ permalink raw reply
* Re: [PATCH] sound/soc: keep pointer to resource so it can be freed
From: Mark Brown @ 2011-10-22 9:47 UTC (permalink / raw)
To: Julia Lawall
Cc: alsa-devel, Takashi Iwai, kernel-janitors, linux-kernel,
Liam Girdwood
In-Reply-To: <1318950399-17201-1-git-send-email-julia@diku.dk>
On Tue, Oct 18, 2011 at 05:06:39PM +0200, Julia Lawall wrote:
> From: Julia Lawall <julia@diku.dk>
>
> Add a new variable for storing resources accessed subsequent to the one
> accessed using request_mem_region, so the one accessed using
> request_mem_region can be released if needed.
Applied, thanks.
Please try to match your subject lines with those normally used for the
subsystem.
^ permalink raw reply
* Re: [PATCH] sound/soc: keep pointer to resource so it can be freed
From: Mark Brown @ 2011-10-22 9:47 UTC (permalink / raw)
To: Julia Lawall
Cc: alsa-devel, Takashi Iwai, kernel-janitors, linux-kernel,
Liam Girdwood
In-Reply-To: <1318950399-17201-1-git-send-email-julia@diku.dk>
On Tue, Oct 18, 2011 at 05:06:39PM +0200, Julia Lawall wrote:
> From: Julia Lawall <julia@diku.dk>
>
> Add a new variable for storing resources accessed subsequent to the one
> accessed using request_mem_region, so the one accessed using
> request_mem_region can be released if needed.
Applied, thanks.
Please try to match your subject lines with those normally used for the
subsystem.
^ permalink raw reply
* Re: [PATCH] sound/soc: keep pointer to resource so it can be freed
From: Mark Brown @ 2011-10-22 9:47 UTC (permalink / raw)
To: Julia Lawall
Cc: Liam Girdwood, kernel-janitors, Jaroslav Kysela, Takashi Iwai,
alsa-devel, linux-kernel
In-Reply-To: <1318950399-17201-1-git-send-email-julia@diku.dk>
On Tue, Oct 18, 2011 at 05:06:39PM +0200, Julia Lawall wrote:
> From: Julia Lawall <julia@diku.dk>
>
> Add a new variable for storing resources accessed subsequent to the one
> accessed using request_mem_region, so the one accessed using
> request_mem_region can be released if needed.
Applied, thanks.
Please try to match your subject lines with those normally used for the
subsystem.
^ permalink raw reply
* Re: [RFD] Isolated memory cgroups again
From: Michal Hocko @ 2011-10-22 9:47 UTC (permalink / raw)
To: Glauber Costa
Cc: Ying Han, linux-mm, LKML, Johannes Weiner, KAMEZAWA Hiroyuki,
Daisuke Nishimura, Hugh Dickins, Andrew Morton, Kir Kolyshkin,
Pavel Emelianov, GregThelen, pjt@google.com, Tim Hockin,
Dave Hansen, Paul Menage, James Bottomley
In-Reply-To: <4EA12FBA.7090700@parallels.com>
On Fri 21-10-11 12:39:22, Glauber Costa wrote:
> On 10/21/2011 03:41 AM, Ying Han wrote:
> >On Wed, Oct 19, 2011 at 6:33 PM, Michal Hocko<mhocko@suse.cz> wrote:
[...]
> >>TODO
[...]
> >>- is bool sufficient. Don't we rather want something like priority
> >> instead?
[...]
> >Hi Michal:
> >
> >I didn't read through the patch itself but only the description. If we
> >wanna protect a memcg being reclaimed from under global memory
> >pressure, I think we can approach it by making change on soft_limit
> >reclaim.
> >
> >I have a soft_limit change built on top of Johannes's patchset, which
> >does basically soft_limit aware reclaim under global memory pressure.
> >The implementation is simple, and I am looking forward to discuss more
> >with you guys in the conference.
> >
> >--Ying
> I don't think soft limits will help his case, if I know understand
> it correctly. Global reclaim can be triggered regardless of any soft
> limits we may set.
>
> Now, there are two things I still don't like about it:
> * The definition of a "main workload", "main cgroup", or anything
> like that.
This was just because I wanted to point out the particular case that I
am interested in. You can of course setup more cgroups to be isolated
and balance them by the soft limit.
> I'd prefer to rank them according to some parameter,
> something akin to swapiness. This would allow for other people to
> use it in a different way, while still making you capable of
> reaching your goals through parameter settings (i.e. one cgroup has
> a high value of reclaim, all others, a much lower one)
Yes, this has been mentioned in the patch TODO section (above). I wanted
the first post to be as easy as possible for the discussion starter. I
guess that we really need something like priority in fact.
>
> * The fact that you seem to want to *skip* reclaim altogether for a
> cgroup. That's a dangerous condition, IMHO. What I think we should
> try to achieve, is "skip it for practical purposes on sane
> workloads".
Yes the feature might be dangerous (we provide many ways to shoot self
toes already ;)) but that is what you get if you want to guarantee
something.
But I agree, I guess we can be more clever and if it is priority based
we can map isolation priorities to the reclaim priorities somehow.
> Again, a parameter that when set to a very high mark, has the effect
> of disallowing reclaim for a cgroup under most sane circumstances.
>
> What do you think of the above, Michal ?
Yes I guess that priority based isolation is the way to go. We should,
however, start with a consensus in this regard (should we do something
like that at all?).
Thanks
--
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
^ 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.