* Peter Zijlstra [2009-08-28 08:48:05]:
> On Fri, 2009-08-28 at 11:44 +0530, Arun R Bharadwaj wrote:
> > * Peter Zijlstra [2009-08-27 14:53:27]:
> >
> > Hi Peter, Ben,
> >
> > I've put the whole thing in a sort of a block diagram. Hope it
> > explains things more clearly.
> >
> >
> >
> >
>
On Fri, 2009-08-28 at 11:44 +0530, Arun R Bharadwaj wrote:
> * Peter Zijlstra [2009-08-27 14:53:27]:
>
> Hi Peter, Ben,
>
> I've put the whole thing in a sort of a block diagram. Hope it
> explains things more clearly.
>
>
>
>
>
>
>
>
On Fri, 2009-08-28 at 10:19 +0530, Arun R Bharadwaj wrote:
>
>
> This only does the job of picking the right idle loop for current
> latency and power requirement. This is already done in ladder/menu
> governors under the routines menu_select()/ladder_select().
> I'm not sure whats the purpose of
* Peter Zijlstra [2009-08-27 14:53:27]:
> On Thu, 2009-08-27 at 17:23 +0530, Arun R Bharadwaj wrote:
> > * Arun R Bharadwaj [2009-08-27 17:19:08]:
> >
> > Cpuidle infrastructure assumes pm_idle as the default idle routine.
> > But, ppc_md.power_save is the default idle callback in case of pSeri
* Peter Zijlstra [2009-08-27 14:53:27]:
Hi Peter, Ben,
I've put the whole thing in a sort of a block diagram. Hope it
explains things more clearly.
|CPUIDLE | (Select idle states like
On Tuesday 18 August 2009, Anton Vorontsov wrote:
> - Fix build issues in fsl_qe_udc;
> - Some minor cosmetic changes in "Add support for QE DMA mode and
> CPM1/CPM2 chips" patch.
Hmm ... the first four of these are pure PPC stuff and thus
not appropriate to send as SPI patches; but the second
On Aug 18, 2009, at 5:04 PM, Anton Vorontsov wrote:
This patch fixes the following warning:
CC drivers/spi/spi_mpc8xxx.o
spi_mpc8xxx.c: In function 'of_mpc8xxx_spi_probe':
spi_mpc8xxx.c:681: warning: 'ret' may be used uninitialized in this
function
Signed-off-by: Anton Vorontsov
--
On Aug 18, 2009, at 5:04 PM, Anton Vorontsov wrote:
This is needed to avoid ugly #ifdefs in drivers. Also update
fsl_qe_udc
driver so that now it doesn't define its own versions that cause build
breakage when the generic stubs are used.
Signed-off-by: Anton Vorontsov
---
arch/powerpc/includ
On Aug 18, 2009, at 5:04 PM, Anton Vorontsov wrote:
The bits are generic to CPM devices, so let's move them to the
common header file, so drivers won't need to privately reintroduce
another bunch of the same bits (as we can't include cpm2.h header
together with cpm1.h).
Signed-off-by: Anton Vo
On Aug 18, 2009, at 5:04 PM, Anton Vorontsov wrote:
struct mcc defined in both immap_qe.h and immap_cpm2.h, so they will
conflic when included in a single file. The mcc struct is easy to deal
with, since it isn't used in any driver (yet), so let's just rename QE
version to qe_mcc.
The ucb_ctlr
On Aug 18, 2009, at 5:04 PM, Anton Vorontsov wrote:
When cpm2.h included into spi_mpc8xxx driver, the SPI defines
in the header conflict with defines in the driver.
We don't need them in the header file, so remove them. Plus
remove "struct spi", we'll use a better version in the driver.
Signe
On Aug 27, 2009, at 12:30 PM, Anton Vorontsov wrote:
This patch adds suspend/resume support for MPC8540-compatible and
MPC8569 CPUs.
MPC8540-compatible PMCs are trivial: we just write SLP bit into PM
control and status register.
MPC8569 is a bit trickier, QE turns off during suspend and so on
On Aug 27, 2009, at 12:30 PM, Anton Vorontsov wrote:
This is needed to avoid #ifdefs in MPC85xx suspend/resume code.
Signed-off-by: Anton Vorontsov
---
arch/powerpc/include/asm/qe.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
applied to next
- k
On Aug 27, 2009, at 12:30 PM, Anton Vorontsov wrote:
For MPC8569 CPUs we'll need to reset QE after each suspend, so make
qe_reset() code path suitable for repeated invocation, that is:
- Don't initialize rheap structures if already initialized;
- Don't allocate muram for SDMA if already alloc
On Aug 25, 2009, at 8:54 AM, Poonam Aggrwal wrote:
P1020 is another member of Freescale QorIQ series of processors.
It is an e500 based dual core SOC.
Being a scaled down version of P2020 it has following differences
from P2020:
- 533MHz - 800MHz core frequency.
- 256Kbyte L2 cache
- Etherne
On Aug 27, 2009, at 12:30 PM, Anton Vorontsov wrote:
MPC8569 CPUs have four QE RISCs, so we need to increase MAX_QE_RISC
constant, otherwise qe_upload_firmware() fails at sanity checking.
Signed-off-by: Anton Vorontsov
---
arch/powerpc/sysdev/qe_lib/qe.c |2 +-
1 files changed, 1 insertio
>> FIXED-TERM Seeh Thomas (BEG/EMS1) wrote:
>> Dear Mr Denk,
>>
>> thanks for your reply. I checked out kernel 2.6.30.3 stable for testing too.
>> I mean it's really a Lite5200. That is the U-boot boot message:
> Just to be sure. The old Lite5200 eval board has *one* PCI slot, while
> the new Li
* Peter Zijlstra [2009-08-27 14:53:27]:
> On Thu, 2009-08-27 at 17:23 +0530, Arun R Bharadwaj wrote:
> > * Arun R Bharadwaj [2009-08-27 17:19:08]:
> >
> > Cpuidle infrastructure assumes pm_idle as the default idle routine.
> > But, ppc_md.power_save is the default idle callback in case of pSeri
On Fri, 2009-08-28 at 12:43 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-08-27 at 16:36 -1000, Mitch Bradley wrote:
> > The idea of a wiki as a registration authority is a good one, but I'm
> > not volunteering to maintain it :-)
>
> here goes my hope :-)
>
> Do we have wiki's we could us
On Thu, 2009-08-27 at 16:36 -1000, Mitch Bradley wrote:
> The idea of a wiki as a registration authority is a good one, but I'm
> not volunteering to maintain it :-)
here goes my hope :-)
Do we have wiki's we could use on power.org or should we aim for a
community place ? Anybody has suggestions
The idea of a wiki as a registration authority is a good one, but I'm
not volunteering to maintain it :-)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
> I agree in general. It has long been a convention of mine to follow the
> vendor's names as exactly as possible. But that often presents
> difficulties. Many of them have been touched on in our previous
> discussion but I'll list some here just to emphasize the problem we face:
>
> a) Inco
On Fri, Aug 28, 2009 at 03:19:25AM +0400, Anton Vorontsov wrote:
[...]
> > That is why platform code should device_init_wakeup() and
> > drivers should check device_can_wakeup(dev) ...
>
> They should (and do) check may_wakeup() (i.e. should_wakeup) before
> suspending, not can_wakeup().
>
> stat
On Thu, Aug 27, 2009 at 02:52:36PM -0700, David Brownell wrote:
[...]
> > I believe that it's not platform code responsibility to allow or
> > disallow wakeups, instead, drivers themselves should set the capability
> > if a device can trigger wakeups.
>
> Drivers can't generally know if that's pos
> One advantage of indices is that they avoid endless arguments about the
> exact name (and spelling) of things.
Right, though in that case, nobody gets to have to decide on the name,
it comes from the chip manufacturer pin naming or data sheet.
I agree in general. It has long bee
> Open Firmware often avoids indexed structures. Cases in point include
> the use of named properties instead of fixed structures and named
> methods instead of function pointer arrays. Open Firmware's use of
> arrays for reg properties seems like the right choice for that
> particular cas
On Thu, 2009-08-27 at 11:11 -1000, Mitch Bradley wrote:
> I refrained from commenting as I didn't want to get involved in an
> endless argument about "goodness".
Oh well, I asked for it, didn't it ? :-)
> Indexed arrays are appropriate for some cases and names are better for
> others. Names a
NAK; see details below
On Thursday 27 August 2009, Anton Vorontsov wrote:
> RTC core won't allow wakeup alarms to be set if RTC devices' parent
> (i.e. i2c_client or spi_device) isn't wakeup capable.
Quite rightly so ... being wakeup-capable is config-specific.
> For I2C devices there is I2C_CL
On Thu, 2009-08-27 at 14:53 +0200, Peter Zijlstra wrote:
> I'm not quite seeing how this makes anything any better. Not we have 3
> function pointers, where 1 should suffice.
There's also the question of us having different "idle" vs.
"power_save", the former being the entire idle loop, the later
On Tue, 2009-08-18 at 14:21 +1000, Benjamin Herrenschmidt wrote:
> So here's a followup to my discussion about the clock API.
Really nobody has a comment here ? :-) Not even Mitch ?
I refrained from commenting as I didn't want to get involved in an
endless argument about "goodn
On Thu, 2009-08-27 at 07:05 -0400, Josh Boyer wrote:
> On Thu, Aug 27, 2009 at 01:33:48PM +1000, Benjamin Herrenschmidt wrote:
> >Hi Linus !
> >
> >Here are a couple of last minute patches for 2.6.31. One is a regression fix
> >(afaik) where a PS3 driver gets incorrectly loaded on other platforms a
Hi Josh,
> >Now we only need someone that can look at the CONFIG_4xx cases still :-)
>
> It seems the FSL watchdog is much more flexible than the one found in 4xx
> cores. On 4xx, you basically have 4 static choices that represent specific
> times determined by the clock frequency. I'm concerne
Anton Vorontsov wrote:
> MPC8569 CPUs have four QE RISCs, so we need to increase MAX_QE_RISC
> constant, otherwise qe_upload_firmware() fails at sanity checking.
>
> Signed-off-by: Anton Vorontsov
> ---
Acked-by: Timur Tabi
Anton, I'll review the rest of your patches next week. I'm too busy t
2009/8/27 Scott Wood
>
> > //check if we successfully store value at 0x400,
> >
> > lis r22, 0x400
> > ori r22,r22,0x0
> > lwz r23,0(r22)
> > cmpw r23, 30
>
> The values should not be equal, since you wrote a byte and read back a
> word.
>
> Furthermore, you are storing the constant 30, but a
On 8/27/09, Joachim Fenkes wrote:
>
> Hal Rosenstock wrote on 26.08.2009 17:15:03:
>
> > Thanks for doing this. It looks sane to me. The only issue I recall that
>
> > appears to be remaining is a better setting of
> ClassPortInfo:RespTimeValue
> > rather than hardcoding. Perhaps using the value
RTC core won't allow wakeup alarms to be set if RTC devices' parent
(i.e. i2c_client or spi_device) isn't wakeup capable.
For I2C devices there is I2C_CLIENT_WAKE flag exists that we can pass
via board info, and if set, I2C core will initialize wakeup capability.
For SPI devices there is no such f
This patch removes currently unused UGETH_MAGIC_PACKET Kconfig symbol
and code, i.e. magic_packet_detection_{enable,disable} functions.
The two functions each contain just two steps that we'll place into
suspend/resume code path under CONFIG_PM.
Signed-off-by: Anton Vorontsov
---
drivers/net/Kc
This patch implements suspend/resume and WOL support for UCC Ethernet
driver.
We support two wake up events: wake on PHY/link changes and wake
on magic packet.
In some CPUs (like MPC8569) QE shuts down during sleep, so magic packet
detection is unusable, and also on resume we should fully reiniti
This patch factors out MAC initialization into ucc_geth_init_mac()
function that we'll use for suspend/resume.
Signed-off-by: Anton Vorontsov
---
drivers/net/ucc_geth.c | 87 ---
1 files changed, 52 insertions(+), 35 deletions(-)
diff --git a/driver
In some CPUs (i.e. MPC8569) QE shuts down completely during sleep,
drivers may want to know that to reinitialize registers and buffer
descriptors.
This patch implements qe_alive_during_sleep() helper function, so far
it just checks if MPC8569-compatible power management controller is
present, whic
In commit 3e73fc9a12679a546284d597c1f19165792d0b83 ("ucc_geth: Fix IO
memory (un)mapping code") I fixed ug_regs IO memory leak by properly
freeing the allocated memory. But ethtool_stats() callback doesn't
check for ug_regs being NULL, and that causes following oops if
'ethtool -S' is executed on a
- Add power management controller nodes;
- Add interrupts for RTC nodes, the RTC interrupt may be used as a
wakeup source;
Signed-off-by: Anton Vorontsov
---
arch/powerpc/boot/dts/mpc8568mds.dts | 15 +--
arch/powerpc/boot/dts/mpc8569mds.dts | 13 -
arch/p
This patch adds suspend/resume support for MPC8540-compatible and
MPC8569 CPUs.
MPC8540-compatible PMCs are trivial: we just write SLP bit into PM
control and status register.
MPC8569 is a bit trickier, QE turns off during suspend and so on
resume we must reload QE microcode firmware and reset QE
For MPC8569 CPUs we'll need to reset QE after each suspend, so make
qe_reset() code path suitable for repeated invocation, that is:
- Don't initialize rheap structures if already initialized;
- Don't allocate muram for SDMA if already allocated, just reinitialize
registers with previously alloca
This is needed to avoid #ifdefs in MPC85xx suspend/resume code.
Signed-off-by: Anton Vorontsov
---
arch/powerpc/include/asm/qe.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index 791c67a..e8232bb 100
MPC8569 CPUs have four QE RISCs, so we need to increase MAX_QE_RISC
constant, otherwise qe_upload_firmware() fails at sanity checking.
Signed-off-by: Anton Vorontsov
---
arch/powerpc/sysdev/qe_lib/qe.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/
Hi,
I have a custom spi device connected to a Xilinx spi controller. To map the
register space of the controller a reg property is defined in the device tree.
Because my custom device also has register space which I want to map in my
driver, I also defined a reg property. Because things weren't
wilbur.chan wrote:
2009/8/27 Scott Wood :
Is this under Linux (it is a Linux mailing list...)? If so, there are
better ways of communicating that don't involve clobbering random memory and
overlapping userspace TLB mappings.
Yes, I'm doing this under linux in kernel mode.
I've used interrupt
2009/8/27 Scott Wood :
>
> Is this under Linux (it is a Linux mailing list...)? If so, there are
> better ways of communicating that don't involve clobbering random memory and
> overlapping userspace TLB mappings.
Yes, I'm doing this under linux in kernel mode.
I've used interrupt between cores,
FIXED-TERM Seeh Thomas (BEG/EMS1) wrote:
> Dear Mr Denk,
>
> thanks for your reply. I checked out kernel 2.6.30.3 stable for testing too.
> I mean it's really a Lite5200. That is the U-boot boot message:
Just to be sure. The old Lite5200 eval board has *one* PCI slot, while
the new Lite5200B has
wilbur.chan wrote:
I am using a SMP E500 v2, and I want CPU0 to write some value to a
physical address, and wait for CPU1 to read from it.
Is this under Linux (it is a Linux mailing list...)? If so, there are
better ways of communicating that don't involve clobbering random memory
and overl
There was a patch of kexec on SMP mips 64 , and I attempt to implement
kexec on SMP powerpc .
I found that , it was a little different with mips when booting a
kernel. We know that, every CPU jumped directly into kernel on
mips, but on powerpc , E500 SMP, the 'master' CPU was in charge of
'sl
Dear Mr Denk,
thanks for your reply. I checked out kernel 2.6.30.3 stable for testing too.
I mean it's really a Lite5200. That is the U-boot boot message:
U-Boot 2009.06 (Aug 26 2009 - 08:23:36)
CPU: MPC5200 v1.2, Core v1.1 at 231 MHz
Bus 66 MHz, IPB 33 MHz, PCI 16.500
On Thu, 2009-08-27 at 12:22 +0530, Amit Shah wrote:
> On (Thu) Aug 27 2009 [15:04:45], Michael Ellerman wrote:
> Ryan you called his code "pure legacy baggage" if you
> > don't ;)
> >
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=commitdiff;h=d450b4ae023fb4be175389c18
Dear "FIXED-TERM Seeh Thomas (BEG/EMS1)",
In message <6e9d235b18ce694399d781f05d9c42e79f0c2...@si-mbx11.de.bosch.com> you
wrote:
>
> I'll try to run a 2.6.31-rc7 kernel on my Lite5200 board.
Is this really a Lite5200, or is it a Lite5200B?
Hint: if U-Boot prints something like "CPU: MPC5200B v2
On Thu, 2009-08-27 at 17:23 +0530, Arun R Bharadwaj wrote:
> * Arun R Bharadwaj [2009-08-27 17:19:08]:
>
> Cpuidle infrastructure assumes pm_idle as the default idle routine.
> But, ppc_md.power_save is the default idle callback in case of pSeries.
>
> So, create a more generic, architecture ind
On Thu, Aug 27, 2009 at 01:14:58PM +0200, Wim Van Sebroeck wrote:
>Hi Chris,
>
>> The WDIOC_SETTIMEOUT argument is supposed to be a "seconds" value.
>> However, the book E wdt currently treats it as a "period" which is
>> interpreted in a board-specific way.
>>
>> This patch allows the user to pas
* Arun R Bharadwaj [2009-08-27 17:19:08]:
This patch creates arch/powerpc/platforms/pseries/processor_idle.c,
which implements the cpuidle infrastructure for pseries.
It implements a pseries_cpuidle_loop() which would be the main idle loop
called from cpu_idle(). It makes decision of entering eit
* Arun R Bharadwaj [2009-08-27 17:19:08]:
Set the idle routine to cpuidle_pm_idle after registering cpuidle
devices. Earlier pm_idle was assumed as the defualt idle loop by
cpuidle infrastructure. This is changed to an architecture independent
cpuidle_pm_idle.
There are 2 instances which are usi
* Arun R Bharadwaj [2009-08-27 17:19:08]:
Cpuidle infrastructure assumes pm_idle as the default idle routine.
But, ppc_md.power_save is the default idle callback in case of pSeries.
So, create a more generic, architecture independent cpuidle_pm_idle
function pointer in driver/cpuidle/cpuidle.c a
* Arun R Bharadwaj [2009-08-27 17:19:08]:
This patch enables the cpuidle option in Kconfig for pSeries.
Currently cpuidle infrastructure is enabled only for x86 and ARM.
This code is almost completely borrowed from x86 to enable
cpuidle for pSeries.
Signed-off-by: Arun R Bharadwaj
---
arch/po
Hi,
Changes from previous iteration:
* Remove the EXPORT_SYMBOL(pm_idle) from
arch/powerpc/platform/pseries/processor_idle.c and introduce a
generic cpuidle_pm_idle in cpuidle.c which was earlier assuming pm_idle
to be the default idle routine. (As suggested by P
On Thu, Aug 27, 2009 at 07:27:23PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-08-27 at 10:08 +0100, Alan Cox wrote:
> So at this stage, I think the reasonably thing to do is to stick to the
> spinlock, but we can try to make it a bit smarter, and we can definitely
> attempt to fix the case
Hi Chris,
> The WDIOC_SETTIMEOUT argument is supposed to be a "seconds" value.
> However, the book E wdt currently treats it as a "period" which is
> interpreted in a board-specific way.
>
> This patch allows the user to pass in a "seconds" value and the driver
> will set the smallest timeout tha
On Thu, Aug 27, 2009 at 01:33:48PM +1000, Benjamin Herrenschmidt wrote:
>Hi Linus !
>
>Here are a couple of last minute patches for 2.6.31. One is a regression fix
>(afaik) where a PS3 driver gets incorrectly loaded on other platforms and
>crashes, along with a PS3 defconfig update.
>The following
> - Then, are we certain that there's no case where the tty layer will
> call us with some lock held or in an atomic context ? To be honest,
> I've totally lost track of the locking rules in tty land lately so it
> might well be ok, but something to verify.
Some of the less well behaved line disc
Hal Rosenstock wrote on 26.08.2009 17:15:03:
> Thanks for doing this. It looks sane to me. The only issue I recall that
> appears to be remaining is a better setting of
ClassPortInfo:RespTimeValue
> rather than hardcoding. Perhaps using the value from PortInfo is the way
to go
> (ideally it
On Wed, 2009-08-19 at 11:41 +0200, Peter Zijlstra wrote:
> > > > which implies to me that spin_is_locked() will always return
> false. Is this
> > > > expected behavior.
> > >
> > > That's wrong. spin_is_locked should always return true on UP.
> >
> > Surely it's not that simple? Maybe spin_is_
On Thu, 2009-08-27 at 14:04 +0900, HongWoo Lee wrote:
> And I have a question about bdnz+ instruction.
> Through googling, I learned that bdnz does decrement count register
> and
> branch if it is still nonzero.
> But I couldn't find what "bdnz+" is.
> Can anybody explain to me what it is ??
On P
On Thu, 2009-08-27 at 10:08 +0100, Alan Cox wrote:
> > - Then, are we certain that there's no case where the tty layer will
> > call us with some lock held or in an atomic context ? To be honest,
> > I've totally lost track of the locking rules in tty land lately so it
> > might well be ok, but so
For stable/linux-2.6.30.y
-- Forwarded message --
Date: Thu, 27 Aug 2009 03:59:28 GMT
From: Linux Kernel Mailing List
To: git-commits-h...@vger.kernel.org
Subject: powerpc/ps3: Add missing check for PS3 to rtc-ps3 platform device
registration
Gitweb: http://git.kernel.org
Hello everyone,
I'll try to run a 2.6.31-rc7 kernel on my Lite5200 board.
For the device tree I use lite5200.dts and compiled it simply with
make ARCH=powerpc CROSS_COMPILE=ppc_6xx- lite5200.dtb
But I'm not sure what configuration for the kernel I should choose. There is no
lite5200_defc
On Thu, 2009-08-27 at 09:22 +0200, Ingo Molnar wrote:
>
> ah, yes, they are stable/fine. I've put it into a separate branch
> for you.
>
> Ben, please pull the latest iommu-for-powerpc git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
> iommu-for-powerpc
We call lmb_end_of_DRAM() to test whether a DMA mask
is ok on a machine without IOMMU, but this function is
marked as __init.
I don't think there's a clean way to get the top of RAM
max_pfn doesn't appear to include highmem or I missed
(or we have a bug :-) so for now, let's just avoid having
a br
Hi Ben,
WARNING: vmlinux.o(.text+0x1d864): Section mismatch in reference from the
function .dma_direct_dma_supported() to the function
.init.text:.lmb_end_of_DRAM()
The function .dma_direct_dma_supported() references
the function __init .lmb_end_of_DRAM().
This is often because .dma_direct_dma_s
This moves the code to start the decrementer on 40x and BookE into
a separate function which is now called from time_init() and
secondary_time_init(), before the respective clock sources are
registered. We also remove the 85xx specific code for doing it
from the platform code.
Signed-off-by: Benja
76 matches
Mail list logo
