RE: [PATCHv1 5/8] ASoC: sgtl5000: Revise the bugs about the sgt15000 codec.
@@ -883,14 +883,19 @@ static int ldo_regulator_register(struct
snd_soc_codec *codec,
struct regulator_init_data *init_data,
int voltage)
{
+#ifdef CONFIG_SND_SOC_FSL_SGTL5000
+ return 0;
+#else
dev_err(codec-dev, this setup needs regulator support in the
kernel\n);
return -EINVAL;
+#endif
}
If these systems don't actually need the internal regulator then should
they not be trying to enable it?
Yes, I think do not trying to enable the regulator is much better.
Alternatively if it's OK to ignore this then why is this conditional in the
board?
The CONFIG_SND_SOC_FSL_SGTL5000 micro maybe confuse you and others.
And it should be CONFIG_SND_SOC_FSL_SGTL5000_VF610
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
+static struct snd_pcm_hardware snd_fsl_hardware = {
+ .info = SNDRV_PCM_INFO_INTERLEAVED |
+ SNDRV_PCM_INFO_BLOCK_TRANSFER |
+ SNDRV_PCM_INFO_MMAP |
+ SNDRV_PCM_INFO_MMAP_VALID |
+ SNDRV_PCM_INFO_PAUSE |
+ SNDRV_PCM_INFO_RESUME,
+ .formats = SNDRV_PCM_FMTBIT_S16_LE,
+ .rate_min = 8000,
+ .channels_min = 2,
+ .channels_max = 2,
+ .buffer_bytes_max = FSL_SAI_DMABUF_SIZE,
+ .period_bytes_min = 4096,
+ .period_bytes_max = FSL_SAI_DMABUF_SIZE / TCD_NUMBER,
+ .periods_min = TCD_NUMBER,
+ .periods_max = TCD_NUMBER,
+ .fifo_size = 0,
+};
There's a patch in -next that lets the generic dmaengine code figure out
some settings from the dmacontroller rather than requiring the driver to
explicitly provide configuration - it's ASoC: dmaengine-pcm: Provide
default config. Please update your driver to use this, or let's work
out what it doesn't do any try to fix it.
I will do a research.
+ ret = fsl_sai_set_dai_sysclk_tr(cpu_dai, clk_id, freq,
+ FSL_FMT_TRANSMITTER);
+ if (ret) {
+ dev_err(cpu_dai-dev,
+ Cannot set sai's transmitter sysclk: %d\n,
+ ret);
+ return ret;
+ }
+
+ ret = fsl_sai_set_dai_sysclk_tr(cpu_dai, clk_id, freq,
+ FSL_FMT_RECEIVER);
As other people have commented these should be exposed as separate clocks
rather than set in sync, unless there's some hardware reason they need to
be identical. If that is the case then a comment explaining the
limitation would be good.
Similarly with several of the other functions.
As I have replied before, there is one function couldn't be separated for the
hardware limitation.
+int fsl_sai_dai_remove(struct snd_soc_dai *dai) {
+ struct fsl_sai *sai = dev_get_drvdata(dai-dev);
+
+ clk_disable_unprepare(sai-clk);
It'd be a bit nicer to only enable the clock while the driver is actively
being used rather than all the time the system is powered up but it's not
a blocker for merge.
Actully there are to XXX_probe functions and two XXX_remove functions:
fsl_sai_dai_probe() and fsl_sai_dai_remove() are callbacks of the ASoC
subsystem.
And in fsl_sai_dai_probe() needs to read/write the SAI controller's registers,
so
the clk_enable_prepare() must be here and clk_disable_unprepare() in
fsl_sai_dai_remove().
fsl_sai_probe() and fsl_sai_remove() are the driver's probe and remove
interfaces.
So the + clk_disable_unprepare(sai-clk); sentence in fsl_sai_remove()
will be removed later.
+ ret = snd_soc_register_component(pdev-dev, fsl_component,
+ fsl_sai_dai, 1);
+ if (ret)
+ return ret;
There's a devm_snd_soc_register_component() in -next, please use that.
See the next version.
+
+ ret = fsl_pcm_dma_init(pdev);
+ if (ret)
+ goto out;
+
+ platform_set_drvdata(pdev, sai);
These should go before the driver is registered with the subsystem
otherwise you've got a race where something might try to use the driver
before init is finished.
+static int fsl_sai_remove(struct platform_device *pdev) {
+ struct fsl_sai *sai = platform_get_drvdata(pdev);
+
+ fsl_pcm_dma_exit(pdev);
+
+ snd_soc_unregister_component(pdev-dev);
Similarly here, unregister from the subsystem then clean up after.
See the next version.
+#define SAI_CR5_FBT(x) ((x) 8)
+#define SAI_CR5_FBT_MASK (0x1f 8)
+
+/* SAI audio dividers */
+#define FSL_SAI_TX_DIV 0
+#define FSL_SAI_RX_DIV 1
Make the namespacing consistent please - for preference use FSL_SAI
always.
See the next version.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the dt-rh tree
Hi Rob, After merging the dt-rh tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: arch/powerpc/platforms/powernv/rng.c: In function 'rng_init_per_cpu': arch/powerpc/platforms/powernv/rng.c:64:2: error: implicit declaration of function 'of_get_ibm_chip_id' [-Werror=implicit-function-declaration] chip_id = of_get_ibm_chip_id(dn); ^ arch/powerpc/platforms/powernv/rng.c: In function 'rng_create': arch/powerpc/platforms/powernv/rng.c:85:2: error: implicit declaration of function 'of_iomap' [-Werror=implicit-function-declaration] rng-regs = of_iomap(dn, 0); ^ arch/powerpc/platforms/powernv/rng.c:85:12: error: assignment makes pointer from integer without a cast [-Werror] rng-regs = of_iomap(dn, 0); ^ Caused by commit a4da0d50b2a0 (powerpc: Implement arch_get_random_long/int() for powernv) from the powerpc tree interacting with commit b5b4bb3f6a11 (of: only include prom.h on sparc) from the dt-rh tree. I added this merge fix patch (which will need to be sent to Linus when these two trees get merged, or could be applied now to the powerpc tree): From: Stephen Rothwell s...@canb.auug.org.au Date: Mon, 28 Oct 2013 19:34:41 +1100 Subject: [PATCH] powerpc: add include of prom.h to fix powernv/rng.c build Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- arch/powerpc/platforms/powernv/rng.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/platforms/powernv/rng.c b/arch/powerpc/platforms/powernv/rng.c index 02db7d73cf8b..483b06640efb 100644 --- a/arch/powerpc/platforms/powernv/rng.c +++ b/arch/powerpc/platforms/powernv/rng.c @@ -11,10 +11,12 @@ #include linux/kernel.h #include linux/of.h +#include linux/of_address.h #include linux/of_platform.h #include linux/slab.h #include asm/archrandom.h #include asm/io.h +#include asm/prom.h #include asm/machdep.h -- 1.8.4.rc3 -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp_LY3Q_v9MN.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: perf events ring buffer memory barrier on powerpc
On Sun, Oct 27, 2013 at 11:00:33AM +0200, Victor Kaplansky wrote: Peter Zijlstra pet...@infradead.org wrote on 10/25/2013 07:37:49 PM: I would argue for: READ -data_tail READ -data_head smp_rmb() (A) smp_rmb() (C) WRITE $data READ $data smp_wmb() (B) smp_mb() (D) STORE -data_headWRITE -data_tail Where A pairs with D, and B pairs with C. 1. I agree. My only concern is that architectures which do use atomic operations with memory barriers, will issue two consecutive barriers now, which is sub-optimal. Yeah, although that would be fairly easy to optimize by the CPUs itself; not sure they actually do this though. But we don't really have much choice aside of introducing things like: smp_wmb__after_local_$op; and I'm fairly sure people won't like adding a ton of conditional barriers like that either. 2. I think the comment in include/linux/perf_event.h describing data_head and data_tail for user space need an update as well. Current version - Oh, indeed. Thanks; I'll update that too! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: perf events ring buffer memory barrier on powerpc
2013/10/25 Peter Zijlstra pet...@infradead.org: On Wed, Oct 23, 2013 at 03:19:51PM +0100, Frederic Weisbecker wrote: I would argue for: READ -data_tail READ -data_head smp_rmb() (A) smp_rmb() (C) WRITE $data READ $data smp_wmb() (B) smp_mb()(D) STORE -data_head WRITE -data_tail Where A pairs with D, and B pairs with C. I don't think A needs to be a full barrier because we won't in fact write data until we see the store from userspace. So we simply don't issue the data WRITE until we observe it. OTOH, D needs to be a full barrier since it separates the data READ from the tail WRITE. For B a WMB is sufficient since it separates two WRITEs, and for C an RMB is sufficient since it separates two READs. Hmm, I need to defer on you for that, I'm not yet comfortable with picking specific barrier flavours when both write and read are involved in a same side :) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] ADB_PMU_LED_IDE selects LEDS_TRIGGER_IDE_DISK which has unmet direct dependencies
Hi, for quite some time the following is printed (twice) after doing make oldconfig: [...] scripts/kconfig/conf --oldconfig Kconfig warning: (ADB_PMU_LED_IDE) selects LEDS_TRIGGER_IDE_DISK which has unmet direct dependencies (NEW_LEDS IDE_GD_ATA LEDS_TRIGGERS) warning: (ADB_PMU_LED_IDE) selects LEDS_TRIGGER_IDE_DISK which has unmet direct dependencies (NEW_LEDS IDE_GD_ATA LEDS_TRIGGERS) I never got around to look into this. But I remember that (when I still had CONFIG_IDE selected, because CONFIG_PATA_MACIO was not working for my PowerBook G5), I always had ADB_PMU_LED_IDE selected, so this option was carried over to my current config. When doing make menuconfig with this generated config I could see that all 3 necessary options are selected: Support for PMU based PowerMacs CONFIG_ADB_PMU Support for the Power/iBook front LED CONFIG_ADB_PMU_LED Use front LED as IDE LED by default CONFIG_ADB_PMU_LED_IDE And CONFIG_ADB_PMU_LED_IDE selects CONFIG_LEDS_TRIGGER_IDE_DISK, which in turn depends on CONFIG_IDE_GD_ATA - but in make menuconfig I could still *unselect* CONFIG_IDE (since I'm using CONFIG_PATA_MACIO) and the 3 options above were still available. I guess make oldconfig noticed that and hence printed the warning above. The following patch causes ADB_PMU_LED to depend on IDE_GD_ATA, so that the options above are only available when IDE_GD_ATA is actually selected and thus eliminates the warning. Signed-off-by: Christian Kujau li...@nerdbynature.de diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig index 696238b..f30ac9d 100644 --- a/drivers/macintosh/Kconfig +++ b/drivers/macintosh/Kconfig @@ -90,6 +90,7 @@ config ADB_PMU config ADB_PMU_LED bool Support for the Power/iBook front LED depends on ADB_PMU + depends on IDE_GD_ATA select NEW_LEDS select LEDS_CLASS help Being a kbuild n00b, I don't know if this is the correct approach though. After looking through the archives I found that this has been reported by Geert back in 2012 already: https://lkml.org/lkml/2012/3/13/556 Thanks, Christian. -- BOFH excuse #186: permission denied ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: perf events ring buffer memory barrier on powerpc
From: Frederic Weisbecker fweis...@gmail.com 2013/10/25 Peter Zijlstra pet...@infradead.org: On Wed, Oct 23, 2013 at 03:19:51PM +0100, Frederic Weisbecker wrote: I would argue for READ -data_tail READ -data_head smp_rmb() (A) smp_rmb() (C) WRITE $data READ $data smp_wmb() (B) smp_mb()(D) STORE -data_head WRITE -data_tail Where A pairs with D, and B pairs with C. I don't think A needs to be a full barrier because we won't in fact write data until we see the store from userspace. So we simply don't issue the data WRITE until we observe it. OTOH, D needs to be a full barrier since it separates the data READ from the tail WRITE. For B a WMB is sufficient since it separates two WRITEs, and for C an RMB is sufficient since it separates two READs. Hmm, I need to defer on you for that, I'm not yet comfortable with picking specific barrier flavours when both write and read are involved in a same side :) I think you have a point :) IMO, memory barrier (A) is superfluous. At producer side we need to ensure that WRITE $data is not committed to memory before READ -data_tail had seen a new value and if the old one indicated that there is no enough space for a new entry. All this is already guaranteed by control flow dependancy on single CPU - writes will not be committed to the memory if read value of data_tail doesn't specify enough free space in the ring buffer. Likewise, on consumer side, we can make use of natural data dependency and memory ordering guarantee for single CPU and try to replace smp_mb by a more light-weight smp_rmb: READ -data_tail READ -data_head // ...smp_rmb() (C) WRITE $data READ $data smp_wmb() (B) smp_rmb() (D) READ $header_size STORE -data_head WRITE -data_tail = $old_data_tail + $header_size We ensure that all $data is read before data_tail is written by doing READ $header_size after all other data is read and we rely on natural data dependancy between data_tail write and header_size read. -- Victor ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] warning: symbol value 'm' invalid for MCU_MPC8349EMITX
Hi, during make ppc6xx_defconfig the following happens: HOSTCC scripts/basic/fixdep GEN /usr/local/src/tmp/lnx/Makefile HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf arch/powerpc/configs/ppc6xx_defconfig:74:warning: symbol value 'm' invalid for MCU_MPC8349EMITX Setting CONFIG_MCU_MPC8349EMITX=y in ppc6xx_defconfig makes the warning go away. This too has been reported by Geert Uytterhoeven a long time ago: https://lkml.org/lkml/2011/11/13/11 - I only came across this because I needed a clean defconfig for this Powerbook G5. Signed-off-by: Christian Kujau li...@nerdbynature.de diff --git a/arch/powerpc/configs/ppc6xx_defconfig b/arch/powerpc/configs/ppc6xx_defconfig index 20ebfaf..c2353bf 100644 --- a/arch/powerpc/configs/ppc6xx_defconfig +++ b/arch/powerpc/configs/ppc6xx_defconfig @@ -71,7 +71,7 @@ CONFIG_QUICC_ENGINE=y CONFIG_QE_GPIO=y CONFIG_PPC_BESTCOMM=y CONFIG_GPIO_MPC8XXX=y -CONFIG_MCU_MPC8349EMITX=m +CONFIG_MCU_MPC8349EMITX=y CONFIG_HIGHMEM=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y Christian. -- BOFH excuse #312: incompatible bit-registration operators ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: perf events ring buffer memory barrier on powerpc
On Mon, Oct 28, 2013 at 02:38:29PM +0200, Victor Kaplansky wrote:
2013/10/25 Peter Zijlstra pet...@infradead.org:
On Wed, Oct 23, 2013 at 03:19:51PM +0100, Frederic Weisbecker wrote:
I would argue for
READ -data_tail READ -data_head
smp_rmb() (A) smp_rmb() (C)
WRITE $data READ $data
smp_wmb() (B) smp_mb()(D)
STORE -data_head WRITE -data_tail
Where A pairs with D, and B pairs with C.
I don't think A needs to be a full barrier because we won't in fact
write data until we see the store from userspace. So we simply don't
issue the data WRITE until we observe it.
OTOH, D needs to be a full barrier since it separates the data READ from
the tail WRITE.
For B a WMB is sufficient since it separates two WRITEs, and for C an
RMB is sufficient since it separates two READs.
snip
I think you have a point :) IMO, memory barrier (A) is superfluous.
At producer side we need to ensure that WRITE $data is not committed
to memory before READ -data_tail had seen a new value and if the
old one indicated that there is no enough space for a new entry. All
this is already guaranteed by control flow dependancy on single CPU -
writes will not be committed to the memory if read value of
data_tail doesn't specify enough free space in the ring buffer.
Likewise, on consumer side, we can make use of natural data dependency and
memory ordering guarantee for single CPU and try to replace smp_mb by
a more light-weight smp_rmb:
READ -data_tail READ -data_head
// ...smp_rmb() (C)
WRITE $data READ $data
smp_wmb() (B) smp_rmb() (D)
READ $header_size
STORE -data_head WRITE -data_tail = $old_data_tail +
$header_size
We ensure that all $data is read before data_tail is written by
doing READ $header_size after all other data is read and we rely on
natural data dependancy between data_tail write and header_size
read.
I'm not entirely sure I get the $header_size trickery; need to think
more on that. But yes, I did consider the other one. However, I had
trouble having no pairing barrier for (D).
ISTR something like Alpha being able to miss the update (for a long
while) if you don't issue the RMB.
Lets add Paul and Oleg to the thread; this is getting far more 'fun'
that it should be ;-)
For completeness; below the patch as I had queued it.
---
Subject: perf: Fix perf ring buffer memory ordering
From: Peter Zijlstra pet...@infradead.org
Date: Mon Oct 28 13:55:29 CET 2013
The PPC64 people noticed a missing memory barrier and crufty old
comments in the perf ring buffer code. So update all the comments and
add the missing barrier.
When the architecture implements local_t using atomic_long_t there
will be double barriers issued; but short of introducing more
conditional barrier primitives this is the best we can do.
Cc: an...@samba.org
Cc: b...@kernel.crashing.org
Cc: Mathieu Desnoyers mathieu.desnoy...@polymtl.ca
Cc: mich...@ellerman.id.au
Cc: Paul McKenney paul...@linux.vnet.ibm.com
Cc: Michael Neuling mi...@neuling.org
Cc: Frederic Weisbecker fweis...@gmail.com
Reported-by: Victor Kaplansky vict...@il.ibm.com
Tested-by: Victor Kaplansky vict...@il.ibm.com
Signed-off-by: Peter Zijlstra pet...@infradead.org
Link: http://lkml.kernel.org/r/20131025173749.gg19...@laptop.lan
---
include/uapi/linux/perf_event.h | 12 +++-
kernel/events/ring_buffer.c | 29 ++---
2 files changed, 33 insertions(+), 8 deletions(-)
Index: linux-2.6/include/uapi/linux/perf_event.h
===
--- linux-2.6.orig/include/uapi/linux/perf_event.h
+++ linux-2.6/include/uapi/linux/perf_event.h
@@ -479,13 +479,15 @@ struct perf_event_mmap_page {
/*
* Control data for the mmap() data buffer.
*
-* User-space reading the @data_head value should issue an rmb(), on
-* SMP capable platforms, after reading this value -- see
-* perf_event_wakeup().
+* User-space reading the @data_head value should issue an smp_rmb(),
+* after reading this value.
*
* When the mapping is PROT_WRITE the @data_tail value should be
-* written by userspace to reflect the last read data. In this case
-* the kernel will not over-write unread data.
+* written by userspace to reflect the last read data, after issueing
+* an smp_mb() to separate the data read from the -data_tail store.
+* In this case the kernel will not over-write unread data.
+*
+* See perf_output_put_handle() for the data ordering.
*/
__u64 data_head; /* head in the data section
Re: [PATCH 1/3] sched: Fix nohz_kick_needed to consider the nr_busy of the parent domain's group
On Thu, Oct 24, 2013 at 01:37:38PM +0530, Preeti U Murthy wrote:
kernel/sched/core.c |5 +
kernel/sched/fair.c | 38 --
kernel/sched/sched.h |1 +
3 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c06b8d3..c540392 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5271,6 +5271,7 @@ DEFINE_PER_CPU(struct sched_domain *, sd_llc);
DEFINE_PER_CPU(int, sd_llc_size);
DEFINE_PER_CPU(int, sd_llc_id);
DEFINE_PER_CPU(struct sched_domain *, sd_numa);
+DEFINE_PER_CPU(struct sched_domain *, sd_busy);
static void update_top_cache_domain(int cpu)
{
@@ -5290,6 +5291,10 @@ static void update_top_cache_domain(int cpu)
sd = lowest_flag_domain(cpu, SD_NUMA);
rcu_assign_pointer(per_cpu(sd_numa, cpu), sd);
+
+ sd = highest_flag_domain(cpu, SD_SHARE_PKG_RESOURCES);
+ if (sd)
+ rcu_assign_pointer(per_cpu(sd_busy, cpu), sd-parent);
}
/*
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index e9c9549..f66cfd9 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6515,16 +6515,16 @@ static inline void nohz_balance_exit_idle(int cpu)
static inline void set_cpu_sd_state_busy(void)
{
struct sched_domain *sd;
+ int cpu = smp_processor_id();
rcu_read_lock();
+ sd = rcu_dereference(per_cpu(sd_busy, cpu));
if (!sd || !sd-nohz_idle)
goto unlock;
sd-nohz_idle = 0;
+ atomic_inc(sd-groups-sgp-nr_busy_cpus);
unlock:
rcu_read_unlock();
}
@@ -6532,16 +6532,16 @@ unlock:
void set_cpu_sd_state_idle(void)
{
struct sched_domain *sd;
+ int cpu = smp_processor_id();
rcu_read_lock();
+ sd = rcu_dereference(per_cpu(sd_busy, cpu));
if (!sd || sd-nohz_idle)
goto unlock;
sd-nohz_idle = 1;
+ atomic_dec(sd-groups-sgp-nr_busy_cpus);
unlock:
rcu_read_unlock();
}
Oh nice, that gets rid of the multiple atomics, and it nicely splits
this nohz logic into per topology groups -- now if only we could split
the rest too :-)
@@ -6748,6 +6748,8 @@ static inline int nohz_kick_needed(struct rq *rq, int
cpu)
{
unsigned long now = jiffies;
struct sched_domain *sd;
+ struct sched_group_power *sgp;
+ int nr_busy;
if (unlikely(idle_cpu(cpu)))
return 0;
@@ -6773,22 +6775,22 @@ static inline int nohz_kick_needed(struct rq *rq, int
cpu)
goto need_kick;
rcu_read_lock();
+ sd = rcu_dereference(per_cpu(sd_busy, cpu));
+ if (sd) {
+ sgp = sd-groups-sgp;
+ nr_busy = atomic_read(sgp-nr_busy_cpus);
+ if (nr_busy 1)
goto need_kick_unlock;
}
OK, so far so good.
+
+ sd = highest_flag_domain(cpu, SD_ASYM_PACKING);
+
+ if (sd (cpumask_first_and(nohz.idle_cpus_mask,
+ sched_domain_span(sd)) cpu))
+ goto need_kick_unlock;
+
rcu_read_unlock();
return 0;
This again is a bit sad; most archs will not have SD_ASYM_PACKING set at
all; this means that they all will do a complete (and pointless) sched
domain tree walk here.
It would be much better to also introduce sd_asym and do the analogous
thing to the new sd_busy.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: Move local setup.h declarations to arch includes
* Michael Ellerman (mich...@ellerman.id.au) wrote: On Fri, Oct 25, 2013 at 02:25:07PM -0500, Robert C Jennings wrote: Move the few declarations from arch/powerpc/kernel/setup.h into arch/powerpc/include/asm/setup.h. This resolves a sparse warning for arch/powerpc/mm/numa.c which defines do_init_bootmem() but can't include the setup.h header in the prior path. Resolves: arch/powerpc/mm/numa.c:998:13: warning: symbol 'do_init_bootmem' was not declared. Should it be static? There's always a tension between too many well-focused-micro-headers, and too few random-piles-of-junk headers. I tend towards the former, but in this case I think you're right to drop setup.h. diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h index d3ca855..5e24df0 100644 --- a/arch/powerpc/include/asm/setup.h +++ b/arch/powerpc/include/asm/setup.h @@ -23,6 +23,11 @@ extern void reloc_got2(unsigned long); #define PTRRELOC(x)((typeof(x)) add_reloc_offset((unsigned long)(x))) +extern void check_for_initrd(void); +extern void do_init_bootmem(void); +extern void setup_panic(void); +extern int do_early_xmon; I don't see do_early_xmon used anywhere? Looks like I forgot to clean it up in 47679283. Mind dropping it? I think these days it's trendy to not use extern in headers. cheers I'll clean that up and send again. -Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 1/2] powerpc: Fix warnings for arch/powerpc/mm/numa.c
Simple fixes for sparse warnings in this file.
Resolves:
arch/powerpc/mm/numa.c:198:24:
warning: Using plain integer as NULL pointer
arch/powerpc/mm/numa.c:1157:5:
warning: symbol 'hot_add_node_scn_to_nid' was not declared.
Should it be static?
arch/powerpc/mm/numa.c:1238:28:
warning: Using plain integer as NULL pointer
arch/powerpc/mm/numa.c:1538:6:
warning: symbol 'topology_schedule_update' was not declared.
Should it be static?
Signed-off-by: Robert C Jennings r...@linux.vnet.ibm.com
---
v1 - v2: No changes in this patch
---
arch/powerpc/mm/numa.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index c916127..33d6784 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -195,7 +195,7 @@ static const __be32 *of_get_usable_memory(struct
device_node *memory)
u32 len;
prop = of_get_property(memory, linux,drconf-usable-memory, len);
if (!prop || len sizeof(unsigned int))
- return 0;
+ return NULL;
return prop;
}
@@ -1154,7 +1154,7 @@ static int hot_add_drconf_scn_to_nid(struct device_node
*memory,
* represented in the device tree as a node (i.e. memory@) for
* each memblock.
*/
-int hot_add_node_scn_to_nid(unsigned long scn_addr)
+static int hot_add_node_scn_to_nid(unsigned long scn_addr)
{
struct device_node *memory;
int nid = -1;
@@ -1235,7 +1235,7 @@ static u64 hot_add_drconf_memory_max(void)
struct device_node *memory = NULL;
unsigned int drconf_cell_cnt = 0;
u64 lmb_size = 0;
- const __be32 *dm = 0;
+ const __be32 *dm = NULL;
memory = of_find_node_by_path(/ibm,dynamic-reconfiguration-memory);
if (memory) {
@@ -1535,7 +1535,7 @@ static void topology_work_fn(struct work_struct *work)
}
static DECLARE_WORK(topology_work, topology_work_fn);
-void topology_schedule_update(void)
+static void topology_schedule_update(void)
{
schedule_work(topology_work);
}
--
1.8.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 0/2] powerpc: Sparse fixes for numa.c
Cleaning out some stashed fixes for sparse warnings found while working on 3be7db6: (powerpc: VPHN topology change updates all siblings) I don't see a reason why the declarations in arch/powerpc/kernel/setup.h can't live in arch/powerpc/include/asm/setup.h and .../mm/numa.c should include these definitions. Robert C Jennings (2): powerpc: Fix warnings for arch/powerpc/mm/numa.c powerpc: Move local setup.h declarations to arch includes arch/powerpc/include/asm/setup.h | 4 arch/powerpc/kernel/module.c | 3 +-- arch/powerpc/kernel/module_32.c| 3 +-- arch/powerpc/kernel/module_64.c| 3 +-- arch/powerpc/kernel/setup-common.c | 2 -- arch/powerpc/kernel/setup.h| 9 - arch/powerpc/kernel/setup_32.c | 2 -- arch/powerpc/kernel/setup_64.c | 2 -- arch/powerpc/kernel/vdso.c | 3 +-- arch/powerpc/mm/numa.c | 8 10 files changed, 12 insertions(+), 27 deletions(-) delete mode 100644 arch/powerpc/kernel/setup.h -- 1.8.1.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 2/2] powerpc: Move local setup.h declarations to arch includes
Move the few declarations from arch/powerpc/kernel/setup.h into arch/powerpc/include/asm/setup.h. This resolves a sparse warning for arch/powerpc/mm/numa.c which defines do_init_bootmem() but can't include the setup.h header in the prior path. Resolves: arch/powerpc/mm/numa.c:998:13: warning: symbol 'do_init_bootmem' was not declared. Should it be static? Signed-off-by: Robert C Jennings r...@linux.vnet.ibm.com --- v1 - v2: Removed do_early_xmon (unused since 47679283) Removed 'extern' keyword --- arch/powerpc/include/asm/setup.h | 4 arch/powerpc/kernel/module.c | 3 +-- arch/powerpc/kernel/module_32.c| 3 +-- arch/powerpc/kernel/module_64.c| 3 +-- arch/powerpc/kernel/setup-common.c | 2 -- arch/powerpc/kernel/setup.h| 9 - arch/powerpc/kernel/setup_32.c | 2 -- arch/powerpc/kernel/setup_64.c | 2 -- arch/powerpc/kernel/vdso.c | 3 +-- 9 files changed, 8 insertions(+), 23 deletions(-) delete mode 100644 arch/powerpc/kernel/setup.h diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h index d3ca855..703a841 100644 --- a/arch/powerpc/include/asm/setup.h +++ b/arch/powerpc/include/asm/setup.h @@ -23,6 +23,10 @@ extern void reloc_got2(unsigned long); #define PTRRELOC(x)((typeof(x)) add_reloc_offset((unsigned long)(x))) +void check_for_initrd(void); +void do_init_bootmem(void); +void setup_panic(void); + #endif /* !__ASSEMBLY__ */ #endif /* _ASM_POWERPC_SETUP_H */ diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c index 2d27570..9547381 100644 --- a/arch/powerpc/kernel/module.c +++ b/arch/powerpc/kernel/module.c @@ -25,8 +25,7 @@ #include asm/uaccess.h #include asm/firmware.h #include linux/sort.h - -#include setup.h +#include asm/setup.h LIST_HEAD(module_bug_list); diff --git a/arch/powerpc/kernel/module_32.c b/arch/powerpc/kernel/module_32.c index 2e3200c..6cff040 100644 --- a/arch/powerpc/kernel/module_32.c +++ b/arch/powerpc/kernel/module_32.c @@ -26,8 +26,7 @@ #include linux/cache.h #include linux/bug.h #include linux/sort.h - -#include setup.h +#include asm/setup.h #if 0 #define DEBUGP printk diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c index a102f44..12664c1 100644 --- a/arch/powerpc/kernel/module_64.c +++ b/arch/powerpc/kernel/module_64.c @@ -26,8 +26,7 @@ #include asm/firmware.h #include asm/code-patching.h #include linux/sort.h - -#include setup.h +#include asm/setup.h /* FIXME: We don't do .init separately. To do this, we'd need to have a separate r2 value in the init and core section, and stub between diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c index 3d261c0..febc804 100644 --- a/arch/powerpc/kernel/setup-common.c +++ b/arch/powerpc/kernel/setup-common.c @@ -62,8 +62,6 @@ #include mm/mmu_decl.h #include asm/fadump.h -#include setup.h - #ifdef DEBUG #include asm/udbg.h #define DBG(fmt...) udbg_printf(fmt) diff --git a/arch/powerpc/kernel/setup.h b/arch/powerpc/kernel/setup.h deleted file mode 100644 index 4c67ad7..000 --- a/arch/powerpc/kernel/setup.h +++ /dev/null @@ -1,9 +0,0 @@ -#ifndef _POWERPC_KERNEL_SETUP_H -#define _POWERPC_KERNEL_SETUP_H - -void check_for_initrd(void); -void do_init_bootmem(void); -void setup_panic(void); -extern int do_early_xmon; - -#endif /* _POWERPC_KERNEL_SETUP_H */ diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c index a4bbcae..b903dc5 100644 --- a/arch/powerpc/kernel/setup_32.c +++ b/arch/powerpc/kernel/setup_32.c @@ -40,8 +40,6 @@ #include asm/mmu_context.h #include asm/epapr_hcalls.h -#include setup.h - #define DBG(fmt...) extern void bootx_init(unsigned long r4, unsigned long phys); diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c index 278ca93..4085aaa 100644 --- a/arch/powerpc/kernel/setup_64.c +++ b/arch/powerpc/kernel/setup_64.c @@ -68,8 +68,6 @@ #include asm/hugetlb.h #include asm/epapr_hcalls.h -#include setup.h - #ifdef DEBUG #define DBG(fmt...) udbg_printf(fmt) #else diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c index 1d9c926..094e45c 100644 --- a/arch/powerpc/kernel/vdso.c +++ b/arch/powerpc/kernel/vdso.c @@ -34,8 +34,7 @@ #include asm/firmware.h #include asm/vdso.h #include asm/vdso_datapage.h - -#include setup.h +#include asm/setup.h #undef DEBUG -- 1.8.1.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] sched: Aggressive balance in domains whose groups share package resources
On Mon, Oct 21, 2013 at 05:15:02PM +0530, Vaidyanathan Srinivasan wrote: From: Preeti U Murthy pre...@linux.vnet.ibm.com The current logic in load balance is such that after picking the busiest group, the load is attempted to be moved from the busiest cpu in that group to the dst_cpu. If the load cannot be moved from the busiest cpu to dst_cpu due to either tsk_cpus_allowed mask or cache hot tasks, then the dst_cpu is changed to be another idle cpu within the dst-grpmask. If even then, the load cannot be moved from the busiest cpu, then the source group is changed. The next busiest group is found and the above steps are repeated. However if the cpus in the group share package resources, then when a load movement from the busiest cpu in this group fails as above, instead of finding the next busiest group to move load from, find the next busiest cpu *within the same group* from which to move load away. By doing so, a conscious effort is made during load balancing to keep just one cpu busy as much as possible within domains that have SHARED_PKG_RESOURCES flag set unless under scenarios of high load. Having multiple cpus busy within a domain which share package resource could lead to a performance hit. A similar scenario arises in active load balancing as well. When the current task on the busiest cpu cannot be moved away due to task pinning, currently no more attempts at load balancing is made. This patch checks if the balancing is being done on a group whose cpus share package resources. If so, then check if the load balancing can be done for other cpus in the same group. So I absolutely hate this patch... Also I'm not convinced I actually understand the explanation above. Furthermore; there is nothing special about spreading tasks for SHARED_PKG_RESOURCES and special casing that one case is just wrong. If anything it should be keyed off of SD_PREFER_SIBLING and or cpu_power. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: perf events ring buffer memory barrier on powerpc
On Mon, Oct 28, 2013 at 02:26:34PM +0100, Peter Zijlstra wrote:
On Mon, Oct 28, 2013 at 02:38:29PM +0200, Victor Kaplansky wrote:
2013/10/25 Peter Zijlstra pet...@infradead.org:
On Wed, Oct 23, 2013 at 03:19:51PM +0100, Frederic Weisbecker wrote:
I would argue for
READ -data_tail READ -data_head
smp_rmb() (A) smp_rmb() (C)
WRITE $data READ $data
smp_wmb() (B) smp_mb()(D)
STORE -data_head WRITE -data_tail
Where A pairs with D, and B pairs with C.
I don't think A needs to be a full barrier because we won't in fact
write data until we see the store from userspace. So we simply don't
issue the data WRITE until we observe it.
OTOH, D needs to be a full barrier since it separates the data READ from
the tail WRITE.
For B a WMB is sufficient since it separates two WRITEs, and for C an
RMB is sufficient since it separates two READs.
snip
I think you have a point :) IMO, memory barrier (A) is superfluous.
At producer side we need to ensure that WRITE $data is not committed
to memory before READ -data_tail had seen a new value and if the
old one indicated that there is no enough space for a new entry. All
this is already guaranteed by control flow dependancy on single CPU -
writes will not be committed to the memory if read value of
data_tail doesn't specify enough free space in the ring buffer.
Likewise, on consumer side, we can make use of natural data dependency and
memory ordering guarantee for single CPU and try to replace smp_mb by
a more light-weight smp_rmb:
READ -data_tail READ -data_head
// ...smp_rmb() (C)
WRITE $data READ $data
smp_wmb() (B) smp_rmb() (D)
READ $header_size
STORE -data_head WRITE -data_tail = $old_data_tail +
$header_size
We ensure that all $data is read before data_tail is written by
doing READ $header_size after all other data is read and we rely on
natural data dependancy between data_tail write and header_size
read.
I'm not entirely sure I get the $header_size trickery; need to think
more on that. But yes, I did consider the other one. However, I had
trouble having no pairing barrier for (D).
ISTR something like Alpha being able to miss the update (for a long
while) if you don't issue the RMB.
Lets add Paul and Oleg to the thread; this is getting far more 'fun'
that it should be ;-)
For completeness; below the patch as I had queued it.
---
Subject: perf: Fix perf ring buffer memory ordering
From: Peter Zijlstra pet...@infradead.org
Date: Mon Oct 28 13:55:29 CET 2013
The PPC64 people noticed a missing memory barrier and crufty old
comments in the perf ring buffer code. So update all the comments and
add the missing barrier.
When the architecture implements local_t using atomic_long_t there
will be double barriers issued; but short of introducing more
conditional barrier primitives this is the best we can do.
Cc: an...@samba.org
Cc: b...@kernel.crashing.org
Cc: Mathieu Desnoyers mathieu.desnoy...@polymtl.ca
Cc: mich...@ellerman.id.au
Cc: Paul McKenney paul...@linux.vnet.ibm.com
Cc: Michael Neuling mi...@neuling.org
Cc: Frederic Weisbecker fweis...@gmail.com
Reported-by: Victor Kaplansky vict...@il.ibm.com
Tested-by: Victor Kaplansky vict...@il.ibm.com
Signed-off-by: Peter Zijlstra pet...@infradead.org
Link: http://lkml.kernel.org/r/20131025173749.gg19...@laptop.lan
---
include/uapi/linux/perf_event.h | 12 +++-
kernel/events/ring_buffer.c | 29 ++---
2 files changed, 33 insertions(+), 8 deletions(-)
Index: linux-2.6/include/uapi/linux/perf_event.h
===
--- linux-2.6.orig/include/uapi/linux/perf_event.h
+++ linux-2.6/include/uapi/linux/perf_event.h
@@ -479,13 +479,15 @@ struct perf_event_mmap_page {
/*
* Control data for the mmap() data buffer.
*
- * User-space reading the @data_head value should issue an rmb(), on
- * SMP capable platforms, after reading this value -- see
- * perf_event_wakeup().
+ * User-space reading the @data_head value should issue an smp_rmb(),
+ * after reading this value.
*
* When the mapping is PROT_WRITE the @data_tail value should be
- * written by userspace to reflect the last read data. In this case
- * the kernel will not over-write unread data.
+ * written by userspace to reflect the last read data, after issueing
+ * an smp_mb() to separate the data read from the -data_tail store.
+ * In this case the kernel will not over-write unread data.
+ *
Re: [PATCH] [RFC] Emulate lwsync to run standard user land on e500 cores
On Fri, 2013-10-25 at 10:25 -0500, James Yang wrote: On Fri, 25 Oct 2013, Scott Wood wrote: Has anyone measured how much this slows things down with a typical userspace? Not a measurement of the patch in question but an older similar patch on 3.0.51 (8572 running Debian 5.0.3): $ ./test-lwsync cycles per emulated lwsync = 371 cycles per sync = 36 My point was more to find out how often a typical userspace executes these instructions. From Wolfgang's e-mail it seems the answer is not very often. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: perf events ring buffer memory barrier on powerpc
On 10/28, Peter Zijlstra wrote:
Lets add Paul and Oleg to the thread; this is getting far more 'fun'
that it should be ;-)
Heh. All I can say is that I would like to see the authoritative answer,
you know who can shed a light ;)
But to avoid the confusion, wmb() added by this patch looks obviously
correct to me.
+ * Since the mmap() consumer (userspace) can run on a different CPU:
+ *
+ * kernel user
+ *
+ * READ -data_tail READ -data_head
+ * smp_rmb() (A) smp_rmb() (C)
+ * WRITE $dataREAD $data
+ * smp_wmb() (B) smp_mb()(D)
+ * STORE -data_head WRITE -data_tail
+ *
+ * Where A pairs with D, and B pairs with C.
+ *
+ * I don't think A needs to be a full barrier because we won't in fact
+ * write data until we see the store from userspace.
this matches the intuition, but ...
So we simply don't
+ * issue the data WRITE until we observe it.
why do we need any barrier (rmb) then? how it can help to serialize with
WRITE $data ?
(of course there could be other reasons for this rmb(), just I can't
really understand A pairs with D).
And this reminds me about the memory barrier in kfifo.c which I was not
able to understand. Hmm, it has already gone away, and now I do not
understand kfifo.c at all ;) But I have found the commit, attached below.
Note that that commit added the full barrier into __kfifo_put(). And to
me it looks the same as A above. Following the logic above we could say
that we do not need a barrier (at least the full one), we won't in fact
write into the unread area until we see the store to -out from
__kfifo_get() ?
In short. I am confused, I _feel_ that A has to be a full barrier, but
I can't prove this. And let me suggest the artificial/simplified example,
boolBUSY;
data_t DATA;
bool try_to_get(data_t *data)
{
if (!BUSY)
return false;
rmb();
*data = DATA;
mb();
BUSY = false;
return true;
}
bool try_to_put(data_t *data)
{
if (BUSY)
return false;
mb(); // : do we really need it? I think yes.
DATA = *data;
wmb();
BUSY = true;
return true;
}
Again, following the description above we could turn the mb() in _put()
into barrier(), but I do not think we can rely on the contorl dependency.
Oleg.
---
commit a45bce49545739a940f8bd4ca85c3b7435564893
Author: Paul E. McKenney paul...@us.ibm.com
Date: Fri Sep 29 02:00:11 2006 -0700
[PATCH] memory ordering in __kfifo primitives
Both __kfifo_put() and __kfifo_get() have header comments stating that if
there is but one concurrent reader and one concurrent writer, locking is not
necessary. This is almost the case, but a couple of memory barriers are
needed. Another option would be to change the header comments to remove the
bit about locking not being needed, and to change the those callers who
currently don't use locking to add the required locking. The attachment
analyzes this approach, but the patch below seems simpler.
Signed-off-by: Paul E. McKenney paul...@us.ibm.com
Cc: Stelian Pop stel...@popies.net
Signed-off-by: Andrew Morton a...@osdl.org
Signed-off-by: Linus Torvalds torva...@osdl.org
diff --git a/kernel/kfifo.c b/kernel/kfifo.c
index 64ab045..5d1d907 100644
--- a/kernel/kfifo.c
+++ b/kernel/kfifo.c
@@ -122,6 +122,13 @@ unsigned int __kfifo_put(struct kfifo *fifo,
len = min(len, fifo-size - fifo-in + fifo-out);
+ /*
+* Ensure that we sample the fifo-out index -before- we
+* start putting bytes into the kfifo.
+*/
+
+ smp_mb();
+
/* first put the data starting from fifo-in to buffer end */
l = min(len, fifo-size - (fifo-in (fifo-size - 1)));
memcpy(fifo-buffer + (fifo-in (fifo-size - 1)), buffer, l);
@@ -129,6 +136,13 @@ unsigned int __kfifo_put(struct kfifo *fifo,
/* then put the rest (if any) at the beginning of the buffer */
memcpy(fifo-buffer, buffer + l, len - l);
+ /*
+* Ensure that we add the bytes to the kfifo -before-
+* we update the fifo-in index.
+*/
+
+ smp_wmb();
+
fifo-in += len;
return len;
@@ -154,6 +168,13 @@ unsigned int __kfifo_get(struct kfifo *fifo,
len = min(len, fifo-in - fifo-out);
+ /*
+* Ensure that we sample the fifo-in index -before- we
+* start removing bytes from the kfifo.
+*/
+
+ smp_rmb();
+
/* first get the data from fifo-out until the end of the buffer */
l = min(len,
Re: [PATCH 02/12][v3] pci: fsl: add structure fsl_pci
On Fri, 2013-10-25 at 13:58 +0800, Lian Minghuan-b31939 wrote: Hi Kumar, please see my comment inline. On 10/24/2013 12:11 PM, Kumar Gala wrote: On Oct 23, 2013, at 5:41 AM, Minghuan Lian wrote: PowerPC uses structure pci_controller to describe PCI controller, but ARM uses structure pci_sys_data. In order to support PowerPC and ARM simultaneously, the patch adds a structure fsl_pci that contains most of the members of the pci_controller and pci_sys_data. Meanwhile, it defines a interface fsl_arch_sys_to_pci() which should be implemented in architecture-specific PCI controller driver to convert pci_controller or pci_sys_data to fsl_pci. Signed-off-by: Minghuan Lian minghuan.l...@freescale.com --- change log: v1-v3: Derived from http://patchwork.ozlabs.org/patch/278965/ Based on upstream master. Based on the discussion of RFC version here http://patchwork.ozlabs.org/patch/274487/ include/linux/fsl/pci-common.h | 41 + 1 file changed, 41 insertions(+) NAK. We discussed this some at the ARM Summit this week and the feeling is we need to move to a common interface between the various ARCHs. [Minghuan] Do you mean we will use the common interface instead of arch/powerpc/kernel/pci-common.c... and arch/arm/kernel/bios32.c? Who will do the code movement and when will the work be completed? The patches just move the common functions of FSL PCI controller operation which can be re-used by PowerPC and ARM. LS1 is coming, I worry about not having enough time to wait for the move is completed. I agree -- it can take quite a while to get from the feeling is we need to move to a common interface to actually having something we can use. If and when this unification is achieved, we can drop this extra layer. It's a better interim solution than just duplicating the entire driver and letting them drift apart. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Build regressions/improvements in v3.12-rc7
On Mon, 28 Oct 2013, Geert Uytterhoeven wrote:
JFYI, when comparing v3.12-rc7 to v3.12-rc6[3], the summaries are:
- build errors: +9/-10
+ /scratch/kisskb/src/arch/powerpc/kernel/cacheinfo.c: error: 'associativity'
may be used uninitialized in this function [-Werror=uninitialized]: = 575:2
+ /scratch/kisskb/src/arch/powerpc/kernel/cacheinfo.c: error: 'size_kb' may
be used uninitialized in this function [-Werror=uninitialized]: = 526:2
+ /scratch/kisskb/src/drivers/tty/serial/nwpserial.c: error: implicit
declaration of function 'udelay' [-Werror=implicit-function-declaration]: =
53:3
powerpc-randconfig
+ /scratch/kisskb/src/drivers/gpu/drm/drm_gem_cma_helper.c: error: implicit
declaration of function 'dma_alloc_writecombine'
[-Werror=implicit-function-declaration]: = 91:2
+ /scratch/kisskb/src/drivers/gpu/drm/drm_gem_cma_helper.c: error: implicit
declaration of function 'dma_free_writecombine'
[-Werror=implicit-function-declaration]: = 176:3
sh-randconfig
[1] http://kisskb.ellerman.id.au/kisskb/head/6819/ (119 out of 120 configs)
[3] http://kisskb.ellerman.id.au/kisskb/head/6796/ (all 120 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: perf events ring buffer memory barrier on powerpc
On 10/28, Paul E. McKenney wrote:
On Mon, Oct 28, 2013 at 02:26:34PM +0100, Peter Zijlstra wrote:
--- linux-2.6.orig/kernel/events/ring_buffer.c
+++ linux-2.6/kernel/events/ring_buffer.c
@@ -87,10 +87,31 @@ static void perf_output_put_handle(struc
goto out;
/*
-* Publish the known good head. Rely on the full barrier implied
-* by atomic_dec_and_test() order the rb-head read and this
-* write.
+* Since the mmap() consumer (userspace) can run on a different CPU:
+*
+* kernel user
+*
+* READ -data_tail READ -data_head
+* smp_rmb() (A) smp_rmb() (C)
Given that both of the kernel's subsequent operations are stores/writes,
doesn't (A) need to be smp_mb()?
Yes, this is my understanding^Wfeeling too, but I have to admit that
I can't really explain to myself why _exactly_ we need mb() here.
And let me copy-and-paste the artificial example from my previous
email,
boolBUSY;
data_t DATA;
bool try_to_get(data_t *data)
{
if (!BUSY)
return false;
rmb();
*data = DATA;
mb();
BUSY = false;
return true;
}
bool try_to_put(data_t *data)
{
if (BUSY)
return false;
mb(); // : do we really need it? I think yes.
DATA = *data;
wmb();
BUSY = true;
return true;
}
(just in case, the code above obviously assumes that _get or _put
can't race with itself, but they can race with each other).
Could you confirm that try_to_put() actually needs mb() between
LOAD(BUSY) and STORE(DATA) ?
I am sure it actually needs, but I will appreciate it if you can
explain why. IOW, how it is possible that without mb() try_to_put()
can overwrite DATA before try_to_get() completes its *data = DATA
in this particular case.
Perhaps this can happen if, say, reader and writer share a level of
cache or something like this...
Oleg.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: perf events ring buffer memory barrier on powerpc
Oleg Nesterov o...@redhat.com wrote on 10/28/2013 10:17:35 PM: mb(); // : do we really need it? I think yes. Oh, it is hard to argue with feelings. Also, it is easy to be on conservative side and put the barrier here just in case. But I still insist that the barrier is redundant in your example. -- Victor ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [tpmdd-devel] Has anyone a ATMEL TPM Chip on PPC64 (CONFIG_TCG_ATMEL)?
On 10/27/2013 05:06 PM, Peter Hüwe wrote: Hi, I was wondering if anyone here on this list still has a machine with an old ATMEL TPM (trusted platform module) lying around? From the kconfig entry it becomes evident that it was only supported on ppc64 machines. config TCG_ATMEL tristate Atmel TPM Interface depends on PPC64 || HAS_IOPORT ---help--- If you have a TPM security chip from Atmel say Yes and it will be accessible from within Linux. To compile this driver as a module, choose M here; the module will be called tpm_atmel. The hardware/driver is pretty old and the driver might have contained a bug that made it unusable for the last 6 years ;) So if anyone still has this kind of hardware around, please reply. As near as I can tell this was on a single machine type (the js21 circa 2006). The firmware on the machine didn't support establishing a root of trust, so use of the TPM was as a practical matter effective only for the other functions like random number generation and key management. The number of users who used the TPM for this on this machine was likely very small 7 years ago. The number of those machines still in service today is likely smaller still. The cross section of those two small numbers combined with those who want to run on a shiny new kernel has to be quickly approaching zero. I reccomend removing the driver. If the stars align and a user actually appears who wants to use one I'll clean up the driver and resubmit it for inclusion. I just don't think that will happen. -Joel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the dt-rh tree
On 10/28/2013 03:38 AM, Stephen Rothwell wrote: Hi Rob, After merging the dt-rh tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: arch/powerpc/platforms/powernv/rng.c: In function 'rng_init_per_cpu': arch/powerpc/platforms/powernv/rng.c:64:2: error: implicit declaration of function 'of_get_ibm_chip_id' [-Werror=implicit-function-declaration] chip_id = of_get_ibm_chip_id(dn); ^ arch/powerpc/platforms/powernv/rng.c: In function 'rng_create': arch/powerpc/platforms/powernv/rng.c:85:2: error: implicit declaration of function 'of_iomap' [-Werror=implicit-function-declaration] rng-regs= of_iomap(dn, 0); ^ arch/powerpc/platforms/powernv/rng.c:85:12: error: assignment makes pointer from integer without a cast [-Werror] rng-regs = of_iomap(dn, 0); ^ Caused by commit a4da0d50b2a0 (powerpc: Implement arch_get_random_long/int() for powernv) from the powerpc tree interacting with commit b5b4bb3f6a11 (of: only include prom.h on sparc) from the dt-rh tree. I added this merge fix patch (which will need to be sent to Linus when these two trees get merged, or could be applied now to the powerpc tree): Applying to the powerpc tree now seems like the better path. From: Stephen Rothwell s...@canb.auug.org.au Date: Mon, 28 Oct 2013 19:34:41 +1100 Subject: [PATCH] powerpc: add include of prom.h to fix powernv/rng.c build Signed-off-by: Stephen Rothwell s...@canb.auug.org.au Acked-by: Rob Herring rob.herr...@calxeda.com Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [tpmdd-devel] Has anyone a ATMEL TPM Chip on PPC64 (CONFIG_TCG_ATMEL)?
Am Dienstag, 29. Oktober 2013, 00:47:45 schrieb Jason Gunthorpe: On Mon, Oct 28, 2013 at 01:03:43PM -0500, Joel Schopp wrote: On 10/27/2013 05:06 PM, Peter H?we wrote: Hi, I was wondering if anyone here on this list still has a machine with an old ATMEL TPM (trusted platform module) lying around? From the kconfig entry it becomes evident that it was only supported on ppc64 machines. config TCG_ATMEL tristate Atmel TPM Interface depends on PPC64 || HAS_IOPORT Hurm, that is crazy, because tpm_atmel.h contains an #else block for !CONFIG_PPC64. The single major source of complexity in this driver is that else block. Argh, sorry my bad. Of course it's available on other archs as well, since it's PPC64 _||_ HAS_IOPORT d'oh - sorry. Peter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [tpmdd-devel] Has anyone a ATMEL TPM Chip on PPC64 (CONFIG_TCG_ATMEL)?
On Mon, Oct 28, 2013 at 01:03:43PM -0500, Joel Schopp wrote:
On 10/27/2013 05:06 PM, Peter H?we wrote:
Hi,
I was wondering if anyone here on this list still has a machine with an old
ATMEL TPM (trusted platform module) lying around?
From the kconfig entry it becomes evident that it was only supported on
ppc64
machines.
config TCG_ATMEL
tristate Atmel TPM Interface
depends on PPC64 || HAS_IOPORT
Hurm, that is crazy, because tpm_atmel.h contains an #else block for
!CONFIG_PPC64. The single major source of complexity in this driver is
that else block.
The driver would be fine, and straightforward if it was a standard,
modern DT enabled driver, which is very easy if PPC64 is the only
supported implementation.
I reccomend removing the driver. If the stars align and a user actually
appears who wants to use one I'll clean up the driver and resubmit it
for inclusion. I just don't think that will happen.
The needed clean up is really easy actually, replace everything below
'tpm_vendor_specific tpm_atmel' with approximately this:
static int atml_probe(struct platform_device *pdev)
{
struct tpm_chip *chip;
struct resrouce *res;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!r)
return -EIO;
if (!(chip = tpm_register_hardware(dev, tpm_atmel)))
return -ENODEV;
chip-iobase = devm_request_and_ioremap(pdev-dev, res);
if (!chip-iobase)
return -ENOMEM;
return 0;
}
static void atml_plat_remove(struct platform_device *pdev)
{
struct tpm_chip *chip = dev_get_drvdata(pdev-dev);
tpm_remove_hardware(chip-dev);
};
static const struct of_device_id platform_match[] = {
{.compatible = AT97SC3201},
{},
};
MODULE_DEVICE_TABLE(of, platform_match);
static SIMPLE_DEV_PM_OPS(tpm_atml_pm, tpm_pm_suspend, tpm_pm_resume);
static struct platform_driver atml_drv = {
.probe = atml_probe,
.remove = atml_plat_remove,
.driver = {
.name = tpm_atmel,
.owner = THIS_MODULE,
.pm = tpm_atml_pm,
.of_match_table = of_match_ptr(platform_match),
},
};
module_platform_driver(atml_drv);
MODULE_AUTHOR(Leendert van Doorn (leend...@watson.ibm.com));
MODULE_DESCRIPTION(TPM Driver);
MODULE_VERSION(2.0);
MODULE_LICENSE(GPL);
If you guys can convice yourselves that doesn't obviously break anything I can
probably send a proper patch.
Jason
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [5/7] powerpc/corenet64_smp_defconfig: Enable most SPI splash
On Fri, Sep 06, 2013 at 08:43:17AM -0700, York Sun wrote: Enable CONFIG_MTD_M25P80 for corenet64_smp_defconfig. Verified on P5040DS. Signed-off-by: York Sun york...@freescale.com Reviewed-by: Wood Scott-B07421 scottw...@freescale.com Reviewed-by: Fleming Andrew-AFLEMING aflem...@freescale.com Tested-by: Fleming Andrew-AFLEMING aflem...@freescale.com --- arch/powerpc/configs/corenet64_smp_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig index 6c8b020..1ec6f0c 100644 --- a/arch/powerpc/configs/corenet64_smp_defconfig +++ b/arch/powerpc/configs/corenet64_smp_defconfig @@ -66,6 +66,7 @@ CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_CHAR=y CONFIG_MTD_BLKDEVS=y CONFIG_MTD_BLOCK=y +CONFIG_MTD_M25P80=y CONFIG_FTL=y CONFIG_MTD_CFI=y CONFIG_MTD_GEN_PROBE=y This has already been enabled in corenet64_smp_config since commit 478a4829d815865b919c1fa20f0f33543a2291fb, over a year ago. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [5/7] powerpc/corenet64_smp_defconfig: Enable most SPI splash
On 10/28/2013 05:28 PM, Scott Wood wrote: On Fri, Sep 06, 2013 at 08:43:17AM -0700, York Sun wrote: Enable CONFIG_MTD_M25P80 for corenet64_smp_defconfig. Verified on P5040DS. Signed-off-by: York Sun york...@freescale.com Reviewed-by: Wood Scott-B07421 scottw...@freescale.com Reviewed-by: Fleming Andrew-AFLEMING aflem...@freescale.com Tested-by: Fleming Andrew-AFLEMING aflem...@freescale.com --- arch/powerpc/configs/corenet64_smp_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig index 6c8b020..1ec6f0c 100644 --- a/arch/powerpc/configs/corenet64_smp_defconfig +++ b/arch/powerpc/configs/corenet64_smp_defconfig @@ -66,6 +66,7 @@ CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_CHAR=y CONFIG_MTD_BLKDEVS=y CONFIG_MTD_BLOCK=y +CONFIG_MTD_M25P80=y CONFIG_FTL=y CONFIG_MTD_CFI=y CONFIG_MTD_GEN_PROBE=y This has already been enabled in corenet64_smp_config since commit 478a4829d815865b919c1fa20f0f33543a2291fb, over a year ago. Oh. Thanks. Please drop it then. York ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2][v8] powerpc/mpc85xx:Add initial device tree support of T104x
On Mon, 2013-10-21 at 09:07 +0530, Prabhakar Kushwaha wrote:
Hi Ben,
This patch is present in upstream review list from a long time.
There are no review comments.
So, I request you to pick this patch-set for powerpc.git repository.
http://patchwork.ozlabs.org/patch/280207/
http://patchwork.ozlabs.org/patch/280208/
This revision has only been posted for about 2.5 weeks.
+ #address-cells = 1;
+ #size-cells = 1;
+ pll0: pll0@800 {
+ #clock-cells = 1;
+ reg = 0x800 4;
+ compatible = fsl,qoriq-core-pll-2.0;
+ clocks = clockgen;
+ clock-output-names = pll0, pll0-div2, pll0-div4;
+ };
+ pll1: pll1@820 {
+ #clock-cells = 1;
+ reg = 0x820 4;
+ compatible = fsl,qoriq-core-pll-2.0;
+ clocks = clockgen;
+ clock-output-names = pll1, pll1-div2, pll1-div4;
+ };
+ mux0: mux0@0 {
+ #clock-cells = 0;
+ reg = 0x0 4;
+ compatible = fsl,core-mux-clock;
+ clocks = pll0 0, pll0 1, pll0 2,
+pll1 0, pll1 1, pll1 2;
+ clock-names = pll0_0, pll0_1, pll0_2,
+ pll1_0, pll1_1, pll1_2;
+ clock-output-names = cmux0;
+ };
The clock bindings are still under discussion.
+++ b/arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi
@@ -0,0 +1,106 @@
+/*
+ * T1040/T1042 Silicon/SoC Device Tree Source (pre include)
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are
met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/dts-v1/;
+
+/include/ e5500_power_isa.dtsi
+
+/ {
+ compatible = fsl,T104x;
No wildcards in compatibles. If your response is that this will get
overwritten anyway, then why have compatible here at all?
+ crypto = crypto;
+
+ };
No blank lines before a closing brace.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Pull request: scottwood/linux.git next
Sorry again for the lateness. I tried to get this done before the
conferences last week, but it just didn't happen.
Highlights include corenet board file consolidation, the ability to run
userspaces with lwsync on e500v1/v2, some cleanup patches that other KVM
patches will build on, support for stripped-down e6500 emulation targets,
and some fixes of minor longstanding issues.
Some of the more complicated and/or more recently posted patches didn't
make it this time around; this doesn't mean I've forgotten them (as long
as they're in patchwork in an action required state), just that I've run
out of time for 3.13.
The following changes since commit 3ad26e5c4459d3793ad65bc8929037c70515df83:
Merge branch 'for-kvm' into next (2013-10-11 18:23:53 +1100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next
for you to fetch changes up to b60c5a7a82cdfec2221263ce259faa4a36696163:
powerpc/6xx: CONFIG_MCU_MPC8349EMITX cannot be a module (2013-10-28 21:11:24
-0500)
Bharat Bhushan (3):
powerpc: remove unnecessary line continuations
powerpc: move debug registers in a structure
powerpc: export debug registers save function for KVM
Christian Kujau (1):
powerpc/6xx: CONFIG_MCU_MPC8349EMITX cannot be a module
Chunhe Lan (1):
powerpc/pci: Change the DECLARE_PCI_FIXUP_{HEADER = EARLY} macro of pci
quirk
Haijun.Zhang (2):
powerpc/eSDCH: Specify voltage for T4240QDS
powerpc/dts: Correct sdhci quirk for bsc9131
Hongtao Jia (1):
powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
James Yang (2):
powerpc: Emulate sync instruction variants
powerpc/booke: clear DBCR0_BT in user_disable_single_step()
Kevin Hao (3):
powerpc/85xx: introduce corenet_generic machine
powerpc/85xx: rename the corenet_ds.c to corenet_generic.c
powerpc/85xx: use one kernel option for all the CoreNet_Generic boards
LEROY Christophe (4):
powerpc/mpc8xx: Clearer Oops message for Software Emulation Exception
powerpc/8xx: Revert commit e0908085fc2391c85b85fb814ae1df377c8e0dcb
powerpc/8xx: Fixing issue with CONFIG_PIN_TLB
powerpc/8xx: Fixing memory init issue with CONFIG_PIN_TLB
Lijun Pan (2):
powerpc/e6500: Include Power ISA properties
powerpc/e500v2: Include Power ISA properties
Mihai Caraman (2):
powerpc/booke64: Use common defines for AltiVec interrupts numbers
powerpc/fsl-booke: Use common defines for SPE/FP interrupts numbers
Minghuan Lian (1):
powerpc/dts: fix sRIO error interrupt for b4860
Paul Bolle (1):
powerpc: remove dependency on MV64360
Prabhakar Kushwaha (1):
powerpc/dts/c293pcie: Add range field for IFC NAND
Scott Wood (1):
powerpc/b4qds: enable coreint
Shengzhou Liu (1):
powerpc/fsl/defconfig: enable CONFIG_AT803X_PHY
Suzuki Poulose (1):
powerpc: Set the NOTE type for SPE regset
Tiejun Chen (1):
powerpc/kgdb: use DEFINE_PER_CPU to allocate kgdb's thread_info
Wei Yongjun (2):
powerpc/6xx: add missing iounmap() on error in hlwd_pic_init()
powerpc/mv643xx_eth: fix return check in
mv64x60_eth_register_shared_pdev()
Wolfram Sang (1):
arch/powerpc/platforms/83xx: Remove obsolete cleanup for clientdata
York Sun (2):
powerpc/t4240emu: Add device tree file for t4240emu
powerpc/b4860emu: Add device tree file for b4860emu
Zhao Qiang (1):
powerpc/p1010rdb: add P1010RDB-PB platform support
arch/powerpc/Kconfig | 2 +-
arch/powerpc/boot/dts/b4860emu.dts | 218
arch/powerpc/boot/dts/b4qds.dtsi | 51 +++--
arch/powerpc/boot/dts/c293pcie.dts | 1 +
arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 2 +
arch/powerpc/boot/dts/fsl/b4860si-post.dtsi| 2 +-
arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 2 +
arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/bsc9131si-pre.dtsi | 3 +
arch/powerpc/boot/dts/t4240emu.dts | 268 +
arch/powerpc/boot/dts/t4240qds.dts | 73 ---
arch/powerpc/configs/corenet32_smp_defconfig | 7 +-
arch/powerpc/configs/corenet64_smp_defconfig | 5 +-
arch/powerpc/configs/mpc85xx_defconfig | 1 +
arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
arch/powerpc/configs/ppc64e_defconfig | 2 +-
arch/powerpc/configs/ppc6xx_defconfig | 2 +-
arch/powerpc/include/asm/ppc-opcode.h | 2 +
arch/powerpc/include/asm/processor.h | 34 ++--
arch/powerpc/include/asm/reg_booke.h | 8 +-
arch/powerpc/include/asm/switch_to.h | 1 +
arch/powerpc/kernel/asm-offsets.c | 2 +-
arch/powerpc/kernel/exceptions-64e.S | 5 +-
arch/powerpc/kernel/head_8xx.S | 3 +
Re: Pull request: scottwood/linux.git next
On Mon, 2013-10-28 at 21:44 -0500, Scott Wood wrote: Sorry again for the lateness. I tried to get this done before the conferences last week, but it just didn't happen. Highlights include corenet board file consolidation, the ability to run userspaces with lwsync on e500v1/v2, some cleanup patches that other KVM patches will build on, support for stripped-down e6500 emulation targets, and some fixes of minor longstanding issues. Some of the more complicated and/or more recently posted patches didn't make it this time around; this doesn't mean I've forgotten them (as long as they're in patchwork in an action required state), just that I've run out of time for 3.13. The following changes since commit 3ad26e5c4459d3793ad65bc8929037c70515df83: Merge branch 'for-kvm' into next (2013-10-11 18:23:53 +1100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next for you to fetch changes up to b60c5a7a82cdfec2221263ce259faa4a36696163: powerpc/6xx: CONFIG_MCU_MPC8349EMITX cannot be a module (2013-10-28 21:11:24 -0500) Sigh, I just saw Kumar's e-mail about the build breakage with CONFIG_PPC_EMULATED_STATS (I got dropped from the CC list at some point). CONFIG_PPC_EMULATED_STATS should probably be enabled by default, and by default print the first emulation of each type rather than just using printk_ratelimited(). I'll send a fix for the build breakage. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Fix PPC_EMULATED_STATS build break with sync patch
Commit 9863c28a2af90a56c088f5f6288d7f6d2c923c14 (powerpc: Emulate sync
instruction variants) introduced a build breakage with
CONFIG_PPC_EMULATED_STATS enabled.
Signed-off-by: Scott Wood scottw...@freescale.com
Cc: Kumar Gala ga...@kernel.org
Cc: James Yang james.y...@freescale.com
---
---
arch/powerpc/include/asm/emulated_ops.h | 1 +
arch/powerpc/kernel/traps.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/powerpc/include/asm/emulated_ops.h
b/arch/powerpc/include/asm/emulated_ops.h
index 5a8b82a..4358e30 100644
--- a/arch/powerpc/include/asm/emulated_ops.h
+++ b/arch/powerpc/include/asm/emulated_ops.h
@@ -43,6 +43,7 @@ extern struct ppc_emulated {
struct ppc_emulated_entry popcntb;
struct ppc_emulated_entry spe;
struct ppc_emulated_entry string;
+ struct ppc_emulated_entry sync;
struct ppc_emulated_entry unaligned;
#ifdef CONFIG_MATH_EMULATION
struct ppc_emulated_entry math;
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index ad20dcf..62c3dd8 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -1820,6 +1820,7 @@ struct ppc_emulated ppc_emulated = {
WARN_EMULATED_SETUP(popcntb),
WARN_EMULATED_SETUP(spe),
WARN_EMULATED_SETUP(string),
+ WARN_EMULATED_SETUP(sync),
WARN_EMULATED_SETUP(unaligned),
#ifdef CONFIG_MATH_EMULATION
WARN_EMULATED_SETUP(math),
--
1.8.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5] powerpc/mpc85xx: Update the clock nodes in device tree
On Sun, 2013-10-20 at 21:55 -0500, Tang Yuantian-B29983 wrote: I didn't see how your suggestion is a better matching. OSC PLL1 mux CPU | | |-- PLL2 --| As your suggestion, the clock tree looks like the above. In this case, the MUX driver will not know the divider details(/2, /4, or /3). When is there ever a /3? I think the MUX should act like switch which choose one of the input clock as a output clock. It should not CREATE clock(like PLL1/2, PLL1/4). The purpose of clock driver is to establish the clock tree. The clock tree will not be established in your suggestion because the divider is missing, we don't know where PLL/2 comes from. If you really like your proposal, it should be changed to this: OSC -- PLL1 - PLL1 /1 - MUX ---CPU ||___ PLL1 /2 ___| | | | PLL2 - PLL2 /2 ---| |___ PLL2/ 4 ___| (it is possible that PLLs have different divider). Do we actually have (or expect) a situation where the PLLs have different dividers, or even where the same bit setting in the MUX register means a different divider from one chip to another (within the same MUX compatible string)? If so, then I agree that we should go with your approach. The way Freescale documents things in chip manuals rather than in block manuals, with little bits of information different in each chip manual, makes it hard to figure out this sort of thing. From the examples I looked at, it seemed pretty consistent that the low 2 bits of CLKSEL in the MUX were the log2 of the divider. Are there any chips that don't adhere to this? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] sched: Fix nohz_kick_needed to consider the nr_busy of the parent domain's group
Hi Peter,
On 10/28/2013 07:20 PM, Peter Zijlstra wrote:
On Thu, Oct 24, 2013 at 01:37:38PM +0530, Preeti U Murthy wrote:
kernel/sched/core.c |5 +
kernel/sched/fair.c | 38 --
kernel/sched/sched.h |1 +
3 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c06b8d3..c540392 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5271,6 +5271,7 @@ DEFINE_PER_CPU(struct sched_domain *, sd_llc);
DEFINE_PER_CPU(int, sd_llc_size);
DEFINE_PER_CPU(int, sd_llc_id);
DEFINE_PER_CPU(struct sched_domain *, sd_numa);
+DEFINE_PER_CPU(struct sched_domain *, sd_busy);
static void update_top_cache_domain(int cpu)
{
@@ -5290,6 +5291,10 @@ static void update_top_cache_domain(int cpu)
sd = lowest_flag_domain(cpu, SD_NUMA);
rcu_assign_pointer(per_cpu(sd_numa, cpu), sd);
+
+sd = highest_flag_domain(cpu, SD_SHARE_PKG_RESOURCES);
+if (sd)
+rcu_assign_pointer(per_cpu(sd_busy, cpu), sd-parent);
}
/*
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index e9c9549..f66cfd9 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6515,16 +6515,16 @@ static inline void nohz_balance_exit_idle(int cpu)
static inline void set_cpu_sd_state_busy(void)
{
struct sched_domain *sd;
+int cpu = smp_processor_id();
rcu_read_lock();
+sd = rcu_dereference(per_cpu(sd_busy, cpu));
if (!sd || !sd-nohz_idle)
goto unlock;
sd-nohz_idle = 0;
+atomic_inc(sd-groups-sgp-nr_busy_cpus);
unlock:
rcu_read_unlock();
}
@@ -6532,16 +6532,16 @@ unlock:
void set_cpu_sd_state_idle(void)
{
struct sched_domain *sd;
+int cpu = smp_processor_id();
rcu_read_lock();
+sd = rcu_dereference(per_cpu(sd_busy, cpu));
if (!sd || sd-nohz_idle)
goto unlock;
sd-nohz_idle = 1;
+atomic_dec(sd-groups-sgp-nr_busy_cpus);
unlock:
rcu_read_unlock();
}
Oh nice, that gets rid of the multiple atomics, and it nicely splits
this nohz logic into per topology groups -- now if only we could split
the rest too :-)
I am sorry, I don't get you here. By the 'rest', do you refer to
nohz_kick_needed() as below? Or am I missing something?
@@ -6748,6 +6748,8 @@ static inline int nohz_kick_needed(struct rq *rq, int
cpu)
{
unsigned long now = jiffies;
struct sched_domain *sd;
+struct sched_group_power *sgp;
+int nr_busy;
if (unlikely(idle_cpu(cpu)))
return 0;
@@ -6773,22 +6775,22 @@ static inline int nohz_kick_needed(struct rq *rq,
int cpu)
goto need_kick;
rcu_read_lock();
+sd = rcu_dereference(per_cpu(sd_busy, cpu));
+if (sd) {
+sgp = sd-groups-sgp;
+nr_busy = atomic_read(sgp-nr_busy_cpus);
+if (nr_busy 1)
goto need_kick_unlock;
}
OK, so far so good.
+
+sd = highest_flag_domain(cpu, SD_ASYM_PACKING);
+
+if (sd (cpumask_first_and(nohz.idle_cpus_mask,
+ sched_domain_span(sd)) cpu))
+goto need_kick_unlock;
+
rcu_read_unlock();
return 0;
This again is a bit sad; most archs will not have SD_ASYM_PACKING set at
all; this means that they all will do a complete (and pointless) sched
domain tree walk here.
There will not be a 'complete' sched domain tree walk right? The
iteration will break at the first level of the sched domain for those
archs which do not have SD_ASYM_PACKING set at all.
But it is true that doing a sched domain tree walk regularly is a bad
idea, might as well update the domain with SD_ASYM_PACKING flag set once
and query this domain when required.
I will send out the patch with sd_asym domain introduced rather than the
above.
Thanks
Regards
Preeti U Murthy
It would be much better to also introduce sd_asym and do the analogous
thing to the new sd_busy.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2][v8] powerpc/mpc85xx:Add initial device tree support of T104x
On 10/29/2013 6:41 AM, Scott Wood wrote:
On Mon, 2013-10-21 at 09:07 +0530, Prabhakar Kushwaha wrote:
Hi Ben,
This patch is present in upstream review list from a long time.
There are no review comments.
So, I request you to pick this patch-set for powerpc.git repository.
http://patchwork.ozlabs.org/patch/280207/
http://patchwork.ozlabs.org/patch/280208/
This revision has only been posted for about 2.5 weeks.
+ #address-cells = 1;
+ #size-cells = 1;
+ pll0: pll0@800 {
+ #clock-cells = 1;
+ reg = 0x800 4;
+ compatible = fsl,qoriq-core-pll-2.0;
+ clocks = clockgen;
+ clock-output-names = pll0, pll0-div2, pll0-div4;
+ };
+ pll1: pll1@820 {
+ #clock-cells = 1;
+ reg = 0x820 4;
+ compatible = fsl,qoriq-core-pll-2.0;
+ clocks = clockgen;
+ clock-output-names = pll1, pll1-div2, pll1-div4;
+ };
+ mux0: mux0@0 {
+ #clock-cells = 0;
+ reg = 0x0 4;
+ compatible = fsl,core-mux-clock;
+ clocks = pll0 0, pll0 1, pll0 2,
+pll1 0, pll1 1, pll1 2;
+ clock-names = pll0_0, pll0_1, pll0_2,
+ pll1_0, pll1_1, pll1_2;
+ clock-output-names = cmux0;
+ };
The clock bindings are still under discussion.
I think, I should wait for clock bindings discussion :(
+++ b/arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi
@@ -0,0 +1,106 @@
+/*
+ * T1040/T1042 Silicon/SoC Device Tree Source (pre include)
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/dts-v1/;
+
+/include/ e5500_power_isa.dtsi
+
+/ {
+ compatible = fsl,T104x;
No wildcards in compatibles. If your response is that this will get
overwritten anyway, then why have compatible here at all?
I will take care of this
+ crypto = crypto;
+
+ };
No blank lines before a closing brace.
I will take care of this.
Thanks,
Prabhakar
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
+static struct snd_pcm_hardware snd_fsl_hardware = {
+ .info = SNDRV_PCM_INFO_INTERLEAVED |
+ SNDRV_PCM_INFO_BLOCK_TRANSFER |
+ SNDRV_PCM_INFO_MMAP |
+ SNDRV_PCM_INFO_MMAP_VALID |
+ SNDRV_PCM_INFO_PAUSE |
+ SNDRV_PCM_INFO_RESUME,
+ .formats = SNDRV_PCM_FMTBIT_S16_LE,
+ .rate_min = 8000,
+ .channels_min = 2,
+ .channels_max = 2,
+ .buffer_bytes_max = FSL_SAI_DMABUF_SIZE,
+ .period_bytes_min = 4096,
+ .period_bytes_max = FSL_SAI_DMABUF_SIZE / TCD_NUMBER,
+ .periods_min = TCD_NUMBER,
+ .periods_max = TCD_NUMBER,
+ .fifo_size = 0,
+};
There's a patch in -next that lets the generic dmaengine code figure out
some settings from the dmacontroller rather than requiring the driver to
explicitly provide configuration - it's ASoC: dmaengine-pcm: Provide
default config. Please update your driver to use this, or let's work
out what it doesn't do any try to fix it.
I couldn't find the patch in the next and other trees.
Does this patch has been submitted to the -next tree ?
Or could you tell me how to find the patch please?
Thanks very much.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
On Tue, Oct 29, 2013 at 12:00:57PM +0800, Xiubo Li-B47053 wrote: There's a patch in -next that lets the generic dmaengine code figure out some settings from the dmacontroller rather than requiring the driver to explicitly provide configuration - it's ASoC: dmaengine-pcm: Provide default config. Please update your driver to use this, or let's work out what it doesn't do any try to fix it. I couldn't find the patch in the next and other trees. Does this patch has been submitted to the -next tree ? Or could you tell me how to find the patch please? Are you using broonie's repository? git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git If you searched the title in for-next branch, you should have found it. Best regards, Nicolin Chen ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: boot: Don't change link address for OF-based platforms
Commit c55aef0e5bc6 (powerpc/boot: Change the load address for the wrapper to fit the kernel) adjusts the wrapper address unnecessarily for platforms that use arch/powerpc/boot/of.c, since the code there allocates space for the kernel wherever it can find it and doesn't necessarily load the kernel at address 0. Changing the link address is actually harmful since it can cause the zImage to overlap with Open Firmware and thus fail to boot. To fix this, we set make_space to n for all of the platforms that use of.o. Signed-off-by: Paul Mackerras pau...@samba.org --- arch/powerpc/boot/wrapper | 4 1 file changed, 4 insertions(+) diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper index cd7af84..ac16e99 100755 --- a/arch/powerpc/boot/wrapper +++ b/arch/powerpc/boot/wrapper @@ -150,18 +150,22 @@ case $platform in pseries) platformo=$object/of.o $object/epapr.o link_address='0x400' +make_space=n ;; maple) platformo=$object/of.o $object/epapr.o link_address='0x40' +make_space=n ;; pmac|chrp) platformo=$object/of.o $object/epapr.o +make_space=n ;; coff) platformo=$object/crt0.o $object/of.o $object/epapr.o lds=$object/zImage.coff.lds link_address='0x50' +make_space=n pie= ;; miboot|uboot*) -- 1.8.4.rc3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] sched: Aggressive balance in domains whose groups share package resources
Hi Peter, On 10/28/2013 09:23 PM, Peter Zijlstra wrote: On Mon, Oct 21, 2013 at 05:15:02PM +0530, Vaidyanathan Srinivasan wrote: From: Preeti U Murthy pre...@linux.vnet.ibm.com The current logic in load balance is such that after picking the busiest group, the load is attempted to be moved from the busiest cpu in that group to the dst_cpu. If the load cannot be moved from the busiest cpu to dst_cpu due to either tsk_cpus_allowed mask or cache hot tasks, then the dst_cpu is changed to be another idle cpu within the dst-grpmask. If even then, the load cannot be moved from the busiest cpu, then the source group is changed. The next busiest group is found and the above steps are repeated. However if the cpus in the group share package resources, then when a load movement from the busiest cpu in this group fails as above, instead of finding the next busiest group to move load from, find the next busiest cpu *within the same group* from which to move load away. By doing so, a conscious effort is made during load balancing to keep just one cpu busy as much as possible within domains that have SHARED_PKG_RESOURCES flag set unless under scenarios of high load. Having multiple cpus busy within a domain which share package resource could lead to a performance hit. A similar scenario arises in active load balancing as well. When the current task on the busiest cpu cannot be moved away due to task pinning, currently no more attempts at load balancing is made. This patch checks if the balancing is being done on a group whose cpus share package resources. If so, then check if the load balancing can be done for other cpus in the same group. So I absolutely hate this patch... Also I'm not convinced I actually understand the explanation above. Furthermore; there is nothing special about spreading tasks for SHARED_PKG_RESOURCES and special casing that one case is just wrong. If anything it should be keyed off of SD_PREFER_SIBLING and or cpu_power. At a SIBLING level, which has SHARED_PKG_RESOURCES set, cpu_power in fact takes care of ensuring that the scheduler mostly spreads the load when there is more than one running task by nominating the group as busy. But the issue that this patch is bringing to the front is a bit different; its not during the time of this nomination, its at the time of load balancing. It is explained below. So metrics like cpu_power and flags like SD_PREFER_SIBLING ensure that we spread the load by nominating such groups as busiest in update_sg_lb_stats() and update_sd_lb_stats(). So nominating a group as busiest by virtue of cpu_power or flags is taken care of. However, in load_balance(), if the imbalance cannot be offset by moving load from the busiest_cpu in the busiest_group, then today we do not try the *next busiest cpu in the group*; instead we try the next busiest_group. So whatever effort we put in by nominating this group as busiest, if the grp_power and flags do not favour tasks on it, seems relevant only if the busiest cpu in that group co-operates in offloading tasks. Should we not be trying our best to move load from any other cpu in this group ? This patch identifies one such situation, which led to too many tasks on a core and got me to ponder over this question. I agree that the fix in this patch is not right. But I thought this would open up discussion around the above question. Its true that iterating over all the cpus in a group during the actual load balance is too much of an overhead, but isn't there a balance we can strike during load balance iterations for such groups which have limited cpu power? Thanks Regards Preeti U Murthy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
