[PATCH] powerpc: build in e1000e for pseries ppc64_defconfig
The e1000e device is becoming more common these days, so let's just build it in for pseries ppc64_defconfig. Signed-off-by: Michael Neuling mi...@neuling.org --- arch/powerpc/configs/ppc64_defconfig |2 +- arch/powerpc/configs/pseries_defconfig |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Index: linux-2.6-ozlabs/arch/powerpc/configs/ppc64_defconfig === --- linux-2.6-ozlabs.orig/arch/powerpc/configs/ppc64_defconfig +++ linux-2.6-ozlabs/arch/powerpc/configs/ppc64_defconfig @@ -988,7 +988,7 @@ CONFIG_ACENIC=m CONFIG_ACENIC_OMIT_TIGON_I=y # CONFIG_DL2K is not set CONFIG_E1000=y -CONFIG_E1000E=m +CONFIG_E1000E=y # CONFIG_IP1000 is not set # CONFIG_IGB is not set # CONFIG_NS83820 is not set Index: linux-2.6-ozlabs/arch/powerpc/configs/pseries_defconfig === --- linux-2.6-ozlabs.orig/arch/powerpc/configs/pseries_defconfig +++ linux-2.6-ozlabs/arch/powerpc/configs/pseries_defconfig @@ -804,7 +804,7 @@ CONFIG_ACENIC=m CONFIG_ACENIC_OMIT_TIGON_I=y # CONFIG_DL2K is not set CONFIG_E1000=y -CONFIG_E1000E=m +CONFIG_E1000E=y # CONFIG_IP1000 is not set # CONFIG_IGB is not set # CONFIG_NS83820 is not set ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] fsl_msi: enable msi sharing through AMP OSes
On Mon, Apr 19, 2010 at 10:34 AM, Michael Ellerman
mich...@ellerman.id.au wrote:
On Fri, 2010-04-16 at 15:34 +0800, Li Yang wrote:
From: Zhao Chenhui b26...@freescale.com
Make a single PCIe MSI bank shareable through CAMP OSes. The number of
MSI used by each core can be configured by dts file.
Signed-off-by: Zhao Chenhui b26...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
---
arch/powerpc/sysdev/fsl_msi.c | 8 +++-
arch/powerpc/sysdev/msi_bitmap.c | 4 ++--
2 files changed, 9 insertions(+), 3 deletions(-)
..
diff --git a/arch/powerpc/sysdev/msi_bitmap.c
b/arch/powerpc/sysdev/msi_bitmap.c
index 5a32cbe..b41db96 100644
--- a/arch/powerpc/sysdev/msi_bitmap.c
+++ b/arch/powerpc/sysdev/msi_bitmap.c
@@ -95,8 +95,8 @@ int msi_bitmap_reserve_dt_hwirqs(struct msi_bitmap *bmp)
/* Format is: (u32 start u32 count)+ */
len /= 2 * sizeof(u32);
for (i = 0; i len; i++, p += 2) {
- for (j = 0; j *(p + 1); j++)
- bitmap_release_region(bmp-bitmap, *p + j, 0);
+ for (j = *p; j *(p + 1); j++)
+ bitmap_release_region(bmp-bitmap, j, 0);
}
spin_unlock(bmp-lock);
This looks like a bug fix to the msi bitmap code, is it not? Please
split it into a separate commit with an explanatory changelog.
Oops. We thought the property to be {start end} by mistake. The
change shouldn't be needed.
Thanks,
Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/4] fsl_msi: enable msi allocation in all banks
On Mon, Apr 19, 2010 at 10:46 AM, Michael Ellerman mich...@ellerman.id.au wrote: On Fri, 2010-04-16 at 15:34 +0800, Li Yang wrote: From: Zhao Chenhui b26...@freescale.com Put all fsl_msi banks in a linked list. The list of banks then can be traversed when allocating new msi interrupts. So there are multiple banks, and you just use the first one that has an empty slot in it's bitmap? Yes, currently we are. What allocation algorithm do you think is better? I don't think spreading the allocation evenly should have any performance benefit. The point of multiple banks should be better insulation through multiple OS's, IMHO. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] ehea: error handling improvement
Reset a port's resources only if they're actually in an error state
Signed-off-by: Thomas Klein tkl...@de.ibm.com
---
Patch created against 2.6.34-rc4
diff -Nurp linux-2.6.34-rc4.orig//drivers/net/ehea/ehea_main.c
linux-2.6.34-rc4//drivers/net/ehea/ehea_main.c
--- linux-2.6.34-rc4.orig//drivers/net/ehea/ehea_main.c 2010-04-19
11:54:07.0 +0200
+++ linux-2.6.34-rc4//drivers/net/ehea/ehea_main.c 2010-04-19
11:55:43.0 +0200
@@ -791,11 +791,17 @@ static struct ehea_cqe *ehea_proc_cqes(s
cqe_counter++;
rmb();
if (cqe-status EHEA_CQE_STAT_ERR_MASK) {
- ehea_error(Send Completion Error: Resetting port);
+ ehea_error(Bad send completion status=0x%04X,
+ cqe-status);
+
if (netif_msg_tx_err(pr-port))
ehea_dump(cqe, sizeof(*cqe), Send CQE);
- ehea_schedule_port_reset(pr-port);
- break;
+
+ if (cqe-status EHEA_CQE_STAT_RESET_MASK) {
+ ehea_error(Resetting port);
+ ehea_schedule_port_reset(pr-port);
+ break;
+ }
}
if (netif_msg_tx_done(pr-port))
@@ -901,6 +907,8 @@ static irqreturn_t ehea_qp_aff_irq_handl
struct ehea_eqe *eqe;
struct ehea_qp *qp;
u32 qp_token;
+ u64 resource_type, aer, aerr;
+ int reset_port = 0;
eqe = ehea_poll_eq(port-qp_eq);
@@ -910,11 +918,24 @@ static irqreturn_t ehea_qp_aff_irq_handl
eqe-entry, qp_token);
qp = port-port_res[qp_token].qp;
- ehea_error_data(port-adapter, qp-fw_handle);
+
+ resource_type = ehea_error_data(port-adapter, qp-fw_handle,
+ aer, aerr);
+
+ if (resource_type == EHEA_AER_RESTYPE_QP) {
+ if ((aer EHEA_AER_RESET_MASK) ||
+ (aerr EHEA_AERR_RESET_MASK))
+reset_port = 1;
+ } else
+ reset_port = 1; /* Reset in case of CQ or EQ error */
+
eqe = ehea_poll_eq(port-qp_eq);
}
- ehea_schedule_port_reset(port);
+ if (reset_port) {
+ ehea_error(Resetting port);
+ ehea_schedule_port_reset(port);
+ }
return IRQ_HANDLED;
}
diff -Nurp linux-2.6.34-rc4.orig//drivers/net/ehea/ehea_qmr.c
linux-2.6.34-rc4//drivers/net/ehea/ehea_qmr.c
--- linux-2.6.34-rc4.orig//drivers/net/ehea/ehea_qmr.c 2010-04-19
11:54:07.0 +0200
+++ linux-2.6.34-rc4//drivers/net/ehea/ehea_qmr.c 2010-04-19
11:56:36.0 +0200
@@ -229,14 +229,14 @@ u64 ehea_destroy_cq_res(struct ehea_cq *
int ehea_destroy_cq(struct ehea_cq *cq)
{
- u64 hret;
+ u64 hret, aer, aerr;
if (!cq)
return 0;
hcp_epas_dtor(cq-epas);
hret = ehea_destroy_cq_res(cq, NORMAL_FREE);
if (hret == H_R_STATE) {
- ehea_error_data(cq-adapter, cq-fw_handle);
+ ehea_error_data(cq-adapter, cq-fw_handle, aer, aerr);
hret = ehea_destroy_cq_res(cq, FORCE_FREE);
}
@@ -357,7 +357,7 @@ u64 ehea_destroy_eq_res(struct ehea_eq *
int ehea_destroy_eq(struct ehea_eq *eq)
{
- u64 hret;
+ u64 hret, aer, aerr;
if (!eq)
return 0;
@@ -365,7 +365,7 @@ int ehea_destroy_eq(struct ehea_eq *eq)
hret = ehea_destroy_eq_res(eq, NORMAL_FREE);
if (hret == H_R_STATE) {
- ehea_error_data(eq-adapter, eq-fw_handle);
+ ehea_error_data(eq-adapter, eq-fw_handle, aer, aerr);
hret = ehea_destroy_eq_res(eq, FORCE_FREE);
}
@@ -540,7 +540,7 @@ u64 ehea_destroy_qp_res(struct ehea_qp *
int ehea_destroy_qp(struct ehea_qp *qp)
{
- u64 hret;
+ u64 hret, aer, aerr;
if (!qp)
return 0;
@@ -548,7 +548,7 @@ int ehea_destroy_qp(struct ehea_qp *qp)
hret = ehea_destroy_qp_res(qp, NORMAL_FREE);
if (hret == H_R_STATE) {
- ehea_error_data(qp-adapter, qp-fw_handle);
+ ehea_error_data(qp-adapter, qp-fw_handle, aer, aerr);
hret = ehea_destroy_qp_res(qp, FORCE_FREE);
}
@@ -986,42 +986,45 @@ void print_error_data(u64 *data)
if (length EHEA_PAGESIZE)
length = EHEA_PAGESIZE;
- if (type == 0x8) /* Queue Pair */
+ if (type == EHEA_AER_RESTYPE_QP)
ehea_error(QP (resource=%llX) state: AER=0x%llX, AERR=0x%llX,
port=%llX, resource, data[6], data[12], data[22]);
-
- if (type == 0x4) /* Completion Queue */
+ else if (type == EHEA_AER_RESTYPE_CQ)
ehea_error(CQ (resource=%llX) state:
[PATCH 2/2] ehea: fix possible DLPAR/mem deadlock
Force serialization of userspace-triggered DLPAR/mem operations
Signed-off-by: Thomas Klein tkl...@de.ibm.com
---
Patch created against 2.6.34-rc4
diff -Nurp linux-2.6.34-rc4.orig//drivers/net/ehea/ehea.h
linux-2.6.34-rc4//drivers/net/ehea/ehea.h
--- linux-2.6.34-rc4.orig//drivers/net/ehea/ehea.h 2010-04-19
11:54:07.0 +0200
+++ linux-2.6.34-rc4//drivers/net/ehea/ehea.h 2010-04-19 12:00:14.0
+0200
@@ -40,7 +40,7 @@
#include asm/io.h
#define DRV_NAME ehea
-#define DRV_VERSIONEHEA_0102
+#define DRV_VERSIONEHEA_0103
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff -Nurp linux-2.6.34-rc4.orig//drivers/net/ehea/ehea_main.c
linux-2.6.34-rc4//drivers/net/ehea/ehea_main.c
--- linux-2.6.34-rc4.orig//drivers/net/ehea/ehea_main.c 2010-04-19
11:59:11.0 +0200
+++ linux-2.6.34-rc4//drivers/net/ehea/ehea_main.c 2010-04-19
11:59:50.0 +0200
@@ -2889,7 +2889,6 @@ static void ehea_rereg_mrs(struct work_s
int ret, i;
struct ehea_adapter *adapter;
- mutex_lock(dlpar_mem_lock);
ehea_info(LPAR memory changed - re-initializing driver);
list_for_each_entry(adapter, adapter_list, list)
@@ -2959,7 +2958,6 @@ static void ehea_rereg_mrs(struct work_s
}
ehea_info(re-initializing driver complete);
out:
- mutex_unlock(dlpar_mem_lock);
return;
}
@@ -3542,7 +3540,14 @@ void ehea_crash_handler(void)
static int ehea_mem_notifier(struct notifier_block *nb,
unsigned long action, void *data)
{
+ int ret = NOTIFY_BAD;
struct memory_notify *arg = data;
+
+ if (!mutex_trylock(dlpar_mem_lock)) {
+ ehea_info(ehea_mem_notifier must not be called parallelized);
+ goto out;
+ }
+
switch (action) {
case MEM_CANCEL_OFFLINE:
ehea_info(memory offlining canceled);
@@ -3551,14 +3556,14 @@ static int ehea_mem_notifier(struct noti
ehea_info(memory is going online);
set_bit(__EHEA_STOP_XFER, ehea_driver_flags);
if (ehea_add_sect_bmap(arg-start_pfn, arg-nr_pages))
- return NOTIFY_BAD;
+ goto out_unlock;
ehea_rereg_mrs(NULL);
break;
case MEM_GOING_OFFLINE:
ehea_info(memory is going offline);
set_bit(__EHEA_STOP_XFER, ehea_driver_flags);
if (ehea_rem_sect_bmap(arg-start_pfn, arg-nr_pages))
- return NOTIFY_BAD;
+ goto out_unlock;
ehea_rereg_mrs(NULL);
break;
default:
@@ -3566,8 +3571,12 @@ static int ehea_mem_notifier(struct noti
}
ehea_update_firmware_handles();
+ ret = NOTIFY_OK;
- return NOTIFY_OK;
+out_unlock:
+ mutex_unlock(dlpar_mem_lock);
+out:
+ return ret;
}
static struct notifier_block ehea_mem_nb = {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] fsl_msi: fix the conflict of virt_msir's chip_data
On Apr 18, 2010, at 11:50 PM, Li Yang wrote: On 4/19/2010 10:40 AM, Michael Ellerman wrote: On Fri, 2010-04-16 at 15:34 +0800, Li Yang wrote: From: Zhao Chenhuib26...@freescale.com In fsl_of_msi_probe(), the virt_msir's chip_data have been stored the pointer to struct mpic. We add a struct fsl_msi_cascade_data to store the pointer to struct fsl_msi and msir_index. Otherwise, the pointer to struct mpic will be over-written, and will cause problem when calling eoi() of the irq. I don't quite understand. Do you mean someone was overwriting handler_data somewhere? The patch at http://patchwork.ozlabs.org/patch/48794/ was overwriting the chip_data. We move the newly added pointer to fsl_msi structure to the handler data. Let's fix that patch. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Pending interrupts not always replayed
On Sun, 18 Apr 2010 21:14:12 +0200 (CEST) Thomas Gleixner t...@linutronix.de wrote: On Sun, 18 Apr 2010, Guillaume Knispel wrote: Now everything seems to work fine: my device was not previously not interrupting anymore after typically 1 or 2 minutes (because the interrupt signal stays at level low until the device is served, so So you are having a level interrupt device and the irq line is handled by an edge type handler ? Why not configuring the irq line for level and in the first place ? Not really the problem here, it indeed helped me do discover the real bug (because I would not have seen that an interrupt went missing if the device have generated another one all by itself soon after that). I would of course prefer to have this line in level trigger, but the pic just can't do it for this signal, so I play with masking and unmasking interrupts on the device side to regenerate edges when needed. When interrupts are enabled, I do that in the isr, so if it is not called after a falling edge it won't be anymore in the future. What is a real bug IMHO is that when in falling edge trigger mode, the sequence: - disable_irq(), - 1 falling edge, - enable_irq() doesn't lead to the isr being called just after enable_irq(). This is because: * __disable_irq basically do (when really disabling) desc-status |= IRQ_DISABLED; desc-chip-disable(irq); = noop or racy see under * arch/powerpc/sysdev/cpm2_pic.c does not define a disable() in struct irq_chip cpm2_pic. So default_disable is used, and it's a noop. For pics where this is not a noop, there can be a race if the interrupt triggers before the disable(): the flow handler will still be executed just after desc-lock is unlocked in disable_irq_nosync(). So it does not really matters whether disable() is implemented or is a noop. * When the flow handler is executed after disable_irq_nosync(), handle_edge_irq() does: desc-status = ~(IRQ_REPLAY | IRQ_WAITING); desc-status |= (IRQ_PENDING | IRQ_MASKED); mask_ack_irq(desc, irq); The responsibility of triggering the interrupt has now been transferred from the pic to the kernel (the interrupt has been acked at pic level), so I would say that if the kernel does not run replay it later, it will be a bug. * When __enable_irq() is called, it does: unsigned int status = desc-status ~IRQ_DISABLED; desc-status = status | IRQ_NOPROBE; check_irq_resend(desc, irq); * if it's an edge triggered IRQ (and in my case it is) check_irq_resend() sometimes, if the planets are aligned, resend the IRQ. Planet alignement is defined by retrigger being provided for the irq_chip and retrigger succeed, or CONFIG_HARDIRQS_SW_RESEND is defined (in which case and if retrigger is absent or has failed, the hardirq is indeed executed in a tasklet -- which might maybe cause obscure problems?). My guess is that CONFIG_HARDIRQS_SW_RESEND was meant to be defined on any platform where a pic can exist and can do edge trigger but does not implement retrigger or implements a retrigger that can fail (because otherwise interrupts can be missed). This seems to be a quite unknown fact that might have been missed by multiple irq_chips (and could be missed by more in the future), and I would propose to just unconditionally build the resend_irqs() tasklet and its scheduling code, and completely remove CONFIG_HARDIRQS_SW_RESEND, at least if it is sure that executing a flow handler in a tasklet can never cause obscure problems. Cheers! -- Guillaume Knispel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] sched: fix capacity calculations for SMT4
On Mon, 2010-04-19 at 07:34 +1000, Michael Neuling wrote: Are there any numbers available on how much they gain? It might be worth to stick in real numbers instead of this alleged 15%. I get some gain numbers but obviously the workloads makes a huge difference. From a scheduler perspective, I assume an average/representative gain is best rather than an optimistic or pessimistic one? Yeah, average would be best. We'll have different gains for SMT2 and SMT4, so we could change the gain dynamically based on which SMT mode we are in. Does that seem like something we should add as an arch hook? That's the sort of thing you can use arch_scale_smt_power() for. But be weary to not fall into the same trap I did with x86, where I confused actual gain with capacity (When idle the actual gain is 0, but the capacity is not). ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Pending interrupts not always replayed
Hi, From reading the code (kernel/irq stuffs), it seems that at least some handle_edge_irq based interrupts are not replayed when enabling if desc-chip-retrigger == NULL and on a platform where CONFIG_HARDIRQS_SW_RESEND is not set (which for now is only defined for (some?) arm and avr32). Depending on the pic this problem might be masked if multiple interrupts are received between disable_irq and enable_irq (maybe other conditions exist with controllers i don't know). I happen to program a PPC SoC (MPC8555E to be precise), using some edge interrupts on the PortC of the CPM2 pic (arch/powerpc/sysdev/cpm2_pic.c) in a driver that does some enable_irq/disable_irq while various patterns of interrupts are received and i think i've hit the problem. Is the behavior intended (not always replaying edge triggered interrupts) or is it just a bug to fix? Anybody knows if it's safe to activate CONFIG_HARDIRQS_SW_RESEND for a powerpc or are there some known dangerous interactions? (I'll give it a try on my side in the meantime anyway) Cheers! -- Guillaume Knispel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] sched: fix capacity calculations for SMT4
In message 1271688543.1488.253.ca...@laptop you wrote: On Mon, 2010-04-19 at 07:34 +1000, Michael Neuling wrote: Are there any numbers available on how much they gain? It might be worth to stick in real numbers instead of this alleged 15%. I get some gain numbers but obviously the workloads makes a huge difference. From a scheduler perspective, I assume an average/representative gain is best rather than an optimistic or pessimistic one? Yeah, average would be best. Ok. We'll have different gains for SMT2 and SMT4, so we could change the gain dynamically based on which SMT mode we are in. Does that seem like something we should add as an arch hook? That's the sort of thing you can use arch_scale_smt_power() for. But be weary to not fall into the same trap I did with x86, where I confused actual gain with capacity (When idle the actual gain is 0, but the capacity is not). Oops, yes of course :-) from before Hrmm, my brain seems muddled but I might have another solution, let me ponder this for a bit.. Let me know if/when you come up this solution or if I can help. Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] fsl_msi: fix the conflict of virt_msir's chip_data
On Mon, Apr 19, 2010 at 8:19 PM, Kumar Gala ga...@kernel.crashing.org wrote: On Apr 18, 2010, at 11:50 PM, Li Yang wrote: On 4/19/2010 10:40 AM, Michael Ellerman wrote: On Fri, 2010-04-16 at 15:34 +0800, Li Yang wrote: From: Zhao Chenhuib26...@freescale.com In fsl_of_msi_probe(), the virt_msir's chip_data have been stored the pointer to struct mpic. We add a struct fsl_msi_cascade_data to store the pointer to struct fsl_msi and msir_index. Otherwise, the pointer to struct mpic will be over-written, and will cause problem when calling eoi() of the irq. I don't quite understand. Do you mean someone was overwriting handler_data somewhere? The patch at http://patchwork.ozlabs.org/patch/48794/ was overwriting the chip_data. We move the newly added pointer to fsl_msi structure to the handler data. Let's fix that patch. All right. You can merge the two patches if you like it that way. Thanks. Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: 83xx: add RTC drivers in 83xx defconfig
On Apr 5, 2010, at 11:13 AM, Kim Phillips wrote: 83xx boards typically have the DS1307 or DS1374: git grep RTC_DRV arch/powerpc/configs/*83* | grep =y arch/powerpc/configs/83xx/asp8347_defconfig:CONFIG_RTC_DRV_DS1374=y arch/powerpc/configs/83xx/mpc8313_rdb_defconfig:CONFIG_RTC_DRV_DS1307=y arch/powerpc/configs/83xx/mpc8315_rdb_defconfig:CONFIG_RTC_DRV_DS1307=y arch/powerpc/configs/83xx/mpc832x_mds_defconfig:CONFIG_RTC_DRV_DS1374=y arch/powerpc/configs/83xx/mpc834x_itx_defconfig:CONFIG_RTC_DRV_DS1307=y arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig:CONFIG_RTC_DRV_DS1307=y arch/powerpc/configs/83xx/mpc834x_mds_defconfig:CONFIG_RTC_DRV_DS1374=y arch/powerpc/configs/83xx/mpc836x_mds_defconfig:CONFIG_RTC_DRV_DS1374=y Signed-off-by: Kim Phillips kim.phill...@freescale.com --- arch/powerpc/configs/mpc83xx_defconfig | 62 ++-- 1 files changed, 59 insertions(+), 3 deletions(-) applied to merge. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: 83xx: enable EPOLL syscall in defconfig
On Apr 5, 2010, at 11:14 AM, Kim Phillips wrote: 83xx users looking to run apache will experience this error: /var/log/apache2/error.log: [emerg] (38)Function not implemented: Couldn't create pollset in child; check system or user limits enabling CONFIG_EPOLL in kernel config fixes this so apache can run. Signed-off-by: Kim Phillips kim.phill...@freescale.com --- arch/powerpc/configs/83xx/asp8347_defconfig |2 +- arch/powerpc/configs/83xx/mpc8313_rdb_defconfig |2 +- arch/powerpc/configs/83xx/mpc8315_rdb_defconfig |2 +- arch/powerpc/configs/83xx/mpc832x_mds_defconfig |2 +- arch/powerpc/configs/83xx/mpc832x_rdb_defconfig |2 +- arch/powerpc/configs/83xx/mpc834x_itx_defconfig |2 +- arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig |2 +- arch/powerpc/configs/83xx/mpc834x_mds_defconfig |2 +- arch/powerpc/configs/83xx/mpc836x_mds_defconfig |2 +- arch/powerpc/configs/83xx/mpc836x_rdk_defconfig |2 +- arch/powerpc/configs/83xx/mpc837x_mds_defconfig |2 +- arch/powerpc/configs/83xx/mpc837x_rdb_defconfig |2 +- arch/powerpc/configs/83xx/sbc834x_defconfig |2 +- arch/powerpc/configs/mpc83xx_defconfig|2 +- 14 files changed, 14 insertions(+), 14 deletions(-) applied to merge. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] PowerPC/FSL/CPM: Configure clock correctly for SCC
On Apr 3, 2010, at 9:11 AM, Wolfgang Ocker wrote: Some board setup functions call cpm1_clk_setup() or cmp2_clk_setup() to configure the clock source. If CPM_CLK_RTX has been used for the parameter mode, the clock has been configured only for TX but not for RX. With this patch CPM_CLK_RTX configures the clock for both directions correctly. Signed-off-by: Wolfgang Ocker w...@reccoware.de --- v2: Scott Wood encouraged me to include a similar fix for CPM2. arch/powerpc/sysdev/cpm1.c | 14 +++--- arch/powerpc/sysdev/cpm2.c | 11 --- 2 files changed, 19 insertions(+), 6 deletions(-) applied to merge. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx/86xx: Fix build w/ CONFIG_PCI=n
On Apr 16, 2010, at 2:07 PM, Anton Vorontsov wrote:
Currently some MPC85xx and MPC86xx boards fail to build without
CONFIG_PCI:
arch/powerpc/platforms/fsl_uli1575.c: In function 'quirk_final_uli5249':
arch/powerpc/platforms/fsl_uli1575.c:234: error: implicit declaration of
function 'pci_bus_for_each_resource'
arch/powerpc/platforms/fsl_uli1575.c:234: error: expected ';' before '{' token
cc1: warnings being treated as errors
arch/powerpc/platforms/fsl_uli1575.c:223: warning: unused variable 'dummy'
make[1]: *** [arch/powerpc/platforms/fsl_uli1575.o] Error 1
This patch fixes the issue by appending 'if PCI' condition when
selecting FSL_ULI1575 Kconfig symbol.
Signed-off-by: Anton Vorontsov avoront...@mvista.com
---
arch/powerpc/platforms/85xx/Kconfig |4 ++--
arch/powerpc/platforms/86xx/Kconfig |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
applied to merge.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2] fsl_booke: Correct test for MMU_FTR_BIG_PHYS
On Apr 12, 2010, at 11:21 AM, Becky Bruce wrote: The code was looking for this in cpu_features, not mmu_features. Fix this. Signed-off-by: Becky Bruce bec...@kernel.crashing.org --- Switched to mmu_has_feature. arch/powerpc/mm/fsl_booke_mmu.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) applied to merge. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: mpc8xxx defconfigs: turn off SYSFS_DEPRECATED
On Apr 15, 2010, at 6:59 PM, Kim Phillips wrote: a recent fc11 udev update on an 83xx board made root console login disappear: Updating : udev-141-8.fc11.ppc32/83 udev: starting version 141 udev: deprecated sysfs layout; update the kernel or disable CONFIG_SYSFS_DEPRECATED; some udev features will not work correctly and sure enough, turning off SYSFS_DEPRECATED brings the login prompt back. Signed-off-by: Kim Phillips kim.phill...@freescale.com --- arch/powerpc/configs/83xx/asp8347_defconfig |3 +-- arch/powerpc/configs/83xx/mpc8313_rdb_defconfig |3 +-- arch/powerpc/configs/83xx/mpc8315_rdb_defconfig |3 +-- arch/powerpc/configs/83xx/mpc832x_mds_defconfig |3 +-- arch/powerpc/configs/83xx/mpc832x_rdb_defconfig |3 +-- arch/powerpc/configs/83xx/mpc834x_itx_defconfig |3 +-- arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig |3 +-- arch/powerpc/configs/83xx/mpc834x_mds_defconfig |3 +-- arch/powerpc/configs/83xx/mpc836x_mds_defconfig |3 +-- arch/powerpc/configs/83xx/mpc836x_rdk_defconfig |3 +-- arch/powerpc/configs/83xx/mpc837x_mds_defconfig |3 +-- arch/powerpc/configs/83xx/mpc837x_rdb_defconfig |3 +-- arch/powerpc/configs/83xx/sbc834x_defconfig |3 +-- arch/powerpc/configs/85xx/ksi8560_defconfig |3 +-- arch/powerpc/configs/85xx/mpc8540_ads_defconfig |3 +-- arch/powerpc/configs/85xx/mpc8560_ads_defconfig |3 +-- arch/powerpc/configs/85xx/mpc85xx_cds_defconfig |3 +-- arch/powerpc/configs/85xx/sbc8548_defconfig |3 +-- arch/powerpc/configs/85xx/sbc8560_defconfig |3 +-- arch/powerpc/configs/85xx/socrates_defconfig |3 +-- arch/powerpc/configs/85xx/stx_gp3_defconfig |3 +-- arch/powerpc/configs/85xx/tqm8540_defconfig |3 +-- arch/powerpc/configs/85xx/tqm8541_defconfig |3 +-- arch/powerpc/configs/85xx/tqm8548_defconfig |3 +-- arch/powerpc/configs/85xx/tqm8555_defconfig |3 +-- arch/powerpc/configs/85xx/tqm8560_defconfig |3 +-- arch/powerpc/configs/85xx/xes_mpc85xx_defconfig |3 +-- arch/powerpc/configs/mpc8272_ads_defconfig|3 +-- arch/powerpc/configs/mpc83xx_defconfig|3 +-- arch/powerpc/configs/mpc85xx_defconfig|3 +-- arch/powerpc/configs/mpc85xx_smp_defconfig|3 +-- arch/powerpc/configs/mpc866_ads_defconfig |3 +-- arch/powerpc/configs/mpc86xx_defconfig|3 +-- arch/powerpc/configs/mpc885_ads_defconfig |3 +-- 34 files changed, 34 insertions(+), 68 deletions(-) applied to merge. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: 83xx: configure SIL SATA driver in 83xx-wide defconfig
On Apr 15, 2010, at 6:59 PM, Kim Phillips wrote: to enable the storage controller on earlier rev. mpc834x itx boards. Signed-off-by: Kim Phillips kim.phill...@freescale.com --- arch/powerpc/configs/mpc83xx_defconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) applied to merge. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
(Mostly defconfig updates, but a few minor bug fixes). The following changes since commit 01bf0b64579ead8a82e7cfc32ae44bc667e7ad0f: Linus Torvalds (1): Linux 2.6.34-rc5 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git merge Anton Vorontsov (1): powerpc/85xx/86xx: Fix build w/ CONFIG_PCI=n Becky Bruce (1): powerpc/fsl_booke: Correct test for MMU_FTR_BIG_PHYS Kim Phillips (4): powerpc/83xx: add RTC drivers in 83xx defconfig powerpc/83xx: enable EPOLL syscall in defconfig powerpc/83xx: configure SIL SATA driver in 83xx-wide defconfig powerpc/mpc8xxx defconfigs - turn off SYSFS_DEPRECATED Kumar Gala (1): powerpc: 2.6.34 update of defconfigs for embedded 6xx/7xxx, 8xx, 8xxx Wolfgang Ocker (1): powerpc/fsl-cpm: Configure clock correctly for SCC arch/powerpc/configs/83xx/asp8347_defconfig | 44 arch/powerpc/configs/83xx/kmeter1_defconfig | 28 +++-- arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 49 + arch/powerpc/configs/83xx/mpc8315_rdb_defconfig | 50 + arch/powerpc/configs/83xx/mpc832x_mds_defconfig | 45 arch/powerpc/configs/83xx/mpc832x_rdb_defconfig | 49 arch/powerpc/configs/83xx/mpc834x_itx_defconfig | 44 arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig | 43 arch/powerpc/configs/83xx/mpc834x_mds_defconfig | 46 + arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 45 arch/powerpc/configs/83xx/mpc836x_rdk_defconfig | 44 --- arch/powerpc/configs/83xx/mpc837x_mds_defconfig | 46 + arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 51 + arch/powerpc/configs/83xx/sbc834x_defconfig | 44 arch/powerpc/configs/85xx/ksi8560_defconfig | 23 +++- arch/powerpc/configs/85xx/mpc8540_ads_defconfig | 25 +++-- arch/powerpc/configs/85xx/mpc8560_ads_defconfig | 34 -- arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 31 -- arch/powerpc/configs/85xx/sbc8548_defconfig | 31 -- arch/powerpc/configs/85xx/sbc8560_defconfig | 25 +++-- arch/powerpc/configs/85xx/socrates_defconfig | 51 + arch/powerpc/configs/85xx/stx_gp3_defconfig | 51 + arch/powerpc/configs/85xx/tqm8540_defconfig | 48 +--- arch/powerpc/configs/85xx/tqm8541_defconfig | 54 ++--- arch/powerpc/configs/85xx/tqm8548_defconfig | 47 +--- arch/powerpc/configs/85xx/tqm8555_defconfig | 54 ++--- arch/powerpc/configs/85xx/tqm8560_defconfig | 54 ++--- arch/powerpc/configs/85xx/xes_mpc85xx_defconfig | 59 +++--- arch/powerpc/configs/86xx/gef_ppc9a_defconfig | 102 +++--- arch/powerpc/configs/86xx/gef_sbc310_defconfig| 53 ++ arch/powerpc/configs/86xx/gef_sbc610_defconfig| 96 +++-- arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig | 34 +++--- arch/powerpc/configs/86xx/mpc8641_hpcn_defconfig | 48 +--- arch/powerpc/configs/86xx/sbc8641d_defconfig | 40 --- arch/powerpc/configs/adder875_defconfig | 18 ++-- arch/powerpc/configs/c2k_defconfig| 55 - arch/powerpc/configs/ep8248e_defconfig| 20 +++- arch/powerpc/configs/ep88xc_defconfig | 17 ++-- arch/powerpc/configs/linkstation_defconfig| 48 +--- arch/powerpc/configs/mgcoge_defconfig | 31 -- arch/powerpc/configs/mgsuvd_defconfig | 19 ++-- arch/powerpc/configs/mpc7448_hpc2_defconfig | 26 +++-- arch/powerpc/configs/mpc8272_ads_defconfig| 23 +++- arch/powerpc/configs/mpc83xx_defconfig| 124 - arch/powerpc/configs/mpc85xx_defconfig| 62 +++ arch/powerpc/configs/mpc85xx_smp_defconfig| 64 +++ arch/powerpc/configs/mpc866_ads_defconfig | 20 ++-- arch/powerpc/configs/mpc86xx_defconfig| 57 ++ arch/powerpc/configs/mpc885_ads_defconfig | 20 ++-- arch/powerpc/configs/pq2fads_defconfig| 22 +++- arch/powerpc/configs/prpmc2800_defconfig | 52 ++--- arch/powerpc/configs/storcenter_defconfig | 33 +++--- arch/powerpc/mm/fsl_booke_mmu.c |4 +- arch/powerpc/platforms/85xx/Kconfig |4 +- arch/powerpc/platforms/86xx/Kconfig |4 +- arch/powerpc/sysdev/cpm1.c| 14 ++- arch/powerpc/sysdev/cpm2.c| 11 ++- 57 files changed, 1432 insertions(+), 904 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
