* Re: Freescale MPC8313ERDB-RevA and newer BSP/kernel
From: Mark Bishop @ 2009-03-11 18:27 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090311165320.GB11120@ld0162-tx32.am.freescale.net>
Quoting Scott Wood <scottwood@freescale.com>:
> On Wed, Mar 11, 2009 at 12:03:00PM -0400, Mark Bishop wrote:
>> Yes I have actually. I have booted a 2.6.28.6. Same problem.
>
> I've booted many recent kernels on revA 8313ERDB; networking works fine.
> I'll try 2.6.28.6 specifically, though u-boot is acting up at the moment
> so I have to address that first. :-(
>
> Are you using the stock config and device tree from 2.6.28.6, or have you
> made any changes?
>
>> Also, is it me but at some point from 2.6.23 to 2.6.28 did they
>> started using hex numbers in the .dts file for "interrupts =3D " without
>> the 0x preamble?
>
> Yes. dts version 0 had hex by default (with OF-like radix =20
> prefixes), and version 1 (indicated by
> /dts-v1/; at the top of the file) has decimal by default (with C-like
> radix prefixes).
>
>> I've been looking at 2.6.20, 2.6.23, and 2.6.28 .dts files for this
>> board and .28 looked way different in the interrupt section for the
>> eTSEC.
>>
>> Quoting Kumar Gala <galak@kernel.crashing.org>:
>
> Please don't top-post.
>
>> >>The boards we received didn't have SPI compiled into the kernel and
>> >>when we went to go re-compile the kernel using the 20081222 and
>> >>20080711 BSPs. I realize that the interrupts were reversed for
>> >>eTEC1 and eTEC2 and I've made the changes in the .dtb file and I no
>> >>longer hang when I ping, etc. But I still can't get the board on
>> >>the network. I've verified it isn't the network settings.
>
> You're sure you're not trying to talk to the switch (which will claim
> link-up regardless of what's plugged into it)? The non-switch ethernet
> port is eTSEC2.
>
> What *does* it do when you ping, if neither hang nor work?
>
> -Scott
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
After remapping the IRQs, it is working now.
Any idea on what I need to do to get SPI working? I've compiled it =20
into the kernel but don't see anything in /proc/bus
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
From: Valentine Barshak @ 2009-03-11 19:06 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Stefan Roese, lebon
In-Reply-To: <20090311103716.GE26415@zod.rchland.ibm.com>
Josh Boyer wrote:
> On Tue, Mar 10, 2009 at 10:50:13PM +0300, Valentine Barshak wrote:
>> I was just going to submit a patch for that too.
>> Indeed, the denali_fixup_memsize() miscalculated a couple of address
>> field widths. We were lucky to eventually get the right result,
>> because the effect of the first error was killed by the other one.
>> According to the AMCC 440EPX/GRX user manual,
>> the Chip Select width is always fixed at 1 bit no matter
>> what is actually read from register DDR_10.
>> The workaround is to use a predefined chipselect value for 440EPx/GRx.
>> Also, setting the REDUC bit (REDUC = 1) enables 32-bit data path.
>> If REDUC = 0, full data path of 64 bits is used.
>>
>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>> Signed-off-by: Mikhail Zolotaryov <lebon@lebon.org.ua>
>
> I've been looking over this one a bit more. At the moment, I'm inclined
> to queue this up in my -next branch. I would like to see if Mikhail
> could test it though, and have Valentine answer the question in the hard
> wired part.
I've been looking at the docs once again and actually I couldn't find an
explanation there. And I don't have that e-mail from AMCC support
that I got a while back regarding the issue anymore.
There might have been some misunderstanding.
The docs (PPC440EPX UM 19.2 Device Address Mapping) say that the chip
select field width is always fixed at one bit, but this doesn't actually
mean that there's always one chip select used.
The patch works fine on Sequoia and another Sequoia-like board with 1GB
RAM installed, but it might not work with 2GB RAM. I've tried to play
with DDR0_10 settings and Sequoia works fine regardless of what's
actually written to DDR0_10.
So, probably the best way would be to fix that in u-boot
amcc/sequoia/sdram.c by doing mtsdram(DDR0_10, 0x00000100); instead of
mtsdram(DDR0_10, 0x00000300);
Sorry, for confusion, but after reviewing the docs, I think that
only REDUC interpretation has to be fixed. The chips select part should
be fixed in u-boot sdram code for Sequoia as was originally proposed by
Mikhail.
Stefan, could you please take a look?
Thanks,
Valentine.
>
> josh
^ permalink raw reply
* Re: [PATCH v5] introduce macro spin_event_timeout()
From: Timur Tabi @ 2009-03-11 19:14 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Roland Dreier
In-Reply-To: <49B7EC27.3030305@freescale.com>
On Wed, Mar 11, 2009 at 11:51 AM, Scott Wood <scottwood@freescale.com> wrote:
> One jiffy is fine, but two is just too long?
Any number of jiffies is *not* too long if a timeout occurs. However,
I think even one jiffy is too long if that's the normal condition.
Unfortunately, the driver may not have any choice in some
circumstances. If the hardware is just too slow to respond, and it
doesn't provide interrupts, but the code is running in atomic context,
and the function what else can it do?
> Disallow that, enforced with a call to might_sleep().
I think we need to be able to allow this function to work in atomic
context. Is jiffies updated in atomic context?
> Alternatively, do something with get_cycles(), and have some sort of #define
> by which arches can say if get_cycles actually works. In the absence of a
> working get_cycles() or equivalent, timeouts with interrupts disabled aren't
> going to happen whether we abstract it with a macro or not.
I think I can live with that.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Linus Torvalds @ 2009-03-11 19:18 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Andrew Morton, Linux Kernel list, linuxppc-dev list
In-Reply-To: <alpine.LRH.2.00.0903111652070.1040@vixen.sonytel.be>
On Wed, 11 Mar 2009, Geert Uytterhoeven wrote:
>
> Are you aware the old one was introduced in 2.6.29-rc1? So there cannot be a
> regression from 2.6.28 or older.
Ahh, no, that part hadn't registered.
In that case, I guess I don't really care, as long as everybody involved
feels it's clearly better than the one merged into -rc1.
Linus
^ permalink raw reply
* Re: [PATCH v5] introduce macro spin_event_timeout()
From: Scott Wood @ 2009-03-11 19:22 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Roland Dreier
In-Reply-To: <ed82fe3e0903111214j2072319pe985e6bbecdd1665@mail.gmail.com>
Timur Tabi wrote:
> On Wed, Mar 11, 2009 at 11:51 AM, Scott Wood <scottwood@freescale.com> wrote:
>
>> One jiffy is fine, but two is just too long?
>
> Any number of jiffies is *not* too long if a timeout occurs. However,
> I think even one jiffy is too long if that's the normal condition.
I was under the impression that we were only talking about timeouts, and
that the common case was significantly shorter than that.
> Unfortunately, the driver may not have any choice in some
> circumstances. If the hardware is just too slow to respond, and it
> doesn't provide interrupts, but the code is running in atomic context,
> and the function what else can it do?
Rework the driver to poll from a periodic timer (like we do with PHYs).
However, that's overkill when the hardware is supposed to respond in a
handful of clocks, and preemption is enabled in case the timeout path
does happen.
>> Disallow that, enforced with a call to might_sleep().
>
> I think we need to be able to allow this function to work in atomic
> context. Is jiffies updated in atomic context?
If it's atomic because preemption was disabled, yes -- but even a rare
extended spin in such a context would be bad for hard realtime. If
interrupts are disabled, or the code is executing from a timer interrupt
(or possibly other interrupts depending on the hardware and its priority
scheme), no.
>> Alternatively, do something with get_cycles(), and have some sort of #define
>> by which arches can say if get_cycles actually works. In the absence of a
>> working get_cycles() or equivalent, timeouts with interrupts disabled aren't
>> going to happen whether we abstract it with a macro or not.
>
> I think I can live with that.
Another option is to use udelay() on platforms without a working
get_cycles().
-Scott
^ permalink raw reply
* Re: [PATCH v5] introduce macro spin_event_timeout()
From: Timur Tabi @ 2009-03-11 20:45 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Roland Dreier
In-Reply-To: <49B80F7F.30705@freescale.com>
On Wed, Mar 11, 2009 at 2:22 PM, Scott Wood <scottwood@freescale.com> wrote=
:
> I was under the impression that we were only talking about timeouts, and
> that the common case was significantly shorter than that.
I think one of the concerns that Alan Cox raised is that the existence
of this macro would encourage people to spin for long durations.
> If it's atomic because preemption was disabled, yes -- but even a rare
> extended spin in such a context would be bad for hard realtime. =A0If
> interrupts are disabled, or the code is executing from a timer interrupt =
(or
> possibly other interrupts depending on the hardware and its priority
> scheme), no.
So in that case, I can't rely on jiffies. I guess get_cycle() is my
only choice. The problem is that there is no num_cycles_per_usec().
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v5] introduce macro spin_event_timeout()
From: Scott Wood @ 2009-03-11 21:00 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Roland Dreier
In-Reply-To: <ed82fe3e0903111345m2962f5b5wdfc9e2efae1c33ae@mail.gmail.com>
Timur Tabi wrote:
> On Wed, Mar 11, 2009 at 2:22 PM, Scott Wood <scottwood@freescale.com> wrote:
>
>> I was under the impression that we were only talking about timeouts, and
>> that the common case was significantly shorter than that.
>
> I think one of the concerns that Alan Cox raised is that the existence
> of this macro would encourage people to spin for long durations.
Yes, and I've already stated my response to that line of thinking. I
just don't see anyone who would have done something better than a spin
loop changing their mind because doing a spin loop becomes a little
easier -- the spin loop is *already* easier than the alternatives.
What if another variant were added that did msleep between iterations,
for longer expected completion times? Or if we want to be really fancy,
combine them into one function that starts with small udelays, then
switches to msleep of progressively larger intervals up to some maximum?
>> If it's atomic because preemption was disabled, yes -- but even a rare
>> extended spin in such a context would be bad for hard realtime. If
>> interrupts are disabled, or the code is executing from a timer interrupt (or
>> possibly other interrupts depending on the hardware and its priority
>> scheme), no.
>
> So in that case, I can't rely on jiffies.
Or you can say that atomic context is outside the scope of this macro.
-Scott
^ permalink raw reply
* Re: [PATCH v5] introduce macro spin_event_timeout()
From: Timur Tabi @ 2009-03-11 21:02 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Roland Dreier
In-Reply-To: <49B82657.9050709@freescale.com>
Scott Wood wrote:
> Or you can say that atomic context is outside the scope of this macro.
No, I don't want to say that. We have wait_event_timeout() for larger-scale
operations. I'm just looking for something that can replace "while (!condition);"
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH v5] introduce macro spin_event_timeout()
From: Scott Wood @ 2009-03-11 21:03 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Roland Dreier
In-Reply-To: <49B826E3.6020007@freescale.com>
Timur Tabi wrote:
> Scott Wood wrote:
>
> > Or you can say that atomic context is outside the scope of this macro.
>
> No, I don't want to say that. We have wait_event_timeout() for
> larger-scale operations. I'm just looking for something that can
> replace "while (!condition);"
wait_event_timeout() requires a wait queue.
-Scott
^ permalink raw reply
* Re: fsldma driver questions
From: Timur Tabi @ 2009-03-11 21:34 UTC (permalink / raw)
To: Crossley, Malcolm (GE EntSol, Intelligent Platforms); +Cc: linuxppc-dev
In-Reply-To: <FF6D174B07759740B0259F914CE6D7D305B1A61D@LONMLVEM04.e2k.ad.ge.com>
On Wed, Mar 11, 2009 at 10:52 AM, Crossley, Malcolm (GE EntSol,
Intelligent Platforms) <Malcolm.Crossley2@gefanuc.com> wrote:
> I have noticed that append_ld_queue() changes the next link descriptor
> address field in the last link descriptor of the chain. The
> append_ld_queue function is called from the fsl_dma_tx_submit() which
> can called at any time by a kernel module using that channel. This could
> result in the link descriptor being changed whilst the DMA engine is
> running. Could this issue cause unexpected behavior of the DMA engine or
> the driver?
I would need to study the code more thoroughly, but keep in mind that
a DMA descriptor is read by the DMA controller only when it is about
to be processed. It's okay to change the descriptor contents while
the DMA buffer it references is being transferred. The new values in
the descriptor won't be used until the DMA engine tries to use it the
next time.
> A second question I have is to do with the dma_halt() routine setting
> the channel abort flag. The dma_halt() routine is called from
> fsl_chan_xfer_ld_queue() after the dma engine has been detected as idle.
> The dma_halt() routine sets the channel stop flag and the channel abort
> flag. Whilst the dma engine could be idle, it may not have completed a
> transfer AFAICT. Or if the engine is has no more transactions then a
> channel abort does not need to be issued anyway?
I would need to study the code to answer this question. I wrote a
different driver that uses this DMA controller, so I'm familiar with
the controller but not the code.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 1/9] powerpc/kconfig: Kill PPC_MULTIPLATFORM
From: Benjamin Herrenschmidt @ 2009-03-11 21:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <7FB04997-33E8-479C-B5EF-A1ECA8059A99@kernel.crashing.org>
On Wed, 2009-03-11 at 07:04 -0500, Kumar Gala wrote:
> On Mar 10, 2009, at 10:53 PM, Benjamin Herrenschmidt wrote:
>
> >
> > config PPC_NATIVE
> > bool
> > - depends on PPC_MULTIPLATFORM
> > + depends on 6xx || PPC64
> > help
> > Support for running natively on the hardware, i.e. without
> > a hypervisor. This option is not user-selectable but should
> > be selected by all platforms that need it.
>
> Should this really just be PPC64 && BOOK3S ? It doesnt look to be
> used for anything beyond using hash_native_64.S
Maybe... In this case I didn't want to change it from what it was but
you're right, it probably is hash64 only.
Ben
^ permalink raw reply
* Re: NFS problems on a MPC5200-based board
From: Benjamin Herrenschmidt @ 2009-03-11 21:39 UTC (permalink / raw)
To: Bartłomiej Sięka; +Cc: linuxppc-dev
In-Reply-To: <4C4E1899-9086-4DF5-A5BF-832AEBEAA8E9@semihalf.com>
On Wed, 2009-03-11 at 16:08 +0100, Bartłomiej Sięka wrote:
> Hi,
>
> This is a follow-up on NFS problems on an MPC5200-based board reported
> here a while back:
>
> http://www.nabble.com/-PATCH--Add-support-for-the-digsy-MTC-board.-to21750004.html#a21792612
>
> To recap: while using NFS, especially while mounting the root
> filesystem over NFS, the system is really slow and displays a bunch of
> "nfs: server 192.168.1.1 not responding, still trying" messages.
> Sometimes it is able to get to the login prompt, sometimes not. In
> cases where the login is successful, the system is still extremely
> sluggish (console hangs for tens of seconds and longer).
>
> git bisect narrows down the troublesome commit as:
Maybe you need to set CPU_FTR_NEED_COHERENT for the 5200 ?
Cheers,
Ben.
> commit 4c456a67f501b8b15542c7c21c28812bf88f484b
> Author: Gerhard Pircher <gerhard_pircher@gmx.net>
> Date: Fri Jan 23 06:51:28 2009 +0000
>
> powerpc/mm: Fix handling of _PAGE_COHERENT in BAT setup code
>
> _PAGE_COHERENT is now always set in _PAGE_RAM resp. PAGE_KERNEL.
> Thus it has to be masked out, if the BAT mapping should be non
> cacheable or CPU_FTR_NEED_COHERENT is not set.
>
> This will work on normal SMP setups because we force-set
> CPU_FTR_NEED_COHERENT as part of CPU_FTR_COMMON on SMP.
>
> Signed-off-by: Gerhard Pircher <gerhard_pircher@gmx.net>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
>
> We have tested recent mainline kernel (past 2.6.29-rc7) with the
> 4c456a6...
> commit reverted and NFS problems went away.
>
> Other people have also reported similar problems (original posters on
> Cc):
> http://www.nabble.com/-PATCH--Add-support-for-the-digsy-MTC-board.-tp21750004p21792825.html
> http://www.nabble.com/-PATCH--Add-support-for-the-digsy-MTC-board.-tp21750004p21792612.html
>
> The commit in question does not look directly related to NFS/
> networking; moreover it is a fix for some other problem, so just
> reverting it is not an option, it seems (?). So how do we go about
> having NFS operational again? Any comments?
>
> Regards,
> Bartlomiej Sieka
^ permalink raw reply
* Re: [PATCH v5] introduce macro spin_event_timeout()
From: Benjamin Herrenschmidt @ 2009-03-11 21:49 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, linuxppc-dev, Timur Tabi
In-Reply-To: <fa686aa40903111010l7bd7e2f8r47c7d42184d0a36a@mail.gmail.com>
> No, not udelay. Or any delay for that matter. If spinning on a
> condition, then there is no advantage to burning cycles with a
> udelay(). Those cycles may as well be used to keep testing the
> condition so the loop can be exited faster. a udelay() would only
> serve to always make the busywait longer.
Well, there's a non-empty set of HW where polling as fast as you can
will effectively prevent it to make fwd progress...
Ben.
^ permalink raw reply
* Re: [PATCH v5] introduce macro spin_event_timeout()
From: Timur Tabi @ 2009-03-11 21:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <1236808190.7086.61.camel@pasglop>
Benjamin Herrenschmidt wrote:
> Well, there's a non-empty set of HW where polling as fast as you can
> will effectively prevent it to make fwd progress...
Alan Cox mentioned this. He gave PCI and 10us as an example. I suggested
adding a third parameter that would be a udelay() inserted into the loop. He
countered with this:
spin_until_timeout(readb(foo) & 0x80, 30 * HZ) {
udelay(10);
/* Maybe do other stuff */
}
But I don't know how to make that work *and* have it return a value indicating
timeout or success.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
From: Josh Boyer @ 2009-03-11 21:57 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, Stefan Roese, lebon
In-Reply-To: <49B80BA3.1090301@ru.mvista.com>
On Wed, Mar 11, 2009 at 10:06:11PM +0300, Valentine Barshak wrote:
> Josh Boyer wrote:
>> On Tue, Mar 10, 2009 at 10:50:13PM +0300, Valentine Barshak wrote:
>>> I was just going to submit a patch for that too.
>>> Indeed, the denali_fixup_memsize() miscalculated a couple of address
>>> field widths. We were lucky to eventually get the right result,
>>> because the effect of the first error was killed by the other one.
>>> According to the AMCC 440EPX/GRX user manual,
>>> the Chip Select width is always fixed at 1 bit no matter
>>> what is actually read from register DDR_10.
>>> The workaround is to use a predefined chipselect value for 440EPx/GRx.
>>> Also, setting the REDUC bit (REDUC = 1) enables 32-bit data path.
>>> If REDUC = 0, full data path of 64 bits is used.
>>>
>>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>>> Signed-off-by: Mikhail Zolotaryov <lebon@lebon.org.ua>
>>
>> I've been looking over this one a bit more. At the moment, I'm inclined
>> to queue this up in my -next branch. I would like to see if Mikhail
>> could test it though, and have Valentine answer the question in the hard
>> wired part.
>
> I've been looking at the docs once again and actually I couldn't find an
> explanation there. And I don't have that e-mail from AMCC support that
> I got a while back regarding the issue anymore.
> There might have been some misunderstanding.
> The docs (PPC440EPX UM 19.2 Device Address Mapping) say that the chip
> select field width is always fixed at one bit, but this doesn't actually
> mean that there's always one chip select used.
> The patch works fine on Sequoia and another Sequoia-like board with 1GB
> RAM installed, but it might not work with 2GB RAM. I've tried to play
> with DDR0_10 settings and Sequoia works fine regardless of what's
> actually written to DDR0_10.
> So, probably the best way would be to fix that in u-boot
> amcc/sequoia/sdram.c by doing mtsdram(DDR0_10, 0x00000100); instead of
> mtsdram(DDR0_10, 0x00000300);
> Sorry, for confusion, but after reviewing the docs, I think that
> only REDUC interpretation has to be fixed. The chips select part should
> be fixed in u-boot sdram code for Sequoia as was originally proposed by
> Mikhail.
Ok, so we're back to using Mikhail's original patch then?
josh
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
From: Valentine @ 2009-03-11 22:08 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Stefan Roese, lebon
In-Reply-To: <20090311215728.GA12676@zod.rchland.ibm.com>
Josh Boyer wrote:
> On Wed, Mar 11, 2009 at 10:06:11PM +0300, Valentine Barshak wrote:
>> Josh Boyer wrote:
>>> On Tue, Mar 10, 2009 at 10:50:13PM +0300, Valentine Barshak wrote:
>>>> I was just going to submit a patch for that too.
>>>> Indeed, the denali_fixup_memsize() miscalculated a couple of address
>>>> field widths. We were lucky to eventually get the right result,
>>>> because the effect of the first error was killed by the other one.
>>>> According to the AMCC 440EPX/GRX user manual,
>>>> the Chip Select width is always fixed at 1 bit no matter
>>>> what is actually read from register DDR_10.
>>>> The workaround is to use a predefined chipselect value for 440EPx/GRx.
>>>> Also, setting the REDUC bit (REDUC = 1) enables 32-bit data path.
>>>> If REDUC = 0, full data path of 64 bits is used.
>>>>
>>>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>>>> Signed-off-by: Mikhail Zolotaryov <lebon@lebon.org.ua>
>>> I've been looking over this one a bit more. At the moment, I'm inclined
>>> to queue this up in my -next branch. I would like to see if Mikhail
>>> could test it though, and have Valentine answer the question in the hard
>>> wired part.
>> I've been looking at the docs once again and actually I couldn't find an
>> explanation there. And I don't have that e-mail from AMCC support that
>> I got a while back regarding the issue anymore.
>> There might have been some misunderstanding.
>> The docs (PPC440EPX UM 19.2 Device Address Mapping) say that the chip
>> select field width is always fixed at one bit, but this doesn't actually
>> mean that there's always one chip select used.
>> The patch works fine on Sequoia and another Sequoia-like board with 1GB
>> RAM installed, but it might not work with 2GB RAM. I've tried to play
>> with DDR0_10 settings and Sequoia works fine regardless of what's
>> actually written to DDR0_10.
>> So, probably the best way would be to fix that in u-boot
>> amcc/sequoia/sdram.c by doing mtsdram(DDR0_10, 0x00000100); instead of
>> mtsdram(DDR0_10, 0x00000300);
>> Sorry, for confusion, but after reviewing the docs, I think that
>> only REDUC interpretation has to be fixed. The chips select part should
>> be fixed in u-boot sdram code for Sequoia as was originally proposed by
>> Mikhail.
>
> Ok, so we're back to using Mikhail's original patch then?
>
> josh
Yes, but until u-boot is fixed this will break Sequoia/Rainier support.
Thanks,
Valentine.
^ permalink raw reply
* [PATCH] powerpc: make sysfs code use smp_call_function_single
From: Rusty Russell @ 2009-03-11 22:20 UTC (permalink / raw)
To: linuxppc-dev
Impact: performance improvement
This fixes 'powerpc: avoid cpumask games in arch/powerpc/kernel/sysfs.c'
which talked about using smp_call_function_single, but actually used
work_on_cpu (an older version of the patch).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
arch/powerpc/kernel/sysfs.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -135,14 +135,14 @@ EXPORT_SYMBOL(ppc_enable_pmcs);
EXPORT_SYMBOL(ppc_enable_pmcs);
#define SYSFS_PMCSETUP(NAME, ADDRESS) \
-static long read_##NAME(void *junk) \
+static void read_##NAME(void *val) \
{ \
- return mfspr(ADDRESS); \
+ *(unsigned long *)val = mfspr(ADDRESS); \
} \
static long write_##NAME(void *val) \
{ \
ppc_enable_pmcs(); \
- mtspr(ADDRESS, (unsigned long)val); \
+ mtspr(ADDRESS, *(unsigned long *)val); \
return 0; \
} \
static ssize_t show_##NAME(struct sys_device *dev, \
@@ -150,7 +150,8 @@ static ssize_t show_##NAME(struct sys_de
char *buf) \
{ \
struct cpu *cpu = container_of(dev, struct cpu, sysdev); \
- unsigned long val = work_on_cpu(cpu->sysdev.id, read_##NAME, NULL); \
+ unsigned long val; \
+ smp_call_function_single(cpu->sysdev.id, read_##NAME, &val, 1); \
return sprintf(buf, "%lx\n", val); \
} \
static ssize_t __used \
@@ -162,7 +163,7 @@ static ssize_t __used \
int ret = sscanf(buf, "%lx", &val); \
if (ret != 1) \
return -EINVAL; \
- work_on_cpu(cpu->sysdev.id, write_##NAME, (void *)val); \
+ smp_call_function_single(cpu->sysdev.id, write_##NAME, &val, 1); \
return count; \
}
^ permalink raw reply
* Re: NFS problems on a MPC5200-based board
From: Gerhard Pircher @ 2009-03-11 22:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt, tur; +Cc: linuxppc-dev
In-Reply-To: <1236807566.7086.51.camel@pasglop>
-------- Original-Nachricht --------
> Datum: Thu, 12 Mar 2009 08:39:26 +1100
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: "Bartłomiej Sięka" <tur@semihalf.com>
> CC: linuxppc-dev@ozlabs.org, gerhard_pircher@gmx.net, Grant Likely <grant.likely@secretlab.ca>
> Betreff: Re: NFS problems on a MPC5200-based board
> On Wed, 2009-03-11 at 16:08 +0100, Bartłomiej Sięka wrote:
> > Hi,
> >
> > This is a follow-up on NFS problems on an MPC5200-based board reported
> > here a while back:
> >
> >
> http://www.nabble.com/-PATCH--Add-support-for-the-digsy-MTC-board.-to21750004.html#a21792612
> >
> > To recap: while using NFS, especially while mounting the root
> > filesystem over NFS, the system is really slow and displays a bunch of
> > "nfs: server 192.168.1.1 not responding, still trying" messages.
> > Sometimes it is able to get to the login prompt, sometimes not. In
> > cases where the login is successful, the system is still extremely
> > sluggish (console hangs for tens of seconds and longer).
> >
> > git bisect narrows down the troublesome commit as:
>
> Maybe you need to set CPU_FTR_NEED_COHERENT for the 5200 ?
I would say the same, as the patch just replicates the
CPU_FTR_NEED_COHERENT handling of the hash page table code.
regards,
Gerhard
> > commit 4c456a67f501b8b15542c7c21c28812bf88f484b
> > Author: Gerhard Pircher <gerhard_pircher@gmx.net>
> > Date: Fri Jan 23 06:51:28 2009 +0000
> >
> > powerpc/mm: Fix handling of _PAGE_COHERENT in BAT setup code
> >
> > _PAGE_COHERENT is now always set in _PAGE_RAM resp. PAGE_KERNEL.
> > Thus it has to be masked out, if the BAT mapping should be non
> > cacheable or CPU_FTR_NEED_COHERENT is not set.
> >
> > This will work on normal SMP setups because we force-set
> > CPU_FTR_NEED_COHERENT as part of CPU_FTR_COMMON on SMP.
> >
> > Signed-off-by: Gerhard Pircher <gerhard_pircher@gmx.net>
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> >
> >
> > We have tested recent mainline kernel (past 2.6.29-rc7) with the
> > 4c456a6...
> > commit reverted and NFS problems went away.
> >
> > Other people have also reported similar problems (original posters on
> > Cc):
> >
> http://www.nabble.com/-PATCH--Add-support-for-the-digsy-MTC-board.-tp21750004p21792825.html
> >
> http://www.nabble.com/-PATCH--Add-support-for-the-digsy-MTC-board.-tp21750004p21792612.html
> >
> > The commit in question does not look directly related to NFS/
> > networking; moreover it is a fix for some other problem, so just
> > reverting it is not an option, it seems (?). So how do we go about
> > having NFS operational again? Any comments?
> >
> > Regards,
> > Bartlomiej Sieka
--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01
^ permalink raw reply
* Re: [PATCH v5] introduce macro spin_event_timeout()
From: Scott Wood @ 2009-03-11 22:49 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <49B83332.9040201@freescale.com>
Timur Tabi wrote:
> Benjamin Herrenschmidt wrote:
>
>> Well, there's a non-empty set of HW where polling as fast as you can
>> will effectively prevent it to make fwd progress...
>
> Alan Cox mentioned this. He gave PCI and 10us as an example. I
> suggested adding a third parameter that would be a udelay() inserted
> into the loop. He countered with this:
>
> spin_until_timeout(readb(foo) & 0x80, 30 * HZ) {
> udelay(10);
> /* Maybe do other stuff */
> }
Hmm, the person objecting that it could lead to people using it for
excessive timeouts suggested a timeout of *30 seconds*?
> But I don't know how to make that work *and* have it return a value
> indicating timeout or success.
And it also doesn't allow using the udelay as part of the timeout mechanism.
-Scott
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
From: Josh Boyer @ 2009-03-11 23:07 UTC (permalink / raw)
To: Valentine; +Cc: linuxppc-dev, Stefan Roese, lebon
In-Reply-To: <49B8367B.5060402@ru.mvista.com>
On Thu, Mar 12, 2009 at 01:08:59AM +0300, Valentine wrote:
>>> So, probably the best way would be to fix that in u-boot
>>> amcc/sequoia/sdram.c by doing mtsdram(DDR0_10, 0x00000100); instead
>>> of mtsdram(DDR0_10, 0x00000300);
>>> Sorry, for confusion, but after reviewing the docs, I think that
>>> only REDUC interpretation has to be fixed. The chips select part
>>> should be fixed in u-boot sdram code for Sequoia as was originally
>>> proposed by Mikhail.
>>
>> Ok, so we're back to using Mikhail's original patch then?
>>
>> josh
>
> Yes, but until u-boot is fixed this will break Sequoia/Rainier support.
Well, that's sort of a problem. The wrapper will have to deal with both
a fixed and unfixed u-boot because not everyone will update their u-boot
with the fix.
So we need a patch for the wrapper that works in all cases.
josh
^ permalink raw reply
* [PATCH v3] powerpc: clean up ssi.txt, add definition for fsl, ssi-asynchronous
From: Timur Tabi @ 2009-03-12 0:22 UTC (permalink / raw)
To: linuxppc-dev, galak
Add the definition of the fsl,ssi-asynchronous property to ssi.txt (documentation
of the device tree bindings for the Freescale SSI device).
Also tidy up the layout of ssi.txt.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
v3: rebased
v2: fixed typo, improved wording.
Documentation/powerpc/dts-bindings/fsl/ssi.txt | 68 ++++++++++++++----------
1 files changed, 39 insertions(+), 29 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/ssi.txt b/Documentation/powerpc/dts-bindings/fsl/ssi.txt
index 7313322..5ff76c9 100644
--- a/Documentation/powerpc/dts-bindings/fsl/ssi.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/ssi.txt
@@ -4,46 +4,56 @@ The SSI is a serial device that communicates with audio codecs. It can
be programmed in AC97, I2S, left-justified, or right-justified modes.
Required properties:
-- compatible : compatible list, containing "fsl,ssi"
-- cell-index : the SSI, <0> = SSI1, <1> = SSI2, and so on
-- reg : offset and length of the register set for the device
-- interrupts : <a b> where a is the interrupt number and b is a
- field that represents an encoding of the sense and
- level information for the interrupt. This should be
- encoded based on the information in section 2)
- depending on the type of interrupt controller you
- have.
-- interrupt-parent : the phandle for the interrupt controller that
- services interrupts for this device.
-- fsl,mode : the operating mode for the SSI interface
- "i2s-slave" - I2S mode, SSI is clock slave
- "i2s-master" - I2S mode, SSI is clock master
- "lj-slave" - left-justified mode, SSI is clock slave
- "lj-master" - l.j. mode, SSI is clock master
- "rj-slave" - right-justified mode, SSI is clock slave
- "rj-master" - r.j., SSI is clock master
- "ac97-slave" - AC97 mode, SSI is clock slave
- "ac97-master" - AC97 mode, SSI is clock master
-- fsl,playback-dma: phandle to a node for the DMA channel to use for
+- compatible: Compatible list, contains "fsl,ssi".
+- cell-index: The SSI, <0> = SSI1, <1> = SSI2, and so on.
+- reg: Offset and length of the register set for the device.
+- interrupts: <a b> where a is the interrupt number and b is a
+ field that represents an encoding of the sense and
+ level information for the interrupt. This should be
+ encoded based on the information in section 2)
+ depending on the type of interrupt controller you
+ have.
+- interrupt-parent: The phandle for the interrupt controller that
+ services interrupts for this device.
+- fsl,mode: The operating mode for the SSI interface.
+ "i2s-slave" - I2S mode, SSI is clock slave
+ "i2s-master" - I2S mode, SSI is clock master
+ "lj-slave" - left-justified mode, SSI is clock slave
+ "lj-master" - l.j. mode, SSI is clock master
+ "rj-slave" - right-justified mode, SSI is clock slave
+ "rj-master" - r.j., SSI is clock master
+ "ac97-slave" - AC97 mode, SSI is clock slave
+ "ac97-master" - AC97 mode, SSI is clock master
+- fsl,playback-dma: Phandle to a node for the DMA channel to use for
playback of audio. This is typically dictated by SOC
design. See the notes below.
-- fsl,capture-dma: phandle to a node for the DMA channel to use for
+- fsl,capture-dma: Phandle to a node for the DMA channel to use for
capture (recording) of audio. This is typically dictated
by SOC design. See the notes below.
-- fsl,fifo-depth: the number of elements in the transmit and receive FIFOs.
+- fsl,fifo-depth: The number of elements in the transmit and receive FIFOs.
This number is the maximum allowed value for SFCSR[TFWM0].
+- fsl,ssi-asynchronous:
+ If specified, the SSI is to be programmed in asynchronous
+ mode. In this mode, pins SRCK, STCK, SRFS, and STFS must
+ all be connected to valid signals. In synchronous mode,
+ SRCK and SRFS are ignored. Asynchronous mode allows
+ playback and capture to use different sample sizes and
+ sample rates. Some drivers may require that SRCK and STCK
+ be connected together, and SRFS and STFS be connected
+ together. This would still allow different sample sizes,
+ but not different sample rates.
Optional properties:
-- codec-handle : phandle to a 'codec' node that defines an audio
- codec connected to this SSI. This node is typically
- a child of an I2C or other control node.
+- codec-handle: Phandle to a 'codec' node that defines an audio
+ codec connected to this SSI. This node is typically
+ a child of an I2C or other control node.
Child 'codec' node required properties:
-- compatible : compatible list, contains the name of the codec
+- compatible: Compatible list, contains the name of the codec
Child 'codec' node optional properties:
-- clock-frequency : The frequency of the input clock, which typically
- comes from an on-board dedicated oscillator.
+- clock-frequency: The frequency of the input clock, which typically comes
+ from an on-board dedicated oscillator.
Notes on fsl,playback-dma and fsl,capture-dma:
--
1.6.1.3
^ permalink raw reply related
* Interrupt mapping for MPC8323 board
From: Praveen VS @ 2009-03-12 3:38 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 923 bytes --]
We have a board similar to the MPC8323 rdb. In the board we have
connected the IDSEL to AD18 & we have only one minipci connector for it. We
have interfaced a Wlan Card . When we do
# lspci -x we get following
00:12.0 Network controller: RaLink RT2561/RT61 802.11g PCI
00: 14 18 01 03 07 00 10 04 00 00 80 02 08 80 00 00
10: 00 80 00 90 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 01 06 00 00 14 18 61 25
30: 00 00 00 00 40 00 00 00 00 00 00 00 13 01 00 00
In our circuit INTA is connected to IRQ4 . We are unable
to transmit thro this card. We are not getting any interrupts.We want to
make sure where to give the mapping of interrupts ?
how to give that for IDsel AD 18, INTA should be mapped to IRQ4 .
Is it that we need to change the dts file & create a new dtb? if so where to get exact meaning of how to configure "interrupt mapping" in the dts file
Regards
Praveen
[-- Attachment #2: Type: text/html, Size: 1602 bytes --]
^ permalink raw reply
* [PATCH 1/3] powerpc: Fix page_ins details in lppaca comments
From: Jeremy Kerr @ 2009-03-12 3:55 UTC (permalink / raw)
To: Ben Herrenschmidt; +Cc: linuxppc-dev
The page_ins member ends at byte 0x3, not 0x4. Also, fix up the
alignment.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
---
arch/powerpc/include/asm/lppaca.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/lppaca.h b/arch/powerpc/include/asm/lppaca.h
index 25aaa97..b063121 100644
--- a/arch/powerpc/include/asm/lppaca.h
+++ b/arch/powerpc/include/asm/lppaca.h
@@ -133,7 +133,7 @@ struct lppaca {
//=============================================================================
// CACHE_LINE_4-5 0x0180 - 0x027F Contains PMC interrupt data
//=============================================================================
- u32 page_ins; // CMO Hint - # page ins by OS x00-x04
+ u32 page_ins; // CMO Hint - # page ins by OS x00-x03
u8 pmc_save_area[252]; // PMC interrupt Area x04-xFF
} __attribute__((__aligned__(0x400)));
^ permalink raw reply related
* [PATCH 2/3] powerpc: Add dispatch trace log fields to lppaca
From: Jeremy Kerr @ 2009-03-12 3:55 UTC (permalink / raw)
To: Ben Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1236830152.728754.855135891014.1.gpush@pingu>
PAPR v2.3 defines fields in the virtual processor area for a dispatch
trace log (DLT). Since we'd like to use the DLT, add the necessary
fields to struct lppaca.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
---
arch/powerpc/include/asm/lppaca.h | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/lppaca.h b/arch/powerpc/include/asm/lppaca.h
index b063121..68235f7 100644
--- a/arch/powerpc/include/asm/lppaca.h
+++ b/arch/powerpc/include/asm/lppaca.h
@@ -97,7 +97,7 @@ struct lppaca {
u64 saved_gpr4; // Saved GPR4 x28-x2F
u64 saved_gpr5; // Saved GPR5 x30-x37
- u8 reserved4; // Reserved x38-x38
+ u8 dtl_enable_mask; // Dispatch Trace Log mask x38-x38
u8 donate_dedicated_cpu; // Donate dedicated CPU cycles x39-x39
u8 fpregs_in_use; // FP regs in use x3A-x3A
u8 pmcregs_in_use; // PMC regs in use x3B-x3B
@@ -134,7 +134,9 @@ struct lppaca {
// CACHE_LINE_4-5 0x0180 - 0x027F Contains PMC interrupt data
//=============================================================================
u32 page_ins; // CMO Hint - # page ins by OS x00-x03
- u8 pmc_save_area[252]; // PMC interrupt Area x04-xFF
+ u8 reserved8[148]; // Reserved x04-x97
+ volatile u64 dtl_idx; // Dispatch Trace Log head idx x98-x9F
+ u8 reserved9[96]; // Reserved xA0-xFF
} __attribute__((__aligned__(0x400)));
extern struct lppaca lppaca[];
^ permalink raw reply related
* [PATCH 3/3] powerpc: Add virtual processor dispatch trace log
From: Jeremy Kerr @ 2009-03-12 3:55 UTC (permalink / raw)
To: Ben Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1236830152.728754.855135891014.1.gpush@pingu>
pseries SPLPAR machines are able to retrieve a log of dispatch and
preempt events from the hypervisor. With this information, we can
see when and why each dispatch & preempt is occuring.
This change adds a set of debugfs files allowing userspace to read this
dispatch log.
Based on initial patches from Nishanth Aravamudan <nacc@us.ibm.com>.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
---
arch/powerpc/platforms/pseries/Kconfig | 10
arch/powerpc/platforms/pseries/Makefile | 1
arch/powerpc/platforms/pseries/dtl.c | 274 ++++++++++++++++++++++++
arch/powerpc/platforms/pseries/plpar_wrappers.h | 10
4 files changed, 295 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
index ddc2a30..730a5cd 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -63,3 +63,13 @@ config CMM
makes sense for a system running in an LPAR where the unused pages
will be reused for other LPARs. The interface allows firmware to
balance memory across many LPARs.
+
+config DTL
+ bool "Dispatch Trace Log"
+ depends on PPC_SPLPAR && DEBUG_FS
+ help
+ SPLPAR machines can log hypervisor preempt & dispatch events to a
+ kernel buffer. Saying Y here will enable logging these events,
+ which are accessible through a debugfs file.
+
+ Say N if you are unsure.
diff --git a/arch/powerpc/platforms/pseries/Makefile b/arch/powerpc/platforms/pseries/Makefile
index dfe574a..1b388b3 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_HVCS) += hvcserver.o
obj-$(CONFIG_HCALL_STATS) += hvCall_inst.o
obj-$(CONFIG_PHYP_DUMP) += phyp_dump.o
obj-$(CONFIG_CMM) += cmm.o
+obj-$(CONFIG_DTL) += dtl.o
diff --git a/arch/powerpc/platforms/pseries/dtl.c b/arch/powerpc/platforms/pseries/dtl.c
new file mode 100644
index 0000000..dc9b0f8
--- /dev/null
+++ b/arch/powerpc/platforms/pseries/dtl.c
@@ -0,0 +1,274 @@
+/*
+ * Virtual Processor Dispatch Trace Log
+ *
+ * (C) Copyright IBM Corporation 2009
+ *
+ * Author: Jeremy Kerr <jk@ozlabs.org>
+ *
+ * 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, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/init.h>
+#include <linux/debugfs.h>
+#include <asm/smp.h>
+#include <asm/system.h>
+#include <asm/uaccess.h>
+
+#include "plpar_wrappers.h"
+
+/*
+ * Layout of entries in the hypervisor's DTL buffer. Although we don't
+ * actually access the internals of an entry (we only need to know the size),
+ * we might as well define it here for reference.
+ */
+struct dtl_entry {
+ u8 dispatch_reason;
+ u8 preempt_reason;
+ u16 processor_id;
+ u32 enqueue_to_dispatch_time;
+ u32 ready_to_enqueue_time;
+ u32 waiting_to_ready_time;
+ u64 timebase;
+ u64 fault_addr;
+ u64 srr0;
+ u64 srr1;
+};
+
+struct dtl {
+ struct dtl_entry *buf;
+ struct dentry *file;
+ int cpu;
+ int buf_entries;
+ u64 last_idx;
+};
+static DEFINE_PER_CPU(struct dtl, dtl);
+
+/*
+ * Dispatch trace log event mask:
+ * 0x7: 0x1: voluntary virtual processor waits
+ * 0x2: time-slice preempts
+ * 0x4: virtual partition memory page faults
+ */
+static u8 dtl_event_mask = 0x7;
+
+
+/*
+ * Size of per-cpu log buffers. Default is just under 16 pages worth.
+ */
+static int dtl_buf_entries = (16 * 85);
+
+
+static int dtl_enable(struct dtl *dtl)
+{
+ unsigned long addr;
+ int ret, hwcpu;
+
+ /* only allow one reader */
+ if (dtl->buf)
+ return -EBUSY;
+
+ /* we need to store the original allocation size for use during read */
+ dtl->buf_entries = dtl_buf_entries;
+
+ dtl->buf = kmalloc_node(dtl->buf_entries * sizeof(struct dtl_entry),
+ GFP_KERNEL, cpu_to_node(dtl->cpu));
+ if (!dtl->buf) {
+ printk(KERN_WARNING "%s: buffer alloc failed for cpu %d\n",
+ __func__, dtl->cpu);
+ return -ENOMEM;
+ }
+
+ /* Register our dtl buffer with the hypervisor. The HV expects the
+ * buffer size to be passed in the second word of the buffer */
+ ((u32 *)dtl->buf)[1] = dtl->buf_entries * sizeof(struct dtl_entry);
+
+ hwcpu = get_hard_smp_processor_id(dtl->cpu);
+ addr = __pa(dtl->buf);
+ ret = register_dtl(hwcpu, addr);
+ if (ret) {
+ printk(KERN_WARNING "%s: DTL registration for cpu %d (hw %d) "
+ "failed with %d\n", __func__, dtl->cpu, hwcpu, ret);
+ kfree(dtl->buf);
+ return -EIO;
+ }
+
+ /* set our initial buffer indices */
+ dtl->last_idx = lppaca[dtl->cpu].dtl_idx = 0;
+
+ /* enable event logging */
+ lppaca[dtl->cpu].dtl_enable_mask = dtl_event_mask;
+
+ return 0;
+}
+
+static void dtl_disable(struct dtl *dtl)
+{
+ int hwcpu = get_hard_smp_processor_id(dtl->cpu);
+
+ lppaca[dtl->cpu].dtl_enable_mask = 0x0;
+
+ unregister_dtl(hwcpu, __pa(dtl->buf));
+
+ kfree(dtl->buf);
+ dtl->buf = NULL;
+ dtl->buf_entries = 0;
+}
+
+/* file interface */
+
+static int dtl_file_open(struct inode *inode, struct file *filp)
+{
+ struct dtl *dtl = inode->i_private;
+ int rc;
+
+ rc = dtl_enable(dtl);
+ if (rc)
+ return rc;
+
+ filp->private_data = dtl;
+ return 0;
+}
+
+static int dtl_file_release(struct inode *inode, struct file *filp)
+{
+ struct dtl *dtl = inode->i_private;
+ dtl_disable(dtl);
+ return 0;
+}
+
+static ssize_t dtl_file_read(struct file *filp, char __user *buf, size_t len,
+ loff_t *pos)
+{
+ int rc, cur_idx, last_idx, n_read, n_req, read_size;
+ struct dtl *dtl;
+
+ if ((len % sizeof(struct dtl_entry)) != 0)
+ return -EINVAL;
+
+ dtl = filp->private_data;
+
+ /* requested number of entries to read */
+ n_req = len / sizeof(struct dtl_entry);
+
+ /* actual number of entries read */
+ n_read = 0;
+
+ cur_idx = lppaca[dtl->cpu].dtl_idx;
+ last_idx = dtl->last_idx;
+
+ if (cur_idx - last_idx > dtl->buf_entries) {
+ pr_debug("%s: hv buffer overflow for cpu %d, samples lost\n",
+ __func__, dtl->cpu);
+ }
+
+ cur_idx %= dtl->buf_entries;
+ last_idx %= dtl->buf_entries;
+
+ /* read the tail of the buffer if we've wrapped */
+ if (last_idx > cur_idx) {
+ read_size = min(n_req, dtl->buf_entries - last_idx);
+
+ rc = copy_to_user(buf, &dtl->buf[last_idx],
+ read_size * sizeof(struct dtl_entry));
+ if (rc)
+ return -EFAULT;
+
+ last_idx = 0;
+ n_req -= read_size;
+ n_read += read_size;
+ buf += read_size * sizeof(struct dtl_entry);
+ }
+
+ /* .. and now the head */
+ read_size = min(n_req, cur_idx - last_idx);
+ rc = copy_to_user(buf, &dtl->buf[last_idx],
+ read_size * sizeof(struct dtl_entry));
+ if (rc)
+ return -EFAULT;
+
+ n_read += read_size;
+ dtl->last_idx += n_read;
+
+ return n_read * sizeof(struct dtl_entry);
+}
+
+static struct file_operations dtl_fops = {
+ .open = dtl_file_open,
+ .release = dtl_file_release,
+ .read = dtl_file_read,
+ .llseek = no_llseek,
+};
+
+static struct dentry *dtl_dir;
+
+static int dtl_setup_file(struct dtl *dtl)
+{
+ char name[10];
+
+ sprintf(name, "cpu-%d", dtl->cpu);
+
+ dtl->file = debugfs_create_file(name, 0400, dtl_dir, dtl, &dtl_fops);
+ if (!dtl->file)
+ return -ENOMEM;
+
+ return 0;
+}
+
+static int dtl_init(void)
+{
+ struct dentry *event_mask_file, *buf_entries_file;
+ int rc, i;
+
+ if (!firmware_has_feature(FW_FEATURE_SPLPAR))
+ return -ENODEV;
+
+ /* set up common debugfs structure */
+
+ rc = -ENOMEM;
+ dtl_dir = debugfs_create_dir("dtl", powerpc_debugfs_root);
+ if (!dtl_dir) {
+ printk(KERN_WARNING "%s: can't create dtl root dir\n",
+ __func__);
+ goto err;
+ }
+
+ event_mask_file = debugfs_create_x8("dtl_event_mask", 0600,
+ dtl_dir, &dtl_event_mask);
+ buf_entries_file = debugfs_create_u32("dtl_buf_entries", 0600,
+ dtl_dir, &dtl_buf_entries);
+
+ if (!event_mask_file || !buf_entries_file) {
+ printk(KERN_WARNING "%s: can't create dtl files\n", __func__);
+ goto err_remove_dir;
+ }
+
+ /* set up the per-cpu log structures */
+ for_each_possible_cpu(i) {
+ struct dtl *dtl = &per_cpu(dtl, i);
+ dtl->cpu = i;
+
+ rc = dtl_setup_file(dtl);
+ if (rc)
+ goto err_remove_dir;
+ }
+
+ return 0;
+
+err_remove_dir:
+ debugfs_remove_recursive(dtl_dir);
+err:
+ return rc;
+}
+arch_initcall(dtl_init);
diff --git a/arch/powerpc/platforms/pseries/plpar_wrappers.h b/arch/powerpc/platforms/pseries/plpar_wrappers.h
index d967c18..a24a6b2 100644
--- a/arch/powerpc/platforms/pseries/plpar_wrappers.h
+++ b/arch/powerpc/platforms/pseries/plpar_wrappers.h
@@ -43,6 +43,16 @@ static inline long register_slb_shadow(unsigned long cpu, unsigned long vpa)
return vpa_call(0x3, cpu, vpa);
}
+static inline long unregister_dtl(unsigned long cpu, unsigned long vpa)
+{
+ return vpa_call(0x6, cpu, vpa);
+}
+
+static inline long register_dtl(unsigned long cpu, unsigned long vpa)
+{
+ return vpa_call(0x2, cpu, vpa);
+}
+
static inline long plpar_page_set_loaned(unsigned long vpa)
{
unsigned long cmo_page_sz = cmo_get_page_size();
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox