* Re: [PATCH] [PPC4xx] Fix device tree dts file for katmai board.
From: Stefan Roese @ 2009-11-26 7:22 UTC (permalink / raw)
To: Pravin Bathija; +Cc: linuxppc-dev
In-Reply-To: <1259017573-27985-1-git-send-email-pbathija@amcc.com>
On Tuesday 24 November 2009 00:06:13 Pravin Bathija wrote:
> Description: Set PCI-E node inbound DMA ranges size to 4GB for correct
> boot up of katmai. Including only changes for PCI-E DMA ranges as
> suggested by Stefan.
>
> Signed-off-by: Pravin Bathija <pbathija@amcc.com>
> Acked-by: Feng Kan <fkan@amcc.com>
> Acked-by: Prodyut Hazarika <phazarika@amcc.com>
> Acked-by: Loc Ho <lho@amcc.com>
> Acked-by: Tirumala Reddy Marri <tmarri@amcc.com>
> Acked-by: Victor Gallardo <vgallardo@amcc.com>
Acked-by: Stefan Roese <sr@denx.de>
Cheers,
Stefan
^ permalink raw reply
* Re: [RFC] powerpc/mm: honor O_SYNC flag for memory map
From: Li Yang @ 2009-11-26 7:43 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev, Li Yang-R58472
In-Reply-To: <20091125113023.GC12738@iram.es>
On Wed, Nov 25, 2009 at 7:30 PM, Gabriel Paubert <paubert@iram.es> wrote:
> On Wed, Nov 25, 2009 at 04:07:46PM +0800, Li Yang wrote:
>> On Sun, Nov 22, 2009 at 4:01 AM, Segher Boessenkool
>> <segher@kernel.crashing.org> wrote:
>> >>> You need to be a bit more careful tho. You must not allow RAM manage=
d by
>> >>> the kernel to be mapped non-cachable.
>> >>
>> >> Even if the user explicitly sets the O_SYNC flag? =C2=A0IMHO, it's a =
bug of
>> >> the application if it uses O_SYNC on main memory to be mmap'ed later.
>> >> And we don't need to cover up the bug.
>> >
>> > Is that "embedded thinking"? =C2=A0Conflicts like this cause machine c=
hecks or
>> > checkstops on many PowerPC implementations, we do not normally allow s=
uch
>> > to be caused by userland.
>>
>> 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? =C2=A0This is new to me. =C2=A0Could you elaborat=
e a bit?
>
> That's called cache paradoxes. And yes they may be a problem.
Thanks. I will prevent this from happening.
>
> Besides that, existing =C2=A0application may have used mmap without O_SYN=
C on
> I/O devices, knowing that the kernel would map them uncached. Your
> patch would break them by using cached accesses (and it can cause
> really hard to debug lockups, I've seen this, probably caused by
> infinite retries on the PCI bus).
That's my concern too. But after all mmap without O_SYNC on I/O
devices should be deprecated. A warning message in deprecation period
could reduce potential problem caused by this change.
- Leo
^ permalink raw reply
* Re: [PATCH 04/11] of/flattree: eliminate cell_t typedef
From: Mitch Bradley @ 2009-11-26 7:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: sfr, microblaze-uclinux, devicetree-discuss, sparclinux,
linuxppc-dev, davem, M. Warner Losh
In-Reply-To: <1259219171.16367.331.camel@pasglop>
>
> 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.
^ permalink raw reply
* [PATCH] powerpc/mm: honor O_SYNC flag for memory mapping
From: Li Yang @ 2009-11-26 8:02 UTC (permalink / raw)
To: benh, linuxppc-dev
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 <leoli@freescale.com>
---
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
^ permalink raw reply related
* Re: [RFC PATCH 03/19] powerpc: gamecube: bootwrapper bits
From: Gabriel Paubert @ 2009-11-26 8:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <1259210216.16367.249.camel@pasglop>
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
^ permalink raw reply
* Re: [PATCH] zlib: Optimize inffast when copying direct from output
From: Joakim Tjernlund @ 2009-11-26 8:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1259032363.16367.108.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> 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
^ permalink raw reply
* [-next Nov 25] eHEA driver failure during boot.
From: Sachin Sant @ 2009-11-26 8:36 UTC (permalink / raw)
To: Linux/PPC Development
Cc: Stephen Rothwell, HERING2, linux-next, Jan-Bernd Themann
In-Reply-To: <20091125235333.37c425ec.sfr@canb.auug.org.au>
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: 0xc00000000003c0cc
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: c00000000003c0cc LR: c00000000003ce50 CTR: 0000000000091b94
REGS: c00000000cade820 TRAP: 0300 Not tainted (2.6.32-rc8-autotest-next-20091125)
MSR: 8000000000001032 <ME,IR,DR> CR: 28020424 XER: 00000020
DAR: 409d0148e8e40018, DSISR: 0000000040000000
TASK = c00000000c818d60[1683] 'ip' THREAD: c00000000cadc000 CPU: 1
GPR00: 0000000000000010 c00000000cadeaa0 c000000000b28340 409d0148e8e40008
GPR04: d00008008000f040 c00000000cadeb20 0000000000001000 0000000000000000
GPR08: 000000000000001c c0000000018c0398 0000000000000000 c000000000bc0000
GPR12: 8000000000009032 c000000000bc2880 00000000ffffffff ffffffffffffffff
GPR16: 00000000203c8fc0 c00000000cadf4a8 c00000000cadf450 c00000000e4c0000
GPR20: 0000000000000300 0000000000000201 c000000000c68590 c000000000bc0000
GPR24: 0000000000000000 0000000000e5f87e 0000000000000001 c000000009920000
GPR28: 0000000000000000 d00008008000f040 0000000000000000 c000000000a63328
NIP [c00000000003c0cc] .subpage_protection+0x48/0x8c
LR [c00000000003ce50] .hash_page+0x3e0/0x45c
Call Trace:
[c00000000cadeaa0] [00000000ffffffff] 0xffffffff (unreliable)
[c00000000cadeb90] [c0000000000055d0] .do_hash_page+0x50/0x6c
--- Exception: 301 at .ehea_create_cq+0x234/0x2bc [ehea]
LR = .ehea_create_cq+0x1c0/0x2bc [ehea]
[c00000000cadef40] [d0000000015e46fc] .ehea_init_port_res+0xb4/0x47c [ehea]
[c00000000cadf000] [d0000000015e4bd8] .ehea_up+0x114/0x6bc [ehea]
[c00000000cadf110] [d0000000015e51e0] .ehea_open+0x60/0x114 [ehea]
[c00000000cadf1b0] [c000000000542e7c] .dev_open+0x11c/0x19c
[c00000000cadf240] [c000000000541e7c] .dev_change_flags+0x10c/0x214
[c00000000cadf2e0] [c00000000054e0f8] .do_setlink+0x304/0x41c
[c00000000cadf3c0] [c00000000054f324] .rtnl_newlink+0x388/0x600
[c00000000cadf5d0] [c00000000054ef50] .rtnetlink_rcv_msg+0x260/0x2ac
[c00000000cadf680] [c000000000568104] .netlink_rcv_skb+0x74/0x108
[c00000000cadf710] [c00000000054eccc] .rtnetlink_rcv+0x34/0x58
[c00000000cadf7a0] [c000000000567bfc] .netlink_unicast+0x32c/0x408
[c00000000cadf870] [c0000000005688d8] .netlink_sendmsg+0x2d0/0x310
[c00000000cadf950] [c000000000529c9c] .sock_sendmsg+0xe0/0x11c
[c00000000cadfb50] [c000000000529fc8] .SyS_sendmsg+0x1f4/0x288
[c00000000cadfd70] [c000000000527f88] .SyS_socketcall+0x214/0x280
[c00000000cadfe30] [c0000000000085b4] syscall_exit+0x0/0x40
Instruction dump:
78000020 7fa40040 409d0020 7889aae0 39290072 79291f24 7d2b4a14 e8690010
2fa30000 419e0048 788014e2 78001f24 <7c63002a> 2fa30000 419e0034 788084a2
---[ end trace cacb4bbddb53f7bd ]---
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: [RFC PATCH 03/19] powerpc: gamecube: bootwrapper bits
From: Benjamin Herrenschmidt @ 2009-11-26 8:46 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <20091126081724.GA6538@iram.es>
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.
^ permalink raw reply
* Re: [PATCH] zlib: Optimize inffast when copying direct from output
From: Benjamin Herrenschmidt @ 2009-11-26 8:46 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <OF23DC26B5.C444DA5A-ONC125767A.002E6FF8-C125767A.002EB4D0@transmode.se>
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.
^ permalink raw reply
* Re: [PATCH] zlib: Optimize inffast when copying direct from output
From: Joakim Tjernlund @ 2009-11-26 9:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1259225218.16367.333.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> 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
^ permalink raw reply
* Re: [PATCH] Reserve memory for kdump kernel within RMO region
From: M. Mohan Kumar @ 2009-11-26 11:12 UTC (permalink / raw)
To: Bernhard Walle; +Cc: kexec, ppcdev
In-Reply-To: <4B0D7CF4.8040402@bwalle.de>
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
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* [PATCH] PPC: Sync guest visible MMU state
From: Alexander Graf @ 2009-11-26 11:16 UTC (permalink / raw)
To: kvm; +Cc: kvm-ppc, linuxppc-dev
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 <agraf@suse.de>
---
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_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 >= 0x330000) && (pvr < 0x70330000)) {
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++) {
+ kvmppc_set_bat(vcpu, &(to_book3s(vcpu)->ibat[i]), false,
+ (u32)sregs->ppc32.ibat[i]);
+ kvmppc_set_bat(vcpu, &(to_book3s(vcpu)->ibat[i]), true,
+ (u32)(sregs->ppc32.ibat[i] >> 32));
+ kvmppc_set_bat(vcpu, &(to_book3s(vcpu)->dbat[i]), false,
+ (u32)sregs->ppc32.dbat[i]);
+ kvmppc_set_bat(vcpu, &(to_book3s(vcpu)->dbat[i]), true,
+ (u32)(sregs->ppc32.dbat[i] >> 32));
+ }
+ }
+
+ /* Flush the MMU after messing with the segments */
+ kvmppc_mmu_pte_flush(vcpu, 0, 0);
return 0;
}
diff --git a/arch/powerpc/kvm/book3s_64_emulate.c b/arch/powerpc/kvm/book3s_64_emulate.c
index c343e67..1027eac 100644
--- a/arch/powerpc/kvm/book3s_64_emulate.c
+++ b/arch/powerpc/kvm/book3s_64_emulate.c
@@ -185,7 +185,27 @@ int kvmppc_core_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,
return emulated;
}
-static void kvmppc_write_bat(struct kvm_vcpu *vcpu, int sprn, u64 val)
+void kvmppc_set_bat(struct kvm_vcpu *vcpu, struct kvmppc_bat *bat, bool upper,
+ u32 val)
+{
+ if (upper) {
+ /* Upper BAT */
+ u32 bl = (val >> 2) & 0x7ff;
+ bat->bepi_mask = (~bl << 17);
+ bat->bepi = val & 0xfffe0000;
+ bat->vs = (val & 2) ? 1 : 0;
+ bat->vp = (val & 1) ? 1 : 0;
+ bat->raw = (bat->raw & 0xffffffff00000000ULL) | val;
+ } else {
+ /* Lower BAT */
+ bat->brpn = val & 0xfffe0000;
+ bat->wimg = (val >> 3) & 0xf;
+ bat->pp = val & 3;
+ bat->raw = (bat->raw & 0x00000000ffffffffULL) | ((u64)val << 32);
+ }
+}
+
+static void kvmppc_write_bat(struct kvm_vcpu *vcpu, int sprn, u32 val)
{
struct kvmppc_vcpu_book3s *vcpu_book3s = to_book3s(vcpu);
struct kvmppc_bat *bat;
@@ -207,19 +227,7 @@ static void kvmppc_write_bat(struct kvm_vcpu *vcpu, int sprn, u64 val)
BUG();
}
- if (!(sprn % 2)) {
- /* Upper BAT */
- u32 bl = (val >> 2) & 0x7ff;
- bat->bepi_mask = (~bl << 17);
- bat->bepi = val & 0xfffe0000;
- bat->vs = (val & 2) ? 1 : 0;
- bat->vp = (val & 1) ? 1 : 0;
- } else {
- /* Lower BAT */
- bat->brpn = val & 0xfffe0000;
- bat->wimg = (val >> 3) & 0xf;
- bat->pp = val & 3;
- }
+ kvmppc_set_bat(vcpu, bat, !(sprn % 2), val);
}
int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, int rs)
@@ -243,7 +251,7 @@ int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, int rs)
case SPRN_IBAT4U ... SPRN_IBAT7L:
case SPRN_DBAT0U ... SPRN_DBAT3L:
case SPRN_DBAT4U ... SPRN_DBAT7L:
- kvmppc_write_bat(vcpu, sprn, vcpu->arch.gpr[rs]);
+ kvmppc_write_bat(vcpu, sprn, (u32)vcpu->arch.gpr[rs]);
/* BAT writes happen so rarely that we're ok to flush
* everything here */
kvmppc_mmu_pte_flush(vcpu, 0, 0);
diff --git a/arch/powerpc/kvm/book3s_64_mmu.c b/arch/powerpc/kvm/book3s_64_mmu.c
index a31f9c6..5598f88 100644
--- a/arch/powerpc/kvm/book3s_64_mmu.c
+++ b/arch/powerpc/kvm/book3s_64_mmu.c
@@ -473,4 +473,6 @@ void kvmppc_mmu_book3s_64_init(struct kvm_vcpu *vcpu)
mmu->esid_to_vsid = kvmppc_mmu_book3s_64_esid_to_vsid;
mmu->ea_to_vp = kvmppc_mmu_book3s_64_ea_to_vp;
mmu->is_dcbz32 = kvmppc_mmu_book3s_64_is_dcbz32;
+
+ vcpu->arch.hflags |= BOOK3S_HFLAG_SLB;
}
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 692c370..d82551e 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -144,6 +144,9 @@ int kvm_dev_ioctl_check_extension(long ext)
int r;
switch (ext) {
+ case KVM_CAP_PPC_SEGSTATE:
+ r = 1;
+ break;
case KVM_CAP_COALESCED_MMIO:
r = KVM_COALESCED_MMIO_PAGE_OFFSET;
break;
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index f8f8900..caf6173 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -436,6 +436,9 @@ struct kvm_ioeventfd {
#endif
#define KVM_CAP_IOEVENTFD 36
#define KVM_CAP_SET_IDENTITY_MAP_ADDR 37
+/* KVM upstream has more features, but we synced this number.
+ Linus, please remove this comment on rebase. */
+#define KVM_CAP_PPC_SEGSTATE 43
#ifdef KVM_CAP_IRQ_ROUTING
--
1.6.0.2
^ permalink raw reply related
* Re: spi_mpc8xxx.c: chip select polarity problem
From: Anton Vorontsov @ 2009-11-26 12:12 UTC (permalink / raw)
To: Grant Likely; +Cc: Torsten Fleischer, spi-devel-general, linuxppc-dev
In-Reply-To: <fa686aa40911251411t13dd0131od6b497399641ce3d@mail.gmail.com>
On Wed, Nov 25, 2009 at 03:11:57PM -0700, Grant Likely wrote:
> On Wed, Nov 25, 2009 at 1:41 PM, Torsten Fleischer
> <to-fleischer@t-online.de> 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 <to-fleischer@t-online.de>
>
> 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: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 00/11] Yet another series of OF merge patches.
From: Wolfram Sang @ 2009-11-26 12:28 UTC (permalink / raw)
To: Grant Likely
Cc: sfr, monstr, microblaze-uclinux, devicetree-discuss, sparclinux,
linuxppc-dev, davem
In-Reply-To: <20091124081316.6216.66310.stgit@angua>
[-- Attachment #1: Type: text/plain, Size: 916 bytes --]
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 <w.sang@pengutronix.de>
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] PPC: Sync guest visible MMU state
From: Avi Kivity @ 2009-11-26 12:40 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm-ppc, kvm, linuxppc-dev
In-Reply-To: <1259234174-1104-1-git-send-email-agraf@suse.de>
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_MAX 16
>
> #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>= 0x330000)&& (pvr< 0x70330000)) {
> 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++) {
> + kvmppc_set_bat(vcpu,&(to_book3s(vcpu)->ibat[i]), false,
> + (u32)sregs->ppc32.ibat[i]);
> + kvmppc_set_bat(vcpu,&(to_book3s(vcpu)->ibat[i]), true,
> + (u32)(sregs->ppc32.ibat[i]>> 32));
> + kvmppc_set_bat(vcpu,&(to_book3s(vcpu)->dbat[i]), false,
> + (u32)sregs->ppc32.dbat[i]);
> + kvmppc_set_bat(vcpu,&(to_book3s(vcpu)->dbat[i]), true,
> + (u32)(sregs->ppc32.dbat[i]>> 32));
> + }
> + }
> +
> + /* Flush the MMU after messing with the segments */
> + kvmppc_mmu_pte_flush(vcpu, 0, 0);
> return 0;
> }
>
> diff --git a/arch/powerpc/kvm/book3s_64_emulate.c b/arch/powerpc/kvm/book3s_64_emulate.c
> index c343e67..1027eac 100644
> --- a/arch/powerpc/kvm/book3s_64_emulate.c
> +++ b/arch/powerpc/kvm/book3s_64_emulate.c
> @@ -185,7 +185,27 @@ int kvmppc_core_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,
> return emulated;
> }
>
> -static void kvmppc_write_bat(struct kvm_vcpu *vcpu, int sprn, u64 val)
> +void kvmppc_set_bat(struct kvm_vcpu *vcpu, struct kvmppc_bat *bat, bool upper,
> + u32 val)
> +{
> + if (upper) {
> + /* Upper BAT */
> + u32 bl = (val>> 2)& 0x7ff;
> + bat->bepi_mask = (~bl<< 17);
> + bat->bepi = val& 0xfffe0000;
> + bat->vs = (val& 2) ? 1 : 0;
> + bat->vp = (val& 1) ? 1 : 0;
> + bat->raw = (bat->raw& 0xffffffff00000000ULL) | val;
> + } else {
> + /* Lower BAT */
> + bat->brpn = val& 0xfffe0000;
> + bat->wimg = (val>> 3)& 0xf;
> + bat->pp = val& 3;
> + bat->raw = (bat->raw& 0x00000000ffffffffULL) | ((u64)val<< 32);
> + }
> +}
> +
> +static void kvmppc_write_bat(struct kvm_vcpu *vcpu, int sprn, u32 val)
> {
> struct kvmppc_vcpu_book3s *vcpu_book3s = to_book3s(vcpu);
> struct kvmppc_bat *bat;
> @@ -207,19 +227,7 @@ static void kvmppc_write_bat(struct kvm_vcpu *vcpu, int sprn, u64 val)
> BUG();
> }
>
> - if (!(sprn % 2)) {
> - /* Upper BAT */
> - u32 bl = (val>> 2)& 0x7ff;
> - bat->bepi_mask = (~bl<< 17);
> - bat->bepi = val& 0xfffe0000;
> - bat->vs = (val& 2) ? 1 : 0;
> - bat->vp = (val& 1) ? 1 : 0;
> - } else {
> - /* Lower BAT */
> - bat->brpn = val& 0xfffe0000;
> - bat->wimg = (val>> 3)& 0xf;
> - bat->pp = val& 3;
> - }
> + kvmppc_set_bat(vcpu, bat, !(sprn % 2), val);
> }
>
> int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, int rs)
> @@ -243,7 +251,7 @@ int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, int rs)
> case SPRN_IBAT4U ... SPRN_IBAT7L:
> case SPRN_DBAT0U ... SPRN_DBAT3L:
> case SPRN_DBAT4U ... SPRN_DBAT7L:
> - kvmppc_write_bat(vcpu, sprn, vcpu->arch.gpr[rs]);
> + kvmppc_write_bat(vcpu, sprn, (u32)vcpu->arch.gpr[rs]);
> /* BAT writes happen so rarely that we're ok to flush
> * everything here */
> kvmppc_mmu_pte_flush(vcpu, 0, 0);
> diff --git a/arch/powerpc/kvm/book3s_64_mmu.c b/arch/powerpc/kvm/book3s_64_mmu.c
> index a31f9c6..5598f88 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu.c
> @@ -473,4 +473,6 @@ void kvmppc_mmu_book3s_64_init(struct kvm_vcpu *vcpu)
> mmu->esid_to_vsid = kvmppc_mmu_book3s_64_esid_to_vsid;
> mmu->ea_to_vp = kvmppc_mmu_book3s_64_ea_to_vp;
> mmu->is_dcbz32 = kvmppc_mmu_book3s_64_is_dcbz32;
> +
> + vcpu->arch.hflags |= BOOK3S_HFLAG_SLB;
> }
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 692c370..d82551e 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -144,6 +144,9 @@ int kvm_dev_ioctl_check_extension(long ext)
> int r;
>
> switch (ext) {
> + case KVM_CAP_PPC_SEGSTATE:
> + r = 1;
> + break;
> case KVM_CAP_COALESCED_MMIO:
> r = KVM_COALESCED_MMIO_PAGE_OFFSET;
> break;
> diff --git a/include/linux/kvm.h b/include/linux/kvm.h
> index f8f8900..caf6173 100644
> --- a/include/linux/kvm.h
> +++ b/include/linux/kvm.h
> @@ -436,6 +436,9 @@ struct kvm_ioeventfd {
> #endif
> #define KVM_CAP_IOEVENTFD 36
> #define KVM_CAP_SET_IDENTITY_MAP_ADDR 37
> +/* KVM upstream has more features, but we synced this number.
> + Linus, please remove this comment on rebase. */
> +#define KVM_CAP_PPC_SEGSTATE 43
>
> #ifdef KVM_CAP_IRQ_ROUTING
>
>
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] PPC: Sync guest visible MMU state
From: Alexander Graf @ 2009-11-26 12:46 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm-ppc, kvm, linuxppc-dev
In-Reply-To: <4B0E7738.5030506@redhat.com>
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
^ permalink raw reply
* Re: [PATCH] PPC: Sync guest visible MMU state
From: Avi Kivity @ 2009-11-26 12:50 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm-ppc, kvm, linuxppc-dev
In-Reply-To: <4B0E78BC.5050901@suse.de>
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
^ permalink raw reply
* Re: [PATCH] PPC: Sync guest visible MMU state
From: Alexander Graf @ 2009-11-26 13:16 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm-ppc, kvm, linuxppc-dev
In-Reply-To: <4B0E799C.80209@redhat.com>
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
^ permalink raw reply
* Re: [PATCH] PPC: Sync guest visible MMU state
From: Avi Kivity @ 2009-11-26 13:20 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm-ppc, kvm, linuxppc-dev
In-Reply-To: <4B0E7FC0.3000803@suse.de>
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
^ permalink raw reply
* fsl diu, edid info and i2c platform data
From: Kári Davíðsson @ 2009-11-26 14:34 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
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
^ permalink raw reply
* Re: [RFC PATCH 04/19] powerpc: wii: device tree
From: Albert Herranz @ 2009-11-26 15:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1259210722.16367.256.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
>
>> +/memreserve/ 0x01800000 0xe800000; /* memory hole (includes I/O area) */
>> +/memreserve/ 0x10000000 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 0x00000000 and contains 24MB of 1T-SRAM.
>> + * MEM2 starts at 0x10000000 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 = <0x00000000 0x133e0000>;
>> + };
>
> 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,broadway@0 {
>> + device_type = "cpu";
>> + reg = <0>;
>> + clock-frequency = <729000000>; /* 729MHz */
>> + bus-frequency = <243000000>; /* 243MHz core-to-bus 3x */
>> + timebase-frequency = <60750000>; /* 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 = <243000000>; /* 243MHz */
>> + ranges = <0x0c000000 0x0c000000 0x00010000
>> + 0x0d000000 0x0d000000 0x00010000
>> + 0x0d040000 0x0d040000 0x00050000
>> + 0x0d800000 0x0d800000 0x00001000
>> + 0x133e0000 0x133e0000 0x00c20000>;
>> +
>> + video@0c002000 {
>> + compatible = "nintendo,hollywood-video";
>> + reg = <0x0c002000 0x100>;
>> + interrupts = <8>;
>> + interrupt-parent = <&PIC0>;
>> + };
>> +
>> + PIC0: pic0@0c003000 {
>> + #interrupt-cells = <1>;
>> + compatible = "nintendo,flipper-pic";
>> + reg = <0x0c003000 0x8>;
>> + interrupt-controller;
>> + };
>> +
>> + resetswitch@0c003000 {
>> + compatible = "nintendo,hollywood-resetswitch";
>> + reg = <0x0c003000 0x4>;
>> + interrupts = <1>;
>> + interrupt-parent = <&PIC0>;
>> + };
>> +
>> + audio@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.
>> + mini@0d000000 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + #interrupt-cells = <1>;
>> + compatible = "twiizers,starlet-mini-ipc";
>> + reg = <0x0d000000 0x40 /* IPC */
>> + 0x13fffffc 0x4>; /* mini header pointer */
>> + };
>> +
>> + serial@0d006400 {
>> + compatible = "nintendo,hollywood-serial";
>> + reg = <0x0d006400 0x100>;
>> + interrupts = <3>;
>> + interrupt-parent = <&PIC0>;
>> + };
>> +
>> + /* External Interface bus */
>> + exi@0d006800 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "nintendo,hollywood-exi";
>> + reg = <0x0d006800 0x40>;
>> + interrupts = <4>;
>> + interrupt-parent = <&PIC0>;
>> +
>> + USBGECKO0: usbgecko@0d006814 {
>> + compatible = "usbgecko,usbgecko";
>> + reg = <0x0d006814 0x14>;
>> + virtual-reg = <0xcd006814>;
>> + };
>> + };
>
> 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 ?
>
Yes, the usbgecko is more of a developer gadget.
>> + ehci@0d040000 {
>> + compatible = "nintendo,hollywood-ehci";
>> + reg = <0x0d040000 0x100
>> + 0x133e0000 0x80000>; /* 512 KB */
>> + interrupts = <4>;
>> + interrupt-parent = <&PIC1>;
>> + };
>> +
>> + ohci0@0d050000 {
>> + compatible = "nintendo,hollywood-ohci";
>> + reg = <0x0d050000 0x100
>> + 0x13460000 0x80000>; /* 512 KB */
>> + interrupts = <5>;
>> + interrupt-parent = <&PIC1>;
>> + };
>> +
>> + ohci1@0d060000 {
>
> Why the "1" ?
>
I thought that names should be unique, but I see they don't need to.
I'll use just "ohci".
>> + compatible = "nintendo,hollywood-ohci";
>> + reg = <0x0d060000 0x100
>> + 0x134e0000 0x80000>; /* 512 KB */
>> + interrupts = <6>;
>> + interrupt-parent = <&PIC1>;
>> + };
>
> 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.
>> + sdhc0@0d070000 {
>> + compatible = "nintendo,hollywood-sdhci";
>> + reg = <0x0d070000 0x200>;
>> + interrupts = <7>;
>> + interrupt-parent = <&PIC1>;
>> + };
>> +
>> + sdhc1@0d080000 {
>> + compatible = "nintendo,hollywood-sdhci";
>> + reg = <0x0d080000 0x200>;
>> + interrupts = <8>;
>> + interrupt-parent = <&PIC1>;
>> + };
>
> Again, no need for a "1" in there. Names don't have to be unique if the
> unit address is different.
>
I'll fix this too.
>> + PIC1: pic1@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
>
It works fine :)
>> + hollywood-ahbprot@0d800064 {
>> + compatible = "nintendo,hollywood-ahbprot";
>> + reg = <0x0d800064 0x4>;
>> + };
>
> What is this ?
>
A register that controls if the PowerPC side can directly access part of the hardware or not.
>> + gpio0: hollywood-gpio@0d8000c0 {
>> + compatible = "nintendo,hollywood-gpio";
>> + reg = <0x0d8000c0 0x20>;
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + };
>> +
>> + gpio1: hollywood-gpio@0d8000e0 {
>> + compatible = "nintendo,hollywood-gpio";
>> + reg = <0x0d8000e0 0x20>;
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + };
>
> Same comment about the "1"
>
Yup.
>> + hollywood-resets@0d800194 {
>> + compatible = "nintendo,hollywood-resets";
>> + reg = <0x0d800194 0x4>;
>> + };
>> +
>> + i2c-video {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "virtual,i2c-gpio";
>> +
>> + gpios = <&gpio0 16 0 /* 31-15 */
>> + &gpio0 17 0 /* 31-14 */
>> + >;
>> + sda-is-open-drain = <1>;
>> + sda-enforce-dir = <1>;
>> + scl-is-open-drain = <1>;
>> + scl-is-output-only = <1>;
>> + udelay = <2>;
>> +
>> + audio-video-encoder {
>> + compatible = "nintendo,wii-ave-rvl";
>> + reg = <0x70>;
>> + };
>> + };
>> + };
>> +};
>> +
>
> Cheers,
> Ben.
>
Thanks,
Albert
^ permalink raw reply
* Re: fsl diu, edid info and i2c platform data
From: Kári Davíðsson @ 2009-11-26 15:11 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
In-Reply-To: <4B0E9203.7040208@marel.com>
[-- Attachment #1: Type: text/plain, Size: 1655 bytes --]
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
>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: edid.patch --]
[-- Type: text/x-diff; name="edid.patch", Size: 17167 bytes --]
diff --git a/arch/powerpc/boot/dts/v39.dts b/arch/powerpc/boot/dts/v39.dts
new file mode 100644
index 0000000..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,5121@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 = <49500000>;// 49.5 MHz (csb/4)
+ bus-frequency = <198000000>; // 198 MHz csb bus
+ clock-frequency = <396000000>; // 396 MHz ppc core
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x10000000>; // 256MB at 0
+ };
+
+ mbx@20000000 {
+ compatible = "fsl,mpc5121-mbx";
+ reg = <0x20000000 0x4000>;
+ interrupts = <66 0x8>;
+ interrupt-parent = < &ipic >;
+ };
+
+ sram@30000000 {
+ compatible = "fsl,mpc5121-sram";
+ reg = <0x30000000 0x20000>; // 128K at 0x30000000
+ };
+
+ soc@80000000 {
+ compatible = "fsl,mpc5121-immr";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ ranges = <0x0 0x80000000 0x400000>;
+ reg = <0x80000000 0x400000>;
+ bus-frequency = <66000000>; // 66 MHz ips bus
+
+
+ // IPIC
+ // interrupts cell = <intr #, sense>
+ // sense values match linux IORESOURCE_IRQ_* defines:
+ // sense == 8: Level, low assertion
+ // sense == 2: Edge, high-to-low change
+ //
+ ipic: interrupt-controller@c00 {
+ compatible = "fsl,mpc5121-ipic", "fsl,ipic";
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <0xc00 0x100>;
+ };
+
+ rtc@a00 { // Real time clock
+ compatible = "fsl,mpc5121-rtc";
+ reg = <0xa00 0x100>;
+ interrupts = <79 0x8 80 0x8>;
+ interrupt-parent = < &ipic >;
+ };
+
+ clock@f00 { // Clock control
+ compatible = "fsl,mpc5121-clock";
+ reg = <0xf00 0x100>;
+ };
+
+/*
+ gpio@1100 {
+ compatible = "fsl,mpc5121-gpio";
+ reg = <0x1100 0x100>;
+ interrupts = <78 0x8>;
+ interrupt-parent = < &ipic >;
+ };
+*/
+
+ mscan@1300 {
+ compatible = "fsl,mpc5121-mscan";
+ cell-index = <0>;
+ interrupts = <12 0x8>;
+ interrupt-parent = < &ipic >;
+ reg = <0x1300 0x80>;
+ clock-ipb;
+ };
+
+ mscan@1380 {
+ compatible = "fsl,mpc5121-mscan";
+ cell-index = <1>;
+ interrupts = <13 0x8>;
+ interrupt-parent = < &ipic >;
+ reg = <0x1380 0x80>;
+ clock-ipb;
+ };
+
+ edidbus: i2c@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: edid@50 {
+ compatible = "vesa,edid";
+ reg = <0x50>;
+ };
+ };
+
+ i2c@1720 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5121-i2c", "fsl-i2c";
+ cell-index = <1>;
+ reg = <0x1720 0x20>;
+ interrupts = <10 0x8>;
+ interrupt-parent = < &ipic >;
+ fsl5200-clocking;
+ };
+
+ i2c@1740 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5121-i2c", "fsl-i2c";
+ cell-index = <2>;
+ reg = <0x1740 0x20>;
+ interrupts = <11 0x8>;
+ interrupt-parent = < &ipic >;
+ fsl5200-clocking;
+ ts@49 {
+ compatible = "bb,tsc2007";
+ reg = <0x49>;
+ interrupts = <17 0x8>; // IRQ1 (17)
+ interrupt-parent = < &ipic >;
+ device_type="tsc";
+ };
+
+ };
+
+ i2ccontrol@1760 {
+ compatible = "fsl,mpc5121-i2c-ctrl";
+ reg = <0x1760 0x8>;
+ };
+
+ axe@2000 {
+ compatible = "fsl,mpc5121-axe";
+ reg = <0x2000 0x100>;
+ interrupts = <42 0x8>;
+ interrupt-parent = < &ipic >;
+ };
+
+ display@2100 {
+ device_type = "display";
+ compatible = "fsl,diu";
+ reg = <0x2100 0x100>;
+ interrupts = <64 0x8>;
+ interrupt-parent = < &ipic >;
+ edid = < &edidbus >;
+ };
+
+ mdio@2800 {
+ compatible = "fsl,mpc5121-fec-mdio";
+ reg = <0x2800 0x800>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy: ethernet-phy@0 {
+ reg = <1>;
+ device_type = "ethernet-phy";
+ };
+ };
+
+ ethernet@2800 {
+ device_type = "network";
+ compatible = "fsl,mpc5121-fec";
+ reg = <0x2800 0x800>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <4 0x8>;
+ interrupt-parent = < &ipic >;
+ phy-handle = < &phy >;
+ fsl,align-tx-packets = <4>;
+ };
+
+ // 5121e has two dr usb modules
+ // USB1 using external ULPI PHY
+ usb@3000 {
+ compatible = "fsl,mpc5121-usb2-dr", "fsl-usb2-dr";
+ reg = <0x3000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = < &ipic >;
+ interrupts = <43 0x8>;
+ dr_mode = "otg";
+ phy_type = "ulpi";
+ port1;
+ };
+
+ // USB0 using internal UTMI PHY
+ usb@4000 {
+ compatible = "fsl,mpc5121-usb2-dr", "fsl-usb2-dr";
+ reg = <0x4000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = < &ipic >;
+ interrupts = <44 0x8>;
+ dr_mode = "otg";
+ phy_type = "utmi_wide";
+ port0;
+ };
+
+ // IO control
+ ioctl@a000 {
+ compatible = "fsl,mpc5121-ioctl";
+ reg = <0xA000 0x1000>;
+ };
+
+ // 512x PSCs are not 52xx PSC compatible
+ // PSC3 serial port A aka ttyPSC0
+ serial@11300 {
+ device_type = "serial";
+ compatible = "fsl,mpc5121-psc-uart", "fsl,mpc5121-psc";
+ // Logical port assignment needed until driver
+ // learns to use aliases
+ port-number = <0>;
+ cell-index = <3>;
+ reg = <0x11300 0x100>;
+ interrupts = <40 0x8>;
+ interrupt-parent = < &ipic >;
+ rx-fifo-size = <16>;
+ tx-fifo-size = <16>;
+ };
+
+ // PSC4 serial port B aka ttyPSC1
+ serial@11400 {
+ device_type = "serial";
+ compatible = "fsl,mpc5121-psc-uart", "fsl,mpc5121-psc";
+ // Logical port assignment needed until driver
+ // learns to use aliases
+ port-number = <1>;
+ cell-index = <4>;
+ reg = <0x11400 0x100>;
+ interrupts = <40 0x8>;
+ interrupt-parent = < &ipic >;
+ rx-fifo-size = <16>;
+ tx-fifo-size = <16>;
+ };
+
+ pscfifo@11f00 {
+ compatible = "fsl,mpc5121-psc-fifo";
+ reg = <0x11f00 0x100>;
+ interrupts = <40 0x8>;
+ interrupt-parent = < &ipic >;
+ };
+
+ dma@14000 {
+ compatible = "fsl,mpc5121-dma2", "fsl,mpc512x-dma2", "mpc512x-dma2";
+ reg = <0x14000 0x1800>;
+ interrupts = <65 0x8>;
+ interrupt-parent = < &ipic >;
+ };
+
+ };
+};
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 188e1ba..672d962 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -218,6 +218,15 @@ config FB_MODE_HELPERS
your driver does not take advantage of this feature, choosing Y will
just increase the kernel size by about 5K.
+config I2CEDID
+ bool "Encapsulate EDID functions with i2c driver"
+ depends on I2C
+ default n
+ ---help---
+ This helps with automatic probing of the EDID information from
+ of tree. Can probably help others where instantiation of the EDID
+ instantiation could be factored out of the console driver.
+
config FB_TILEBLITTING
bool "Enable Tile Blitting Support"
depends on FB
@@ -1827,6 +1836,8 @@ config FB_FSL_DIU
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
select PPC_LIB_RHEAP
+ select I2CEDID
+ select FB_DDC
---help---
Framebuffer driver for the Freescale SoC DIU
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 80232e1..c3c5a3d 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -4,6 +4,7 @@
# Each configuration option enables a list of files.
+obj-$(CONFIG_I2CEDID) += i2cedid.o
obj-$(CONFIG_VGASTATE) += vgastate.o
obj-y += fb_notify.o
obj-$(CONFIG_FB) += fb.o
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index 72d68b3..f6fcbae 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -35,6 +35,7 @@
#include <sysdev/fsl_soc.h>
#include "fsl-diu-fb.h"
+#include "i2cedid.h"
/*
* These parameters give default parameters
@@ -44,8 +45,8 @@
*/
static struct fb_videomode __devinitdata fsl_diu_default_mode = {
.refresh = 60,
- .xres = 1024,
- .yres = 768,
+ .xres = 640,
+ .yres = 480,
.pixclock = 15385,
.left_margin = 160,
.right_margin = 24,
@@ -57,132 +58,9 @@ static struct fb_videomode __devinitdata fsl_diu_default_mode = {
.vmode = FB_VMODE_NONINTERLACED
};
-static struct fb_videomode __devinitdata fsl_diu_mode_db[] = {
- {
- .name = "1024x768-60",
- .refresh = 60,
- .xres = 1024,
- .yres = 768,
- .pixclock = 15385,
- .left_margin = 160,
- .right_margin = 24,
- .upper_margin = 29,
- .lower_margin = 3,
- .hsync_len = 136,
- .vsync_len = 6,
- .sync = FB_SYNC_COMP_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
- .vmode = FB_VMODE_NONINTERLACED
- },
- {
- .name = "1024x768-70",
- .refresh = 70,
- .xres = 1024,
- .yres = 768,
- .pixclock = 16886,
- .left_margin = 3,
- .right_margin = 3,
- .upper_margin = 2,
- .lower_margin = 2,
- .hsync_len = 40,
- .vsync_len = 18,
- .sync = FB_SYNC_COMP_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
- .vmode = FB_VMODE_NONINTERLACED
- },
- {
- .name = "1024x768-75",
- .refresh = 75,
- .xres = 1024,
- .yres = 768,
- .pixclock = 15009,
- .left_margin = 3,
- .right_margin = 3,
- .upper_margin = 2,
- .lower_margin = 2,
- .hsync_len = 80,
- .vsync_len = 32,
- .sync = FB_SYNC_COMP_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
- .vmode = FB_VMODE_NONINTERLACED
- },
- {
- .name = "1280x1024-60",
- .refresh = 60,
- .xres = 1280,
- .yres = 1024,
- .pixclock = 9375,
- .left_margin = 38,
- .right_margin = 128,
- .upper_margin = 2,
- .lower_margin = 7,
- .hsync_len = 216,
- .vsync_len = 37,
- .sync = FB_SYNC_COMP_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
- .vmode = FB_VMODE_NONINTERLACED
- },
- {
- .name = "1280x1024-70",
- .refresh = 70,
- .xres = 1280,
- .yres = 1024,
- .pixclock = 9380,
- .left_margin = 6,
- .right_margin = 6,
- .upper_margin = 4,
- .lower_margin = 4,
- .hsync_len = 60,
- .vsync_len = 94,
- .sync = FB_SYNC_COMP_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
- .vmode = FB_VMODE_NONINTERLACED
- },
- {
- .name = "1280x1024-75",
- .refresh = 75,
- .xres = 1280,
- .yres = 1024,
- .pixclock = 9380,
- .left_margin = 6,
- .right_margin = 6,
- .upper_margin = 4,
- .lower_margin = 4,
- .hsync_len = 60,
- .vsync_len = 15,
- .sync = FB_SYNC_COMP_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
- .vmode = FB_VMODE_NONINTERLACED
- },
- {
- .name = "320x240", /* for AOI only */
- .refresh = 60,
- .xres = 320,
- .yres = 240,
- .pixclock = 15385,
- .left_margin = 0,
- .right_margin = 0,
- .upper_margin = 0,
- .lower_margin = 0,
- .hsync_len = 0,
- .vsync_len = 0,
- .sync = FB_SYNC_COMP_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
- .vmode = FB_VMODE_NONINTERLACED
- },
- {
- .name = "1280x480-60",
- .refresh = 60,
- .xres = 1280,
- .yres = 480,
- .pixclock = 18939,
- .left_margin = 353,
- .right_margin = 47,
- .upper_margin = 39,
- .lower_margin = 4,
- .hsync_len = 8,
- .vsync_len = 2,
- .sync = FB_SYNC_COMP_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
- .vmode = FB_VMODE_NONINTERLACED
- },
-};
-
-static char *fb_mode = "1024x768-32@60";
+static char *fb_mode = "640x480-32@60";
static unsigned long default_bpp = 32;
-static int monitor_port;
+static int monitor_port = 0;
#if defined(CONFIG_NOT_COHERENT_CACHE)
static u8 *coherence_data;
@@ -325,7 +203,7 @@ static int fsl_diu_enable_panel(struct fb_info *info)
struct fsl_diu_data *machine_data = mfbi->parent;
int res = 0;
- pr_debug("enable_panel index %d\n", mfbi->index);
+ printk(KERN_INFO "enable_panel index %d\n", mfbi->index);
if (mfbi->type != MFB_TYPE_OFF) {
switch (mfbi->index) {
case 0: /* plane 0 */
@@ -704,8 +582,8 @@ static void update_lcdc(struct fb_info *info)
out_be32(&hw->gamma, pool.gamma.paddr);
out_be32(&hw->cursor, pool.cursor.paddr);
- out_be32(&hw->bgnd, 0x007F7F7F); /* BGND */
- out_be32(&hw->bgnd_wb, 0); /* BGND_WB */
+ out_be32(&hw->bgnd, 0x00000000); /* BGND */
+ out_be32(&hw->bgnd_wb, 0x00000000); /* BGND_WB */
out_be32(&hw->disp_size, (var->yres << 16 | var->xres));
/* DISP SIZE */
pr_debug("DIU xres: %d\n", var->xres);
@@ -1172,18 +1050,12 @@ static int __devinit install_fb(struct fb_info *info)
{
int rc;
struct mfb_info *mfbi = info->par;
- const char *aoi_mode, *init_aoi_mode = "320x240";
if (init_fbinfo(info))
return -EINVAL;
- if (mfbi->index == 0) /* plane 0 */
- aoi_mode = fb_mode;
- else
- aoi_mode = init_aoi_mode;
- pr_debug("mode used = %s\n", aoi_mode);
- rc = fb_find_mode(&info->var, info, aoi_mode, fsl_diu_mode_db,
- ARRAY_SIZE(fsl_diu_mode_db), &fsl_diu_default_mode, default_bpp);
+ pr_debug("mode used = %s\n", edid_fbmodetxt);
+ rc = fb_find_mode(&info->var, info, edid_fbmodetxt, edid_fbmonspec->modedb, edid_fbmonspec->modedb_len, &fsl_diu_default_mode, default_bpp);
switch (rc) {
case 1:
@@ -1428,6 +1300,8 @@ static int __devinit fsl_diu_probe(struct of_device *ofdev,
struct resource res;
struct fsl_diu_data *machine_data;
+ printk(KERN_INFO "The mode %s \n", edid_fbmodetxt );
+
machine_data = kzalloc(sizeof(struct fsl_diu_data), GFP_KERNEL);
if (!machine_data)
return -ENOMEM;
@@ -1700,6 +1574,7 @@ static int __init fsl_diu_init(void)
if (!coherence_data)
return -ENOMEM;
#endif
+
ret = of_register_platform_driver(&fsl_diu_driver);
if (ret) {
printk(KERN_ERR
diff --git a/drivers/video/i2cedid.c b/drivers/video/i2cedid.c
new file mode 100644
index 0000000..ae5cd1f
--- /dev/null
+++ b/drivers/video/i2cedid.c
@@ -0,0 +1,102 @@
+/* Copyright 2009 Marel ehf. All Rights Reserverd.
+ *
+ * Author Kári Davíðsson <karidav@marel.is>
+ *
+ * Of platform driver for edid reading.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/i2c.h>
+#include <linux/list.h>
+#include <linux/fb.h>
+#include "i2cedid.h"
+#include "edid.h"
+
+static char fb_modexx[100];
+static struct fb_monspecs i2cedid_monspec;
+static struct fb_var_screeninfo i2cedid_screeninfo;
+
+struct fb_monspecs * edid_fbmonspec;
+EXPORT_SYMBOL( edid_fbmodespec );
+
+char * edid_fbmodetxt = &fb_modexx[0];
+EXPORT_SYMBOL( edid_fbmodetxt );
+
+static int __devinit i2cedid_probe(struct i2c_client *client, const struct i2c_device_id *id)
+{
+ char tblock[EDID_LENGTH];
+ s32 read = 0;
+
+ while( read < EDID_LENGTH)
+ {
+ s32 res;
+ res = i2c_smbus_read_i2c_block_data( client, read, EDID_LENGTH, &tblock[read]);
+ if( res > 0 )
+ {
+ read += res;
+ }
+ }
+
+ fb_edid_to_monspecs( &tblock[0], &i2cedid_monspec);
+
+ if( fb_parse_edid( &tblock[0], &i2cedid_screeninfo ) != 0 )
+ {
+ printk(KERN_WARNING "Unable to parse edid information\n");
+ return -ENODEV;
+ }
+
+ edid_fbmonspec = &i2cedid_monspec;
+
+ snprintf( &fb_modexx[0], sizeof(fb_modexx), "%dx%d-%d@%d", i2cedid_monspec.modedb[0].xres, i2cedid_monspec.modedb[0].yres, 32, i2cedid_monspec.modedb[0].refresh);
+ printk( KERN_INFO "fb_mode set to %s %d\n", fb_modexx, i2cedid_monspec.modedb[0].pixclock);
+
+
+
+ return 0;
+}
+
+static int __devexit i2cedid_remove(struct i2c_client *client)
+{
+ edid_fbmonspec = NULL;
+ fb_destroy_modedb( i2cedid_monspec.modedb );
+ memset( &i2cedid_monspec, 0, sizeof(i2cedid_monspec) );
+
+ return 0;
+}
+
+static struct i2c_device_id i2cedid_idtable[] = {
+ { "edid", 0 },
+ { },
+};
+
+MODULE_DEVICE_TABLE(i2c, i2cedid_idtable);
+
+static struct i2c_driver i2cedid_driver = {
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = "edid",
+ },
+ .id_table = i2cedid_idtable,
+ .probe = i2cedid_probe,
+ .remove = __devexit_p(i2cedid_remove),
+};
+
+static int __init i2cedid_init( void )
+{
+ return i2c_add_driver(&i2cedid_driver);
+}
+
+static void __exit i2cedid_exit( void )
+{
+ i2c_del_driver(&i2cedid_driver);
+}
+
+module_init( i2cedid_init );
+module_exit( i2cedid_exit );
+
+MODULE_AUTHOR( "Kári Davíðsson <karidav@marel.is>" );
+MODULE_DESCRIPTION( "I2C driver encapsulation for OF integration." );
+MODULE_LICENSE( "GPL" );
+
diff --git a/drivers/video/i2cedid.h b/drivers/video/i2cedid.h
new file mode 100644
index 0000000..4845201
--- /dev/null
+++ b/drivers/video/i2cedid.h
@@ -0,0 +1,14 @@
+/* Copyright 2009 Marel ehf. All Rights Reserverd.
+ *
+ * Author Kári Davíðsson <karidav@marel.is>
+ *
+ * Header file to Of platform driver for edid reading.
+ */
+
+#ifndef __I2CEDID_H__
+#define __I2CEDID_H__
+
+extern struct fb_monspecs * edid_fbmonspec;
+extern char * edid_fbmodetxt;
+
+#endif /* __I2CEDID_H__ */
^ permalink raw reply related
* Re: [RFC PATCH 04/19] powerpc: wii: device tree
From: Albert Herranz @ 2009-11-26 15:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1259211061.16367.260.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Wed, 2009-11-25 at 18:49 +0100, Segher Boessenkool wrote:
>>> +/memreserve/ 0x01800000 0xe800000; /* 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/ 0x10000000 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 = <0x0c000000 0x0c000000 0x00010000
>>> + 0x0d000000 0x0d000000 0x00010000
>>> + 0x0d040000 0x0d040000 0x00050000
>>> + 0x0d800000 0x0d800000 0x00001000
>> All of 0cXXXXXX and 0dXXXXXX actually.
>>
>>> + 0x133e0000 0x133e0000 0x00c20000>;
>> This is just part of MEM2, don't treat it special here.
>>
>>> + video@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: pic0@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;
>>> + };
>>> +
>>> + resetswitch@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 */
>>> + mini@0d000000 {
>> Although mini is awesome, it isn't hardware, and doesn't
>> belong in the device tree.
>
> So what is at d0000000 ?
>
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.
>>> + serial@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
^ permalink raw reply
* Re: [RFC PATCH 04/19] powerpc: wii: device tree
From: Albert Herranz @ 2009-11-26 15:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1259211505.16367.261.camel@pasglop>
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
^ permalink raw reply
* Re: [RFC PATCH 06/19] powerpc: gamecube/wii: introduce GAMECUBE_COMMON
From: Albert Herranz @ 2009-11-26 15:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1259212129.16367.262.camel@pasglop>
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
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox