Re: [PATCH 1/5] sched: fix capacity calculations for SMT4
In message <1271426308.1674.429.ca...@laptop> you wrote: > On Wed, 2010-04-14 at 14:28 +1000, Michael Neuling wrote: > > > > Right, so I suspect this will indeed break some things. > > > > > > We initially allowed 0 capacity for when a cpu is consumed by an RT task > > > and there simply isn't much capacity left, in that case you really want > > > to try and move load to your sibling cpus if possible. > > > > Changing the CPU power based on what tasks are running on them seems a > > bit wrong to me. Shouldn't we keep those concepts separate? > > Well the thing cpu_power represents is a ratio of compute capacity > available to this cpu as compared to other cpus. By normalizing the > runqueue weights with this we end up with a fair balance. > > The thing to realize here is that this is solely about SCHED_NORMAL > tasks, SCHED_FIFO/RR (or the proposed DEADLINE) tasks do not care about > fairness and available compute capacity. > > So if we were to ignore RT tasks, you'd end up with a situation where, > assuming 2 cpus and 4 equally weighted NORMAL tasks, and 1 RT task, the > load-balancer would give each cpu 2 NORMAL tasks, but the tasks that > would end up on the cpu the RT tasks would be running on would not run > as fast -- is that fair? > > Since RT tasks do not have a weight (FIFO/RR have no limit at all, > DEADLINE would have something equivalent to a max weight), it is > impossible to account them in the normal weight sense. > > Therefore the current model takes them into account by lowering the > compute capacity according to their (avg) cpu usage. So if the RT task > would consume 66% cputime, we'd end up with a situation where the cpu > running the RT task would get 1 NORMAL task, and other cpu would have > the remaining 3, that way they'd all get 33% cpu. > > > > However you're right that this goes awry in your case. > > > > > > One thing to look at is if that 15% increase is indeed representative > > > for the power7 cpu, it having 4 SMT threads seems to suggest there was > > > significant gains, otherwise they'd not have wasted the silicon. > > > > There are certainly, for most workloads, per core gains for SMT4 over > > SMT2 on P7. My kernels certainly compile faster and that's the only > > workload anyone who matters cares about ;-) > > For sure ;-) > > Are there any numbers available on how much they gain? It might be worth > to stick in real numbers instead of this alleged 15%. > > > > One thing we could look at is using the cpu base power to compute > > > capacity from. We'd have to add another field to sched_group and store > > > power before we do the scale_rt_power() stuff. > > > > Separating capacity from what RT tasks are running seems like a good > > idea to me. > > Well, per the above we cannot fully separate them. > > > This would fix the RT issue, but it's not clear to me how you are > > suggesting fixing the rounding down to 0 SMT4 issue. Are you suggesting > > we bump smt_gain to say 2048 + 15%? Or are you suggesting we separate > > the RT tasks out from capacity and keep the max(1, capacity) that I've > > added? Or something else? > > I would think that 4 SMT threads are still slower than two full cores, > right? So cpu_power=2048 would not be appropriate. > > > Would another possibility be changing capacity a scaled value (like > > cpu_power is now) rather than a small integer as it is now. For > > example, a scaled capacity of 1024 would be equivalent to a capacity of > > 1 now. This might enable us to handle partial capacities better? We'd > > probably have to scale a bunch of nr_running too. > > Right, so my proposal was to scale down the capacity divider (currently > 1024) to whatever would be the base capacity for that cpu. Trouble seems > to be that that makes group capacity a lot more complex, as you would > end up needing to average all the cpu's their base capacity. > > > Hrmm, my brain seems muddled but I might have another solution, let me > ponder this for a bit.. > Peter, Did you manage to get anywhere on this capacity issue? Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Wed, Apr 28, 2010 at 6:52 PM, Benjamin Herrenschmidt wrote: > On Wed, 2010-04-28 at 17:13 -0500, Timur Tabi wrote: >> On Wed, Apr 28, 2010 at 4:58 PM, Grant Likely >> wrote: >> >> > The sound0 node needs a compatible value, >> >> I knew I was forgetting something >> >> > the sound-device node should >> > probably have one too. >> >> The aliases, cpus, and memory node don't have a compatible property, >> and I was modeling the design after the aliases node. > > aliases is a bad choice, it's very very special and is neither a device > nor a virtual device, like chosen. > > cpus is more of a match in your case. > > In any case, I agree, you may not really need a compatible prop for the > virtual device. In fact, Grant, do we really need an enclosing node like > that ? Mostly I'm concerned about 'polluting' the root node in a way that we'd regret later; but perhaps I'm being overly conservative. The sound node will still be uniquely identified by it's compatible property, so perhaps I'm fretting over nothing. > In any case, it's no big deal and shouldn't have much impact on > the design. Right, the point has been reached of quibbling over trivialities. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Wed, Apr 28, 2010 at 6:36 PM, Benjamin Herrenschmidt wrote: > On Wed, 2010-04-28 at 13:07 +0100, Mark Brown wrote: >> > The device-tree helps keep the platform .c file simple and devoid of too >> > horrible hacks, it allows to easily pass various configuration data to >> > leaf drivers such as i2c thingies, PHY devices etc... without gross >> > hooks between these and the platform, but the platform code still has >> > the upper hand for doing ad-hoc bits and pieces (or overwriting the >> > device-tree based behaviour) if necessary. >> >> Once again, if you can get the device tree guys to buy into this and >> stick with it that sounds good but my experience has been that this >> isn't where any of these discussions end up. > > Well, as the person who came up with the flattened device-tree format in > the first place I suppose I qualify as a "device-tree" guy here :-) > > At the moment, I'd say Grant (and to some extent Jeremy Kerr) are the > guys in charge though, but yes, I agree with you, there's a tendency to > be too over-exited and to want to do "too much" with the DT and that is > counter productive. It's a good tool but it's not going to solve world > hunger and in some places an ad-hoc bit of C code is a better option :) > > Now, I don't think Grant is totally off the tracks here but I must admit > I haven't taken the time to ensure I understand perfectly everybody's > position in that debate. At least I made mine clear, hope this helps :-) After an IRC conversation with Timur, I think we've pretty much sorted out the best way to handle the mpc8610 use case that allows the ssi/dma/codec drivers to remain blissfully ignorant and bind in the appropriate ASoC machine driver for the board. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC ftrace function trace optimisation
On Wed, 2010-04-28 at 21:55 -0400, Steven Rostedt wrote: > On Thu, 2010-04-29 at 10:51 +1000, Anton Blanchard wrote: > > Hi, > > > # gcc -pg -mprofile-kernel > > > > <.foo>: > >0: 7c 08 02 a6 mflrr0 > >4: f8 01 00 10 std r0,16(r1) > >8: 48 00 00 01 bl 8 <.foo+0x8><--- call to mcount > > > >c: 7c 08 02 a6 mflrr0 > > Why the extra mflr? Can't we just make it a requirement that mcount > returns with r0 back to what it was? Well, we can't just change that now, it's been in for long enough. We might be able to get a new option later on that makes it more efficient tho (for example removing the std), but let's see what we can do with what we have. The extra mflr makes sense if you consider that the option just pre-pends a pre-canned set of instructions and doesn't actually touch anything to the prolog generation. It might be possible to do a hack to make the prolog aware that LR is already in r0 but let's look at that after we've verified we can get the existing stuff working :-) Another idea Alan had is that if we could have a list of call sites, instead of NOP'ing we could instead change the branches of all call sites to skip the 3 instruction mcount prolog :-) Now, we do store the relocs with the kernel image when using CONFIG_RELOCATABLE, though we might want to 'sort' them a bit to easily find callers from call sites, but it's something to also consider. Cheers, Ben. > -- Steve > > > 10: f8 01 00 10 std r0,16(r1) > > 14: f8 21 ff d1 stdur1,-48(r1) > > 18: e9 22 00 00 ld r9,0(r2) > > 1c: e8 69 00 02 lwa r3,0(r9) > > 20: 38 21 00 30 addir1,r1,48 > > 24: e8 01 00 10 ld r0,16(r1) > > 28: 7c 08 03 a6 mtlrr0 > > 2c: 4e 80 00 20 blr > > > > > > This mean we could support ftrace function trace with very little overhead. > > > > In fact if we are careful when switching to the new mcount ABI and don't > > rely on the store of r0, we could probably optimise this even further in a > > future gcc and remove the store completely. mcount would be 2 instructions: > > > >mflrr0 > >bl 8 <.foo+0x8> > > > > Anton > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC ftrace function trace optimisation
On Thu, 2010-04-29 at 10:51 +1000, Anton Blanchard wrote: > Hi, > # gcc -pg -mprofile-kernel > > <.foo>: >0: 7c 08 02 a6 mflrr0 >4: f8 01 00 10 std r0,16(r1) >8: 48 00 00 01 bl 8 <.foo+0x8> <--- call to mcount > >c: 7c 08 02 a6 mflrr0 Why the extra mflr? Can't we just make it a requirement that mcount returns with r0 back to what it was? -- Steve > 10: f8 01 00 10 std r0,16(r1) > 14: f8 21 ff d1 stdur1,-48(r1) > 18: e9 22 00 00 ld r9,0(r2) > 1c: e8 69 00 02 lwa r3,0(r9) > 20: 38 21 00 30 addir1,r1,48 > 24: e8 01 00 10 ld r0,16(r1) > 28: 7c 08 03 a6 mtlrr0 > 2c: 4e 80 00 20 blr > > > This mean we could support ftrace function trace with very little overhead. > > In fact if we are careful when switching to the new mcount ABI and don't > rely on the store of r0, we could probably optimise this even further in a > future gcc and remove the store completely. mcount would be 2 instructions: > >mflrr0 >bl 8 <.foo+0x8> > > Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC ftrace function trace optimisation
On Thu, Apr 29, 2010 at 11:02:47AM +1000, Benjamin Herrenschmidt wrote: > From a quick test it appears that this only works with -m64, not -m32. > Alan is that correct ? Yes. > Any chance you can fix that in future gcc versions ? No need really. 32-bit _mcount calls happen before the prologue anyway. > > In fact if we are careful when switching to the new mcount ABI and don't > > rely on the store of r0, we could probably optimise this even further in a > > future gcc and remove the store completely. mcount would be 2 instructions: > > > >mflrr0 > >bl 8 <.foo+0x8> Yeah. Also, I should have used a different name for this mcount from the standard 64-bit mcount. -- Alan Modra Australia Development Lab, IBM ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC ftrace function trace optimisation
On Thu, 2010-04-29 at 11:02 +1000, Benjamin Herrenschmidt wrote: > > The option Alan added reduces the footprint to 3 instructions which can > > be noped out completely. The rest of the function does not rely on the first > > three instructions. No stack spill is forced either: > > > > # gcc -pg -mprofile-kernel > > >From a quick test it appears that this only works with -m64, not -m32. > Alan is that correct ? Any chance you can fix that in future gcc > versions ? > > Also should we implement support for both type of mcounts or just only > allow enabling of ftrace with gcc's that support this ? Also, Anton noticed : > Cheers, > Ben. > > > <.foo>: > >0: 7c 08 02 a6 mflrr0 > >4: f8 01 00 10 std r0,16(r1) The std is not useful here. We can do it inside mcount. > >8: 48 00 00 01 bl 8 <.foo+0x8><--- call to mcount And I noticed: > >c: 7c 08 02 a6 mflrr0 I'm happy to guarantee that mcount does the above. > > 10: f8 01 00 10 std r0,16(r1) And maybe that one too. However I understand if it's easier not to change the prolog codegen (the 2 insn above) and just stick to adding a 2 or 3 instructions boilerplate at the top. Cheers, Ben. > > 14: f8 21 ff d1 stdur1,-48(r1) > > 18: e9 22 00 00 ld r9,0(r2) > > 1c: e8 69 00 02 lwa r3,0(r9) > > 20: 38 21 00 30 addir1,r1,48 > > 24: e8 01 00 10 ld r0,16(r1) > > 28: 7c 08 03 a6 mtlrr0 > > 2c: 4e 80 00 20 blr > > > > > > This mean we could support ftrace function trace with very little overhead. > > > > In fact if we are careful when switching to the new mcount ABI and don't > > rely on the store of r0, we could probably optimise this even further in a > > future gcc and remove the store completely. mcount would be 2 instructions: > > > >mflrr0 > >bl 8 <.foo+0x8> > > > > Anton > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC ftrace function trace optimisation
> The option Alan added reduces the footprint to 3 instructions which can > be noped out completely. The rest of the function does not rely on the first > three instructions. No stack spill is forced either: > > # gcc -pg -mprofile-kernel >From a quick test it appears that this only works with -m64, not -m32. Alan is that correct ? Any chance you can fix that in future gcc versions ? Also should we implement support for both type of mcounts or just only allow enabling of ftrace with gcc's that support this ? Cheers, Ben. > <.foo>: >0: 7c 08 02 a6 mflrr0 >4: f8 01 00 10 std r0,16(r1) >8: 48 00 00 01 bl 8 <.foo+0x8> <--- call to mcount > >c: 7c 08 02 a6 mflrr0 > 10: f8 01 00 10 std r0,16(r1) > 14: f8 21 ff d1 stdur1,-48(r1) > 18: e9 22 00 00 ld r9,0(r2) > 1c: e8 69 00 02 lwa r3,0(r9) > 20: 38 21 00 30 addir1,r1,48 > 24: e8 01 00 10 ld r0,16(r1) > 28: 7c 08 03 a6 mtlrr0 > 2c: 4e 80 00 20 blr > > > This mean we could support ftrace function trace with very little overhead. > > In fact if we are careful when switching to the new mcount ABI and don't > rely on the store of r0, we could probably optimise this even further in a > future gcc and remove the store completely. mcount would be 2 instructions: > >mflrr0 >bl 8 <.foo+0x8> > > Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
PowerPC ftrace function trace optimisation
Hi, Alan Modra pointed out that he added an option to PowerPC gcc years ago specifically for us to do lightweight mcount profiling. The normal PowerPC gcc mcount stuff forces a stack spill and gets itself tangled up in the function prolog, making it impossible to nop out easily: # gcc -pg: <.foo>: 0: 7c 08 02 a6 mflrr0 <--- shared stack spill code 4: f8 01 00 10 std r0,16(r1) <--| 8: f8 21 ff 91 stdur1,-112(r1) <--+ c: 48 00 00 01 bl c <.foo+0xc><--- call to mcount 10: 60 00 00 00 nop 14: e9 22 00 00 ld r9,0(r2) 18: e8 69 00 02 lwa r3,0(r9) 1c: 38 21 00 70 addir1,r1,112 20: e8 01 00 10 ld r0,16(r1) 24: 7c 08 03 a6 mtlrr0 28: 4e 80 00 20 blr The option Alan added reduces the footprint to 3 instructions which can be noped out completely. The rest of the function does not rely on the first three instructions. No stack spill is forced either: # gcc -pg -mprofile-kernel <.foo>: 0: 7c 08 02 a6 mflrr0 4: f8 01 00 10 std r0,16(r1) 8: 48 00 00 01 bl 8 <.foo+0x8><--- call to mcount c: 7c 08 02 a6 mflrr0 10: f8 01 00 10 std r0,16(r1) 14: f8 21 ff d1 stdur1,-48(r1) 18: e9 22 00 00 ld r9,0(r2) 1c: e8 69 00 02 lwa r3,0(r9) 20: 38 21 00 30 addir1,r1,48 24: e8 01 00 10 ld r0,16(r1) 28: 7c 08 03 a6 mtlrr0 2c: 4e 80 00 20 blr This mean we could support ftrace function trace with very little overhead. In fact if we are careful when switching to the new mcount ABI and don't rely on the store of r0, we could probably optimise this even further in a future gcc and remove the store completely. mcount would be 2 instructions: mflrr0 bl 8 <.foo+0x8> Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Wed, 2010-04-28 at 17:13 -0500, Timur Tabi wrote:
> On Wed, Apr 28, 2010 at 4:58 PM, Grant Likely
> wrote:
>
> > The sound0 node needs a compatible value,
>
> I knew I was forgetting something
>
> > the sound-device node should
> > probably have one too.
>
> The aliases, cpus, and memory node don't have a compatible property,
> and I was modeling the design after the aliases node.
aliases is a bad choice, it's very very special and is neither a device
nor a virtual device, like chosen.
cpus is more of a match in your case.
In any case, I agree, you may not really need a compatible prop for the
virtual device. In fact, Grant, do we really need an enclosing node like
that ? In any case, it's no big deal and shouldn't have much impact on
the design.
Cheers,
Ben.
> > The sound0 node should have something board specific like
> > "fsl,mpc8610hpcd-sound" to make it clear that the binding really only
> > applies to this particular board. It would also be a good idea to
> > prefix all of the property names with 'fsl,' to avoid conflicting with
> > any future common bindings or conventions. Other boards can use the
> > same binding, but they would get a different compatible value (the
> > driver could bind on both).
>
> The aliases node doesn't have an fsl, prefix. I understand the need
> for the prefix, but I wonder why we don't do that for the aliases
> node.
>
> > I'm not a huge fan of the name "sound-devices" for the parent node.
> > There are other sorts of things that we need 'virtual' device nodes to
> > describe. It would be nice to have a single place for collecting
> > nodes for stuff like this. Perhaps this:
> >
> > system {
> >compatible = "system-devices";
> >sound0 {
> >compatible = "fsl,mpc8610hpcd-sound";
> >fsl,ssi = &ssi0;
> >fsl,playback-dma = &dma00;
> >fsl,capture-dma = &dma01;
> >fsl,codec = &cs4270;
> >};
> > };
>
> I like that.
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Wed, 2010-04-28 at 15:35 -0500, Timur Tabi wrote:
> Second, how about this binding for the virtual sound node? It would
> be a root-level node.
>
> sound-devices {
> sound0 {
> ssi = &ssi0;
> playback-dma = &dma00;
> capture-dma = &dma01;
> codec = &cs4270;
> }
> };
Make sure you also have a "compatible" property to uniquely identify the
design. You could use the toplevel board one but I'd rather keep a
separate one here. I've seen case where the exact same base board may
have different sound components (because they are dautherboards for
example, but there's a few other cases).
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Wed, 2010-04-28 at 14:00 +0100, Mark Brown wrote: > > The whole thing is a matter of common sense and a bit of taste :-) > > The impression that has been created in the past is that there are > inflexible device tree rules which can't be varied. I'm a bit sad this is how things have been perceived since that's clearly not the policy I've applied to the powerpc architecture. Or rather, there are -some- inflexible rules yes, which are to: - Have a device-tree :-) - Have a /compatible property at the toplevel to identify your board - Have the /cpus nodes for representing the CPUs. That's pretty much the only absolute requirements from a code perspective. Now I -do- require people to also have nodes for things like PCI host bridge, since that allows using a ton of existing code for handling most aspects of PCI, and I -do- complain if people just hard wire platform devices everywhere or interrupt numbers without even trying to consider using the device-tree appropriately. However, I've always been against the one-bsp-fits-all approach, and it's always been my clear policy that there should be a per-machine .c file. I did bend when folks pushed the "simple" platform but with the understanding that it must contain an -explicit- list of boards it supports. You'll also notice that all of my virtual interrupt handling stuff is such that you -can- use it without device-tree nodes, the DT just makes it easier. Same goes with PCI devices (only the PHB requires a DT node at this stage) etc... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Wed, 2010-04-28 at 13:07 +0100, Mark Brown wrote: > > The device-tree helps keep the platform .c file simple and devoid of too > > horrible hacks, it allows to easily pass various configuration data to > > leaf drivers such as i2c thingies, PHY devices etc... without gross > > hooks between these and the platform, but the platform code still has > > the upper hand for doing ad-hoc bits and pieces (or overwriting the > > device-tree based behaviour) if necessary. > > Once again, if you can get the device tree guys to buy into this and > stick with it that sounds good but my experience has been that this > isn't where any of these discussions end up. Well, as the person who came up with the flattened device-tree format in the first place I suppose I qualify as a "device-tree" guy here :-) At the moment, I'd say Grant (and to some extent Jeremy Kerr) are the guys in charge though, but yes, I agree with you, there's a tendency to be too over-exited and to want to do "too much" with the DT and that is counter productive. It's a good tool but it's not going to solve world hunger and in some places an ad-hoc bit of C code is a better option :) Now, I don't think Grant is totally off the tracks here but I must admit I haven't taken the time to ensure I understand perfectly everybody's position in that debate. At least I made mine clear, hope this helps :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc: only call start-cpu when a CPU is stopped
Currently we always call start-cpu irrespective of if the CPU is
stopped or not. Unfortunatley on POWER7, firmware seems to not like
start-cpu being called when a cpu already been started. This was not
the case on POWER6 and earlier.
This patch checks to see if the CPU is stopped or not via an
query-cpu-stopped-state call, and only calls start-cpu on CPUs which
are stopped.
This fixes a bug with kexec on POWER7 on PHYP where only the primary
thread would make it to the second kernel.
Reported-by: Ankita Garg
Cc:
Signed-off-by: Michael Neuling
---
arch/powerpc/platforms/pseries/smp.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/smp.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/smp.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/smp.c
@@ -103,6 +103,12 @@ static inline int __devinit smp_startup_
return 1;
pcpu = get_hard_smp_processor_id(lcpu);
+
+ /* Check to see if the CPU out of FW already for kexec */
+ if (smp_query_cpu_stopped(pcpu) == QCSS_NOT_STOPPED){
+ cpu_set(lcpu, of_spin_map);
+ return 1;
+ }
/* Fixup atomic count: it exited inside IRQ handler. */
task_thread_info(paca[lcpu].__current)->preempt_count = 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc: make query_cpu_stopped callable outside hotplug cpu
This moves query_cpu_stopped() out of the hotplug cpu code and into
smp.c so it can called in other places and renames it to
smp_query_cpu_stopped().
It also cleans up the return values by adding some #defines
Cc:
Signed-off-by: Michael Neuling
---
arch/powerpc/platforms/pseries/hotplug-cpu.c| 30 +++-
arch/powerpc/platforms/pseries/plpar_wrappers.h |8 ++
arch/powerpc/platforms/pseries/smp.c| 22 +
3 files changed, 34 insertions(+), 26 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/hotplug-cpu.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -154,30 +154,6 @@ static void pseries_mach_cpu_die(void)
for(;;);
}
-static int qcss_tok; /* query-cpu-stopped-state token */
-
-/* Get state of physical CPU.
- * Return codes:
- * 0 - The processor is in the RTAS stopped state
- * 1 - stop-self is in progress
- * 2 - The processor is not in the RTAS stopped state
- * -1 - Hardware Error
- * -2 - Hardware Busy, Try again later.
- */
-static int query_cpu_stopped(unsigned int pcpu)
-{
- int cpu_status, status;
-
- status = rtas_call(qcss_tok, 1, 2, &cpu_status, pcpu);
- if (status != 0) {
- printk(KERN_ERR
- "RTAS query-cpu-stopped-state failed: %i\n", status);
- return status;
- }
-
- return cpu_status;
-}
-
static int pseries_cpu_disable(void)
{
int cpu = smp_processor_id();
@@ -224,8 +200,9 @@ static void pseries_cpu_die(unsigned int
} else if (get_preferred_offline_state(cpu) == CPU_STATE_OFFLINE) {
for (tries = 0; tries < 25; tries++) {
- cpu_status = query_cpu_stopped(pcpu);
- if (cpu_status == 0 || cpu_status == -1)
+ cpu_status = smp_query_cpu_stopped(pcpu);
+ if (cpu_status == QCSS_STOPPED ||
+ cpu_status == QCSS_HARDWARE_ERROR)
break;
cpu_relax();
}
@@ -388,6 +365,7 @@ static int __init pseries_cpu_hotplug_in
struct device_node *np;
const char *typep;
int cpu;
+ int qcss_tok;
for_each_node_by_name(np, "interrupt-controller") {
typep = of_get_property(np, "compatible", NULL);
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/plpar_wrappers.h
===
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/plpar_wrappers.h
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/plpar_wrappers.h
@@ -4,6 +4,14 @@
#include
#include
+/* Get state of physical CPU from query_cpu_stopped */
+int smp_query_cpu_stopped(unsigned int pcpu);
+#define QCSS_STOPPED 0
+#define QCSS_STOPPING 1
+#define QCSS_NOT_STOPPED 2
+#define QCSS_HARDWARE_ERROR -1
+#define QCSS_HARDWARE_BUSY -2
+
static inline long poll_pending(void)
{
return plpar_hcall_norets(H_POLL_PENDING);
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/smp.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/smp.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/smp.c
@@ -57,6 +57,28 @@
*/
static cpumask_t of_spin_map;
+/* Query where a cpu is now. Return codes #defined in plpar_wrappers.h */
+int smp_query_cpu_stopped(unsigned int pcpu)
+{
+ int cpu_status, status;
+ int qcss_tok = rtas_token("query-cpu-stopped-state");
+
+ if (qcss_tok == RTAS_UNKNOWN_SERVICE) {
+ printk(KERN_INFO "Firmware doesn't support "
+ "query-cpu-stopped-state\n");
+ return QCSS_HARDWARE_ERROR;
+ }
+
+ status = rtas_call(qcss_tok, 1, 2, &cpu_status, pcpu);
+ if (status != 0) {
+ printk(KERN_ERR
+ "RTAS query-cpu-stopped-state failed: %i\n", status);
+ return status;
+ }
+
+ return cpu_status;
+}
+
/**
* smp_startup_cpu() - start the given cpu
*
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] mpc5121_nfc: Changed SVR check to allow MPC5123.
The revision in SVR for MPC5123 is 3. The NFC is the same as MPC5121
revision 2.
---
drivers/mtd/nand/mpc5121_nfc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/mpc5121_nfc.c
b/drivers/mtd/nand/mpc5121_nfc.c
index 191bf99..dc04d74 100644
--- a/drivers/mtd/nand/mpc5121_nfc.c
+++ b/drivers/mtd/nand/mpc5121_nfc.c
@@ -666,10 +666,10 @@ static int __devinit mpc5121_nfc_probe(struct
of_device *op,
/*
* Check SoC revision. This driver supports only NFC
-* in MPC5121 revision 2.
+* in MPC5121 revision 2 and MPC5123 revision 3.
*/
rev = (mfspr(SPRN_SVR) >> 4) & 0xF;
- if (rev != 2) {
+ if ((rev != 2) && (rev != 3)) {
dev_err(dev, "SoC revision %u is not supported!\n",
rev);
return -ENXIO;
}
--
1.5.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300
On Wed, 2010-04-28 at 14:15 -0500, Xianghua Xiao wrote: > This change works me on a 834x(e300) platform, tested with lmbench and > a production-ready application with 2.6.33.3. But have you tested that DEBUG_PAGEALLOC actually works ? :-) A way to do that is to - get_free_pages a page - read from it - free it - write to it It should oops on the write, and I suspect that without my patch it doesn't. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] genirq: reliably replay pending edge-triggered irq
On Wed, 28 Apr 2010, Guillaume Knispel wrote: > On Tue, 27 Apr 2010 15:42:11 +0200 (CEST) > Thomas Gleixner wrote: > > > On Thu, 22 Apr 2010, Guillaume Knispel wrote: > [snip] > > > acked and masked at controller level and IRQ_PENDING is set. > > > --- > > > arch/arm/Kconfig |4 > > > arch/arm/configs/acs5k_defconfig |1 - > > > arch/arm/configs/acs5k_tiny_defconfig |1 - > > > >Changing the defconfigs should be a separate patch and I'm not > >going to push such a thing through the genirq tree. The stale > >entries do not hurt. > > Ok > In this separate patch, to I put "genirq" in the title? > Do I put it in the same series? Just keep them out for now and send them to the arch maintainers once the change hits linus tree. Thanks, tglx ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Wed, Apr 28, 2010 at 4:13 PM, Timur Tabi wrote: > On Wed, Apr 28, 2010 at 4:58 PM, Grant Likely > wrote: > >> The sound0 node needs a compatible value, > > I knew I was forgetting something :-) > >> the sound-device node should >> probably have one too. > > The aliases, cpus, and memory node don't have a compatible property, > and I was modeling the design after the aliases node. Well, there are typically three ways to find a node; by name, by device_type and by compatible. device_type is meaningless for the flattened tree, so that's out. Matching by name could potentially have namespace collisions, but I'm not sure. I'll defer to Ben & Mitch's judgment here. The difference with aliases, cpus and memory nodes is that the conventions around them were defined and agreed on a very long time ago. We could get consensus to do the same here, but I cannot make that call. >> The sound0 node should have something board specific like >> "fsl,mpc8610hpcd-sound" to make it clear that the binding really only >> applies to this particular board. It would also be a good idea to >> prefix all of the property names with 'fsl,' to avoid conflicting with >> any future common bindings or conventions. Other boards can use the >> same binding, but they would get a different compatible value (the >> driver could bind on both). > > The aliases node doesn't have an fsl, prefix. I understand the need > for the prefix, but I wonder why we don't do that for the aliases > node. aliases is not a vendor-specific or limited scope convention. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Wed, Apr 28, 2010 at 4:58 PM, Grant Likely wrote:
> The sound0 node needs a compatible value,
I knew I was forgetting something
> the sound-device node should
> probably have one too.
The aliases, cpus, and memory node don't have a compatible property,
and I was modeling the design after the aliases node.
> The sound0 node should have something board specific like
> "fsl,mpc8610hpcd-sound" to make it clear that the binding really only
> applies to this particular board. It would also be a good idea to
> prefix all of the property names with 'fsl,' to avoid conflicting with
> any future common bindings or conventions. Other boards can use the
> same binding, but they would get a different compatible value (the
> driver could bind on both).
The aliases node doesn't have an fsl, prefix. I understand the need
for the prefix, but I wonder why we don't do that for the aliases
node.
> I'm not a huge fan of the name "sound-devices" for the parent node.
> There are other sorts of things that we need 'virtual' device nodes to
> describe. It would be nice to have a single place for collecting
> nodes for stuff like this. Perhaps this:
>
> system {
> compatible = "system-devices";
> sound0 {
> compatible = "fsl,mpc8610hpcd-sound";
> fsl,ssi = &ssi0;
> fsl,playback-dma = &dma00;
> fsl,capture-dma = &dma01;
> fsl,codec = &cs4270;
> };
> };
I like that.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [microblaze-uclinux] [PATCHv2] [RFC] Xilinx MPMC SDMA subsystem
On Wednesday 28 April 2010 09:13:06 you wrote:
> Hi Sergey and Steven,
>
> On Tue, Apr 27, 2010 at 8:29 PM, Steven J. Magnani
>
> wrote:
> > On Wed, 2010-04-28 at 02:06 +0400, Sergey Temerkhanov wrote:
> >> This is the 2nd version of Xilinx MPMC LocalLink SDMA subsystem
> >>
> >> Changelog v2:
> >> * Changed the functions and struct definition prefix from sdma_ to
> >> xllsdma_ * Platform bus bindings and various changes by Steven J.
> >> Magnani. * Moved source files from arch/powerpc/sysdev to global
> >> locations and added CONFIG_XLLSDMA option.
> >>
> >> Regards, Sergey Temerkhanov,
> >> Cifronic ZAO
> >>
> >> diff -r baced9e29ab5 drivers/dma/Kconfig
> >> --- a/drivers/dma/Kconfig Tue Apr 27 20:48:50 2010 +0400
> >> +++ b/drivers/dma/Kconfig Wed Apr 28 02:00:51 2010 +0400
> >> @@ -97,6 +97,14 @@
> >> Support the TXx9 SoC internal DMA controller. This can be
> >> integrated in chips such as the Toshiba TX4927/38/39.
> >>
> >> +config XLLSDMA
>
> I'd prefer XILINX_LLSDMA. XLLSDMA could be ambiguous in the global
> namespace (for a human reader), particularly as it is something that
> few people will actually see.
I've changed it to XILINX_SDMA in the current version.
>
> >> + bool "Xilinx MPMC DMA support"
> >> + depends on XILINX_VIRTEX || MICROBLAZE
> >> + select DMA_ENGINE
> >> + help
> >> + Support fot Xilinx MPMC LocalLink SDMA. Virtex FPGA family
> >> + has it integrated or fabric-based.
> >> +
> >
> > fot --> for
> >
> > Since the xllsdma driver provides services to other drivers - not to
> > userland - I think this would be better as a "silent" option, selected
> > automatically when something like ll_temac or the forthcoming Xilinx DMA
> > engine is selected. If we do it that way, note that XLLSDMA is
> > independent of DMA_ENGINE so drivers/Makefile will need to be patched so
> > that the dma subdirectory is always "y".
>
> Agreed. However, looking at this code, I don't see anything that
> actually uses DMA_ENGINE here. Am I missing something?
It's because the appropriate line in drivers/Makefile is
obj-$(CONFIG_DMA_ENGINE) += dma/
instead of
obj-$(CONFIG_DMADEVICES) += dma/
>
> >> diff -r baced9e29ab5 drivers/dma/Makefile
> >> --- a/drivers/dma/MakefileTue Apr 27 20:48:50 2010 +0400
> >> +++ b/drivers/dma/MakefileWed Apr 28 02:00:51 2010 +0400
> >> @@ -10,3 +10,4 @@
> >> obj-$(CONFIG_AT_HDMAC) += at_hdmac.o
> >> obj-$(CONFIG_MX3_IPU) += ipu/
> >> obj-$(CONFIG_TXX9_DMAC) += txx9dmac.o
> >> +obj-$(CONFIG_XLLSDMA) += xllsdma.o
> >> diff -r baced9e29ab5 drivers/dma/xllsdma.c
> >> --- /dev/null Thu Jan 01 00:00:00 1970 +
> >> +++ b/drivers/dma/xllsdma.c Wed Apr 28 02:00:51 2010 +0400
> >> @@ -0,0 +1,887 @@
> >> +/*
> >> + * SDMA subsystem support for Xilinx MPMC.
> >> + *
> >> + * Author: Sergey Temerkhanov
> >> + * Platform Bus by Steven J. Magnani
> >> + *
> >> + * Copyright (c) 2008-2010 Cifronic ZAO
> >> + *
> >> + * This program is free software; you can redistribute it and/or
> >> modify it + * under the terms of the GNU General Public License as
> >> published by the + * Free Software Foundation; either version 2 of the
> >> License, or (at your + * option) any later version.
> >> + *
> >> + */
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +#include
> >> +#include
> >> +
> >> +#define DRV_VERSION "0.1.0"
>
> Irrelevant, can be dropped
>
> >> +#define DRV_NAME "sdma"
>
> Used only once, drop.
>
> >> +
> >> +MODULE_AUTHOR("Sergey Temerkhanov ");
> >> +MODULE_DESCRIPTION("Xilinx SDMA driver");
> >> +MODULE_LICENSE("GPL");
> >> +MODULE_VERSION(DRV_VERSION);
> >> +
> >> +LIST_HEAD(mpmc_devs);
> >> +DEFINE_MUTEX(mpmc_devs_lock);
> >> +
> >> +void xllsdma_tx_irq_enable(struct xllsdma_device *sdma)
> >> +{
> >> + u32 tx_cr;
> >> + unsigned long flags;
> >> +
> >> + BUG_ON(sdma->tx_irq == NO_IRQ);
> >> +
> >> + spin_lock_irqsave(&sdma->lock, flags);
> >> + tx_cr = xllsdma_tx_in32(sdma, XLLSDMA_CR);
> >> + xllsdma_tx_out32(sdma, XLLSDMA_CR, tx_cr | XLLSDMA_CR_IRQ_EN);
> >> + spin_unlock_irqrestore(&sdma->lock, flags);
>
> This pattern is used a lot. Might be worth while to implement
> xllsdma_tx_* variants of setbits32, clrbits32 and clrsetbits32.
>
> Also, there are a lot of these little functions; really trivial and
> small. Would it be better to have them as static inlines in the
> header file instead of exported globals?
Well, I can do this but it will require moving of register definitions to
xllsdma.h
>
> >> +}
> >> +EXPORT_SYMBOL_GPL(xllsdma_tx_irq_enable);
> >> +
> >> +void xllsdma_rx_irq_enable(struct xllsdma_device *sdma)
> >> +{
> >> + u32 rx_cr;
> >> + unsigned long flags;
> >> +
> >> + BUG_ON(sdma->rx_irq == NO_IRQ);
> >> +
> >> + spin_lock_irqsave(&sdma->lock, flags);
> >>
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Wed, Apr 28, 2010 at 2:35 PM, Timur Tabi wrote:
> On Tue, Apr 27, 2010 at 5:09 AM, Benjamin Herrenschmidt
> wrote:
>
>> Keep in mind that it's perfectly kosher to create nodes for "virtual"
>> devices. IE. We could imagine a node for the "sound subsystem" that
>> doesn't actually correspond to any physical device but contain the
>> necessary properties that binds everything together. You could even have
>> multiple of these if you have separate set of sound HW that aren't
>> directly dependant.
>
> First, I want to officially retract this patch. I've talked with
> Grant, and we've come up with a different approach to this problem.
>
> Second, how about this binding for the virtual sound node? It would
> be a root-level node.
>
> sound-devices {
> sound0 {
> ssi = &ssi0;
> playback-dma = &dma00;
> capture-dma = &dma01;
> codec = &cs4270;
> }
> };
The sound0 node needs a compatible value, the sound-device node should
probably have one too.
The sound0 node should have something board specific like
"fsl,mpc8610hpcd-sound" to make it clear that the binding really only
applies to this particular board. It would also be a good idea to
prefix all of the property names with 'fsl,' to avoid conflicting with
any future common bindings or conventions. Other boards can use the
same binding, but they would get a different compatible value (the
driver could bind on both).
I'm not a huge fan of the name "sound-devices" for the parent node.
There are other sorts of things that we need 'virtual' device nodes to
describe. It would be nice to have a single place for collecting
nodes for stuff like this. Perhaps this:
system {
compatible = "system-devices";
sound0 {
compatible = "fsl,mpc8610hpcd-sound";
fsl,ssi = &ssi0;
fsl,playback-dma = &dma00;
fsl,capture-dma = &dma01;
fsl,codec = &cs4270;
};
};
But I really don't have any knowledge of what has been done previously
in this regard or if any conventions have been established. Ben, any
thoughts?
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] genirq: reliably replay pending edge-triggered irq
On Tue, 27 Apr 2010 15:42:11 +0200 (CEST) Thomas Gleixner wrote: > On Thu, 22 Apr 2010, Guillaume Knispel wrote: [snip] > > acked and masked at controller level and IRQ_PENDING is set. > > --- > > arch/arm/Kconfig |4 > > arch/arm/configs/acs5k_defconfig |1 - > > arch/arm/configs/acs5k_tiny_defconfig |1 - > >Changing the defconfigs should be a separate patch and I'm not >going to push such a thing through the genirq tree. The stale >entries do not hurt. Ok In this separate patch, to I put "genirq" in the title? Do I put it in the same series? Cheers, Guillaume Knispel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, Apr 27, 2010 at 5:09 AM, Benjamin Herrenschmidt
wrote:
> Keep in mind that it's perfectly kosher to create nodes for "virtual"
> devices. IE. We could imagine a node for the "sound subsystem" that
> doesn't actually correspond to any physical device but contain the
> necessary properties that binds everything together. You could even have
> multiple of these if you have separate set of sound HW that aren't
> directly dependant.
First, I want to officially retract this patch. I've talked with
Grant, and we've come up with a different approach to this problem.
Second, how about this binding for the virtual sound node? It would
be a root-level node.
sound-devices {
sound0 {
ssi = &ssi0;
playback-dma = &dma00;
capture-dma = &dma01;
codec = &cs4270;
}
};
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc/mpc5121: shared DIU framebuffer support
Hi Grant,
Thanks for review and comments. I'm back to this now and hope
to address your comments soon.
On Sat, 27 Feb 2010 23:50:09 -0700
Grant Likely wrote:
> On Sat, Feb 27, 2010 at 2:58 PM, Anatolij Gustschin wrote:
> > MPC5121 DIU configuration/setup as initialized by the boot
> > loader currently will get lost while booting Linux. As a
> > result displaying the boot splash is not possible through
> > the boot process.
> >
> > To prevent this we reserve configured DIU frame buffer
> > address range while booting and preserve AOI descriptor
> > and gamma table so that DIU continues displaying through
> > the whole boot process. On first open from user space
> > DIU frame buffer driver releases the reserved frame
> > buffer area and continues to operate as usual.
> >
> > The patch also moves drivers/video/fsl-diu-fb.h file to
> > include/linux as we use some DIU structures in platform
> > code.
> >
> > 'diu_ops' callbacks in platform code borrowed from John's
> > DIU code.
> >
> > Signed-off-by: John Rigby
> > Signed-off-by: Anatolij Gustschin
> > Cc: Grant Likely
>
> On quick glance this patch seems mostly okay, but this patch should
> probably be broken up a bit to simplify review and dissociate
> unrelated changes. For example, the move of fsl-diu-fb.h is a
> discrete change that should be split off. Some more comments
> below
I will split off fsl-diu-fb.h move to separate patch.
...
> > diff --git a/arch/powerpc/platforms/512x/mpc5121_generic.c
> > b/arch/powerpc/platforms/512x/mpc5121_generic.c
> > index a6c0e3a..3aaa281 100644
> > --- a/arch/powerpc/platforms/512x/mpc5121_generic.c
> > +++ b/arch/powerpc/platforms/512x/mpc5121_generic.c
> > @@ -28,6 +28,7 @@
> > */
> > static char *board[] __initdata = {
> > "prt,prtlvt",
> > + "ifm,pdm360ng",
>
> You're adding a new board here. This is completely unrelated.
Yes, it is unrelated. This hunk sneaked in by accident, will drop it.
...
> > diff --git a/arch/powerpc/platforms/512x/mpc512x.h
> > b/arch/powerpc/platforms/512x/mpc512x.h
> > index d72b2c7..1cfe9d5 100644
> > --- a/arch/powerpc/platforms/512x/mpc512x.h
> > +++ b/arch/powerpc/platforms/512x/mpc512x.h
> > @@ -17,4 +17,7 @@ extern int __init mpc5121_clk_init(void);
> > void __init mpc512x_declare_of_platform_devices(void);
> > extern void mpc512x_restart(char *cmd);
> > extern void __init mpc5121_usb_init(void);
> > +extern void __init mpc512x_init_diu(void);
> > +extern void __init mpc512x_setup_diu(void);
>
> __init annotations do not belong in header files.
Ok, I will remove them.
> > +extern struct fsl_diu_shared_fb diu_shared_fb;
>
> H. I'm not fond of the global data structure. Especially
> considering that the struct fsl_diu_shared_fb is defined in
> mpc512x_shared.c, so nothing outside of that .c file can do anything
> with the structure.
This is a remainder from early debugging code, will remove it.
> > #endif /* __MPC512X_H__ */
> > diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c
> > b/arch/powerpc/platforms/512x/mpc512x_shared.c
> > index fbdf65f..a8c50a6 100644
> > --- a/arch/powerpc/platforms/512x/mpc512x_shared.c
> > +++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
> > @@ -16,7 +16,11 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > +#include
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -53,6 +57,284 @@ void mpc512x_restart(char *cmd)
> > ;
> > }
> >
> > +struct fsl_diu_shared_fb {
> > + char gamma[0x300]; /* 32-bit aligned! */
> > + struct diu_ad ad0; /* 32-bit aligned! */
> > + phys_addr_t fb_phys;
> > + size_t fb_len;
> > + bool in_use;
> > +};
> > +
> > +unsigned int mpc512x_get_pixel_format(unsigned int bits_per_pixel,
> > + int monitor_port)
> > +{
> > + unsigned int pix_fmt;
> > +
> > + switch (bits_per_pixel) {
> > + case 32:
> > + pix_fmt = 0x3316;
> > + break;
> > + case 24:
> > + pix_fmt = 0x88082219;
> > + break;
> > + case 16:
> > + pix_fmt = 0x65053118;
> > + break;
> > + default:
> > + pix_fmt = 0x0400;
> > + }
> > + return pix_fmt;
> > +}
> > +
> > +void mpc512x_set_gamma_table(int monitor_port, char *gamma_table_base)
> > +{
> > +}
> > +
> > +void mpc512x_set_monitor_port(int monitor_port)
> > +{
> > +}
> > +
> > +#define CCM_SCFR1 0x000c
> > +#define DIU_DIV_MASK 0x00ff
> > +void mpc512x_set_pixel_clock(unsigned int pixclock)
> > +{
> > + unsigned long bestval, bestfreq, speed_ccb, busfreq;
> > + unsigned long minpixclock, maxpixclock, pixval;
> > + struct device_node *np;
> > + void __iomem *ccm;
> > + u32 temp;
> > + long err;
> > + int i;
> > +
> > + np = of_find_compati
Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300
On Wed, 28 Apr 2010 14:15:50 -0500 Xianghua Xiao wrote: > On Wed, Apr 28, 2010 at 2:22 AM, Benjamin Herrenschmidt > wrote: > > So we tried to speed things up a bit using flush_hash_pages() directly > > but that falls over on 603 of course meaning we fail to flush the TLB > > properly and we may even end up having it corrupt memory randomly by > > accessing a hash table that doesn't exist. > > > > This removes the "optimization" by always going through flush_tlb_page() > > for now at least. > > > > Signed-off-by: Benjamin Herrenschmidt > > --- > > Somebody with a 603 or e300 core based FSL SoC to try this out for me ? > > > This change works me on a 834x(e300) platform, tested with lmbench and > a production-ready application with 2.6.33.3. moi aussi, Ben: booted this on an 8377 and started a kernel build. It seems to be progressing normally, I'm just not going to wait for it to complete before hitting send :). Kim ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Fix DEBUG_PAGEALLOC on 603/e300
On Wed, Apr 28, 2010 at 2:22 AM, Benjamin Herrenschmidt wrote: > So we tried to speed things up a bit using flush_hash_pages() directly > but that falls over on 603 of course meaning we fail to flush the TLB > properly and we may even end up having it corrupt memory randomly by > accessing a hash table that doesn't exist. > > This removes the "optimization" by always going through flush_tlb_page() > for now at least. > > Signed-off-by: Benjamin Herrenschmidt > --- > > Somebody with a 603 or e300 core based FSL SoC to try this out for me ? > > It's obviously completely untested :-) > > Cheers, > Ben. > > diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c > index b9243e7..95774b4 100644 > --- a/arch/powerpc/mm/pgtable_32.c > +++ b/arch/powerpc/mm/pgtable_32.c > @@ -385,11 +385,7 @@ static int __change_page_attr(struct page *page, > pgprot_t prot) > return -EINVAL; > __set_pte_at(&init_mm, address, kpte, mk_pte(page, prot), 0); > wmb(); > -#ifdef CONFIG_PPC_STD_MMU > - flush_hash_pages(0, address, pmd_val(*kpmd), 1); > -#else > flush_tlb_page(NULL, address); > -#endif > pte_unmap(kpte); > > return 0; > > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > This change works me on a 834x(e300) platform, tested with lmbench and a production-ready application with 2.6.33.3. Xianghua ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [microblaze-uclinux] [PATCHv2] [RFC] Xilinx MPMC SDMA subsystem
Grant -
Thanks for the feedback. My responses are inline.
--Steve
On Tue, 2010-04-27 at 23:13 -0600, Grant Likely wrote:
> Hi Sergey and Steven,
>
> On Tue, Apr 27, 2010 at 8:29 PM, Steven J. Magnani
> wrote:
> > On Wed, 2010-04-28 at 02:06 +0400, Sergey Temerkhanov wrote:
> >> This is the 2nd version of Xilinx MPMC LocalLink SDMA subsystem
> >>
[snip]
> >> diff -r baced9e29ab5 drivers/dma/Kconfig
> >> --- a/drivers/dma/Kconfig Tue Apr 27 20:48:50 2010 +0400
> >> +++ b/drivers/dma/Kconfig Wed Apr 28 02:00:51 2010 +0400
> >> @@ -97,6 +97,14 @@
> >> Support the TXx9 SoC internal DMA controller. This can be
> >> integrated in chips such as the Toshiba TX4927/38/39.
> >>
> >> +config XLLSDMA
>
> I'd prefer XILINX_LLSDMA. XLLSDMA could be ambiguous in the global
> namespace (for a human reader), particularly as it is something that
> few people will actually see.
>
> >> + bool "Xilinx MPMC DMA support"
> >> + depends on XILINX_VIRTEX || MICROBLAZE
> >> + select DMA_ENGINE
> >> + help
> >> + Support fot Xilinx MPMC LocalLink SDMA. Virtex FPGA family
> >> + has it integrated or fabric-based.
> >> +
> >
> > fot --> for
> >
> > Since the xllsdma driver provides services to other drivers - not to
> > userland -
> > I think this would be better as a "silent" option, selected automatically
> > when
> > something like ll_temac or the forthcoming Xilinx DMA engine is selected.
> > If we do it that way, note that XLLSDMA is independent of DMA_ENGINE so
> > drivers/Makefile will need to be patched so that the dma subdirectory is
> > always "y".
>
> Agreed. However, looking at this code, I don't see anything that
> actually uses DMA_ENGINE here. Am I missing something?
This is a low-level driver that provides services to ll_temac and the
(still in the works) DMA engine driver. There's no real relationship
between this driver and DMA_ENGINE, and the still-in-the-works driver
will come later after we stabilize the interface of this one.
> >> +++ b/drivers/dma/xllsdma.c Wed Apr 28 02:00:51 2010 +0400
[snip]
> >> +
> >> +static int __devinit mpmc_of_probe(struct of_device *op,
> >> + const struct of_device_id *match)
> >> +{
> >> + int err = mpmc_init(&op->dev);
> >> + if (err)
> >> + return err;
> >> +
> >> + of_platform_bus_probe(op->node, xllsdma_of_match, &op->dev);
> >> + return 0;
> >> +}
>
> Okay, I think I've figured out what is bothering me
>
> While this *does* work; it really is the long way to go about things.
> Doing it this way requires going back out to the driver model to tell
> it things and trigger a probe on things that *this* driver needs, and
> *this* driver already knows about. It doesn't need to be this
> complex.
>
> Rather than register a bunch more of_platform devices, do something
> like this instead:
>
> +static int __devinit mpmc_of_probe(struct of_device *op,
> + const struct of_device_id *match)
> +{
> + struct mpmc_device *mpmc;
> + struct device_node *node;
> +
> + mpmc = mpmc_init(&op->dev);
> + if (!mpmc)
> + return -ENODEV;
> +
> + for_each_child_of_node(op->node, node) {
> + xllsdma_of_init(mpmc, node);
> + }
> + return 0;
> +}
>
> You do *not* need to register a separate struct device for each DMA
> channel sub node (at least with regard to the driver model; I don't
> know about the dma subsystem). If you *want* a struct device, then
> xllsdma_of_init() is free to register one, but it does not need to be
> on the of_platform_bus, and this driver should not require a probe
> step for each DMA channel.
The DMA engine driver (and ll_temac, I imagine) will gain access to this driver
via xllsdma_find_device().
They should not need a struct device.
[snip]
> >> +#else/* CONFIG_OF */
>
> Why else? It is perfectly valid to have both of_platform and platform
> bus bindings. That being said, this split will become unnecessary in
> the very near future. I've eliminated of_platform_bus_type, and
> automatically moved all users of it over to the platform bus (without
> driver changes).
Agreed. It would help to have an idea of the timeline for the
convergence. I haven't been following any OF-related discussions on
LKML; I'll try to pay more attention.
>
> However, current powerpc and microblaze code makes CONFIG_OF
> manditory. What condition will compile in the platform bus
> attachment?
At the moment, none in mainline. See my next comment.
>
> >> +/*---
> >> + * Platform bus attachment
> >> + */
> >> +
> >> +static __devexit int xllsdma_plat_remove(struct platform_device *pdev)
> >> +{
> >> + xllsdma_cleanup(&pdev->dev);
> >> + return 0;
> >> +}
> >> +
> >> +static int __devinit xllsdma_plat_probe(struct platform_device *pdev)
> >> +{
> >> + struct resource *rx_irq, *tx_irq, *mem;
> >> +
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
Grant Likely wrote:
> Didn't you just finish saying that you cannot see any situation where
> you would want the SSI devices linked into a single audio device? So
> then if both SSIs are being used for audio, then do you not need a
> machine driver for each ssi?
That's right. But in order for my fabric/machine driver to be called at all, I
thought I needed to make it a platform driver and use
platform_device_register_simple() and platform_driver_register().
>> Are you saying that I should call platform_device_register_simple()
>> from the SSI's driver initialization function, fsl_ssi_init()?
>
> No, I'm saying call it from the probe hook.
But then platform_device_register_simple() will be called twice, and it should
be called only once.
I must be missing something here.
> However, you should probably do a two stage platform_device_alloc() /
> platform_device_add() so you can add data (node pointer) to the
> platform device before it gets probed by the machine driver.
Don't you mean platform_device_add_resources() instead of
platform_device_add()? That is, use platform_device_add_resources() too add
information about each SSI that gets probed, and then after all of the SSIs are
probed, then call platform_device_add().
If that's what you mean, then where do I call platform_device_add()?
> I'm not talking about platform_data or about the ssi driver decoding
> things that the machine driver needs. I'm talking about giving the
> machine driver a pointer to the ssi device tree node so you don't need
> to go through weird gymnastics to find the correct node again.
The only gymnastics I need to go through is this:
while ((np = of_find_compatible_node(np, NULL, "fsl,mpc8610-ssi"))) {
This finds every SSI node. I then extract the information from the SSI nodes
and all the other nodes, and then register it with ASoC.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Wed, Apr 28, 2010 at 10:20 AM, Timur Tabi wrote: > On Wed, Apr 28, 2010 at 8:57 AM, Grant Likely > wrote: > >> I'm just saying move the registration of the machine device out of >> arch/powerpc platform code and into the ssi driver. > > But the SSI driver is an OF driver, and it gets probed for every SSI > node in the device tree. On the 8610, that means being probed twice. > But I should only call platform_device_register_simple() once. Didn't you just finish saying that you cannot see any situation where you would want the SSI devices linked into a single audio device? So then if both SSIs are being used for audio, then do you not need a machine driver for each ssi? > Are you saying that I should call platform_device_register_simple() > from the SSI's driver initialization function, fsl_ssi_init()? No, I'm saying call it from the probe hook. However, you should probably do a two stage platform_device_alloc() / platform_device_add() so you can add data (node pointer) to the platform device before it gets probed by the machine driver. >> Then you've got a >> reasonable place to pass shared data (either the ssi device node or >> device instance or name. Whatever you need) to the machine driver. > > The problem is that the fabric driver needs much more information from > the device tree than the SSI driver needs. So if the SSI driver is > going to pass that information to the fabric driver via the platform > data, it's going to have to know what information the fabric driver > needs. Then the SSI driver is not board-independent. I'm not talking about platform_data or about the ssi driver decoding things that the machine driver needs. I'm talking about giving the machine driver a pointer to the ssi device tree node so you don't need to go through weird gymnastics to find the correct node again. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Wed, Apr 28, 2010 at 8:57 AM, Grant Likely wrote: > I'm just saying move the registration of the machine device out of > arch/powerpc platform code and into the ssi driver. But the SSI driver is an OF driver, and it gets probed for every SSI node in the device tree. On the 8610, that means being probed twice. But I should only call platform_device_register_simple() once. Are you saying that I should call platform_device_register_simple() from the SSI's driver initialization function, fsl_ssi_init()? > Then you've got a > reasonable place to pass shared data (either the ssi device node or > device instance or name. Whatever you need) to the machine driver. The problem is that the fabric driver needs much more information from the device tree than the SSI driver needs. So if the SSI driver is going to pass that information to the fabric driver via the platform data, it's going to have to know what information the fabric driver needs. Then the SSI driver is not board-independent. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/4xx: Add optional "reset_type" property to control reboot via dts
On Wed, Apr 28, 2010 at 10:13:34AM +0200, Stefan Roese wrote:
>By setting "reset_type" to one of the following values, the default
>software reset mechanism may be overidden. Here the possible values of
>"reset_type":
>
> 1 - PPC4xx core reset
> 2 - PPC4xx chip reset
> 3 - PPC4xx system reset (default)
>
>This will be used by a new PPC440SPe board port, which needs a "chip
>reset" instead of the default "system reset" to be asserted.
>
>Signed-off-by: Stefan Roese
>Cc: Josh Boyer
>Cc: Benjamin Herrenschmidt
>---
>v2:
>- Add small property description to Documentation
>- Add sanity check for property value
Thanks for the quick respin.
Acked-by: Josh Boyer
Ben, I don't have anything else pending for -next at the moment. Can you pick
this up yourself, or do you want me to create a pull request for just this
patch?
josh
>
> Documentation/powerpc/dts-bindings/4xx/reboot.txt | 18 +++
> arch/powerpc/sysdev/ppc4xx_soc.c | 24 +++-
> 2 files changed, 40 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/4xx/reboot.txt
>
>diff --git a/Documentation/powerpc/dts-bindings/4xx/reboot.txt
>b/Documentation/powerpc/dts-bindings/4xx/reboot.txt
>new file mode 100644
>index 000..d721726
>--- /dev/null
>+++ b/Documentation/powerpc/dts-bindings/4xx/reboot.txt
>@@ -0,0 +1,18 @@
>+Reboot property to control system reboot on PPC4xx systems:
>+
>+By setting "reset_type" to one of the following values, the default
>+software reset mechanism may be overidden. Here the possible values of
>+"reset_type":
>+
>+ 1 - PPC4xx core reset
>+ 2 - PPC4xx chip reset
>+ 3 - PPC4xx system reset (default)
>+
>+Example:
>+
>+ c...@0 {
>+ device_type = "cpu";
>+ model = "PowerPC,440SPe";
>+ ...
>+ reset-type = <2>; /* Use chip-reset */
>+ };
>diff --git a/arch/powerpc/sysdev/ppc4xx_soc.c
>b/arch/powerpc/sysdev/ppc4xx_soc.c
>index 5c01435..d3d6ce3 100644
>--- a/arch/powerpc/sysdev/ppc4xx_soc.c
>+++ b/arch/powerpc/sysdev/ppc4xx_soc.c
>@@ -191,11 +191,31 @@ static int __init ppc4xx_l2c_probe(void)
> arch_initcall(ppc4xx_l2c_probe);
>
> /*
>- * At present, this routine just applies a system reset.
>+ * Apply a system reset. Alternatively a board specific value may be
>+ * provided via the "reset-type" property in the cpu node.
> */
> void ppc4xx_reset_system(char *cmd)
> {
>- mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) | DBCR0_RST_SYSTEM);
>+ struct device_node *np;
>+ u32 reset_type = DBCR0_RST_SYSTEM;
>+ const u32 *prop;
>+
>+ np = of_find_node_by_type(NULL, "cpu");
>+ if (np) {
>+ prop = of_get_property(np, "reset-type", NULL);
>+
>+ /*
>+ * Check if property exists and if it is in range:
>+ * 1 - PPC4xx core reset
>+ * 2 - PPC4xx chip reset
>+ * 3 - PPC4xx system reset (default)
>+ */
>+ if ((prop) && ((prop[0] >= 1) && (prop[0] <= 3)))
>+ reset_type = prop[0] << 28;
>+ }
>+
>+ mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) | reset_type);
>+
> while (1)
> ; /* Just in case the reset doesn't work */
> }
>--
>1.7.1
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Wed, Apr 28, 2010 at 7:35 AM, Timur Tabi wrote: > On Wed, Apr 28, 2010 at 12:37 AM, Grant Likely > wrote: > >> Why not? Just have the ssi driver probe routine register the fabric >> device based on the existence of the codec-handle property. It is the >> best way to go about things with the data that you've got available, >> and it is no big deal. The relevant fabric driver can then bind >> against that. You should probably also stuff the ssi device node >> pointer into the fabric device of_node pointer. > > And then where do I put the board-specific initialization code that's > currently in the fabric driver? The programming information for that > initialization is not in the device tree. In the fabric driver; where it is right now. I'm saying *instantiate* the device when the ssi driver gets probed. Use the top level board name when assigning the name so that the correct asoc machine driver gets bound to it. > It sounds to me like you're saying I should take all the code from the > fabric driver and shove it into the SSI driver, just so that I can > avoid instantiating a platform driver. Nope. > Keep in mind that asoc likes to have a different struct device for the > fabric driver and the SSI nodes, so I would need to manually create a > struct device for the fabric device anyway. You can do it this way too, but this is not what I'm saying. >> Linux struct device registrations are cheap, and every struct device >> has a device_node pointer available. It is totally fine to have both >> the ssi device and the fabric device point to the same device node if >> that helps solve your problem of finding references to the right >> things in each driver. (Just as long as only one of them is an >> of_platform driver). > > But I already have it set up like that. The SSI driver is an OF > driver, and the fabric driver is a platform driver. I might be able > to move some code from the fabric driver into the SSI driver to make > it the fabric driver less obnoxious about scanning the device tree. I'm just saying move the registration of the machine device out of arch/powerpc platform code and into the ssi driver. Then you've got a reasonable place to pass shared data (either the ssi device node or device instance or name. Whatever you need) to the machine driver. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] video: add support for getting video mode from device tree
On Mon, 01 Mar 2010 14:45:20 +1100
Benjamin Herrenschmidt wrote:
> On Sat, 2010-02-27 at 22:44 -1000, Mitch Bradley wrote:
>
> > As it turns out, I'm doing exactly that - exporting verbatim EDID
> > data
> > as the value of the "edid" property - for the display node on the Via
> > version of the OLPC machine. The kernel driver uses it instead of
> > trying to obtain the EDID data from the monitor, because the builtin
> > OLPC display cannot supply EDID data through the usual hardware
> > interfaces.
>
> This is actually a common practice (though EDID is most often in
> uppercase) on Apple hardware too. It has issues though in the sense that
> it doesn't carry proper connector information and falls over in many
> multi-head cases.
>
> I think passing the EDID data, when available, is thus the right thing
> to do indeed, however that doesn't solve two problems:
>
> - Where to put that property ? This is a complicated problem and we
> might argue on a binding for weeks because video cards typically support
> multiple outputs, etc. etc... I think the best for now is to stick as
> closely as possible to the existing OF fb binding, and have "display"
> nodes for each output, which can eventually contain an EDID. We might
> also want to add a string that indicate the connector type. Specific
> drivers might want to define additional properties here where it makes
> sense such as binding of those outputs to CRTCs or such, up to you.
Putting EDID to display node would be really sufficient for LCDs in
our case. Other systems might define this additional connector type
property.
>
> - We -also- want a way to specify the "default" mode as set by the
> firmware, at least on some devices. The EDID gives capabilities, and
> often for LCDs also the "preferred" mode which is almost always the
> "default" mode ... but could be different. In order to avoid "flicking",
> the driver might wants to know what is the currently programmed mode.
> For that, having split out properties makes sense, though I would like
> to either prefix them all with "mode," or stick them in a sub-node of
> the disp...@.
I would propose defining following properties in the case the
programmed mode is different from "default" mode:
disp...@...{
compatible = ","
EDID = [edid-data];
current-mode {
pixel_clock = ;
horizontal_active = ;
horizontal_blank = ;
vertical_active = ;
vertical_blank = ;
horizontal_active = ;
hsync_offset = ;
hsync_pulse_width = ;
vsync_offset = ;
vsync_pulse_width = ;
hsync_positive;
vsync_positive;
}
};
The firmware can set the "default" mode using the EDID's preferred
Detailed Timing Descriptor data. If on some devices it sets another
mode than the preferred mode, then the firmware can insert a
"current-mode" sub-node with currently programmed mode. The driver
can check for this sub-node and use it's data and if it isn't present,
it can use the preferred timing data from EDID. The names of the
properties here are actually what Detailed Timing Descriptor in EDID
specifies. What do you think?
Thanks,
Anatolij
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Wed, Apr 28, 2010 at 08:19:00AM -0500, Timur Tabi wrote: > On Tue, Apr 27, 2010 at 5:29 PM, Mark Brown > > You also want to be representing unused pins here. > If they're unused, how do I represent them? Can you give me an example? You should arrange for something to call snd_soc_dapm_nc_pin() on any unconnected pins. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Wed, Apr 28, 2010 at 12:37 AM, Grant Likely wrote: > Why not? Just have the ssi driver probe routine register the fabric > device based on the existence of the codec-handle property. It is the > best way to go about things with the data that you've got available, > and it is no big deal. The relevant fabric driver can then bind > against that. You should probably also stuff the ssi device node > pointer into the fabric device of_node pointer. And then where do I put the board-specific initialization code that's currently in the fabric driver? The programming information for that initialization is not in the device tree. It sounds to me like you're saying I should take all the code from the fabric driver and shove it into the SSI driver, just so that I can avoid instantiating a platform driver. Keep in mind that asoc likes to have a different struct device for the fabric driver and the SSI nodes, so I would need to manually create a struct device for the fabric device anyway. >> I don't know when I would ever do this. The two SSI devices are completely >> independent. Why would I bind them together into one "device"? > > If there is no use case for binding them together, then you're right. > The current binding is probably just fine. I cannot comment on > whether or not it will be used that way by platform designers. Although the 8610 has two SSI devices, the reference board we ship only has one wired up. I have a prototype board in the lab that has both wired up, but even then, I don't think I can get the two SSIs synchronized in any meaningful fashion. Mark suggested a technique, but even if I could get that to work, the driver code would need to be rewritten to handle two SSI devices in concert. In short, it might be theoretically possible, but I'm not going to try to make it work. > Linux struct device registrations are cheap, and every struct device > has a device_node pointer available. It is totally fine to have both > the ssi device and the fabric device point to the same device node if > that helps solve your problem of finding references to the right > things in each driver. (Just as long as only one of them is an > of_platform driver). But I already have it set up like that. The SSI driver is an OF driver, and the fabric driver is a platform driver. I might be able to move some code from the fabric driver into the SSI driver to make it the fabric driver less obnoxious about scanning the device tree. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, Apr 27, 2010 at 5:29 PM, Mark Brown
wrote:
>> codec1 :co...@4f {
>> compatible = "cirrus,cs4270";
>> reg = <0x4f>;
>> /* MCLK source is a stand-alone oscillator */
>> clock-frequency = <12288000>;
>> };
>
> You also want to be representing unused pins here.
If they're unused, how do I represent them? Can you give me an example?
>> [...]
>> ssi1: s...@16000 {
>> compatible = "fsl,mpc8610-ssi";
>> [...]
>> fsl,mode = "i2s-slave";
>
> I'd not include the master/slave decision; it's either implied by the
> fact that the CODEC has a standalone clock, a property of the link/card,
> or a policy decision that the running software can change on a whim.
I know it's redundant, but at the time, it seemed a lot simpler than
walking the device tree.
Frankly, I'd rather not consider minor device tree changes at this
point. I'm hoping I don't need to change the device tree at all.
>> sound {
>> compatible = "fsl,mpc8610-hpcd-sound";
>> /* maybe something like (totally off the top of my head) */
>> dai-links = <&ssi1 0 &codec 0
>> &ssi1 1 &codec 1>;
>
> I'm having a hard time loving this. I'd be looking for a lot more
> semantics on the links (things like information about separate clocks
> for the two directions, for example) which makes me think that that
> simple list format is far too simple and you want a list of more complex
> objects.
Yeah, I don't like it either. It seems arbitrary.
> I think the ideal is something that's purely descriptive of the hardware
> and doesn't include any policy decisions.
I like to think that this is what we have today.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Wed, Apr 28, 2010 at 02:25:29PM +1000, Benjamin Herrenschmidt wrote: > I'd stay stick to the basics and move incrementally up until it stops > making sense: > - First, the basics: nodes for actual physical devices. i2c codecs on > their i2c busses, DMA controllers, etc... This is already supported by the ASoC core and has been for about a year or so, it just needs the device drivers to make use of it. IIRC the drivers relevant to PowerPC are pretty much doing so already, but I didn't actually check. > - From there, see what simple properties are better off being put in > those respective nodes because they represent common enough variants of > functionality or simply because they are specific attributes of a given > device that aren't too concerned by the way things are interconnected. This one is just a case of writing boiler plate for the existing platform data devices have to convert that from device tree into the existing formats. It's not a monumentally edifying task, but I don't think we really need to worry about it here. > - Provide at least one identifier (either in a "sound" virtual device, > or just use the board's own "compatible" property) to have a .c file to > put everything together. This has been the big sticking point so far. It has been difficult to get people to accept this idea at all, the idea that there may be more to the machine specific setup than can be readily expressed in static data and might even vary dynamically at runtime is what seems to upset people. I've been told on a number of occasions that instantiating machine specific code that's not part of a specific chip is very difficult and would cause the device tree to be horribly buggy. What you're suggesting here is exactly what is supposed to happen from an ASoC point of view. > The whole thing is a matter of common sense and a bit of taste :-) The impression that has been created in the past is that there are inflexible device tree rules which can't be varied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, 2010-04-27 at 14:27 -0600, Grant Likely wrote: > > Unfortunately, I'm in the same boat. :-( However, I'll be at UDS in > 2 weeks time, and I know audio is a big concern for the Ubuntu folks. > A bunch of the ARM vendors will be there too. I'll schedule a session > to talk about audio bindings and hopefully that way make some headway > on defining a binding that makes sense and is actually useful. It's not clear if I'm going to UDS atm, but I'll join via IRC. Graeme is going to UDS so he will probably pop in to the discussion if he's free. Liam ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Wed, Apr 28, 2010 at 02:10:11PM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2010-04-27 at 23:29 +0100, Mark Brown wrote: > > On the other hand from a pragmatic point of view it's just much less > > hassle to just only provide the mechanism for instantiating a machine > > with custom code and use that for everything. > Right, that's the balance to find. A too descriptive device-tree becomes > a mess, and attempting to deal with any kind of representation in SW is > horrible. Sadly this often seems to be what the device tree folks are pushing for. I really want whatever you guys come up with to explicitly say that it's OK to just write standard code like we have at the minute and not faff around defining device tree representations for everything so that we can just point people at that when the discussion gets too bogged down. > For example, one could imagine a /sound node with simply a "compatible" > property that matches what we call in AOA terminology a "fabric" driver. > IE. The one thing specific to the board that puts bits and pieces > together. This is the current ASoC design (someone probably ought to look at merging AOA into ASoC, it's approximately the same hardware and at least the CPU driver ought to be useful for other systems). > Now, the device-tree is still obviously useful to provide things like > the actual i2c IDs of codecs, GPIOs used for various actions, link to > from various components to their clock source devices, etc.. All these > things simplify the code, avoids horrid board specific code in the > actual drivers (codecs, busses, etc...) and overall help keeping the > code more maintainable. You're preaching to the choir here. With ASoC all this system specific code ends up in the machine driver (which you guys are calling the fabric driver). All the design stuff you're talking about here is already dealt with as-is, it's just that the parameterisation is done with C code and data structures in the kernel (which can deal with multiple boards if it chooses to) rather than with device tree stuff. The chip specific drivers do not have any board specific code so there is no meaningful change that's being proposed to them. The problems with the device tree have been that people have been hostile to the idea of there being any board specific code at all in the kernel (or a board specific device tree node for the audio), and that people keep wanting to define some OF stuff that is supposed to cover a wide range of boards but makes unrealistic simplifying assumptions about what general hardware looks like. > The device-tree helps keep the platform .c file simple and devoid of too > horrible hacks, it allows to easily pass various configuration data to > leaf drivers such as i2c thingies, PHY devices etc... without gross > hooks between these and the platform, but the platform code still has > the upper hand for doing ad-hoc bits and pieces (or overwriting the > device-tree based behaviour) if necessary. Once again, if you can get the device tree guys to buy into this and stick with it that sounds good but my experience has been that this isn't where any of these discussions end up. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, Apr 27, 2010 at 08:31:18PM -0600, Grant Likely wrote: > On Tue, Apr 27, 2010 at 4:29 PM, Mark Brown > > On the other hand from a pragmatic point of view it's just much less > > hassle to just only provide the mechanism for instantiating a machine > > with custom code and use that for everything. > Also true, but this approach carries with it an incremental cost that > distributions feel the pain of. Ultimately I think we'll find a sweet > spot somewhere in between. Meh, it's not really much hassle for the distributions - it's all handled by the kernel, they don't need to explicitly do anything. None of the machine-specific stuff has ever been a hassle getting stuff merged, problems have always been in the drivers for the devices which device tree isn't going to make a blind bit of difference to (other than the usual discussions about what exactly the device tree should look like). ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
change_page_attr support on ppc, patch discussion
Hi,
I am trying to set a page of my data-structure as read-only on a USI MPC8347E.
This is primarily to figure a data structure corruption issue.
Added small support as follows:
ppc/mm/init.c:MMU_setup
__map_without_bats = 1;
__map_without_ltlbs = 1;
ppc/mm/pgtable.c
static int __change_page_attr(struct page *page, pgprot_t prot)
{
pte_t *kpte;
pmd_t *kpmd;
unsigned long address;
BUG_ON(PageHighMem(page));
address = (unsigned long)page_address(page);
if (v_mapped_by_bats(address) || v_mapped_by_tlbcam(address))
return 0;
if (!get_pteptr(&init_mm, address, &kpte, &kpmd))
return -EINVAL;
set_pte_at(&init_mm, address, kpte, mk_pte(page, prot));
wmb();
flush_HPTE(0, address, pmd_val(*kpmd));
pte_unmap(kpte);
mb();
return 0;
}
/*
* Change the page attributes of an page in the linear mapping.
*/
int change_page_attr(struct page *page, int numpages, pgprot_t prot)
{
int i, err = 0;
unsigned long flags;
local_irq_save(flags);
for (i = 0; i < numpages; i++, page++) {
err = __change_page_attr(page, prot);
if (err)
break;
}
local_irq_restore(flags);
return err;
}
EXPORT_SYMBOL(change_page_attr);
After allocation of my data structure, when I mark the page readonly like this:
change_page_attr(virt_to_page(dat_str), 1, PAGE_READONLY);
it works (throws Oops) but only for the first time, but subsequent writes
are going through. I expect even the subsequent writes to fail.
One more quirkiness to this is, after changing the page attribute I need to
read the element at least once for this to work.
Have I written the supportive api's (above ) correctly ? This is on 2.6.18
kernel.
If there is any other way to catch this corruption please let me know.
kgdb and bdi won't help me as it is a dynamically created data-structure and I
have timing constraints.
Regards,
Maindoor.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc/4xx: Add optional "reset_type" property to control reboot via dts
By setting "reset_type" to one of the following values, the default
software reset mechanism may be overidden. Here the possible values of
"reset_type":
1 - PPC4xx core reset
2 - PPC4xx chip reset
3 - PPC4xx system reset (default)
This will be used by a new PPC440SPe board port, which needs a "chip
reset" instead of the default "system reset" to be asserted.
Signed-off-by: Stefan Roese
Cc: Josh Boyer
Cc: Benjamin Herrenschmidt
---
v2:
- Add small property description to Documentation
- Add sanity check for property value
Documentation/powerpc/dts-bindings/4xx/reboot.txt | 18 +++
arch/powerpc/sysdev/ppc4xx_soc.c | 24 +++-
2 files changed, 40 insertions(+), 2 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/4xx/reboot.txt
diff --git a/Documentation/powerpc/dts-bindings/4xx/reboot.txt
b/Documentation/powerpc/dts-bindings/4xx/reboot.txt
new file mode 100644
index 000..d721726
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/4xx/reboot.txt
@@ -0,0 +1,18 @@
+Reboot property to control system reboot on PPC4xx systems:
+
+By setting "reset_type" to one of the following values, the default
+software reset mechanism may be overidden. Here the possible values of
+"reset_type":
+
+ 1 - PPC4xx core reset
+ 2 - PPC4xx chip reset
+ 3 - PPC4xx system reset (default)
+
+Example:
+
+ c...@0 {
+ device_type = "cpu";
+ model = "PowerPC,440SPe";
+ ...
+ reset-type = <2>; /* Use chip-reset */
+ };
diff --git a/arch/powerpc/sysdev/ppc4xx_soc.c b/arch/powerpc/sysdev/ppc4xx_soc.c
index 5c01435..d3d6ce3 100644
--- a/arch/powerpc/sysdev/ppc4xx_soc.c
+++ b/arch/powerpc/sysdev/ppc4xx_soc.c
@@ -191,11 +191,31 @@ static int __init ppc4xx_l2c_probe(void)
arch_initcall(ppc4xx_l2c_probe);
/*
- * At present, this routine just applies a system reset.
+ * Apply a system reset. Alternatively a board specific value may be
+ * provided via the "reset-type" property in the cpu node.
*/
void ppc4xx_reset_system(char *cmd)
{
- mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) | DBCR0_RST_SYSTEM);
+ struct device_node *np;
+ u32 reset_type = DBCR0_RST_SYSTEM;
+ const u32 *prop;
+
+ np = of_find_node_by_type(NULL, "cpu");
+ if (np) {
+ prop = of_get_property(np, "reset-type", NULL);
+
+ /*
+* Check if property exists and if it is in range:
+* 1 - PPC4xx core reset
+* 2 - PPC4xx chip reset
+* 3 - PPC4xx system reset (default)
+*/
+ if ((prop) && ((prop[0] >= 1) && (prop[0] <= 3)))
+ reset_type = prop[0] << 28;
+ }
+
+ mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) | reset_type);
+
while (1)
; /* Just in case the reset doesn't work */
}
--
1.7.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Fix DEBUG_PAGEALLOC on 603/e300
So we tried to speed things up a bit using flush_hash_pages() directly but that falls over on 603 of course meaning we fail to flush the TLB properly and we may even end up having it corrupt memory randomly by accessing a hash table that doesn't exist. This removes the "optimization" by always going through flush_tlb_page() for now at least. Signed-off-by: Benjamin Herrenschmidt --- Somebody with a 603 or e300 core based FSL SoC to try this out for me ? It's obviously completely untested :-) Cheers, Ben. diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c index b9243e7..95774b4 100644 --- a/arch/powerpc/mm/pgtable_32.c +++ b/arch/powerpc/mm/pgtable_32.c @@ -385,11 +385,7 @@ static int __change_page_attr(struct page *page, pgprot_t prot) return -EINVAL; __set_pte_at(&init_mm, address, kpte, mk_pte(page, prot), 0); wmb(); -#ifdef CONFIG_PPC_STD_MMU - flush_hash_pages(0, address, pmd_val(*kpmd), 1); -#else flush_tlb_page(NULL, address); -#endif pte_unmap(kpte); return 0; ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Tue, 2010-04-27 at 15:56 +1000, Benjamin Herrenschmidt wrote: > Hi Linus ! > > PowerPC has been a bit quiet this time around :-) That is until Kumar > woke me up with a few fixes and defconfig updates for the freescale > embedded platforms. I added a few patches to that. Some ps3 defconfig & maintainers change and a couple of nasty bug fixes. Here's an updated request. Cheers, Ben. The following changes since commit b91ce4d14a21fc04d165be30319541e0f9204f15: Linus Torvalds (1): Merge git://git.kernel.org/.../davem/net-2.6 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Anton Blanchard (1): powerpc/numa: Add form 1 NUMA affinity Anton Vorontsov (1): powerpc/85xx/86xx: Fix build w/ CONFIG_PCI=n Becky Bruce (1): powerpc/fsl_booke: Correct test for MMU_FTR_BIG_PHYS Benjamin Herrenschmidt (1): powerpc/pseries: Flush lazy kernel mappings after unplug operations Geoff Levand (2): powerpc/ps3: Update platform maintainer powerpc/ps3: Update ps3_defconfig Kim Phillips (4): powerpc/83xx: add RTC drivers in 83xx defconfig powerpc/83xx: enable EPOLL syscall in defconfig powerpc/83xx: configure SIL SATA driver in 83xx-wide defconfig powerpc/mpc8xxx defconfigs - turn off SYSFS_DEPRECATED Kumar Gala (2): powerpc: 2.6.34 update of defconfigs for embedded 6xx/7xxx, 8xx, 8xxx powerpc/fsl-booke: Fix CONFIG_RELOCATABLE support on FSL Book-E ppc32 Wolfgang Ocker (1): powerpc/fsl-cpm: Configure clock correctly for SCC MAINTAINERS |8 +- arch/powerpc/configs/83xx/asp8347_defconfig | 44 +++--- arch/powerpc/configs/83xx/kmeter1_defconfig | 28 ++-- arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 49 +++--- arch/powerpc/configs/83xx/mpc8315_rdb_defconfig | 50 +++--- arch/powerpc/configs/83xx/mpc832x_mds_defconfig | 45 +++--- arch/powerpc/configs/83xx/mpc832x_rdb_defconfig | 49 +++--- arch/powerpc/configs/83xx/mpc834x_itx_defconfig | 44 +++--- arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig | 43 +++--- arch/powerpc/configs/83xx/mpc834x_mds_defconfig | 46 +++--- arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 45 +++--- arch/powerpc/configs/83xx/mpc836x_rdk_defconfig | 44 +++-- arch/powerpc/configs/83xx/mpc837x_mds_defconfig | 46 +++--- arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 51 +++--- arch/powerpc/configs/83xx/sbc834x_defconfig | 44 +++--- arch/powerpc/configs/85xx/ksi8560_defconfig | 23 ++- arch/powerpc/configs/85xx/mpc8540_ads_defconfig | 25 ++- arch/powerpc/configs/85xx/mpc8560_ads_defconfig | 34 +++-- arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 31 +++-- arch/powerpc/configs/85xx/sbc8548_defconfig | 31 +++-- arch/powerpc/configs/85xx/sbc8560_defconfig | 25 ++- arch/powerpc/configs/85xx/socrates_defconfig | 51 --- arch/powerpc/configs/85xx/stx_gp3_defconfig | 51 --- arch/powerpc/configs/85xx/tqm8540_defconfig | 48 +++-- arch/powerpc/configs/85xx/tqm8541_defconfig | 54 -- arch/powerpc/configs/85xx/tqm8548_defconfig | 47 +++-- arch/powerpc/configs/85xx/tqm8555_defconfig | 54 -- arch/powerpc/configs/85xx/tqm8560_defconfig | 54 -- arch/powerpc/configs/85xx/xes_mpc85xx_defconfig | 59 +-- arch/powerpc/configs/86xx/gef_ppc9a_defconfig | 102 +++- arch/powerpc/configs/86xx/gef_sbc310_defconfig| 53 --- arch/powerpc/configs/86xx/gef_sbc610_defconfig| 96 +++ arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig | 34 ++-- arch/powerpc/configs/86xx/mpc8641_hpcn_defconfig | 48 -- arch/powerpc/configs/86xx/sbc8641d_defconfig | 40 +++-- arch/powerpc/configs/adder875_defconfig | 18 +- arch/powerpc/configs/c2k_defconfig| 55 +++ arch/powerpc/configs/ep8248e_defconfig| 20 ++- arch/powerpc/configs/ep88xc_defconfig | 17 +- arch/powerpc/configs/linkstation_defconfig| 48 +++-- arch/powerpc/configs/mgcoge_defconfig | 31 +++- arch/powerpc/configs/mgsuvd_defconfig | 19 ++- arch/powerpc/configs/mpc7448_hpc2_defconfig | 26 ++- arch/powerpc/configs/mpc8272_ads_defconfig| 23 ++- arch/powerpc/configs/mpc83xx_defconfig| 124 +++--- arch/powerpc/configs/mpc85xx_defconfig| 62 +--- arch/powerpc/configs/mpc85xx_smp_defconfig| 64 +--- arch/powerpc/configs/mpc866_ads_defconfig | 20 +- arch/powerpc/configs/mpc86xx_defconfig| 57 --- arch/powerpc/configs/mpc885_ads_defconfig | 20 +- arch/powerpc/configs/pq2fads_defconfig| 22 ++- arch/powerpc/configs/prpmc2800_defconfig | 52 -- arch/powerpc/configs/ps3_defconfig| 189 ++
