* [PATCH V3 3/3] powernv: Have uniform logging of errors in opal-elog.c
From: Deepthi Dharwar @ 2014-01-18 2:43 UTC (permalink / raw)
To: benh, linuxppc-dev, mpe
In-Reply-To: <20140118024150.13537.11381.stgit@deepthi>
Currently some errors/info to be reported use
printk and the rest pr_fmt(). This patch
makes the complete error/event logging uniform.
Signed-off-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/opal-elog.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-elog.c b/arch/powerpc/platforms/powernv/opal-elog.c
index 0f67faa..78d3828 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -63,7 +63,7 @@ void opal_elog_ack(uint64_t ack_id)
struct opal_err_log *record, *next;
bool found = false;
- printk(KERN_INFO "OPAL Log ACK=%llx", ack_id);
+ pr_info("OPAL Log ACK=%llx", ack_id);
/* once user acknowledge a log delete record from list */
spin_lock_irqsave(&opal_elog_lock, flags);
@@ -189,7 +189,7 @@ static void opal_elog_read(void)
/* read log size and log ID from OPAL */
rc = opal_get_elog_size(&log_id, &elog_size, &elog_type);
if (rc != OPAL_SUCCESS) {
- pr_err("ELOG: Opal log read failed\n");
+ pr_err("Opal log read failed\n");
return;
}
if (elog_size >= OPAL_MAX_ERRLOG_SIZE)
@@ -203,7 +203,7 @@ static void opal_elog_read(void)
rc = opal_read_elog(__pa(err_log_data), elog_size, log_id);
if (rc != OPAL_SUCCESS) {
mutex_unlock(&err_log_data_mutex);
- pr_err("ELOG: log read failed for log-id=%llx\n", log_id);
+ pr_err("Reading of log failed for log-id=%llx\n", log_id);
/* put back the free node. */
spin_lock_irqsave(&opal_elog_lock, flags);
list_add(&record->link, &elog_ack_list);
@@ -265,7 +265,7 @@ static int init_err_log_buffer(void)
buf_ptr = vmalloc(sizeof(struct opal_err_log) * MAX_NUM_RECORD);
if (!buf_ptr) {
- printk(KERN_ERR "ELOG: failed to allocate memory.\n");
+ pr_err("Failed to allocate memory for error logging buffers.\n");
return -ENOMEM;
}
memset(buf_ptr, 0, sizeof(struct opal_err_log) * MAX_NUM_RECORD);
@@ -359,15 +359,13 @@ int __init opal_elog_init(void)
rc = sysfs_create_bin_file(opal_kobj, &opal_elog_attr);
if (rc) {
- printk(KERN_ERR "ELOG: unable to create sysfs file"
- "opal_elog (%d)\n", rc);
+ pr_err("Unable to create sysfs file opal_elog (%d)\n", rc);
return rc;
}
rc = sysfs_create_file(opal_kobj, &opal_elog_ack_attr.attr);
if (rc) {
- printk(KERN_ERR "ELOG: unable to create sysfs file"
- " opal_elog_ack (%d)\n", rc);
+ pr_err("Unable to create sysfs file opal_elog_ack (%d)\n", rc);
return rc;
}
^ permalink raw reply related
* [PATCH V3 2/3] powernv: Correct spell error in opal-elog.c
From: Deepthi Dharwar @ 2014-01-18 2:43 UTC (permalink / raw)
To: benh, linuxppc-dev, mpe
In-Reply-To: <20140118024150.13537.11381.stgit@deepthi>
Correct spell error in opal-elog.c
Signed-off-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/opal-elog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/opal-elog.c b/arch/powerpc/platforms/powernv/opal-elog.c
index 5aa2d86..0f67faa 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -26,7 +26,7 @@
/* Maximum size of a single log on FSP is 16KB */
#define OPAL_MAX_ERRLOG_SIZE 16384
-/* maximu number of records powernv can hold */
+/* Maximum number of records powernv platform can hold */
#define MAX_NUM_RECORD 128
struct opal_err_log {
^ permalink raw reply related
* [PATCH V3 1/3] powernv: Push critical error logs to FSP
From: Deepthi Dharwar @ 2014-01-18 2:43 UTC (permalink / raw)
To: benh, linuxppc-dev, mpe
In-Reply-To: <20140118024150.13537.11381.stgit@deepthi>
This patch provides error logging interfaces to report critical
powernv error logs to FSP.
All the required information to dump the error is collected
at POWERNV level through error log interfaces
and then pushed on to FSP.
Signed-off-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/opal.h | 123 ++++++++++++++++++++++++
arch/powerpc/platforms/powernv/opal-elog.c | 76 +++++++++++++++
arch/powerpc/platforms/powernv/opal-wrappers.S | 1
3 files changed, 200 insertions(+)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 013a696..51b8eb6 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -173,6 +173,7 @@ extern int opal_enter_rtas(struct rtas_args *args,
#define OPAL_SENSOR_READ 88
#define OPAL_GET_PARAM 89
#define OPAL_SET_PARAM 90
+#define OPAL_ELOG_SEND 92
#ifndef __ASSEMBLY__
@@ -267,6 +268,119 @@ enum OpalMessageType {
OPAL_MSG_TYPE_MAX,
};
+
+/* Classification of error/event type to be reported on OPAL */
+/* Platform Events/Errors: Report Machine Check Interrupt */
+#define OPAL_PLATFORM_ERR_EVT 0x01
+/* INPUT_OUTPUT: Report all I/O related events/errors */
+#define OPAL_INPUT_OUTPUT_ERR_EVT 0x02
+/* RESOURCE_DEALLOC: Hotplug events and errors */
+#define OPAL_RESOURCE_DEALLOC_ERR_EVT 0x03
+/* MISC: Miscellanous error */
+#define OPAL_MISC_ERR_EVT 0x04
+
+/* OPAL Subsystem IDs listed for reporting events/errors */
+#define OPAL_PROCESSOR_SUBSYSTEM 0x10
+#define OPAL_MEMORY_SUBSYSTEM 0x20
+#define OPAL_IO_SUBSYSTEM 0x30
+#define OPAL_IO_DEVICES 0x40
+#define OPAL_CEC_HARDWARE 0x50
+#define OPAL_POWER_COOLING 0x60
+#define OPAL_MISC_SUBSYSTEM 0x70
+#define OPAL_SURVEILLANCE_ERR 0x7A
+#define OPAL_PLATFORM_FIRMWARE 0x80
+#define OPAL_SOFTWARE 0x90
+#define OPAL_EXTERNAL_ENV 0xA0
+
+
+/*
+ * During reporting an event/error the following represents
+ * how serious the logged event/error is. (Severity)
+ */
+#define OPAL_INFO 0x00
+#define OPAL_RECOVERED_ERR_GENERAL 0x10
+
+/* 0x2X series is to denote set of Predictive Error */
+/* 0x20 Generic predictive error */
+#define OPAL_PREDICTIVE_ERR_GENERAL 0x20
+/* 0x21 Predictive error, degraded performance */
+#define OPAL_PREDICTIVE_ERR_DEGRADED_PERF 0x21
+/* 0x22 Predictive error, fault may be corrected after reboot */
+#define OPAL_PREDICTIVE_ERR_FAULT_RECTIFY_REBOOT 0x22
+/*
+ * 0x23 Predictive error, fault may be corrected after reboot,
+ * degraded performance
+ */
+#define OPAL_PREDICTIVE_ERR_FAULT_RECTIFY_BOOT_DEGRADE_PERF 0x23
+/* 0x24 Predictive error, loss of redundancy */
+#define OPAL_PREDICTIVE_ERR_LOSS_OF_REDUNDANCY 0x24
+
+/* 0x4X series for Unrecoverable Error */
+/* 0x40 Generic Unrecoverable error */
+#define OPAL_UNRECOVERABLE_ERR_GENERAL 0x40
+/* 0x41 Unrecoverable error bypassed with degraded performance */
+#define OPAL_UNRECOVERABLE_ERR_DEGRADE_PERF 0x41
+/* 0x44 Unrecoverable error bypassed with loss of redundancy */
+#define OPAL_UNRECOVERABLE_ERR_LOSS_REDUNDANCY 0x44
+/* 0x45 Unrecoverable error bypassed with loss of redundancy and performance */
+#define OPAL_UNRECOVERABLE_ERR_LOSS_REDUNDANCY_PERF 0x45
+/* 0x48 Unrecoverable error bypassed with loss of function */
+#define OPAL_UNRECOVERABLE_ERR_LOSS_OF_FUNCTION 0x48
+
+/*
+ * OPAL Event Sub-type
+ * This field provides additional information on the non-error
+ * event type
+ */
+#define OPAL_NA 0x00
+#define OPAL_MISCELLANEOUS_INFO_ONLY 0x01
+#define OPAL_PREV_REPORTED_ERR_RECTIFIED 0x10
+#define OPAL_SYS_RESOURCES_DECONFIG_BY_USER 0x20
+#define OPAL_SYS_RESOURCE_DECONFIG_PRIOR_ERR 0x21
+#define OPAL_RESOURCE_DEALLOC_EVENT_NOTIFY 0x22
+#define OPAL_CONCURRENT_MAINTENANCE_EVENT 0x40
+#define OPAL_CAPACITY_UPGRADE_EVENT 0x60
+#define OPAL_RESOURCE_SPARING_EVENT 0x70
+#define OPAL_DYNAMIC_RECONFIG_EVENT 0x80
+#define OPAL_NORMAL_SYS_PLATFORM_SHUTDOWN 0xD0
+#define OPAL_ABNORMAL_POWER_OFF 0xE0
+
+/* Max user dump size is 14K */
+#define OPAL_LOG_MAX_DUMP 14336
+#define OPAL_USER_DATA_SZ 4
+
+/* Multiple user data sections */
+struct __attribute__((__packed__)) opal_user_data_section {
+ uint32_t tag;
+ uint16_t size;
+ uint16_t component_id;
+ char data_dump[OPAL_USER_DATA_SZ];
+};
+
+
+/*
+ * All the information regarding an error/event to be reported
+ * needs to populate this structure using pre-defined interfaces
+ * only
+ */
+struct __attribute__((__packed__)) opal_errorlog {
+
+ uint16_t component_id;
+ uint8_t error_event_type;
+ uint8_t subsystem_id;
+
+ uint8_t event_severity;
+ uint8_t event_subtype;
+ uint8_t user_section_count;
+ uint8_t elog_origin;
+
+ uint32_t user_section_size;
+ uint32_t reason_code;
+ uint32_t additional_info[4];
+
+ char user_data_dump[OPAL_LOG_MAX_DUMP];
+};
+
/* Machine check related definitions */
enum OpalMCE_Version {
OpalMCE_V1 = 1,
@@ -861,6 +975,15 @@ int64_t opal_get_elog_size(uint64_t *log_id, size_t *size, uint64_t *elog_type);
int64_t opal_write_elog(uint64_t buffer, uint64_t size, uint64_t offset);
int64_t opal_send_ack_elog(uint64_t log_id);
void opal_resend_pending_logs(void);
+struct opal_errorlog *opal_elog_create(uint8_t opal_error_event_type,
+ uint16_t opal_component_id, uint8_t opal_subsystem_id,
+ uint8_t opal_event_severity, uint8_t opal_event_subtype,
+ uint32_t reason_code, uint32_t info0, uint32_t info1,
+ uint32_t info2, uint32_t info3);
+int opal_elog_update_user_dump(struct opal_errorlog *buf, unsigned char *data,
+ uint32_t tag, uint16_t size);
+int opal_commit_errorlog_to_fsp(struct opal_errorlog *buf);
+int opal_commit_log_to_fsp(void *buf);
int64_t opal_validate_flash(uint64_t buffer, uint32_t *size, uint32_t *result);
int64_t opal_manage_flash(uint8_t op);
int64_t opal_update_flash(uint64_t blk_list);
diff --git a/arch/powerpc/platforms/powernv/opal-elog.c b/arch/powerpc/platforms/powernv/opal-elog.c
index fc891ae..5aa2d86 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -8,6 +8,9 @@
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*/
+#undef DEBUG
+#define pr_fmt(fmt) "ELOG: " fmt
+
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/of.h>
@@ -16,6 +19,7 @@
#include <linux/fs.h>
#include <linux/vmalloc.h>
#include <linux/fcntl.h>
+#include <linux/mm.h>
#include <asm/uaccess.h>
#include <asm/opal.h>
@@ -272,6 +276,78 @@ static int init_err_log_buffer(void)
return 0;
}
+/* Interface to be used by POWERNV to push the logs to FSP via Sapphire */
+struct opal_errorlog *opal_elog_create(uint8_t opal_error_event_type,
+ uint16_t opal_component_id, uint8_t opal_subsystem_id,
+ uint8_t opal_event_severity, uint8_t opal_event_subtype,
+ uint32_t reason_code, uint32_t info0, uint32_t info1,
+ uint32_t info2, uint32_t info3)
+{
+ struct opal_errorlog *buf;
+
+ buf = kzalloc(sizeof(struct opal_errorlog), GFP_KERNEL);
+ if (!buf) {
+ pr_err("Failed to allocate buffer for generating error log\n");
+ return NULL;
+ }
+
+ buf->error_event_type = opal_error_event_type;
+ buf->component_id = opal_component_id;
+ buf->subsystem_id = opal_subsystem_id;
+ buf->event_severity = opal_event_severity;
+ buf->event_subtype = opal_event_subtype;
+ buf->reason_code = reason_code;
+ buf->additional_info[0] = info0;
+ buf->additional_info[1] = info1;
+ buf->additional_info[2] = info2;
+ buf->additional_info[3] = info3;
+ return buf;
+}
+
+int opal_elog_update_user_dump(struct opal_errorlog *buf, unsigned char *data,
+ uint32_t tag, uint16_t size)
+{
+ char *buffer;
+ struct opal_user_data_section *tmp;
+
+ if (!buf) {
+ pr_err("Cannot update user data. Error log buffer is invalid");
+ return -1;
+ }
+
+ buffer = (char *)buf->user_data_dump + buf->user_section_size;
+ if ((buf->user_section_size + size) > OPAL_LOG_MAX_DUMP) {
+ pr_err("Size of user data overruns the buffer");
+ return -1;
+ }
+
+ tmp = (struct opal_user_data_section *)buffer;
+ tmp->tag = tag;
+ tmp->size = size + sizeof(struct opal_user_data_section)
+ - OPAL_USER_DATA_SZ;
+ memcpy(tmp->data_dump, data, size);
+
+ buf->user_section_size += tmp->size;
+ buf->user_section_count++;
+ return 0;
+}
+
+int opal_commit_errorlog_to_fsp(struct opal_errorlog *buf)
+{
+ int rc;
+
+ rc = opal_commit_log_to_fsp((void *)
+ (vmalloc_to_pfn(buf) << PAGE_SHIFT));
+ if (rc == OPAL_SUCCESS) {
+ /* If the log has been committed, free the buffer */
+ kfree(buf);
+ buf = NULL;
+ } else
+ pr_err("Error log could not be committed to FSP");
+
+ return rc;
+}
+
/* Initialize error logging */
int __init opal_elog_init(void)
{
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S b/arch/powerpc/platforms/powernv/opal-wrappers.S
index c4907aa..65c25277 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -136,3 +136,4 @@ OPAL_CALL(opal_sync_host_reboot, OPAL_SYNC_HOST_REBOOT);
OPAL_CALL(opal_sensor_read, OPAL_SENSOR_READ);
OPAL_CALL(opal_get_param, OPAL_GET_PARAM);
OPAL_CALL(opal_set_param, OPAL_SET_PARAM);
+OPAL_CALL(opal_commit_log_to_fsp, OPAL_ELOG_SEND);
^ permalink raw reply related
* [PATCH V3 0/3] powerpc/powernv: Error logging interfaces
From: Deepthi Dharwar @ 2014-01-18 2:42 UTC (permalink / raw)
To: benh, linuxppc-dev, mpe
This patch series defines generic interfaces for error logging to
push down critical errors from powernv platform to FSP.
Also, it contains few minor fixes for the exisiting error logging
framework that retrieves error logs from FSP.
This patch only adds the framework to log errors. Coming days this
framework will be used to report all POWERNV errors in a phased manner.
We would ideally be targeting one sub-system at a time and use these
interfaces.
Changes from V2:
* Review comments from V2 have been addressed
includes comment formats, changing naming
conventions and incorporated error handling
of the buffers.
* Minor typo fix and use of pr_err/pr_fmt to
log errors.
Deepthi Dharwar (3):
powernv: Push critical error logs to FSP
powernv: Correct spell error in opal-elog.c
powernv: Have uniform logging of errors in opal-elog.c
arch/powerpc/include/asm/opal.h | 123 ++++++++++++++++++++++++
arch/powerpc/platforms/powernv/opal-elog.c | 92 ++++++++++++++++--
arch/powerpc/platforms/powernv/opal-wrappers.S | 1
3 files changed, 207 insertions(+), 9 deletions(-)
-- Deepthi
^ permalink raw reply
* Pull request: scottwood/linux.git
From: Scott Wood @ 2014-01-18 1:22 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
This contains a fix for a chroma_defconfig build break that was
introduced by e6500 tablewalk support, and a device tree binding patch
that missed the previous pull request due to some last-minute polishing.
The following changes since commit fac515db45207718168cb55ca4d0a390e43b61af:
Merge remote-tracking branch 'scott/next' into next (2014-01-15 14:22:35 +1100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next
for you to fetch changes up to 4b3cbc82a04485f6400cb5b227798daaa8512a23:
clk: corenet: Adds the clock binding (2014-01-17 19:01:27 -0600)
----------------------------------------------------------------
Scott Wood (1):
powerpc/booke64: Guard e6500 tlb handler with CONFIG_PPC_FSL_BOOK3E
Tang Yuantian (1):
clk: corenet: Adds the clock binding
.../devicetree/bindings/clock/corenet-clock.txt | 134 +++++++++++++++++++++
arch/powerpc/Kconfig | 1 +
arch/powerpc/mm/tlb_low_64e.S | 3 +-
arch/powerpc/mm/tlb_nohash.c | 2 +
4 files changed, 139 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/clock/corenet-clock.txt
^ permalink raw reply
* Re: [PATCH v9] clk: corenet: Adds the clock binding
From: Scott Wood @ 2014-01-18 1:06 UTC (permalink / raw)
To: Tang Yuantian; +Cc: mark.rutland, b07421, devicetree, linuxppc-dev
In-Reply-To: <1389600995-28293-1-git-send-email-Yuantian.Tang@freescale.com>
On Mon, 2014-01-13 at 16:16 +0800, Tang Yuantian wrote:
> +Example for clock block and clock provider:
> +/ {
> + clockgen: global-utilities@e1000 {
> + compatible = "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0";
> + ranges = <0x0 0xe1000 0x1000>;
> + clock-frequency = 133333;
Missing <> around 133333, and the actual p5020ds input clock (based on
observing what U-Boot fills in) is 133333333, not 133333.
I'll fix when applying.
-Scott
^ permalink raw reply
* [PATCH] powerpc/booke64: Guard e6500 tlb handler with CONFIG_PPC_FSL_BOOK3E
From: Scott Wood @ 2014-01-18 0:53 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood
...and make CONFIG_PPC_FSL_BOOK3E conflict with CONFIG_PPC_64K_PAGES.
This fixes a build break with CONFIG_PPC_64K_PAGES on 64-bit book3e,
that was introduced by commit 28efc35fe68dacbddc4b12c2fa8f2df1593a4ad3
("powerpc/e6500: TLB miss handler with hardware tablewalk support").
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/mm/tlb_low_64e.S | 3 ++-
arch/powerpc/mm/tlb_nohash.c | 2 ++
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index fa39517..ad912d5 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -526,6 +526,7 @@ config PPC_16K_PAGES
config PPC_64K_PAGES
bool "64k page size" if 44x || PPC_STD_MMU_64 || PPC_BOOK3E_64
+ depends on !PPC_FSL_BOOK3E
select PPC_HAS_HASH_64K if PPC_STD_MMU_64
config PPC_256K_PAGES
diff --git a/arch/powerpc/mm/tlb_low_64e.S b/arch/powerpc/mm/tlb_low_64e.S
index 16250b1..c95eb32 100644
--- a/arch/powerpc/mm/tlb_low_64e.S
+++ b/arch/powerpc/mm/tlb_low_64e.S
@@ -240,6 +240,7 @@ itlb_miss_fault_bolted:
beq tlb_miss_common_bolted
b itlb_miss_kernel_bolted
+#ifdef CONFIG_PPC_FSL_BOOK3E
/*
* TLB miss handling for e6500 and derivatives, using hardware tablewalk.
*
@@ -409,7 +410,7 @@ itlb_miss_fault_e6500:
TLB_MISS_STATS_I(MMSTAT_TLB_MISS_NORM_FAULT)
tlb_epilog_bolted
b exc_instruction_storage_book3e
-
+#endif /* CONFIG_PPC_FSL_BOOK3E */
/**********************************************************************
* *
diff --git a/arch/powerpc/mm/tlb_nohash.c b/arch/powerpc/mm/tlb_nohash.c
index 735839b..b37a58e 100644
--- a/arch/powerpc/mm/tlb_nohash.c
+++ b/arch/powerpc/mm/tlb_nohash.c
@@ -557,10 +557,12 @@ static void setup_mmu_htw(void)
patch_exception(0x1c0, exc_data_tlb_miss_htw_book3e);
patch_exception(0x1e0, exc_instruction_tlb_miss_htw_book3e);
break;
+#ifdef CONFIG_PPC_FSL_BOOK3E
case PPC_HTW_E6500:
patch_exception(0x1c0, exc_data_tlb_miss_e6500_book3e);
patch_exception(0x1e0, exc_instruction_tlb_miss_e6500_book3e);
break;
+#endif
}
pr_info("MMU: Book3E HW tablewalk %s\n",
book3e_htw_mode != PPC_HTW_NONE ? "enabled" : "not supported");
--
1.8.3.2
^ permalink raw reply related
* Re: Pull request: scottwood/linux.git
From: Scott Wood @ 2014-01-17 23:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1389758064.6933.56.camel@pasglop>
On Wed, 2014-01-15 at 14:54 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2014-01-10 at 18:44 -0600, Scott Wood wrote:
> > Highlights include 32-bit booke relocatable support, e6500 hardware
> > tablewalk support, various e500 SPE fixes, some new/revived boards, and
> > e6500 deeper idle and altivec powerdown modes.
>
> This breaks WSP (A2) build with 64K pages:
>
> /home/benh/linux-powerpc-test/arch/powerpc/mm/tlb_low_64e.S: Assembler messages:
> /home/benh/linux-powerpc-test/arch/powerpc/mm/tlb_low_64e.S:334: Error: can't resolve `L0^A' {*ABS* section} - `PUD_SHIFT' {*UND* section}
> /home/benh/linux-powerpc-test/arch/powerpc/mm/tlb_low_64e.S:334: Error: expression too complex
> /home/benh/linux-powerpc-test/arch/powerpc/mm/tlb_low_64e.S:334: Error: operand out of range (67 is not between 0 and 63)
> make[2]: *** [arch/powerpc/mm/tlb_low_64e.o] Error 1
>
> I'm merging anyway because nobody uses WSP anymore (I'm keen to remove it by 3.15 or so)
Does this apply to all non-FSL 64-bit book3e, or is there anything else
that is still in use?
> but in the meantime you may want to fix it (probably just ifdef the PUD level walk on
> 64k pages, look at what I do elsewhere).
Ifdeffing the PUD level doesn't make much sense in this case (other than
perhaps as the least intrusive way to make the error go away) because
that codepath is specific to e6500 which doesn't support 64K pages. The
whole e6500 section should be ifdeffed out if there are 64K pages (or
really, if CONFIG_PPC_FSL_BOOK3E isn't defined, and 64K pages should
conflict with PPC_FSL_BOOK3E).
-Scott
^ permalink raw reply
* Re: [PATCH 3/4 v2]powerpc/fsl-booke: Add support for T2080/T2081 SoC
From: Scott Wood @ 2014-01-17 22:27 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linuxppc-dev
In-Reply-To: <1389866562-6235-1-git-send-email-Shengzhou.Liu@freescale.com>
On Thu, 2014-01-16 at 18:02 +0800, Shengzhou Liu wrote:
> + cpc: l3-cache-controller@10000 {
> + compatible = "cache";
> + reg = <0x10000 0x1000
> + 0x11000 0x1000
> + 0x12000 0x1000>;
> + interrupts = <16 2 1 27
> + 16 2 1 26
> + 16 2 1 25>;
> + };
Where's the specific compatible for this node?
> + corenet-cf@18000 {
> + compatible = "fsl,corenet2-cf";
> + reg = <0x18000 0x1000>;
> + interrupts = <16 2 1 31>;
> + fsl,ccf-num-csdids = <32>;
> + fsl,ccf-num-snoopids = <32>;
> + };
"fsl,corenet2-cf" doesn't appear in any other device tree nor in any
binding.
> + clockgen: global-utilities@e1000 {
> + compatible = "fsl,qoriq-clockgen-2.0", "fixed-clock";
> + reg = <0xe1000 0x1000>;
> + clock-output-names = "sysclk";
> + #clock-cells = <0>;
Please update this according to v9 of the clock binding:
In particular, sysclk goes in its own node, and compatible strings have
changed.
> + rcpm: global-utilities@e2000 {
> + compatible = "fsl,qoriq-rcpm-2.0";
> + reg = <0xe2000 0x1000>;
> + };
compatible = "fsl,t2080-rcpm-2.0", "fsl,qoriq-rcpm-2.0";
-Scott
^ permalink raw reply
* Re: [PATCH RFC] powerpc/mpc85xx: add support for the kmp204x reference board
From: Scott Wood @ 2014-01-17 21:48 UTC (permalink / raw)
To: Valentin Longchamp; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <52D9273E.10008@keymile.com>
On Fri, 2014-01-17 at 13:51 +0100, Valentin Longchamp wrote:
> Hi Scott,
>
> Thanks for you feedback.
>
> On 01/17/2014 12:35 AM, Scott Wood wrote:
> > On Thu, 2014-01-16 at 14:38 +0100, Valentin Longchamp wrote:
> >> This patch introduces the support for Keymile's kmp204x reference
> >> design. This design is based on Freescale's P2040/P2041 SoC.
> >>
> >> The peripherals used by this design are:
> >> - SPI NOR Flash as bootloader medium
> >> - NAND Flash with a ubi partition
> >> - 2 PCIe busses (hosts 1 and 3)
> >> - 3 FMAN Ethernet devices (FMAN1 DTSEC1/2/5)
> >> - 4 Local Bus windows, with one dedicated to the QRIO reset/power mgmt
> >> FPGA
> >> - 2 HW I2C busses
> >> - last but not least, the mandatory serial port
> >>
> >> The patch also adds a defconfig file for this reference design and a DTS
> >> file for the kmcoge4 board which is the first one based on this
> >> reference design.
> >>
> >> To try to avoid code duplication, the support was added directly to the
> >> corenet_generic.c file.
> >>
> >> Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
> >> ---
> >> arch/powerpc/boot/dts/kmcoge4.dts | 165 ++++++++++++++++++
> >> arch/powerpc/configs/85xx/kmp204x_defconfig | 231 ++++++++++++++++++++++++++
> >> arch/powerpc/platforms/85xx/Kconfig | 14 ++
> >> arch/powerpc/platforms/85xx/Makefile | 1 +
> >> arch/powerpc/platforms/85xx/corenet_generic.c | 52 ++++++
> >> 5 files changed, 463 insertions(+)
> >> create mode 100644 arch/powerpc/boot/dts/kmcoge4.dts
> >> create mode 100644 arch/powerpc/configs/85xx/kmp204x_defconfig
> >>
> >> diff --git a/arch/powerpc/boot/dts/kmcoge4.dts b/arch/powerpc/boot/dts/kmcoge4.dts
> >> new file mode 100644
> >> index 0000000..c10df6d
> >> --- /dev/null
> >> +++ b/arch/powerpc/boot/dts/kmcoge4.dts
> >> @@ -0,0 +1,165 @@
> >> +/*
> >> + * Keymile kmcoge4 Device Tree Source, based on the P2041RDB DTS
> >> + *
> >> + * (C) Copyright 2014
> >> + * Valentin Longchamp, Keymile AG, valentin.longchamp@keymile.com
> >> + *
> >> + * Copyright 2011 Freescale Semiconductor Inc.
> >> + *
> >> + * 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 of the License, or (at your
> >> + * option) any later version.
> >> + */
> >> +
> >> +/include/ "fsl/p2041si-pre.dtsi"
> >> +
> >> +/ {
> >> + model = "keymile,kmcoge4";
> >> + compatible = "keymile,kmp204x";
> >
> > Don't put wildcards in compatible.
>
> Well it's a wildcard in the sense that we support both the p2040 and the p2041,
> but it's also the name of the plaftorm, similarly to names like '85xx' or 'tqm85xx'.
Names like 85xx are not allowed in device trees.
With "p204x", what would happen if a p2042 were introduced, that were
not compatible?
Why isn't the compatible "keymile,kmcoge4", like the model?
> > I realize it's common practice, but it would be good to get away from
> > putting partition layouts in the dts file. Alternatives include using
> > mtdparts on the command line, or having U-Boot put the partition info
> > into the dtb based on the mtdparts environment variable (there is
> > existing code for this).
>
> I agree that u-boot also has to know about the addresses because it also
> accesses these partitions.
>
> But I think it is clearer to have this in the device tree: I try to keep the
> kernel command line small and I don't like having u-boot "fixing" the dtb at
> runtime.
The problem is that the dts source is often far removed from the actual
programming of flash, and the partitioning can vary based on use case,
or change for other reasons (e.g. there have been requests to change
existing partition layouts to accommodate growth in U-Boot size).
Ideally it wouldn't be in the device tree at all, but having U-Boot fix
it up based on an environment variable is better than statically
defining it in a file in the Linux tree.
> >> + zl30343@1 {
> >> + compatible = "gen,spidev";
> >
> > Node names are supposed to be generic. Compatibles are supposed to be
> > specific.
>
> That's a very specific device for which we only have a userspace driver and for
> which we must use the generic kernel spidev driver.
The device tree describes the hardware, not what driver you want to use.
Plus, I don't see any driver that matches "gen,spidev" nor any binding
for it, and "gen" doesn't make sense as a vendor prefix. The only
instance of that string I can find in the Linux tree is in mgcoge.dts.
> > That's why the node name is
> > so specific and the compatible field very generic.
Userspace can't search for a node by compatible?
> >> + lbc: localbus@ffe124000 {
> >> + reg = <0xf 0xfe124000 0 0x1000>;
> >> + ranges = <0 0 0xf 0xffa00000 0x00040000 /* LB 0 */
> >> + 1 0 0xf 0xfb000000 0x00010000 /* LB 1 */
> >> + 2 0 0xf 0xd0000000 0x10000000 /* LB 2 */
> >> + 3 0 0xf 0xe0000000 0x10000000>; /* LB 3 */
> >> +
> >> + nand@0,0 {
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> + compatible = "fsl,elbc-fcm-nand";
> >> + reg = <0 0 0x40000>;
> >> +
> >> + partition@0 {
> >> + label = "ubi0";
> >> + reg = <0x0 0x8000000>;
> >> + };
> >> + };
> >> + };
> >
> > No nodes for those other chipselects?
>
> Well, there are nodes, but they are internally developed FPGAs and the drivers
> are not mainlined that's why I removed the nodes.
The device tree describes the hardware, not what drivers are currently
mainlined in Linux.
> >> diff --git a/arch/powerpc/configs/85xx/kmp204x_defconfig b/arch/powerpc/configs/85xx/kmp204x_defconfig
> >> new file mode 100644
> >> index 0000000..3bbf4fa
> >> --- /dev/null
> >> +++ b/arch/powerpc/configs/85xx/kmp204x_defconfig
> >
> > Why does this board need its own defconfig?
>
> Apart from the different drivers and FS that we use (or don't use) on the
> system,
That is not generally a good reason for a separate defconfig. Just
enable the drivers you need in the main defconfig, and don't worry about
the drivers you don't need. You may want a smaller kernel for actual
shipping products (though the changelog said this is a reference
board...), but in mainline we want a small number of defconfigs that
cover as many boards as possible (or at least, a reasonably small number
and not one per board).
> the most notable differences are:
> - lowmem must be set to a bigger size so that we can ioremap the the total
> memory requested for all of our PCIe devices
> - CGROUPS is enabled because that's a mandatory feature for our systems
> - NAND_ECC_BCH is enabled because it is used on all of our NAND devices
I don't think there would be a problem adding CGROUPS or NAND_ECC_BCH to
corenet32_smp_defconfig (though CGROUPS seems more like a use-case
configuration than something to do with the board itself). The lowmem
adjustment is probably a good reason, though I wish things like that
could be specified as a defconfig that #includes corenet32_smp_defconfig
and then just makes a couple changes.
> > The whole point of corenet_generic.c is to avoid duplicating all of this
> > stuff.
> >
> > Can't you just use corenet_generic as-is other than adding the
> > compatible to boards[]? If not, explain why and put it in a different
> > file.
> >
>
> That's a valid point and I have to admit I have hesitated about that. I have
> mostly based my work on the FSL SDK where every single board has a "dedicated" file.
>
> I agree that I do nothing different than the corenet_generic does and adding my
> platform to the boards[] would be the same and you are right, I should use that
> and avoid code duplication.
>
> The only thing that would "bother" me is thus the pr_info print from
> *_gen_setup_arch(), it would be nice if somehow we could differentiate it or at
> least make it more generic since the kmp204x boards are not strictly boards from
> Freescale.
Just remove the "from Freescale Semiconductor" part of the string.
-Scott
^ permalink raw reply
* Re: [RFC PATCH powerpc] Fix compile error of pgtable-ppc64.h
From: Benjamin Herrenschmidt @ 2014-01-17 20:59 UTC (permalink / raw)
To: Li Zhong; +Cc: Paul Mackerras, PowerPC email list, Aneesh Kumar K.V
In-Reply-To: <1389965453.5628.3.camel@ThinkPad-T5421>
On Fri, 2014-01-17 at 21:30 +0800, Li Zhong wrote:
> On Fri, 2014-01-17 at 12:27 +0530, Aneesh Kumar K.V wrote:
> > Li Zhong <zhong@linux.vnet.ibm.com> writes:
> >
> > > It seems that forward declaration couldn't work well with typedef, use
> > > struct spinlock directly to avoiding following build errors:
> > >
> > > In file included from include/linux/spinlock.h:81,
> > > from include/linux/seqlock.h:35,
> > > from include/linux/time.h:5,
> > > from include/uapi/linux/timex.h:56,
> > > from include/linux/timex.h:56,
> > > from include/linux/sched.h:17,
> > > from arch/powerpc/kernel/asm-offsets.c:17:
> > > include/linux/spinlock_types.h:76: error: redefinition of typedef 'spinlock_t'
> > > /root/linux-next/arch/powerpc/include/asm/pgtable-ppc64.h:563: note: previous declaration of 'spinlock_t' was here
> > >
> >
> > what compiler version ? I have seen that error in gcc 4.3 and it was
> > concluded that it is too old a compiler version to worry about. That
> > specific compiler version also gave error for forward declaring struct;
>
> gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC), and it doesn't
> report error after use struct directly.
Ok, I think that's justification enough then. I'll add that. It's all
too late for 3.13 anyway so I'll send these patches during the window
with an appropriate CC to stable.
Cheers,
Ben.
> >
> > > Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
> > > ---
> > > arch/powerpc/include/asm/pgtable-ppc64.h | 6 +++---
> > > 1 files changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h
> > > index d27960c..bc141c9 100644
> > > --- a/arch/powerpc/include/asm/pgtable-ppc64.h
> > > +++ b/arch/powerpc/include/asm/pgtable-ppc64.h
> > > @@ -560,9 +560,9 @@ extern void pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
> > > pmd_t *pmdp);
> > >
> > > #define pmd_move_must_withdraw pmd_move_must_withdraw
> > > -typedef struct spinlock spinlock_t;
> > > -static inline int pmd_move_must_withdraw(spinlock_t *new_pmd_ptl,
> > > - spinlock_t *old_pmd_ptl)
> > > +struct spinlock;
> > > +static inline int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
> > > + struct spinlock *old_pmd_ptl)
> > > {
> > > /*
> > > * Archs like ppc64 use pgtable to store per pmd
>
^ permalink raw reply
* Re: [PATCH] powerpc/configs: Enbale Freescale IFC controller
From: Scott Wood @ 2014-01-17 18:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Prabhakar Kushwaha
In-Reply-To: <B2E40837-4025-4975-8DAC-BB47E2B07E1A@kernel.crashing.org>
On Fri, 2014-01-17 at 11:02 -0600, Kumar Gala wrote:
> On Jan 17, 2014, at 12:09 AM, Prabhakar Kushwaha <prabhakar@freescale.com> wrote:
>
> > Currently IFC NAND driver is enabled in corenet32smp_defconfig. But IFC
> > controller is not enabled
> >
> > So, Enable IFC controller in corenet32smp_defconfig.
> >
> > Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> > ---
> > Based upon git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
> > branch master
> >
> > arch/powerpc/configs/corenet32_smp_defconfig | 1 +
> > 1 file changed, 1 insertion(+)
>
> Shouldn’t the NAND driver get the IFC controller enabled by Kconfig dependancies?
Yes (by select, not dependencies).
Prabhakar, was there an actual problem you saw before? Did you run
savedefconfig after making this change?
CONFIG_FSL_IFC isn't even user-selectable (though it probably should be,
as how else would it get enabled in the absence of NAND for catching NOR
errors?).
-Scott
^ permalink raw reply
* linuxppc-dev@lists.ozlabs.org
From: Christian Zigotzky @ 2014-01-17 18:04 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
First, let me introduce myself. My name is Christian Zigotzky. I'm 39
years old and I live in Germany. My hobbies are traveling and computing.
I'm a member of the A-EON Core Linux Support Team.
A-EON Technology, in co-operation with Varisys, Hyperion Entertainment
and AmigaKit created the AmigaONE X1000, a new high-end, prestige
platform that will once more allow the Amiga Operating System to shine.
The Nemo motherboard is at the heart of A-EON Technology’s AmigaONE
X1000 system, the most powerful Next-Generation computer, custom
designed to specifically run the latest version of the Amiga Operating
system (AmigaOS 4.1). Built around the unique PA Semi PA6T 1682M, a
64-bit dual core PowerPC CPU, the Nemo motherboard also supports a lot
of Linux PowerPC distributions including the a specially configured Live
Ubuntu Remix 12.04 LTS DVD.
Information about the Nemo board:
CPU: PA Semi Dual-core PA6T-1682M, nominal 2.0GHz (1.8GHz standard)
PowerISA™ v2.04+
4x DDR2 RAM slots
10x USB 2.0
1x Gigabit Ethernet
2x PCIe x16 slots (1x16 or 2x8)
2x PCIe x1 slots
1x Xorro slot
2x PCI legacy slots
2x RS232
4x SATA 2 connectors
1x IDE connector
JTAG connector
1x Compact Flash
1x "Xena" 500MHz XMOS XS1-L2 124
http://en.wikipedia.org/wiki/AmigaOne_X1000
http://www.a-eon.com/?page=nemo
http://www.supertuxkart-amiga.de/amiga/x1000.html
The Nemo motherboard is currently available. You can buy it from a lot
of Amiga dealers. It is also possible to get a developer board for free
of charge.
Current state of the Linux support:
RadeonHD 4000, 5000, 6000 series support: WORKS
HDAudio 7.1 Driver: WORKS
PA Semi Network Driver: WORKS
3D acceleration: WORKS (Mesa 8.0.X - 9.1.X)
Linux distributions: Debian 6 and 7, Ubuntu 10.04.4 LTS and 12.04.3 LTS,
openSUSE 11.1 and 12.3, Fedora 17, Gentoo, CRUX PPC, Red Ribbon RC6,
Live Debian USB image, Live MintPPC USB image, and MintPPC 11. Released
soon: Live Ubuntu Remix DVD. In development: Ubuntu 13.10 and 14.04,
Debian Sid, and SliTaz.
Linux kernel: 2.6.38, 2.6.39, 3.5.7, 3.8.7, 3.9.0, 3.9.8.1 (openSUSE
kernel), 3.10.0, 3.10.3 (Ubuntu kernel), 3.10.13, 3.10.15 (Live Ubuntu
Remix DVD kernel), 3.11.0, 3.12.0, and 3.12.5. In development: 3.13.0.
Mesa 9.2.X and higher: DOESN'T WORK
RadeonHD 7000 series support: WORKS WITHOUT 3D ACCELERATION
We have created a patch to support the A-EON Nemo board. It based on the
great work of Olof Johansson. Nemo uses the AMD/ATI SB600 South Bridge
to provide various integrated I/O functions including
SATA/PATA ports, USB and audio. The SB600’s HD Audio controller is
connected to an IDT 92HD700 codec. This patch makes the kernel
compatible with the SB600 chipset and the HD Audio chip on the Nemo
board. It also solved any problems with Radeon HD graphics cards. I'd
like to integrate this patch to the kernel sources. Olof and Alan told
me that I have to split up the big patch into separate patches.
OK, here is the first part. :-)
diff -rupN linux-3.13/arch/powerpc/platforms/pasemi/Kconfig
linux-3.13-nemo/arch/powerpc/platforms/pasemi/Kconfig
--- linux-3.13/arch/powerpc/platforms/pasemi/Kconfig 2013-12-06
18:34:04.000000000 +0100
+++ linux-3.13-nemo/arch/powerpc/platforms/pasemi/Kconfig 2013-12-14
10:31:19.896353725 +0100
@@ -14,6 +14,13 @@ config PPC_PASEMI
menu "PA Semi PWRficient options"
depends on PPC_PASEMI
+config PPC_PASEMI_SB600
+ bool "Nemo SB600 South Bridge Support"
+ depends on PPC_PASEMI
+ select PPC_I8259
+ help
+ Workarounds for the SB600 South Bridge.
+
config PPC_PASEMI_IOMMU
bool "PA Semi IOMMU support"
depends on PPC_PASEMI
Is it possible to integrate the support of the Nemo board to the
official kernel sources? Thanks a lot to this list for the help to solve
the boot problems with the kernel 3.13. Sorry, my English isn't very
well. I hope you understand my email. But I'll learn more English. I
promise it gets better.
Rgds,
Christian
^ permalink raw reply
* PASEMI: Nemo support
From: Christian Zigotzky @ 2014-01-17 18:11 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
First, let me introduce myself. My name is Christian Zigotzky. I'm 39
years old and I live in Germany. My hobbies are traveling and computing.
I'm a member of the A-EON Core Linux Support Team.
A-EON Technology, in co-operation with Varisys, Hyperion Entertainment
and AmigaKit created the AmigaONE X1000, a new high-end, prestige
platform that will once more allow the Amiga Operating System to shine.
The Nemo motherboard is at the heart of A-EON Technology’s AmigaONE
X1000 system, the most powerful Next-Generation computer, custom
designed to specifically run the latest version of the Amiga Operating
system (AmigaOS 4.1). Built around the unique PA Semi PA6T 1682M, a
64-bit dual core PowerPC CPU, the Nemo motherboard also supports a lot
of Linux PowerPC distributions including the a specially configured Live
Ubuntu Remix 12.04 LTS DVD.
Information about the Nemo board:
CPU: PA Semi Dual-core PA6T-1682M, nominal 2.0GHz (1.8GHz standard)
PowerISA™ v2.04+
4x DDR2 RAM slots
10x USB 2.0
1x Gigabit Ethernet
2x PCIe x16 slots (1x16 or 2x8)
2x PCIe x1 slots
1x Xorro slot
2x PCI legacy slots
2x RS232
4x SATA 2 connectors
1x IDE connector
JTAG connector
1x Compact Flash
1x "Xena" 500MHz XMOS XS1-L2 124
http://en.wikipedia.org/wiki/AmigaOne_X1000
http://www.a-eon.com/?page=nemo
http://www.supertuxkart-amiga.de/amiga/x1000.html
The Nemo motherboard is currently available. You can buy it from a lot
of Amiga dealers. It is also possible to get a developer board for free
of charge.
Current state of the Linux support:
RadeonHD 4000, 5000, 6000 series support: WORKS
HDAudio 7.1 Driver: WORKS
PA Semi Network Driver: WORKS
3D acceleration: WORKS (Mesa 8.0.X - 9.1.X)
Linux distributions: Debian 6 and 7, Ubuntu 10.04.4 LTS and 12.04.3 LTS,
openSUSE 11.1 and 12.3, Fedora 17, Gentoo, CRUX PPC, Red Ribbon RC6,
Live Debian USB image, Live MintPPC USB image, and MintPPC 11. Released
soon: Live Ubuntu Remix DVD. In development: Ubuntu 13.10 and 14.04,
Debian Sid, and SliTaz.
Linux kernel: 2.6.38, 2.6.39, 3.5.7, 3.8.7, 3.9.0, 3.9.8.1 (openSUSE
kernel), 3.10.0, 3.10.3 (Ubuntu kernel), 3.10.13, 3.10.15 (Live Ubuntu
Remix DVD kernel), 3.11.0, 3.12.0, and 3.12.5. In development: 3.13.0.
Mesa 9.2.X and higher: DOESN'T WORK
RadeonHD 7000 series support: WORKS WITHOUT 3D ACCELERATION
We have created a patch to support the A-EON Nemo board. It based on the
great work of Olof Johansson. Nemo uses the AMD/ATI SB600 South Bridge
to provide various integrated I/O functions including
SATA/PATA ports, USB and audio. The SB600’s HD Audio controller is
connected to an IDT 92HD700 codec. This patch makes the kernel
compatible with the SB600 chipset and the HD Audio chip on the Nemo
board. It also solved any problems with Radeon HD graphics cards. I'd
like to integrate this patch to the kernel sources. Olof and Alan told
me that I have to split up the big patch into separate patches.
OK, here is the first part.
diff -rupN linux-3.13/arch/powerpc/platforms/pasemi/Kconfig
linux-3.13-nemo/arch/powerpc/platforms/pasemi/Kconfig
--- linux-3.13/arch/powerpc/platforms/pasemi/Kconfig 2013-12-06
18:34:04.000000000 +0100
+++ linux-3.13-nemo/arch/powerpc/platforms/pasemi/Kconfig 2013-12-14
10:31:19.896353725 +0100
@@ -14,6 +14,13 @@ config PPC_PASEMI
menu "PA Semi PWRficient options"
depends on PPC_PASEMI
+config PPC_PASEMI_SB600
+ bool "Nemo SB600 South Bridge Support"
+ depends on PPC_PASEMI
+ select PPC_I8259
+ help
+ Workarounds for the SB600 South Bridge.
+
config PPC_PASEMI_IOMMU
bool "PA Semi IOMMU support"
depends on PPC_PASEMI
Is it possible to integrate the support of the Nemo board to the
official kernel sources? Thanks a lot to this list for the help to solve
the boot problems with the kernel 3.13. Sorry, my English isn't very
well. I hope you understand my email. But I'll learn more English. I
promise it gets better.
Rgds,
Christian
^ permalink raw reply
* Re: [PATCH 1/2][v3] driver/memory:Move Freescale IFC driver to a common driver
From: Kumar Gala @ 2014-01-17 17:08 UTC (permalink / raw)
To: Prabhakar Kushwaha
Cc: Scott Wood, Greg Kroah-Hartman, linuxppc-dev, linux-kernel,
Arnd Bergmann
In-Reply-To: <1389850929-19873-1-git-send-email-prabhakar@freescale.com>
On Jan 15, 2014, at 11:42 PM, Prabhakar Kushwaha =
<prabhakar@freescale.com> wrote:
> Freescale IFC controller has been used for mpc8xxx. It will be used
> for ARM-based SoC as well. This patch moves the driver to =
driver/memory
> and fix the header file includes.
>=20
> Also remove module_platform_driver() and instead call
> platform_driver_register() from subsys_initcall() to make sure this =
module
> has been loaded before MTD partition parsing starts.
>=20
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> ---
> Changes for v2:
> - Move fsl_ifc in driver/memory
>=20
> Changes for v3:
> - move device tree bindings to memory
>=20
> .../{powerpc =3D> memory-controllers}/fsl/ifc.txt | 0
> arch/powerpc/sysdev/Makefile | 1 -
> drivers/memory/Makefile | 1 +
> {arch/powerpc/sysdev =3D> drivers/memory}/fsl_ifc.c | 8 ++++++--
> drivers/mtd/nand/fsl_ifc_nand.c | 2 +-
> .../include/asm =3D> include/linux}/fsl_ifc.h | 0
> 6 files changed, 8 insertions(+), 4 deletions(-)
> rename Documentation/devicetree/bindings/{powerpc =3D> =
memory-controllers}/fsl/ifc.txt (100%)
> rename {arch/powerpc/sysdev =3D> drivers/memory}/fsl_ifc.c (98%)
> rename {arch/powerpc/include/asm =3D> include/linux}/fsl_ifc.h (100%)
The Kconfig option for FSL_IFC should move into drivers/memory/Kconfig
>=20
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt =
b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> similarity index 100%
> rename from Documentation/devicetree/bindings/powerpc/fsl/ifc.txt
> rename to =
Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> diff --git a/arch/powerpc/sysdev/Makefile =
b/arch/powerpc/sysdev/Makefile
> index f67ac90..afbcc37 100644
> --- a/arch/powerpc/sysdev/Makefile
> +++ b/arch/powerpc/sysdev/Makefile
> @@ -21,7 +21,6 @@ obj-$(CONFIG_FSL_SOC) +=3D fsl_soc.o =
fsl_mpic_err.o
> obj-$(CONFIG_FSL_PCI) +=3D fsl_pci.o $(fsl-msi-obj-y)
> obj-$(CONFIG_FSL_PMC) +=3D fsl_pmc.o
> obj-$(CONFIG_FSL_LBC) +=3D fsl_lbc.o
> -obj-$(CONFIG_FSL_IFC) +=3D fsl_ifc.o
> obj-$(CONFIG_FSL_GTM) +=3D fsl_gtm.o
> obj-$(CONFIG_FSL_85XX_CACHE_SRAM) +=3D fsl_85xx_l2ctlr.o =
fsl_85xx_cache_sram.o
> obj-$(CONFIG_SIMPLE_GPIO) +=3D simple_gpio.o
> diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
> index 969d923..f2bf25c 100644
> --- a/drivers/memory/Makefile
> +++ b/drivers/memory/Makefile
> @@ -6,6 +6,7 @@ ifeq ($(CONFIG_DDR),y)
> obj-$(CONFIG_OF) +=3D of_memory.o
> endif
> obj-$(CONFIG_TI_EMIF) +=3D emif.o
> +obj-$(CONFIG_FSL_IFC) +=3D fsl_ifc.o
> obj-$(CONFIG_MVEBU_DEVBUS) +=3D mvebu-devbus.o
> obj-$(CONFIG_TEGRA20_MC) +=3D tegra20-mc.o
> obj-$(CONFIG_TEGRA30_MC) +=3D tegra30-mc.o
> diff --git a/arch/powerpc/sysdev/fsl_ifc.c b/drivers/memory/fsl_ifc.c
> similarity index 98%
> rename from arch/powerpc/sysdev/fsl_ifc.c
> rename to drivers/memory/fsl_ifc.c
> index d7fc722..135a950 100644
> --- a/arch/powerpc/sysdev/fsl_ifc.c
> +++ b/drivers/memory/fsl_ifc.c
> @@ -30,8 +30,8 @@
> #include <linux/of.h>
> #include <linux/of_device.h>
> #include <linux/platform_device.h>
> +#include <linux/fsl_ifc.h>
> #include <asm/prom.h>
> -#include <asm/fsl_ifc.h>
>=20
> struct fsl_ifc_ctrl *fsl_ifc_ctrl_dev;
> EXPORT_SYMBOL(fsl_ifc_ctrl_dev);
> @@ -299,7 +299,11 @@ static struct platform_driver fsl_ifc_ctrl_driver =
=3D {
> .remove =3D fsl_ifc_ctrl_remove,
> };
>=20
> -module_platform_driver(fsl_ifc_ctrl_driver);
> +static int __init fsl_ifc_init(void)
> +{
> + return platform_driver_register(&fsl_ifc_ctrl_driver);
> +}
> +subsys_initcall(fsl_ifc_init);
>=20
> MODULE_LICENSE("GPL");
> MODULE_AUTHOR("Freescale Semiconductor");
> diff --git a/drivers/mtd/nand/fsl_ifc_nand.c =
b/drivers/mtd/nand/fsl_ifc_nand.c
> index 4335577..865b323 100644
> --- a/drivers/mtd/nand/fsl_ifc_nand.c
> +++ b/drivers/mtd/nand/fsl_ifc_nand.c
> @@ -30,7 +30,7 @@
> #include <linux/mtd/nand.h>
> #include <linux/mtd/partitions.h>
> #include <linux/mtd/nand_ecc.h>
> -#include <asm/fsl_ifc.h>
> +#include <linux/fsl_ifc.h>
>=20
> #define FSL_IFC_V1_1_0 0x01010000
> #define ERR_BYTE 0xFF /* Value returned for read
> diff --git a/arch/powerpc/include/asm/fsl_ifc.h =
b/include/linux/fsl_ifc.h
> similarity index 100%
> rename from arch/powerpc/include/asm/fsl_ifc.h
> rename to include/linux/fsl_ifc.h
> --=20
> 1.7.9.5
>=20
>=20
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe =
linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH] powerpc/pci: Fix IMMRBAR address
From: Kumar Gala @ 2014-01-17 17:06 UTC (permalink / raw)
To: Minghuan Lian; +Cc: Scott Wood, linuxppc-dev, Zang Roy-R61911
In-Reply-To: <1389860091-32754-1-git-send-email-Minghuan.Lian@freescale.com>
On Jan 16, 2014, at 2:14 AM, Minghuan Lian <Minghuan.Lian@freescale.com> =
wrote:
> For PEXCSRBAR, bit 3-0 indicate prefetchable and address type.
> So when getting base address, these bits should be masked,
> otherwise we may get incorrect base address.
>=20
> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> ---
> arch/powerpc/sysdev/fsl_pci.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>=20
> diff --git a/arch/powerpc/sysdev/fsl_pci.c =
b/arch/powerpc/sysdev/fsl_pci.c
> index 4dfd61d..44eae39 100644
> --- a/arch/powerpc/sysdev/fsl_pci.c
> +++ b/arch/powerpc/sysdev/fsl_pci.c
> @@ -868,6 +868,14 @@ u64 fsl_pci_immrbar_base(struct pci_controller =
*hose)
>=20
> pci_bus_read_config_dword(hose->bus,
> PCI_DEVFN(0, 0), PCI_BASE_ADDRESS_0, &base);
> +
> + /*
> + * For PEXCSRBAR, bit 3-0 indicate prefetchable and
> + * address type. So when getting base address, these
> + * bits should be masked
> + */
> + base &=3D 0xfffffff0;
> +
base & PCI_BASE_ADDRESS_MEM_MASK
> return base;
> }
> #endif
> --=20
> 1.8.1.2
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] powerpc/configs: Enbale Freescale IFC controller
From: Kumar Gala @ 2014-01-17 17:02 UTC (permalink / raw)
To: Prabhakar Kushwaha; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <1389938981-30858-1-git-send-email-prabhakar@freescale.com>
On Jan 17, 2014, at 12:09 AM, Prabhakar Kushwaha =
<prabhakar@freescale.com> wrote:
> Currently IFC NAND driver is enabled in corenet32smp_defconfig. But =
IFC
> controller is not enabled
>=20
> So, Enable IFC controller in corenet32smp_defconfig.
>=20
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> ---
> Based upon =
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
> branch master
>=20
> arch/powerpc/configs/corenet32_smp_defconfig | 1 +
> 1 file changed, 1 insertion(+)
Shouldn=92t the NAND driver get the IFC controller enabled by Kconfig =
dependancies?
- k=
^ permalink raw reply
* [PATCH 2/2] powerpc/pseries: add Gen3 definitions for PCIE link speed
From: Kleber Sacilotto de Souza @ 2014-01-17 13:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Brian King, Paul Mackerras, Kleber Sacilotto de Souza
In-Reply-To: <1389967012-7774-1-git-send-email-klebers@linux.vnet.ibm.com>
Rev3 of the PCI Express Base Specification defines a Supported Link
Speeds Vector where the bit definitions within this field are:
Bit 0 - 2.5 GT/s
Bit 1 - 5.0 GT/s
Bit 2 - 8.0 GT/s
This vector definition is used by the platform firmware to export the
maximum and current link speeds of the PCI bus via the
"ibm,pcie-link-speed-stats" device-tree property.
This patch updates pseries_root_bridge_prepare() to detect Gen3
speed buses (defined by 0x04).
Signed-off-by: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/pci.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/pci.c b/arch/powerpc/platforms/pseries/pci.c
index a6f7a14..c413ec1 100644
--- a/arch/powerpc/platforms/pseries/pci.c
+++ b/arch/powerpc/platforms/pseries/pci.c
@@ -144,6 +144,9 @@ int pseries_root_bridge_prepare(struct pci_host_bridge *bridge)
case 0x02:
bus->max_bus_speed = PCIE_SPEED_5_0GT;
break;
+ case 0x04:
+ bus->max_bus_speed = PCIE_SPEED_8_0GT;
+ break;
default:
bus->max_bus_speed = PCI_SPEED_UNKNOWN;
break;
@@ -156,6 +159,9 @@ int pseries_root_bridge_prepare(struct pci_host_bridge *bridge)
case 0x02:
bus->cur_bus_speed = PCIE_SPEED_5_0GT;
break;
+ case 0x04:
+ bus->cur_bus_speed = PCIE_SPEED_8_0GT;
+ break;
default:
bus->cur_bus_speed = PCI_SPEED_UNKNOWN;
break;
--
1.7.1
^ permalink raw reply related
* [PATCH 1/2] powerpc/pseries: fix regression on PCI link speed
From: Kleber Sacilotto de Souza @ 2014-01-17 13:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Brian King, Paul Mackerras, Kleber Sacilotto de Souza
In-Reply-To: <1389967012-7774-1-git-send-email-klebers@linux.vnet.ibm.com>
Commit 5091f0c (powerpc/pseries: Fix PCIE link speed endian issue)
introduced a regression on the PCI link speed detection using the
device-tree property. The ibm,pcie-link-speed-stats property is composed
of two 32-bit integers, the first one being the maxinum link speed and
the second the current link speed. The changes introduced by the
aforementioned commit are considering just the first integer.
Fix this issue by changing how the property is accessed, using the
helper functions to properly access the array of values. The explicit
byte swapping is not needed anymore here, since it's done by the helper
functions.
Signed-off-by: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/pci.c | 16 +++++++++-------
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/pci.c b/arch/powerpc/platforms/pseries/pci.c
index 70670a2..a6f7a14 100644
--- a/arch/powerpc/platforms/pseries/pci.c
+++ b/arch/powerpc/platforms/pseries/pci.c
@@ -113,7 +113,8 @@ int pseries_root_bridge_prepare(struct pci_host_bridge *bridge)
{
struct device_node *dn, *pdn;
struct pci_bus *bus;
- const __be32 *pcie_link_speed_stats;
+ u32 pcie_link_speed_stats[2];
+ int rc;
bus = bridge->bus;
@@ -122,20 +123,21 @@ int pseries_root_bridge_prepare(struct pci_host_bridge *bridge)
return 0;
for (pdn = dn; pdn != NULL; pdn = of_get_next_parent(pdn)) {
- pcie_link_speed_stats = of_get_property(pdn,
- "ibm,pcie-link-speed-stats", NULL);
- if (pcie_link_speed_stats)
+ rc = of_property_read_u32_array(pdn,
+ "ibm,pcie-link-speed-stats",
+ &pcie_link_speed_stats[0], 2);
+ if (!rc)
break;
}
of_node_put(pdn);
- if (!pcie_link_speed_stats) {
+ if (rc) {
pr_err("no ibm,pcie-link-speed-stats property\n");
return 0;
}
- switch (be32_to_cpup(pcie_link_speed_stats)) {
+ switch (pcie_link_speed_stats[0]) {
case 0x01:
bus->max_bus_speed = PCIE_SPEED_2_5GT;
break;
@@ -147,7 +149,7 @@ int pseries_root_bridge_prepare(struct pci_host_bridge *bridge)
break;
}
- switch (be32_to_cpup(pcie_link_speed_stats)) {
+ switch (pcie_link_speed_stats[1]) {
case 0x01:
bus->cur_bus_speed = PCIE_SPEED_2_5GT;
break;
--
1.7.1
^ permalink raw reply related
* [PATCH 0/2] Fixes for PCI-E link speed
From: Kleber Sacilotto de Souza @ 2014-01-17 13:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Brian King, Paul Mackerras, Kleber Sacilotto de Souza
These two patches fix problems on the PCI-E link speed detection.
The first one fixes a regression and adds some improvements on the
code, and the second one adds definitions for Gen3 speeds.
Kleber Sacilotto de Souza (2):
powerpc/pseries: fix regression on PCI link speed
powerpc/pseries: add Gen3 definitions for PCIE link speed
arch/powerpc/platforms/pseries/pci.c | 22 +++++++++++++++-------
1 files changed, 15 insertions(+), 7 deletions(-)
^ permalink raw reply
* Re: [RFC PATCH powerpc] Fix compile error of pgtable-ppc64.h
From: Li Zhong @ 2014-01-17 13:30 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: PowerPC email list, Paul Mackerras
In-Reply-To: <87vbxj6qp1.fsf@linux.vnet.ibm.com>
On Fri, 2014-01-17 at 12:27 +0530, Aneesh Kumar K.V wrote:
> Li Zhong <zhong@linux.vnet.ibm.com> writes:
>
> > It seems that forward declaration couldn't work well with typedef, use
> > struct spinlock directly to avoiding following build errors:
> >
> > In file included from include/linux/spinlock.h:81,
> > from include/linux/seqlock.h:35,
> > from include/linux/time.h:5,
> > from include/uapi/linux/timex.h:56,
> > from include/linux/timex.h:56,
> > from include/linux/sched.h:17,
> > from arch/powerpc/kernel/asm-offsets.c:17:
> > include/linux/spinlock_types.h:76: error: redefinition of typedef 'spinlock_t'
> > /root/linux-next/arch/powerpc/include/asm/pgtable-ppc64.h:563: note: previous declaration of 'spinlock_t' was here
> >
>
> what compiler version ? I have seen that error in gcc 4.3 and it was
> concluded that it is too old a compiler version to worry about. That
> specific compiler version also gave error for forward declaring struct;
gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC), and it doesn't
report error after use struct directly.
>
> > Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
> > ---
> > arch/powerpc/include/asm/pgtable-ppc64.h | 6 +++---
> > 1 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h
> > index d27960c..bc141c9 100644
> > --- a/arch/powerpc/include/asm/pgtable-ppc64.h
> > +++ b/arch/powerpc/include/asm/pgtable-ppc64.h
> > @@ -560,9 +560,9 @@ extern void pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
> > pmd_t *pmdp);
> >
> > #define pmd_move_must_withdraw pmd_move_must_withdraw
> > -typedef struct spinlock spinlock_t;
> > -static inline int pmd_move_must_withdraw(spinlock_t *new_pmd_ptl,
> > - spinlock_t *old_pmd_ptl)
> > +struct spinlock;
> > +static inline int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
> > + struct spinlock *old_pmd_ptl)
> > {
> > /*
> > * Archs like ppc64 use pgtable to store per pmd
^ permalink raw reply
* Re: [PATCH RFC] powerpc/mpc85xx: add support for the kmp204x reference board
From: Valentin Longchamp @ 2014-01-17 12:51 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1389915301.24905.240.camel@snotra.buserror.net>
Hi Scott,
Thanks for you feedback.
On 01/17/2014 12:35 AM, Scott Wood wrote:
> On Thu, 2014-01-16 at 14:38 +0100, Valentin Longchamp wrote:
>> This patch introduces the support for Keymile's kmp204x reference
>> design. This design is based on Freescale's P2040/P2041 SoC.
>>
>> The peripherals used by this design are:
>> - SPI NOR Flash as bootloader medium
>> - NAND Flash with a ubi partition
>> - 2 PCIe busses (hosts 1 and 3)
>> - 3 FMAN Ethernet devices (FMAN1 DTSEC1/2/5)
>> - 4 Local Bus windows, with one dedicated to the QRIO reset/power mgmt
>> FPGA
>> - 2 HW I2C busses
>> - last but not least, the mandatory serial port
>>
>> The patch also adds a defconfig file for this reference design and a DTS
>> file for the kmcoge4 board which is the first one based on this
>> reference design.
>>
>> To try to avoid code duplication, the support was added directly to the
>> corenet_generic.c file.
>>
>> Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
>> ---
>> arch/powerpc/boot/dts/kmcoge4.dts | 165 ++++++++++++++++++
>> arch/powerpc/configs/85xx/kmp204x_defconfig | 231 ++++++++++++++++++++++++++
>> arch/powerpc/platforms/85xx/Kconfig | 14 ++
>> arch/powerpc/platforms/85xx/Makefile | 1 +
>> arch/powerpc/platforms/85xx/corenet_generic.c | 52 ++++++
>> 5 files changed, 463 insertions(+)
>> create mode 100644 arch/powerpc/boot/dts/kmcoge4.dts
>> create mode 100644 arch/powerpc/configs/85xx/kmp204x_defconfig
>>
>> diff --git a/arch/powerpc/boot/dts/kmcoge4.dts b/arch/powerpc/boot/dts/kmcoge4.dts
>> new file mode 100644
>> index 0000000..c10df6d
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/kmcoge4.dts
>> @@ -0,0 +1,165 @@
>> +/*
>> + * Keymile kmcoge4 Device Tree Source, based on the P2041RDB DTS
>> + *
>> + * (C) Copyright 2014
>> + * Valentin Longchamp, Keymile AG, valentin.longchamp@keymile.com
>> + *
>> + * Copyright 2011 Freescale Semiconductor Inc.
>> + *
>> + * 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 of the License, or (at your
>> + * option) any later version.
>> + */
>> +
>> +/include/ "fsl/p2041si-pre.dtsi"
>> +
>> +/ {
>> + model = "keymile,kmcoge4";
>> + compatible = "keymile,kmp204x";
>
> Don't put wildcards in compatible.
Well it's a wildcard in the sense that we support both the p2040 and the p2041,
but it's also the name of the plaftorm, similarly to names like '85xx' or 'tqm85xx'.
>
>> + soc: soc@ffe000000 {
>> + ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
>> + reg = <0xf 0xfe000000 0 0x00001000>;
>> + spi@110000 {
>> + flash@0 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "spansion,s25fl256s1";
>> + reg = <0>;
>> + spi-max-frequency = <20000000>; /* input clock */
>> + partition@u-boot {
>> + label = "u-boot";
>> + reg = <0x00000000 0x00100000>;
>> + read-only;
>> + };
>> + partition@env {
>> + label = "env";
>> + reg = <0x00100000 0x00010000>;
>> + };
>> + partition@envred {
>> + label = "envred";
>> + reg = <0x00110000 0x00010000>;
>> + };
>> + partition@fman {
>> + label = "fman-ucode";
>> + reg = <0x00120000 0x00010000>;
>> + read-only;
>> + };
>> + };
>
> I realize it's common practice, but it would be good to get away from
> putting partition layouts in the dts file. Alternatives include using
> mtdparts on the command line, or having U-Boot put the partition info
> into the dtb based on the mtdparts environment variable (there is
> existing code for this).
I agree that u-boot also has to know about the addresses because it also
accesses these partitions.
But I think it is clearer to have this in the device tree: I try to keep the
kernel command line small and I don't like having u-boot "fixing" the dtb at
runtime.
>
>> + zl30343@1 {
>> + compatible = "gen,spidev";
>
> Node names are supposed to be generic. Compatibles are supposed to be
> specific.
That's a very specific device for which we only have a userspace driver and for
which we must use the generic kernel spidev driver. That's why the node name is
so specific and the compatible field very generic.
>
>> + lbc: localbus@ffe124000 {
>> + reg = <0xf 0xfe124000 0 0x1000>;
>> + ranges = <0 0 0xf 0xffa00000 0x00040000 /* LB 0 */
>> + 1 0 0xf 0xfb000000 0x00010000 /* LB 1 */
>> + 2 0 0xf 0xd0000000 0x10000000 /* LB 2 */
>> + 3 0 0xf 0xe0000000 0x10000000>; /* LB 3 */
>> +
>> + nand@0,0 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "fsl,elbc-fcm-nand";
>> + reg = <0 0 0x40000>;
>> +
>> + partition@0 {
>> + label = "ubi0";
>> + reg = <0x0 0x8000000>;
>> + };
>> + };
>> + };
>
> No nodes for those other chipselects?
Well, there are nodes, but they are internally developed FPGAs and the drivers
are not mainlined that's why I removed the nodes.
>
>> diff --git a/arch/powerpc/configs/85xx/kmp204x_defconfig b/arch/powerpc/configs/85xx/kmp204x_defconfig
>> new file mode 100644
>> index 0000000..3bbf4fa
>> --- /dev/null
>> +++ b/arch/powerpc/configs/85xx/kmp204x_defconfig
>
> Why does this board need its own defconfig?
Apart from the different drivers and FS that we use (or don't use) on the
system, the most notable differences are:
- lowmem must be set to a bigger size so that we can ioremap the the total
memory requested for all of our PCIe devices
- CGROUPS is enabled because that's a mandatory feature for our systems
- NAND_ECC_BCH is enabled because it is used on all of our NAND devices
>
>> diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
>> index fbd871e..8e84e1c 100644
>> --- a/arch/powerpc/platforms/85xx/corenet_generic.c
>> +++ b/arch/powerpc/platforms/85xx/corenet_generic.c
>> @@ -122,6 +122,7 @@ static const char * const hv_boards[] __initconst = {
>> NULL
>> };
>>
>> +#ifdef CONFIG_CORENET_GENERIC
>
> corenet_generic.c without CONFIG_CORENET_GENERIC?
It would be possible with the CONFIG_KMP204X introduced with the patch. But this
is linked with the below discussion.
>
>> /*
>> * Called very early, device-tree isn't unflattened
>> */
>> @@ -180,3 +181,54 @@ machine_arch_initcall(corenet_generic, corenet_gen_publish_devices);
>> #ifdef CONFIG_SWIOTLB
>> machine_arch_initcall(corenet_generic, swiotlb_setup_bus_notifier);
>> #endif
>> +#endif
>> +
>> +#ifdef CONFIG_KMP204X
>> +/*
>> + * Called very early, device-tree isn't unflattened
>> + */
>> +static int __init kmp204x_generic_probe(void)
>> +{
>> + unsigned long root = of_get_flat_dt_root();
>> +
>> + return of_flat_dt_is_compatible(root, "keymile,kmp204x");
>> +}
>> +
>> +
>> +/*
>> + * Setup the architecture
>> + */
>> +void __init kmp204x_gen_setup_arch(void)
>> +{
>> + mpc85xx_smp_init();
>> +
>> + swiotlb_detect_4g();
>> +
>> + pr_info("%s platform from Keymile\n", ppc_md.name);
>> +}
>> +
>> +define_machine(kmp204x) {
>> + .name = "kmp204x",
>> + .probe = kmp204x_generic_probe,
>> + .setup_arch = kmp204x_gen_setup_arch,
>> + .init_IRQ = corenet_gen_pic_init,
>> +#ifdef CONFIG_PCI
>> + .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
>> +#endif
>> + .get_irq = mpic_get_coreint_irq,
>> + .restart = fsl_rstcr_restart,
>> + .calibrate_decr = generic_calibrate_decr,
>> + .progress = udbg_progress,
>> +#ifdef CONFIG_PPC64
>> + .power_save = book3e_idle,
>> +#else
>> + .power_save = e500_idle,
>> +#endif
>> +};
>> +
>> +machine_arch_initcall(kmp204x, corenet_gen_publish_devices);
>> +
>> +#ifdef CONFIG_SWIOTLB
>> +machine_arch_initcall(kmp204x, swiotlb_setup_bus_notifier);
>> +#endif
>> +#endif
>
> The whole point of corenet_generic.c is to avoid duplicating all of this
> stuff.
>
> Can't you just use corenet_generic as-is other than adding the
> compatible to boards[]? If not, explain why and put it in a different
> file.
>
That's a valid point and I have to admit I have hesitated about that. I have
mostly based my work on the FSL SDK where every single board has a "dedicated" file.
I agree that I do nothing different than the corenet_generic does and adding my
platform to the boards[] would be the same and you are right, I should use that
and avoid code duplication.
The only thing that would "bother" me is thus the pr_info print from
*_gen_setup_arch(), it would be nice if somehow we could differentiate it or at
least make it more generic since the kmp204x boards are not strictly boards from
Freescale.
Best regards
Valentin
^ permalink raw reply
* Re: powerpc/hugetlb: BUG: using smp_processor_id() in preemptible
From: Nikita Yushchenko @ 2014-01-17 12:41 UTC (permalink / raw)
To: “tiejun.chen”
Cc: Alexey Lugovskoy, linux-kernel, Paul Mackerras, Aneesh Kumar K.V,
Andrew Morton, linuxppc-dev, Naoya Horiguchi
In-Reply-To: <52D8F960.6030107@windriver.com>
> Could you try this?
>
> powerpc/hugetlb: replace __get_cpu_var with get_cpu_var
>
> Replace __get_cpu_var safely with get_cpu_var to avoid
> the following call trace:
Confirmed, no more acktraces.
Nikita
^ permalink raw reply
* Re: powerpc/hugetlb: BUG: using smp_processor_id() in preemptible
From: "“tiejun.chen”" @ 2014-01-17 9:35 UTC (permalink / raw)
To: Nikita Yushchenko, Benjamin Herrenschmidt, Paul Mackerras,
Aneesh Kumar K.V, Andrew Morton, Naoya Horiguchi, linuxppc-dev,
linux-kernel
Cc: Alexey Lugovskoy
In-Reply-To: <201401171323.52657@blacky.localdomain>
On 01/17/2014 05:23 PM, Nikita Yushchenko wrote:
> Hi
>
> While running LTP hugeltb tests on freescale powerpc board, I'm getting
>
> [ 7253.637591] BUG: using smp_processor_id() in preemptible [00000000 00000000]
> code: hugemmap01/9048
> [ 7253.637601] caller is free_hugepd_range.constprop.25+0x88/0x1a8
> [ 7253.637605] CPU: 1 PID: 9048 Comm: hugemmap01 Not tainted 3.10.20-rt14+ #114
> [ 7253.637606] Call Trace:
> [ 7253.637617] [cb049d80] [c0007ea4] show_stack+0x4c/0x168 (unreliable)
> [ 7253.637624] [cb049dc0] [c031c674] debug_smp_processor_id+0x114/0x134
> [ 7253.637628] [cb049de0] [c0016d28] free_hugepd_range.constprop.25+0x88/0x1a8
> [ 7253.637632] [cb049e00] [c001711c] hugetlb_free_pgd_range+0x6c/0x168
> [ 7253.637639] [cb049e40] [c0117408] free_pgtables+0x12c/0x150
> [ 7253.637646] [cb049e70] [c011ce38] unmap_region+0xa0/0x11c
> [ 7253.637671] [cb049ef0] [c011f03c] do_munmap+0x224/0x3bc
> [ 7253.637676] [cb049f20] [c011f2e0] vm_munmap+0x38/0x5c
> [ 7253.637682] [cb049f40] [c000ef88] ret_from_syscall+0x0/0x3c
> [ 7253.637686] --- Exception: c01 at 0xff16004
>
> This is on 3.10 based kernel but looks like code in question did not change
> since then.
>
> Immediate reason of this dump is usage of smp_processor_id() in hugepd_free(),
> which is executed in preemptible context on this path.
>
> Perhaps need to add preempt_disable() / preempt_enable() somewhere.
> But what is the proper location for these?
>
Could you try this?
powerpc/hugetlb: replace __get_cpu_var with get_cpu_var
Replace __get_cpu_var safely with get_cpu_var to avoid
the following call trace:
[ 7253.637591] BUG: using smp_processor_id() in preemptible [00000000 00000000]
code: hugemmap01/9048
[ 7253.637601] caller is free_hugepd_range.constprop.25+0x88/0x1a8
[ 7253.637605] CPU: 1 PID: 9048 Comm: hugemmap01 Not tainted 3.10.20-rt14+ #114
[ 7253.637606] Call Trace:
[ 7253.637617] [cb049d80] [c0007ea4] show_stack+0x4c/0x168 (unreliable)
[ 7253.637624] [cb049dc0] [c031c674] debug_smp_processor_id+0x114/0x134
[ 7253.637628] [cb049de0] [c0016d28] free_hugepd_range.constprop.25+0x88/0x1a8
[ 7253.637632] [cb049e00] [c001711c] hugetlb_free_pgd_range+0x6c/0x168
[ 7253.637639] [cb049e40] [c0117408] free_pgtables+0x12c/0x150
[ 7253.637646] [cb049e70] [c011ce38] unmap_region+0xa0/0x11c
[ 7253.637671] [cb049ef0] [c011f03c] do_munmap+0x224/0x3bc
[ 7253.637676] [cb049f20] [c011f2e0] vm_munmap+0x38/0x5c
[ 7253.637682] [cb049f40] [c000ef88] ret_from_syscall+0x0/0x3c
[ 7253.637686] --- Exception: c01 at 0xff16004
Signed-off-by: Tiejun Chen<tiejun.chen@windriver.com>
---
arch/powerpc/mm/hugetlbpage.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index fb05b12..42779c0 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -400,12 +400,13 @@ static void hugepd_free(struct mmu_gather *tlb, void *hugepte)
{
struct hugepd_freelist **batchp;
- batchp = &__get_cpu_var(hugepd_freelist_cur);
+ batchp = &get_cpu_var(hugepd_freelist_cur);
if (atomic_read(&tlb->mm->mm_users) < 2 ||
cpumask_equal(mm_cpumask(tlb->mm),
cpumask_of(smp_processor_id()))) {
kmem_cache_free(hugepte_cache, hugepte);
+ put_cpu_var(hugepd_freelist_cur);
return;
}
@@ -419,6 +420,7 @@ static void hugepd_free(struct mmu_gather *tlb, void *hugepte)
call_rcu_sched(&(*batchp)->rcu, hugepd_free_rcu_callback);
*batchp = NULL;
}
+ put_cpu_var(hugepd_freelist_cur);
}
#endif
--
1.7.9.5
Tiejun
>
> Nikita
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
^ permalink raw reply related
* powerpc/hugetlb: BUG: using smp_processor_id() in preemptible
From: Nikita Yushchenko @ 2014-01-17 9:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Aneesh Kumar K.V,
Andrew Morton, Naoya Horiguchi, linuxppc-dev, linux-kernel
Cc: Alexey Lugovskoy
Hi
While running LTP hugeltb tests on freescale powerpc board, I'm getting
[ 7253.637591] BUG: using smp_processor_id() in preemptible [00000000 00000000]
code: hugemmap01/9048
[ 7253.637601] caller is free_hugepd_range.constprop.25+0x88/0x1a8
[ 7253.637605] CPU: 1 PID: 9048 Comm: hugemmap01 Not tainted 3.10.20-rt14+ #114
[ 7253.637606] Call Trace:
[ 7253.637617] [cb049d80] [c0007ea4] show_stack+0x4c/0x168 (unreliable)
[ 7253.637624] [cb049dc0] [c031c674] debug_smp_processor_id+0x114/0x134
[ 7253.637628] [cb049de0] [c0016d28] free_hugepd_range.constprop.25+0x88/0x1a8
[ 7253.637632] [cb049e00] [c001711c] hugetlb_free_pgd_range+0x6c/0x168
[ 7253.637639] [cb049e40] [c0117408] free_pgtables+0x12c/0x150
[ 7253.637646] [cb049e70] [c011ce38] unmap_region+0xa0/0x11c
[ 7253.637671] [cb049ef0] [c011f03c] do_munmap+0x224/0x3bc
[ 7253.637676] [cb049f20] [c011f2e0] vm_munmap+0x38/0x5c
[ 7253.637682] [cb049f40] [c000ef88] ret_from_syscall+0x0/0x3c
[ 7253.637686] --- Exception: c01 at 0xff16004
This is on 3.10 based kernel but looks like code in question did not change
since then.
Immediate reason of this dump is usage of smp_processor_id() in hugepd_free(),
which is executed in preemptible context on this path.
Perhaps need to add preempt_disable() / preempt_enable() somewhere.
But what is the proper location for these?
Nikita
^ permalink raw reply
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