* PCI Host Controller Structure Init Linux kernel 2.6
From: Deepak Gaur @ 2007-06-20 11:31 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20070620092822.M62113@cdotd.ernet.in>
Hello all,
I have certain doubts regarding initialization of PCI host controller in a MPC8560 based
custom board. The board has three 32bit PCI devices attached to MPC8560 PCI/X interface
and all of them are on same PCI bus. Moreover all the three devices do not understand
PCI I/O transactions(as per device datasheets). Each device has its own PCI memory range
and and are non-contigous in MPC8560 local memory address map . PCI memory is 1:1 mapped
to Local memory address range of MPC8560.
Consider the linux kernel 2.6 source code . The board specific function
mpc8560custom_setup_arch() defined in "arch/ppc/platforms/85xx/mpc8560_custom.c" is
called during initialization as described below
static void __init
mpc8560custom_setup_arch(void)
{
...
...
...
#ifdef CONFIG_PCI
/* setup PCI host bridges */
mpc85xx_setup_hose();
#endif
...
...
...
...
}
The mpc8560custom_setup_arch(void) then calls mpc85xx_setup_hose() for setting up a PCI
Host Controller for MPC8560 PCI/X interface as described in file
"arch/ppc/syslib/ppc85xx_setup.c"
void __init
mpc85xx_setup_hose(void)
{
struct pci_controller *hose_a;
...
...
bd_t *binfo = (bd_t *) __res;
hose_a = pcibios_alloc_controller();
if (!hose_a)
return;
ppc_md.pci_swizzle = common_swizzle;
ppc_md.pci_map_irq = mpc85xx_map_irq;
hose_a->first_busno = 0;
hose_a->bus_offset = 0;
hose_a->last_busno = 0xff;
setup_indirect_pci(hose_a, binfo->bi_immr_base + PCI1_CFG_ADDR_OFFSET,
binfo->bi_immr_base + PCI1_CFG_DATA_OFFSET);
hose_a->set_cfg_type = 1;
mpc85xx_setup_pci1(hose_a);
hose_a->pci_mem_offset = MPC85XX_PCI1_MEM_OFFSET;
hose_a->mem_space.start = MPC85XX_PCI1_LOWER_MEM;
hose_a->mem_space.end = MPC85XX_PCI1_UPPER_MEM;
hose_a->io_space.start = MPC85XX_PCI1_LOWER_IO;
hose_a->io_space.end = MPC85XX_PCI1_UPPER_IO;
hose_a->io_base_phys = MPC85XX_PCI1_IO_BASE;
#ifdef CONFIG_85xx_PCI2
isa_io_base =
(unsigned long) ioremap(MPC85XX_PCI1_IO_BASE,
MPC85XX_PCI1_IO_SIZE +
MPC85XX_PCI2_IO_SIZE);
#else
isa_io_base =
(unsigned long) ioremap(MPC85XX_PCI1_IO_BASE,
MPC85XX_PCI1_IO_SIZE);
#endif
hose_a->io_base_virt = (void *) isa_io_base;
/* setup resources */
pci_init_resource(&hose_a->mem_resources[0],
MPC85XX_PCI1_LOWER_MEM,
MPC85XX_PCI1_UPPER_MEM,
IORESOURCE_MEM, "PCI1 host bridge");
pci_init_resource(&hose_a->io_resource,
MPC85XX_PCI1_LOWER_IO,
MPC85XX_PCI1_UPPER_IO,
IORESOURCE_IO, "PCI1 host bridge");
ppc_md.pci_exclude_device = mpc85xx_exclude_device;
...
...
...
...
}
The mpc85xx_setup_pci1(hose_a) function set up the outbound and inbound transaltion
windows as described below . I customized the function for supporting 3 PCI devices each
having one outbound and inbound window.
mpc85xx_setup_pci1(hose_a)
{
...
...
...
/* Setup Phys:PCI 1:1 outbound mem window @ MPC85XX_PCI1_DEV1_LOWER_MEM */
pci->potar1 = (MPC85XX_PCI1_DEVICE1_LOWER_MEM >> 12) & 0x000fffff;
pci->potear1 = 0x00000000;
pci->powbar1 = (MPC85XX_PCI1_56900_DEVICE1_MEM >> 12) & 0x000fffff;
/* Enable, Mem R/W */
pci->powar1 = 0x80044000 |
(__ilog2(MPC85XX_PCI1_56900_DEVICE1_MEM - MPC85XX_PCI1_DEVICE1_LOWER_MEM + 1)
- 1);
and
/* Setup Phys:PCI 1:1 inbound mem window @ MPC85XX_PCI1_DEVICE1_LOWER_MEM */
pci->pitar1 = (MPC85XX_PCI1_DEVICE1_LOWER_MEM >> 12) & 0x000fffff;
pci->pitear1 = 0x00000000;
pci->piwbar1 = (MPC85XX_PCI1_DEVICE1_LOWER_MEM >> 12) & 0x000fffff;
pci->piwar1 = 0xa0f5501e; /* Enable, Prefetch, Local
Mem, Snoop R/W, 2G */
...
...
...
}
I have following doubts for customizing this code for my custom board requirements
(1) As none of the devices understand PCI I/O transactions (as per device datasheets)
what need to be filled in hose_a->io_space.start, hose_a->io_space.end
,hose_a->io_base_phys variables in function mpc85xx_setup_hose(void)
(2) As the board has 3 devices with following MPC8560 local memory map locations
DEVICE1 80000000 to 800FFFFF
DEVICE2 90000000 to 900FFFFF
Other non PCI devices
DEVICE3 B0000000 to BFFFFFFF
These memory locations are to be 1:1 memory mapped in PCI address space as
MPC85XX_PCI1_MEM_OFFSET is 00000000. Now my doublt is how to give this information in
following section of code
hose_a->pci_mem_offset = MPC85XX_PCI1_MEM_OFFSET;
hose_a->mem_space.start = MPC85XX_PCI1_LOWER_MEM;
hose_a->mem_space.end = MPC85XX_PCI1_UPPER_MEM;
As hose_a->mem_space.start and hose_a->mem_space.end are single variables how the all
devices info can be given (we need three elements)? Or we need to give this info as
following
/* setup resources */
pci_init_resource(&hose_a->mem_resources[0],
MPC85XX_PCI1_DEV1_LOWER_MEM,
MPC85XX_PCI1_DEV1 UPPER_MEM,
IORESOURCE_MEM, "PCI1 host bridge Device 1");
pci_init_resource(&hose_a->mem_resources[0],
MPC85XX_PCI1_DEV2_LOWER_MEM,
MPC85XX_PCI1_DEV2 UPPER_MEM,
IORESOURCE_MEM, "PCI1 host bridge Device 2");
pci_init_resource(&hose_a->mem_resources[0],
MPC85XX_PCI1_DEV3_LOWER_MEM,
MPC85XX_PCI1_DEV3 UPPER_MEM,
IORESOURCE_MEM, "PCI1 host bridge Device 3");
(3) As no PCI I/O transaction are required with PCI device what needs to be filled in
pci_init_resource(&hose_a->io_resource,
MPC85XX_PCI1_LOWER_IO,
MPC85XX_PCI1_UPPER_IO,
IORESOURCE_IO, "PCI1 host bridge");
hose_a->io_resource?
(4) In case I had 4 or 5 PCI or more devices where and what initialization I would have
done. Am I doing the customization at the right place?
I shall be gratful if anyone can tell be PCI setup required for above board
configuration and help me in understanding PCI init in Linux Kernel 2.6
Thanks in advance,
with warm regards,
Deepak Gaur
------- End of Forwarded Message -------
Deepak Gaur
^ permalink raw reply
* Re: [patch 5/6] ps3: ROM Storage Driver
From: Milton Miller @ 2007-06-20 12:16 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: ppcdev
In-Reply-To: <Pine.LNX.4.62.0706191405190.4069@pademelon.sonytel.be>
On Jun 19, 2007, at 7:29 AM, Geert Uytterhoeven wrote:
> On Mon, 18 Jun 2007, Milton Miller wrote:
>>> +config PS3_ROM
>>> + tristate "PS3 ROM Storage Driver"
>>> + depends on PPC_PS3 && BLK_DEV_SR
>>> + select PS3_STORAGE
>>> + help
>>> + Include support for the PS3 ROM Storage.
>>> +
>>> + This support is required to access the PS3 BD/DVD/CD-ROM drive.
>>> + In general, all users will say Y or M.
>>> +
>>
>> Why does it depend on BLK_DEV_SR?
>
> Because it needs SCSI CD-ROM support.
>
To compile? I don't see any exports there.
My point is if it only relies on it to produce the device node, then
you should provide guidance in your help text but not make the module
build dependent on it.
milton
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-06-20 12:46 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get two more bug fixes for powerpc. Both bugs cause an oops in
some circumstances.
(Please also do the pull that Kumar requested; I haven't pulled in his
commits in this instance.)
Thanks,
Paul.
arch/powerpc/mm/fault.c | 5 ++---
arch/powerpc/platforms/powermac/setup.c | 3 +++
2 files changed, 5 insertions(+), 3 deletions(-)
commit c5f226c7e95bf318879fb6ae02fc0dfb0f6d408c
Author: Tony Breeds <tony@bakeyournoodle.com>
Date: Wed Jun 20 15:17:29 2007 +1000
[POWERPC] Fix powermac late initcall to only run on powermac
Current ppc64_defconfig kernel fails to boot on iSeries, dying with:
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc00000000071b258
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=32 iSeries
<snip>
NIP [c00000000071b258] .iSeries_src_init+0x34/0x64
LR [c000000000701bb4] .kernel_init+0x1fc/0x3bc
Call Trace:
[c000000007d0be30] [0000000000008000] 0x8000 (unreliable)
[c000000007d0bea0] [c000000000701bb4] .kernel_init+0x1fc/0x3bc
[c000000007d0bf90] [c0000000000262d4] .kernel_thread+0x4c/0x68
Instruction dump:
e922cba8 3880ffff 78840420 f8010010 f821ff91 60000000 e8090000 78095fe3
4182002c e922cb58 e862cbb0 e9290140 <e8090000> f8410028 7c0903a6 e9690010
Kernel panic - not syncing: Attempted to kill init!
This happens because some powermac code unconditionally sets
ppc_md.progress to NULL. This patch makes sure the powermac late
initcall is only run on powermac machines.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 9ba4ace39fdfe22268daca9f28c5df384ae462cf
Author: Segher Boessenkool <segher@kernel.crashing.org>
Date: Wed Jun 20 01:07:04 2007 +1000
[POWERPC] PowerPC: Prevent data exception in kernel space (32-bit)
The "is_exec" branch of the protection check in do_page_fault()
didn't do anything on 32-bit PowerPC. So if a userland program
jumps to a page with Linux protection flags "---p", all the tests
happily fall through, and handle_mm_fault() is called, which in
turn calls handle_pte_fault(), which calls update_mmu_cache(),
which goes flush the dcache to a page with no access rights.
Boom.
This fixes it.
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* OPB vs. PLB DDR Memory Controller
From: Thomas Glanzmann @ 2007-06-20 13:45 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I used secretlabs kernel tree and build my hardware once with the obp
uart and once with the uart lite and compiled in the coresponding
drivers into the linux kernel.
loaded at: 00400000 004951A0
board data at: 00000000 0000007C
relocated to: 0040402C 004040A8
zimage at: 00404EE5 00492F1A
avail ram: 00496000 7C9E2378
Linux/PPC load: root=/dev/nfs rw ip=on
Uncompressing Linux...done.
Now booting the kernel
As you can see the embedded boot loader works, but the kernel does not
produce any output. I wonder if I have to configure Linux that it has a
OPB Memory Controller instead of a PLB Memory Controller. I used the
ml403 Option in my kernel config.
Thomas
^ permalink raw reply
* Re: [RFC] clocksouce implementation for powerpc
From: Daniel Walker @ 2007-06-20 14:57 UTC (permalink / raw)
To: Tony Breeds
Cc: Andrew Morton, john stultz, LKML, LinuxPPC-dev, Thomas Gleixner,
Ingo Molnar
In-Reply-To: <20070620065710.GR9768@bakeyournoodle.com>
On Wed, 2007-06-20 at 16:57 +1000, Tony Breeds wrote:
> On Sat, Jun 16, 2007 at 08:51:23AM -0700, Daniel Walker wrote:
> > On Sat, 2007-06-16 at 10:36 +0000, Thomas Gleixner wrote:
> > > plain text document attachment
> > > (clocksource-add-settimeofday-hook.patch)
> > > From: Tony Breeds <tony@bakeyournoodle.com >
> > >
> > > I'm working on a clocksource implementation for all powerpc platforms.
> > > some of these platforms needs to do a little work as part of the
> > > settimeofday() syscall and I can't see a way to do that without adding
> > > this hook to clocksource.
> > >
> >
> >
> > I'd like to see how this is used? If the code that uses this API change
> > isn't ready yet, then this patch should really wait..
>
> This is my current patch to rework arch/powerpc/kernel/time.c to create
> a clocksource. It's not ready for inclusion.
>
> powerpc needs to keep the vdso in sync whenener settimeodfay() is
> called. Adding the hook the to the clocksource structure was my way of
> allowing this to happen. There are other approaches, but this seemed to
> best allow for runtime. Initially I considered using update_vsyscall()
> but this is called from do_timer(), and I don't need this code run then
> :(
As I said in our private thread, I do think you should be using
update_vsyscall() .. update_vsyscall() is just called when the time is
set, usually that happens in the timer interrupt and sometimes that
happens in settimeofday() ..
> This has been booted on pSeries and iSeries (I'm using glibc 2.5, which
> uses the vdso gettimeoday())
>
> All comments appreiated.
At least some of your code is duplications over what is already being
worked on inside the powerpc community.. For instance, I know there is
already a timebase clocksource,
http://people.redhat.com/~mingo/realtime-preempt/patch-2.6.21.5-rt17
> Index: working/arch/powerpc/Kconfig
> ===================================================================
> --- working.orig/arch/powerpc/Kconfig
> +++ working/arch/powerpc/Kconfig
> @@ -31,6 +31,12 @@ config MMU
> bool
> default y
>
> +config GENERIC_TIME
> + def_bool y
> +
> +config GENERIC_TIME_VSYSCALL
> + def_bool y
> +
> config GENERIC_HARDIRQS
> bool
> default y
> Index: working/arch/powerpc/kernel/time.c
> ===================================================================
> --- working.orig/arch/powerpc/kernel/time.c
> +++ working/arch/powerpc/kernel/time.c
> @@ -74,6 +74,30 @@
> #endif
> #include <asm/smp.h>
>
> +/* powerpc clocksource/clockevent code */
> +
> +/* TODO:
> + * o Code style
> + * * Variable names ... be consistent.
> + *
> + * TODO: Clocksource
> + * o Need a _USE_RTC() clocksource impelementation
> + * o xtime: Either time.c manages it, or clocksource does, not both
> + */
> +
> +#include <linux/clocksource.h>
> +
> +static struct clocksource clocksource_timebase = {
> + .name = "timebase",
> + .rating = 200,
> + .flags = CLOCK_SOURCE_IS_CONTINUOUS,
> + .mask = CLOCKSOURCE_MASK(64),
> + .shift = 22,
> + .mult = 0, /* To be filled in */
> + .read = NULL, /* To be filled in */
> + .settimeofday = NULL, /* To be filled in */
> +};
> +
> /* keep track of when we need to update the rtc */
> time_t last_rtc_update;
> #ifdef CONFIG_PPC_ISERIES
> @@ -376,65 +400,6 @@ static __inline__ void timer_check_rtc(v
> }
> }
>
> -/*
> - * This version of gettimeofday has microsecond resolution.
> - */
> -static inline void __do_gettimeofday(struct timeval *tv)
> -{
> - unsigned long sec, usec;
> - u64 tb_ticks, xsec;
> - struct gettimeofday_vars *temp_varp;
> - u64 temp_tb_to_xs, temp_stamp_xsec;
> -
> - /*
> - * These calculations are faster (gets rid of divides)
> - * if done in units of 1/2^20 rather than microseconds.
> - * The conversion to microseconds at the end is done
> - * without a divide (and in fact, without a multiply)
> - */
> - temp_varp = do_gtod.varp;
> -
> - /* Sampling the time base must be done after loading
> - * do_gtod.varp in order to avoid racing with update_gtod.
> - */
> - data_barrier(temp_varp);
> - tb_ticks = get_tb() - temp_varp->tb_orig_stamp;
> - temp_tb_to_xs = temp_varp->tb_to_xs;
> - temp_stamp_xsec = temp_varp->stamp_xsec;
> - xsec = temp_stamp_xsec + mulhdu(tb_ticks, temp_tb_to_xs);
> - sec = xsec / XSEC_PER_SEC;
> - usec = (unsigned long)xsec & (XSEC_PER_SEC - 1);
> - usec = SCALE_XSEC(usec, 1000000);
> -
> - tv->tv_sec = sec;
> - tv->tv_usec = usec;
> -}
> -
> -void do_gettimeofday(struct timeval *tv)
> -{
> - if (__USE_RTC()) {
> - /* do this the old way */
> - unsigned long flags, seq;
> - unsigned int sec, nsec, usec;
> -
> - do {
> - seq = read_seqbegin_irqsave(&xtime_lock, flags);
> - sec = xtime.tv_sec;
> - nsec = xtime.tv_nsec + tb_ticks_since(tb_last_jiffy);
> - } while (read_seqretry_irqrestore(&xtime_lock, seq, flags));
> - usec = nsec / 1000;
> - while (usec >= 1000000) {
> - usec -= 1000000;
> - ++sec;
> - }
> - tv->tv_sec = sec;
> - tv->tv_usec = usec;
> - return;
> - }
> - __do_gettimeofday(tv);
> -}
> -
> -EXPORT_SYMBOL(do_gettimeofday);
>
> /*
> * There are two copies of tb_to_xs and stamp_xsec so that no
> @@ -666,8 +631,8 @@ void timer_interrupt(struct pt_regs * re
> if (per_cpu(last_jiffy, cpu) >= tb_next_jiffy) {
> tb_last_jiffy = tb_next_jiffy;
> do_timer(1);
> - timer_recalc_offset(tb_last_jiffy);
> - timer_check_rtc();
> + /* timer_recalc_offset() && timer_check_rtc()
> + * are now called from update_vsyscall() */
> }
> write_sequnlock(&xtime_lock);
> }
> @@ -739,77 +704,6 @@ unsigned long long sched_clock(void)
> return mulhdu(get_tb() - boot_tb, tb_to_ns_scale) << tb_to_ns_shift;
> }
>
> -int do_settimeofday(struct timespec *tv)
> -{
> - time_t wtm_sec, new_sec = tv->tv_sec;
> - long wtm_nsec, new_nsec = tv->tv_nsec;
> - unsigned long flags;
> - u64 new_xsec;
> - unsigned long tb_delta;
> -
> - if ((unsigned long)tv->tv_nsec >= NSEC_PER_SEC)
> - return -EINVAL;
> -
> - write_seqlock_irqsave(&xtime_lock, flags);
> -
> - /*
> - * Updating the RTC is not the job of this code. If the time is
> - * stepped under NTP, the RTC will be updated after STA_UNSYNC
> - * is cleared. Tools like clock/hwclock either copy the RTC
> - * to the system time, in which case there is no point in writing
> - * to the RTC again, or write to the RTC but then they don't call
> - * settimeofday to perform this operation.
> - */
> -#ifdef CONFIG_PPC_ISERIES
> - if (firmware_has_feature(FW_FEATURE_ISERIES) && first_settimeofday) {
> - iSeries_tb_recal();
> - first_settimeofday = 0;
> - }
> -#endif
> -
> - /* Make userspace gettimeofday spin until we're done. */
> - ++vdso_data->tb_update_count;
> - smp_mb();
> -
> - /*
> - * Subtract off the number of nanoseconds since the
> - * beginning of the last tick.
> - */
> - tb_delta = tb_ticks_since(tb_last_jiffy);
> - tb_delta = mulhdu(tb_delta, do_gtod.varp->tb_to_xs); /* in xsec */
> - new_nsec -= SCALE_XSEC(tb_delta, 1000000000);
> -
> - wtm_sec = wall_to_monotonic.tv_sec + (xtime.tv_sec - new_sec);
> - wtm_nsec = wall_to_monotonic.tv_nsec + (xtime.tv_nsec - new_nsec);
> -
> - set_normalized_timespec(&xtime, new_sec, new_nsec);
> - set_normalized_timespec(&wall_to_monotonic, wtm_sec, wtm_nsec);
> -
> - /* In case of a large backwards jump in time with NTP, we want the
> - * clock to be updated as soon as the PLL is again in lock.
> - */
> - last_rtc_update = new_sec - 658;
> -
> - ntp_clear();
> -
> - new_xsec = xtime.tv_nsec;
> - if (new_xsec != 0) {
> - new_xsec *= XSEC_PER_SEC;
> - do_div(new_xsec, NSEC_PER_SEC);
> - }
> - new_xsec += (u64)xtime.tv_sec * XSEC_PER_SEC;
> - update_gtod(tb_last_jiffy, new_xsec, do_gtod.varp->tb_to_xs);
> -
> - vdso_data->tz_minuteswest = sys_tz.tz_minuteswest;
> - vdso_data->tz_dsttime = sys_tz.tz_dsttime;
> -
> - write_sequnlock_irqrestore(&xtime_lock, flags);
> - clock_was_set();
> - return 0;
> -}
> -
> -EXPORT_SYMBOL(do_settimeofday);
> -
> static int __init get_freq(char *name, int cells, unsigned long *val)
> {
> struct device_node *cpu;
> @@ -878,6 +772,78 @@ unsigned long get_boot_time(void)
> tm.tm_hour, tm.tm_min, tm.tm_sec);
> }
>
> +/* clocksource code */
> +static cycle_t timebase_read(void)
> +{
> + return (cycle_t)get_tb();
> +}
> +
> +static void clocksource_settimeofday(struct clocksource *cs,
> + struct timespec *ts)
> +{
> + u64 new_xsec;
> +
> +#ifdef CONFIG_PPC_ISERIES
> + if (firmware_has_feature(FW_FEATURE_ISERIES) && first_settimeofday) {
> + iSeries_tb_recal();
> + first_settimeofday = 0;
> + }
> +#endif
> +
> + /* Make userspace gettimeofday spin until we're done. */
> + ++vdso_data->tb_update_count;
> + smp_mb();
> +
> + /* In case of a large backwards jump in time with NTP, we want the
> + * clock to be updated as soon as the PLL is again in lock.
> + */
> + last_rtc_update = xtime.tv_sec - 658;
> +
> + new_xsec = xtime.tv_nsec;
> + if (new_xsec != 0) {
> + new_xsec *= XSEC_PER_SEC;
> + do_div(new_xsec, NSEC_PER_SEC);
> + }
> +
> + new_xsec += (u64)xtime.tv_sec * XSEC_PER_SEC;
> +
> + vdso_data->tz_minuteswest = sys_tz.tz_minuteswest;
> + vdso_data->tz_dsttime = sys_tz.tz_dsttime;
> +
> + update_gtod(tb_last_jiffy, new_xsec, do_gtod.varp->tb_to_xs);
> +}
It does look too large to run from interrupt context, but it also looks
like it could get cleaned out more ..
> +void update_vsyscall(struct timespec *wall_time, struct clocksource *clock)
> +{
> + timer_recalc_offset(tb_last_jiffy);
> + timer_check_rtc();
> +}
Hmm .. This doesn't look like it's taking into account that the time has
changed .. Your time has effectively incremented by one jiffie .. The
vdso_data doesn't appear to be updated ..
> +void __init clocksource_init(void)
> +{
> + int mult;
> +
> + if (__USE_RTC())
> + return;
> +
> + mult = clocksource_hz2mult(tb_ticks_per_sec,
> + clocksource_timebase.shift);
> + clocksource_timebase.mult = mult;
> +
> + clocksource_timebase.read = timebase_read;
> + clocksource_timebase.settimeofday = clocksource_settimeofday;
> +
> + if (clocksource_register(&clocksource_timebase)) {
> + printk(KERN_ERR "clocksource: %s is already registered\n",
> + clocksource_timebase.name);
> + return;
> + }
> +
> + printk(KERN_INFO "clocksource: %s mult[%x] shift[%d] registered\n",
> + clocksource_timebase.name,
> + clocksource_timebase.mult, clocksource_timebase.shift);
> +}
> +
> /* This function is only called on the boot processor */
> void __init time_init(void)
> {
> @@ -999,6 +965,9 @@ void __init time_init(void)
> -xtime.tv_sec, -xtime.tv_nsec);
> write_sequnlock_irqrestore(&xtime_lock, flags);
>
> + /* Register the clocksource */
> + clocksource_init();
> +
> /* Not exact, but the timer interrupt takes care of this */
> set_dec(tb_ticks_per_jiffy);
> }
> Yours Tony
>
> linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
> Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
>
^ permalink raw reply
* Re: [PATCH] Fix I8042 IRQs on MPC8641 HPCN
From: Sergei Shtylyov @ 2007-06-20 16:04 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus
In-Reply-To: <567a30ea184b6efc37e4c5df60fea1ac@kernel.crashing.org>
Segher Boessenkool wrote:
>> * IRQ 9: Level
>> * IRQ 10: Level
>> * IRQ 11: Level
>>- * IRQ 12: Level
>>+ * IRQ 12: Edge
>> * IRQ 14: Edge
>> * IRQ 15: Edge
>> */
>>- outb(0xfa, 0x4d0);
>>- outb(0x1e, 0x4d1);
>>+ outb(0xf8, 0x4d0);
>>+ outb(0x0e, 0x4d1);
>
>
> The comment doesn't mention IRQ13. You're changing IRQ9
> to edge as well; is this an accident?
Whare -- I'm only seeing bit 1 changing which corresponds to IRQ1 and is
reserved (0) anyway.
> If not, you need
> to change the comment too.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] Fix I8042 IRQs on MPC8641 HPCN
From: Segher Boessenkool @ 2007-06-20 16:07 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, paulus
In-Reply-To: <46795026.8040502@ru.mvista.com>
>>> * IRQ 9: Level
>>> * IRQ 10: Level
>>> * IRQ 11: Level
>>> - * IRQ 12: Level
>>> + * IRQ 12: Edge
>>> * IRQ 14: Edge
>>> * IRQ 15: Edge
>>> */
>>> - outb(0xfa, 0x4d0);
>>> - outb(0x1e, 0x4d1);
>>> + outb(0xf8, 0x4d0);
>>> + outb(0x0e, 0x4d1);
>> The comment doesn't mention IRQ13. You're changing IRQ9
>> to edge as well; is this an accident?
>
> Whare -- I'm only seeing bit 1 changing which corresponds to IRQ1
> and is reserved (0) anyway.
Uh yeah, bit 1, it's hard to count these single-byte quantities :-)
>> If not, you need to change the comment too.
Segher
^ permalink raw reply
* Re: [PATCH] Fix I8042 IRQs on MPC8641 HPCN
From: Wade Farnsworth @ 2007-06-20 16:16 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus
In-Reply-To: <000737fbc16c8d25bb3ebcdc9bbd9eab@kernel.crashing.org>
On Wed, 2007-06-20 at 18:07 +0200, Segher Boessenkool wrote:
> >>> * IRQ 9: Level
> >>> * IRQ 10: Level
> >>> * IRQ 11: Level
> >>> - * IRQ 12: Level
> >>> + * IRQ 12: Edge
> >>> * IRQ 14: Edge
> >>> * IRQ 15: Edge
> >>> */
> >>> - outb(0xfa, 0x4d0);
> >>> - outb(0x1e, 0x4d1);
> >>> + outb(0xf8, 0x4d0);
> >>> + outb(0x0e, 0x4d1);
> >> The comment doesn't mention IRQ13. You're changing IRQ9
> >> to edge as well; is this an accident?
> >
> > Whare -- I'm only seeing bit 1 changing which corresponds to IRQ1
> > and is reserved (0) anyway.
>
> Uh yeah, bit 1, it's hard to count these single-byte quantities :-)
Yep, only IRQ's 1 and 12 should be changed here.
>
> >> If not, you need to change the comment too.
>
I'm not the original author of the comment, but I think it's only
mentioning the IRQ's whose triggering is being modified here. The
omitted IRQ's already had the correct triggering.
In any case, I can clarify the comment to make it more clear.
--Wade
^ permalink raw reply
* Re: [PATCH v2] Create add_rtc() function to enable the RTC CMOS driver
From: Wade Farnsworth @ 2007-06-20 16:21 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus
In-Reply-To: <c5941587e5e4cb07efbc86845c9a15a4@kernel.crashing.org>
On Wed, 2007-06-20 at 12:06 +0200, Segher Boessenkool wrote:
> > This creates a function to register the platform device based on the
> > RTC
> > device node and verifies that the RTC port against the hard-coded value
> > in asm/mc146818rtc.h. It also sets the RTC to 24-hr mode as 12-hr mode
> > is not currently supported by the driver.
>
> The 24h thing should be set in the driver itself. Does the
> driver handle binary vs. decimal mode btw? If not, you'll
> want to do the analogue thing for that.
>
OK, I'll look into putting the 24h fix into the driver.
It looks like binary mode is also not supported, so I'll add a fix for
that as well.
Thanks,
--Wade
^ permalink raw reply
* Re: [PATCH] Fix I8042 IRQs on MPC8641 HPCN
From: Wade Farnsworth @ 2007-06-20 16:22 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus
In-Reply-To: <1182356216.5674.370.camel@rhino>
On Wed, 2007-06-20 at 09:16 -0700, Wade Farnsworth wrote:
>
> In any case, I can clarify the comment to make it more clear.
Heh, department of redundancy department. :)
>
> --Wade
^ permalink raw reply
* Re: [PATCH] Fix I8042 IRQs on MPC8641 HPCN
From: Segher Boessenkool @ 2007-06-20 16:27 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: linuxppc-dev, paulus
In-Reply-To: <1182356216.5674.370.camel@rhino>
>> Uh yeah, bit 1, it's hard to count these single-byte quantities :-)
>
> Yep, only IRQ's 1 and 12 should be changed here.
>
>>>> If not, you need to change the comment too.
>
> I'm not the original author of the comment, but I think it's only
> mentioning the IRQ's whose triggering is being modified here. The
> omitted IRQ's already had the correct triggering.
Yeah.
> In any case, I can clarify the comment to make it more clear.
The commit message already mentioned IRQ 1, all is fine :-)
Segher
^ permalink raw reply
* Re: [RFC] clocksouce implementation for powerpc
From: Sergei Shtylyov @ 2007-06-20 16:53 UTC (permalink / raw)
To: Tony Breeds
Cc: Andrew Morton, Daniel Walker, john stultz, LKML, LinuxPPC-dev,
Thomas Gleixner, Ingo Molnar
In-Reply-To: <20070620065710.GR9768@bakeyournoodle.com>
Hello.
Tony Breeds wrote:
>>>plain text document attachment
>>>(clocksource-add-settimeofday-hook.patch)
>>>From: Tony Breeds <tony@bakeyournoodle.com >
>>>I'm working on a clocksource implementation for all powerpc platforms.
>>>some of these platforms needs to do a little work as part of the
>>>settimeofday() syscall and I can't see a way to do that without adding
>>>this hook to clocksource.
>>I'd like to see how this is used? If the code that uses this API change
>>isn't ready yet, then this patch should really wait..
> This is my current patch to rework arch/powerpc/kernel/time.c to create
> a clocksource. It's not ready for inclusion.
I guess it's been based on the prior work by John Stultz (and me too :-)?
> powerpc needs to keep the vdso in sync whenener settimeodfay() is
> called. Adding the hook the to the clocksource structure was my way of
> allowing this to happen. There are other approaches, but this seemed to
> best allow for runtime. Initially I considered using update_vsyscall()
> but this is called from do_timer(), and I don't need this code run then
> :(
> This has been booted on pSeries and iSeries (I'm using glibc 2.5, which
> uses the vdso gettimeoday())
[...]
> Index: working/arch/powerpc/kernel/time.c
> ===================================================================
> --- working.orig/arch/powerpc/kernel/time.c
> +++ working/arch/powerpc/kernel/time.c
> @@ -74,6 +74,30 @@
> #endif
> #include <asm/smp.h>
>
> +/* powerpc clocksource/clockevent code */
> +
> +/* TODO:
> + * o Code style
> + * * Variable names ... be consistent.
> + *
> + * TODO: Clocksource
> + * o Need a _USE_RTC() clocksource impelementation
> + * o xtime: Either time.c manages it, or clocksource does, not both
If you mean the init. part, this has been already done by me -- I've
implemented read_persistent_clock() and got rid of xtime setting. What's left
is to implemet update_persistent_clock() and get rid of timer_check_rtc()...
> + */
> +
> +#include <linux/clocksource.h>
> +
> +static struct clocksource clocksource_timebase = {
> + .name = "timebase",
> + .rating = 200,
Perhaps we even need to raise the rating to 300 or 400 -- according to
what <linux/clocksource.h> says?
> + .flags = CLOCK_SOURCE_IS_CONTINUOUS,
> + .mask = CLOCKSOURCE_MASK(64),
> + .shift = 22,
PPC64 has issues with the fixed shift value, see:
http://patchwork.ozlabs.org/linuxppc/patch?id=11125
> + .mult = 0, /* To be filled in */
> + .read = NULL, /* To be filled in */
> + .settimeofday = NULL, /* To be filled in */
I don't quite understand why not just init them right away? The values
are fixed anyways.
> +};
> +
> /* keep track of when we need to update the rtc */
> time_t last_rtc_update;
> #ifdef CONFIG_PPC_ISERIES
[...]
> @@ -666,8 +631,8 @@ void timer_interrupt(struct pt_regs * re
> if (per_cpu(last_jiffy, cpu) >= tb_next_jiffy) {
> tb_last_jiffy = tb_next_jiffy;
> do_timer(1);
> - timer_recalc_offset(tb_last_jiffy);
> - timer_check_rtc();
> + /* timer_recalc_offset() && timer_check_rtc()
> + * are now called from update_vsyscall() */
I.e. in the softirq context...
[...]
WBR, Sergei
^ permalink raw reply
* [PATCH v3] Create add_rtc() function to enable the RTC CMOS driver
From: Wade Farnsworth @ 2007-06-20 16:59 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <1182298510.5674.358.camel@rhino>
In order to use the RTC CMOS driver, each architecture must register a
platform device for the RTC.
This creates a function to register the platform device based on the RTC
device node and verifies that the RTC port against the hard-coded value
in asm/mc146818rtc.h.
Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
---
arch/powerpc/sysdev/Makefile | 1
arch/powerpc/sysdev/rtc_cmos_setup.c | 51 +++++++++++++++++++++++++
2 files changed, 52 insertions(+)
Index: linux-2.6-powerpc-8641/arch/powerpc/sysdev/Makefile
===================================================================
--- linux-2.6-powerpc-8641.orig/arch/powerpc/sysdev/Makefile
+++ linux-2.6-powerpc-8641/arch/powerpc/sysdev/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pc
obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
mv64x60-$(CONFIG_PCI) += mv64x60_pci.o
obj-$(CONFIG_MV64X60) += $(mv64x60-y) mv64x60_pic.o mv64x60_dev.o
+obj-$(CONFIG_RTC_DRV_CMOS) += rtc_cmos_setup.o
# contains only the suspend handler for time
obj-$(CONFIG_PM) += timer.o
Index: linux-2.6-powerpc-8641/arch/powerpc/sysdev/rtc_cmos_setup.c
===================================================================
--- /dev/null
+++ linux-2.6-powerpc-8641/arch/powerpc/sysdev/rtc_cmos_setup.c
@@ -0,0 +1,51 @@
+/*
+ * Setup code for PC-style Real-Time Clock.
+ *
+ * Author: Wade Farnsworth <wfarnsworth@mvista.com>
+ *
+ * 2007 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether
express
+ * or implied.
+ */
+
+#include <linux/platform_device.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/mc146818rtc.h>
+
+#include <asm/prom.h>
+
+static int __init add_rtc(void)
+{
+ struct device_node *np;
+ struct platform_device *pd;
+ struct resource res;
+
+ np = of_find_compatible_node(NULL, NULL, "pnpPNP,b00");
+ if (!np)
+ return -ENODEV;
+
+ if (of_address_to_resource(np, 0, &res)) {
+ of_node_put(np);
+ return -ENODEV;
+ }
+
+ /*
+ * RTC_PORT(x) is hardcoded in asm/mc146818rtc.h. Verify that the
+ * address provided by the device node matches.
+ */
+ if (res.start != RTC_PORT(0)) {
+ of_node_put(np);
+ return -ENODEV;
+ }
+
+ pd = platform_device_register_simple("rtc_cmos", -1,
+ &res, 1);
+ of_node_put(np);
+ if (IS_ERR(pd))
+ return PTR_ERR(pd);
+
+ return 0;
+}
+fs_initcall(add_rtc);
^ permalink raw reply
* Re: [RFC] clocksouce implementation for powerpc
From: Sergei Shtylyov @ 2007-06-20 17:20 UTC (permalink / raw)
To: Tony Breeds
Cc: Andrew Morton, Daniel Walker, john stultz, LKML, LinuxPPC-dev,
Thomas Gleixner, Ingo Molnar
In-Reply-To: <1182351439.18168.79.camel@imap.mvista.com>
Daniel Walker wrote:
>>+static void clocksource_settimeofday(struct clocksource *cs,
>>+ struct timespec *ts)
>>+{
>>+ u64 new_xsec;
>>+
>>+#ifdef CONFIG_PPC_ISERIES
>>+ if (firmware_has_feature(FW_FEATURE_ISERIES) && first_settimeofday) {
>>+ iSeries_tb_recal();
>>+ first_settimeofday = 0;
>>+ }
>>+#endif
>>+
>>+ /* Make userspace gettimeofday spin until we're done. */
>>+ ++vdso_data->tb_update_count;
>>+ smp_mb();
>>+
>>+ /* In case of a large backwards jump in time with NTP, we want the
>>+ * clock to be updated as soon as the PLL is again in lock.
>>+ */
>>+ last_rtc_update = xtime.tv_sec - 658;
>>+
>>+ new_xsec = xtime.tv_nsec;
>>+ if (new_xsec != 0) {
>>+ new_xsec *= XSEC_PER_SEC;
>>+ do_div(new_xsec, NSEC_PER_SEC);
>>+ }
>>+
>>+ new_xsec += (u64)xtime.tv_sec * XSEC_PER_SEC;
>>+
>>+ vdso_data->tz_minuteswest = sys_tz.tz_minuteswest;
>>+ vdso_data->tz_dsttime = sys_tz.tz_dsttime;
I'm not sure why these are copied *only* here. Shouldn't they be copied
only once, at init. time?
>>+
>>+ update_gtod(tb_last_jiffy, new_xsec, do_gtod.varp->tb_to_xs);
>>+}
> It does look too large to run from interrupt context,
You mean if this would have been "included" into update_vsyscall()?
> but it also looks
> like it could get cleaned out more ..
Yeah, at least new_xsec calculation is duplicated in timer_recalc_offset()..
>>+void update_vsyscall(struct timespec *wall_time, struct clocksource *clock)
>>+{
>>+ timer_recalc_offset(tb_last_jiffy);
>>+ timer_check_rtc();
>>+}
> Hmm .. This doesn't look like it's taking into account that the time has
> changed ..
Why? By the time it gets called (form the timer softirq context)
tb_last_jiffy should've been incremented. Well, this won't happen wither in or
right after the timer interrupt... since timer has no IRQ on PowerPC -- it
signals "exception". Well, HRT works somehow anyway. :-)
> Your time has effectively incremented by one jiffie .. The
> vdso_data doesn't appear to be updated ..
Moreover, it will get called for settimeofday() as well which would seem
to double the overhead since your clocksource hook will get called beforehand.
WBR, Sergei
^ permalink raw reply
* Re: [RFC] clocksouce implementation for powerpc
From: Thomas Gleixner @ 2007-06-20 17:31 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Andrew Morton, Daniel Walker, john stultz, LKML, LinuxPPC-dev,
Ingo Molnar
In-Reply-To: <467961F1.1060909@ru.mvista.com>
On Wed, 2007-06-20 at 21:20 +0400, Sergei Shtylyov wrote:
> >>+void update_vsyscall(struct timespec *wall_time, struct clocksource *clock)
> >>+{
> >>+ timer_recalc_offset(tb_last_jiffy);
> >>+ timer_check_rtc();
> >>+}
>
> > Hmm .. This doesn't look like it's taking into account that the time has
> > changed ..
>
> Why? By the time it gets called (form the timer softirq context)
It is called from interrupt context at least in mainline. Only the -rt
patch moves this to the softirq.
tglx
^ permalink raw reply
* Re: [PATCH v3] Create add_rtc() function to enable the RTC CMOS driver
From: Segher Boessenkool @ 2007-06-20 17:46 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: linuxppc-dev, paulus
In-Reply-To: <1182358772.5674.383.camel@rhino>
> + /*
> + * RTC_PORT(x) is hardcoded in asm/mc146818rtc.h. Verify that the
> + * address provided by the device node matches.
> + */
> + if (res.start != RTC_PORT(0)) {
> + of_node_put(np);
> + return -ENODEV;
> + }
You can place the of_node_put() here and remove the
previous one, and the following one.
> + pd = platform_device_register_simple("rtc_cmos", -1,
> + &res, 1);
> + of_node_put(np);
Code looks fine, with or without that change.
Segher
^ permalink raw reply
* Re: [RFC] clocksouce implementation for powerpc
From: Sergei Shtylyov @ 2007-06-20 18:11 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Andrew Morton, Daniel Walker, john stultz, LKML, LinuxPPC-dev,
Ingo Molnar
In-Reply-To: <1182360681.3316.25.camel@chaos>
Hello.
Thomas Gleixner wrote:
>>>>+void update_vsyscall(struct timespec *wall_time, struct clocksource *clock)
>>>>+{
>>>>+ timer_recalc_offset(tb_last_jiffy);
>>>>+ timer_check_rtc();
>>>>+}
>>
>>>Hmm .. This doesn't look like it's taking into account that the time has
>>>changed ..
>>
>> Why? By the time it gets called (form the timer softirq context)
>
>
> It is called from interrupt context at least in mainline. Only the -rt
> patch moves this to the softirq.
Anyway, by the time it gets called, tb_last_jiffy gets updated.
> tglx
WBR, Sergei
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 4/5] cell: saving spus information for kexec crash
From: André Detsch @ 2007-06-20 18:52 UTC (permalink / raw)
To: michael
Cc: Arnd Bergmann, Arnd Bergmann, Luke Browning, linuxppc-dev list,
Lucio Jose Herculano Correia, cbe-oss-dev
In-Reply-To: <1182211119.23887.3.camel@concordia.ozlabs.ibm.com>
Michael Ellerman wrote:
> On Tue, 2007-06-19 at 00:42 +0200, Arnd Bergmann wrote:
>> plain text document attachment (cell-spus-info-kexec-crash-1.diff)
>> From: Andre Detsch <adetsch@br.ibm.com>
>> This patch adds support for investigating spus information after a
>> kernel crash event, through kdump vmcore file.
>> Implementation is based on xmon code, but the new functionality was
>> kept independent from xmon.
>>
>> Signed-off-by: Lucio Jose Herculano Correia <luciojhc@br.ibm.com>
>> Signed-off-by: Andre Detsch <adetsch@br.ibm.com>
>> Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
>
>
> I'd like to have this patch share the emergency stopping logic with the
> xmon code, I'll try and get a patch done in the next few days.
>
Hi Michael,
What aspect of the patch do you think would benefit from sharing logic
with xmon? The structures (struct crash_spu + crash_register_spus
function) or the stop spus logic itself (crash_kexec_stop_spus)? Or both?
My first approach was actually to use the same structure and code as
xmon (as you might remember from an private email I've sent before
posting the patch). However, talking with Luke, we decided to keep xmon
and crash data independent from each other, since he was interested on
eventually allowing xmon to be run before the second kernel gets loaded.
So, having a separate structure for crash info would allow us to save
the exact state when the crash occurred, no matter of what the user did
while running xmon.
Best regards,
--
Andre Detsch
^ permalink raw reply
* Re: [RFC] clocksouce implementation for powerpc
From: john stultz @ 2007-06-20 21:06 UTC (permalink / raw)
To: Tony Breeds
Cc: Andrew Morton, Daniel Walker, LKML, LinuxPPC-dev, Thomas Gleixner,
Ingo Molnar
In-Reply-To: <20070620065710.GR9768@bakeyournoodle.com>
On Wed, 2007-06-20 at 16:57 +1000, Tony Breeds wrote:
> On Sat, Jun 16, 2007 at 08:51:23AM -0700, Daniel Walker wrote:
> > On Sat, 2007-06-16 at 10:36 +0000, Thomas Gleixner wrote:
> > > plain text document attachment
> > > (clocksource-add-settimeofday-hook.patch)
> > > From: Tony Breeds <tony@bakeyournoodle.com >
> > >
> > > I'm working on a clocksource implementation for all powerpc platforms.
> > > some of these platforms needs to do a little work as part of the
> > > settimeofday() syscall and I can't see a way to do that without adding
> > > this hook to clocksource.
> > >
> >
> >
> > I'd like to see how this is used? If the code that uses this API change
> > isn't ready yet, then this patch should really wait..
>
> This is my current patch to rework arch/powerpc/kernel/time.c to create
> a clocksource. It's not ready for inclusion.
Hey Tony,
Thanks for sending this out! I really appreciate this work, as its been
on my todo forever, and I've just not been able to focus on it.
Currently it seems a bit minimal of a conversion (ideally there should
be very little time code left), but It looks like a great start!
More comments below.
> powerpc needs to keep the vdso in sync whenener settimeodfay() is
> called. Adding the hook the to the clocksource structure was my way of
> allowing this to happen. There are other approaches, but this seemed to
> best allow for runtime. Initially I considered using update_vsyscall()
> but this is called from do_timer(), and I don't need this code run then
> :(
I might be missing a subtlety in the ppc code, but I'm still not sure if
I see the need for the clocksource settimeofday hook.
update_vsyscall() is intended to provide a hook that allows the generic
time code to provide all the needed timekeeping state to the arch
specific vsyscall implementation. It is called any time the base
timekeeping variables are changed.
You're already calling timer_recalc_offset from there which looks almost
as expensive as the settime hook, so I'm not sure I understand the
division.
But to your credit, the patch Sergei and I have been slowly working on
(I believe I've sent that to you already, but if not let me know) never
got the VDSO code working, so good show!
> +static void clocksource_settimeofday(struct clocksource *cs,
> + struct timespec *ts)
> +{
> + u64 new_xsec;
> +
> +#ifdef CONFIG_PPC_ISERIES
> + if (firmware_has_feature(FW_FEATURE_ISERIES) && first_settimeofday) {
> + iSeries_tb_recal();
> + first_settimeofday = 0;
> + }
> +#endif
> +
> + /* Make userspace gettimeofday spin until we're done. */
> + ++vdso_data->tb_update_count;
> + smp_mb();
> +
> + /* In case of a large backwards jump in time with NTP, we want the
> + * clock to be updated as soon as the PLL is again in lock.
> + */
> + last_rtc_update = xtime.tv_sec - 658;
> +
> + new_xsec = xtime.tv_nsec;
> + if (new_xsec != 0) {
> + new_xsec *= XSEC_PER_SEC;
> + do_div(new_xsec, NSEC_PER_SEC);
> + }
> +
> + new_xsec += (u64)xtime.tv_sec * XSEC_PER_SEC;
> +
> + vdso_data->tz_minuteswest = sys_tz.tz_minuteswest;
> + vdso_data->tz_dsttime = sys_tz.tz_dsttime;
> +
> + update_gtod(tb_last_jiffy, new_xsec, do_gtod.varp->tb_to_xs);
> +}
> +
> +void update_vsyscall(struct timespec *wall_time, struct clocksource *clock)
> +{
> + timer_recalc_offset(tb_last_jiffy);
> + timer_check_rtc();
> +}
I think it would be enlightening to flatten this out a bit. Putting both
the timer_recalc_offset and clocksource_settime code in the same
function. It might illustrate where some optimizations could be done and
where it might make more sense to split things up.
Also I'd leave timer_check_rtc() in the timer_interrupt for now (later
moving it to tglx's generic rtc update).
thanks
-john
^ permalink raw reply
* General question on upgrading Linux version
From: Bizhan Gholikhamseh (bgholikh) @ 2007-06-20 21:29 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 351 bytes --]
Hi All,
We are using MPC8541 processor from freescale. Our current kernel
version is based on 2.6.11 plus some patches provided by Freescale. I
would like to update our Kernel version to a more recent version.
I would greatly appreciate if you could provide me with some general
guideline on how to proceed .....
Many thanks in advance,
B
[-- Attachment #2: Type: text/html, Size: 1083 bytes --]
^ permalink raw reply
* Re: General question on upgrading Linux version
From: Andy Fleming @ 2007-06-20 21:52 UTC (permalink / raw)
To: Bizhan Gholikhamseh; +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA911279641502D1A3FA@xmb-sjc-212.amer.cisco.com>
On Jun 20, 2007, at 16:29, Bizhan Gholikhamseh ((bgholikh)) wrote:
> Hi All,
> We are using MPC8541 processor from freescale. Our current kernel
> version is based on 2.6.11 plus some patches provided by Freescale.
> I would like to update our Kernel version to a more recent version.
> I would greatly appreciate if you could provide me with some
> general guideline on how to proceed .....
You should be able to check out the latest sources from git://
git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
You will probably also need a newer u-boot from here:
git://www.denx.de/git/u-boot-mpc85xx.git
Please tell me if you have any problems using these.
Andy
^ permalink raw reply
* RE: General question on upgrading Linux version
From: Bizhan Gholikhamseh (bgholikh) @ 2007-06-20 21:53 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-embedded
In-Reply-To: <33351C82-D56D-4414-81F1-328D36A7993D@freescale.com>
=20
> -----Original Message-----
> From: Andy Fleming [mailto:afleming@freescale.com]=20
> Sent: Wednesday, June 20, 2007 2:52 PM
> To: Bizhan Gholikhamseh (bgholikh)
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: General question on upgrading Linux version
>=20
>=20
> On Jun 20, 2007, at 16:29, Bizhan Gholikhamseh ((bgholikh)) wrote:
>=20
> > Hi All,
> > We are using MPC8541 processor from freescale. Our current kernel=20
> > version is based on 2.6.11 plus some patches provided by Freescale.
> > I would like to update our Kernel version to a more recent version.
> > I would greatly appreciate if you could provide me with=20
> some general=20
> > guideline on how to proceed .....
>=20
> You should be able to check out the latest sources from=20
> git:// git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
>=20
> You will probably also need a newer u-boot from here:
>=20
> git://www.denx.de/git/u-boot-mpc85xx.git
>=20
> Please tell me if you have any problems using these.
Thanks will do.
>=20
> Andy
>=20
^ permalink raw reply
* Re: [PATCH/RFC] Modify sched_clock() to make CONFIG_PRINTK_TIME more sane.
From: Tony Breeds @ 2007-06-21 4:29 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Olof Johansson, LinuxPPC-dev
In-Reply-To: <Pine.LNX.4.62.0706200936300.27011@pademelon.sonytel.be>
On Wed, Jun 20, 2007 at 09:37:51AM +0200, Geert Uytterhoeven wrote:
Hi Geert,
> Just wondering, does the INITIAL_JIFFIES mechanism to catch wrap bugs still
> work after this patch?
>
> include/linux/jiffies.h:
> | /*
> | * Have the 32 bit jiffies value wrap 5 minutes after boot
> | * so jiffies wrap bugs show up earlier.
> | */
> | #define INITIAL_JIFFIES ((unsigned long)(unsigned int) (-300*HZ))
I've done a quick check and I can't see how my patch would break
anything, given that sched_clock() on powerpc returns a timebase value
generally not related to jiffies.
I hope I haven't missed anything.
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [PATCH/RFC] Make certain timekeeping variables __read_mostly
From: Tony Breeds @ 2007-06-21 4:41 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: LinuxPPC-dev
In-Reply-To: <Pine.LNX.4.62.0706200940260.27011@pademelon.sonytel.be>
On Wed, Jun 20, 2007 at 09:41:47AM +0200, Geert Uytterhoeven wrote:
Hi Geert,
> There's no __read_mostly support for powerpc yet (is there?), so __read_mostly
> just expands to nothing?
That's true but we may in the future! :)
Perhaps something like the patch below will start discussion.
From: Tony Breeds <tony@bakeyournoodle.com>
Initial cut to add __read_mostly support for powerpc.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/kernel/vmlinux.lds.S | 6 ++++++
include/asm-powerpc/cache.h | 2 ++
2 files changed, 8 insertions(+)
Index: working/arch/powerpc/kernel/vmlinux.lds.S
===================================================================
--- working.orig/arch/powerpc/kernel/vmlinux.lds.S
+++ working/arch/powerpc/kernel/vmlinux.lds.S
@@ -7,6 +7,7 @@
#define PROVIDE32(x) PROVIDE(x)
#endif
#include <asm-generic/vmlinux.lds.h>
+#include <asm/cache.h>
ENTRY(_stext)
@@ -211,6 +212,11 @@ SECTIONS
*(.data.cacheline_aligned)
}
+ . = ALIGN(L1_CACHE_BYTES);
+ .data.read_mostly : {
+ *(.data.read_mostly)
+ }
+
. = ALIGN(PAGE_SIZE);
__data_nosave : {
__nosave_begin = .;
Index: working/include/asm-powerpc/cache.h
===================================================================
--- working.orig/include/asm-powerpc/cache.h
+++ working/include/asm-powerpc/cache.h
@@ -34,5 +34,9 @@ struct ppc64_caches {
extern struct ppc64_caches ppc64_caches;
#endif /* __powerpc64__ && ! __ASSEMBLY__ */
+#if !defined(__ASSEMBLY__)
+#define __read_mostly __attribute__((__section__(".data.read_mostly")))
+#endif
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_CACHE_H */
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* [PATCH] mpc52xx: sparse fixes
From: Domen Puncer @ 2007-06-21 7:45 UTC (permalink / raw)
To: linuxppc-embedded
sparse caught these static functions / __iomem annotations
under arch/powerpc/platform/52xx/
Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
---
arch/powerpc/platforms/52xx/efika.c | 4 ++--
arch/powerpc/platforms/52xx/lite5200.c | 2 +-
arch/powerpc/platforms/52xx/mpc52xx_pm.c | 8 ++++----
3 files changed, 7 insertions(+), 7 deletions(-)
Index: work-powerpc.git/arch/powerpc/platforms/52xx/efika.c
===================================================================
--- work-powerpc.git.orig/arch/powerpc/platforms/52xx/efika.c
+++ work-powerpc.git/arch/powerpc/platforms/52xx/efika.c
@@ -83,7 +83,7 @@ static struct pci_ops rtas_pci_ops = {
};
-void __init efika_pcisetup(void)
+static void __init efika_pcisetup(void)
{
const int *bus_range;
int len;
@@ -145,7 +145,7 @@ void __init efika_pcisetup(void)
}
#else
-void __init efika_pcisetup(void)
+static void __init efika_pcisetup(void)
{}
#endif
Index: work-powerpc.git/arch/powerpc/platforms/52xx/lite5200.c
===================================================================
--- work-powerpc.git.orig/arch/powerpc/platforms/52xx/lite5200.c
+++ work-powerpc.git/arch/powerpc/platforms/52xx/lite5200.c
@@ -158,7 +158,7 @@ static void __init lite5200_setup_arch(v
}
-void lite5200_show_cpuinfo(struct seq_file *m)
+static void lite5200_show_cpuinfo(struct seq_file *m)
{
struct device_node* np = of_find_all_nodes(NULL);
const char *model = NULL;
Index: work-powerpc.git/arch/powerpc/platforms/52xx/mpc52xx_pm.c
===================================================================
--- work-powerpc.git.orig/arch/powerpc/platforms/52xx/mpc52xx_pm.c
+++ work-powerpc.git/arch/powerpc/platforms/52xx/mpc52xx_pm.c
@@ -9,8 +9,8 @@
/* these are defined in mpc52xx_sleep.S, and only used here */
-extern void mpc52xx_deep_sleep(void *sram, void *sdram_regs,
- struct mpc52xx_cdm *, struct mpc52xx_intr *);
+extern void mpc52xx_deep_sleep(void __iomem *sram, void __iomem *sdram_regs,
+ struct mpc52xx_cdm __iomem *, struct mpc52xx_intr __iomem*);
extern void mpc52xx_ds_sram(void);
extern const long mpc52xx_ds_sram_size;
extern void mpc52xx_ds_cached(void);
@@ -21,7 +21,7 @@ static void __iomem *sdram;
static struct mpc52xx_cdm __iomem *cdm;
static struct mpc52xx_intr __iomem *intr;
static struct mpc52xx_gpio_wkup __iomem *gpiow;
-static void *sram;
+static void __iomem *sram;
static int sram_size;
struct mpc52xx_suspend mpc52xx_suspend;
@@ -100,7 +100,7 @@ int mpc52xx_pm_enter(suspend_state_t sta
u32 clk_enables;
u32 msr, hid0;
u32 intr_main_mask;
- void __iomem * irq_0x500 = (void *)CONFIG_KERNEL_START + 0x500;
+ void __iomem * irq_0x500 = (void __iomem *)CONFIG_KERNEL_START + 0x500;
unsigned long irq_0x500_stop = (unsigned long)irq_0x500 + mpc52xx_ds_cached_size;
char saved_0x500[mpc52xx_ds_cached_size];
^ 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