* Re: [PATCH] powerpc: Avoid giving out RTC dates below EPOCH
From: Benjamin Herrenschmidt @ 2009-11-02 5:13 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1257138663.7907.32.camel@pasglop>
On Mon, 2009-11-02 at 16:11 +1100, Benjamin Herrenschmidt wrote:
> Doing so causes xtime to be negative which crashes the timekeeping
> code in funny ways when doing suspend/resume
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> +void read_persistent_clock(struct timespec *ts)
> +{
> + __read_persistent_clock(&ts);
Should read
+ __read_persistent_clock(ts);
Forgot a quilt ref ;-)
Cheers,
Ben.
> + /* Sanitize it in case real time clock is set below EPOCH */
> + if (ts->tv_sec < 0) {
> + ts->tv_sec = 0;
> + ts->tv_nsec = 0;
> + }
> +
> +}
> +
> /* clocksource code */
> static cycle_t rtc_read(struct clocksource *cs)
> {
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [powerpc] Next tree Nov 2 : kernel BUG at mm/mmap.c:2135!
From: Sachin Sant @ 2009-11-02 9:12 UTC (permalink / raw)
To: Linux/PPC Development; +Cc: Stephen Rothwell, linux-next
In-Reply-To: <20091102173845.210d1c57.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 4210 bytes --]
Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20091030:
>
Today's next tree failed to boot on a POWER 6 box with :
------------[ cut here ]------------
kernel BUG at mm/mmap.c:2135!
Oops: Exception in kernel mode, sig: 5 [#2]
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in: ibmvscsic scsi_transport_srp scsi_tgt scsi_mod
NIP: c00000000014e30c LR: c00000000014e2f8 CTR: c00000000014db88
REGS: c0000000db703620 TRAP: 0700 Tainted: G D (2.6.32-rc5-autotest-next-20091102)
MSR: 8000000000029032 <EE,ME,CE,IR,DR> CR: 24022442 XER: 2000000c
TASK = c0000000db7f6fe0[76] 'init' THREAD: c0000000db700000 CPU: 1
GPR00: 0000000000000001 c0000000db7038a0 c000000000b19900 0000000000000000
GPR04: c0000000db406a40 000000000000000c c0000000fe10c370 c000000000bb2800
GPR08: 000000000000db40 0000000000000000 c0000000dfdc0e00 000000000000000c
GPR12: 0000000044022442 c000000000bb2800 00000000ffffffff ffffffffffffffff
GPR16: 0000000008430000 00000000003c0000 c0000000db703ea0 c0000000db569108
GPR20: c0000000db568908 0000000000000000 c0000000db703d60 0000000000000000
GPR24: 0000000000000001 0000000000040100 c0000000fe503580 c0000000db1ac180
GPR28: 0000000000000000 c000000000f812d0 c000000000a84f00 0000000000000000
NIP [c00000000014e30c] .exit_mmap+0x190/0x1b8
LR [c00000000014e2f8] .exit_mmap+0x17c/0x1b8
Call Trace:
[c0000000db7038a0] [c00000000014e2f8] .exit_mmap+0x17c/0x1b8 (unreliable)
[c0000000db703950] [c0000000000916cc] .mmput+0x54/0x164
[c0000000db7039e0] [c0000000000968d8] .exit_mm+0x17c/0x1a0
[c0000000db703a90] [c000000000098cb8] .do_exit+0x248/0x784
[c0000000db703b70] [c0000000000992a8] .do_group_exit+0xb4/0xe8
[c0000000db703c00] [c0000000000aca2c] .get_signal_to_deliver+0x3ec/0x478
[c0000000db703cf0] [c0000000000134ac] .do_signal+0x6c/0x31c
[c0000000db703e30] [c000000000008b7c] do_work+0x24/0x28
Instruction dump:
7c8407b4 387d0018 4800ab11 60000000 939d0008 7fe3fb78 4bfffdbd 7c7f1b79
4082fff4 e81b00e8 3120ffff 7c090110 <0b000000> 382100b0 e8010010 eb61ffd8
---[ end trace ec052ac77a8e7cb4 ]---
Fixing recursive fault but reboot is needed!
mm/mmap.c:2135 corresponds to :
BUG_ON(mm->nr_ptes > (FIRST_USER_ADDRESS+PMD_SIZE-1)>>PMD_SHIFT);
3:mon> di 0xc00000000014e300
c00000000014e300 e81b00e8 ld r0,232(r27)
c00000000014e304 3120ffff addic r9,r0,-1
c00000000014e308 7c090110 subfe r0,r9,r0
c00000000014e30c 0b000000 tdnei r0,0
c00000000014e310 382100b0 addi r1,r1,176
c00000000014e314 e8010010 ld r0,16(r1)
c00000000014e318 eb61ffd8 ld r27,-40(r1)
c00000000014e31c 7c0803a6 mtlr r0
c00000000014e320 eb81ffe0 ld r28,-32(r1)
c00000000014e324 eba1ffe8 ld r29,-24(r1)
c00000000014e328 ebc1fff0 ld r30,-16(r1)
c00000000014e32c ebe1fff8 ld r31,-8(r1)
c00000000014e330 4e800020 blr
c00000000014e334 fb21ffc8 std r25,-56(r1)
c00000000014e338 7c0802a6 mflr r0
c00000000014e33c fb81ffe0 std r28,-32(r1)
3:mon> r
R00 = 0000000000000001 R16 = 0000000030daf420
R01 = c0000000fae37a60 R17 = 0000000000000002
R02 = c000000000b19900 R18 = 0000000000000000
R03 = 0000000000000000 R19 = 0000000030d903b0
R04 = c0000000fabd8670 R20 = 0000000000000000
R05 = c000000000a4d600 R21 = 0000000000000000
R06 = 0000000000000003 R22 = 0000000000000000
R07 = c000000000bb2c00 R23 = 0000000030daf340
R08 = 000000000000fabd R24 = 0000000000000001
R09 = 0000000000000000 R25 = 00000fffc2402158
R10 = c0000000fffb2958 R26 = 00000fffb793df80
R11 = 0000000000000005 R27 = c0000000fa9aa580
R12 = 0000000044000442 R28 = 0000000000000000
R13 = c000000000bb2c00 R29 = c000000000fc12d0
R14 = 00000000ffffffff R30 = c000000000a84f00
R15 = ffffffffffffffff R31 = 0000000000000000
pc = c00000000014e30c .exit_mmap+0x190/0x1b8
lr = c00000000014e2f8 .exit_mmap+0x17c/0x1b8
msr = 8000000000029032 cr = 24000442
ctr = c0000000002f0cb0 xer = 000000002000000a trap = 700
3:mon>
Have attached the boot log. Next tree for 20091030 worked fine.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
[-- Attachment #2: boot-log --]
[-- Type: text/plain, Size: 10695 bytes --]
Using 007cf32f bytes for initrd buffer
Please wait, loading kernel...
Allocated 00f00000 bytes for kernel @ 02300000
Elf64 kernel loaded...
Loading ramdisk...
ramdisk loaded 007cf32f @ 03200000
OF stdout device is: /vdevice/vty@30000000
Preparing to boot Linux version 2.6.32-rc5-autotest-next-20091102 (root@mpower6lp5) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP Mon Nov 2 12:29:14 IST 2009
Calling ibm,client-architecture-support... done
command line: root=/dev/sda3 sysrq=8 insmod=sym53c8xx insmod=ipr crashkernel=512M-:256M IDENT=1257146334
memory layout at init:
memory_limit : 0000000000000000 (16 MB aligned)
alloc_bottom : 00000000039d0000
alloc_top : 0000000008000000
alloc_top_hi : 0000000008000000
rmo_top : 0000000008000000
ram_top : 0000000008000000
instantiating rtas at 0x00000000074e0000... done
boot cpu hw idx 0000000000000000
copying OF device tree...
Building dt strings...
Building dt structure...
Device tree strings 0x00000000039e0000 -> 0x00000000039e15c2
Device tree struct 0x00000000039f0000 -> 0x0000000003a10000
Calling quiesce...
returning from prom_init
Crash kernel location must be 0x2000000
Reserving 256MB of memory at 32MB for crashkernel (System RAM: 4096MB)
Using pSeries machine description
Using 1TB segments
Found initrd at 0xc000000003200000:0xc0000000039cf32f
bootconsole [udbg0] enabled
Partition configured for 2 cpus.
CPU maps initialized for 2 threads per core
Starting Linux PPC64 #1 SMP Mon Nov 2 12:29:14 IST 2009
-----------------------------------------------------
ppc64_pft_size = 0x1a
physicalMemorySize = 0x100000000
htab_hash_mask = 0x7ffff
-----------------------------------------------------
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.32-rc5-autotest-next-20091102 (root@mpower6lp5) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP Mon Nov 2 12:29:14 IST 2009
[boot]0012 Setup Arch
EEH: No capable adapters found
PPC64 nvram contains 15360 bytes
Zone PFN ranges:
DMA 0x00000000 -> 0x00010000
Normal 0x00010000 -> 0x00010000
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
2: 0x00000000 -> 0x0000e000
3: 0x0000e000 -> 0x00010000
Could not find start_pfn for node 0
[boot]0015 Setup Done
PERCPU: Embedded 2 pages/cpu @c000000000f00000 s89000 r0 d42072 u524288
pcpu-alloc: s89000 r0 d42072 u524288 alloc=1*1048576
pcpu-alloc: [0] 0 1
Built 3 zonelists in Node order, mobility grouping on. Total pages: 65480
Policy zone: DMA
Kernel command line: root=/dev/sda3 sysrq=8 insmod=sym53c8xx insmod=ipr crashkernel=512M-:256M IDENT=1257146334
PID hash table entries: 4096 (order: -1, 32768 bytes)
freeing bootmem node 2
freeing bootmem node 3
Memory: 3899776k/4194304k available (9216k kernel code, 294528k reserved, 2688k data, 2370k bss, 640k init)
Hierarchical RCU implementation.
RCU-based detection of stalled CPUs is enabled.
NR_IRQS:512 nr_irqs:512
[boot]0020 XICS Init
[boot]0021 XICS Done
clocksource: timebase mult[7d0000] shift[22] registered
Console: colour dummy device 80x25
console [hvc0] enabled, bootconsole disabled
console [hvc0] enabled, bootconsole disabled
allocated 2621440 bytes of page_cgroup
please try 'cgroup_disable=memory' option if you don't want memory cgroups
Security Framework initialized
SELinux: Disabled at boot.
Dentry cache hash table entries: 524288 (order: 6, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 5, 2097152 bytes)
Mount-cache hash table entries: 4096
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
Processor 1 found.
Brought up 2 CPUs
NET: Registered protocol family 16
IBM eBus Device Driver
POWER6 performance monitor hardware support registered
PCI: Probing PCI hardware
bio: create slab <bio-0> at 0
vgaarb: loaded
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Switching to clocksource timebase
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 2, 262144 bytes)
TCP established hash table entries: 131072 (order: 5, 2097152 bytes)
TCP bind hash table entries: 65536 (order: 4, 1048576 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
UDP hash table entries: 4096 (order: 0, 65536 bytes)
UDP-Lite hash table entries: 4096 (order: 0, 65536 bytes)
NET: Registered protocol family 1
Unpacking initramfs...
IOMMU table initialized, virtual merging enabled
audit: initializing netlink socket (disabled)
type=2000 audit(1257150470.200:1): initialized
rcu-torture:--- Start of test: nreaders=4 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval=3 stutter=5 irqreader=1
HugeTLB registered 16 MB page size, pre-allocated 0 pages
HugeTLB registered 16 GB page size, pre-allocated 0 pages
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 8192 (order 0, 65536 bytes)
msgmni has been set to 7616
alg: No test for stdrng (krng)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: PCI Express Hot Plug Controller Driver version: 0.4
rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
Generic RTC Driver v1.07
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
pmac_zilog: 0.6 (Benjamin Herrenschmidt <benh@kernel.crashing.org>)
input: Macintosh mouse button emulation as /devices/virtual/input/input0
Uniform Multi-Platform E-IDE driver
ide-gd driver 1.18
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
mice: PS/2 mouse device common for all mice
EDAC MC: Ver: 2.1.0 Nov 2 2009
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP cubic registered
NET: Registered protocol family 15
registered taskstats version 1
Freeing unused kernel memory: 640k freed
doing fast boot
------------[ cut here ]------------
kernel BUG at mm/mmap.c:2135!
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in:
NIP: c00000000014e30c LR: c00000000014e2f8 CTR: c0000000002f0cb0
REGS: c0000000db7337e0 TRAP: 0700 Not tainted (2.6.32-rc5-autotest-next-20091102)
MSR: 8000000000029032 <EE,ME,CE,IR,DR> CR: 24000442 XER: 20000002
TASK = c0000000db618a60[68] 'showconsole' THREAD: c0000000db730000 CPU: 0
GPR00: 0000000000000001 c0000000db733a60 c000000000b19900 0000000000000000
GPR04: c0000000db408670 c000000000a4d600 0000000000000003 c000000000bb2600
GPR08: 000000000000db40 0000000000000000 c0000000dfdc0e00 0000000000000005
GPR12: 0000000044000442 c000000000bb2600 00000000ffffffff ffffffffffffffff
GPR16: 000000004206e7d0 0000000000000002 0000000000000000 00000000420503b0
GPR20: 0000000000000000 0000000000000000 0000000000000000 000000004206fd70
GPR24: 0000000000000001 00000fffc0ac9b08 00000fff99b1df80 c0000000db1aa580
GPR28: 0000000000000000 c000000000f012d0 c000000000a84f00 0000000000000000
NIP [c00000000014e30c] .exit_mmap+0x190/0x1b8
LR [c00000000014e2f8] .exit_mmap+0x17c/0x1b8
Call Trace:
[c0000000db733a60] [c00000000014e2f8] .exit_mmap+0x17c/0x1b8 (unreliable)
[c0000000db733b10] [c0000000000916cc] .mmput+0x54/0x164
[c0000000db733ba0] [c0000000000968d8] .exit_mm+0x17c/0x1a0
[c0000000db733c50] [c000000000098cb8] .do_exit+0x248/0x784
[c0000000db733d30] [c0000000000992a8] .do_group_exit+0xb4/0xe8
[c0000000db733dc0] [c0000000000992f0] .SyS_exit_group+0x14/0x28
[c0000000db733e30] [c0000000000085b4] syscall_exit+0x0/0x40
Instruction dump:
7c8407b4 387d0018 4800ab11 60000000 939d0008 7fe3fb78 4bfffdbd 7c7f1b79
4082fff4 e81b00e8 3120ffff 7c090110 <0b000000> 382100b0 e8010010 eb61ffd8
SysRq : Changing Loglevel
Loglevel set to 8
---[ end trace ec052ac77a8e7cb3 ]---
Fixing recursive fault but reboot is needed!
SCSI subsystem initialized
vio_register_driver: driver ibmvscsi registering
ibmvscsi 30000007: SRP_VERSION: 16.a
scsi0 : IBM POWER Virtual SCSI Adapter 1.5.8
ibmvscsi 30000007: partner initialization complete
ibmvscsi 30000007: host srp version: 16.a, host partition VIO Server (1), OS 3, max io 1048576
ibmvscsi 30000007: Client reserve enabled
ibmvscsi 30000007: sent SRP login
ibmvscsi 30000007: SRP_LOGIN succeeded
scsi 0:0:1:0: Direct-Access AIX VDASD 0001 PQ: 0 ANSI: 3
scsi 0:0:2:0: CD-ROM AIX VOPTA PQ: 0 ANSI: 4
Creating device nodes with udev
------------[ cut here ]------------
kernel BUG at mm/mmap.c:2135!
Oops: Exception in kernel mode, sig: 5 [#2]
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in: ibmvscsic scsi_transport_srp scsi_tgt scsi_mod
NIP: c00000000014e30c LR: c00000000014e2f8 CTR: c00000000014db88
REGS: c0000000db703620 TRAP: 0700 Tainted: G D (2.6.32-rc5-autotest-next-20091102)
MSR: 8000000000029032 <EE,ME,CE,IR,DR> CR: 24022442 XER: 2000000c
TASK = c0000000db7f6fe0[76] 'init' THREAD: c0000000db700000 CPU: 1
GPR00: 0000000000000001 c0000000db7038a0 c000000000b19900 0000000000000000
GPR04: c0000000db406a40 000000000000000c c0000000fe10c370 c000000000bb2800
GPR08: 000000000000db40 0000000000000000 c0000000dfdc0e00 000000000000000c
GPR12: 0000000044022442 c000000000bb2800 00000000ffffffff ffffffffffffffff
GPR16: 0000000008430000 00000000003c0000 c0000000db703ea0 c0000000db569108
GPR20: c0000000db568908 0000000000000000 c0000000db703d60 0000000000000000
GPR24: 0000000000000001 0000000000040100 c0000000fe503580 c0000000db1ac180
GPR28: 0000000000000000 c000000000f812d0 c000000000a84f00 0000000000000000
NIP [c00000000014e30c] .exit_mmap+0x190/0x1b8
LR [c00000000014e2f8] .exit_mmap+0x17c/0x1b8
Call Trace:
[c0000000db7038a0] [c00000000014e2f8] .exit_mmap+0x17c/0x1b8 (unreliable)
[c0000000db703950] [c0000000000916cc] .mmput+0x54/0x164
[c0000000db7039e0] [c0000000000968d8] .exit_mm+0x17c/0x1a0
[c0000000db703a90] [c000000000098cb8] .do_exit+0x248/0x784
[c0000000db703b70] [c0000000000992a8] .do_group_exit+0xb4/0xe8
[c0000000db703c00] [c0000000000aca2c] .get_signal_to_deliver+0x3ec/0x478
[c0000000db703cf0] [c0000000000134ac] .do_signal+0x6c/0x31c
[c0000000db703e30] [c000000000008b7c] do_work+0x24/0x28
Instruction dump:
7c8407b4 387d0018 4800ab11 60000000 939d0008 7fe3fb78 4bfffdbd 7c7f1b79
4082fff4 e81b00e8 3120ffff 7c090110 <0b000000> 382100b0 e8010010 eb61ffd8
---[ end trace ec052ac77a8e7cb4 ]---
Fixing recursive fault but reboot is needed!
^ permalink raw reply
* Re: [PATCH 08/27] Add SLB switching code for entry/exit
From: Alexander Graf @ 2009-11-02 9:23 UTC (permalink / raw)
To: Michael Neuling
Cc: Kevin Wolf, Arnd Bergmann, Hollis Blanchard, Marcelo Tosatti,
kvm-ppc, linuxppc-dev@ozlabs.org, Avi Kivity, kvm@vger.kernel.org,
bphilips@suse.de, Olof Johansson
In-Reply-To: <6695.1257117827@neuling.org>
Am 02.11.2009 um 00:23 schrieb Michael Neuling <mikey@neuling.org>:
>> This is the really low level of guest entry/exit code.
>>
>> Book3s_64 has an SLB, which stores all ESID -> VSID mappings we're
>> currently aware of.
>>
>> The segments in the guest differ from the ones on the host, so we
>> need
>> to switch the SLB to tell the MMU that we're in a new context.
>>
>> So we store a shadow of the guest's SLB in the PACA, switch to that
>> on
>> entry and only restore bolted entries on exit, leaving the rest to
>> the
>> Linux SLB fault handler.
>>
>> That way we get a really clean way of switching the SLB.
>>
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> ---
>> arch/powerpc/kvm/book3s_64_slb.S | 277 ++++++++++++++++++++++++++++
>> ++++++++
> ++
>> 1 files changed, 277 insertions(+), 0 deletions(-)
>> create mode 100644 arch/powerpc/kvm/book3s_64_slb.S
>>
>> diff --git a/arch/powerpc/kvm/book3s_64_slb.S b/arch/powerpc/kvm/
>> book3s_64_sl
> b.S
>> new file mode 100644
>> index 0000000..00a8367
>> --- /dev/null
>> +++ b/arch/powerpc/kvm/book3s_64_slb.S
>> @@ -0,0 +1,277 @@
>> +/*
>> + * This program is free software; you can redistribute it and/or
>> modify
>> + * it under the terms of the GNU General Public License, version
>> 2, as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
>> 02110-1301, USA.
>> + *
>> + * Copyright SUSE Linux Products GmbH 2009
>> + *
>> + * Authors: Alexander Graf <agraf@suse.de>
>> + */
>> +
>> +/
>> ***
>> ***
>> *********************************************************************
> ***
>> + *
> *
>> + * Entry code
> *
>> + *
> *
>> +
>> ***
>> ***
>> *********************************************************************
> **/
>> +
>> +.global kvmppc_handler_trampoline_enter
>> +kvmppc_handler_trampoline_enter:
>> +
>> + /* Required state:
>> + *
>> + * MSR = ~IR|DR
>> + * R13 = PACA
>> + * R9 = guest IP
>> + * R10 = guest MSR
>> + * R11 = free
>> + * R12 = free
>> + * PACA[PACA_EXMC + EX_R9] = guest R9
>> + * PACA[PACA_EXMC + EX_R10] = guest R10
>> + * PACA[PACA_EXMC + EX_R11] = guest R11
>> + * PACA[PACA_EXMC + EX_R12] = guest R12
>> + * PACA[PACA_EXMC + EX_R13] = guest R13
>> + * PACA[PACA_EXMC + EX_CCR] = guest CR
>> + * PACA[PACA_EXMC + EX_R3] = guest XER
>> + */
>> +
>> + mtsrr0 r9
>> + mtsrr1 r10
>> +
>> + mtspr SPRN_SPRG_SCRATCH0, r0
>> +
>> + /* Remove LPAR shadow entries */
>> +
>> +#if SLB_NUM_BOLTED == 3
>
> You could alternatively check the persistent entry in the slb_shawdow
> buffer. This would give you a run time check. Not sure what's best
> though.
Well we're in the hot path here, so anything using as few registers as
possible and being simple is the best :-). I'd guess the more we are
clever at compile time the better.
>
>
>> +
>> + ld r12, PACA_SLBSHADOWPTR(r13)
>> + ld r10, 0x10(r12)
>> + ld r11, 0x18(r12)
>
> Can you define something in asm-offsets.c for these magic constants
> 0x10
> and 0x18. Similarly below.
>
>> + /* Invalid? Skip. */
>> + rldicl. r0, r10, 37, 63
>> + beq slb_entry_skip_1
>> + xoris r9, r10, SLB_ESID_V@h
>> + std r9, 0x10(r12)
>> +slb_entry_skip_1:
>> + ld r9, 0x20(r12)
>> + /* Invalid? Skip. */
>> + rldicl. r0, r9, 37, 63
>> + beq slb_entry_skip_2
>> + xoris r9, r9, SLB_ESID_V@h
>> + std r9, 0x20(r12)
>> +slb_entry_skip_2:
>> + ld r9, 0x30(r12)
>> + /* Invalid? Skip. */
>> + rldicl. r0, r9, 37, 63
>> + beq slb_entry_skip_3
>> + xoris r9, r9, SLB_ESID_V@h
>> + std r9, 0x30(r12)
>
> Can these 3 be made into a macro?
Phew - dynamically generating jump points sounds rather hard. I can
give it a try...
>
>> +slb_entry_skip_3:
>> +
>> +#else
>> +#error unknown number of bolted entries
>> +#endif
>> +
>> + /* Flush SLB */
>> +
>> + slbia
>> +
>> + /* r0 = esid & ESID_MASK */
>> + rldicr r10, r10, 0, 35
>> + /* r0 |= CLASS_BIT(VSID) */
>> + rldic r12, r11, 56 - 36, 36
>> + or r10, r10, r12
>> + slbie r10
>> +
>> + isync
>> +
>> + /* Fill SLB with our shadow */
>> +
>> + lbz r12, PACA_KVM_SLB_MAX(r13)
>> + mulli r12, r12, 16
>> + addi r12, r12, PACA_KVM_SLB
>> + add r12, r12, r13
>> +
>> + /* for (r11 = kvm_slb; r11 < kvm_slb + kvm_slb_size;
>> r11+=slb_entry) */
>> + li r11, PACA_KVM_SLB
>> + add r11, r11, r13
>> +
>> +slb_loop_enter:
>> +
>> + ld r10, 0(r11)
>> +
>> + rldicl. r0, r10, 37, 63
>> + beq slb_loop_enter_skip
>> +
>> + ld r9, 8(r11)
>> + slbmte r9, r10
>
> If you're updating the first 3 slbs, you need to make sure the slb
> shadow is updated at the same time
Well - what happens if we don't? We'd get a segment fault when phyp
stole our entry! So what? Let it fault, see the mapping is already
there and get back in again :-).
> (BTW dumb question: can we run this
> under PHYP?)
Yes, I tested it on bare metal, phyp and a PS3.
Alex
^ permalink raw reply
* Re: [PATCH 11/27] Add book3s_64 Host MMU handling
From: Alexander Graf @ 2009-11-02 9:26 UTC (permalink / raw)
To: Michael Neuling
Cc: Kevin Wolf, Arnd Bergmann, Hollis Blanchard, Marcelo Tosatti,
kvm-ppc, linuxppc-dev@ozlabs.org, Avi Kivity, kvm@vger.kernel.org,
bphilips@suse.de, Olof Johansson
In-Reply-To: <7786.1257118763@neuling.org>
Am 02.11.2009 um 00:39 schrieb Michael Neuling <mikey@neuling.org>:
> <snip>
>> +static void invalidate_pte(struct hpte_cache *pte)
>> +{
>> + dprintk_mmu("KVM: Flushing SPT %d: 0x%llx (0x%llx) -> 0x%llx\n",
>> + i, pte->pte.eaddr, pte->pte.vpage, pte->host_va);
>> +
>> + ppc_md.hpte_invalidate(pte->slot, pte->host_va,
>> + MMU_PAGE_4K, MMU_SEGSIZE_256M,
>> + false);
>
> Are we assuming 256M segments here (and elsewhere)?
Yes, on the host we only create 256MB segments. What the guest uses is
a different question.
>
> <snip>
>> +static int kvmppc_mmu_next_segment(struct kvm_vcpu *vcpu, ulong
>> esid)
>> +{
>> + int i;
>> + int max_slb_size = 64;
>> + int found_inval = -1;
>> + int r;
>> +
>> + if (!get_paca()->kvm_slb_max)
>> + get_paca()->kvm_slb_max = 1;
>> +
>> + /* Are we overwriting? */
>> + for (i = 1; i < get_paca()->kvm_slb_max; i++) {
>> + if (!(get_paca()->kvm_slb[i].esid & SLB_ESID_V))
>> + found_inval = i;
>> + else if ((get_paca()->kvm_slb[i].esid & ESID_MASK) == esid)
>> + return i;
>> + }
>> +
>> + /* Found a spare entry that was invalidated before */
>> + if (found_inval > 0)
>> + return found_inval;
>> +
>> + /* No spare invalid entry, so create one */
>> +
>> + if (mmu_slb_size < 64)
>> + max_slb_size = mmu_slb_size;
>
> Can we just use the global mmu_slb_size eliminate max_slb_size?
Hm, for a strange reason I wanted to have at most 64 slb entries.
Maybe the struct can't hold more? I'll check again as soon as I'm on a
notebook again.
Alex
>
> <snip>
>
> Mikey
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 08/27] Add SLB switching code for entry/exit
From: Michael Neuling @ 2009-11-02 9:39 UTC (permalink / raw)
To: Alexander Graf
Cc: Kevin Wolf, Arnd Bergmann, Hollis Blanchard, Marcelo Tosatti,
kvm-ppc, linuxppc-dev@ozlabs.org, Avi Kivity, kvm@vger.kernel.org,
bphilips@suse.de, Olof Johansson
In-Reply-To: <00BF2D99-F2CE-4204-B4B4-0D113FD54CE6@suse.de>
> >> This is the really low level of guest entry/exit code.
> >>
> >> Book3s_64 has an SLB, which stores all ESID -> VSID mappings we're
> >> currently aware of.
> >>
> >> The segments in the guest differ from the ones on the host, so we
> >> need
> >> to switch the SLB to tell the MMU that we're in a new context.
> >>
> >> So we store a shadow of the guest's SLB in the PACA, switch to that
> >> on
> >> entry and only restore bolted entries on exit, leaving the rest to
> >> the
> >> Linux SLB fault handler.
> >>
> >> That way we get a really clean way of switching the SLB.
> >>
> >> Signed-off-by: Alexander Graf <agraf@suse.de>
> >> ---
> >> arch/powerpc/kvm/book3s_64_slb.S | 277 ++++++++++++++++++++++++++++
> >> ++++++++
> > ++
> >> 1 files changed, 277 insertions(+), 0 deletions(-)
> >> create mode 100644 arch/powerpc/kvm/book3s_64_slb.S
> >>
> >> diff --git a/arch/powerpc/kvm/book3s_64_slb.S b/arch/powerpc/kvm/
> >> book3s_64_sl
> > b.S
> >> new file mode 100644
> >> index 0000000..00a8367
> >> --- /dev/null
> >> +++ b/arch/powerpc/kvm/book3s_64_slb.S
> >> @@ -0,0 +1,277 @@
> >> +/*
> >> + * This program is free software; you can redistribute it and/or
> >> modify
> >> + * it under the terms of the GNU General Public License, version
> >> 2, as
> >> + * published by the Free Software Foundation.
> >> + *
> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >> + * GNU General Public License for more details.
> >> + *
> >> + * You should have received a copy of the GNU General Public License
> >> + * along with this program; if not, write to the Free Software
> >> + * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
> >> 02110-1301, USA.
> >> + *
> >> + * Copyright SUSE Linux Products GmbH 2009
> >> + *
> >> + * Authors: Alexander Graf <agraf@suse.de>
> >> + */
> >> +
> >> +/
> >> ***
> >> ***
> >> *********************************************************************
> > ***
> >> + *
> > *
> >> + * Entry code
> > *
> >> + *
> > *
> >> +
> >> ***
> >> ***
> >> *********************************************************************
> > **/
> >> +
> >> +.global kvmppc_handler_trampoline_enter
> >> +kvmppc_handler_trampoline_enter:
> >> +
> >> + /* Required state:
> >> + *
> >> + * MSR = ~IR|DR
> >> + * R13 = PACA
> >> + * R9 = guest IP
> >> + * R10 = guest MSR
> >> + * R11 = free
> >> + * R12 = free
> >> + * PACA[PACA_EXMC + EX_R9] = guest R9
> >> + * PACA[PACA_EXMC + EX_R10] = guest R10
> >> + * PACA[PACA_EXMC + EX_R11] = guest R11
> >> + * PACA[PACA_EXMC + EX_R12] = guest R12
> >> + * PACA[PACA_EXMC + EX_R13] = guest R13
> >> + * PACA[PACA_EXMC + EX_CCR] = guest CR
> >> + * PACA[PACA_EXMC + EX_R3] = guest XER
> >> + */
> >> +
> >> + mtsrr0 r9
> >> + mtsrr1 r10
> >> +
> >> + mtspr SPRN_SPRG_SCRATCH0, r0
> >> +
> >> + /* Remove LPAR shadow entries */
> >> +
> >> +#if SLB_NUM_BOLTED == 3
> >
> > You could alternatively check the persistent entry in the slb_shawdow
> > buffer. This would give you a run time check. Not sure what's best
> > though.
>
> Well we're in the hot path here, so anything using as few registers as
> possible and being simple is the best :-). I'd guess the more we are
> clever at compile time the better.
Yeah, I tend to agree.
>
> >
> >
> >> +
> >> + ld r12, PACA_SLBSHADOWPTR(r13)
> >> + ld r10, 0x10(r12)
> >> + ld r11, 0x18(r12)
> >
> > Can you define something in asm-offsets.c for these magic constants
> > 0x10
> > and 0x18. Similarly below.
> >
> >> + /* Invalid? Skip. */
> >> + rldicl. r0, r10, 37, 63
> >> + beq slb_entry_skip_1
> >> + xoris r9, r10, SLB_ESID_V@h
> >> + std r9, 0x10(r12)
> >> +slb_entry_skip_1:
> >> + ld r9, 0x20(r12)
> >> + /* Invalid? Skip. */
> >> + rldicl. r0, r9, 37, 63
> >> + beq slb_entry_skip_2
> >> + xoris r9, r9, SLB_ESID_V@h
> >> + std r9, 0x20(r12)
> >> +slb_entry_skip_2:
> >> + ld r9, 0x30(r12)
> >> + /* Invalid? Skip. */
> >> + rldicl. r0, r9, 37, 63
> >> + beq slb_entry_skip_3
> >> + xoris r9, r9, SLB_ESID_V@h
> >> + std r9, 0x30(r12)
> >
> > Can these 3 be made into a macro?
>
> Phew - dynamically generating jump points sounds rather hard. I can
> give it a try...
>
> >
> >> +slb_entry_skip_3:
> >> +
> >> +#else
> >> +#error unknown number of bolted entries
> >> +#endif
> >> +
> >> + /* Flush SLB */
> >> +
> >> + slbia
> >> +
> >> + /* r0 = esid & ESID_MASK */
> >> + rldicr r10, r10, 0, 35
> >> + /* r0 |= CLASS_BIT(VSID) */
> >> + rldic r12, r11, 56 - 36, 36
> >> + or r10, r10, r12
> >> + slbie r10
> >> +
> >> + isync
> >> +
> >> + /* Fill SLB with our shadow */
> >> +
> >> + lbz r12, PACA_KVM_SLB_MAX(r13)
> >> + mulli r12, r12, 16
> >> + addi r12, r12, PACA_KVM_SLB
> >> + add r12, r12, r13
> >> +
> >> + /* for (r11 = kvm_slb; r11 < kvm_slb + kvm_slb_size;
> >> r11+=slb_entry) */
> >> + li r11, PACA_KVM_SLB
> >> + add r11, r11, r13
> >> +
> >> +slb_loop_enter:
> >> +
> >> + ld r10, 0(r11)
> >> +
> >> + rldicl. r0, r10, 37, 63
> >> + beq slb_loop_enter_skip
> >> +
> >> + ld r9, 8(r11)
> >> + slbmte r9, r10
> >
> > If you're updating the first 3 slbs, you need to make sure the slb
> > shadow is updated at the same time
>
> Well - what happens if we don't? We'd get a segment fault when phyp
> stole our entry! So what? Let it fault, see the mapping is already
> there and get back in again :-).
The problem is you won't take the segment fault as PHYP may put a valid
entry in there. PHYP will put back what's in the shadow buffer, which
could be valid hence no segment fault.
> > (BTW dumb question: can we run this
> > under PHYP?)
>
> Yes, I tested it on bare metal, phyp and a PS3.
Nice!
Mikey
^ permalink raw reply
* Re: [PATCH 08/27] Add SLB switching code for entry/exit
From: Alexander Graf @ 2009-11-02 9:59 UTC (permalink / raw)
To: Michael Neuling
Cc: Kevin Wolf, Arnd Bergmann, Hollis Blanchard, Marcelo Tosatti,
kvm-ppc, linuxppc-dev@ozlabs.org, Avi Kivity, kvm@vger.kernel.org,
bphilips@suse.de, Olof Johansson
In-Reply-To: <11094.1257154783@neuling.org>
Am 02.11.2009 um 10:39 schrieb Michael Neuling <mikey@neuling.org>:
>>>> This is the really low level of guest entry/exit code.
>>>>
>>>> Book3s_64 has an SLB, which stores all ESID -> VSID mappings we're
>>>> currently aware of.
>>>>
>>>> The segments in the guest differ from the ones on the host, so we
>>>> need
>>>> to switch the SLB to tell the MMU that we're in a new context.
>>>>
>>>> So we store a shadow of the guest's SLB in the PACA, switch to that
>>>> on
>>>> entry and only restore bolted entries on exit, leaving the rest to
>>>> the
>>>> Linux SLB fault handler.
>>>>
>>>> That way we get a really clean way of switching the SLB.
>>>>
>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>> ---
>>>> arch/powerpc/kvm/book3s_64_slb.S | 277 ++++++++++++++++++++++++++
>>>> ++
>>>> ++++++++
>>> ++
>>>> 1 files changed, 277 insertions(+), 0 deletions(-)
>>>> create mode 100644 arch/powerpc/kvm/book3s_64_slb.S
>>>>
>>>> diff --git a/arch/powerpc/kvm/book3s_64_slb.S b/arch/powerpc/kvm/
>>>> book3s_64_sl
>>> b.S
>>>> new file mode 100644
>>>> index 0000000..00a8367
>>>> --- /dev/null
>>>> +++ b/arch/powerpc/kvm/book3s_64_slb.S
>>>> @@ -0,0 +1,277 @@
>>>> +/*
>>>> + * This program is free software; you can redistribute it and/or
>>>> modify
>>>> + * it under the terms of the GNU General Public License, version
>>>> 2, as
>>>> + * published by the Free Software Foundation.
>>>> + *
>>>> + * This program is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>>> + * GNU General Public License for more details.
>>>> + *
>>>> + * You should have received a copy of the GNU General Public
>>>> License
>>>> + * along with this program; if not, write to the Free Software
>>>> + * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
>>>> 02110-1301, USA.
>>>> + *
>>>> + * Copyright SUSE Linux Products GmbH 2009
>>>> + *
>>>> + * Authors: Alexander Graf <agraf@suse.de>
>>>> + */
>>>> +
>>>> +/
>>>> ***
>>>> ***
>>>> ***
>>>> ******************************************************************
>>> ***
>>>> + *
>>> *
>>>> + * Entry code
>>> *
>>>> + *
>>> *
>>>> +
>>>> ***
>>>> ***
>>>> ***
>>>> ******************************************************************
>>> **/
>>>> +
>>>> +.global kvmppc_handler_trampoline_enter
>>>> +kvmppc_handler_trampoline_enter:
>>>> +
>>>> + /* Required state:
>>>> + *
>>>> + * MSR = ~IR|DR
>>>> + * R13 = PACA
>>>> + * R9 = guest IP
>>>> + * R10 = guest MSR
>>>> + * R11 = free
>>>> + * R12 = free
>>>> + * PACA[PACA_EXMC + EX_R9] = guest R9
>>>> + * PACA[PACA_EXMC + EX_R10] = guest R10
>>>> + * PACA[PACA_EXMC + EX_R11] = guest R11
>>>> + * PACA[PACA_EXMC + EX_R12] = guest R12
>>>> + * PACA[PACA_EXMC + EX_R13] = guest R13
>>>> + * PACA[PACA_EXMC + EX_CCR] = guest CR
>>>> + * PACA[PACA_EXMC + EX_R3] = guest XER
>>>> + */
>>>> +
>>>> + mtsrr0 r9
>>>> + mtsrr1 r10
>>>> +
>>>> + mtspr SPRN_SPRG_SCRATCH0, r0
>>>> +
>>>> + /* Remove LPAR shadow entries */
>>>> +
>>>> +#if SLB_NUM_BOLTED == 3
>>>
>>> You could alternatively check the persistent entry in the
>>> slb_shawdow
>>> buffer. This would give you a run time check. Not sure what's best
>>> though.
>>
>> Well we're in the hot path here, so anything using as few registers
>> as
>> possible and being simple is the best :-). I'd guess the more we are
>> clever at compile time the better.
>
> Yeah, I tend to agree.
>
>>
>>>
>>>
>>>> +
>>>> + ld r12, PACA_SLBSHADOWPTR(r13)
>>>> + ld r10, 0x10(r12)
>>>> + ld r11, 0x18(r12)
>>>
>>> Can you define something in asm-offsets.c for these magic constants
>>> 0x10
>>> and 0x18. Similarly below.
>>>
>>>> + /* Invalid? Skip. */
>>>> + rldicl. r0, r10, 37, 63
>>>> + beq slb_entry_skip_1
>>>> + xoris r9, r10, SLB_ESID_V@h
>>>> + std r9, 0x10(r12)
>>>> +slb_entry_skip_1:
>>>> + ld r9, 0x20(r12)
>>>> + /* Invalid? Skip. */
>>>> + rldicl. r0, r9, 37, 63
>>>> + beq slb_entry_skip_2
>>>> + xoris r9, r9, SLB_ESID_V@h
>>>> + std r9, 0x20(r12)
>>>> +slb_entry_skip_2:
>>>> + ld r9, 0x30(r12)
>>>> + /* Invalid? Skip. */
>>>> + rldicl. r0, r9, 37, 63
>>>> + beq slb_entry_skip_3
>>>> + xoris r9, r9, SLB_ESID_V@h
>>>> + std r9, 0x30(r12)
>>>
>>> Can these 3 be made into a macro?
>>
>> Phew - dynamically generating jump points sounds rather hard. I can
>> give it a try...
>>
>>>
>>>> +slb_entry_skip_3:
>>>> +
>>>> +#else
>>>> +#error unknown number of bolted entries
>>>> +#endif
>>>> +
>>>> + /* Flush SLB */
>>>> +
>>>> + slbia
>>>> +
>>>> + /* r0 = esid & ESID_MASK */
>>>> + rldicr r10, r10, 0, 35
>>>> + /* r0 |= CLASS_BIT(VSID) */
>>>> + rldic r12, r11, 56 - 36, 36
>>>> + or r10, r10, r12
>>>> + slbie r10
>>>> +
>>>> + isync
>>>> +
>>>> + /* Fill SLB with our shadow */
>>>> +
>>>> + lbz r12, PACA_KVM_SLB_MAX(r13)
>>>> + mulli r12, r12, 16
>>>> + addi r12, r12, PACA_KVM_SLB
>>>> + add r12, r12, r13
>>>> +
>>>> + /* for (r11 = kvm_slb; r11 < kvm_slb + kvm_slb_size;
>>>> r11+=slb_entry) */
>>>> + li r11, PACA_KVM_SLB
>>>> + add r11, r11, r13
>>>> +
>>>> +slb_loop_enter:
>>>> +
>>>> + ld r10, 0(r11)
>>>> +
>>>> + rldicl. r0, r10, 37, 63
>>>> + beq slb_loop_enter_skip
>>>> +
>>>> + ld r9, 8(r11)
>>>> + slbmte r9, r10
>>>
>>> If you're updating the first 3 slbs, you need to make sure the slb
>>> shadow is updated at the same time
>>
>> Well - what happens if we don't? We'd get a segment fault when phyp
>> stole our entry! So what? Let it fault, see the mapping is already
>> there and get back in again :-).
>
> The problem is you won't take the segment fault as PHYP may put a
> valid
> entry in there. PHYP will put back what's in the shadow buffer, which
> could be valid hence no segment fault.
The shadow buffer contains V=0 entries :).
Alex
>
>>> (BTW dumb question: can we run this
>>> under PHYP?)
>>
>> Yes, I tested it on bare metal, phyp and a PS3.
>
> Nice!
>
> Mikey
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] mpc52xx-psc-spi: refactor probe and remove to make use of of_register_spi_devices()
From: Wolfram Sang @ 2009-11-02 13:14 UTC (permalink / raw)
To: Grant Likely
Cc: Kári Davíðsson, spi-devel-general, linuxppc-dev
In-Reply-To: <fa686aa40910311803m43504167s1ad802aecd2b4344@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3131 bytes --]
Hi Grant,
> the patch referenced above is a little ugly. Adding the call should
Agreed. I just referenced it to show there are more people wanting this
feature.
> be really simple. I've drafted a patch to do only that step and
> attached it to this mail. If this one works for you, then I'll merge
> it immediately into -next.
One minor comment, but works in general:
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
> Also, I'm resistant to changing the probe layout on this driver at
> this time. With the work being done to generalize the OF support
> code, there is a strong possibility that of_platform will be
> deprecated in favor of going back to using the platform bus directly
> (just like how OF support works for i2c, spi, etc). I'd rather not
> refactor the driver until I'm certain of the direction that things are
> going to go.
And this was possibly the best answer I could get \o/ Sounds really promising,
is there somewhere a discussion about how OF-generalization could happen?
> From 7629d40dc343ff216b752d5c68654dc9d30f0c91 Mon Sep 17 00:00:00 2001
> From: Grant Likely <grant.likely@secretlab.ca>
> Date: Sat, 31 Oct 2009 17:49:38 -0600
> Subject: [PATCH] spi/mpc5200: Register SPI devices described in device tree
>
> Add call to of_register_spi_devices() to register SPI devices described
> in the OF device tree.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> drivers/spi/mpc52xx_psc_spi.c | 8 +++++++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.c
> index 1b74d5c..b445464 100644
> --- a/drivers/spi/mpc52xx_psc_spi.c
> +++ b/drivers/spi/mpc52xx_psc_spi.c
> @@ -17,6 +17,7 @@
> #include <linux/errno.h>
> #include <linux/interrupt.h>
> #include <linux/of_platform.h>
> +#include <linux/of_spi.h>
> #include <linux/workqueue.h>
> #include <linux/completion.h>
> #include <linux/io.h>
> @@ -464,6 +465,7 @@ static int __init mpc52xx_psc_spi_of_probe(struct of_device *op,
> const u32 *regaddr_p;
> u64 regaddr64, size64;
> s16 id = -1;
> + int rc;
>
> regaddr_p = of_get_address(op->node, 0, &size64, NULL);
> if (!regaddr_p) {
> @@ -485,8 +487,12 @@ static int __init mpc52xx_psc_spi_of_probe(struct of_device *op,
> id = *psc_nump + 1;
> }
>
> - return mpc52xx_psc_spi_do_probe(&op->dev, (u32)regaddr64, (u32)size64,
> + rc = mpc52xx_psc_spi_do_probe(&op->dev, (u32)regaddr64, (u32)size64,
> irq_of_parse_and_map(op->node, 0), id);
> + if (!rc)
A matter of taste, maybe: I'd prefer
if (rc == 0)
as (!ptr) is often used for catching errors with pointers, but here it is the
'all went OK'-path.
> + of_register_spi_devices(dev_get_drvdata(&op->dev), op->node);
> +
> + return rc;
> }
>
> static int __exit mpc52xx_psc_spi_of_remove(struct of_device *op)
> --
> 1.6.3.3
>
Regards,
Wolfram
--
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: Filtering bits in set_pte_at()
From: Hugh Dickins @ 2009-11-02 13:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-mm@kvack.org, linuxppc-dev, linux-kernel@vger.kernel.org
In-Reply-To: <1256957081.6372.344.camel@pasglop>
On Sat, 31 Oct 2009, Benjamin Herrenschmidt wrote:
> Hi folks !
>
> So I have a little problem on powerpc ... :-)
Thanks a lot for running this by us.
>
> Due to the way I'm attempting to do my I$/D$ coherency on embedded
> processors, I basically need to "filter out" _PAGE_EXEC in set_pte_at()
> if the page isn't clean (PG_arch_1) and the set_pte_at() isn't caused by
> an exec fault. etc...
>
> The problem with that approach (current upstream) is that the generic
> code tends not to read back the PTE, and thus still carries around a PTE
> value that doesn't match what was actually written.
>
> For example, we end up with update_mmu_cache() called with an "entry"
> argument that has _PAGE_EXEC set while we really didn't write it into
> the page tables. This will be problematic when we finally add preloading
> directly into the TLB on those processors. There's at least one other
> fishy case where huetlbfs would carry the PTE value around and later do
> the wrong thing because pte_same() with the loaded one failed.
I've not looked to see if there are more such issues in arch/powerpc
itself, but those instances you mention are the only ones I managed
to find: uses of update_mmu_cache() and that hugetlb_cow() one.
The hugetlb_cow() one involves not set_pte_at() but set_huge_pte_at(),
so you'd want to change that too? And presumably set_pte_at_notify()?
It all seems a lot of tedium, when so very few places are interested
in the pte after they've set it.
>
> What do you suggest we do here ? Among the options at hand:
>
> - Ugly but would probably "just work" with the last amount of changes:
> we could make set_pte_at() be a macro on powerpc that modifies it's PTE
> value argument :-) (I -did- warn it was ugly !)
I'm not keen on that one :)
>
> - Another one slightly less bad that would require more work but mostly
> mechanical arch header updates would be to make set_pte_at() return the
> new value of the PTE, and thus change the callsites to something like:
>
> entry = set_pte_at(mm, addr, ptep, entry)
I prefer that, but it still seems more trouble than it's worth.
And though I prefer it to set_pte_at(mm, addr, ptep, &entry)
(which would anyway complicate many of the callsites), it might
unnecessarily increase the codesize for all architectures (depends
on whether gcc notices entry isn't used afterwards anyway).
>
> - Any other idea ? We could use another PTE bit (_PAGE_HWEXEC), in
> fact, we used to, but we are really short on PTE bits nowadays and I
> freed that one up to get _PAGE_SPECIAL... _PAGE_EXEC is trivial to
> "recover" from ptep_set_access_flags() on an exec fault or from the VM
> prot.
No, please don't go ransacking your PTE for a sparish bit.
You're being a very good citizen to want to bring this so forcefully
to the attention of any user of set_pte_at(); but given how few care,
and the other such functions you'd want to change too, am I being
disgracefully lazy to suggest that you simply change the occasional
update_mmu_cache(vma, address, pte);
to
/* powerpc's set_pte_at might have adjusted the pte */
update_mmu_cache(vma, address, *ptep);
? Which would make no difference to those architectures whose
update_mmu_cache() is an empty macro. And fix the mm/hugetlb.c
instance in a similar way?
Hugh
^ permalink raw reply
* Re: [PATCH] spi/mpc52xx: check for invalid PSC usage
From: Wolfram Sang @ 2009-11-02 13:53 UTC (permalink / raw)
To: Grant Likely; +Cc: spi-devel-general, David Brownell, linuxppc-dev
In-Reply-To: <fa686aa40910311822i4ba27b2bs350c5684cd57187b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2509 bytes --]
> I wouldn't even bother. It's not actively dangerous to try and use
> PSC{4,5} in SPI mode. It just not going to work. Besides, the
> MPC5200 common code already checks for an invalid PSC number when
> setting the clock divisor.
>
> Have you seen cases of users trying to do the wrong thing with the
> crippled PSCs?
Yes, that was the reason for this patch :) How about this patch to give users a
better idea than just -ENODEV via set_psc_clkdiv? ...[/me hacks]...
Uuuh, there is even a bug which makes the case go unnoticed.
===
Subject: [PATCH] spi/mpc52xx-psc-spi: check for valid PSC
This driver calls mpc52xx_set_psc_clkdiv() but doesn't check its return value
to see if the PSC is actually valid for SPI use. Add the check and a hint for
the user.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
drivers/spi/mpc52xx_psc_spi.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.c
index 1b74d5c..e268437 100644
--- a/drivers/spi/mpc52xx_psc_spi.c
+++ b/drivers/spi/mpc52xx_psc_spi.c
@@ -313,11 +313,13 @@ static int mpc52xx_psc_spi_port_config(int psc_id, struct mpc52xx_psc_spi *mps)
struct mpc52xx_psc __iomem *psc = mps->psc;
struct mpc52xx_psc_fifo __iomem *fifo = mps->fifo;
u32 mclken_div;
- int ret = 0;
+ int ret;
/* default sysclk is 512MHz */
mclken_div = (mps->sysclk ? mps->sysclk : 512000000) / MCLK;
- mpc52xx_set_psc_clkdiv(psc_id, mclken_div);
+ ret = mpc52xx_set_psc_clkdiv(psc_id, mclken_div);
+ if (ret)
+ return ret;
/* Reset the PSC into a known state */
out_8(&psc->command, MPC52xx_PSC_RST_RX);
@@ -341,7 +343,7 @@ static int mpc52xx_psc_spi_port_config(int psc_id, struct mpc52xx_psc_spi *mps)
mps->bits_per_word = 8;
- return ret;
+ return 0;
}
static irqreturn_t mpc52xx_psc_spi_isr(int irq, void *dev_id)
@@ -410,8 +412,10 @@ static int __init mpc52xx_psc_spi_do_probe(struct device *dev, u32 regaddr,
goto free_master;
ret = mpc52xx_psc_spi_port_config(master->bus_num, mps);
- if (ret < 0)
+ if (ret < 0) {
+ dev_err(dev, "can't configure PSC! Is it capable of SPI?\n");
goto free_irq;
+ }
spin_lock_init(&mps->lock);
init_completion(&mps->done);
--
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 related
* Re: mpc512x/clock: fix clk_get logic
From: Wolfram Sang @ 2009-11-02 14:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Wolfgang Denk
In-Reply-To: <1257022082.7907.7.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 312 bytes --]
> Sure I don't have major objections against your patch (though who is
> formally mpc512x maintainer to ack it ?),
Grant is maintainer for MPC5xxx.
--
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
* [PATCH] mpc512x/clocks: initialize CAN clocks
From: Wolfram Sang @ 2009-11-02 15:17 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Chen Hongjun, John Rigby, Wolfgang Denk
In-Reply-To: <1256925231-21917-1-git-send-email-w.sang@pengutronix.de>
Signed-off-by: John Rigby <jrigby@freescale.com>
Signed-off-by: Chen Hongjun <hong-jun.chen@freescale.com>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
Should come after the fix for clk_get to be usable for the upcoming CAN driver:
http://patchwork.ozlabs.org/patch/37342/
arch/powerpc/platforms/512x/clock.c | 74 +++++++++++++++++++++++++++++++++++
1 files changed, 74 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/512x/clock.c b/arch/powerpc/platforms/512x/clock.c
index 4168457..2d3a5ef 100644
--- a/arch/powerpc/platforms/512x/clock.c
+++ b/arch/powerpc/platforms/512x/clock.c
@@ -50,6 +50,8 @@ struct clk {
static LIST_HEAD(clocks);
static DEFINE_MUTEX(clocks_mutex);
+struct clk mscan_clks[4];
+
static struct clk *mpc5121_clk_get(struct device *dev, const char *id)
{
struct clk *p, *clk = ERR_PTR(-ENOENT);
@@ -119,6 +121,8 @@ struct mpc512x_clockctl {
u32 spccr; /* SPDIF Clk Ctrl Reg */
u32 cccr; /* CFM Clk Ctrl Reg */
u32 dccr; /* DIU Clk Cnfg Reg */
+ /* rev2+ only regs */
+ u32 mccr[4]; /* MSCAN Clk Ctrl Reg 1-4 */
};
struct mpc512x_clockctl __iomem *clockctl;
@@ -688,6 +692,72 @@ static void psc_clks_init(void)
}
}
+
+/*
+ * mscan clock rate calculation
+ */
+static unsigned long mscan_calc_rate(struct device_node *np, int mscannum)
+{
+ unsigned long mscanclk_src, mscanclk_div;
+ u32 *mccr = &clockctl->mccr[mscannum];
+
+ /*
+ * If the divider is the reset default of all 1's then
+ * we know u-boot and/or board setup has not
+ * done anything so set up a sane default
+ */
+ if (((in_be32(mccr) >> 17) & 0x7fff) == 0x7fff) {
+ /* disable */
+ out_be32(mccr, 0);
+ /* src is sysclk, divider is 4 */
+ out_be32(mccr, (0x3 << 17) | 0x10000);
+ }
+
+ switch ((in_be32(mccr) >> 14) & 0x3) {
+ case 0:
+ mscanclk_src = sys_clk.rate;
+ break;
+ case 1:
+ mscanclk_src = ref_clk.rate;
+ break;
+ case 2:
+ mscanclk_src = psc_mclk_in.rate;
+ break;
+ case 3:
+ mscanclk_src = spdif_txclk.rate;
+ break;
+ }
+
+ mscanclk_src = roundup(mscanclk_src, 1000000);
+ mscanclk_div = ((in_be32(mccr) >> 17) & 0x7fff) + 1;
+ return mscanclk_src / mscanclk_div;
+}
+
+/*
+ * Find all silicon rev2 mscan nodes in device tree and assign a clock
+ * with name "mscan%d_clk" and dev pointing at the device
+ * returned from of_find_device_by_node
+ */
+static void mscan_clks_init(void)
+{
+ struct device_node *np;
+ struct of_device *ofdev;
+ const u32 *cell_index;
+
+ for_each_compatible_node(np, NULL, "fsl,mpc5121-mscan") {
+ cell_index = of_get_property(np, "cell-index", NULL);
+ if (cell_index) {
+ struct clk *clk = &mscan_clks[*cell_index];
+ clk->flags = CLK_HAS_RATE;
+ ofdev = of_find_device_by_node(np);
+ clk->dev = &ofdev->dev;
+ clk->rate = mscan_calc_rate(np, *cell_index);
+ sprintf(clk->name, "mscan%d_clk", *cell_index);
+ clk_register(clk);
+ }
+ }
+}
+
static struct clk_interface mpc5121_clk_functions = {
.clk_get = mpc5121_clk_get,
.clk_enable = mpc5121_clk_enable,
@@ -719,6 +789,10 @@ mpc5121_clk_init(void)
rate_clks_init();
psc_clks_init();
+ /* Setup per-controller CAN clocks for Rev2 and later */
+ if (((mfspr(SPRN_SVR) >> 4) & 0xF) > 1)
+ mscan_clks_init();
+
/* leave clockctl mapped forever */
/*iounmap(clockctl); */
DEBUG_CLK_DUMP();
--
1.6.3.3
^ permalink raw reply related
* mpc8548 does not make use of DMA when doing memory copy?
From: hank peng @ 2009-11-02 15:40 UTC (permalink / raw)
To: linuxppc-dev
Kernel version is 2.6.30 and I have enabled fsl DMA engine during
configuring kernel. After system booted, I have seen only 38 DMA
interrupts, and no increase later when I am doing data transfer
through network.
So I wonder if mpc8548 had made use of DMA engine when doing memcpy,
or maybe if there are other things I haven't noticed?
--
The simplest is not all best but the best is surely the simplest!
^ permalink raw reply
* Re: [PATCH] macintosh: Explicitly set llseek to no_llseek in ans-lcd
From: Arnd Bergmann @ 2009-11-02 15:51 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Arnd Bergmann, Jonathan Corbet, LKML, linuxppc-dev, John Kacur,
Thomas Gleixner, Ingo Molnar, Alan Cox
In-Reply-To: <20091021221619.GF4880@nowhere>
On Thursday 22 October 2009, Frederic Weisbecker wrote:
> > I'm thinking that the simplier approach, would be to make the
> > default_llseek the unlocked one. Then you only have to audit the drivers
> > that have the BKL - ie the ones we are auditing anyway, and explicitly set
> > them to the bkl locked llseek.
> >
> > There might be a hidden interaction though between the non-unlocked
> > variety of ioctls and default llseek though.
>
>
> I fear that won't work because the bkl in default_llseek() does not
> only synchronizes with others uses of the bkl in a driver, it also
> synchronizes lseek() itself.
>
> As an example offset change is not atomic. This is a long long, so
> updating its value is not atomic in 32 bits archs.
A late follow-up on this one:
I looked at what places in the code manipulate file->f_pos directly
and found that almost all the uses in driver code are broken because
they don't take any locks. Most of them are in driver specific
lseek operations. Others are in read/write methods and are even
more broken because the change gets immediately overwritten by
vfs_read/vfs_write when the driver method returns.
IMHO, we should complete the pushdown into all ioctl methods
that John and Thomas have started working on, fixing the lseek
methods in those files we touch.
When that is done, all interaction between default_llseek and
driver locking has to be with explicit calls to lock_kernel
in those drivers, so we can reasonably well script the search
for drivers needing the BKL in llseek: everyhing that
a) defines file_operations without an llseek function,
b) touches f_pos somewhere, and
c) calls lock_kernel() somewhere
That should only be a small number and when they are fixed,
we can remove default_llseek and instead call generic_file_llseek
for any file operation without a separate llseek method.
Arnd <><
^ permalink raw reply
* Re: [PATCH] mpc52xx-psc-spi: refactor probe and remove to make use of of_register_spi_devices()
From: Grant Likely @ 2009-11-02 16:08 UTC (permalink / raw)
To: Wolfram Sang
Cc: Kári Davíðsson, spi-devel-general, linuxppc-dev
In-Reply-To: <20091102131427.GB4696@pengutronix.de>
On Mon, Nov 2, 2009 at 6:14 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
>> Also, I'm resistant to changing the probe layout on this driver at
>> this time. =A0With the work being done to generalize the OF support
>> code, there is a strong possibility that of_platform will be
>> deprecated in favor of going back to using the platform bus directly
>> (just like how OF support works for i2c, spi, etc). =A0I'd rather not
>> refactor the driver until I'm certain of the direction that things are
>> going to go.
>
> And this was possibly the best answer I could get \o/ Sounds really promi=
sing,
> is there somewhere a discussion about how OF-generalization could happen?
It has been discussed on-and-off on the mailing list and on IRC.
There are 2 major problems that need to be solved before it can be
done:
1. Figure out how to do OF-style driver probing with the platform bus.
I could use the same heuristic as used by i2c & spi, but that
approach isn't very scalable, and doesn't handle backwards
compatibility very well.
2. Figure out the best way to extract platform data from the device
tree without having a huge impact on the device drivers. The adapter
code still driver specific, so it needs to be part of the device
driver itself, but I want to establish a pattern which does not
require major surgery to platform drivers in order to add OF support.
>> - =A0 =A0 return mpc52xx_psc_spi_do_probe(&op->dev, (u32)regaddr64, (u32=
)size64,
>> + =A0 =A0 rc =3D mpc52xx_psc_spi_do_probe(&op->dev, (u32)regaddr64, (u32=
)size64,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 irq_of_parse_and_map(op->node, 0), id);
>> + =A0 =A0 if (!rc)
>
> A matter of taste, maybe: I'd prefer
>
> =A0 =A0 =A0 =A0if (rc =3D=3D 0)
>
> as (!ptr) is often used for catching errors with pointers, but here it is=
the
> 'all went OK'-path.
Okay, I'll change this. Thanks for the feedback.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 3/6 v5] Memory probe/release files
From: Nathan Fontenot @ 2009-11-02 16:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1256786013.26770.40.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Wed, 2009-10-28 at 15:55 -0500, Nathan Fontenot wrote:
>> This patch creates the release sysfs file for memory and updates the
>> exisiting probe file so both make arch-specific callouts to handle removing
>> and adding memory to the system. This also creates the powerpc specific stubs
>> for handling the arch callouts.
>>
>> The creation and use of these files are governed by the exisitng
>> CONFIG_ARCH_MEMORY_PROBE and new CONFIG_ARCH_MEMORY_RELEASE config options.
>>
>> Signed-off-by: Nathan Fontenot <nfont at austin.ibm.com>
>> ---
>
> Is there anybody on linux-mm who needs to Ack this patche ?
Not sure. I will cc linux-mm on the next set of updated patches I send out.
-Nathan
>
> Cheers,
> Ben.
>
>
>
^ permalink raw reply
* Re: [PATCH 6/6 v5] CPU DLPAR Handling
From: Nathan Fontenot @ 2009-11-02 16:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1256786763.26770.46.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Wed, 2009-10-28 at 15:59 -0500, Nathan Fontenot wrote:
>
>> +#ifdef CONFIG_ARCH_CPU_PROBE_RELEASE
>> +static ssize_t cpu_probe(const char *buf, size_t count)
>
> dlpar_cpu_probe() pls
>
>> +static ssize_t cpu_release(const char *buf, size_t count)
>> +{
>
> Ditto.
>
> Or else in system.map, backtraces, etc... it's hard to figure out off
> hand where it's dying :-)
Good point, I'll fix this.
-Nathan
>
> Cheers,
> Ben.
>
>
^ permalink raw reply
* Re: [PATCH 1/6 v5] Kernel DLPAR Infrastructure
From: Nathan Fontenot @ 2009-11-02 16:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1256785731.26770.38.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Wed, 2009-10-28 at 15:53 -0500, Nathan Fontenot wrote:
>> This patch provides the kernel DLPAR infrastructure in a new filed named
>> dlpar.c. The functionality provided is for acquiring and releasing a resource
>> from firmware and the parsing of information returned from the
>> ibm,configure-connector rtas call. Additionally this exports the pSeries
>> reconfiguration notifier chain so that it can be invoked when device tree
>> updates are made.
>>
>> Signed-off-by: Nathan Fontenot <nfont at austin.ibm.com>
>> ---
>
> Hi Nathan !
>
> Finally I get to review this stuff :-)
>
Thanks!
>> +#define CFG_CONN_WORK_SIZE 4096
>> +static char workarea[CFG_CONN_WORK_SIZE];
>> +static DEFINE_SPINLOCK(workarea_lock);
>
> So I'm not a huge fan of this workarea static. First a static is in
> effect a global name (as far as System.map etc... are concerned) so it
> would warrant a better name. Then, do we really want that 4K of BSS
> taken even on platforms that don't do dlpar ? Any reason why you don't
> just pop a free page with __get_free_page() inside of
> configure_connector() ?
>
I'm not either, having a static buffer and a lock feels like overkill
for this. I tried kmalloc, but that didn't work. I'll try using
__get_free_page.
>> +struct cc_workarea {
>> + u32 drc_index;
>> + u32 zero;
>> + u32 name_offset;
>> + u32 prop_length;
>> + u32 prop_offset;
>> +};
>> +
>> +static struct property *parse_cc_property(char *workarea)
>> +{
>> + struct property *prop;
>> + struct cc_workarea *ccwa;
>> + char *name;
>> + char *value;
>> +
>> + prop = kzalloc(sizeof(*prop), GFP_KERNEL);
>> + if (!prop)
>> + return NULL;
>> +
>> + ccwa = (struct cc_workarea *)workarea;
>> + name = workarea + ccwa->name_offset;
>> + prop->name = kzalloc(strlen(name) + 1, GFP_KERNEL);
>> + if (!prop->name) {
>> + kfree(prop);
>> + return NULL;
>> + }
>> +
>> + strcpy(prop->name, name);
>> +
>> + prop->length = ccwa->prop_length;
>> + value = workarea + ccwa->prop_offset;
>> + prop->value = kzalloc(prop->length, GFP_KERNEL);
>> + if (!prop->value) {
>> + kfree(prop->name);
>> + kfree(prop);
>> + return NULL;
>> + }
>> +
>> + memcpy(prop->value, value, prop->length);
>> + return prop;
>> +}
>> +
>> +static void free_property(struct property *prop)
>> +{
>> + kfree(prop->name);
>> + kfree(prop->value);
>> + kfree(prop);
>> +}
>> +
>> +static struct device_node *parse_cc_node(char *work_area)
>> +{
>
> const char* maybe ?
sure.
>
>> + struct device_node *dn;
>> + struct cc_workarea *ccwa;
>> + char *name;
>> +
>> + dn = kzalloc(sizeof(*dn), GFP_KERNEL);
>> + if (!dn)
>> + return NULL;
>> +
>> + ccwa = (struct cc_workarea *)work_area;
>> + name = work_area + ccwa->name_offset;
>
> I'm wondering whether work_area should be a struct cc_workarea * in the
> first place with a char data[] at the end, but that would mean probably
> tweaking the offsets... no big deal, up to you.
>
I'll look onto that. Anything that makes this easier to understand is good.
>> + dn->full_name = kzalloc(strlen(name) + 1, GFP_KERNEL);
>> + if (!dn->full_name) {
>> + kfree(dn);
>> + return NULL;
>> + }
>> +
>> + strcpy(dn->full_name, name);
>
> kstrdup ?
yep, should have used kstrdup.
>
> .../...
>
>> +#define NEXT_SIBLING 1
>> +#define NEXT_CHILD 2
>> +#define NEXT_PROPERTY 3
>> +#define PREV_PARENT 4
>> +#define MORE_MEMORY 5
>> +#define CALL_AGAIN -2
>> +#define ERR_CFG_USE -9003
>> +
>> +struct device_node *configure_connector(u32 drc_index)
>> +{
>
> It's a global exported function, I'd rather you call it
> dlpar_configure_connector()
>
ok.
>> + struct device_node *dn;
>> + struct device_node *first_dn = NULL;
>> + struct device_node *last_dn = NULL;
>> + struct property *property;
>> + struct property *last_property = NULL;
>> + struct cc_workarea *ccwa;
>> + int cc_token;
>> + int rc;
>> +
>> + cc_token = rtas_token("ibm,configure-connector");
>> + if (cc_token == RTAS_UNKNOWN_SERVICE)
>> + return NULL;
>> +
>> + spin_lock(&workarea_lock);
>> +
>> + ccwa = (struct cc_workarea *)&workarea[0];
>> + ccwa->drc_index = drc_index;
>> + ccwa->zero = 0;
>
> Popping a free page with gfp (or just kmalloc'ing 4K) would avoid the
> need for the lock too.
yes, see comment at beginning.
>
>> + rc = rtas_call(cc_token, 2, 1, NULL, workarea, NULL);
>> + while (rc) {
>> + switch (rc) {
>> + case NEXT_SIBLING:
>> + dn = parse_cc_node(workarea);
>> + if (!dn)
>> + goto cc_error;
>> +
>> + dn->parent = last_dn->parent;
>> + last_dn->sibling = dn;
>> + last_dn = dn;
>> + break;
>> +
>> + case NEXT_CHILD:
>> + dn = parse_cc_node(workarea);
>> + if (!dn)
>> + goto cc_error;
>> +
>> + if (!first_dn)
>> + first_dn = dn;
>> + else {
>> + dn->parent = last_dn;
>> + if (last_dn)
>> + last_dn->child = dn;
>> + }
>> +
>> + last_dn = dn;
>> + break;
>> +
>> + case NEXT_PROPERTY:
>> + property = parse_cc_property(workarea);
>> + if (!property)
>> + goto cc_error;
>> +
>> + if (!last_dn->properties)
>> + last_dn->properties = property;
>> + else
>> + last_property->next = property;
>> +
>> + last_property = property;
>> + break;
>> +
>> + case PREV_PARENT:
>> + last_dn = last_dn->parent;
>> + break;
>> +
>> + case CALL_AGAIN:
>> + break;
>> +
>> + case MORE_MEMORY:
>> + case ERR_CFG_USE:
>> + default:
>> + printk(KERN_ERR "Unexpected Error (%d) "
>> + "returned from configure-connector\n", rc);
>> + goto cc_error;
>> + }
>> +
>> + rc = rtas_call(cc_token, 2, 1, NULL, workarea, NULL);
>> + }
>> +
>> + spin_unlock(&workarea_lock);
>> + return first_dn;
>> +
>> +cc_error:
>> + spin_unlock(&workarea_lock);
>> +
>> + if (first_dn)
>> + free_cc_nodes(first_dn);
>> +
>> + return NULL;
>> +}
>> +
>> +static struct device_node *derive_parent(const char *path)
>> +{
>> + struct device_node *parent;
>> + char parent_path[128];
>> + int parent_path_len;
>> +
>> + parent_path_len = strrchr(path, '/') - path + 1;
>> + strlcpy(parent_path, path, parent_path_len);
>> +
>> + parent = of_find_node_by_path(parent_path);
>> +
>> + return parent;
>> +}
>
> This ...
>
>> +static int add_one_node(struct device_node *dn)
>> +{
>> + struct proc_dir_entry *ent;
>> + int rc;
>> +
>> + of_node_set_flag(dn, OF_DYNAMIC);
>> + kref_init(&dn->kref);
>> + dn->parent = derive_parent(dn->full_name);
>> +
>> + rc = blocking_notifier_call_chain(&pSeries_reconfig_chain,
>> + PSERIES_RECONFIG_ADD, dn);
>> + if (rc == NOTIFY_BAD) {
>> + printk(KERN_ERR "Failed to add device node %s\n",
>> + dn->full_name);
>> + return -ENOMEM; /* For now, safe to assume kmalloc failure */
>> + }
>> +
>> + of_attach_node(dn);
>> +
>> +#ifdef CONFIG_PROC_DEVICETREE
>> + ent = proc_mkdir(strrchr(dn->full_name, '/') + 1, dn->parent->pde);
>> + if (ent)
>> + proc_device_tree_add_node(dn, ent);
>> +#endif
>> +
>> + of_node_put(dn->parent);
>> + return 0;
>> +}
>
> ... and this ...
>
>> +int add_device_tree_nodes(struct device_node *dn)
>> +{
>> + struct device_node *child = dn->child;
>> + struct device_node *sibling = dn->sibling;
>> + int rc;
>> +
>> + dn->child = NULL;
>> + dn->sibling = NULL;
>> + dn->parent = NULL;
>> +
>> + rc = add_one_node(dn);
>> + if (rc)
>> + return rc;
>> +
>> + if (child) {
>> + rc = add_device_tree_nodes(child);
>> + if (rc)
>> + return rc;
>> + }
>> +
>> + if (sibling)
>> + rc = add_device_tree_nodes(sibling);
>> +
>> + return rc;
>> +}
>
> ... and this ...
>
>> +static int remove_one_node(struct device_node *dn)
>> +{
>> + struct device_node *parent = dn->parent;
>> + struct property *prop = dn->properties;
>> +
>> +#ifdef CONFIG_PROC_DEVICETREE
>> + while (prop) {
>> + remove_proc_entry(prop->name, dn->pde);
>> + prop = prop->next;
>> + }
>> +
>> + if (dn->pde)
>> + remove_proc_entry(dn->pde->name, parent->pde);
>> +#endif
>> +
>> + blocking_notifier_call_chain(&pSeries_reconfig_chain,
>> + PSERIES_RECONFIG_REMOVE, dn);
>> + of_detach_node(dn);
>> + of_node_put(dn); /* Must decrement the refcount */
>> +
>> + return 0;
>> +}
>
> ... and this ...
>
>> +static int _remove_device_tree_nodes(struct device_node *dn)
>> +{
>> + int rc;
>> +
>> + if (dn->child) {
>> + rc = _remove_device_tree_nodes(dn->child);
>> + if (rc)
>> + return rc;
>> + }
>> +
>> + if (dn->sibling) {
>> + rc = _remove_device_tree_nodes(dn->sibling);
>> + if (rc)
>> + return rc;
>> + }
>> +
>> + rc = remove_one_node(dn);
>> + return rc;
>> +}
>
> ... repeat myself ...
>
>> +int remove_device_tree_nodes(struct device_node *dn)
>> +{
>> + int rc;
>> +
>> + if (dn->child) {
>> + rc = _remove_device_tree_nodes(dn->child);
>> + if (rc)
>> + return rc;
>> + }
>> +
>> + rc = remove_one_node(dn);
>> + return rc;
>> +}
>
> ... should probably all go to something like drivers/of/dynamic.c or at
> least for now arch/powerpc/kernel/of_dynamic.c along with everything
> related to dynamically adding and removing nodes. I see that potentially
> useful for more than just DLPAR (though DLPAR is the only user right
> now) and should also all be prefixed with of_*
I agree, there should be at least a powerpc generic implementation of these
routines. The reason I put them here is that I am doing some oddities with
the next, child, and sibling pointers since they point to items not yet in
the device tree.
I saw that Grant Likely is doing updates to all of the of_* stuff right now,
would it be ok to have these routines here, renamed as dlpar_*, and look
to merge them in with Grant's updates when he finishes?
>
>> +#define DR_ENTITY_SENSE 9003
>> +#define DR_ENTITY_PRESENT 1
>> +#define DR_ENTITY_UNUSABLE 2
>> +#define ALLOCATION_STATE 9003
>> +#define ALLOC_UNUSABLE 0
>> +#define ALLOC_USABLE 1
>> +#define ISOLATION_STATE 9001
>> +#define ISOLATE 0
>> +#define UNISOLATE 1
>> +
>> +int acquire_drc(u32 drc_index)
>> +{
>> + int dr_status, rc;
>> +
>> + rc = rtas_call(rtas_token("get-sensor-state"), 2, 2, &dr_status,
>> + DR_ENTITY_SENSE, drc_index);
>> + if (rc || dr_status != DR_ENTITY_UNUSABLE)
>> + return -1;
>> +
>> + rc = rtas_set_indicator(ALLOCATION_STATE, drc_index, ALLOC_USABLE);
>> + if (rc)
>> + return rc;
>> +
>> + rc = rtas_set_indicator(ISOLATION_STATE, drc_index, UNISOLATE);
>> + if (rc) {
>> + rtas_set_indicator(ALLOCATION_STATE, drc_index, ALLOC_UNUSABLE);
>> + return rc;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +int release_drc(u32 drc_index)
>> +{
>> + int dr_status, rc;
>> +
>> + rc = rtas_call(rtas_token("get-sensor-state"), 2, 2, &dr_status,
>> + DR_ENTITY_SENSE, drc_index);
>> + if (rc || dr_status != DR_ENTITY_PRESENT)
>> + return -1;
>> +
>> + rc = rtas_set_indicator(ISOLATION_STATE, drc_index, ISOLATE);
>> + if (rc)
>> + return rc;
>> +
>> + rc = rtas_set_indicator(ALLOCATION_STATE, drc_index, ALLOC_UNUSABLE);
>> + if (rc) {
>> + rtas_set_indicator(ISOLATION_STATE, drc_index, UNISOLATE);
>> + return rc;
>> + }
>> +
>> + return 0;
>> +}
>
> Both above should have a dlpar_* prefix
will do.
>
>> +static int pseries_dlpar_init(void)
>> +{
>> + if (!machine_is(pseries))
>> + return 0;
>> +
>> + return 0;
>> +}
>> +device_initcall(pseries_dlpar_init);
>
> What the point ? :-)
Yeah, its a bit odd looking but later patches actually add code to the init routine
to set up memory probe/release and cpu probe/release handlers.
I'll look to add ifdef's around the initcall for cases where no work is to be done.
-Nathan Fontenot
>
> Cheers
> Ben.
>
^ permalink raw reply
* Re: mpc512x/clock: fix clk_get logic
From: Grant Likely @ 2009-11-02 16:37 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Wolfgang Denk, linuxppc-dev
In-Reply-To: <20091102142232.GD4696@pengutronix.de>
On Mon, Nov 2, 2009 at 7:22 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
>> Sure I don't have major objections against your patch (though who is
>> formally mpc512x maintainer to ack it ?),
>
> Grant is maintainer for MPC5xxx.
Is this patch intended for mainline? I've received so many 5121
patches that only apply against a Denx tree that I'm starting to
ignore them. Until the bulk of the out-of-tree 5121 support is
merged, it would be helpful to specifically mention in the patch
description whether or not it should be merged upstream.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/6 v5] Kernel DLPAR Infrastructure
From: Grant Likely @ 2009-11-02 16:40 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linux-kernel, linuxppc-dev
In-Reply-To: <4AEF086D.9010600@austin.ibm.com>
On Mon, Nov 2, 2009 at 9:27 AM, Nathan Fontenot <nfont@austin.ibm.com> wrote:
> I saw that Grant Likely is doing updates to all of the of_* stuff right now,
> would it be ok to have these routines here, renamed as dlpar_*, and look
> to merge them in with Grant's updates when he finishes?
No because then we're stuck with renaming the API at a later date.
Name it what it is, and put it where it belongs. I'll deal with any
merge breakage as it occurs.
g.
^ permalink raw reply
* Re: [PATCH 1/6 v5] Kernel DLPAR Infrastructure
From: Nathan Fontenot @ 2009-11-02 16:47 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-kernel, linuxppc-dev
In-Reply-To: <fa686aa40911020840s3a6a4819g85f3be3a305820bf@mail.gmail.com>
Grant Likely wrote:
> On Mon, Nov 2, 2009 at 9:27 AM, Nathan Fontenot <nfont@austin.ibm.com> wrote:
>> I saw that Grant Likely is doing updates to all of the of_* stuff right now,
>> would it be ok to have these routines here, renamed as dlpar_*, and look
>> to merge them in with Grant's updates when he finishes?
>
> No because then we're stuck with renaming the API at a later date.
> Name it what it is, and put it where it belongs. I'll deal with any
> merge breakage as it occurs.
>
ok. Would this be better off in powerpc code, or should I go ahead and put it
in something like drivers/of/dynamic.c?
-Nathan Fontenot
^ permalink raw reply
* Re: [PATCH 1/6 v5] Kernel DLPAR Infrastructure
From: Grant Likely @ 2009-11-02 16:56 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linux-kernel, linuxppc-dev
In-Reply-To: <4AEF0D0B.1000100@austin.ibm.com>
On Mon, Nov 2, 2009 at 9:47 AM, Nathan Fontenot <nfont@austin.ibm.com> wrot=
e:
> Grant Likely wrote:
>>
>> On Mon, Nov 2, 2009 at 9:27 AM, Nathan Fontenot <nfont@austin.ibm.com>
>> wrote:
>>>
>>> I saw that Grant Likely is doing updates to all of the of_* stuff right
>>> now,
>>> would it be ok to have these routines here, renamed as dlpar_*, and loo=
k
>>> to merge them in with Grant's updates when he finishes?
>>
>> No because then we're stuck with renaming the API at a later date.
>> Name it what it is, and put it where it belongs. =A0I'll deal with any
>> merge breakage as it occurs.
>>
>
> ok. =A0Would this be better off in powerpc code, or should I go ahead and=
put
> it
> in something like drivers/of/dynamic.c?
drivers/of/dynamic.c sounds fine to me. I can always move them if it
find a better place. Send the patch to me and cc: the
devicetree-discuss@lists.ozlabs.org mailing list.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: mpc512x/clock: fix clk_get logic
From: Wolfram Sang @ 2009-11-02 17:18 UTC (permalink / raw)
To: Grant Likely; +Cc: Wolfgang Denk, linuxppc-dev
In-Reply-To: <fa686aa40911020837g78339e06rf8c1679b2d94c895@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 505 bytes --]
> Is this patch intended for mainline? I've received so many 5121
Yes, my branch is based on linus-git as of today. The CAN driver addition was
just posted to socketcan-devel. It is also independent of the denx-patches[1]
and will later be send to netdev, too.
[1] Of course, the FEC patches are still very handy to bring up a board ;)
--
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: mpc8548 does not make use of DMA when doing memory copy?
From: Kumar Gala @ 2009-11-02 17:32 UTC (permalink / raw)
To: hank peng; +Cc: linuxppc-dev
In-Reply-To: <389deec70911020740k13b56bc6kdad3bfaa39916f54@mail.gmail.com>
On Nov 2, 2009, at 9:40 AM, hank peng wrote:
> Kernel version is 2.6.30 and I have enabled fsl DMA engine during
> configuring kernel. After system booted, I have seen only 38 DMA
> interrupts, and no increase later when I am doing data transfer
> through network.
> So I wonder if mpc8548 had made use of DMA engine when doing memcpy,
> or maybe if there are other things I haven't noticed?
The dma engine code is not normally used for normal memcpy's in the
kernel. There are explicit call sites that have async behavior that
should use it (like the networking code).
- k
^ permalink raw reply
* Re: [PATCH V2] mpc512x/clock: fix clk_get logic
From: Grant Likely @ 2009-11-02 17:48 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, Roel Kluin, Mark Brown, Wolfgang Denk
In-Reply-To: <1256925231-21917-1-git-send-email-w.sang@pengutronix.de>
On Fri, Oct 30, 2009 at 10:53 AM, Wolfram Sang <w.sang@pengutronix.de> wrot=
e:
> + =A0 =A0 =A0 bool id_matched =3D !id;
> + =A0 =A0 =A0 bool dev_matched =3D !dev;
[...]
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_matched =3D true;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (id && strcmp(id, p->name) =3D=3D 0)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 id_matched =3D true;
Using bool/true/false doesn't seem to be a common pattern in the
kernel. Anyone know what the winds of prevailing opinion are
regarding 'bool' in kernel code?
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] mpc512x/clocks: initialize CAN clocks
From: Grant Likely @ 2009-11-02 18:02 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, Chen Hongjun, John Rigby, Wolfgang Denk
In-Reply-To: <1257175056-26093-1-git-send-email-w.sang@pengutronix.de>
Hi Wolfram,
Comments below
On Mon, Nov 2, 2009 at 8:17 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> Signed-off-by: John Rigby <jrigby@freescale.com>
> Signed-off-by: Chen Hongjun <hong-jun.chen@freescale.com>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> Should come after the fix for clk_get to be usable for the upcoming CAN d=
river:
> http://patchwork.ozlabs.org/patch/37342/
>
> =A0arch/powerpc/platforms/512x/clock.c | =A0 74 +++++++++++++++++++++++++=
++++++++++
> =A01 files changed, 74 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/512x/clock.c b/arch/powerpc/platforms=
/512x/clock.c
> index 4168457..2d3a5ef 100644
> --- a/arch/powerpc/platforms/512x/clock.c
> +++ b/arch/powerpc/platforms/512x/clock.c
> @@ -50,6 +50,8 @@ struct clk {
> =A0static LIST_HEAD(clocks);
> =A0static DEFINE_MUTEX(clocks_mutex);
>
> +struct clk mscan_clks[4];
> +
I'd rather not have more globals. If really needed, should at the
very least be static and prefixed with mpc5121_.
> =A0static struct clk *mpc5121_clk_get(struct device *dev, const char *id)
> =A0{
> =A0 =A0 =A0 =A0struct clk *p, *clk =3D ERR_PTR(-ENOENT);
> @@ -119,6 +121,8 @@ struct mpc512x_clockctl {
> =A0 =A0 =A0 =A0u32 spccr; =A0 =A0 =A0 =A0 =A0 =A0 =A0/* SPDIF Clk Ctrl Re=
g */
> =A0 =A0 =A0 =A0u32 cccr; =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* CFM Clk Ctrl Reg =
*/
> =A0 =A0 =A0 =A0u32 dccr; =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* DIU Clk Cnfg Reg =
*/
> + =A0 =A0 =A0 /* rev2+ only regs */
> + =A0 =A0 =A0 u32 mccr[4]; =A0 =A0 =A0 =A0 =A0 =A0/* MSCAN Clk Ctrl Reg 1=
-4 */
> =A0};
>
> =A0struct mpc512x_clockctl __iomem *clockctl;
> @@ -688,6 +692,72 @@ static void psc_clks_init(void)
> =A0 =A0 =A0 =A0}
> =A0}
>
> +
> +/*
> + * mscan clock rate calculation
> + */
> +static unsigned long mscan_calc_rate(struct device_node *np, int mscannu=
m)
> +{
> + =A0 =A0 =A0 unsigned long mscanclk_src, mscanclk_div;
> + =A0 =A0 =A0 u32 *mccr =3D &clockctl->mccr[mscannum];
> +
> + =A0 =A0 =A0 /*
> + =A0 =A0 =A0 =A0* If the divider is the reset default of all 1's then
> + =A0 =A0 =A0 =A0* we know u-boot and/or board setup has not
> + =A0 =A0 =A0 =A0* done anything so set up a sane default
> + =A0 =A0 =A0 =A0*/
> + =A0 =A0 =A0 if (((in_be32(mccr) >> 17) & 0x7fff) =3D=3D 0x7fff) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* disable */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 out_be32(mccr, 0);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* src is sysclk, divider is 4 */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 out_be32(mccr, (0x3 << 17) | 0x10000);
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 switch ((in_be32(mccr) >> 14) & 0x3) {
> + =A0 =A0 =A0 case 0:
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mscanclk_src =3D sys_clk.rate;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> + =A0 =A0 =A0 case 1:
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mscanclk_src =3D ref_clk.rate;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> + =A0 =A0 =A0 case 2:
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mscanclk_src =3D psc_mclk_in.rate;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> + =A0 =A0 =A0 case 3:
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mscanclk_src =3D spdif_txclk.rate;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> + =A0 =A0 =A0 }
Nit: Table lookup perhaps?
> +
> + =A0 =A0 =A0 mscanclk_src =3D roundup(mscanclk_src, 1000000);
> + =A0 =A0 =A0 mscanclk_div =3D ((in_be32(mccr) >> 17) & 0x7fff) + 1;
> + =A0 =A0 =A0 return mscanclk_src / mscanclk_div;
> +}
> +
> +/*
> + * Find all silicon rev2 mscan nodes in device tree and assign a clock
> + * with name "mscan%d_clk" and dev pointing at the device
> + * returned from of_find_device_by_node
> + */
Comment block doesn't really help me understand what the function does.
> +static void mscan_clks_init(void)
> +{
> + =A0 =A0 =A0 struct device_node *np;
> + =A0 =A0 =A0 struct of_device *ofdev;
> + =A0 =A0 =A0 const u32 *cell_index;
> +
> + =A0 =A0 =A0 for_each_compatible_node(np, NULL, "fsl,mpc5121-mscan") {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 cell_index =3D of_get_property(np, "cell-in=
dex", NULL);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (cell_index) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct clk *clk =3D &mscan_=
clks[*cell_index];
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clk->flags =3D CLK_HAS_RATE=
;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ofdev =3D of_find_device_by=
_node(np);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clk->dev =3D &ofdev->dev;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clk->rate =3D mscan_calc_ra=
te(np, *cell_index);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sprintf(clk->name, "mscan%d=
_clk", *cell_index);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clk_register(clk);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> + =A0 =A0 =A0 }
> +}
These clock controllers are 1:1 dedicated to the CAN devices, correct?
Wouldn't it make more sense to put this code directly into the CAN
bus device driver instead of in common code? And allocated the clk
structure at driver probe time? It seems like the only shared bit
seems to be access to the mccr registers.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ 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