Hi Robert,
On Thu, 12 Jun 2008 17:23:11 -0500 Robert Jennings <[EMAIL PROTECTED]> wrote:
>
> + if(adapter->bounce_buffer != NULL) {
Space after "if". Here and elsewhere.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgphvgXx9uuaX.pgp
D
Hi Robert,
On Thu, 12 Jun 2008 17:22:49 -0500 Robert Jennings <[EMAIL PROTECTED]> wrote:
>
> + /* Deactivate all the buffer pools so that the next loop can activate
> +only the buffer pools necessary to hold the new MTU */
> + for(i = 0; ihttp://www.canb.auug.org.au/~sfr/
pgpKzB6
Hi Robert,
Firstly, can all this new stuff be ifdef'ed out if not needed as the
vio infrastructure is also used on legacy iSeries and this adds quite a
bit of stuff that won't ever be used there.
On Thu, 12 Jun 2008 17:19:59 -0500 Robert Jennings <[EMAIL PROTECTED]> wrote:
>
> +static int vio_cmo
On Thu, Jun 12, 2008 at 10:19 PM, David Gibson
<[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 08:10:47AM -0600, Grant Likely wrote:
> [snip]
>> > + [EMAIL PROTECTED] {
>> > + compatible = "fsl,mpc5121-i2c-ctrl";
>> > + reg = <0x1760 0x
On Thu, Jun 12, 2008 at 11:04:33AM +0200, Wolfram Sang wrote:
> Hello,
>
> a project I am working on consists of different hardware modules, which
> can be combined in a lot of variations (not at runtime, though). As each
> module shall contain an I2C-eeprom, the idea is now to put a fragment of
>
On Thu, Jun 12, 2008 at 08:10:47AM -0600, Grant Likely wrote:
[snip]
> > + [EMAIL PROTECTED] {
> > + compatible = "fsl,mpc5121-i2c-ctrl";
> > + reg = <0x1760 0x8>;
> > + };
> > +
> > + [EMAIL PROTECTED] {
>
> (ni
On Thu, Jun 12, 2008 at 07:46:48PM -0500, Jon Loeliger wrote:
> David Gibson wrote:
>
>>> It'd be nice if we could keep the filename around for reporting here...
>>
>> It would. Well, I've been intending to clean up the input file
>> handling in several ways already, I'll see if that can be worked
Hi,
Some comments and questions below.
-Olof
On Thu, Jun 12, 2008 at 05:19:36PM -0500, Robert Jennings wrote:
> Index: b/arch/powerpc/kernel/iommu.c
> ===
> --- a/arch/powerpc/kernel/iommu.c
> +++ b/arch/powerpc/kernel/iommu.c
> @@
David Gibson wrote:
It'd be nice if we could keep the filename around for reporting here...
It would. Well, I've been intending to clean up the input file
handling in several ways already, I'll see if that can be worked in.
With Scott's ACK on this, I intend commit David's patch.
So if yo
Hi Robert,
On Thu, 12 Jun 2008 17:08:58 -0500 Robert Jennings <[EMAIL PROTECTED]> wrote:
>
> - seq_printf(m, "R4=0x%lx\n", h_entitled);
> - seq_printf(m, "R5=0x%lx\n", h_unallocated);
> - seq_printf(m, "R6=0x%lx\n", h_aggregation);
> - seq_printf(m,
On Thu, 2008-06-12 at 09:07 -0600, Matthew Wilcox wrote:
> On Thu, Jun 05, 2008 at 06:43:53PM +1000, Benjamin Herrenschmidt wrote:
> > Note that the powerpc implementation currently clears the flag
> > on spin_lock and tests it on unlock. We are considering changing
> > that to not touch the flag o
On Thu, Jun 12, 2008 at 11:43:22AM -0500, Scott Wood wrote:
> On Wed, Jun 11, 2008 at 11:58:39AM +1000, David Gibson wrote:
> > Scott's original patch does still have some implementation details I
> > didn't like. So in the interests of saving time, I've addressed some
> > of those, added a testca
Move ide_find_port() call to pmac_ide_setup_device().
While at it:
- fix return value (s/-ENODEV/-ENOENT/)
- add DRV_NAME define and use it to set name field of pmac_port_info
- use ide_find_port_slot() instead of ide_find_port()
- remove superfluous error message (ide_find_port_slot() takes c
There should be no functional changes caused by this patch.
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ppc/pmac.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
Index: b/drivers
* Pass pmif instead of hwif to pmac_ide_do_{suspend,resume}().
* Store pmif instead of hwif in ->driver_data.
* Use dev_get_drvdata() instead of ->hwif_data to obtain pmif.
There should be no functional changes caused by this patch.
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by:
* If MB_CD device has already been detected and bay is in mb_up state just
change bay's state to mb_ide_resetting and let probing thread do the rest
instead of having open-coded waiting for IDE device to become ready in
media_bay_set_ide_infos() and doing the probe by ide_device_add().
* Mov
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ppc/pmac.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
Index: b/drivers/ide/ppc/pmac.c
===
-
Add ->cable_detect method and remove no longer needed pmif->cable_80 flag
(there is also no need to mask ->udma_mask now).
This fixes:
- forced ignoring of cable detection (needed for some CF devices & debug)
- cable detection for warm-plug
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-
Fix bug introduced by:
commit 2dde7861afa23cd59db83515cb0b810b92b220aa
Author: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Date: Fri Apr 18 00:46:23 2008 +0200
ide: rework PowerMac media-bay support (take 2)
...
[ Yeah, I suck. ]
bay->cd_index shouldn't be changed if IDE devices are not
The dmaengine provides a generic set of APIs w/a FSL dma backend. It
might be the case that your need of dma doesnt fit into the current
set of APIs.
- k
On Jun 12, 2008, at 3:04 PM, Ron Madrid wrote:
Well in that case wouldn't I need to use the fsldma driver? Or is
dmaengine a generic
From: Nathan Fontenot <[EMAIL PROTECTED]>
Update the architecture vector to indicate that Cooperative Memory
Overcommitment is supported.
This is the last patch in the series. Committing it will signal to
the platform firmware is CMO enabled.
Signed-off-by: Nathan Fontenot <[EMAIL PROTECTED]>
From: Robert Jennings <[EMAIL PROTECTED]>
Enable the driver to function in a Cooperative Memory Overcommitment (CMO)
environment.
The following changes are made to enable the driver for CMO:
* DMA mapping errors will not result in error messages if entitlement has
been exceeded and resources
From: Robert Jennings <[EMAIL PROTECTED]>
Enable ibmveth for Cooperative Memory Overcommitment (CMO). For this driver
it means calculating a desired amount of IO memory based on the current MTU
and updating this value with the bus when MTU changes occur. Because DMA
mappings can fail, we have ad
From: Santiago Leon <[EMAIL PROTECTED]>
Activates larger rx buffer pools when the MTU is changed to a larger
value. This patch de-activates the large rx buffer pools when the MTU
changes to a smaller value.
Signed-off-by: Santiago Leon <[EMAIL PROTECTED]>
---
drivers/net/ibmveth.c | 20
From: Robert Jennings <[EMAIL PROTECTED]>
Define a get_io_entitlement function so that it can function in a
Cooperative Memory Overcommitment (CMO) environment (it returns 0 to
indicate that no IO entitlement is required, as the driver does not
perform DMA operations).
Signed-off-by: Robert Jenni
From: Robert Jennings <[EMAIL PROTECTED]>
Define a get_io_entitlement function so that it can function in a
Cooperative Memory Overcommitment (CMO) environment (it returns 0 to
indicate that no IO entitlement is required, as the driver does not
perform DMA operations).
Signed-off-by: Robert Jenni
From: Nathan Fontenot <[EMAIL PROTECTED]>
Verify memory entitlement updates can be handled by vio.
Signed-off-by: Nathan Fontenot <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/lparcfg.c | 10 ++
1 file changed, 10 insertions(+)
Index: b/arch/powerpc/kernel/lparcfg.c
===
From: Robert Jennings <[EMAIL PROTECTED]>
Enable bus level entitled memory accounting for Cooperative Memory
Overcommitment (CMO) environments. The normal code path should not
be affected.
The following changes are made that the VIO bus layer for CMO:
* add IO memory accounting per device struc
From: Robert Jennings <[EMAIL PROTECTED]>
To support Cooperative Memory Overcommitment (CMO), we need to check
for failure and busy responses from some of the tce hcalls.
These changes for the pseries platform affect the powerpc architecture;
patches for the other affected platforms are included
From: Robert Jennings <[EMAIL PROTECTED]>
In support of Cooperative Memory Overcommitment (CMO) this moves
get_longbusy_msecs() out of the ehca and ehea drivers and into the
architecture's hvcall header as plpar_get_longbusy_msecs. Some firmware
calls made in pSeries platform iommu code will nee
From: Robert Jennings <[EMAIL PROTECTED]>
In support of Cooperative Memory Overcommitment (CMO) this moves
get_longbusy_msecs() out of the ehca and ehea drivers and into the
architecture's hvcall header as plpar_get_longbusy_msecs. Some firmware
calls made in pSeries platform iommu code will nee
From: Brian King <[EMAIL PROTECTED]>
With the addition of Cooperative Memory Overcommitment (CMO) support
for IBM Power Systems, two fields have been added to the VPA to report
paging statistics. Add support in lparcfg to report them to userspace.
Signed-off-by: Brian King <[EMAIL PROTECTED]>
--
From: Brian King <[EMAIL PROTECTED]>
The Cooperative Memory Overcommit (CMO) on System p does not currently
support native PCI devices or eBus devices when enabled. Prevent
PCI bus probe and eBus device probe if the feature is enabled.
Signed-off-by: Brian King <[EMAIL PROTECTED]>
---
arch/pow
From: Brian King <[EMAIL PROTECTED]>
Adds a collaborative memory manager, which acts as a simple balloon driver
for System p machines that support cooperative memory overcommitment
(CMO).
Signed-off-by: Brian King <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/pseries/Kconfig | 11 +
arch/p
From: Brian King <[EMAIL PROTECTED]>
Newer versions of firmware support page states, which are used by the
collaborative memory manager (future patch) to "loan" pages to the
hypervisor for use by other partitions.
Signed-off-by: Brian King <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/pseries
From: Robert Jennings <[EMAIL PROTECTED]>
For Cooperative Memory Overcommitment (CMO), set the FW_FEATURE_CMO
flag in powerpc_firmware_features from the rtas ibm,get-system-parameters
table prior to calling iommu_init_early_pSeries.
With this, any CMO specific functionality can be controlled by c
From: Nathan Fontenot <[EMAIL PROTECTED]>
Split the retrieval of processor entitlement data returned in the H_GET_PPP
hcall into its own helper routine.
Signed-off-by: Nathan Fontenot <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/lparcfg.c | 80 --
1 file
From: Nathan Fontenot <[EMAIL PROTECTED]>
Update /proc/ppc64/lparcfg to enable displaying of Cooperative Memory
Overcommitment statistics as reported by the H_GET_MPP hcall. This also
updates the lparcfg interface to allow setting memory entitlement and
weight.
Signed-off-by: Nathan Fontenot <[E
From: Nathan Fotenot <[EMAIL PROTECTED]>
Split the retreival and setting of processor entitlement and weight into
helper routines.
Signed-off-by: Nathan Fotenot <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/lparcfg.c | 163 ++
1 file changed, 86 insertions
From: Nathan Fontenot <[EMAIL PROTECTED]>
Remove the extraneous error reporting used when a hcall made from lparcfg fails.
Signed-off-by: Nathan Fontenot <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/lparcfg.c | 32
1 file changed, 32 deletions(-)
Index: b/arch
Cooperative Memory Overcommitment (CMO) is a pSeries platform feature
that enables the allocation of more memory to a set logical partitions
than is physically present. For example, a system with 16Gb of memory
can be configured to simultaneously run 3 logical partitions each with
8Gb of memory al
GCC 4.4.x looks to be adding support for generating out-of-line register
saves/restores based on:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html
This breaks the kernel if we enable CONFIG_CC_OPTIMIZE_FOR_SIZE. To fix
this we add the use the save/restore code from gcc and simplified it d
GCC 4.4.x looks to be adding support for generating out-of-line register
saves/restores based on:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html
This breaks the bootwrapper as we'd need to link with libgcc to get the
implementation of the register save/restores.
To workaround this issue
On Thursday 12 June 2008, Kumar Gala wrote:
>
> On Jun 10, 2008, at 2:01 PM, Bartlomiej Zolnierkiewicz wrote:
> > Thanks, applied.
> >
> Acked-by: Kumar Gala <[EMAIL PROTECTED]>
Ok, I've updated my git tree again, to remove this one and
the commproc.h changes that have gone into the m68k-nommu
tr
On Thu, 12 Jun 2008 16:24:13 +0200
Stefan Roese <[EMAIL PROTECTED]> wrote:
> On Wednesday 11 June 2008, Josh Boyer wrote:
> > The 440EPx/GRx chips don't support PCI MRM commands. Drivers determine
> > this by looking for a zero value in the PCI cache line size register.
> > However, some drivers
Well in that case wouldn't I need to use the fsldma driver? Or is dmaengine a
generic dma driver?
Ron
--- Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> On Jun 12, 2008, at 2:35 PM, Ron Madrid wrote:
>
> > I'm trying to write a driver that would make use of the DMA on the
> > MPC8313. I'm attem
On Jun 12, 2008, at 2:35 PM, Ron Madrid wrote:
I'm trying to write a driver that would make use of the DMA on the
MPC8313. I'm attempting to
register the interrupt with request_irq but it is not passing. Is
there something that I need to
do before I call request_irq, maybe in the dts or s
On Thu, Jun 12, 2008 at 02:55:45PM -0400, Adam Litke wrote:
> Update all defconfigs that specify a default configuration for hugetlbfs.
> There is now only one option: CONFIG_HUGETLB. Replace the old
> CONFIG_HUGETLB_PAGE and CONFIG_HUGETLBFS options with the new one. I found no
> cases where CON
I'm trying to write a driver that would make use of the DMA on the MPC8313.
I'm attempting to
register the interrupt with request_irq but it is not passing. Is there
something that I need to
do before I call request_irq, maybe in the dts or somewhere else?
Ron
_
Merge CONFIG_HUGETLB_PAGE and CONFIG_HUGETLBFS into one new config option:
CONFIG_HUGETLB. CONFIG_HUGETLB_PAGE is aliased to the value of
CONFIG_HUGETLBFS, so one option can be removed without any effect. This change
is pretty mechanical, but a little extra verification from arch maintainers
woul
There are currently two global Kconfig options that enable/disable the
hugetlb code: CONFIG_HUGETLB_PAGE and CONFIG_HUGETLBFS. This may have
made sense before hugetlbfs became ubiquitous but now the pair of
options are redundant. Merging these two options into one will simplify
the code slightly
On Thu, Jun 12, 2008 at 05:24:03PM +1000, Stephen Rothwell wrote:
> On Thu, 12 Jun 2008 17:05:05 +1000 Stephen Rothwell <[EMAIL PROTECTED]> wrote:
> >
> > So, I will disable FTRACE on powerpc for now by removing HAVE_FTRACE from
> > being selected in arch/powerpc/Kconfig.
>
> That got rid of the i
On Wed, Jun 11, 2008 at 11:58:39AM +1000, David Gibson wrote:
> Scott's original patch does still have some implementation details I
> didn't like. So in the interests of saving time, I've addressed some
> of those, added a testcase, and and now resubmitting my revised
> version of Scott's patch.
On Thu, Jun 12, 2008 at 04:30:53AM +0400, Vitaly Bordug wrote:
> + muram {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0 0x1>;
> +
> + [EMAIL
On Thu, Jun 12, 2008 at 04:32:47AM +0400, Vitaly Bordug wrote:
> + interrupts = <0x0f 2>; /* decrementer
> interrupt */
Interrupts should probably be decimal.
> + compatible = "fsl,cpm1";
compatible = "fsl,mpc852-cpm", "fsl,cpm1".
> +
On Thu, Jun 05, 2008 at 06:43:53PM +1000, Benjamin Herrenschmidt wrote:
> Note that the powerpc implementation currently clears the flag
> on spin_lock and tests it on unlock. We are considering changing
> that to not touch the flag on spin_lock and just clear it whenever
> we do a sync (ie, on unl
Kumar Gala wrote Wednesday, June 11, 2008 8:36 PM
> To: Sulibhavi, Madhvesh
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> linuxppc-dev@ozlabs.org; Paul Mackerras
> Subject: Re: [RFC] Kprobes for book-e
>
...
> -
> > arch/powerpc
On Thu, Jun 12, 2008 at 04:03:54PM +0200, roel kluin wrote:
> 2008/6/12 Sam Ravnborg <[EMAIL PROTECTED]>:
>
> > diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> > index 508c589..b763aba 100644
> > --- a/scripts/mod/modpost.c
> > +++ b/scripts/mod/modpost.c
> > @@ -467,6 +467,26 @@ stat
On Wednesday 11 June 2008, Josh Boyer wrote:
> The 440EPx/GRx chips don't support PCI MRM commands. Drivers determine
> this by looking for a zero value in the PCI cache line size register.
> However, some drivers write to this register upon initialization. This can
> cause MRMs to be used on th
2008/6/12 Sam Ravnborg <[EMAIL PROTECTED]>:
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index 508c589..b763aba 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -467,6 +467,26 @@ static void parse_elf_finish(struct elf_info *info)
>release_file(info
Looking even better. Just a few more comments. I'll probably be able
to pick up the next one for inclusion in 2.6.27.
On Thu, Jun 12, 2008 at 5:44 AM, David Jander <[EMAIL PROTECTED]> wrote:
> Made MPC5121_ADS board support generic:
> Renamed arch/powerpc/platforms/512x/mpc5121_ads.c and added
On Thu, Jun 12, 2008 at 5:45 AM, David Jander <[EMAIL PROTECTED]> wrote:
>
>
> /* write */
> -#define CBDW_SC(_cbd, _sc) __cbd_out16(&(_cbd)->cbd_sc, (_sc))
> -#define CBDW_DATLEN(_cbd, _datlen) __cbd_out16(&(_cbd)->cbd_datlen,
> (_datlen))
> -#define CBDW_BUFADDR(_cbd, _bufaddr)
Now that arch/ppc is gone we always define CONFIG_PPC_CPM_NEW_BINDING so
we can remove all the code associated with !CONFIG_PPC_CPM_NEW_BINDING.
Also fixed some asm/of_platform.h to linux/of_platform.h (and of_device.h)
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
Jeff, if this looks ok, it
Now that arch/ppc is gone we always define CONFIG_PPC_CPM_NEW_BINDING so
we can remove all the code associated with !CONFIG_PPC_CPM_NEW_BINDING.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
drivers/serial/cpm_uart/cpm_uart.h |3 -
drivers/serial/cpm_uart/cpm_uart_core.c | 371 +
With arch/ppc gone and all in kernel users of CONFIG_PPC_CPM_NEW_BINDING
fixed up we dont have need for the Kconfig option anymore.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/85xx/Kconfig |1 -
arch/powerpc/platforms/Kconfig |5 -
2 files changed, 0
Now that arch/ppc is gone we always define CONFIG_PPC_CPM_NEW_BINDING so
we can remove all the code associated with !CONFIG_PPC_CPM_NEW_BINDING.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
include/asm-powerpc/cpm1.h | 20
include/asm-powerpc/cpm2.h | 26
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
drivers/serial/cpm_uart/cpm_uart.h |8
drivers/serial/cpm_uart/cpm_uart_core.c |4 ++--
drivers/serial/cpm_uart/cpm_uart_cpm1.c |2 +-
drivers/serial/cpm_uart/cpm_uart_cpm1.h |2 +-
drivers/serial/cpm_uart/cpm_uart_cpm
With arch/ppc gone we can get rid of CONFIG_PPC_CPM_NEW_BINDING. These
should be pretty trivial.
These will go via my powerpc-next tree if no one has issues.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/
On Thu, Jun 12, 2008 at 6:12 AM, Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> On Jun 12, 2008, at 6:45 AM, David Jander wrote:
>
> Your commit message isn't exactly helpful as most people dont know what LTIB
> is and its not terribly relevant. It just seems like you are adding support
> for the FEC o
Hi Linus.
Following fix has been late as I have been sloppy to look into this.
Kumar has patiently reminded me and tested the follwing fix.
I could have made the patch a few lines smaller - but decided to add
a helper function and moved the obvious candidates to the helper function.
Please pull
On Thursday 12 June 2008 22:14, Paul Mackerras wrote:
> Nick Piggin writes:
> > /* turn off LED */
> > val64 = readq(&bar0->adapter_control);
> > val64 = val64 &(~ADAPTER_LED_ON);
> > writeq(val64, &bar0->adapter_control);
> >
On Jun 10, 2008, at 2:01 PM, Bartlomiej Zolnierkiewicz wrote:
Hi,
On Tuesday 10 June 2008, [EMAIL PROTECTED] wrote:
This driver was only used by arch/ppc code and is obsolete
now with the move to common arch/powerpc code.
Cc: [EMAIL PROTECTED]
Cc: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED
Signed-off-by: David Jander <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/Kconfig |2 +-
drivers/net/fec.h | 43
drivers/net/fs_enet/Kconfig| 22 +-
drivers/net/fs_enet/fs_enet-main.c | 76 ++--
d
Made MPC5121_ADS board support generic:
Renamed arch/powerpc/platforms/512x/mpc5121_ads.c and added list of supported
boards.
For both MPC5121 ADS or PRTLVT support, just select "MPC5121_GENERIC" and use
the corresponding device-tree.
Signed-off-by: David Jander <[EMAIL PROTECTED]>
---
arch/
Nick Piggin writes:
> /* turn off LED */
> val64 = readq(&bar0->adapter_control);
> val64 = val64 &(~ADAPTER_LED_ON);
> writeq(val64, &bar0->adapter_control);
> s2io_link(nic, LINK_DOWN);
> }
> clear_bi
On Jun 12, 2008, at 6:45 AM, David Jander wrote:
Your commit message isn't exactly helpful as most people dont know
what LTIB is and its not terribly relevant. It just seems like you
are adding support for the FEC on MPC5121 and this point.
Signed-off-by: David Jander <[EMAIL PROTECTED]
On Thursday 12 June 2008 02:07, Jesse Barnes wrote:
> On Tuesday, June 10, 2008 8:29 pm Nick Piggin wrote:
> > You mention strong ordering WRT spin_unlock, which suggests that
> > you would prefer to take option #2 (the current powerpc one): io/io
> > is ordered and io is contained inside spinlock
In message <[EMAIL PROTECTED]> you wrote:
>
> On Thu, 2008-06-12 at 18:06 +1000, Michael Neuling wrote:
> > In message <[EMAIL PROTECTED]> you wrote:
> > > On Wednesday 11 June 2008, Michael Ellerman wrote:
> > > > On Wed, 2008-06-11 at 18:28 +0200, Arnd Bergmann wrote:
> > > > > We used to do thi
Stefan Roscher writes:
> During corner case testing, we noticed that some versions of ehca
> do not properly transition to interrupt done in special load situations.
> This can be resolved by periodically triggering EOI through H_EOI,
> if eqes are pending.
>
> Signed-off-by: Stefan Roscher <[E
There are now two potential callers of machine_crash_shutdown,
so increase the limit accordingly.
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/crash.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/k
When kexec is disabled, the crash_shutdown_{un,}register
functions are not available in the kernel.
This provides dummy inline functions for those so that
the callers don't have to worry about it.
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
include/asm-powerpc/kexec.h | 13
We need to disable ptcal before starting a new kernel
after a crash, in order to avoid overwriting data
in the kdump kernel.
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/ras.c | 22 ++
1 files changed, 18 insertions(+), 4 deletions(-)
dif
Ok, second try, this time using Mikey's crash_shutdown_register.
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
The pseries_kexec_setup function overwrites some ppc_md
pointers, so make sure it only gets called when running on
the right architecture.
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/pseries/kexec.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
Hello,
a project I am working on consists of different hardware modules, which
can be combined in a lot of variations (not at runtime, though). As each
module shall contain an I2C-eeprom, the idea is now to put a fragment of
a FDT-blob into that EEPROM and let the bootloader combine these
fragment
On Thu, 2008-06-12 at 18:06 +1000, Michael Neuling wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > On Wednesday 11 June 2008, Michael Ellerman wrote:
> > > On Wed, 2008-06-11 at 18:28 +0200, Arnd Bergmann wrote:
> > > > We used to do this correctly in case of a user triggered
> > > > kexec,
Roland Dreier writes:
> > > So just to be clear: this is a workaround for a hardware/firmware bug?
>
> > Yes it is.
>
> OK, so paulus et al... does it seem like a good approach to call H_EOI
> from driver code (given that this driver makes tons of other hcalls)?
If this workaround is approved
On Thu, Jun 12, 2008 at 05:05:05PM +1000, Stephen Rothwell wrote:
> /usr/bin/ld: --relax and -r may not be used together
Can't you arrange so that --relax is only used on the final link? Of
course, if you have mashed all the input .text sections together with
"ld -r", resulting in one monster .te
In message <[EMAIL PROTECTED]> you wrote:
> On Wednesday 11 June 2008, Michael Ellerman wrote:
> > On Wed, 2008-06-11 at 18:28 +0200, Arnd Bergmann wrote:
> > > We used to do this correctly in case of a user triggered
> > > kexec, but not for kdump.
> >
> > Used to?
>
> Sorry, wrong wording. I me
Segher Boessenkool wrote:
+ - chip-delay : may specify a delay value in milliseconds.
>>>
>>> Delay for what? The binding should say. "chip-delay" is a bit
>>> too generic name as well, it could be more descriptive perhaps.
>>
>> The chip-delay property defines an appropriate maximum de
* Stephen Rothwell <[EMAIL PROTECTED]> wrote:
> On Thu, 12 Jun 2008 09:16:12 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > ugh, please do that hack only privately in your allyesconfig testing
> > and do not commit that change to linux-next!
>
> See my other email, I have removed the ftra
On Wednesday 11 June 2008, Michael Ellerman wrote:
> On Wed, 2008-06-11 at 18:28 +0200, Arnd Bergmann wrote:
> > We used to do this correctly in case of a user triggered
> > kexec, but not for kdump.
>
> Used to?
Sorry, wrong wording. I meant without this patch, it's correct
for kexec.
> > This
Hi Ingo,
On Thu, 12 Jun 2008 09:16:12 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> ugh, please do that hack only privately in your allyesconfig testing and
> do not commit that change to linux-next!
See my other email, I have removed the ftrace disabling patch and
reverted one of Sam Ravnbor
On Tue, 2008-06-10 at 16:44 +0200, Stefan Roscher wrote:
> During corner case testing, we noticed that some versions of ehca
> do not properly transition to interrupt done in special load situations.
> This can be resolved by periodically triggering EOI through H_EOI,
> if eqes are pending.
>
>
On Thu, 2008-06-12 at 17:05 +1000, Stephen Rothwell wrote:
> So I tried this (added --relax to LDFLAGS_vmlinux if CONFIG FTRACE was
> set) and got this;
>
> /usr/bin/ld: --relax and -r may not be used together
>
> So, I will disable FTRACE on powerpc for now by removing HAVE_FTRACE
> from
> being
On Thu, 12 Jun 2008 17:05:05 +1000 Stephen Rothwell <[EMAIL PROTECTED]> wrote:
>
> So, I will disable FTRACE on powerpc for now by removing HAVE_FTRACE from
> being selected in arch/powerpc/Kconfig.
That got rid of the initial errors, but now it fails for relocations
on .memcmp and some others.
N
* Stephen Rothwell <[EMAIL PROTECTED]> wrote:
> > It is, but you need to pass --relax to enable generation of the
> > trampolines.
>
> So I tried this (added --relax to LDFLAGS_vmlinux if CONFIG FTRACE was
> set) and got this;
>
> /usr/bin/ld: --relax and -r may not be used together
>
> So,
On Thu, 12 Jun 2008 15:03:35 +0930 Alan Modra <[EMAIL PROTECTED]> wrote:
>
> On Thu, Jun 12, 2008 at 11:38:19AM +1000, Paul Mackerras wrote:
> > Direct unconditional branches, including procedure calls, can only
> > reach +/- 32MB from the address of the branch on powerpc. So if the
> > image grow
98 matches
Mail list logo
