On Thu, May 30, 2013 at 01:57:42PM -0500, Scott Wood wrote:
> On 05/29/2013 10:25:25 PM, Kevin Hao wrote:
> >On Tue, May 28, 2013 at 05:45:56PM -0500, Scott Wood wrote:
> >> On 05/16/2013 01:29:45 AM, Kevin Hao wrote:
> >> >All these boards use the same configuration file p1_p2_rdb_pc.h in
> >> >u-
From: Tang Yuantian
The following SoCs will be affected: p2041, p3041, p4080,
p5020, p5040, b4420, b4860, t4240
Signed-off-by: Tang Yuantian
Signed-off-by: Li Yang
---
v2:
- add t4240, b4420, b4860 support
- remove pll/4 clock from p2041, p3041 and p5020 board
arch/powerpc/bo
From: Sebastian Hesselbarth
Date: Fri, 31 May 2013 08:28:58 +0200
> thanks for pulling these in. I finally found how to check if a patch
> already went into -stable. As Jason already said, the mdio patch that
> #1 fixes did not yet went into -stable. Can you unqueue it? Sorry for
> the confusion.
On Thu, 2013-05-30 at 11:24 -0500, Scott Wood wrote:
> ioremap() and out_bex/in_bex are not appropriate for PCI I/O regions
> (and presumably that's what it is, if pci_iomap is calling
> ioport_map). Big-endian is not appropriate for PCI in any case.
>
> The whole point of pci_iomap() appears
On Thu, 2013-05-30 at 17:40 -0700, wolfking wrote:
> hi, scott:
> Thanks for replying!
> > In what specific way does it not work?
> when I use iowrite8 to write, things seem OK, the codes continue running,
> when I use ioread8 to read, the console I use freezes. The console stops
> respondi
On Fri, 2013-05-31 at 14:41 +0800, Kevin Hao wrote:
> Hi Ben,
>
> Could you shed some light on this issue? Do we really has the restriction
> that we have to pick one bus controller as primary even there is no
> ISA bus on the board? I did check the current code and found no code
> has a requireme
This file is a common include for B4860 and B4420 but is not a valid DTS itself:
DTC arch/powerpc/boot/b4qds.dtb
Error: arch/powerpc/boot/dts/b4qds.dts:35.1-2 syntax error
FATAL ERROR: Unable to parse input tree
make[1]: *** [arch/powerpc/boot/b4qds.dtb] Error
This affects arch/powerpc/boot/dts/virtex440-ml510.dts but I think it is
actually a more general issue:
$ make ARCH=powerpc CROSS_COMPILE=powerpc-linux- virtex440-ml510.dtb
CC scripts/mod/devicetable-offsets.s
GEN scripts/mod/devicetable-offsets.h
HO
On 20 May 2013 10:10, Viresh Kumar wrote:
> On 13 May 2013 11:34, Viresh Kumar wrote:
>> On 22 April 2013 12:19, Viresh Kumar wrote:
>>> On 9 April 2013 14:05, Viresh Kumar wrote:
On 5 April 2013 12:16, Viresh Kumar wrote:
> On 4 April 2013 18:24, Viresh Kumar wrote:
>> This patc
From: "Aneesh Kumar K.V"
If a hash bucket gets full, we "evict" a more/less random entry from it.
When we do that we don't invalidate the TLB (hpte_remove) because we assume
the old translation is still technically "valid". This implies that when
we are invalidating or updating pte, even if HPTE
* Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo
>
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> The following changes since commit c0ffaf3655fab1909a920c8f30ba1722932d01bb:
>
> watchdog: Remove softlockup_thresh from Documentation (2013-05-28 11:28:20
While returning from exception handling in case of PREEMPT enabled,
_TIF_NEED_RESCHED bit is checked in TI_FLAGS (thread_info flag) of current
task. Only if this bit is set, it should continue with the process of
calling preempt_schedule_irq() to schedule highest priority task if
available.
Cu
On Mon, May 27, 2013 at 01:00:17PM +0530, Priyanka Jain wrote:
> While returning from exception handling in case of PREEMPT enabled,
> _TIF_NEED_RESCHED bit is checked in TI_FLAGS (thread_info flag) of current
> task. Only if this bit is set, it should continue with the process of
> calling preempt
On Fri, 31 May 2013 11:29:30 +0100, Ian Campbell
wrote:
> This affects arch/powerpc/boot/dts/virtex440-ml510.dts but I think it is
> actually a more general issue:
>
> $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux- virtex440-ml510.dtb
> CC scripts/mod/devicetable-offset
Arnaud,
On Fri, May 31, 2013 at 12:28:56AM +0200, Arnaud Ebalard wrote:
> Hi,
>
> Jason Cooper writes:
>
> >> For instance 6bd98481ab34 (arm: kirkwood: NETGEAR ReadyNAS Duo v2 init
> >> PCIe via DT) currently sitting in jcooper/mvebu/pcie_kirkwood removes
> >> the PCIE init routine in board-rea
On Fri, 2013-05-31 at 12:48 +0100, Grant Likely wrote:
> On Fri, 31 May 2013 11:29:30 +0100, Ian Campbell
> wrote:
> > This affects arch/powerpc/boot/dts/virtex440-ml510.dts but I think it is
> > actually a more general issue:
> >
> > $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-
> >
hi, Herrenschmidt
Thanks for replying to this topic!
> That looks more like a HW error to me unless you are hitting completely
> the wrong system addresses.
The HW is OK. If I plug this card into another ppc board: mpc86641-hpcn,
it works fine.
> What would be useful would be to add printk's t
On Fri, 2013-05-31 at 08:01 -0500, Jon Loeliger wrote:
> > >
> > > Line 374 is the "IDSEL 0x16..." line here:
> > > interrupt-map = <
> > > /* IRQ mapping for pci slots and ALI M1533
> > >...
> > >
On Fri, 2013-05-31 at 08:01 -0500, Jon Loeliger wrote:
> Hrm. Is this a "that's not in the kernel's copy yet" problem?
BTW I'm using dtc.git 4e76ec796c90d44d417f82d9db2d67cfe575f8ed and not
the kernel copy.
dtc-lexer.l in my HEAD is identical to the current master
(2e3fc7e9b3a4722a5500afaa9faf
> >
> > Line 374 is the "IDSEL 0x16..." line here:
> > interrupt-map = <
> > /* IRQ mapping for pci slots and ALI M1533
> > ...
> > * management core also isn't used.
> >
On 05/31/2013 05:48 AM, Grant Likely wrote:
> On Fri, 31 May 2013 11:29:30 +0100, Ian Campbell
> wrote:
>> This affects arch/powerpc/boot/dts/virtex440-ml510.dts but I think it is
>> actually a more general issue:
>>
>> $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux- virtex440-ml510.dtb
On Fri, May 31, 2013 at 5:04 PM, Stephen Warren wrote:
> On 05/31/2013 05:48 AM, Grant Likely wrote:
>> On Fri, 31 May 2013 11:29:30 +0100, Ian Campbell
>> wrote:
>>> This affects arch/powerpc/boot/dts/virtex440-ml510.dts but I think it is
>>> actually a more general issue:
>>>
>>> $ mak
On 05/31/2013 04:29 AM, Ian Campbell wrote:
> This affects arch/powerpc/boot/dts/virtex440-ml510.dts but I think it is
> actually a more general issue:
>
> $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux- virtex440-ml510.dtb
> CC scripts/mod/devicetable-offsets.s
>
From: Stephen Warren
Previously, the #line parsing regex ended with ({WS}+[0-9]+)?. The {WS}
could match line-break characters. If the #line directive did not contain
the optional flags field at the end, this could cause any integer data on
the next line to be consumed as part of the #line direct
Stephen Warren writes:
> Fix this by replacing {WS} with [ \t] so that it can't match line-breaks.
I think the other uses of {WS} shouldn't span lines either.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now fo
On 05/31/2013 11:38 AM, Andreas Schwab wrote:
> Stephen Warren writes:
>
>> Fix this by replacing {WS} with [ \t] so that it can't match line-breaks.
>
> I think the other uses of {WS} shouldn't span lines either.
That is true, but only the optional occurrence /should/ matter. Any
changes to th
From: Stephen Warren
Previously, the #line parsing regex ended with ({WS}+[0-9]+)?. The {WS}
could match line-break characters. If the #line directive did not contain
the optional flags field at the end, this could cause any integer data on
the next line to be consumed as part of the #line direct
On Tue, 2013-05-28 at 15:59 +0800, Zhao Chenhui wrote:
> Some features depend on the boot cpu, for instance, hibernate/suspend.
> So disable hotplug for the boot cpu.
Don't we have code to "move" the boot CPU around when that happens ?
Ben.
> Signed-off-by: Zhao Chenhui
> ---
> arch/powerpc/ke
On Fri, 2013-05-31 at 14:45 +0530, Aneesh Kumar K.V wrote:
> > The patch you are running on is what I'll send to Linus for 3.10 (+/-
> > cosmetics). Aneesh second patch is a much larger rework which will be
> > needed for THP but that will wait for 3.11. I'm happy for you to test it
> > but I firs
Hi Linus !
Here are a few more fixes for powerpc 3.10. It's a bit more than I would
have liked this late in the game but I suppose that's what happens with
a brand new chip generation coming out.
A few regression fixes, some last minute fixes for new P8 features such
as transactional memory,...
On 05/31/2013 01:43:49 AM, Kevin Hao wrote:
On Thu, May 30, 2013 at 01:54:59PM -0500, Scott Wood wrote:
> On 05/30/2013 05:20:34 AM, Kevin Hao wrote:
> >On Tue, May 28, 2013 at 05:52:09PM -0500, Scott Wood wrote:
> >> On 05/21/2013 07:04:58 AM, Kevin Hao wrote:
> >> >It also seems that we don't s
On Sat, 2013-06-01 at 09:22 +1000, Benjamin Herrenschmidt wrote:
> Hi Linus !
>
> Here are a few more fixes for powerpc 3.10. It's a bit more than I would
> have liked this late in the game but I suppose that's what happens with
> a brand new chip generation coming out.
>
> A few regression fixes,
On Mon, 2013-05-20 at 18:06 +0200, Marc Kleine-Budde wrote:
> On 05/17/2013 11:09 AM, Shawn Guo wrote:
> > On Fri, May 17, 2013 at 10:59:17AM +0200, Marc Kleine-Budde wrote:
> >> This patch removes the Kconfig symbol HAVE_CAN_FLEXCAN from
> >> arch/{arm,powerpc}
> >> and allowing compilation uncon
On Thu, May 30, 2013 at 10:47 AM, Vinod Koul wrote:
> On Mon, May 27, 2013 at 03:14:30PM +0300, Andy Shevchenko wrote:
>> Here is a set of small independent patches that clean up or fix minor things
>> across DMA slave drivers.
> The series looks fine. I am going to wait a day more and apply, pls
On Thu, 2013-05-30 at 16:23 +0800, Gavin Shan wrote:
> For EEH on PowerNV platform, the PCI devices will be probed to
> check if they support EEH functionality. Different from the case
> of EEH for pSeries platform, we will probe real PCI device instead
> of device tree node for EEH capability on P
On Thu, 2013-05-30 at 16:23 +0800, Gavin Shan wrote:
> While processing EEH event interrupt from P7IOC, we need function
> to retrieve the PE according to the indicated PCI host controller
> (struct pci_controller). The patch makes function eeh_phb_pe_get()
> public so that other source files can c
On Thu, 2013-05-30 at 16:23 +0800, Gavin Shan wrote:
> The patch changes the criteria used to judge if the PE has been
> resetted successfully. We needn't the PE status is exactly equal
> to the combo: (EEH_STATE_MMIO_ACTIVE | EEH_STATE_DMA_ACTIVE).
The comment above doesn't mean anything :-)
I a
Shaohui, greetings --
Xie Shaohui-B21989 writes:
> I found a MPC8315ERDB rev1.0 board and did some tests.
I bet that was fun. :) Thanks for going the extra mile and finding
that hardware. Were you able to unearth a 8315DS of any sort?
> First there is no limit speed issue on the board, so i
On Thu, 2013-05-30 at 16:23 +0800, Gavin Shan wrote:
> The patch adds the I/O chip backend to do PE reset. For now, we
> focus on PCI bus dependent PE. If PHB PE has been put into error
> state, the PHB will take complete reset. Besides, the root bridge
> will take fundamental or hot reset accordin
On Thu, 2013-05-30 at 16:24 +0800, Gavin Shan wrote:
> The patch adds EEH backends for PowerNV platform. It's notable that
> part of those EEH backends call to the I/O chip dependent backends.
Add a check for my new OPALv3 flag before registering since you rely
on a whole bunch of new APIs that th
On Thu, 2013-05-30 at 16:24 +0800, Gavin Shan wrote:
> The EEH error interrupts should have been exported by firmware
> through device tree. The OS already installed the interrupt
> handler (opal_interrupt()) for them. The patch checks if we have
> any existing EEH errors and wakes the kernel threa
On Thu, 2013-05-30 at 16:24 +0800, Gavin Shan wrote:
> The patch intends to add debugfs entry powerpc/EEH/PHBx so that
> the administrator can inject EEH errors to specified PCI host
> bridge for testing purpose.
Use a better naming for the debugfs files. Something like
eeh_err_inject/pci, to
On Thu, 2013-04-25 at 15:47 +0530, Aruna Balakrishnaiah wrote:
> Currently the kernel provides the contents of p-series NVRAM only as a
> simple stream of bytes via /dev/nvram, which must be interpreted in user
> space by the nvram command in the powerpc-utils package. This patch set
> exploits the
On Sat, 2013-06-01 at 14:40 +1000, Benjamin Herrenschmidt wrote:
.../...
> In fact, this applies to at least all the BookS server platforms...
>
> Things that come to mind:
>
> - nvram_64.c duplicates generic_nvram.c as far as the user accessors
> are concerned, it should be possible to get
On Thu, 2013-04-25 at 15:48 +0530, Aruna Balakrishnaiah wrote:
> This patch set exploits the pstore subsystem to read details of rtas partition
> in NVRAM to a separate file in /dev/pstore. For instance, rtas details will be
> stored in a file named [rtas-nvram-4].
>
.../...
> diff --git a/inclu
On Sat, 2013-06-01 at 14:49 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2013-04-25 at 15:48 +0530, Aruna Balakrishnaiah wrote:
> > This patch set exploits the pstore subsystem to read details of rtas
> > partition
> > in NVRAM to a separate file in /dev/pstore. For instance, rtas details will
On Thu, 2013-04-25 at 15:49 +0530, Aruna Balakrishnaiah wrote:
> diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
> index 8d4fb65..88cc050 100644
> --- a/fs/pstore/inode.c
> +++ b/fs/pstore/inode.c
> @@ -330,6 +330,9 @@ int pstore_mkfile(enum pstore_type_id type, char *psname,
> u64 id, int cou
On Fri, 2013-04-26 at 15:26 +0530, Aruna Balakrishnaiah wrote:
> The patch set supports compression of oops messages while writing to NVRAM,
> this helps in capturing more of oops data to lnx,oops-log. The pstore file
> for oops messages will be in decompressed format making it readable.
>
> In ca
Another question...
Should the core pstore fail to unlink partitions that don't have
an ->erase callback ? IE. Why would you let anyone erase the OFW
common partition for example ? That means that userspace tools
can no longer manipulate it but we certainly don't want to remove
it from the nvram i
On Fri, May 31, 2013 at 12:33:04PM -0600, Stephen Warren wrote:
> From: Stephen Warren
>
> Previously, the #line parsing regex ended with ({WS}+[0-9]+)?. The {WS}
> could match line-break characters. If the #line directive did not contain
> the optional flags field at the end, this could cause an
50 matches
Mail list logo
