The presence or absence of EBB is advertised to userspace via the presence
or absence of PPC_FEATURE2_EBB in cpu_user_features2.
Because the kernel can be built without PMU support, we should only add
PPC_FEATURE2_EBB to cpu_user_features2 when we successfully register the
power8 PMU support.
Sig
> From: Wood Scott-B07421
> Sent: Saturday, July 13, 2013 5:49
> To: Wang Dongsheng-B40534
> Cc: b...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Wang
> Dongsheng-B40534
> Subject: Re: [PATCH v2 1/2] powerpc: add Book E support to 64-bit hibernation
>
> On 07/11/2013 11:58:08 PM, Dongshen
Erratum A-006598 says that 64-bit mftb is not atomic -- it's subject
to the same race condition as doing mftbu/mftbl on 32-bit, thus we
need to use the same loop to safely read it.
This deals with kernel and vdso accesses, but other userspace accesses
will of course need to be fixed elsewhere.
Th
On 07/12/2013 04:31 PM, Tony Breeds wrote:
On Fri, Jul 12, 2013 at 10:27:41AM -0600, Chris Friesen wrote:
Hi all,
I'm trying to build current mainline git with gcc version 4.4.1 as a
cross compiler and I'm getting the following:
CC arch/powerpc/kernel/ptrace.o
{standard input}: Assemb
On Thu, Jul 11, 2013 at 08:21:54PM +0800, Kevin Hao wrote:
> By doing this we can make sure that the FPU state is only flushed to
> the thread struct when it is really needed.
>
> Signed-off-by: Kevin Hao
> ---
> arch/powerpc/kernel/traps.c | 9 -
> arch/powerpc/math-emu/math.c | 9
On Mon, Jul 08, 2013 at 12:18:39PM -0500, Scott Wood wrote:
> On 07/08/2013 02:16:04 AM, Haijun Zhang wrote:
> >On T4240QDS board controllers has an unusable ADMA engine, so use
> >SDMA instead.
> >Also 3.0v is support on T4240QDS board even if the capacity
> >detailed only 1.8v
> >support. Without
On Fri, 2013-07-12 at 16:54 -0500, Scott Wood wrote:
> set_context() doesn't exist for hash MMUs.
>
> Whatever you do, please try actually building it on various targets,
> including both 32 and 64 bits, and both hash and non-hash. And make
> sure that whatever effect PPC32 was depending on s
On Fri, 2013-07-12 at 15:53 -0500, Scott Wood wrote:
>
> It's not redundant at all to warn when an FPU is absent. It tells you
> that you're being slowed down by running hard-FP code instead of
> soft-FP code.
Right, just warn always.
Ben.
___
L
On Fri, 2013-07-12 at 10:27 -0600, Chris Friesen wrote:
> Hi all,
>
> I'm trying to build current mainline git with gcc version 4.4.1 as a
> cross compiler and I'm getting the following:
>
>
>CC arch/powerpc/kernel/ptrace.o
> {standard input}: Assembler messages:
> {standard input}:161
On 07/12/2013 03:08 PM, Chris Friesen wrote:
I turned on the instrumentation in early_init_dt_scan_memory() and got
the following when jumping to the capture kernel:
memory scan node memory, reg size 16, data: 0 0 2 0,
- 0 , 2
That 0x2 matches the fact that I'm seeing 8GB of me
On Fri, Jul 12, 2013 at 10:27:41AM -0600, Chris Friesen wrote:
> Hi all,
>
> I'm trying to build current mainline git with gcc version 4.4.1 as a
> cross compiler and I'm getting the following:
>
>
> CC arch/powerpc/kernel/ptrace.o
> {standard input}: Assembler messages:
> {standard input
On 07/11/2013 11:04:23 PM, Wang Dongsheng-B40534 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, July 11, 2013 5:43 AM
> To: Wang Dongsheng-B40534
> Cc: Wang Dongsheng-B40534; b...@kernel.crashing.org; Wood
Scott-B07421;
> johan...@sipsolutions.net; an...@enoms
On 07/11/2013 11:58:08 PM, Dongsheng Wang wrote:
+ /* Invalidate all tlbs */
+ bl _tlbil_all
Again, this will break on non-booke.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/li
On 07/11/2013 07:21 PM, Michael Ellerman wrote:
On Thu, Jul 11, 2013 at 03:22:49PM -0600, Chris Friesen wrote:
On 07/11/2013 02:55 PM, Chris Friesen wrote:
Hi,
I'm running 2.6.34 with kexec 2.0.1 on a Freescale p5020-based system
with 8GB of memory. (It's an embedded system and I can't do muc
On 07/11/2013 07:08:58 PM, Haijun Zhang wrote:
Overview of P1020RDB-PD device:
- DDR3 2GB
- NOR flash 64MB
- NAND flash 128MB
- SPI flash 16MB
- I2C EEPROM 256Kb
- eTSEC1 (RGMII PHY) connected to VSC7385 L2 switch
- eTSEC2 (SGMII PHY)
- eTSEC3 (RGMII PHY)
- SDHC
- 1 USB ports
- TDM ports
- PCIe
On 07/11/2013 09:25:12 PM, Kevin Hao wrote:
On Thu, Jul 11, 2013 at 09:30:02AM -0500, Scott Wood wrote:
> Sorry, that was my fault -- for some reason I didn't see that when I
> grepped for PPC_WARN_EMULATED looking for math stuff, and thus
> requested it be added. In any case, I don't see why it
On 07/12/2013 05:26 PM, Gerhard Sittig wrote:
[...]
> Lars, there is a checkpatch warning about a line longer than 80
> characters in the common xlate part -- I didn't dare to change your
> submission, and the part included here is verbatim from your patchwork
> 2331091 (original submission) and 25
Hi all,
I'm trying to build current mainline git with gcc version 4.4.1 as a
cross compiler and I'm getting the following:
CC arch/powerpc/kernel/ptrace.o
{standard input}: Assembler messages:
{standard input}:1619: Error: junk at end of line: `1'
{standard input}:2074: Error: junk at
On Fri, Jul 12, 2013 at 14:14 +0200, Gerhard Sittig wrote:
>
> We shall combine the parts which currently are floating around.
> So that others aren't supposed to pick up pieces but instead can
> use a series and get something consistent.
>
> Here are the parts that I'm aware of:
> - Anatolij's w
Q&D HACK to enable SD card support without correct COMMON_CLK support,
best viewed with 'git diff -w -b', NOT acceptable for mainline (NAKed)
Signed-off-by: Gerhard Sittig
---
drivers/mmc/host/mxcmmc.c | 41 +++--
1 file changed, 27 insertions(+), 14 deletio
From: Lars-Peter Clausen
From: Lars-Peter Clausen
This patch adds a new common OF dma xlate callback function which will match a
channel by it's id. The binding expects one integer argument which it will use
to
lookup the channel by the id.
Unlike of_dma_simple_xlate this function is able to
register the controller for device tree based lookup of DMA channels
(non-fatal for backwards compatibility with older device trees), provide
the '#dma-cells' property in the shared mpc5121.dtsi file, and introduce
a bindings document for the MPC512x DMA controller
Signed-off-by: Gerhard Sittig
-
for the DMA controller of the MPC512x SoC, DMA channels directly
correspond to specific peripherals, since requester lines directly map
to channels while no additional flexibility or mapping is involved
introduce a dt-bindings header file for MPC512x DMA channels, and make
the shared DT specs in t
prepare C preprocessor support when processing MPC512x DTS files
- switch from DTS syntax to CPP syntax for include specs
- create a symlink such that DTS processing can reference includes
Signed-off-by: Gerhard Sittig
---
arch/powerpc/boot/dts/ac14xx.dts |2 +-
arch/powerpc/boot/dt
implement the TERMINATE_ALL request in the device_control() callback
of the DMA engine driver for the MPC512x DMA controller
reword variable initialization to better follow the code path and to
avoid artificial diffs later on (this style change vanishes when this
patch gets squashed with the devic
adjust the conditions how submitted DMA jobs get started: memory transfers
need to get initiated by an explicit software request, all transfers which
involve peripherals need to reference the external requester line
Signed-off-by: Gerhard Sittig
---
drivers/dma/mpc512x_dma.c |4 +++-
1 file
From: Alexander Popov
From: Alexander Popov
Data transfers between memory and i/o memory require more delicate TCD
(Transfer Control Descriptor) configuration and DMA channel service requests
via hardware.
dma_device.device_control callback function is needed to configure
DMA channel to work w
blurb is below the stats
Alexander Popov (1):
powerpc: mpc512x_dma: add support for data transfers between memory
and i/o memory
Gerhard Sittig (6):
dma: mpc512x: fix start condition in execute()
dma: mpc512x: support 'terminate all' control request
dts: mpc512x: prepare for preproces
On Fri, Jul 12, 2013 at 07:11:35AM -0500, Timur Tabi wrote:
> Mark Brown wrote:
> >Yes, that's why I just went ahead - you'd said recently that you'd be
> >out of action for a while and not able to test anything.
> Yeah, I'd rather you waited until I at least made sure it compiled.
> Is there any
On Fri, Jul 12, 2013 at 07:11:35AM -0500, Timur Tabi wrote:
> Mark Brown wrote:
> >Yes, that's why I just went ahead - you'd said recently that you'd be
> >out of action for a while and not able to test anything.
>
> Yeah, I'd rather you waited until I at least made sure it compiled.
> Is there an
[ adding Lars to Cc: since we talk about OF-DMA ]
I put your DMA part of the series into a local test setup, and
slightly modified it in the suggested ways. This may not suffice
for a Tested-By attribute, since it did not test your LPB part
and did not use your original patch. But it verified th
Mark Brown wrote:
Yes, that's why I just went ahead - you'd said recently that you'd be
out of action for a while and not able to test anything.
Yeah, I'd rather you waited until I at least made sure it compiled. Is
there any way you can at least install the Freescale PowerPC SDK and do
comp
Moderator..can you change the subject of this to "Understanding register
usage as per ABI rules for functions" ??
Additionally, doesn't anyone have anything to say about this?
--
View this message in context:
http://linuxppc.10917.n7.nabble.com/ABI-defined-register-usage-within-function-calls-
Hello Gerhard
Thanks for the review.
I'll do my best to answer your questions and fix my code.
2013/7/10 Gerhard Sittig :
> On Wed, Jul 10, 2013 at 14:21 +0400, Alexander Popov wrote:
>> +/*
>> + * SCLPC Module (LPB FIFO)
>> + */
>> +enum lpb_dev_portsize {
>> + LPB_DEV_PORTSIZE_UNDEFINED =
2013/7/10 Gerhard Sittig :
> Disclaimer: It's been a while since I worked with the MPC512x
> DMA controller, and I only read the RM rev3 back then.
Hello Gerhard.
Thank you for fast and detailed feedback.
>> @@ -256,7 +256,9 @@ static void mpc_dma_execute(struct mpc_dma_chan *mchan)
>>
>>
On Thu, Jul 11, 2013 at 11:00:15PM -0500, Timur Tabi wrote:
> Nicolin Chen wrote:
> >If I'm not missing some part of branch updating, it looks like Mark hasn't
> >pushed it to the branch yet.
> >Please test it for me. Thank you.
> I definitely want to. Unfortunately, I'm literally in the middle
On Fri, 2013-07-12 at 13:36 +0800, Kevin Hao wrote:
> + /*
> +* If we support a HW FPU, we need to ensure the FP state
> +* if flushed into the thread_struct before attempting
> +* emulation
> +*/
> +#ifdef CONFIG_PPC_FPU
> + flush_fp_to_thread(current);
* Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo
>
> Hi Ingo,
>
> Please consider pulling,
>
> Regards,
>
> - Arnaldo
>
> The following changes since commit e5302920da9ef23f9d19d4e9ac85704cc25bee7a:
>
> perf: Fix interrupt handler timing harness (2013-07-05 08:54
38 matches
Mail list logo
