[PATCH] via-pmu: convert to proc_fops/seq_file
Signed-off-by: Alexey Dobriyan
---
drivers/macintosh/via-pmu.c | 160 +---
1 file changed, 91 insertions(+), 69 deletions(-)
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -186,17 +187,11 @@ static int init_pmu(void);
static void pmu_start(void);
static irqreturn_t via_pmu_interrupt(int irq, void *arg);
static irqreturn_t gpio1_interrupt(int irq, void *arg);
-static int proc_get_info(char *page, char **start, off_t off,
- int count, int *eof, void *data);
-static int proc_get_irqstats(char *page, char **start, off_t off,
- int count, int *eof, void *data);
+static const struct file_operations pmu_info_proc_fops;
+static const struct file_operations pmu_irqstats_proc_fops;
static void pmu_pass_intr(unsigned char *data, int len);
-static int proc_get_batt(char *page, char **start, off_t off,
- int count, int *eof, void *data);
-static int proc_read_options(char *page, char **start, off_t off,
- int count, int *eof, void *data);
-static int proc_write_options(struct file *file, const char __user *buffer,
- unsigned long count, void *data);
+static const struct file_operations pmu_battery_proc_fops;
+static const struct file_operations pmu_options_proc_fops;
#ifdef CONFIG_ADB
struct adb_driver via_pmu_driver = {
@@ -507,19 +502,15 @@ static int __init via_pmu_dev_init(void)
for (i=0; iread_proc = proc_read_options;
- proc_pmu_options->write_proc = proc_write_options;
- }
+ proc_pmu_info = proc_create("info", 0, proc_pmu_root,
&pmu_info_proc_fops);
+ proc_pmu_irqstats = proc_create("interrupts", 0, proc_pmu_root,
+ &pmu_irqstats_proc_fops);
+ proc_pmu_options = proc_create("options", 0600, proc_pmu_root,
+ &pmu_options_proc_fops);
}
return 0;
}
@@ -799,27 +790,33 @@ query_battery_state(void)
2, PMU_SMART_BATTERY_STATE, pmu_cur_battery+1);
}
-static int
-proc_get_info(char *page, char **start, off_t off,
- int count, int *eof, void *data)
+static int pmu_info_proc_show(struct seq_file *m, void *v)
{
- char* p = page;
-
- p += sprintf(p, "PMU driver version : %d\n", PMU_DRIVER_VERSION);
- p += sprintf(p, "PMU firmware version : %02x\n", pmu_version);
- p += sprintf(p, "AC Power : %d\n",
+ seq_printf(m, "PMU driver version : %d\n", PMU_DRIVER_VERSION);
+ seq_printf(m, "PMU firmware version : %02x\n", pmu_version);
+ seq_printf(m, "AC Power : %d\n",
((pmu_power_flags & PMU_PWR_AC_PRESENT) != 0) ||
pmu_battery_count == 0);
- p += sprintf(p, "Battery count : %d\n", pmu_battery_count);
+ seq_printf(m, "Battery count : %d\n", pmu_battery_count);
+
+ return 0;
+}
- return p - page;
+static int pmu_info_proc_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, pmu_info_proc_show, NULL);
}
-static int
-proc_get_irqstats(char *page, char **start, off_t off,
- int count, int *eof, void *data)
+static const struct file_operations pmu_info_proc_fops = {
+ .owner = THIS_MODULE,
+ .open = pmu_info_proc_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release= single_release,
+};
+
+static int pmu_irqstats_proc_show(struct seq_file *m, void *v)
{
int i;
- char* p = page;
static const char *irq_names[] = {
"Total CB1 triggered events",
"Total GPIO1 triggered events",
@@ -835,60 +832,76 @@ proc_get_irqstats(char *page, char **start, off_t off,
};
for (i=0; i<11; i++) {
- p += sprintf(p, " %2u: %10u (%s)\n",
+ seq_printf(m, " %2u: %10u (%s)\n",
i, pmu_irq_stats[i], irq_names[i]);
}
- return p - page;
+ return 0;
}
-static int
-proc_get_batt(char *page, char **start, off_t off,
- int count, int *eof, void *data)
+static int pmu_irqstats_proc_open(struct inode *inode, struct file *file)
{
- long batnum = (long)data;
- char *p = page;
+ return single_open(file, pmu_irqstats_proc_show, NULL);
+}
+
+static const struct file_operations pmu_irqstats_proc_fops = {
+ .owner = THIS_MODULE,
+ .open = pmu_irqstats_proc_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release= single_release,
+};
+
+static int pmu_battery_proc_show(struct seq_file *m, void *v)
+{
+ long batnum = (long)m->privat
[PATCH] iseries: convert to proc_fops
Signed-off-by: Alexey Dobriyan
---
arch/powerpc/platforms/iseries/mf.c | 147
1 file changed, 83 insertions(+), 64 deletions(-)
--- a/arch/powerpc/platforms/iseries/mf.c
+++ b/arch/powerpc/platforms/iseries/mf.c
@@ -855,59 +855,58 @@ static int mf_get_boot_rtc(struct rtc_time *tm)
}
#ifdef CONFIG_PROC_FS
-
-static int proc_mf_dump_cmdline(char *page, char **start, off_t off,
- int count, int *eof, void *data)
+static int mf_cmdline_proc_show(struct seq_file *m, void *v)
{
- int len;
- char *p;
+ char *page, *p;
struct vsp_cmd_data vsp_cmd;
int rc;
dma_addr_t dma_addr;
/* The HV appears to return no more than 256 bytes of command line */
- if (off >= 256)
- return 0;
- if ((off + count) > 256)
- count = 256 - off;
+ page = kmalloc(256, GFP_KERNEL);
+ if (!page)
+ return -ENOMEM;
- dma_addr = iseries_hv_map(page, off + count, DMA_FROM_DEVICE);
- if (dma_addr == DMA_ERROR_CODE)
+ dma_addr = iseries_hv_map(page, 256, DMA_FROM_DEVICE);
+ if (dma_addr == DMA_ERROR_CODE) {
+ kfree(page);
return -ENOMEM;
- memset(page, 0, off + count);
+ }
+ memset(page, 0, 256);
memset(&vsp_cmd, 0, sizeof(vsp_cmd));
vsp_cmd.cmd = 33;
vsp_cmd.sub_data.kern.token = dma_addr;
vsp_cmd.sub_data.kern.address_type = HvLpDma_AddressType_TceIndex;
- vsp_cmd.sub_data.kern.side = (u64)data;
- vsp_cmd.sub_data.kern.length = off + count;
+ vsp_cmd.sub_data.kern.side = (u64)m->private;
+ vsp_cmd.sub_data.kern.length = 256;
mb();
rc = signal_vsp_instruction(&vsp_cmd);
- iseries_hv_unmap(dma_addr, off + count, DMA_FROM_DEVICE);
- if (rc)
+ iseries_hv_unmap(dma_addr, 256, DMA_FROM_DEVICE);
+ if (rc) {
+ kfree(page);
return rc;
- if (vsp_cmd.result_code != 0)
+ }
+ if (vsp_cmd.result_code != 0) {
+ kfree(page);
return -ENOMEM;
+ }
p = page;
- len = 0;
- while (len < (off + count)) {
- if ((*p == '\0') || (*p == '\n')) {
- if (*p == '\0')
- *p = '\n';
- p++;
- len++;
- *eof = 1;
+ while (p - page < 256) {
+ if (*p == '\0' || *p == '\n') {
+ *p = '\n';
break;
}
p++;
- len++;
- }
- if (len < off) {
- *eof = 1;
- len = 0;
}
- return len;
+ seq_write(m, page, p - page);
+ kfree(page);
+ return 0;
+}
+
+static int mf_cmdline_proc_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, mf_cmdline_proc_show, PDE(inode)->data);
}
#if 0
@@ -962,10 +961,8 @@ static int proc_mf_dump_vmlinux(char *page, char **start,
off_t off,
}
#endif
-static int proc_mf_dump_side(char *page, char **start, off_t off,
- int count, int *eof, void *data)
+static int mf_side_proc_show(struct seq_file *m, void *v)
{
- int len;
char mf_current_side = ' ';
struct vsp_cmd_data vsp_cmd;
@@ -989,21 +986,17 @@ static int proc_mf_dump_side(char *page, char **start,
off_t off,
}
}
- len = sprintf(page, "%c\n", mf_current_side);
+ seq_printf(m, "%c\n", mf_current_side);
+ return 0;
+}
- if (len <= (off + count))
- *eof = 1;
- *start = page + off;
- len -= off;
- if (len > count)
- len = count;
- if (len < 0)
- len = 0;
- return len;
+static int mf_side_proc_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, mf_side_proc_show, NULL);
}
-static int proc_mf_change_side(struct file *file, const char __user *buffer,
- unsigned long count, void *data)
+static ssize_t mf_side_proc_write(struct file *file, const char __user *buffer,
+ size_t count, loff_t *pos)
{
char side;
u64 newSide;
@@ -1041,6 +1034,15 @@ static int proc_mf_change_side(struct file *file, const
char __user *buffer,
return count;
}
+static const struct file_operations mf_side_proc_fops = {
+ .owner = THIS_MODULE,
+ .open = mf_side_proc_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release= single_release,
+ .write = mf_side_proc_write,
+};
+
#if 0
static void mf_getSrcHistory(char *buffer, int size)
{
@@ -1087,8 +1089,7 @@ static void mf_getSrcHistory(char *buffer, int size)
}
#endif
-static int proc_mf_dump_src(char *page, char **start, off_t off,
- int co
Re: Fix bug in pagetable cache cleanup with CONFIG_PPC_SUBPAGE_PROT (v2)
Oops, stupid compile bug in the !CONFIG_PPC_SUBPAGE_PROT case with the
last version. Fixed below.
Fix bug in pagetable cache cleanup with CONFIG_PPC_SUBPAGE_PROT
Commit a0668cdc154e54bf0c85182e0535eea237d53146 cleans up the handling
of kmem_caches for allocating various levels of pagetables.
Unfortunately, it conflicts badly with CONFIG_PPC_SUBPAGE_PROT, due to
the latter's cleverly hidden technique of adding some extra allocation
space to the top level page directory to store the extra information
it needs.
Since that extra allocation really doesn't fit into the cleaned up
page directory allocating scheme, this patch alters
CONFIG_PPC_SUBPAGE_PROT to instead allocate its struct
subpage_prot_table as part of the mm_context_t.
Signed-off-by: David Gibson
Index: working-2.6/arch/powerpc/include/asm/mmu-hash64.h
===
--- working-2.6.orig/arch/powerpc/include/asm/mmu-hash64.h 2009-11-27
10:40:40.0 +1100
+++ working-2.6/arch/powerpc/include/asm/mmu-hash64.h 2009-11-27
15:54:27.423721648 +1100
@@ -373,6 +373,38 @@ extern void slb_set_size(u16 size);
#ifndef __ASSEMBLY__
+#ifdef CONFIG_PPC_SUBPAGE_PROT
+/*
+ * For the sub-page protection option, we extend the PGD with one of
+ * these. Basically we have a 3-level tree, with the top level being
+ * the protptrs array. To optimize speed and memory consumption when
+ * only addresses < 4GB are being protected, pointers to the first
+ * four pages of sub-page protection words are stored in the low_prot
+ * array.
+ * Each page of sub-page protection words protects 1GB (4 bytes
+ * protects 64k). For the 3-level tree, each page of pointers then
+ * protects 8TB.
+ */
+struct subpage_prot_table {
+ unsigned long maxaddr; /* only addresses < this are protected */
+ unsigned int **protptrs[2];
+ unsigned int *low_prot[4];
+};
+
+#define SBP_L1_BITS(PAGE_SHIFT - 2)
+#define SBP_L2_BITS(PAGE_SHIFT - 3)
+#define SBP_L1_COUNT (1 << SBP_L1_BITS)
+#define SBP_L2_COUNT (1 << SBP_L2_BITS)
+#define SBP_L2_SHIFT (PAGE_SHIFT + SBP_L1_BITS)
+#define SBP_L3_SHIFT (SBP_L2_SHIFT + SBP_L2_BITS)
+
+extern void subpage_prot_free(struct mm_struct *mm);
+extern void subpage_prot_init_new_context(struct mm_struct *mm);
+#else
+static inline void subpage_prot_free(struct mm_struct *mm) {}
+static inline void subpage_prot_init_new_context(struct mm_struct *mm) { }
+#endif /* CONFIG_PPC_SUBPAGE_PROT */
+
typedef unsigned long mm_context_id_t;
typedef struct {
@@ -386,6 +418,9 @@ typedef struct {
u16 sllp; /* SLB page size encoding */
#endif
unsigned long vdso_base;
+#ifdef CONFIG_PPC_SUBPAGE_PROT
+ struct subpage_prot_table spt;
+#endif /* CONFIG_PPC_SUBPAGE_PROT */
} mm_context_t;
Index: working-2.6/arch/powerpc/include/asm/pgalloc-64.h
===
--- working-2.6.orig/arch/powerpc/include/asm/pgalloc-64.h 2009-11-27
10:40:40.0 +1100
+++ working-2.6/arch/powerpc/include/asm/pgalloc-64.h 2009-11-27
10:55:00.654766147 +1100
@@ -28,10 +28,6 @@
*/
#define MAX_PGTABLE_INDEX_SIZE 0xf
-#ifndef CONFIG_PPC_SUBPAGE_PROT
-static inline void subpage_prot_free(pgd_t *pgd) {}
-#endif
-
extern struct kmem_cache *pgtable_cache[];
#define PGT_CACHE(shift) (pgtable_cache[(shift)-1])
@@ -42,7 +38,6 @@ static inline pgd_t *pgd_alloc(struct mm
static inline void pgd_free(struct mm_struct *mm, pgd_t *pgd)
{
- subpage_prot_free(pgd);
kmem_cache_free(PGT_CACHE(PGD_INDEX_SIZE), pgd);
}
Index: working-2.6/arch/powerpc/include/asm/pte-hash64-64k.h
===
--- working-2.6.orig/arch/powerpc/include/asm/pte-hash64-64k.h 2009-11-17
11:55:00.0 +1100
+++ working-2.6/arch/powerpc/include/asm/pte-hash64-64k.h 2009-11-27
10:55:00.654766147 +1100
@@ -76,41 +76,4 @@
remap_pfn_range((vma), (addr), (pfn), PAGE_SIZE,\
__pgprot(pgprot_val((prot)) | _PAGE_4K_PFN))
-
-#ifdef CONFIG_PPC_SUBPAGE_PROT
-/*
- * For the sub-page protection option, we extend the PGD with one of
- * these. Basically we have a 3-level tree, with the top level being
- * the protptrs array. To optimize speed and memory consumption when
- * only addresses < 4GB are being protected, pointers to the first
- * four pages of sub-page protection words are stored in the low_prot
- * array.
- * Each page of sub-page protection words protects 1GB (4 bytes
- * protects 64k). For the 3-level tree, each page of pointers then
- * protects 8TB.
- */
-struct subpage_prot_table {
- unsigned long maxaddr; /* only addresses < this are protected */
- unsigned int **protptrs[2];
- unsigned int *low_prot[4];
-};
-
-#undef PGD_TABLE_SIZE
-#define PGD_TABLE_SIZE ((sizeof(pgd_t) << PGD_INDEX_SIZE) + \
-
Re: [PATCH 0/4] powerpc: Fix minor build issues on 2.6.32-rc7 without CONFIG_XICS set
On Wed, 2009-11-18 at 17:05 +, Mel Gorman wrote: > > diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig > index 04a8061..a82c470 100644 > --- a/arch/powerpc/platforms/Kconfig > +++ b/arch/powerpc/platforms/Kconfig > @@ -52,9 +52,9 @@ config PPC_UDBG_BEAT > default n > > config XICS > - depends on PPC_PSERIES > + depends on PCI_MSI > bool > - default y > + default n Why the above ? XICS only exist on PSERIES and select bypass depends in nasty ways anyways. > config IPIC > bool > diff --git a/arch/powerpc/platforms/pseries/Kconfig > b/arch/powerpc/platforms/pseries/Kconfig > index f0e6f28..81c2289 100644 > --- a/arch/powerpc/platforms/pseries/Kconfig > +++ b/arch/powerpc/platforms/pseries/Kconfig > @@ -5,6 +5,8 @@ config PPC_PSERIES > select PPC_I8259 > select PPC_RTAS > select RTAS_ERROR_LOGGING > + select PCI_MSI > + select XICS > select PPC_UDBG_16550 > select PPC_NATIVE > select PPC_PCI_CHOICE if EMBEDDED The above bits look plenty enough. Can you also stick it next to the MPIC one ? Cheers, Ben. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mm: honor O_SYNC flag for memory mapping
Li Yang writes: > There was no way to set mapped memory as cacheable if the memory > is not managed by Linux kernel. It's not rare in real system to > allocate some dedicated memory to a certain application which is not > managed by kernel and then mmap'ed the memory to the application. > The memory should be cacheable but we can't map it to be cacheable > due to the intelligent setting of cacheability. > > The patch makes the cacheability depend on O_SYNC flag of the file > mapped for non-kernel managed memory. Also prints a deprecation > warning for mmap users without using O_SYNC. NAK, since it is an incompatible change to the kernel ABI. What sort of memory is this that you want to map as cacheable? Is it normal system RAM that your platform code reserves, or is it some other kind of memory? If it's the normal system RAM, you could make phys_mem_access_prot() smart enough to recognize that (by looking in the lmb array or the device tree). If it's another kind of memory, it should be described in the device tree, and you could have a platform-specific phys_mem_access_prot function for your platform that looks in the device tree to see if the memory being mapped is this special sort of memory. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] powerpc/mm: honor O_SYNC flag for memory map
Li Yang writes: > That's my concern too. But after all mmap without O_SYNC on I/O > devices should be deprecated. It should? Why? Shouldn't the onus rather be on those proposing an incompatible change to the kernel ABI, such as this is, to show why the change is absolutely essential? > A warning message in deprecation period > could reduce potential problem caused by this change. Not making the change at all would reduce the potential problems even further. :) Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 04/19] powerpc: wii: device tree
On Fri, 2009-11-27 at 01:16 +0100, Segher Boessenkool wrote: > > In all code I have done for the XFB, I map it like any other RAM and > dcbst it after writing to it. Maybe that is slower though, WIMG=0100 > might be better. Dunno. Well, it depends also what you want to do with it. If you want to expose it as a standard linux fbdev, it might break apps to expect them to use dcbst... but it will make rmw cycles a lot faster and avoid wasting memory with shadowfb. It's going to mostly depend on what kind of HW accel we can get out of it, if we get good enough accel we can probably got for I=1 like a standard fb Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 02/19] powerpc: gamecube: device tree
If you have only one interrupt controller, like here, you don't need to refer to it _at all_ :-) I think Linux requires that you do though. It might be a mistake on our part but heh ... Linux doesn't require it; (old) Macs are like this, for example, and that works fine. Oh and all Maple firmwares are like that as well I think. Etc. It works fine on old macs thanks to a quirk we enable in the mac code iirc and old maple works thanks to mere luck with the fallback code we have which reads things of PCI config space :-) Don't rely on that. It is standard OF. Let's fix the Linux code if that is needed (and I don't think it is, anyway). OTOH, it's nice to use the interrupt mapping stuff in all new device trees. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 04/19] powerpc: wii: device tree
Yup. The idea is to map the first 16MB of MEM1 with a BAT. Mapping the whole 24MB with BATs may not be possible because we want the framebuffer in MEM1 for performance reasons. How big is the fb ? A bit more than a megabyte, something like that. We have plenty of BATs on these things... so one 16M for the low mem and one 64M for the "high" mem, that leaves something like 6 to manage as much as possible up to the fb :-) The CXe in the gamecube has only four BATs though. In all code I have done for the XFB, I map it like any other RAM and dcbst it after writing to it. Maybe that is slower though, WIMG=0100 might be better. Dunno. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 12/19] powerpc: gamecube: platform support
We need it as it currently doesn't match with the default bus ids. Should I introduce a .type property matching any of those above in the soc node, and get rid of the explicit bus probe? You don't need any fake bus as far as I can see, just probe the devices you want. But it's way easier to let the bus probe do it for us. I don't see the win here. As long as this doesn't leak into the device tree in any way, I don't care. How's that? :-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support
Maybe using FLIPPER (or GAMECUBE_FLIPPER) instead of GAMECUBE_COMMON is a good name? I'd prefer to not use a name that implies a specific hardware to describe two (mostly) similar but different hardwares. Hollywood is 100% compatible to Flipper though. No. There's no ARAM for example :) ARAM is an external device. +/* + * Each interrupt has a corresponding bit in both + * the Interrupt Cause (ICR) and Interrupt Mask (IMR) registers. + * + * Enabling/disabling an interrupt line involves asserting/ clearing + * the corresponding bit in IMR. ACK'ing a request simply involves + * asserting the corresponding bit in ICR. + */ I looked it up in YAGCD; it says that _reading_ the ICR reg already acks all interrupts (and clears the bits), you never write this reg! YAGCD is not always right. You should not take it as _the truth_. Oh I know. But I have no better source of information. Well I could actually test it, that's very easy using OF :-) Let's do that. No, it acks just a single IRQ. No it doesn't. Say IRQs 1 and 3 are asserted, so the reg contains 0x0a. Now you want to ack IRQ1; set_bit() will write 0x0a | 0x02, not just 0x02. Let me rephrase it. No it should just ack a single IRQ :) So then this is working by accident. If that's the case, I guess it works because the interrupt is not cleared at the source and the ICR is set again immediately for any pending interrupt? Probably, yes. Also, you will not often have more than one interrupt pending anyway (on the legacy PIC). Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support
On Fri, 2009-11-27 at 00:00 +0100, Segher Boessenkool wrote:
> >>> +unsigned int flipper_pic_get_irq(void)
> >>> +{
> >>> + void __iomem *io_base = flipper_irq_host->host_data;
> >>> + int irq;
> >>> + u32 irq_status;
> >>> +
> >>> + irq_status = in_be32(io_base + FLIPPER_ICR) &
> >>> +in_be32(io_base + FLIPPER_IMR);
> >>> + if (irq_status == 0)
> >>> + return -1; /* no more IRQs pending */
> >>
> >> NO_IRQ_IGNORE
> >
> > Why no just 0 ? (aka NO_IRQ)
> >
> > Or do you know you are getting lots of spurrious that you don't
> > want to
> > account ?
>
> IRQ #0 is a valid IRQ here (graphics error IIRC), it should be
> remapped I suppose?
All interrupts are remapped. _get_irq() should call the appropriate
revmap function to remap the HW number into a linux number. 0 is never a
valid linux number and means "no interrupt".
In the above case, it would seem to me that what he gets is a bitfield
so 0 means no interrupt. Hence the code should be:
if (irq_status == 0)
return 0;
Then, find first bit and return the linear revmap... Just look at what
the old pmac_pic does, same stuff basically.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 04/11] of/flattree: eliminate cell_t typedef
From: Segher Boessenkool Date: Thu, 26 Nov 2009 22:36:41 +0100 >>> You're right, it's not, but makes merging less complex, and then I can >>> refactor properly. >> >> Still, make them __be32 at least > > There is no alignment guarantee at all either, better make it all u8 > and use accessor functions everywhere. I think that might be overkill. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 10/19] powerpc: gamecube/wii: early debugging using usbgecko
On Thu, 2009-11-26 at 23:54 +0100, Segher Boessenkool wrote: > No Ben. The whole point of EARLY_DEBUG is that it _always works_, > because > it is such trivial code. Don't break that please, or we'll be forced to > add a "REALLY_EARLY_DEBUG" instead :-) I do tend to agree but heh... temptation to do more cute hacks ... :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 04/19] powerpc: wii: device tree
There you can find the hardware interface that supports the IPC mechanism. It is made up of a pair of registers to pass data between the processors and a pair of control/flags registers. The hardware can interrupt the PowerPC side when there is data available for it. Ok. So the right way to do that would be to have a node purely representing the HW IPC, unrelated to whatever is running on the secondary processor. Or you can keep it implicit in the Hollywood control registers. It is one 512-byte block with lots of things thrown together (and then mixed up real good). However, it's ok to have -below- that node, a set of device nodes or a node with properties or whatever representing the FW in there and the function it exposes. That's not really useful though, it's easy to probe for. What might do however is to have a way for that FW itself to provide you with the nodes and properties for the functions it provides :-) You get a pointer at the very last word of memory. It point to an info header that has everything you need to know (most importantly, a version identifier). Of course that wouldn't work with FW we don't have control on. Can Linux run on the wii with the original N. FW on the aux. processor ? It _can_, but there are no advantages to doing that, and lots and lots of disadvantages, so the plan is to not add support for that in mainline. Can we detect what is running there ? Do we care ? You can detect this for anything that uses a mini-compatible interface. You shouldn't care for anything else ;-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 04/19] powerpc: wii: device tree
They are a bit special because registers are in reverse little endian format, must be written in 32-bit chunks, and (all things point to) they have hardware bugs. Well.. first what is "reverse little endian" ? :-) Big endian ? Nah. Little-endian, with a 32-bit bus swizzle. This is not the same thing as big-endian when not all your registers are 32 bits. Also, you can only write 32 bits, they don't use byte enables. As for HW bugs, well, as long as we know them we can define a quirk bit and add the necessary workarounds to the driver :-) The question is if the device is close enough to OHCI to declare it as that in the device tree. I would say "yes". Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 09/19] powerpc: gamecube/wii: udbg support for usbgecko
The usbgecko is hotplugable and hotswappable. But as this is mostly a developer feature, not normaly used by end users, I think that we can just let it be as it is: autodetect it on boot (now probing for it instead of using information from the device tree). If you unplug it later it causes no errors, you just miss whatever data is sent to it. You can get interrupts when an EXI device is plugged or unplugged; the "normal" driver should use that. But you haven't posted that yet. The "early debug" driver can just assume the user doesn't like to hurt himself, and provide pain when the user does, there's no problem with that :-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 04/19] powerpc: wii: device tree
Segher Boessenkool wrote:
>> So what is at d000 ?
>
> 0c00 is the flipper-compatible stuff
> 0d00 is the hollywood new devices
> 0d80 is the same as part of 0d00, but with some extra bits
> sometimes.
>
Also, when in Wii native mode, stuff like EXI, SI and AI (which is
flipper-compatible stuff too) is available at 0d00 only.
+ser...@0d006400 {
+compatible = "nintendo,hollywood-serial";
>>>
>>> You might want to pick a more descriptive name for this,
>>> "serial" is usually understaood to mean "RS232". Which
>>> this isn't.
>>
>> What is it then ? You definitely want some other name if it's not
>> classic rs232 style serial.
>
> It's SPI I think, with some extra signals. It's the gamepads mostly.
>
EXI is SPI.
But SI is a different thingy.
See http://www.int03.co.uk/crema/hardware/gamecube/gc-control.htm .
>
> Segher
>
>
Cheers,
Albert
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 03/19] powerpc: gamecube: bootwrapper bits
Sure, the memory controllers don't do coherency. I'm slightly worried about two things: 1) Will the generic code use M=0 as well? Is it a problem if it doesn't? We can make it not do it. 2) Do lwarx. etc. work in M=0? They should hopefully... as long as you don't rely on the reservation blowing as a result of a DMA write. Hmm, this really depends on whether the DMA transfers generate bus cycles that require coherency or not. They do not; device DMA never goes to the 6xx bus with this bridge. Not the other way around. M=1 only forces bus cycles to be snooped by other processors (asserting the GBL signal on 603/604/750 busses). Right, it enables sending probes, not receiving them. On this CPU anyway. The architecture specification is quite silent on this all. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 16/19] powerpc: wii: hollywood interrupt controller support
+static void hlwd_pic_mask_and_ack(unsigned int virq)
+{
+ int irq = virq_to_hw(virq);
+ void __iomem *io_base = get_irq_chip_data(virq);
+
+ clear_bit(irq, io_base + HW_BROADWAY_IMR);
+ set_bit(irq, io_base + HW_BROADWAY_ICR);
+}
Same comment as with flipper. BTW. It looks really similar, can't you
use the same driver ?
No, they aren't actually similar; the old PIC acks when the status reg
is read, the new PIC acks when you write a 1. Also, the new PIC has
more registers, it is an interrupt controller for the ARM as well. Not
that we use it, but still.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support
+unsigned int flipper_pic_get_irq(void)
+{
+ void __iomem *io_base = flipper_irq_host->host_data;
+ int irq;
+ u32 irq_status;
+
+ irq_status = in_be32(io_base + FLIPPER_ICR) &
+in_be32(io_base + FLIPPER_IMR);
+ if (irq_status == 0)
+ return -1; /* no more IRQs pending */
NO_IRQ_IGNORE
Why no just 0 ? (aka NO_IRQ)
Or do you know you are getting lots of spurrious that you don't
want to
account ?
IRQ #0 is a valid IRQ here (graphics error IIRC), it should be
remapped I suppose?
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 10/19] powerpc: gamecube/wii: early debugging using usbgecko
This will probably break other platforms if CONFIG_PPC_EARLY_DEBUG_USBGECKO is set. In general, we try hard to make it possible to build generic kernels for multiple systems, so it would be better to also add a runtime check here. No Arnd. The whole point of EARLY_DEBUG is that it is -known- to break other platforms :-) So that we can use it before we even get to probe anything. I am still tempted, one day, to change the kernel early init to setup a stack in .bss and go straight to C to do that sort of stuff by parsing the flat DT, this could be done using pretty much completely generic code :-) But not right now. No Ben. The whole point of EARLY_DEBUG is that it _always works_, because it is such trivial code. Don't break that please, or we'll be forced to add a "REALLY_EARLY_DEBUG" instead :-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 04/19] powerpc: wii: device tree
BTW. If we want to play with clocks, maybe you should look at
my proposed binding for clocks and implementing the clk API :-)
There are no clocks that are configurable from the PowerPC side
(well, maybe things like the USB clocks, but we do not know how).
+ /* Team Twiizers' 'mini' firmware IPC */
+ m...@0d00 {
Although mini is awesome, it isn't hardware, and doesn't
belong in the device tree.
So what is at d000 ?
0c00 is the flipper-compatible stuff
0d00 is the hollywood new devices
0d80 is the same as part of 0d00, but with some extra bits
sometimes.
+ ser...@0d006400 {
+ compatible = "nintendo,hollywood-serial";
You might want to pick a more descriptive name for this,
"serial" is usually understaood to mean "RS232". Which
this isn't.
What is it then ? You definitely want some other name if it's not
classic rs232 style serial.
It's SPI I think, with some extra signals. It's the gamepads mostly.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 02/19] powerpc: gamecube: device tree
On Thu, 2009-11-26 at 23:15 +0100, Segher Boessenkool wrote: > >> If you have only one interrupt controller, like here, you don't > >> need to refer to it _at all_ :-) > > > > I think Linux requires that you do though. It might be a mistake on > > our > > part but heh ... > > Linux doesn't require it; (old) Macs are like this, for example, > and that works fine. Oh and all Maple firmwares are like that as > well I think. Etc. It works fine on old macs thanks to a quirk we enable in the mac code iirc and old maple works thanks to mere luck with the fallback code we have which reads things of PCI config space :-) Don't rely on that. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 04/19] powerpc: wii: device tree
+/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O
area) */
+/memreserve/ 0x1000 0x0004000; /* DSP RAM */
Weird layout... nothing you can do about I suppose.
Out of curiosity, what is that DSP RAM ? Some actual DSP core
somewhere
in the IO chip setup to use memory from up there ?
It's an actual DSP yes, and it seems it uses that fixed address range
(at the start of the 64MB GDDR3 memory) always. So we have to stay
away from that memory range.
+ memory {
+ device_type = "memory";
+ /* MEM1 + memory hole + MEM2 - firmware/buffers area */
+ reg = <0x 0x133e>;
+ };
So we do have a nasty hole here in the middle. How bad it is if you
try
to just have two ranges in there (ie as if it was discontiguous) ?
Not bad at all. There is no "as if" -- it _is_ discontiguous memory,
they are totally different memory technology even.
+ /* Team Twiizers' 'mini' firmware IPC */
Out of curiosity, what are these ? :-)
There is an embedded ARM9 in the Hollywood. It is "the boss" of the
system, not the PowerPC. "mini" is the name of the code we run on it.
There is a hardware IPC interface between the ARM and the PowerPC (just
a bunch of doorbells and general purpose regs).
Similar comment as before, could the above be dynamically probed ? If
you are not a hacker you may not need that at all to use some linux
based piece of SW on the wii right ?
Yeah. Well, after any other drivers have been merged, anyway, heh :-)
+ oh...@0d06 {
Why the "1" ?
Right, call them both just "ohci" please. Or "usb" even.
+ PIC1: p...@0d800030 {
+ #interrupt-cells = <1>;
+ compatible = "nintendo,hollywood-pic";
+ reg = <0x0d800030 0x8>;
+ interrupt-controller;
+ interrupts = <14>;
+ interrupt-parent = <&PIC0>;
+ };
Ah, a cascaded PIC, fun fun fun
Well at least this cascaded PIC is sane, the root PIC is less so :-P
+ hollywood-ahbp...@0d800064 {
+ compatible = "nintendo,hollywood-ahbprot";
+ reg = <0x0d800064 0x4>;
+ };
What is this ?
Most of the devices new in Hollywood (AES engine, NAND engine, USB,
SD, etc.) sit on an AHB bus. The AHBPROT register is used to configure
which of these can be accessed from the PowerPC.
Modern "mini" always gives us full control. Also, there is no reason
to single out the AHBPROT reg in the device tree like this, anyway.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 04/19] powerpc: wii: device tree
On Thu, 2009-11-26 at 22:38 +0100, Albert Herranz wrote: > Yup. The idea is to map the first 16MB of MEM1 with a BAT. > Mapping the whole 24MB with BATs may not be possible because we want the > framebuffer > in MEM1 for performance reasons. How big is the fb ? We have plenty of BATs on these things... so one 16M for the low mem and one 64M for the "high" mem, that leaves something like 6 to manage as much as possible up to the fb :-) Let's keep 1 or 2 for debug and maybe even BAT map the fb itself, we still are quite comfortable :-) That reminds me we still need to re-introduce a clean version of io_block_mapping (or ioremap flag that does the same) so the platform code can establish a BAT mapping for a whole bunch of IOs and ioremap transparenty picks addresses in there. We used to do it, dropped it mostly because it was done badly (virtual address was hard coded which caused all sorts of issues) but it shouldn't be hard to do it right and it would improve perfs a little bit more. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 02/19] powerpc: gamecube: device tree
+ soc {
It would be better to rename this as IMMR or the bus type. This node
doesn't actually describe the entire chip, but describes the internal
memory mapped registers.
I would really just call it "flipper" :-)
Yeah, I came to the same conclusion.
Since you're only doing 1:1 mappings; you could replace this with an
empty "ranges;" property instead.
On the other hand it is a useful "documentation" to specify the exact
range decoded when you know it :-)
Not the "decoded" range in this case, that is 0..4G :-) The "canonical"
ranges is nice doc, yes.
Hint: If you move the interrupt-parent property up to the root node,
then you don't need to specify it in every single device node; it
will
just inherit from the parent.
Note that this is a linux-ism no ? (aka ePAPRism).
Nope, it is from the standard interrupt mapping recommended practice.
It is fine.
If they aim toward having a real OF which I think they do
We do.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 03/19] powerpc: gamecube: bootwrapper bits
So what's your proposal then? Placing it within a fake func? Just do a .S file :-) Yeah. You might be able to do one that handles both GC and Wii, maybe it's easier/clearer to keep them separate though. Ouch. I wouldn't be surprised if those guys don't do cache coherency in the bridge anyways. That is correct; we haven't found any way to enable it, at least. To be fair, it's actually better for performance to _not_ do RAM coherency when used as a game system. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 02/19] powerpc: gamecube: device tree
+ xfb-start = <0x01698000>; /* end-of-ram - xfb-size */
+ xfb-size = <0x168000>;
XFB address isn't fixed on the hardware, and the kernel might
want to move it, and you can easily probe for it anyway. Remove
these last two properties please.
Ok but you need to know what it was setup to by the FW no ? To avoid
having a temporary display "glitch" while booting... Also on a 24M
config,it might get tough for the driver to allocate 2M contiguous
like
that if it's done late in the boot process.
Sure, the platform code will have to probe this very early. Can always
do the /memreserve/ if really needed.
+ aux...@0c005000 {
+ compatible = "nintendo,flipper-auxram";
+ reg = <0x0c005000 0x200>; /* DSP */
+ interrupts = <6>;
+ interrupt-parent = <&pic>;
+ };
+
+ au...@0c005000 {
+ compatible = "nintendo,flipper-audio";
+ reg = <0x0c005000 0x200 /* DSP */
+ 0x0c006c00 0x20>; /* AI */
+ interrupts = <6>;
+ interrupt-parent = <&pic>;
+ };
These two have the same address, not good. Just remove the
auxram node?
Or make it a child of audio ? :-)
Hrm, actually, DSP and AI should be separate nodes, and ARAM a child
of DSP (on its own bus, so it can show that it is 16MB etc.)
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 02/19] powerpc: gamecube: device tree
If you have only one interrupt controller, like here, you don't need to refer to it _at all_ :-) I think Linux requires that you do though. It might be a mistake on our part but heh ... Linux doesn't require it; (old) Macs are like this, for example, and that works fine. Oh and all Maple firmwares are like that as well I think. Etc. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 12/19] powerpc: gamecube: platform support
Segher Boessenkool wrote: >> We need it as it currently doesn't match with the default bus ids. > >> Should I introduce a .type property matching any of those above in the >> soc node, and get rid of the explicit bus probe? > > You don't need any fake bus as far as I can see, just probe the devices > you want. > But it's way easier to let the bus probe do it for us. I don't see the win here. > > Segher > > Thanks, Albert ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support
Segher Boessenkool wrote:
>>> Maybe using FLIPPER (or GAMECUBE_FLIPPER) instead of GAMECUBE_COMMON
>>> is a good name?
>>
>> I'd prefer to not use a name that implies a specific hardware to
>> describe two (mostly) similar but different hardwares.
>
> Hollywood is 100% compatible to Flipper though.
>
No. There's no ARAM for example :)
+/*
+ * Each interrupt has a corresponding bit in both
+ * the Interrupt Cause (ICR) and Interrupt Mask (IMR) registers.
+ *
+ * Enabling/disabling an interrupt line involves asserting/clearing
+ * the corresponding bit in IMR. ACK'ing a request simply involves
+ * asserting the corresponding bit in ICR.
+ */
>
> I looked it up in YAGCD; it says that _reading_ the ICR reg already
> acks all interrupts (and clears the bits), you never write this reg!
>
YAGCD is not always right. You should not take it as _the truth_.
I'm not telling this is the case. But I don't recall such behavior. It's been a
long time since this is done this way.
+static void flipper_pic_ack(unsigned int virq)
+{
+int irq = virq_to_hw(virq);
+void __iomem *io_base = get_irq_chip_data(virq);
+
+set_bit(irq, io_base + FLIPPER_ICR);
+}
>>>
>>> So it should be a simple write instead of an RMW here, right?
>>> As it is you are ACKing _all_ IRQs as far as I can see.
>>>
>>
>> No, it acks just a single IRQ.
>
> No it doesn't. Say IRQs 1 and 3 are asserted, so the reg contains 0x0a.
> Now you want to ack IRQ1; set_bit() will write 0x0a | 0x02, not just 0x02.
>
Let me rephrase it. No it should just ack a single IRQ :)
So then this is working by accident.
If that's the case, I guess it works because the interrupt is not cleared at
the source and the ICR is set again immediately for any pending interrupt?
>
> Segher
>
>
Thanks,
Albert
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 18/19] powerpc: wii: platform support
+#ifdef CONFIG_STARLET_MINI
+
+#define HW_RESETS_OF_COMPATIBLE"nintendo,hollywood-resets"
+#define HW_GPIO_ALIAS"hw_gpio
This should be unconditional now I think? You access the hardware
directly.
Yes, at this stage direct hardware should be possible, but only if
'mini' support is compiled-in (which will be the default option at
this stage).
We can either leave the conditionals as is now, or remove them and
add them later if we support more than one firmware flavour.
I'm fine with both options.
Removing all superfluous code is best in my opinion.
+np = of_find_node_by_name(NULL, "aliases");
+if (!np) {
+pr_err("unable to find node %s\n", "aliases");
+goto out;
+}
+
+path = of_get_property(np, HW_GPIO_ALIAS, NULL);
+of_node_put(np);
+if (!path) {
+pr_err("alias %s unknown\n", HW_GPIO_ALIAS);
+goto out;
+}
Don't use an alias here, search for e.g. a matching "compatible"
instead.
I used an alias because I wanted explicitly the second GPIO word.
Is there another way to select a specific instance of repeated
identical hardware?
Yes, probe for it with its address. There is no guarantee in which
order
you will get them.
We have two instances of gpios here, matching the same "compatible".
It's a pain in the behind that the GPIO binding will not allow you to
show the two GPIO regs as one controller, which it is. Or can it
actually do that?
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PPC: Sync guest visible MMU state
Am 26.11.2009 um 16:24 schrieb Alexander Graf :
Currently userspace has no chance to find out which virtual address
space we're
in and resolve addresses. While that is a big problem for migration,
it's also
unpleasent when debugging, as gdb and the monitor don't work on
virtual
addresses.
This patch exports enough of the MMU segment state to userspace to
make
debugging work and thus also includes the groundwork for migration.
Signed-off-by: Alexander Graf
---
Ben, please take this patch in your tree.
v2 -> v3:
- don't use anonymous unions/structs
---
arch/powerpc/include/asm/kvm.h| 20 +++-
arch/powerpc/include/asm/kvm_asm.h |1 +
arch/powerpc/include/asm/kvm_book3s.h |3 ++
arch/powerpc/kvm/book3s.c | 53
+++-
arch/powerpc/kvm/book3s_64_emulate.c | 38 ++-
arch/powerpc/kvm/book3s_64_mmu.c |2 +
arch/powerpc/kvm/powerpc.c|3 ++
include/linux/kvm.h |3 ++
8 files changed, 104 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/
asm/kvm.h
index c9ca97f..cb6ad08 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -46,8 +46,24 @@ struct kvm_regs {
};
struct kvm_sregs {
-__u32 pvr;
-char pad[1020];
+union {
+struct {
+__u32 pvr;
Meh this breaks old userspace. Better patch following tomorrow.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 17/19] powerpc: wii: bootmii starlet 'mini' firmware support
Add support for the BootMii 'mini' firmware replacement for the
Starlet processor.
'mini' is an open source IOS replacement written from scratch by
Team Twiizers.
It's not a replacement, it doesn't have any of the same
functionality.
I didn't know 'replacement' had that semantics.
It's ambiguous.
My intention was to say that 'mini' firmware is an alternative to
the stock IOS firmware, not trying to imply that it behaves like it
or it is compatible with it.
Point taken.
I'll use 'mini' alternate firmware if that's ok.
"Alternative firmware" is fine.
+enum starlet_ipc_flavour {
+STARLET_IPC_IOS,
+STARLET_IPC_MINI,
+};
I thought you don't support IOS at all anymore?
I don't plan to mainline IOS support.
But to make runtime decisions I need to know if we are running
along the 'mini' firmware or the default IOS firmware.
That's the intention of that enum.
Modern mini will always have AHBPROT set up to give you full access,
so this isn't needed either.
So we have two options here:
- assume that whatever firmware is running properly sets AHBPROT
and hope it works
- or try to use the existing firmware interfaces to check and make
sure that AHBPROT is indeed properly set
I chose the second option here.
It is much much simpler to simply require a new enough mini :-)
Do you need this driver to boot? If not, it might be best to
leave it
out for now.
Strictly speaking, we don't need the driver to boot if we asume
that AHBPROT is properly set.
But we'll need it later to shutdown 'mini' drivers, unless 'mini'
is changed to boot PowerPC code with all hardware already
relinquished.
That is not true for the last available version of 'mini' firmware.
That version still boots PowerPC code with at least the SDHCI
controller driven by 'mini'.
I'll fix this.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 12/19] powerpc: gamecube: platform support
We need it as it currently doesn't match with the default bus ids. Should I introduce a .type property matching any of those above in the soc node, and get rid of the explicit bus probe? You don't need any fake bus as far as I can see, just probe the devices you want. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support
Maybe using FLIPPER (or GAMECUBE_FLIPPER) instead of GAMECUBE_COMMON
is a good name?
I'd prefer to not use a name that implies a specific hardware to
describe two (mostly) similar but different hardwares.
Hollywood is 100% compatible to Flipper though.
+/*
+ * Each interrupt has a corresponding bit in both
+ * the Interrupt Cause (ICR) and Interrupt Mask (IMR) registers.
+ *
+ * Enabling/disabling an interrupt line involves asserting/clearing
+ * the corresponding bit in IMR. ACK'ing a request simply involves
+ * asserting the corresponding bit in ICR.
+ */
I looked it up in YAGCD; it says that _reading_ the ICR reg already
acks all interrupts (and clears the bits), you never write this reg!
+static void flipper_pic_ack(unsigned int virq)
+{
+int irq = virq_to_hw(virq);
+void __iomem *io_base = get_irq_chip_data(virq);
+
+set_bit(irq, io_base + FLIPPER_ICR);
+}
So it should be a simple write instead of an RMW here, right?
As it is you are ACKing _all_ IRQs as far as I can see.
No, it acks just a single IRQ.
No it doesn't. Say IRQs 1 and 3 are asserted, so the reg contains 0x0a.
Now you want to ack IRQ1; set_bit() will write 0x0a | 0x02, not just
0x02.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 04/11] of/flattree: eliminate cell_t typedef
On Thu, 2009-11-26 at 22:36 +0100, Segher Boessenkool wrote: > >> You're right, it's not, but makes merging less complex, and then I > >> can > >> refactor properly. > > > > Still, make them __be32 at least > > There is no alignment guarantee at all either, better make it all u8 > and use accessor functions everywhere. Well... if you want to force using an accessor, then make it an opaque type. But __be32 is fine. It doesn't necessarily convey alignment and besides, there happens to -be- aligned in almost all cases so far :-) The flat tree format guarantees 32-bit alignment for the start of a property, so we are good here I think. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 04/19] powerpc: wii: device tree
Benjamin Herrenschmidt wrote: >>> Good point. I can't even guarantee that the kernel will work reliably >>> with nobats :-) At least you really want the kernel .text to be fully >>> covered by an IBAT. >>> >> It works with nobats. > > But does it work -reliably- ? :-) > It does AFAICT. My Wii is a 24x7 linux box although it is not stressed in any way usually. > Any ways, not a big deal right now, as I said, we really want the BATs > for performances anyways, so we should probably just add some kind of > hack in mmu_mapin_ram() for the time being. > Yup. The idea is to map the first 16MB of MEM1 with a BAT. Mapping the whole 24MB with BATs may not be possible because we want the framebuffer in MEM1 for performance reasons. >> I must say that all the patches posted (and the device drivers, which haven't >> been posted yet) are tested and working code. > > That was my impression too, but in this case, I'm talking about a > potential very hard to hit problem that you may well have never managed > to actually trigger. > I haven't actually, if that applies :) >> There you can find the hardware interface that supports the IPC mechanism. >> It is made up of a pair of registers to pass data between the processors and >> a >> pair of control/flags registers. >> The hardware can interrupt the PowerPC side when there is data available for >> it. > > Ok. So the right way to do that would be to have a node purely > representing the HW IPC, unrelated to whatever is running on the > secondary processor. > Totally agreed. > However, it's ok to have -below- that node, a set of device nodes or a > node with properties or whatever representing the FW in there and the > function it exposes. > > That can be discussed later tho. I'm not that keen on having those info > be in the .dts coming with the kernel since those functions essentially > depend on what FW is loaded on the aux. processor. > I think we can leave this for later as you said. > What might do however is to have a way for that FW itself to provide you > with the nodes and properties for the functions it provides :-) Then you > can have the boot wrapper or the kernel platform init code use some well > defined (and as stable as possible) IPC API to identify the FW there and > expose all that stuff. > Segher was playing with an OF implementation... > Of course that wouldn't work with FW we don't have control on. Can Linux > run on the wii with the original N. FW on the aux. processor ? Can we > detect what is running there ? Do we care ? > Yes, it can. And it is done. But I think we don't care/need that in mainline. >> It is what Nintendo calls the "Serial Interface" (SI) which is a proprietary >> serial hardware to drive the gamepads (and a custom keyboard too, once >> available >> for an RPG game). > > So I would give it a different name than "serial" then. Make it gpsi > maybe ? (game pad serial interface ?) :-) Or invent something else... > I'd choose "gcnsi" with a compatible like "nintendo,gamecube-si" :) (gcn is the official short abbreviation for the Nintendo GameCube) > Cheers, > Ben. > Thanks, Albert ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 04/11] of/flattree: eliminate cell_t typedef
You're right, it's not, but makes merging less complex, and then I can refactor properly. Still, make them __be32 at least There is no alignment guarantee at all either, better make it all u8 and use accessor functions everywhere. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 04/19] powerpc: wii: device tree
Benjamin Herrenschmidt wrote: > On Thu, 2009-11-26 at 16:09 +0100, Albert Herranz wrote: > >>> Are the above OHCI and EHCI "special" ? If not, there's an existing >>> binding for that sort of thing, which btw requires properties to >>> indicate the endianness of the registers and in-memory data structures >>> etc... >>> >> They are a bit special because registers are in reverse little endian format, >> must be written in 32-bit chunks, and (all things point to) they have >> hardware bugs. > > Well.. first what is "reverse little endian" ? :-) Big endian ? > It's the same case as the register access for the Freescale eSDHC controller, which is already in the existing sdhci-of driver. > The OHCI driver today has separate flags to control register endianness > and memory based data structures endianness. > > I think we also only use 32-bit reads and writes no ? So that should be > covered :-) > There are 8, 16 and 32 bit accesses. We need the same workarounds as present for the Freescale eSDHC controller. > As for HW bugs, well, as long as we know them we can define a quirk bit > and add the necessary workarounds to the driver :-) > Yes, that's how it was done. Although it it currently not integrated into sdhci-of. I think that the specific eSDHC code should be moved to another file, and leave the sdhci-of with the generic code and the sdhci_of_match table. Then adding a similar driver would simply consist in adding another file with the sdhci_data (containing ops and quirks) and adding an entry to the sdhci_of_match table in sdhci-of. > Do you have a patch somewhere that adds the OCHI and EHCI support btw ? > Yes, too. Although it needs review and cleanup too. I have a git tree with all the stuff, but it contains only the existing code previous to the effort of mainlining it: http://git.infradead.org/users/herraa1/gc-linux-2.6.git/shortlog/refs/heads/mini/gc-linux-2.6.31 > Cheers, > Ben. > Thanks, Albert ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] powerpc/mm: honor O_SYNC flag for memory map
So what you are saying is that if the kernel has mapped a physical page as cacheable while user application is trying to map it as non-cacheable, there will be machine checks and checkstops rather than just performance drop? This is new to me. Could you elaborate a bit? If some data is in cache at a certain physical address, and you then do an uncached read from that address, on at least some CPUs both the bus interface and the cache will reply. Bang, machine check. Writes are problematic as well. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 16/19] powerpc: wii: hollywood interrupt controller support
On Thu, 2009-11-26 at 16:42 +0100, Albert Herranz wrote:
> Benjamin Herrenschmidt wrote:
> > On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
> >
> >> +static void hlwd_pic_mask_and_ack(unsigned int virq)
> >> +{
> >> + int irq = virq_to_hw(virq);
> >> + void __iomem *io_base = get_irq_chip_data(virq);
> >> +
> >> + clear_bit(irq, io_base + HW_BROADWAY_IMR);
> >> + set_bit(irq, io_base + HW_BROADWAY_ICR);
> >> +}
> >
> > Same comment as with flipper. BTW. It looks really similar, can't you
> > use the same driver ?
> >
>
> I'll look at it. Surely, parts of it would be mergeable.
If it's too much work, we can do that later. No big deal.
Cheers,
Ben.
> > Cheers,
> > Ben.
> >
>
> Thanks,
> Albert
>
> >
> >
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 14/19] powerpc: allow ioremap within reserved fake ram regions
On Thu, 2009-11-26 at 16:35 +0100, Albert Herranz wrote: > Benjamin Herrenschmidt wrote: > > On Tue, 2009-11-24 at 18:09 +0100, Albert Herranz wrote: > >> I could use ppc_md.ioremap to duplicate ioremap except for the ioremap > >> ram check. > >> But calling the stock ioremap without modifying it is not possible > >> because it checks and bails out when ioremapping a region marked as > >> ram (even if it's not real ram and it's memreserved). > >> > >> Is the list of memreserved areas preserved once the kernel is running? > >> If it is preserved another option would be to unban ioremapping ram if > >> memreserved. > > > > Yes, check lmb's they should still be around. > > > > Good. > So adding a kconfig option to allow ioremapping memreserved memory marked > as ram and adding a proper check (under that kconfig) to unban this case > in ioremap would be an acceptable solution? Don't even make it Kconfig. Stick it under you GAMECUBE_COMMON for now or CONFIG_WII or whatever. This is temporary until we sort out the whole disctontig mem issue. Cheers, Ben. > > Cheers, > > Ben. > > > > Thanks, > Albert ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support
On Thu, 2009-11-26 at 16:33 +0100, Albert Herranz wrote:
> Benjamin Herrenschmidt wrote:
> > On Sun, 2009-11-22 at 16:28 -0700, Grant Likely wrote:
> >>> +unsigned int flipper_pic_get_irq(void)
> >>> +{
> >>> + void __iomem *io_base = flipper_irq_host->host_data;
> >>> + int irq;
> >>> + u32 irq_status;
> >>> +
> >>> + irq_status = in_be32(io_base + FLIPPER_ICR) &
> >>> +in_be32(io_base + FLIPPER_IMR);
> >>> + if (irq_status == 0)
> >>> + return -1; /* no more IRQs pending */
> >> NO_IRQ_IGNORE
> >
> > Why no just 0 ? (aka NO_IRQ)
> >
>
> I didn't know about 0 (I thought that was another valid interrupt).
0 is a valid hw number. It's not a valid linux "virq" number. In fact,
that's part of the reason why we generalized the whole virq thingy :-)
Because back then, Linus made the statement that 0 should never be a
valid IRQ number in linux. That also allowed us to make sure that 1..15
are never allocated to anything but a legacy 8259 to avoid all sorts of
problems with crackpot legacy x86 originated drivers who hard coded some
of these interrupts.
> I was used to -1 to tell that no IRQs were pending (at least from the
> ARCH=ppc days) :)
Yup, we changed that :-)
> > Or do you know you are getting lots of spurrious that you don't want to
> > account ?
> >
>
> No, this is not the case here.
Cheers,
Ben.
> > Cheers,
> > Ben.
> >
>
> Thanks,
> Albert
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support
On Thu, 2009-11-26 at 16:30 +0100, Albert Herranz wrote:
> Benjamin Herrenschmidt wrote:
> > On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
> >
> >> +static void flipper_pic_mask_and_ack(unsigned int virq)
> >> +{
> >> + int irq = virq_to_hw(virq);
> >> + void __iomem *io_base = get_irq_chip_data(virq);
> >> +
> >> + clear_bit(irq, io_base + FLIPPER_IMR);
> >> + set_bit(irq, io_base + FLIPPER_ICR);
> >> +}
> >
> > Do not use clear_bit and set_bit on IOs. They will do lwarx/stwcx. which
> > is really not what you want. You can use __clear_bit and __set_bit but
> > it's still fishy. Those operate on unsigned long, so the size vary
> > between 32 and 64 bit etc... not something you care that much about, but
> > it's still the wrong tool for the job.
> >
> > Do those guys have more than 32 interrupts ? If not, just hand
> > code the msak & shifts. If they do, then maybe stick with __clear_bit()
> > and __set_bit() which are the non atomic variants.
> >
>
> There can be only 32 interrupt sources per pic.
> I'll build a mask and check if just a simple write works too (it should
> IMHO), instead of a RWM.
For the ICR just writes should be ok. For the IMR, I wouldn't be
surprised if you need to RMW. In which case you have two options:
- One is you just do RMW :-) As long as you don't do SMP, you don't
have a problem since these callbacks are generally called with local
IRQs off.
- Or you could explicitely add a spinlock_irqsave just out of paranoia
or if you envision SMP type access to these things (from the aux
processor ? But then the spinlock would have to be shared with the aux
ptiocrocessor FW... fun)
- In any case, clear_bit and set_bit are the wrong accessors since
lwarx and stwcx. are definitely the wrong instructions to use for non
cachable accesses. On other processor you probably would have blown up
here in fact. Also those accessors don't provide any memory barriers
which mean you may even have some ordering issues. Use readl_be() and
writel_be() (or the ppc specific in_be32/out_be32) or the _le variants
if you want to count bits backward :-)
- You could also keep in memory cache of what the mask is supposed to
be. You RMW the cache and do a simple store to the register. It won't
fix the concurrency problem (that you probably don't have anyways) but
it will make things faster by avoiding an MMIO load
- However you probably need that MMIO load anyways :-) Trick is, the
store you do to ack and mask an interrupt may take some time to hit the
PIC before the said PIC actually lowers the CPU EE line. Enough time for
your code to go back, re-enable MSR:EE and start calling into the
handlers. Enough time thus to catch a "spurrious" interrupt. Old pmacs
have a similar PIC and have the same problem. I would recommend that
after a mask or a mask & ack, you also read back the register. The MMIO
accessors (readl, etc...) will use a twi;isync construct to ensure that
the load has been fully completed before execution continues which will
help.
- The construct and flow handler you use assume all interrupts are
level sensitive, this is the case right ?
Cheers,
Ben.
> > Cheers,
> > Ben.
> >
>
> Thanks,
> Albert
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 09/19] powerpc: gamecube/wii: udbg support for usbgecko
On Thu, 2009-11-26 at 16:28 +0100, Albert Herranz wrote: > Benjamin Herrenschmidt wrote: > > On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote: > >> Add support for using the USB Gecko adapter via the udbg facility on > >> the Nintendo GameCube and Wii video game consoles. > >> The USB Gecko is a 3rd party memory card interface adapter that provides > >> a EXI (External Interface) to USB serial converter. > > > > The main issue here is that the gecko is supposed to be something you > > can plug or unplug no ? Is it hotswap or only at boot ? In the later > > case, maybe the node should be created by the boot wrapper when > > detecting the presence of the device. If it's hotplug, then we need > > something smarter... > > > > The usbgecko is hotplugable and hotswappable. > But as this is mostly a developer feature, not normaly used by end users, > I think that we can just let it be as it is: autodetect it on boot (now > probing > for it instead of using information from the device tree). > If you unplug it later it causes no errors, you just miss whatever data is > sent to it. Ack. We may still went ultimately to have some kind of nice hotplug driver for that connector and we may even have a usbgecko driver for that things "after boot" that creates areal tty etc... but for now, just a hard probe will do just fine. Of course a real OF implemention is welcome to create a device node for it if it was indeed present at boot time. Cheers, Ben. > > Cheers, > > Ben. > > > > Thanks, > Albert > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 04/19] powerpc: wii: device tree
> > Good point. I can't even guarantee that the kernel will work reliably > > with nobats :-) At least you really want the kernel .text to be fully > > covered by an IBAT. > > > > It works with nobats. But does it work -reliably- ? :-) I haven't looked at that for years, but we used to have a subtle issue if you happen to take a hash miss on the kernel text or data in the wrong time, such as when SRR0/SRR1 are modified and before a subsequent rfi. This is very very hard to trigger and maybe impossible without SMP but to keep in mind. Paulus added some code ages ago to close most of these by using the MSR:RI bit so that the hash code could detect the situation and branch to some "recovery" code, but from memory, while that dealt with missing D-BATs, we still had a potential window of problem if the kernel text itself wasn't entirely covered. Any ways, not a big deal right now, as I said, we really want the BATs for performances anyways, so we should probably just add some kind of hack in mmu_mapin_ram() for the time being. > I must say that all the patches posted (and the device drivers, which haven't > been posted yet) are tested and working code. That was my impression too, but in this case, I'm talking about a potential very hard to hit problem that you may well have never managed to actually trigger. > There you can find the hardware interface that supports the IPC mechanism. > It is made up of a pair of registers to pass data between the processors and a > pair of control/flags registers. > The hardware can interrupt the PowerPC side when there is data available for > it. Ok. So the right way to do that would be to have a node purely representing the HW IPC, unrelated to whatever is running on the secondary processor. However, it's ok to have -below- that node, a set of device nodes or a node with properties or whatever representing the FW in there and the function it exposes. That can be discussed later tho. I'm not that keen on having those info be in the .dts coming with the kernel since those functions essentially depend on what FW is loaded on the aux. processor. What might do however is to have a way for that FW itself to provide you with the nodes and properties for the functions it provides :-) Then you can have the boot wrapper or the kernel platform init code use some well defined (and as stable as possible) IPC API to identify the FW there and expose all that stuff. Of course that wouldn't work with FW we don't have control on. Can Linux run on the wii with the original N. FW on the aux. processor ? Can we detect what is running there ? Do we care ? > It is what Nintendo calls the "Serial Interface" (SI) which is a proprietary > serial hardware to drive the gamepads (and a custom keyboard too, once > available > for an RPG game). So I would give it a different name than "serial" then. Make it gpsi maybe ? (game pad serial interface ?) :-) Or invent something else... Cheers, Ben. > > Cheers, > > Ben. > > > > Thanks, > Albert ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 04/19] powerpc: wii: device tree
On Thu, 2009-11-26 at 16:09 +0100, Albert Herranz wrote: > > Are the above OHCI and EHCI "special" ? If not, there's an existing > > binding for that sort of thing, which btw requires properties to > > indicate the endianness of the registers and in-memory data structures > > etc... > > > > They are a bit special because registers are in reverse little endian format, > must be written in 32-bit chunks, and (all things point to) they have > hardware bugs. Well.. first what is "reverse little endian" ? :-) Big endian ? The OHCI driver today has separate flags to control register endianness and memory based data structures endianness. I think we also only use 32-bit reads and writes no ? So that should be covered :-) As for HW bugs, well, as long as we know them we can define a quirk bit and add the necessary workarounds to the driver :-) Do you have a patch somewhere that adds the OCHI and EHCI support btw ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v6 2/2] pseries: Serialize cpu hotplug operations during deactivate Vs deallocate
From: Gautham R Shenoy
Currently the cpu-allocation/deallocation process comprises of two steps:
- Set the indicators and to update the device tree with DLPAR node
information.
- Online/offline the allocated/deallocated CPU.
This is achieved by writing to the sysfs tunables "probe" during allocation
and "release" during deallocation.
At the sametime, the userspace can independently online/offline the CPUs of
the system using the sysfs tunable "online".
It is quite possible that when a userspace tool offlines a CPU
for the purpose of deallocation and is in the process of updating the device
tree, some other userspace tool could bring the CPU back online by writing to
the "online" sysfs tunable thereby causing the deallocate process to fail.
The solution to this is to serialize writes to the "probe/release" sysfs
tunable with the writes to the "online" sysfs tunable.
This patch employs a mutex to provide this serialization, which is a no-op on
all architectures except PPC_PSERIES
Signed-off-by: Gautham R Shenoy
Acked-by: Vaidyanathan Srinivasan
---
arch/powerpc/platforms/pseries/dlpar.c | 45 +---
drivers/base/cpu.c |2 +
include/linux/cpu.h| 13 +
3 files changed, 50 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/dlpar.c
b/arch/powerpc/platforms/pseries/dlpar.c
index 642e1b2..fd2f0af 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -436,6 +436,18 @@ int dlpar_release_drc(u32 drc_index)
#ifdef CONFIG_ARCH_CPU_PROBE_RELEASE
+static DEFINE_MUTEX(pseries_cpu_hotplug_mutex);
+
+void cpu_hotplug_driver_lock()
+{
+ mutex_lock(&pseries_cpu_hotplug_mutex);
+}
+
+void cpu_hotplug_driver_unlock()
+{
+ mutex_unlock(&pseries_cpu_hotplug_mutex);
+}
+
static ssize_t dlpar_cpu_probe(const char *buf, size_t count)
{
struct device_node *dn;
@@ -443,13 +455,18 @@ static ssize_t dlpar_cpu_probe(const char *buf, size_t
count)
char *cpu_name;
int rc;
+ cpu_hotplug_driver_lock();
rc = strict_strtoul(buf, 0, &drc_index);
- if (rc)
- return -EINVAL;
+ if (rc) {
+ rc = -EINVAL;
+ goto out;
+ }
dn = dlpar_configure_connector(drc_index);
- if (!dn)
- return -EINVAL;
+ if (!dn) {
+ rc = -EINVAL;
+ goto out;
+ }
/* configure-connector reports cpus as living in the base
* directory of the device tree. CPUs actually live in the
@@ -459,7 +476,8 @@ static ssize_t dlpar_cpu_probe(const char *buf, size_t
count)
GFP_KERNEL);
if (!cpu_name) {
dlpar_free_cc_nodes(dn);
- return -ENOMEM;
+ rc = -ENOMEM;
+ goto out;
}
sprintf(cpu_name, "/cpus%s", dn->full_name);
@@ -469,7 +487,8 @@ static ssize_t dlpar_cpu_probe(const char *buf, size_t
count)
rc = dlpar_acquire_drc(drc_index);
if (rc) {
dlpar_free_cc_nodes(dn);
- return -EINVAL;
+ rc = -EINVAL;
+ goto out;
}
rc = dlpar_attach_node(dn);
@@ -479,6 +498,8 @@ static ssize_t dlpar_cpu_probe(const char *buf, size_t
count)
}
rc = online_node_cpus(dn);
+out:
+ cpu_hotplug_driver_unlock();
return rc ? rc : count;
}
@@ -499,26 +520,30 @@ static ssize_t dlpar_cpu_release(const char *buf, size_t
count)
return -EINVAL;
}
+ cpu_hotplug_driver_lock();
rc = offline_node_cpus(dn);
if (rc) {
of_node_put(dn);
- return -EINVAL;
+ rc = -EINVAL;
+ goto out;
}
rc = dlpar_release_drc(*drc_index);
if (rc) {
of_node_put(dn);
- return -EINVAL;
+ goto out;
}
rc = dlpar_detach_node(dn);
if (rc) {
dlpar_acquire_drc(*drc_index);
- return rc;
+ goto out;
}
of_node_put(dn);
- return count;
+out:
+ cpu_hotplug_driver_unlock();
+ return rc ? rc : count;
}
static int __init pseries_dlpar_init(void)
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 7c03af7..27fd775 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -35,6 +35,7 @@ static ssize_t __ref store_online(struct sys_device *dev,
struct sysdev_attribut
struct cpu *cpu = container_of(dev, struct cpu, sysdev);
ssize_t ret;
+ cpu_hotplug_driver_lock();
switch (buf[0]) {
case '0':
ret = cpu_down(cpu->sysdev.id);
@@ -49,6 +50,7 @@ static ssize_t __ref store_online(struct sys_device *dev,
struct sysdev_attribut
default:
ret = -EINVAL;
}
+ cpu_hotplug_driver_unlock();
[PATCH v6 1/2] pseries: Add code to online/offline CPUs of a DLPAR node
From: Gautham R Shenoy
Currently the cpu-allocation/deallocation on pSeries is a
two step process from the Userspace.
- Set the indicators and update the device tree by writing to the sysfs
tunable "probe" during allocation and "release" during deallocation.
- Online / Offline the CPUs of the allocated/would_be_deallocated node by
writing to the sysfs tunable "online".
This patch adds kernel code to online/offline the CPUs soon_after/just_before
they have been allocated/would_be_deallocated. This way, the userspace tool
that performs DLPAR operations would only have to deal with one set of sysfs
tunables namely "probe" and release".
Signed-off-by: Gautham R Shenoy
Signed-off-by: Nathan Fontenot
Acked-by: Vaidyanathan Srinivasan
---
arch/powerpc/platforms/pseries/dlpar.c | 101
1 files changed, 101 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/dlpar.c
b/arch/powerpc/platforms/pseries/dlpar.c
index fe8d4b3..642e1b2 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include "offline_states.h"
#include
#include
@@ -287,6 +288,98 @@ int dlpar_detach_node(struct device_node *dn)
return 0;
}
+int online_node_cpus(struct device_node *dn)
+{
+ int rc = 0;
+ unsigned int cpu;
+ int len, nthreads, i;
+ const u32 *intserv;
+
+ intserv = of_get_property(dn, "ibm,ppc-interrupt-server#s", &len);
+ if (!intserv)
+ return -EINVAL;
+
+ nthreads = len / sizeof(u32);
+
+ cpu_maps_update_begin();
+ for (i = 0; i < nthreads; i++) {
+ for_each_present_cpu(cpu) {
+ if (get_hard_smp_processor_id(cpu) != intserv[i])
+ continue;
+ BUG_ON(get_cpu_current_state(cpu)
+ != CPU_STATE_OFFLINE);
+ cpu_maps_update_done();
+ rc = cpu_up(cpu);
+ if (rc)
+ goto out;
+ cpu_maps_update_begin();
+
+ break;
+ }
+ if (cpu == num_possible_cpus())
+ printk(KERN_WARNING "Could not find cpu to online "
+ "with physical id 0x%x\n", intserv[i]);
+ }
+ cpu_maps_update_done();
+
+out:
+ return rc;
+
+}
+
+int offline_node_cpus(struct device_node *dn)
+{
+ int rc = 0;
+ unsigned int cpu;
+ int len, nthreads, i;
+ const u32 *intserv;
+
+ intserv = of_get_property(dn, "ibm,ppc-interrupt-server#s", &len);
+ if (!intserv)
+ return -EINVAL;
+
+ nthreads = len / sizeof(u32);
+
+ cpu_maps_update_begin();
+ for (i = 0; i < nthreads; i++) {
+ for_each_present_cpu(cpu) {
+ if (get_hard_smp_processor_id(cpu) != intserv[i])
+ continue;
+
+ if (get_cpu_current_state(cpu) == CPU_STATE_OFFLINE)
+ break;
+
+ if (get_cpu_current_state(cpu) == CPU_STATE_ONLINE) {
+ cpu_maps_update_done();
+ rc = cpu_down(cpu);
+ if (rc)
+ goto out;
+ cpu_maps_update_begin();
+ break;
+
+ }
+
+ /*
+* The cpu is in CPU_STATE_INACTIVE.
+* Upgrade it's state to CPU_STATE_OFFLINE.
+*/
+ set_preferred_offline_state(cpu, CPU_STATE_OFFLINE);
+ BUG_ON(plpar_hcall_norets(H_PROD, intserv[i])
+ != H_SUCCESS);
+ __cpu_die(cpu);
+ break;
+ }
+ if (cpu == num_possible_cpus())
+ printk(KERN_WARNING "Could not find cpu to offline "
+ "with physical id 0x%x\n", intserv[i]);
+ }
+ cpu_maps_update_done();
+
+out:
+ return rc;
+
+}
+
#define DR_ENTITY_SENSE9003
#define DR_ENTITY_PRESENT 1
#define DR_ENTITY_UNUSABLE 2
@@ -385,6 +478,8 @@ static ssize_t dlpar_cpu_probe(const char *buf, size_t
count)
dlpar_free_cc_nodes(dn);
}
+ rc = online_node_cpus(dn);
+
return rc ? rc : count;
}
@@ -404,6 +499,12 @@ static ssize_t dlpar_cpu_release(const char *buf, size_t
count)
return -EINVAL;
}
+ rc = offline_node_cpus(dn);
+ if (rc) {
+ of_node_put(dn);
+ return -EINVAL;
+ }
+
rc = dlpar_release_drc(*drc_index);
[PATCH v6 0/2] pseries: Add cede support for cpu-offline
Hi, This is version 6 of patch series that provides a framework to choose the state a pseries CPU must be put to when it is offlined. Previous versions can be found here: Version 5: http://lkml.org/lkml/2009/10/30/6 Version 4: http://lkml.org/lkml/2009/10/9/59 Version 3: http://lkml.org/lkml/2009/9/15/164 Version 2: http://lkml.org/lkml/2009/8/28/102 Version 1: http://lkml.org/lkml/2009/8/6/236 Changes from the previous version include: - Built on Nathan Fontenot's v3 of "Kernel handling of Dynamic Logical Partitioning" http://lkml.org/lkml/2009/11/25/21 - Rebased to powerpc.git tree and hence dropped 1st and 2nd patch in the stack since they are already in the powerpc.git tree: With reference to previous version, Dropped: 1/4 pSeries: extended_cede_processor() helper function 2/4 pSeries: Add hooks to put the CPU into an appropriate offline state Posting only: 3/4 pseries: Add code to online/offline CPUs of a DLPAR node 4/4 pseries: Serialize cpu hotplug operations during deactivate Vs deallocate Minor changes in the above patchs due to changes in Nathan's routines. Also, - This approach addresses Peter Z's objections regarding layering violations. The user simply offlines the cpu and doesn't worry about what state the CPU should be put into. That part is automatically handled by the kernel. Acked-by: Peter Zijlstra http://lkml.org/lkml/2009/11/11/328 - It does not add any additional sysfs interface instead uses the existing sysfs interface to offline CPUs. - On platforms which do not have support for ceding the vcpu with a latency specifier value, the offlining mechanism defaults to the current method of calling rtas_stop_self(). This patchset is based on powerpc.git + Nathan's patches and has been built and tested on pseries platforms. This series can be applied to powerpc.git after Nathan's patches. Thanks, Vaidy --- Gautham R Shenoy (2): pseries: Serialize cpu hotplug operations during deactivate Vs deallocate pseries: Add code to online/offline CPUs of a DLPAR node arch/powerpc/platforms/pseries/dlpar.c | 144 ++-- drivers/base/cpu.c |2 include/linux/cpu.h| 13 +++ 3 files changed, 150 insertions(+), 9 deletions(-) -- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Reserve memory for kdump kernel within RMO region
M. Mohan Kumar schrieb: > On 11/26/2009 12:22 AM, Bernhard Walle wrote: >> M. Mohan Kumar schrieb: >>> Reserve memory for kdump kernel within RMO region >>> >>> When the kernel size exceeds 32MB(observed with some distros), memory >>> for kdump kernel can not be reserved as kdump kernel base is assumed to >>> be 32MB always. When the kernel has CONFIG_RELOCATABLE option enabled, >>> provide the feature to reserve the memory for kdump kernel anywhere in >>> the RMO region. > > Hi Bernhard, > >> Correct me if I'm wrong, but: CONFIG_RELOCATABLE is for the kernel that >> gets loaded as crashkernel, not for the kernel that loads the >> crashkernel. So it would be perfectly fine that a kernel that has not >> CONFIG_RELOCATABLE set would load another kernel that has >> CONFIG_RELOCATABLE set on an address != 32 M. > > No, with relocatable option, the same kernel is used as both production > and kdump kernel. Can be, but it's not strictly necessary. It depends what userland does. Especially it's possible that a non-relocatable, self-compiled kernel loads a relocatable distribution kernel as capture kernel. Also, it would make sense to make the behaviour symmetric across platforms. Currently we have: - x86 and ia64: Without offset on command line, use any offset With offset on command line, use that offset and fail if no memory is available at that offset. - ppc64: Always use 32M and ignore the offset. If your patch gets applied, we have: - ppc64: With CONFIG_RELOCATABLE, use any offset With offset on command I don't see why the behaviour on ppc64 should be completely different. Having maintained kdump for SUSE for x86, ia64 and partly ppc64 in the past, I always felt that ppc64 is more different from x86 than ia64 is from x86. That's one more step into that direction without a technical reason. Having that all said: If your patch gets in mainline kernel, than we should change the behaviour also for x86 and ia64. Regards, Bernhard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: spi_mpc8xxx.c: chip select polarity problem
On Thu, Nov 26, 2009 at 12:01 PM, Anton Vorontsov wrote: > On Thu, Nov 26, 2009 at 11:50:05AM -0700, Grant Likely wrote: >> On Thu, Nov 26, 2009 at 11:41 AM, Anton Vorontsov >> wrote: >> > On Thu, Nov 26, 2009 at 11:16:34AM -0700, Grant Likely wrote: >> > [...] >> >> The spi-cs-high property is defined in >> >> Documentation/powerpc/dts-bindings/spi-bus.txt, but it definitely was >> >> a mistake >> > >> > Yup. >> > >> >> Currently the spi-cs-high property is parsed in the >> >> of_register_spi_devices() function, but the CS polarity needs to be >> >> known before registering devices. It needs to be factored out into >> >> another utility function callable by spi bus drivers so that it can >> >> get polarity data at probe time. >> > >> > Untill we have this, Torsten's patch is a real improvement, and >> > works for non-broken hw/fw. >> > >> > So I think it should be applied. >> >> I disagree since it only band-aids the problem and uglifies the driver >> in the process. In the immediate term the driver needs to be changed >> to read the spi-cs-high property out of the child nodes before >> registering the devices. > > Hm. I thought we agreed that spi-cs-high is not good? Why do you > encourage using it then? We'll have to uglify the driver with > legacy device-tree handling code. spi-cs-high is definitely not a complete solution, but it isn't actively evil either. Plus it is documented and (presumably) in active use. so support for it should not be dropped. Regardless, there needs to be a library function for parsing all the SPI child nodes and returning the active state for each GPIO chip select. All the code for parsing the old spi-cs-high properties can be contained in the same place as a new yet-to-be-defined bus node cs polarity property. The rework to the driver itself is not ugly. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: spi_mpc8xxx.c: chip select polarity problem
On Thu, Nov 26, 2009 at 11:50:05AM -0700, Grant Likely wrote: > On Thu, Nov 26, 2009 at 11:41 AM, Anton Vorontsov > wrote: > > On Thu, Nov 26, 2009 at 11:16:34AM -0700, Grant Likely wrote: > > [...] > >> The spi-cs-high property is defined in > >> Documentation/powerpc/dts-bindings/spi-bus.txt, but it definitely was > >> a mistake > > > > Yup. > > > >> Currently the spi-cs-high property is parsed in the > >> of_register_spi_devices() function, but the CS polarity needs to be > >> known before registering devices. It needs to be factored out into > >> another utility function callable by spi bus drivers so that it can > >> get polarity data at probe time. > > > > Untill we have this, Torsten's patch is a real improvement, and > > works for non-broken hw/fw. > > > > So I think it should be applied. > > I disagree since it only band-aids the problem and uglifies the driver > in the process. In the immediate term the driver needs to be changed > to read the spi-cs-high property out of the child nodes before > registering the devices. Hm. I thought we agreed that spi-cs-high is not good? Why do you encourage using it then? We'll have to uglify the driver with legacy device-tree handling code. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: spi_mpc8xxx.c: chip select polarity problem
On Thu, Nov 26, 2009 at 11:41 AM, Anton Vorontsov wrote: > On Thu, Nov 26, 2009 at 11:16:34AM -0700, Grant Likely wrote: > [...] >> The spi-cs-high property is defined in >> Documentation/powerpc/dts-bindings/spi-bus.txt, but it definitely was >> a mistake > > Yup. > >> Currently the spi-cs-high property is parsed in the >> of_register_spi_devices() function, but the CS polarity needs to be >> known before registering devices. It needs to be factored out into >> another utility function callable by spi bus drivers so that it can >> get polarity data at probe time. > > Untill we have this, Torsten's patch is a real improvement, and > works for non-broken hw/fw. > > So I think it should be applied. I disagree since it only band-aids the problem and uglifies the driver in the process. In the immediate term the driver needs to be changed to read the spi-cs-high property out of the child nodes before registering the devices. I'm not going to apply this patch. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: spi_mpc8xxx.c: chip select polarity problem
On Thu, Nov 26, 2009 at 11:16:34AM -0700, Grant Likely wrote: [...] > The spi-cs-high property is defined in > Documentation/powerpc/dts-bindings/spi-bus.txt, but it definitely was > a mistake Yup. > Currently the spi-cs-high property is parsed in the > of_register_spi_devices() function, but the CS polarity needs to be > known before registering devices. It needs to be factored out into > another utility function callable by spi bus drivers so that it can > get polarity data at probe time. Untill we have this, Torsten's patch is a real improvement, and works for non-broken hw/fw. So I think it should be applied. Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: spi_mpc8xxx.c: chip select polarity problem
On Thu, Nov 26, 2009 at 10:27 AM, Torsten Fleischer wrote: > On Thu, Nov 26, 2009 at 13:12:04 Anton Vorontsov wrote: > [...] >> > Ah. I understand what you're doing now. Hmmm. This approach >> > concerns me because it relies on firmware or platform code to get CS >> > gpios set up properly before the driver is probed. >> >> Yes, that was said at the very beginning of this thread. >> >> > Firmware doesn't >> > always get it right, and I prefer to avoid platform specific setups as >> > much as possible. Why can't the CS polarity be encoded into the >> > device tree so the driver *does* have the polarity data at probe time? >> >> We have the spi-cs-high property, but it duplicates compatible >> property. 'compatible' is enough to tell whether some device has >> cs-high or cs-low (device's driver knows that already). >> >> The problem is that SPI bus master doesn't know all the devices, >> so it can't extract that information from the compatible string. >> To workaround that we can use 'spi-cs-high', but that's ugly >> workaround. >> >> SPI modes (0,1,2,3) is another matter, some devices can work in >> several modes, so 'spi-cpol' and 'spi-cpha' are actually useful. >> > To get a sane initial state the needed GPIOs can be set to be inputs during > the driver's initialization. > This requires pull-up/pull-down resistors connected to the chip select > lines. I think we can assume that they exist, because the GPIOs are all inputs > after the controller's hardware reset and the resistors are needed to have a > well-defined voltage level on the chip select lines. Normally the level is set > so that the devices are disabled. > > Therefore, it doesn't matter if the firmware sets the GPIOs wrong. No, that's just shifting responsibility from firmware to hardware. There is just as much broken hardware out there as broken firmware. The assumption cannot be made that the initial state of the pin is the inactive state of the CS line. Plus, some GPIO pins are output only and the inital state cannot be read. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: spi_mpc8xxx.c: chip select polarity problem
On Thu, Nov 26, 2009 at 5:12 AM, Anton Vorontsov wrote: > On Wed, Nov 25, 2009 at 03:11:57PM -0700, Grant Likely wrote: >> On Wed, Nov 25, 2009 at 1:41 PM, Torsten Fleischer >> wrote: >> > On Wen, Nov 25, 2009 at 01:33:57 Grant Likely wrote: >> >> Thanks. However, there needs to be a proper description of what this >> >> patch does to go in the commit header. Can you please write one? >> >> >> >> Thanks, >> >> g. >> >> >> > [...] >> > >> > The initialization of the chip selects is removed from the probe() >> > function of >> > the spi_mpc8xxx driver, because the driver doesn't know the polarity of the >> > chip selects of the SPI devices at the time of its initialization. >> > >> > For this reason the initialization of the several chip selects is postponed >> > to the point of time when the very first SPI transfer to the associated >> > device >> > occurs. >> > >> > >> > Signed-off-by: Torsten Fleischer >> >> Ah. I understand what you're doing now. Hmmm. This approach >> concerns me because it relies on firmware or platform code to get CS >> gpios set up properly before the driver is probed. > > Yes, that was said at the very beginning of this thread. I also came in part way through as I wasn't an SPI maintainer when this thread started. :-) >> Firmware doesn't >> always get it right, and I prefer to avoid platform specific setups as >> much as possible. Why can't the CS polarity be encoded into the >> device tree so the driver *does* have the polarity data at probe time? > > We have the spi-cs-high property, but it duplicates compatible > property. 'compatible' is enough to tell whether some device has > cs-high or cs-low (device's driver knows that already). But the device's driver isn't controlling the CS line, the SPI bus driver is. Besides, there is no guarantee that all drivers will actualy be loaded before something starts using SPI. The bus driver *must* know what the active state of each CS line is before activating any devices. The spi bus binding is deficient in this case. A property (can be optional) need to be added to the spi bus node to explicitly state the CS polarities. It's not entirely sane to look for a "spi-cs-high' property in the spi device nodes because the SPI bus may not be fully populated (ie. if a device happens to be sitting on the bus, but isn't in the device tree yet). Before any SPI transactions go out, it is the responsibility of the bus driver to ensure all CS lines are in the correct state. > The problem is that SPI bus master doesn't know all the devices, > so it can't extract that information from the compatible string. > To workaround that we can use 'spi-cs-high', but that's ugly > workaround. It doesn't need to know about the devices, but is must know how all of its CS lines behave. So it isn't an really an ugly workaround, but I do think the binding is insufficient for the SPI bus driver (see below) > SPI modes (0,1,2,3) is another matter, some devices can work in > several modes, so 'spi-cpol' and 'spi-cpha' are actually useful. yes. spi-cpol and spi-cpha are actually properties of the device, and belong in the spi device node, not the spi bus node. The spi-cs-high property is defined in Documentation/powerpc/dts-bindings/spi-bus.txt, but it definitely was a mistake for the reasons I described above. It does work in some cases, but a property at the bus node would be better. The driver can still fallback to looking for spi-cs-high properties in child nodes. Currently the spi-cs-high property is parsed in the of_register_spi_devices() function, but the CS polarity needs to be known before registering devices. It needs to be factored out into another utility function callable by spi bus drivers so that it can get polarity data at probe time. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: spi_mpc8xxx.c: chip select polarity problem
On Thu, Nov 26, 2009 at 13:12:04 Anton Vorontsov wrote: [...] > > Ah. I understand what you're doing now. Hmmm. This approach > > concerns me because it relies on firmware or platform code to get CS > > gpios set up properly before the driver is probed. > > Yes, that was said at the very beginning of this thread. > > > Firmware doesn't > > always get it right, and I prefer to avoid platform specific setups as > > much as possible. Why can't the CS polarity be encoded into the > > device tree so the driver *does* have the polarity data at probe time? > > We have the spi-cs-high property, but it duplicates compatible > property. 'compatible' is enough to tell whether some device has > cs-high or cs-low (device's driver knows that already). > > The problem is that SPI bus master doesn't know all the devices, > so it can't extract that information from the compatible string. > To workaround that we can use 'spi-cs-high', but that's ugly > workaround. > > SPI modes (0,1,2,3) is another matter, some devices can work in > several modes, so 'spi-cpol' and 'spi-cpha' are actually useful. > To get a sane initial state the needed GPIOs can be set to be inputs during the driver's initialization. This requires pull-up/pull-down resistors connected to the chip select lines. I think we can assume that they exist, because the GPIOs are all inputs after the controller's hardware reset and the resistors are needed to have a well-defined voltage level on the chip select lines. Normally the level is set so that the devices are disabled. Therefore, it doesn't matter if the firmware sets the GPIOs wrong. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 16/19] powerpc: wii: hollywood interrupt controller support
Benjamin Herrenschmidt wrote:
> On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
>
>> +static void hlwd_pic_mask_and_ack(unsigned int virq)
>> +{
>> +int irq = virq_to_hw(virq);
>> +void __iomem *io_base = get_irq_chip_data(virq);
>> +
>> +clear_bit(irq, io_base + HW_BROADWAY_IMR);
>> +set_bit(irq, io_base + HW_BROADWAY_ICR);
>> +}
>
> Same comment as with flipper. BTW. It looks really similar, can't you
> use the same driver ?
>
I'll look at it. Surely, parts of it would be mergeable.
> Cheers,
> Ben.
>
Thanks,
Albert
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 14/19] powerpc: allow ioremap within reserved fake ram regions
Benjamin Herrenschmidt wrote: > On Tue, 2009-11-24 at 18:09 +0100, Albert Herranz wrote: >> I could use ppc_md.ioremap to duplicate ioremap except for the ioremap >> ram check. >> But calling the stock ioremap without modifying it is not possible >> because it checks and bails out when ioremapping a region marked as >> ram (even if it's not real ram and it's memreserved). >> >> Is the list of memreserved areas preserved once the kernel is running? >> If it is preserved another option would be to unban ioremapping ram if >> memreserved. > > Yes, check lmb's they should still be around. > Good. So adding a kconfig option to allow ioremapping memreserved memory marked as ram and adding a proper check (under that kconfig) to unban this case in ioremap would be an acceptable solution? > Cheers, > Ben. > Thanks, Albert ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support
Benjamin Herrenschmidt wrote:
> On Sun, 2009-11-22 at 16:28 -0700, Grant Likely wrote:
>>> +unsigned int flipper_pic_get_irq(void)
>>> +{
>>> + void __iomem *io_base = flipper_irq_host->host_data;
>>> + int irq;
>>> + u32 irq_status;
>>> +
>>> + irq_status = in_be32(io_base + FLIPPER_ICR) &
>>> +in_be32(io_base + FLIPPER_IMR);
>>> + if (irq_status == 0)
>>> + return -1; /* no more IRQs pending */
>> NO_IRQ_IGNORE
>
> Why no just 0 ? (aka NO_IRQ)
>
I didn't know about 0 (I thought that was another valid interrupt).
I was used to -1 to tell that no IRQs were pending (at least from the ARCH=ppc
days) :)
> Or do you know you are getting lots of spurrious that you don't want to
> account ?
>
No, this is not the case here.
> Cheers,
> Ben.
>
Thanks,
Albert
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support
Benjamin Herrenschmidt wrote:
> On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
>
>> +static void flipper_pic_mask_and_ack(unsigned int virq)
>> +{
>> +int irq = virq_to_hw(virq);
>> +void __iomem *io_base = get_irq_chip_data(virq);
>> +
>> +clear_bit(irq, io_base + FLIPPER_IMR);
>> +set_bit(irq, io_base + FLIPPER_ICR);
>> +}
>
> Do not use clear_bit and set_bit on IOs. They will do lwarx/stwcx. which
> is really not what you want. You can use __clear_bit and __set_bit but
> it's still fishy. Those operate on unsigned long, so the size vary
> between 32 and 64 bit etc... not something you care that much about, but
> it's still the wrong tool for the job.
>
> Do those guys have more than 32 interrupts ? If not, just hand
> code the msak & shifts. If they do, then maybe stick with __clear_bit()
> and __set_bit() which are the non atomic variants.
>
There can be only 32 interrupt sources per pic.
I'll build a mask and check if just a simple write works too (it should IMHO),
instead of a RWM.
> Cheers,
> Ben.
>
Thanks,
Albert
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 09/19] powerpc: gamecube/wii: udbg support for usbgecko
Benjamin Herrenschmidt wrote: > On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote: >> Add support for using the USB Gecko adapter via the udbg facility on >> the Nintendo GameCube and Wii video game consoles. >> The USB Gecko is a 3rd party memory card interface adapter that provides >> a EXI (External Interface) to USB serial converter. > > The main issue here is that the gecko is supposed to be something you > can plug or unplug no ? Is it hotswap or only at boot ? In the later > case, maybe the node should be created by the boot wrapper when > detecting the presence of the device. If it's hotplug, then we need > something smarter... > The usbgecko is hotplugable and hotswappable. But as this is mostly a developer feature, not normaly used by end users, I think that we can just let it be as it is: autodetect it on boot (now probing for it instead of using information from the device tree). If you unplug it later it causes no errors, you just miss whatever data is sent to it. > Cheers, > Ben. > Thanks, Albert ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] PPC: Sync guest visible MMU state
Currently userspace has no chance to find out which virtual address space we're
in and resolve addresses. While that is a big problem for migration, it's also
unpleasent when debugging, as gdb and the monitor don't work on virtual
addresses.
This patch exports enough of the MMU segment state to userspace to make
debugging work and thus also includes the groundwork for migration.
Signed-off-by: Alexander Graf
---
Ben, please take this patch in your tree.
v2 -> v3:
- don't use anonymous unions/structs
---
arch/powerpc/include/asm/kvm.h| 20 +++-
arch/powerpc/include/asm/kvm_asm.h|1 +
arch/powerpc/include/asm/kvm_book3s.h |3 ++
arch/powerpc/kvm/book3s.c | 53 +++-
arch/powerpc/kvm/book3s_64_emulate.c | 38 ++-
arch/powerpc/kvm/book3s_64_mmu.c |2 +
arch/powerpc/kvm/powerpc.c|3 ++
include/linux/kvm.h |3 ++
8 files changed, 104 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index c9ca97f..cb6ad08 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -46,8 +46,24 @@ struct kvm_regs {
};
struct kvm_sregs {
- __u32 pvr;
- char pad[1020];
+ union {
+ struct {
+ __u32 pvr;
+ __u64 sdr1;
+ struct {
+ struct {
+ __u64 slbe;
+ __u64 slbv;
+ } slb[64];
+ } ppc64;
+ struct {
+ __u32 sr[16];
+ __u64 ibat[8];
+ __u64 dbat[8];
+ } ppc32;
+ } s;
+ __u8 pad[1024];
+ } u;
};
struct kvm_fpu {
diff --git a/arch/powerpc/include/asm/kvm_asm.h
b/arch/powerpc/include/asm/kvm_asm.h
index 19ddb35..af2abe7 100644
--- a/arch/powerpc/include/asm/kvm_asm.h
+++ b/arch/powerpc/include/asm/kvm_asm.h
@@ -87,6 +87,7 @@
#define BOOK3S_IRQPRIO_MAX 16
#define BOOK3S_HFLAG_DCBZ320x1
+#define BOOK3S_HFLAG_SLB 0x2
#define RESUME_FLAG_NV (1<<0) /* Reload guest nonvolatile state? */
#define RESUME_FLAG_HOST(1<<1) /* Resume host? */
diff --git a/arch/powerpc/include/asm/kvm_book3s.h
b/arch/powerpc/include/asm/kvm_book3s.h
index c601133..74b7369 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -46,6 +46,7 @@ struct kvmppc_sr {
};
struct kvmppc_bat {
+ u64 raw;
u32 bepi;
u32 bepi_mask;
bool vs;
@@ -113,6 +114,8 @@ extern struct kvmppc_pte *kvmppc_mmu_find_pte(struct
kvm_vcpu *vcpu, u64 ea, boo
extern int kvmppc_ld(struct kvm_vcpu *vcpu, ulong eaddr, int size, void *ptr,
bool data);
extern int kvmppc_st(struct kvm_vcpu *vcpu, ulong eaddr, int size, void *ptr);
extern void kvmppc_book3s_queue_irqprio(struct kvm_vcpu *vcpu, unsigned int
vec);
+extern void kvmppc_set_bat(struct kvm_vcpu *vcpu, struct kvmppc_bat *bat,
+ bool upper, u32 val);
extern u32 kvmppc_trampoline_lowmem;
extern u32 kvmppc_trampoline_enter;
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 42037d4..583 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -281,6 +281,7 @@ void kvmppc_core_deliver_interrupts(struct kvm_vcpu *vcpu)
void kvmppc_set_pvr(struct kvm_vcpu *vcpu, u32 pvr)
{
+ vcpu->arch.hflags &= ~BOOK3S_HFLAG_SLB;
vcpu->arch.pvr = pvr;
if ((pvr >= 0x33) && (pvr < 0x7033)) {
kvmppc_mmu_book3s_64_init(vcpu);
@@ -762,14 +763,62 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu,
struct kvm_regs *regs)
int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
struct kvm_sregs *sregs)
{
- sregs->pvr = vcpu->arch.pvr;
+ struct kvmppc_vcpu_book3s *vcpu3s = to_book3s(vcpu);
+ int i;
+
+ sregs->u.s.pvr = vcpu->arch.pvr;
+
+ sregs->u.s.sdr1 = to_book3s(vcpu)->sdr1;
+ if (vcpu->arch.hflags & BOOK3S_HFLAG_SLB) {
+ for (i = 0; i < 64; i++) {
+ sregs->u.s.ppc64.slb[i].slbe = vcpu3s->slb[i].orige | i;
+ sregs->u.s.ppc64.slb[i].slbv = vcpu3s->slb[i].origv;
+ }
+ } else {
+ for (i = 0; i < 16; i++) {
+ sregs->u.s.ppc32.sr[i] = vcpu3s->sr[i].raw;
+ sregs->u.s.ppc32.sr[i] = vcpu3s->sr[i].raw;
+ }
+ for (i = 0; i < 8; i++) {
+ sregs->u.s.ppc32.ibat[i] = vcpu3s->ibat[i].raw;
+ sregs->u.s.ppc32.dbat[i] = vcpu3s->dbat[i].raw;
+ }
+
Re: [RFC PATCH 06/19] powerpc: gamecube/wii: introduce GAMECUBE_COMMON
Benjamin Herrenschmidt wrote: > On Tue, 2009-11-24 at 19:03 +0100, Albert Herranz wrote: >> Segher Boessenkool wrote: Add a config option GAMECUBE_COMMON to be used as a dependency for all options common to the Nintendo GameCube and Wii video game consoles. >>> Maybe something like GAMECUBE_OR_WII instead? "COMMON" is so >>> common it's meaningless. >>> >> I don't like either GAMECUBE_OR_WII. >> It looks as if it can be used to match options for the GAMECUBE _or_ WII. >> But that's not the meaning of it. >> >> This option should be used only for options applicable to both the GAMECUBE >> and WII, i.e. basically those options in the WII which where "inherited" >> from the GAMECUBE to make it retro-compatible. >> >> If GAMECUBE_COMMON is unacceptable, maybe GAMECUBE_LEGACY or GAMECUBE_COMPAT? > > I don't have any strong opinion. Maybe NINTENDO_COMMON ? > We should avoid using NINTENDO just to refer to the Nintendo GameCube or Wii. They have other consoles too :) There's even a port of Linux to the Nintendo DS... I'd stick to GAMECUBE_COMMON or GAMECUBE_COMPAT. > Cheers, > Ben. > Thanks, Albert ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 04/19] powerpc: wii: device tree
Benjamin Herrenschmidt wrote: > On Wed, 2009-11-25 at 19:34 +0100, Albert Herranz wrote: >> We need nobats (or a hack in the mmu_mapin_ram() code) because of the >> discontiguous ram problem. > > I would vote for a hack in mmu_mapin_ram() for now. > I'll cook that. > Cheers, > Ben. > Thanks, Albert ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 04/19] powerpc: wii: device tree
Benjamin Herrenschmidt wrote:
> On Wed, 2009-11-25 at 18:49 +0100, Segher Boessenkool wrote:
>>> +/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O area) */
>> Like others have said already, don't do this. If you need
>> a workaround, put it in the platform code.
>>
>>> +/memreserve/ 0x1000 0x0004000; /* DSP RAM */
>> This address is fixed in the DSP hardware, right? If not,
>> you shouldn't do a reserve here.
>>
>>> + chosen {
>>> + /* root filesystem on 2nd partition of SD card */
>>> + bootargs = "nobats root=/dev/mmcblk0p2 rootwait udbg-immortal";
>> Question: why do you need/want nobats?
>
> Good point. I can't even guarantee that the kernel will work reliably
> with nobats :-) At least you really want the kernel .text to be fully
> covered by an IBAT.
>
It works with nobats.
I must say that all the patches posted (and the device drivers, which haven't
been posted yet) are tested and working code.
>> What does this clock freq mean? Hollywood has lots of
>> clocks, many of them configurable. Bus frequency is in
>> the cpu node already. The binding doesn't say what this
>> is either, since you didn't write a binding :-)
>>
>> Just remove it?
>
> BTW. If we want to play with clocks, maybe you should look at
> my proposed binding for clocks and implementing the clk API :-)
>
>>> + ranges = <0x0c00 0x0c00 0x0001
>>> + 0x0d00 0x0d00 0x0001
>>> + 0x0d04 0x0d04 0x0005
>>> + 0x0d80 0x0d80 0x1000
>> All of 0cXX and 0dXX actually.
>>
>>> + 0x133e 0x133e 0x00c2>;
>> This is just part of MEM2, don't treat it special here.
>>
>>> + vi...@0c002000 {
>>> + compatible = "nintendo,hollywood-video";
>>> + reg = <0x0c002000 0x100>;
>>> + interrupts = <8>;
>>> + interrupt-parent = <&PIC0>;
>> If you say interrupt-parent = <..> in the root node, you can
>> leave it out in most of the rest of the tree. Using the Flipper
>> PIC for this sounds like a good plan.
>
> Well, for the rest of the tree except stuff whose interrupt parent
> is PIC1. With two PICs I prefer being explicit.
>
Let it be specific then :)
>>> + PIC0: p...@0c003000 {
>>> + #interrupt-cells = <1>;
>>> + compatible = "nintendo,flipper-pic";
>>> + reg = <0x0c003000 0x8>;
>> This register block is bigger actually. It's not only PIC,
>> but some other bus stuff as well, dunno what to do here.
>
> Add nodes for the other things ?
>
>>> + interrupt-controller;
>>> + };
>>> +
>>> + resetswi...@0c003000 {
>>> + compatible = "nintendo,hollywood-resetswitch";
>>> + reg = <0x0c003000 0x4>;
>> That's the same address. Don't do that.
>>
>> Create a flipper-processor-interface node for the whole 3000
>> block (size 100)? You can hang the PIC as a subnode under it,
>> without a "reg".
>
> Yeah.
>
Agreed.
>>> + /* Team Twiizers' 'mini' firmware IPC */
>>> + m...@0d00 {
>> Although mini is awesome, it isn't hardware, and doesn't
>> belong in the device tree.
>
> So what is at d000 ?
>
There you can find the hardware interface that supports the IPC mechanism.
It is made up of a pair of registers to pass data between the processors and a
pair of control/flags registers.
The hardware can interrupt the PowerPC side when there is data available for it.
>>> + ser...@0d006400 {
>>> + compatible = "nintendo,hollywood-serial";
>> You might want to pick a more descriptive name for this,
>> "serial" is usually understaood to mean "RS232". Which
>> this isn't.
>
> What is it then ? You definitely want some other name if it's not
> classic rs232 style serial.
>
It is what Nintendo calls the "Serial Interface" (SI) which is a proprietary
serial hardware to drive the gamepads (and a custom keyboard too, once
available for an RPG game).
> Cheers,
> Ben.
>
Thanks,
Albert
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: fsl diu, edid info and i2c platform data
Forgot the patch.
Kári Davíðsson wrote:
Hi,
I am messing about with the fsl-diu-fb.c which handles the display on mpc512x
platforms.
The display panels we are using provide EDID information and I would like to
use that to setup
the display modes etc. The current fsl-diu-fb.c is hard coding display modes
into the driver.
I have started this and it is working more or less but I appreciate all input
from more knowledgeable people
about how to do this "correctly" with the aim that others could benefit.
I have the feeling I am not approaching this correctly.
One option I was looking into was to use platform data for the i2c edid driver,
e.g. for the platform to provide
default fb_mode. But I have a big problem on how to attach the platform data to
the i2cedid driver.
I tried few options and while I think using code like :
np = of_find_compatible_node( NULL, NULL, "vesa,edid" );
if( np )
{
struct i2c_client * tsc2007 = NULL;
//tsc2007 = of_find_i2c_device_by_node( np );
if( tsc2007 )
{
tsc2007->dev.platform_data = &v39_edid_data;
put_device( &tsc2007->dev );
}
of_node_put( np );
}
is the correct way to do it. The function of_find_i2c_device_by_node() hangs
the kernel.
Attached is the patch as I have it now. It compiles and works on our custom
mpc5121 board for two different LCD panels.
rg
kd
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
diff --git a/arch/powerpc/boot/dts/v39.dts b/arch/powerpc/boot/dts/v39.dts
new file mode 100644
index 000..c5a5eec
--- /dev/null
+++ b/arch/powerpc/boot/dts/v39.dts
@@ -0,0 +1,285 @@
+/*
+ * V39 Device Tree Source
+ *
+ * Copyright 2009 Marel ehf.
+ * Copyright 2007,2008 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.
+ */
+
+/dts-v1/;
+
+/ {
+ model = "v39";
+ compatible = "marel,v39";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,5...@0 {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <0x20>; // 32 bytes
+ i-cache-line-size = <0x20>; // 32 bytes
+ d-cache-size = <0x8000>; // L1, 32K
+ i-cache-size = <0x8000>; // L1, 32K
+ timebase-frequency = <4950>;// 49.5 MHz (csb/4)
+ bus-frequency = <19800>; // 198 MHz csb bus
+ clock-frequency = <39600>; // 396 MHz ppc core
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x1000>; // 256MB at 0
+ };
+
+ m...@2000 {
+ compatible = "fsl,mpc5121-mbx";
+ reg = <0x2000 0x4000>;
+ interrupts = <66 0x8>;
+ interrupt-parent = < &ipic >;
+ };
+
+ s...@3000 {
+ compatible = "fsl,mpc5121-sram";
+ reg = <0x3000 0x2>; // 128K at 0x3000
+ };
+
+ s...@8000 {
+ compatible = "fsl,mpc5121-immr";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ ranges = <0x0 0x8000 0x40>;
+ reg = <0x8000 0x40>;
+ bus-frequency = <6600>; // 66 MHz ips bus
+
+
+ // IPIC
+ // interrupts cell =
+ // sense values match linux IORESOURCE_IRQ_* defines:
+ // sense == 8: Level, low assertion
+ // sense == 2: Edge, high-to-low change
+ //
+ ipic: interrupt-control...@c00 {
+ compatible = "fsl,mpc5121-ipic", "fsl,ipic";
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <0xc00 0x100>;
+ };
+
+ r...@a00 { // Real time clock
+ compatible = "fsl,mpc5121-rtc";
+ reg = <0xa00 0x100>;
+ interrupts = <79 0x8 80 0x8>;
+ interrupt-parent = < &ipic >;
+ };
+
+ cl...@f00 { // Clock control
+ compatible = "fsl,mpc5121-clock";
+ reg = <0xf00 0x100>;
+ };
+
+/*
+ g...@1100 {
+ compatible = "fsl,mpc5121-gpio";
+ reg = <0x1100 0x100>;
+ interrupts = <78 0x8>;
+ interrupt-parent = < &ipic >;
+ };
+*/
+
+ ms...@1300 {
+ compatible = "fsl,mpc5121-mscan";
+ cell-index = <0>;
+ interrupts = <12 0x8>;
+ interrupt-parent = < &ipic >;
+ reg = <0x1300 0x80>;
+ clock-ipb;
+ };
+
+ ms...@1380 {
+ compatible = "fsl,mpc5121-mscan";
+ cell-index = <1>;
+ interrupts = <13 0x8>;
+ interrupt-parent = < &ipic >;
+ reg = <0x1380 0x80>;
+ clock-ipb;
+ };
+
+ edidbus: i...@1700 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5121-i2c", "fsl-i2c";
+ cell-index = <0>;
+ reg = <0x1700 0x20>;
+ interrupts = <9 0x8>;
+ interrupt-parent = < &ipic >;
+ fsl5200-clocking;
+ edid: e...@50 {
+compatible = "vesa,edid";
+reg = <0x50>;
+ };
+ };
+
+ i...@1720 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5121-i2c", "fsl-i2c";
+ cell-index = <1>;
+ reg =
Re: [RFC PATCH 04/19] powerpc: wii: device tree
Benjamin Herrenschmidt wrote:
> On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
>
>> +/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O area) */
>> +/memreserve/ 0x1000 0x0004000; /* DSP RAM */
>
> Weird layout... nothing you can do about I suppose.
>
> Out of curiosity, what is that DSP RAM ? Some actual DSP core somewhere
> in the IO chip setup to use memory from up there ?
>
Yes, there's a DSP used normally for audio purposes.
> I'll skip on some things that I'm sure others will have commented
> about :-)
>
Ok :)
>> +/*
>> + * The Nintendo Wii has two discontiguous RAM memory areas called
>> + * MEM1 and MEM2.
>> + * MEM1 starts at 0x and contains 24MB of 1T-SRAM.
>> + * MEM2 starts at 0x1000 and contains 64MB of DDR2 RAM.
>> + * Between both memory address ranges there is an address space
>> + * where memory-mapped I/O registers are found.
>> + *
>> + * Currently, Linux 32-bit PowerPC does not support RAM in
>> + * discontiguous memory address spaces. Thus, in order to use
>> + * both RAM areas, we declare as RAM the range from the start of
>> + * MEM1 to the end of useable MEM2 and exclude the needed parts
>> + * with /memreserve/ statements, at the expense of wasting a bit
>> + * of memory.
>> + */
>> +memory {
>> +device_type = "memory";
>> +/* MEM1 + memory hole + MEM2 - firmware/buffers area */
>> +reg = <0x 0x133e>;
>> +};
>
> So we do have a nasty hole here in the middle. How bad it is if you try
> to just have two ranges in there (ie as if it was discontiguous) ? We
> shouldn't be far from being able to do discontig mem actually, should be
> easy enough to fix. Tho I don't have (yet) the HW :-) (I'm tempted...)
>
My plan is to just put the two ranges on the device tree (to reflect the actual
hardware) and coalesce them in the fixup function of the bootwrapper.
Then add the needed reservations and hacks to make that work (mmu_mapin_ram /
ioremap).
> Same comment as other discussions about the framebuffer here.
>
Ok.
>> +cpus {
>> +#cpus = <1>;
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +PowerPC,broad...@0 {
>> +device_type = "cpu";
>> +reg = <0>;
>> +clock-frequency = <72900>; /* 729MHz */
>> +bus-frequency = <24300>; /* 243MHz core-to-bus 3x */
>> +timebase-frequency = <6075>; /* 243MHz / 4 */
>> +i-cache-line-size = <32>;
>> +d-cache-line-size = <32>;
>> +i-cache-size = <32768>;
>> +d-cache-size = <32768>;
>> +};
>> +};
>> +
>> +/* devices contained in the hollywood chipset */
>> +soc {
>
> Call it "hollywood"
>
I like that too. Simple and effective.
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +#interrupt-cells = <1>;
>> +model = "hollywood";
>> +compatible = "nintendo,hollywood";
>> +clock-frequency = <24300>; /* 243MHz */
>> +ranges = <0x0c00 0x0c00 0x0001
>> + 0x0d00 0x0d00 0x0001
>> + 0x0d04 0x0d04 0x0005
>> + 0x0d80 0x0d80 0x1000
>> + 0x133e 0x133e 0x00c2>;
>> +
>> +vi...@0c002000 {
>> +compatible = "nintendo,hollywood-video";
>> +reg = <0x0c002000 0x100>;
>> +interrupts = <8>;
>> +interrupt-parent = <&PIC0>;
>> +};
>> +
>> +PIC0: p...@0c003000 {
>> +#interrupt-cells = <1>;
>> +compatible = "nintendo,flipper-pic";
>> +reg = <0x0c003000 0x8>;
>> +interrupt-controller;
>> +};
>> +
>> +resetswi...@0c003000 {
>> +compatible = "nintendo,hollywood-resetswitch";
>> +reg = <0x0c003000 0x4>;
>> +interrupts = <1>;
>> +interrupt-parent = <&PIC0>;
>> +};
>> +
>> +au...@0c005000 {
>> +compatible = "nintendo,hollywood-audio";
>> +reg = <0x0c005000 0x200 /* DSP */
>> + 0x0d006c00 0x20>;/* AI */
>> +interrupts = <6>;
>> +interrupt-parent = <&PIC0>;
>> +};
>> +
>> +/* Team Twiizers' 'mini' firmware IPC */
>
> Out of curiosity, what are these ? :-)
>
Those are the guys behind most Wii hacking efforts.
>> +m...@0d00 {
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +#interrupt
fsl diu, edid info and i2c platform data
Hi,
I am messing about with the fsl-diu-fb.c which handles the display on mpc512x
platforms.
The display panels we are using provide EDID information and I would like to
use that to setup
the display modes etc. The current fsl-diu-fb.c is hard coding display modes
into the driver.
I have started this and it is working more or less but I appreciate all input
from more knowledgeable people
about how to do this "correctly" with the aim that others could benefit.
I have the feeling I am not approaching this correctly.
One option I was looking into was to use platform data for the i2c edid driver,
e.g. for the platform to provide
default fb_mode. But I have a big problem on how to attach the platform data to
the i2cedid driver.
I tried few options and while I think using code like :
np = of_find_compatible_node( NULL, NULL, "vesa,edid" );
if( np )
{
struct i2c_client * tsc2007 = NULL;
//tsc2007 = of_find_i2c_device_by_node( np );
if( tsc2007 )
{
tsc2007->dev.platform_data = &v39_edid_data;
put_device( &tsc2007->dev );
}
of_node_put( np );
}
is the correct way to do it. The function of_find_i2c_device_by_node() hangs
the kernel.
Attached is the patch as I have it now. It compiles and works on our custom
mpc5121 board for two different LCD panels.
rg
kd
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PPC: Sync guest visible MMU state
On 11/26/2009 03:16 PM, Alexander Graf wrote: You can keep pvr out of the (named) union. So we'd have sregs.padded.ppc64.slb? or sregs.u.ppc64.slb. I don't see how that is an improvement. Buildability takes precedence. (an alternative is to drop the union, and add a BUILD_BUG_ON(sizeof...)). -- error compiling committee.c: too many arguments to function ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PPC: Sync guest visible MMU state
Avi Kivity wrote: > On 11/26/2009 02:46 PM, Alexander Graf wrote: >> >>> Please avoid unnamed unions in user-visible headers - they're a gcc >>> extension. >>> >>> Yes, we have them elsewhere, but let's not add to the pile. >>> >> I'm open to scalable suggestions that don't break existing userspace >> code. >> If I name the union now, existing qemu code will break. If I align the >> pad array manually I'll definitely mess up something. >> > > You can keep pvr out of the (named) union. So we'd have sregs.padded.ppc64.slb? I don't see how that is an improvement. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PPC: Sync guest visible MMU state
On 11/26/2009 02:46 PM, Alexander Graf wrote: Please avoid unnamed unions in user-visible headers - they're a gcc extension. Yes, we have them elsewhere, but let's not add to the pile. I'm open to scalable suggestions that don't break existing userspace code. If I name the union now, existing qemu code will break. If I align the pad array manually I'll definitely mess up something. You can keep pvr out of the (named) union. -- error compiling committee.c: too many arguments to function ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PPC: Sync guest visible MMU state
Avi Kivity wrote:
> On 11/26/2009 01:16 PM, Alexander Graf wrote:
>> Currently userspace has no chance to find out which virtual address
>> space we're
>> in and resolve addresses. While that is a big problem for migration,
>> it's also
>> unpleasent when debugging, as gdb and the monitor don't work on virtual
>> addresses.
>>
>> This patch exports enough of the MMU segment state to userspace to make
>> debugging work and thus also includes the groundwork for migration.
>>
>>
>> struct kvm_sregs {
>> -__u32 pvr;
>> -char pad[1020];
>> +union {
>> +struct {
>> +__u32 pvr;
>> +__u64 sdr1;
>> +struct {
>> +struct {
>> +__u64 slbe;
>> +__u64 slbv;
>> +} slb[64];
>> +} ppc64;
>> +struct {
>> +__u32 sr[16];
>> +__u64 ibat[8];
>> +__u64 dbat[8];
>> +} ppc32;
>> +};
>> +__u8 pad[1024];
>> +};
>> };
>>
>
> Please avoid unnamed unions in user-visible headers - they're a gcc
> extension.
>
> Yes, we have them elsewhere, but let's not add to the pile.
I'm open to scalable suggestions that don't break existing userspace code.
If I name the union now, existing qemu code will break. If I align the
pad array manually I'll definitely mess up something.
Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PPC: Sync guest visible MMU state
On 11/26/2009 01:16 PM, Alexander Graf wrote:
Currently userspace has no chance to find out which virtual address space we're
in and resolve addresses. While that is a big problem for migration, it's also
unpleasent when debugging, as gdb and the monitor don't work on virtual
addresses.
This patch exports enough of the MMU segment state to userspace to make
debugging work and thus also includes the groundwork for migration.
struct kvm_sregs {
- __u32 pvr;
- char pad[1020];
+ union {
+ struct {
+ __u32 pvr;
+ __u64 sdr1;
+ struct {
+ struct {
+ __u64 slbe;
+ __u64 slbv;
+ } slb[64];
+ } ppc64;
+ struct {
+ __u32 sr[16];
+ __u64 ibat[8];
+ __u64 dbat[8];
+ } ppc32;
+ };
+ __u8 pad[1024];
+ };
};
Please avoid unnamed unions in user-visible headers - they're a gcc
extension.
Yes, we have them elsewhere, but let's not add to the pile.
struct kvm_fpu {
diff --git a/arch/powerpc/include/asm/kvm_asm.h
b/arch/powerpc/include/asm/kvm_asm.h
index 19ddb35..af2abe7 100644
--- a/arch/powerpc/include/asm/kvm_asm.h
+++ b/arch/powerpc/include/asm/kvm_asm.h
@@ -87,6 +87,7 @@
#define BOOK3S_IRQPRIO_MAX16
#define BOOK3S_HFLAG_DCBZ32 0x1
+#define BOOK3S_HFLAG_SLB 0x2
#define RESUME_FLAG_NV (1<<0) /* Reload guest nonvolatile state? */
#define RESUME_FLAG_HOST(1<<1) /* Resume host? */
diff --git a/arch/powerpc/include/asm/kvm_book3s.h
b/arch/powerpc/include/asm/kvm_book3s.h
index c601133..74b7369 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -46,6 +46,7 @@ struct kvmppc_sr {
};
struct kvmppc_bat {
+ u64 raw;
u32 bepi;
u32 bepi_mask;
bool vs;
@@ -113,6 +114,8 @@ extern struct kvmppc_pte *kvmppc_mmu_find_pte(struct
kvm_vcpu *vcpu, u64 ea, boo
extern int kvmppc_ld(struct kvm_vcpu *vcpu, ulong eaddr, int size, void *ptr,
bool data);
extern int kvmppc_st(struct kvm_vcpu *vcpu, ulong eaddr, int size, void *ptr);
extern void kvmppc_book3s_queue_irqprio(struct kvm_vcpu *vcpu, unsigned int
vec);
+extern void kvmppc_set_bat(struct kvm_vcpu *vcpu, struct kvmppc_bat *bat,
+ bool upper, u32 val);
extern u32 kvmppc_trampoline_lowmem;
extern u32 kvmppc_trampoline_enter;
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 42037d4..650ebf8 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -281,6 +281,7 @@ void kvmppc_core_deliver_interrupts(struct kvm_vcpu *vcpu)
void kvmppc_set_pvr(struct kvm_vcpu *vcpu, u32 pvr)
{
+ vcpu->arch.hflags&= ~BOOK3S_HFLAG_SLB;
vcpu->arch.pvr = pvr;
if ((pvr>= 0x33)&& (pvr< 0x7033)) {
kvmppc_mmu_book3s_64_init(vcpu);
@@ -762,14 +763,60 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu,
struct kvm_regs *regs)
int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
struct kvm_sregs *sregs)
{
+ int i;
+
sregs->pvr = vcpu->arch.pvr;
+
+ sregs->sdr1 = to_book3s(vcpu)->sdr1;
+ if (vcpu->arch.hflags& BOOK3S_HFLAG_SLB) {
+ for (i = 0; i< 64; i++) {
+ sregs->ppc64.slb[i].slbe =
to_book3s(vcpu)->slb[i].orige | i;
+ sregs->ppc64.slb[i].slbv =
to_book3s(vcpu)->slb[i].origv;
+ }
+ } else {
+ for (i = 0; i< 16; i++) {
+ sregs->ppc32.sr[i] = to_book3s(vcpu)->sr[i].raw;
+ sregs->ppc32.sr[i] = to_book3s(vcpu)->sr[i].raw;
+ }
+ for (i = 0; i< 8; i++) {
+ sregs->ppc32.ibat[i] = to_book3s(vcpu)->ibat[i].raw;
+ sregs->ppc32.dbat[i] = to_book3s(vcpu)->dbat[i].raw;
+ }
+ }
return 0;
}
int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
struct kvm_sregs *sregs)
{
+ int i;
+
kvmppc_set_pvr(vcpu, sregs->pvr);
+
+ to_book3s(vcpu)->sdr1 = sregs->sdr1;
+ if (vcpu->arch.hflags& BOOK3S_HFLAG_SLB) {
+ for (i = 0; i< 64; i++) {
+ vcpu->arch.mmu.slbmte(vcpu, sregs->ppc64.slb[i].slbv,
+ sregs->ppc64.slb[i].slbe);
+ }
+ } else {
+ for (i = 0; i< 16; i++) {
+ vcpu->arch.mmu.mtsrin(vcpu, i, sregs->ppc32.sr[i]);
+ }
+ for (i = 0; i< 8; i++) {
+
Re: [PATCH 00/11] Yet another series of OF merge patches.
On Tue, Nov 24, 2009 at 01:17:41AM -0700, Grant Likely wrote: > Nothing much to say here other than mostly mechanical merging of OF > support code. Some of it remains a little ugly, but I'm taking the > approach of merging the code first, and refactoring it second. > > I've pushed this series out to my test-devicetree branch on my git > server if anyone wants to test. That branch also includes the > previous 2 patch series that I've sent out. > > git://git.secretlab.ca/git/linux-2.6 test-devicetree > > Compile tested on: ppc64, ppc32, microblaze, sparc64, sparc32. > Boot tested on mpc5200 (ppc32) platform. test-devicetree as of today also works fine on my phyCORE-MPC5200B-IO. Tested-by: Wolfram Sang -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: spi_mpc8xxx.c: chip select polarity problem
On Wed, Nov 25, 2009 at 03:11:57PM -0700, Grant Likely wrote: > On Wed, Nov 25, 2009 at 1:41 PM, Torsten Fleischer > wrote: > > On Wen, Nov 25, 2009 at 01:33:57 Grant Likely wrote: > >> Thanks. However, there needs to be a proper description of what this > >> patch does to go in the commit header. Can you please write one? > >> > >> Thanks, > >> g. > >> > > [...] > > > > The initialization of the chip selects is removed from the probe() function > > of > > the spi_mpc8xxx driver, because the driver doesn't know the polarity of the > > chip selects of the SPI devices at the time of its initialization. > > > > For this reason the initialization of the several chip selects is postponed > > to the point of time when the very first SPI transfer to the associated > > device > > occurs. > > > > > > Signed-off-by: Torsten Fleischer > > Ah. I understand what you're doing now. Hmmm. This approach > concerns me because it relies on firmware or platform code to get CS > gpios set up properly before the driver is probed. Yes, that was said at the very beginning of this thread. > Firmware doesn't > always get it right, and I prefer to avoid platform specific setups as > much as possible. Why can't the CS polarity be encoded into the > device tree so the driver *does* have the polarity data at probe time? We have the spi-cs-high property, but it duplicates compatible property. 'compatible' is enough to tell whether some device has cs-high or cs-low (device's driver knows that already). The problem is that SPI bus master doesn't know all the devices, so it can't extract that information from the compatible string. To workaround that we can use 'spi-cs-high', but that's ugly workaround. SPI modes (0,1,2,3) is another matter, some devices can work in several modes, so 'spi-cpol' and 'spi-cpha' are actually useful. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] PPC: Sync guest visible MMU state
Currently userspace has no chance to find out which virtual address space we're
in and resolve addresses. While that is a big problem for migration, it's also
unpleasent when debugging, as gdb and the monitor don't work on virtual
addresses.
This patch exports enough of the MMU segment state to userspace to make
debugging work and thus also includes the groundwork for migration.
Signed-off-by: Alexander Graf
---
Ben, please take this patch in your tree.
---
arch/powerpc/include/asm/kvm.h| 20 -
arch/powerpc/include/asm/kvm_asm.h|1 +
arch/powerpc/include/asm/kvm_book3s.h |3 ++
arch/powerpc/kvm/book3s.c | 47 +
arch/powerpc/kvm/book3s_64_emulate.c | 38 --
arch/powerpc/kvm/book3s_64_mmu.c |2 +
arch/powerpc/kvm/powerpc.c|3 ++
include/linux/kvm.h |3 ++
8 files changed, 100 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index c9ca97f..bc0aeba 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -46,8 +46,24 @@ struct kvm_regs {
};
struct kvm_sregs {
- __u32 pvr;
- char pad[1020];
+ union {
+ struct {
+ __u32 pvr;
+ __u64 sdr1;
+ struct {
+ struct {
+ __u64 slbe;
+ __u64 slbv;
+ } slb[64];
+ } ppc64;
+ struct {
+ __u32 sr[16];
+ __u64 ibat[8];
+ __u64 dbat[8];
+ } ppc32;
+ };
+ __u8 pad[1024];
+ };
};
struct kvm_fpu {
diff --git a/arch/powerpc/include/asm/kvm_asm.h
b/arch/powerpc/include/asm/kvm_asm.h
index 19ddb35..af2abe7 100644
--- a/arch/powerpc/include/asm/kvm_asm.h
+++ b/arch/powerpc/include/asm/kvm_asm.h
@@ -87,6 +87,7 @@
#define BOOK3S_IRQPRIO_MAX 16
#define BOOK3S_HFLAG_DCBZ320x1
+#define BOOK3S_HFLAG_SLB 0x2
#define RESUME_FLAG_NV (1<<0) /* Reload guest nonvolatile state? */
#define RESUME_FLAG_HOST(1<<1) /* Resume host? */
diff --git a/arch/powerpc/include/asm/kvm_book3s.h
b/arch/powerpc/include/asm/kvm_book3s.h
index c601133..74b7369 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -46,6 +46,7 @@ struct kvmppc_sr {
};
struct kvmppc_bat {
+ u64 raw;
u32 bepi;
u32 bepi_mask;
bool vs;
@@ -113,6 +114,8 @@ extern struct kvmppc_pte *kvmppc_mmu_find_pte(struct
kvm_vcpu *vcpu, u64 ea, boo
extern int kvmppc_ld(struct kvm_vcpu *vcpu, ulong eaddr, int size, void *ptr,
bool data);
extern int kvmppc_st(struct kvm_vcpu *vcpu, ulong eaddr, int size, void *ptr);
extern void kvmppc_book3s_queue_irqprio(struct kvm_vcpu *vcpu, unsigned int
vec);
+extern void kvmppc_set_bat(struct kvm_vcpu *vcpu, struct kvmppc_bat *bat,
+ bool upper, u32 val);
extern u32 kvmppc_trampoline_lowmem;
extern u32 kvmppc_trampoline_enter;
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 42037d4..650ebf8 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -281,6 +281,7 @@ void kvmppc_core_deliver_interrupts(struct kvm_vcpu *vcpu)
void kvmppc_set_pvr(struct kvm_vcpu *vcpu, u32 pvr)
{
+ vcpu->arch.hflags &= ~BOOK3S_HFLAG_SLB;
vcpu->arch.pvr = pvr;
if ((pvr >= 0x33) && (pvr < 0x7033)) {
kvmppc_mmu_book3s_64_init(vcpu);
@@ -762,14 +763,60 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu,
struct kvm_regs *regs)
int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
struct kvm_sregs *sregs)
{
+ int i;
+
sregs->pvr = vcpu->arch.pvr;
+
+ sregs->sdr1 = to_book3s(vcpu)->sdr1;
+ if (vcpu->arch.hflags & BOOK3S_HFLAG_SLB) {
+ for (i = 0; i < 64; i++) {
+ sregs->ppc64.slb[i].slbe =
to_book3s(vcpu)->slb[i].orige | i;
+ sregs->ppc64.slb[i].slbv =
to_book3s(vcpu)->slb[i].origv;
+ }
+ } else {
+ for (i = 0; i < 16; i++) {
+ sregs->ppc32.sr[i] = to_book3s(vcpu)->sr[i].raw;
+ sregs->ppc32.sr[i] = to_book3s(vcpu)->sr[i].raw;
+ }
+ for (i = 0; i < 8; i++) {
+ sregs->ppc32.ibat[i] = to_book3s(vcpu)->ibat[i].raw;
+ sregs->ppc32.dbat[i] = to_book3s(vcpu)->dbat[i].raw;
+ }
+ }
return 0;
}
int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
st
Re: [PATCH] Reserve memory for kdump kernel within RMO region
On 11/26/2009 12:22 AM, Bernhard Walle wrote: M. Mohan Kumar schrieb: Reserve memory for kdump kernel within RMO region When the kernel size exceeds 32MB(observed with some distros), memory for kdump kernel can not be reserved as kdump kernel base is assumed to be 32MB always. When the kernel has CONFIG_RELOCATABLE option enabled, provide the feature to reserve the memory for kdump kernel anywhere in the RMO region. Hi Bernhard, Correct me if I'm wrong, but: CONFIG_RELOCATABLE is for the kernel that gets loaded as crashkernel, not for the kernel that loads the crashkernel. So it would be perfectly fine that a kernel that has not CONFIG_RELOCATABLE set would load another kernel that has CONFIG_RELOCATABLE set on an address != 32 M. No, with relocatable option, the same kernel is used as both production and kdump kernel. If the kernel is not relocatable, kdump kernel can be loaded *only at* 32MB. So if a kernel has RELOCATABLE option enabled and by chance if the production kernel size is beyond 32MB, current code will not load the kdump kernel at 32MB as current kernel overlaps with kdump kernel region. So if the kernel has RELOCATABLE option, we could reserve memory for kdump kernel within RMO region. So it would be part of the command line to determine whether a fixed or a variable address is used. The system configuration (or the admin) knows both: if the kernel that should be loaded is relocatable (can be detected with the x86 bzImage header or with the ELF type for vmlinux) and it can also influence the boot command line. To sum it up: I'm not against reserving it anywhere, I'm only against making it dependent on CONFIG_RELOCATABLE which has another function. Regards, Bernhard ___ kexec mailing list ke...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] zlib: Optimize inffast when copying direct from output
Benjamin Herrenschmidt wrote on 26/11/2009 09:46:58: > > On Thu, 2009-11-26 at 09:30 +0100, Joakim Tjernlund wrote: > > > I'm not sure its going to work to use get_unaligned() like that on all > > > archs .. it might be definitely something to discuss on some more > > > appropriate mailing list. > > > > Oh, why not? Is that because I am using it wrongly or because xx_unaligned > > is impl. incorrectly on some archs? > > I'm just not sure it works in boot wrappers in case archs ... I suppose > it does but I haven't actually checked :-) I am not aware of other boot wrappers than PowerPC and I believe ppc should handle it as unaligned accesses aren't a problem there. Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] zlib: Optimize inffast when copying direct from output
On Thu, 2009-11-26 at 09:30 +0100, Joakim Tjernlund wrote: > > I'm not sure its going to work to use get_unaligned() like that on all > > archs .. it might be definitely something to discuss on some more > > appropriate mailing list. > > Oh, why not? Is that because I am using it wrongly or because xx_unaligned > is impl. incorrectly on some archs? I'm just not sure it works in boot wrappers in case archs ... I suppose it does but I haven't actually checked :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 03/19] powerpc: gamecube: bootwrapper bits
On Thu, 2009-11-26 at 09:17 +0100, Gabriel Paubert wrote: > > > They should hopefully... as long as you don't rely on the reservation > > blowing as a result of a DMA write. > > Hmm, this really depends on whether the DMA transfers generate bus cycles > that require coherency or not. Not the other way around. M=1 only forces > bus cycles to be snooped by other processors (asserting the GBL signal > on 603/604/750 busses). You are absolutely right. Which makes it even more likely that lwarx/stwcx. won't care unless the L2 cache plays tricks. > The host bridge is free to systematically snoop processor accesses (to make > sure that data queued in the bridge and not yet written to memory is seen > in the coherent memory domain even if, for example, interrupts propagate > so fast that DMA target addresses are accessed before it is written to RAM). > > On memory coherent systems, the host bridge has to assert the GBL signal, > to force data to be written to memory (for most DMA accesses), or to > invalidate caches (for full line writes from devices). Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[-next Nov 25] eHEA driver failure during boot.
eHEA driver fails to initialize on a power6 box while booting 20091125 next(f3645ca..). Following are the messages which gets logged during failure. Unable to handle kernel paging request for data at address 0x409d0148e8e40018 Faulting instruction address: 0xc003c0cc Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=1024 NUMA pSeries Modules linked in: fuse loop dm_mod sr_mod cdrom ehea sg sd_mod crc_t10dif ibmvscsic scsi_transport_srp scsi_tgt scsi_mod NIP: c003c0cc LR: c003ce50 CTR: 00091b94 REGS: ccade820 TRAP: 0300 Not tainted (2.6.32-rc8-autotest-next-20091125) MSR: 80001032 CR: 28020424 XER: 0020 DAR: 409d0148e8e40018, DSISR: 4000 TASK = cc818d60[1683] 'ip' THREAD: ccadc000 CPU: 1 GPR00: 0010 ccadeaa0 c0b28340 409d0148e8e40008 GPR04: d8008000f040 ccadeb20 1000 GPR08: 001c c18c0398 c0bc GPR12: 80009032 c0bc2880 GPR16: 203c8fc0 ccadf4a8 ccadf450 ce4c GPR20: 0300 0201 c0c68590 c0bc GPR24: 00e5f87e 0001 c992 GPR28: d8008000f040 c0a63328 NIP [c003c0cc] .subpage_protection+0x48/0x8c LR [c003ce50] .hash_page+0x3e0/0x45c Call Trace: [ccadeaa0] [] 0x (unreliable) [ccadeb90] [c00055d0] .do_hash_page+0x50/0x6c --- Exception: 301 at .ehea_create_cq+0x234/0x2bc [ehea] LR = .ehea_create_cq+0x1c0/0x2bc [ehea] [ccadef40] [d15e46fc] .ehea_init_port_res+0xb4/0x47c [ehea] [ccadf000] [d15e4bd8] .ehea_up+0x114/0x6bc [ehea] [ccadf110] [d15e51e0] .ehea_open+0x60/0x114 [ehea] [ccadf1b0] [c0542e7c] .dev_open+0x11c/0x19c [ccadf240] [c0541e7c] .dev_change_flags+0x10c/0x214 [ccadf2e0] [c054e0f8] .do_setlink+0x304/0x41c [ccadf3c0] [c054f324] .rtnl_newlink+0x388/0x600 [ccadf5d0] [c054ef50] .rtnetlink_rcv_msg+0x260/0x2ac [ccadf680] [c0568104] .netlink_rcv_skb+0x74/0x108 [ccadf710] [c054eccc] .rtnetlink_rcv+0x34/0x58 [ccadf7a0] [c0567bfc] .netlink_unicast+0x32c/0x408 [ccadf870] [c05688d8] .netlink_sendmsg+0x2d0/0x310 [ccadf950] [c0529c9c] .sock_sendmsg+0xe0/0x11c [ccadfb50] [c0529fc8] .SyS_sendmsg+0x1f4/0x288 [ccadfd70] [c0527f88] .SyS_socketcall+0x214/0x280 [ccadfe30] [c00085b4] syscall_exit+0x0/0x40 Instruction dump: 7820 7fa40040 409d0020 7889aae0 39290072 79291f24 7d2b4a14 e8690010 2fa3 419e0048 788014e2 78001f24 <7c63002a> 2fa3 419e0034 788084a2 ---[ end trace cacb4bbddb53f7bd ]--- Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] zlib: Optimize inffast when copying direct from output
Benjamin Herrenschmidt wrote on 24/11/2009 04:12:43: > > On Tue, 2009-11-10 at 10:00 +0100, Joakim Tjernlund wrote: > > JFFS2 uses lesser compression ratio and inflate always > > ends up in "copy direct from output" case. > > This patch tries to optimize the direct copy procedure. > > Uses get_unaligned() but only in one place. > > The copy loop just above this one can also use this > > optimization, but I havn't done so as I have not tested if it > > is a win there too. > > On my MPC8321 this is about 17% faster on my JFFS2 root FS > > than the original. > > --- > > > > Would like some testing of the PowerPC boot wrapper and > > a LE target before sending it upstream. > > Well, you should probably submit that patch to lkml then :-) I have(with LE fixes), Andrew Morton has it. > > I'm not sure its going to work to use get_unaligned() like that on all > archs .. it might be definitely something to discuss on some more > appropriate mailing list. Oh, why not? Is that because I am using it wrongly or because xx_unaligned is impl. incorrectly on some archs? Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 03/19] powerpc: gamecube: bootwrapper bits
On Thu, Nov 26, 2009 at 03:36:56PM +1100, Benjamin Herrenschmidt wrote: > On Tue, 2009-11-24 at 22:00 +0100, Segher Boessenkool wrote: > > > > Sure, the memory controllers don't do coherency. I'm slightly worried > > about two things: > > 1) Will the generic code use M=0 as well? Is it a problem if it > > doesn't? > > We can make it not do it. > > > 2) Do lwarx. etc. work in M=0? > > They should hopefully... as long as you don't rely on the reservation > blowing as a result of a DMA write. Hmm, this really depends on whether the DMA transfers generate bus cycles that require coherency or not. Not the other way around. M=1 only forces bus cycles to be snooped by other processors (asserting the GBL signal on 603/604/750 busses). The host bridge is free to systematically snoop processor accesses (to make sure that data queued in the bridge and not yet written to memory is seen in the coherent memory domain even if, for example, interrupts propagate so fast that DMA target addresses are accessed before it is written to RAM). On memory coherent systems, the host bridge has to assert the GBL signal, to force data to be written to memory (for most DMA accesses), or to invalidate caches (for full line writes from devices). Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/mm: honor O_SYNC flag for memory mapping
There was no way to set mapped memory as cacheable if the memory
is not managed by Linux kernel. It's not rare in real system to
allocate some dedicated memory to a certain application which is not
managed by kernel and then mmap'ed the memory to the application.
The memory should be cacheable but we can't map it to be cacheable
due to the intelligent setting of cacheability.
The patch makes the cacheability depend on O_SYNC flag of the file
mapped for non-kernel managed memory. Also prints a deprecation
warning for mmap users without using O_SYNC.
Signed-off-by: Li Yang
---
arch/powerpc/mm/mem.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 579382c..b9ef77a 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -101,8 +101,17 @@ pgprot_t phys_mem_access_prot(struct file *file, unsigned
long pfn,
if (ppc_md.phys_mem_access_prot)
return ppc_md.phys_mem_access_prot(file, pfn, size, vma_prot);
- if (!page_is_ram(pfn))
- vma_prot = pgprot_noncached(vma_prot);
+ /* kernel managed memory is always cacheable, otherwise is controlled
+* by O_SYNC flag of open() */
+ if (!page_is_ram(pfn)) {
+ if (file->f_flags & O_SYNC)
+ vma_prot = pgprot_noncached(vma_prot);
+ else
+ printk(KERN_WARNING
+ "Warning: mmap on file without O_SYNC will be "
+ "mapped as cacheable. Make sure it is desired."
+ "\n");
+ }
return vma_prot;
}
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 04/11] of/flattree: eliminate cell_t typedef
Right, that's the only sane way to do it, I just didn't remember off hand what was said in the OF spec :-) 3.2.2.1.2 Property values The property-encoding format is independent of hardware byte order and alignment characteristics. The encoded byte order is well-defined (in particular, it is big endian). ... ... -- 32-bit integer. A 32-bit integer is encoded into a property value byte array by storing the most significant byte at the next available address, followed (at address+1) by the high middle byte, the low middle byte, and (at address+3) the least significant byte. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
