* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Scott Wood @ 2007-05-17 18:53 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <464CA380.2020705@freescale.com>
Timur Tabi wrote:
> One more thing - I think each DTS file should specify which revision of the board it
> supports, and there should be code in U-Boot and/or Linux to check that revision and
> reject the device tree if there's a mismatch. We don't want people accidentally using the
> wrong device tree and wondering why it doesn't work.
We also don't want people using a perfectly good device tree on a newer
revision of the board that just fixes things and doesn't make any
device-tree-relevant changes, and wondering why it doesn't work due to a
failed revision check.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc: fix #endif comment
From: Jon Tollefson @ 2007-05-17 18:49 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <464B50B6.3090300@us.ibm.com>
Resubmitting with white space damage repaired.
Fix #endif comments to match #if.
Signed-off-by: Jon Tollefson <kniht@linux.vnet.ibm.com>
----
hash_utils_64.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 028ba4e..4f2f453 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -430,7 +430,7 @@ static void __init htab_finish_init(void)
make_bl(ht64_call_hpte_insert2, ppc_md.hpte_insert);
make_bl(ht64_call_hpte_remove, ppc_md.hpte_remove);
make_bl(ht64_call_hpte_updatepp, ppc_md.hpte_updatepp);
-#endif /* CONFIG_PPC_64K_PAGES */
+#endif /* CONFIG_PPC_HAS_HASH_64K */
make_bl(htab_call_hpte_insert1, ppc_md.hpte_insert);
make_bl(htab_call_hpte_insert2, ppc_md.hpte_insert);
@@ -837,7 +837,7 @@ void hash_preload(struct mm_struct *mm, unsigned long ea,
if (mm->context.user_psize == MMU_PAGE_64K)
__hash_page_64K(ea, access, vsid, ptep, trap, local);
else
-#endif /* CONFIG_PPC_64K_PAGES */
+#endif /* CONFIG_PPC_HAS_HASH_64K */
__hash_page_4K(ea, access, vsid, ptep, trap, local);
local_irq_restore(flags);
^ permalink raw reply related
* Re: [PATCH] powerpc: move common code out of if/else
From: Jon Tollefson @ 2007-05-17 18:49 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <464B50AA.9060807@us.ibm.com>
Resubmitting with white space damage repaired.
Move common code out of if/else.
Signed-off-by: Jon Tollefson <kniht@linux.vnet.ibm.com>
----
hash_native_64.c | 3 +--
1 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/hash_native_64.c b/arch/powerpc/mm/hash_native_64.c
index 4a20d89..bb76814 100644
--- a/arch/powerpc/mm/hash_native_64.c
+++ b/arch/powerpc/mm/hash_native_64.c
@@ -233,15 +233,14 @@ static long native_hpte_updatepp(unsigned long slot, unsigned long newpp,
/* Even if we miss, we need to invalidate the TLB */
if (!HPTE_V_COMPARE(hpte_v, want_v) || !(hpte_v & HPTE_V_VALID)) {
DBG_LOW(" -> miss\n");
- native_unlock_hpte(hptep);
ret = -1;
} else {
DBG_LOW(" -> hit\n");
/* Update the HPTE */
hptep->r = (hptep->r & ~(HPTE_R_PP | HPTE_R_N)) |
(newpp & (HPTE_R_PP | HPTE_R_N | HPTE_R_C));
- native_unlock_hpte(hptep);
}
+ native_unlock_hpte(hptep);
/* Ensure it is out of the tlb too. */
tlbie(va, psize, local);
^ permalink raw reply related
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Timur Tabi @ 2007-05-17 18:48 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <464CA302.9060707@freescale.com>
Timur Tabi wrote:
> I think two DTS files is the best approach for now. A few of us had an
> idea to introduce conditional statements in to the DTS, and U-Boot would
> examine the board and/or environment variables and then apply the
> conditions to the device tree before booting the kernel. This would
> allow you to merge the two DTS files into one, but we're quite a ways
> off from implementing this feature. In the meantime, two DTS files is
> okay.
One more thing - I think each DTS file should specify which revision of the board it
supports, and there should be code in U-Boot and/or Linux to check that revision and
reject the device tree if there's a mismatch. We don't want people accidentally using the
wrong device tree and wondering why it doesn't work.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Timur Tabi @ 2007-05-17 18:46 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <1179421139.8132.256.camel@rhino>
Wade Farnsworth wrote:
> Yes. On rev 1.0 boards, all of the devices on the south bridge are on
> bus 0, while on rev 1.02, the devices on the southbridge are on bus 2.
>
> I'd like to use the same dts for both rev's if possible. But if there
> is a reason why they shouldn't, I suppose I could create a separate dts.
I think two DTS files is the best approach for now. A few of us had an idea to introduce
conditional statements in to the DTS, and U-Boot would examine the board and/or
environment variables and then apply the conditions to the device tree before booting the
kernel. This would allow you to merge the two DTS files into one, but we're quite a ways
off from implementing this feature. In the meantime, two DTS files is okay.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Sergei Shtylyov @ 2007-05-17 18:42 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, tglx, mingo, linux-kernel
In-Reply-To: <6E0D5E13-C939-4FCE-81A3-F29DFA6436A2@kernel.crashing.org>
Hello.
Kumar Gala wrote:
>> Kumar Gala wrote:
>>> I haven't looked at all the new clock/timer code, is there any
>>> utility in having support for more than one clock source?
>> Of course, you may register as many as you like.
> Sure, but is there any utility in registering more than the decrementer
> on PPC?
Not yet. I'm not sure I know any other PPC CPU facility fitting for
clockevents. In theory, FIT could be used -- but its period is measured in
powers of 2, IIRC.
> - k
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Scott Wood @ 2007-05-17 18:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, i2c
In-Reply-To: <5B363A90-5528-4441-BBF9-9C6D8833D938@kernel.crashing.org>
Kumar Gala wrote:
> On May 17, 2007, at 11:47 AM, Scott Wood wrote:
>> But we do handle i2c *controllers* in the device tree, and that's
>> where a bus number property would go. Given that we don't have a
>> binding for non-toplevel i2c buses, and I'm not adding one, I don't
>> see the relevance. Note that adding a bus number property makes zero
>> sense for toplevel buses, as at that level the bus number is just a
>> fiction maintained by Linux for user API and device preregistration
>> purposes.
>
> The only support we have for i2c controllers is to support one specific
> i2c controller from Freescale.
That's not what booting-without-of.txt says.
> If you aren't going to provide a complete solution why are you prosing
> one?
Because if we can't do everything that anyone could ever need, we
shouldn't do anything? There's nothing in what I proposed that prevents
i2c muxes; it just doesn't explicitly specify what extra things would
need to be specified.
>> I'm tired of this put stuff in the device tree but only as much
> as I need to do my particular thing.
I'm tired of unconstructive whining that something that accomplishes
something useful doesn't do everything you want it to. If you want a
device tree binding for i2c muxes, write one. If you think it's
pointless, then stop complaining about bindings that *are* useful.
> The device tree is just as
> important an interface point as the kernel/user space interfaces and we
> should treat it as such.
I agree. And you will note that the entire set of kernel/user
interfaces didn't spring into existence in one instant. In both cases,
adding is much easier than changing, and only additions would be needed
to support i2c muxes.
> If people aren't willing to work to a
> complete solution than they should stop proposing changes.
By that token, if you're not willing to work toward any solution
(complete or otherwise), you should stop proposing changes (or the
absence thereof). If there's a specific change that you would like to
suggest that you believe would improve the binding, then please say what
it is.
>> It's not a matter of the binding only covering some cases; it's a
>> matter of the binding being for one thing (i2c devices) and not
>> another (multiplexed i2c buses).
>
>
> But once you introduce the concept of i2c devices you introduce the
> possibility of hierarchies. For example, tell me how I'd describe the
> following device http://www.nxp.com/pip/PCA9548ABS.html and any i2c
> devices connected to it?
i2c-switch@70 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "pca9548a";
reg = <70>;
i2c@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
rtc@68 {
device_type = "rtc";
compatible = "ds1374";
reg = <68>;
};
};
i2c@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
// more devices here
};
// i2c@2-i2c@7 here
};
>>> If only some subset of cases are handled what good is the device
>>> tree to a user? They will just have to figure out if their usage
>>> is supported or not and if not find some other solution that works
>>> for them.
>>
>>
>> ...just as they'll have to figure out if a binding exists for device
>> type $FOO.
>
>
> True, but if I go look at the PCI OF spec I have some faith that its
> complete and will cover my needs.
So what does the PCI OF spec have to say about devices on i2c
controllers on PCI cards?
> As I've been thinking about this I think trying to even describe i2c
> devices in the device tree is point less.
Well then device trees aren't a complete solution to the problem, so
let's just ditch the concept entirely! That's the way you want to do
things, right?
> Since I2C devices have no
> way of uniquely identifying themselves we are looking at taking on the
> role of device name registrar
How's that different from any other random chip or logic block that gets
hooked up through something that isn't i2c?
> and if someone is willing to do that
> great, but I doubt anyone truly is.
Perhaps something could be done through Power.org?
-Scott
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Kumar Gala @ 2007-05-17 18:31 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, tglx, mingo, linux-kernel
In-Reply-To: <464C9E67.2020909@ru.mvista.com>
On May 17, 2007, at 1:26 PM, Sergei Shtylyov wrote:
> Hello.
>
> Kumar Gala wrote:
>
>> I haven't looked at all the new clock/timer code, is there any
>> utility in having support for more than one clock source?
>
> Of course, you may register as many as you like.
Sure, but is there any utility in registering more than the
decrementer on PPC?
- k
^ permalink raw reply
* Re: [PATCH 2.6.22] ehca: return proper error code if register_mr fails
From: Roland Dreier @ 2007-05-17 18:32 UTC (permalink / raw)
To: Hoang-Nam Nguyen; +Cc: linuxppc-dev, raisch, linux-kernel, openib-general
In-Reply-To: <200705161450.55848.hnguyen@linux.vnet.ibm.com>
thanks, applied
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Sergei Shtylyov @ 2007-05-17 18:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, tglx, mingo, linux-kernel
In-Reply-To: <135307ED-7125-4859-8594-4B5B900D92D6@kernel.crashing.org>
Hello.
Kumar Gala wrote:
> I haven't looked at all the new clock/timer code, is there any utility
> in having support for more than one clock source?
Of course, you may register as many as you like.
> - k
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Kumar Gala @ 2007-05-17 18:17 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, tglx, mingo, linux-kernel
In-Reply-To: <464C99FF.8080404@ru.mvista.com>
On May 17, 2007, at 1:07 PM, Sergei Shtylyov wrote:
> Hello.
>
> Kumar Gala wrote:
>
>>> Index: linux-2.6/arch/powerpc/kernel/time.c
>>> ===================================================================
>>> --- linux-2.6.orig/arch/powerpc/kernel/time.c
>>> +++ linux-2.6/arch/powerpc/kernel/time.c
> [...]
>>> @@ -128,6 +129,83 @@ unsigned long ppc_tb_freq;
>>> static u64 tb_last_jiffy __cacheline_aligned_in_smp;
>>> static DEFINE_PER_CPU(u64, last_jiffy);
>>>
>>> +#ifdef CONFIG_GENERIC_CLOCKEVENTS
>>> +
>>> +#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
>>> +#define DECREMENTER_MAX 0xffffffff
>>> +#else
>>> +#define DECREMENTER_MAX 0x7fffffff /* setting MSB triggers an
>>> interrupt */
>>> +#endif
>>> +
>>> +static int decrementer_set_next_event(unsigned long evt,
>>> + struct clock_event_device *dev)
>>> +{
>>> +#if defined(CONFIG_40x)
>>> + mtspr(SPRN_PIT, evt); /* 40x has a hidden PIT auto-
>>> reload register */
>>> +#elif defined(CONFIG_BOOKE)
>>> + mtspr(SPRN_DECAR, evt); /* Book E has separate auto-reload
>>> register */
>>> + set_dec(evt);
>
>> what's the point of setting decar if you're just going to set_dec
>> as well?
>
> Bothered to read the Book E specs? ;-)
I have :)
> Loading DECAR doesn't auto-reload DEC. What I want is both set
> the auto-reload value and start counting down from it at the same
> time (if the decrementer is in auto-reload mode).
I see you're using DECAR to make it periodic.
> [big cut-off]
>
> WBR, Sergei
I haven't looked at all the new clock/timer code, is there any
utility in having support for more than one clock source?
- k
^ permalink raw reply
* [PATCH 2.6.21-rt2] PowerPC: implement read_persistent_clock()
From: Sergei Shtylyov @ 2007-05-17 18:13 UTC (permalink / raw)
To: tglx, mingo; +Cc: linuxppc-dev, linux-kernel, johnstul
Here's the read_persistent_clock() implementation for PowerPC.
I'm deliberately renaming get_boot_time() despite it's not static as it
doesn't get called from anywhere else.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
---
Have almost forgotten about this one... :-)
This patch hasn't received a good testing though -- at least it doesn't break
without RTC... ;-)
arch/powerpc/kernel/time.c | 62 ++++++++++++++++++++-------------------------
1 files changed, 28 insertions(+), 34 deletions(-)
Index: linux-2.6/arch/powerpc/kernel/time.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/time.c
+++ linux-2.6/arch/powerpc/kernel/time.c
@@ -762,31 +762,46 @@ void __init generic_calibrate_decr(void)
#endif
}
-unsigned long get_boot_time(void)
+unsigned long read_persistent_clock(void)
{
- struct rtc_time tm;
+ unsigned long time = 0;
+ static int first = 1;
+
+ if (first && ppc_md.time_init) {
+ timezone_offset = ppc_md.time_init();
+
+ /* If platform provided a timezone (pmac), we correct the time */
+ if (timezone_offset) {
+ sys_tz.tz_minuteswest = -timezone_offset / 60;
+ sys_tz.tz_dsttime = 0;
+ }
+ }
if (ppc_md.get_boot_time)
- return ppc_md.get_boot_time();
- if (!ppc_md.get_rtc_time)
- return 0;
- ppc_md.get_rtc_time(&tm);
- return mktime(tm.tm_year+1900, tm.tm_mon+1, tm.tm_mday,
- tm.tm_hour, tm.tm_min, tm.tm_sec);
+ time = ppc_md.get_boot_time();
+ else if (ppc_md.get_rtc_time) {
+ struct rtc_time tm;
+
+ ppc_md.get_rtc_time(&tm);
+ time = mktime(tm.tm_year+1900, tm.tm_mon+1, tm.tm_mday,
+ tm.tm_hour, tm.tm_min, tm.tm_sec);
+ }
+ time -= timezone_offset;
+
+ if (first) {
+ last_rtc_update = time;
+ first = 0;
+ }
+ return time;
}
/* This function is only called on the boot processor */
void __init time_init(void)
{
- unsigned long flags;
- unsigned long tm = 0;
struct div_result res;
u64 scale, x;
unsigned shift;
- if (ppc_md.time_init != NULL)
- timezone_offset = ppc_md.time_init();
-
if (__USE_RTC()) {
/* 601 processor: dec counts down by 128 every 128ns */
ppc_tb_freq = 1000000000;
@@ -860,27 +875,6 @@ void __init time_init(void)
tb_to_ns_scale = scale;
tb_to_ns_shift = shift;
- tm = get_boot_time();
-
- write_seqlock_irqsave(&xtime_lock, flags);
-
- /* If platform provided a timezone (pmac), we correct the time */
- if (timezone_offset) {
- sys_tz.tz_minuteswest = -timezone_offset / 60;
- sys_tz.tz_dsttime = 0;
- tm -= timezone_offset;
- }
-
- xtime.tv_sec = tm;
- xtime.tv_nsec = 0;
-
- time_freq = 0;
-
- last_rtc_update = xtime.tv_sec;
- set_normalized_timespec(&wall_to_monotonic,
- -xtime.tv_sec, -xtime.tv_nsec);
- write_sequnlock_irqrestore(&xtime_lock, flags);
-
#ifdef CONFIG_GENERIC_CLOCKEVENTS
decrementer_clockevent.mult = div_sc(ppc_tb_freq, NSEC_PER_SEC,
decrementer_clockevent.shift);
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Sergei Shtylyov @ 2007-05-17 18:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, tglx, mingo, linux-kernel
In-Reply-To: <8E44DB06-767D-4864-8D2C-6132E4D4370B@kernel.crashing.org>
Hello.
Kumar Gala wrote:
>> Index: linux-2.6/arch/powerpc/kernel/time.c
>> ===================================================================
>> --- linux-2.6.orig/arch/powerpc/kernel/time.c
>> +++ linux-2.6/arch/powerpc/kernel/time.c
[...]
>> @@ -128,6 +129,83 @@ unsigned long ppc_tb_freq;
>> static u64 tb_last_jiffy __cacheline_aligned_in_smp;
>> static DEFINE_PER_CPU(u64, last_jiffy);
>>
>> +#ifdef CONFIG_GENERIC_CLOCKEVENTS
>> +
>> +#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
>> +#define DECREMENTER_MAX 0xffffffff
>> +#else
>> +#define DECREMENTER_MAX 0x7fffffff /* setting MSB triggers an
>> interrupt */
>> +#endif
>> +
>> +static int decrementer_set_next_event(unsigned long evt,
>> + struct clock_event_device *dev)
>> +{
>> +#if defined(CONFIG_40x)
>> + mtspr(SPRN_PIT, evt); /* 40x has a hidden PIT auto-reload
>> register */
>> +#elif defined(CONFIG_BOOKE)
>> + mtspr(SPRN_DECAR, evt); /* Book E has separate auto-reload
>> register */
>> + set_dec(evt);
> what's the point of setting decar if you're just going to set_dec as well?
Bothered to read the Book E specs? ;-)
Loading DECAR doesn't auto-reload DEC. What I want is both set the
auto-reload value and start counting down from it at the same time (if the
decrementer is in auto-reload mode).
[big cut-off]
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Kumar Gala @ 2007-05-17 17:47 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, tglx, mingo, linux-kernel
In-Reply-To: <200705172142.26739.sshtylyov@ru.mvista.com>
On May 17, 2007, at 12:42 PM, Sergei Shtylyov wrote:
> Add PowerPC decrementer clock event driver.
>
> Every effort has been made to support the different implementations
> of the
> decrementer: the classic one (with 970 series variation), 40x and
> Book E
> specific ones.
>
> I had to make CONFIG_GENERIC_CLOCKEVENTS option selectable for the
> compatibility reasons -- this option is not compatible with the PPC64
> deterministic time accounting.
>
> Thanks to Daniel Walker and Thomas Gleixner for the suggestions
> they made...
>
> Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
>
> ---
> This patch has been reworked against the 2.6.21 clockevents framework.
> It has only been tested on the Book E 32-bit CPU this time, so re-
> testing on
> "classic" PowerPC CPUs is needed (used to work as of 2.6.18-rt7)...
>
> CONFIG_PPC_MULTIPLATFORM was the best option I was able to come up
> with
> to cover machines built on 970 series CPUs...
>
> arch/powerpc/Kconfig | 12 +++-
> arch/powerpc/kernel/time.c | 124 +++++++++++++++++++++++++++++++++
> +++++++++++-
> 2 files changed, 134 insertions(+), 2 deletions(-)
>
> Index: linux-2.6/arch/powerpc/Kconfig
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/Kconfig
> +++ linux-2.6/arch/powerpc/Kconfig
> @@ -317,7 +317,7 @@ config PPC_STD_MMU_32
>
> config VIRT_CPU_ACCOUNTING
> bool "Deterministic task and CPU time accounting"
> - depends on PPC64
> + depends on PPC64 && !GENERIC_CLOCKEVENTS
> default y
> help
> Select this option to enable more accurate task and CPU time
> @@ -760,6 +760,16 @@ config HIGHMEM
> depends on PPC32
>
> source kernel/Kconfig.hz
> +
> +config GENERIC_CLOCKEVENTS
> + bool "Clock event devices support"
> + default n
> + help
> + Enable support for the clock event devices necessary for the
> + high-resolution timers and the tickless system support.
> + NOTE: This is not compatible with the deterministic time
> accounting
> + option on PPC64.
> +
> source kernel/Kconfig.preempt
>
> config RWSEM_GENERIC_SPINLOCK
> Index: linux-2.6/arch/powerpc/kernel/time.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/kernel/time.c
> +++ linux-2.6/arch/powerpc/kernel/time.c
> @@ -52,6 +52,7 @@
> #include <linux/jiffies.h>
> #include <linux/posix-timers.h>
> #include <linux/irq.h>
> +#include <linux/clockchips.h>
>
> #include <asm/io.h>
> #include <asm/processor.h>
> @@ -128,6 +129,83 @@ unsigned long ppc_tb_freq;
> static u64 tb_last_jiffy __cacheline_aligned_in_smp;
> static DEFINE_PER_CPU(u64, last_jiffy);
>
> +#ifdef CONFIG_GENERIC_CLOCKEVENTS
> +
> +#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
> +#define DECREMENTER_MAX 0xffffffff
> +#else
> +#define DECREMENTER_MAX 0x7fffffff /* setting MSB triggers an
> interrupt */
> +#endif
> +
> +static int decrementer_set_next_event(unsigned long evt,
> + struct clock_event_device *dev)
> +{
> +#if defined(CONFIG_40x)
> + mtspr(SPRN_PIT, evt); /* 40x has a hidden PIT auto-reload
> register */
> +#elif defined(CONFIG_BOOKE)
> + mtspr(SPRN_DECAR, evt); /* Book E has separate auto-reload
> register */
> + set_dec(evt);
what's the point of setting decar if you're just going to set_dec as
well?
> +#else
> + set_dec(evt - 1); /* Classic decrementer interrupts at -1 */
> +#endif
> + return 0;
> +}
> +
> +static void decrementer_set_mode(enum clock_event_mode mode,
> + struct clock_event_device *dev)
> +{
> +#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
> + u32 tcr = mfspr(SPRN_TCR);
> +
> + tcr |= TCR_DIE;
> + switch (mode) {
> + case CLOCK_EVT_MODE_PERIODIC:
> + tcr |= TCR_ARE;
> + break;
> + case CLOCK_EVT_MODE_ONESHOT:
> + tcr &= ~TCR_ARE;
> + break;
> + case CLOCK_EVT_MODE_UNUSED:
> + case CLOCK_EVT_MODE_SHUTDOWN:
> + tcr &= ~TCR_DIE;
> + break;
> + }
> + mtspr(SPRN_TCR, tcr);
> +#endif
> + if (mode == CLOCK_EVT_MODE_PERIODIC)
> + decrementer_set_next_event(tb_ticks_per_jiffy, dev);
> +}
> +
> +static struct clock_event_device decrementer_clockevent = {
> + .name = "decrementer",
> +#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
> + .features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC,
> +#else
> + .features = CLOCK_EVT_FEAT_ONESHOT,
> +#endif
> + .shift = 32,
> + .rating = 200,
> + .irq = -1,
> + .set_next_event = decrementer_set_next_event,
> + .set_mode = decrementer_set_mode,
> +};
> +
> +static DEFINE_PER_CPU(struct clock_event_device, decrementers);
> +
> +static void register_decrementer(void)
> +{
> + int cpu = smp_processor_id();
> + struct clock_event_device *decrementer = &per_cpu(decrementers,
> cpu);
> +
> + memcpy(decrementer, &decrementer_clockevent, sizeof(*decrementer));
> +
> + decrementer->cpumask = cpumask_of_cpu(cpu);
> +
> + clockevents_register_device(decrementer);
> +}
> +
> +#endif /* CONFIG_GENERIC_CLOCKEVENTS */
> +
> #ifdef CONFIG_VIRT_CPU_ACCOUNTING
> /*
> * Factors for converting from cputime_t (timebase ticks) to
> @@ -313,6 +391,9 @@ void snapshot_timebase(void)
> {
> __get_cpu_var(last_jiffy) = get_tb();
> snapshot_purr();
> +#ifdef CONFIG_GENERIC_CLOCKEVENTS
> + register_decrementer();
> +#endif
> }
>
> void __delay(unsigned long loops)
> @@ -470,7 +551,31 @@ void timer_interrupt(struct pt_regs * re
> old_regs = set_irq_regs(regs);
> irq_enter();
>
> +#ifdef CONFIG_GENERIC_CLOCKEVENTS
> +#ifdef CONFIG_PPC_MULTIPLATFORM
> + /*
> + * We must write a positive value to the decrementer to clear
> + * the interrupt on the IBM 970 CPU series. In periodic mode,
> + * this happens when the decrementer gets reloaded later, but
> + * in one-shot mode, we have to do it here since an event handler
> + * may skip loading the new value...
> + */
> + if (per_cpu(decrementers, cpu).mode != CLOCK_EVT_MODE_PERIODIC)
> + set_dec(DECREMENTER_MAX);
> +#endif
> + /*
> + * We can't disable the decrementer, so in the period between
> + * CPU being marked offline and calling stop-self, it's taking
> + * timer interrupts...
> + */
> + if (!cpu_is_offline(cpu)) {
> + struct clock_event_device *dev = &per_cpu(decrementers, cpu);
> +
> + dev->event_handler(dev);
> + }
> +#else
> profile_tick(CPU_PROFILING);
> +#endif
> calculate_steal_time();
>
> #ifdef CONFIG_PPC_ISERIES
> @@ -486,6 +591,7 @@ void timer_interrupt(struct pt_regs * re
> if (__USE_RTC() && per_cpu(last_jiffy, cpu) >= 1000000000)
> per_cpu(last_jiffy, cpu) -= 1000000000;
>
> +#ifndef CONFIG_GENERIC_CLOCKEVENTS
> /*
> * We cannot disable the decrementer, so in the period
> * between this cpu's being marked offline in cpu_online_map
> @@ -495,6 +601,7 @@ void timer_interrupt(struct pt_regs * re
> */
> if (!cpu_is_offline(cpu))
> account_process_time(regs);
> +#endif
>
> /*
> * No need to check whether cpu is offline here; boot_cpuid
> @@ -507,15 +614,19 @@ void timer_interrupt(struct pt_regs * re
> tb_next_jiffy = tb_last_jiffy + tb_ticks_per_jiffy;
> if (per_cpu(last_jiffy, cpu) >= tb_next_jiffy) {
> tb_last_jiffy = tb_next_jiffy;
> +#ifndef CONFIG_GENERIC_CLOCKEVENTS
> do_timer(1);
> +#endif
> /*timer_recalc_offset(tb_last_jiffy);*/
> timer_check_rtc();
> }
> write_sequnlock(&xtime_lock);
> }
> -
> +
> +#ifndef CONFIG_GENERIC_CLOCKEVENTS
> next_dec = tb_ticks_per_jiffy - ticks;
> set_dec(next_dec);
> +#endif
>
> #ifdef CONFIG_PPC_ISERIES
> if (firmware_has_feature(FW_FEATURE_ISERIES) &&
> hvlpevent_is_pending())
> @@ -770,8 +881,19 @@ void __init time_init(void)
> -xtime.tv_sec, -xtime.tv_nsec);
> write_sequnlock_irqrestore(&xtime_lock, flags);
>
> +#ifdef CONFIG_GENERIC_CLOCKEVENTS
> + decrementer_clockevent.mult = div_sc(ppc_tb_freq, NSEC_PER_SEC,
> + decrementer_clockevent.shift);
> + decrementer_clockevent.max_delta_ns =
> + clockevent_delta2ns(DECREMENTER_MAX, &decrementer_clockevent);
> + decrementer_clockevent.min_delta_ns =
> + clockevent_delta2ns(0xf, &decrementer_clockevent);
> +
> + register_decrementer();
> +#else
> /* Not exact, but the timer interrupt takes care of this */
> set_dec(tb_ticks_per_jiffy);
> +#endif
> }
>
> #define FEBRUARY 2
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH 2.6.21-rt2] PowerPC: enable HRT and dynticks support
From: Sergei Shtylyov @ 2007-05-17 17:46 UTC (permalink / raw)
To: tglx, mingo; +Cc: linuxppc-dev, linux-kernel
Enable HRT and dynamic ticks support for PowerPC.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
---
This patch has been reworked against the 2.6.21 clockevents framework.
It has only been tested on the Book E 32-bit CPU this time, so re-testing on
"classic" PowerPC CPUs is needed (there have been issues as of 2.6.18-rt7 but
those should now be fixed)...
arch/powerpc/Kconfig | 1 +
arch/powerpc/kernel/idle.c | 3 +++
2 files changed, 4 insertions(+)
Index: linux-2.6/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/Kconfig
+++ linux-2.6/arch/powerpc/Kconfig
@@ -770,6 +770,7 @@ config GENERIC_CLOCKEVENTS
NOTE: This is not compatible with the deterministic time accounting
option on PPC64.
+source kernel/time/Kconfig
source kernel/Kconfig.preempt
config RWSEM_GENERIC_SPINLOCK
Index: linux-2.6/arch/powerpc/kernel/idle.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/idle.c
+++ linux-2.6/arch/powerpc/kernel/idle.c
@@ -24,6 +24,7 @@
#include <linux/smp.h>
#include <linux/cpu.h>
#include <linux/sysctl.h>
+#include <linux/tick.h>
#include <asm/system.h>
#include <asm/processor.h>
@@ -56,6 +57,7 @@ void cpu_idle(void)
set_thread_flag(TIF_POLLING_NRFLAG);
while (1) {
+ tick_nohz_stop_sched_tick();
while (!need_resched() && !need_resched_delayed() &&
!cpu_should_die()) {
ppc64_runlatch_off();
@@ -92,6 +94,7 @@ void cpu_idle(void)
ppc64_runlatch_on();
if (cpu_should_die())
cpu_die();
+ tick_nohz_restart_sched_tick();
__preempt_enable_no_resched();
schedule();
preempt_disable();
^ permalink raw reply
* [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Sergei Shtylyov @ 2007-05-17 17:42 UTC (permalink / raw)
To: tglx, mingo; +Cc: linuxppc-dev, linux-kernel
Add PowerPC decrementer clock event driver.
Every effort has been made to support the different implementations of the
decrementer: the classic one (with 970 series variation), 40x and Book E
specific ones.
I had to make CONFIG_GENERIC_CLOCKEVENTS option selectable for the
compatibility reasons -- this option is not compatible with the PPC64
deterministic time accounting.
Thanks to Daniel Walker and Thomas Gleixner for the suggestions they made...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
---
This patch has been reworked against the 2.6.21 clockevents framework.
It has only been tested on the Book E 32-bit CPU this time, so re-testing on
"classic" PowerPC CPUs is needed (used to work as of 2.6.18-rt7)...
CONFIG_PPC_MULTIPLATFORM was the best option I was able to come up with
to cover machines built on 970 series CPUs...
arch/powerpc/Kconfig | 12 +++-
arch/powerpc/kernel/time.c | 124 ++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 134 insertions(+), 2 deletions(-)
Index: linux-2.6/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/Kconfig
+++ linux-2.6/arch/powerpc/Kconfig
@@ -317,7 +317,7 @@ config PPC_STD_MMU_32
config VIRT_CPU_ACCOUNTING
bool "Deterministic task and CPU time accounting"
- depends on PPC64
+ depends on PPC64 && !GENERIC_CLOCKEVENTS
default y
help
Select this option to enable more accurate task and CPU time
@@ -760,6 +760,16 @@ config HIGHMEM
depends on PPC32
source kernel/Kconfig.hz
+
+config GENERIC_CLOCKEVENTS
+ bool "Clock event devices support"
+ default n
+ help
+ Enable support for the clock event devices necessary for the
+ high-resolution timers and the tickless system support.
+ NOTE: This is not compatible with the deterministic time accounting
+ option on PPC64.
+
source kernel/Kconfig.preempt
config RWSEM_GENERIC_SPINLOCK
Index: linux-2.6/arch/powerpc/kernel/time.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/time.c
+++ linux-2.6/arch/powerpc/kernel/time.c
@@ -52,6 +52,7 @@
#include <linux/jiffies.h>
#include <linux/posix-timers.h>
#include <linux/irq.h>
+#include <linux/clockchips.h>
#include <asm/io.h>
#include <asm/processor.h>
@@ -128,6 +129,83 @@ unsigned long ppc_tb_freq;
static u64 tb_last_jiffy __cacheline_aligned_in_smp;
static DEFINE_PER_CPU(u64, last_jiffy);
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+#define DECREMENTER_MAX 0xffffffff
+#else
+#define DECREMENTER_MAX 0x7fffffff /* setting MSB triggers an interrupt */
+#endif
+
+static int decrementer_set_next_event(unsigned long evt,
+ struct clock_event_device *dev)
+{
+#if defined(CONFIG_40x)
+ mtspr(SPRN_PIT, evt); /* 40x has a hidden PIT auto-reload register */
+#elif defined(CONFIG_BOOKE)
+ mtspr(SPRN_DECAR, evt); /* Book E has separate auto-reload register */
+ set_dec(evt);
+#else
+ set_dec(evt - 1); /* Classic decrementer interrupts at -1 */
+#endif
+ return 0;
+}
+
+static void decrementer_set_mode(enum clock_event_mode mode,
+ struct clock_event_device *dev)
+{
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+ u32 tcr = mfspr(SPRN_TCR);
+
+ tcr |= TCR_DIE;
+ switch (mode) {
+ case CLOCK_EVT_MODE_PERIODIC:
+ tcr |= TCR_ARE;
+ break;
+ case CLOCK_EVT_MODE_ONESHOT:
+ tcr &= ~TCR_ARE;
+ break;
+ case CLOCK_EVT_MODE_UNUSED:
+ case CLOCK_EVT_MODE_SHUTDOWN:
+ tcr &= ~TCR_DIE;
+ break;
+ }
+ mtspr(SPRN_TCR, tcr);
+#endif
+ if (mode == CLOCK_EVT_MODE_PERIODIC)
+ decrementer_set_next_event(tb_ticks_per_jiffy, dev);
+}
+
+static struct clock_event_device decrementer_clockevent = {
+ .name = "decrementer",
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+ .features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC,
+#else
+ .features = CLOCK_EVT_FEAT_ONESHOT,
+#endif
+ .shift = 32,
+ .rating = 200,
+ .irq = -1,
+ .set_next_event = decrementer_set_next_event,
+ .set_mode = decrementer_set_mode,
+};
+
+static DEFINE_PER_CPU(struct clock_event_device, decrementers);
+
+static void register_decrementer(void)
+{
+ int cpu = smp_processor_id();
+ struct clock_event_device *decrementer = &per_cpu(decrementers, cpu);
+
+ memcpy(decrementer, &decrementer_clockevent, sizeof(*decrementer));
+
+ decrementer->cpumask = cpumask_of_cpu(cpu);
+
+ clockevents_register_device(decrementer);
+}
+
+#endif /* CONFIG_GENERIC_CLOCKEVENTS */
+
#ifdef CONFIG_VIRT_CPU_ACCOUNTING
/*
* Factors for converting from cputime_t (timebase ticks) to
@@ -313,6 +391,9 @@ void snapshot_timebase(void)
{
__get_cpu_var(last_jiffy) = get_tb();
snapshot_purr();
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+ register_decrementer();
+#endif
}
void __delay(unsigned long loops)
@@ -470,7 +551,31 @@ void timer_interrupt(struct pt_regs * re
old_regs = set_irq_regs(regs);
irq_enter();
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+#ifdef CONFIG_PPC_MULTIPLATFORM
+ /*
+ * We must write a positive value to the decrementer to clear
+ * the interrupt on the IBM 970 CPU series. In periodic mode,
+ * this happens when the decrementer gets reloaded later, but
+ * in one-shot mode, we have to do it here since an event handler
+ * may skip loading the new value...
+ */
+ if (per_cpu(decrementers, cpu).mode != CLOCK_EVT_MODE_PERIODIC)
+ set_dec(DECREMENTER_MAX);
+#endif
+ /*
+ * We can't disable the decrementer, so in the period between
+ * CPU being marked offline and calling stop-self, it's taking
+ * timer interrupts...
+ */
+ if (!cpu_is_offline(cpu)) {
+ struct clock_event_device *dev = &per_cpu(decrementers, cpu);
+
+ dev->event_handler(dev);
+ }
+#else
profile_tick(CPU_PROFILING);
+#endif
calculate_steal_time();
#ifdef CONFIG_PPC_ISERIES
@@ -486,6 +591,7 @@ void timer_interrupt(struct pt_regs * re
if (__USE_RTC() && per_cpu(last_jiffy, cpu) >= 1000000000)
per_cpu(last_jiffy, cpu) -= 1000000000;
+#ifndef CONFIG_GENERIC_CLOCKEVENTS
/*
* We cannot disable the decrementer, so in the period
* between this cpu's being marked offline in cpu_online_map
@@ -495,6 +601,7 @@ void timer_interrupt(struct pt_regs * re
*/
if (!cpu_is_offline(cpu))
account_process_time(regs);
+#endif
/*
* No need to check whether cpu is offline here; boot_cpuid
@@ -507,15 +614,19 @@ void timer_interrupt(struct pt_regs * re
tb_next_jiffy = tb_last_jiffy + tb_ticks_per_jiffy;
if (per_cpu(last_jiffy, cpu) >= tb_next_jiffy) {
tb_last_jiffy = tb_next_jiffy;
+#ifndef CONFIG_GENERIC_CLOCKEVENTS
do_timer(1);
+#endif
/*timer_recalc_offset(tb_last_jiffy);*/
timer_check_rtc();
}
write_sequnlock(&xtime_lock);
}
-
+
+#ifndef CONFIG_GENERIC_CLOCKEVENTS
next_dec = tb_ticks_per_jiffy - ticks;
set_dec(next_dec);
+#endif
#ifdef CONFIG_PPC_ISERIES
if (firmware_has_feature(FW_FEATURE_ISERIES) && hvlpevent_is_pending())
@@ -770,8 +881,19 @@ void __init time_init(void)
-xtime.tv_sec, -xtime.tv_nsec);
write_sequnlock_irqrestore(&xtime_lock, flags);
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+ decrementer_clockevent.mult = div_sc(ppc_tb_freq, NSEC_PER_SEC,
+ decrementer_clockevent.shift);
+ decrementer_clockevent.max_delta_ns =
+ clockevent_delta2ns(DECREMENTER_MAX, &decrementer_clockevent);
+ decrementer_clockevent.min_delta_ns =
+ clockevent_delta2ns(0xf, &decrementer_clockevent);
+
+ register_decrementer();
+#else
/* Not exact, but the timer interrupt takes care of this */
set_dec(tb_ticks_per_jiffy);
+#endif
}
#define FEBRUARY 2
^ permalink raw reply
* Re: Resending: RT patches expose netdev race [was Re: [RFC] [patch 2/2] powerpc 2.6.21-rt1: fix kernel hang and/or panic
From: Linas Vepstas @ 2007-05-17 17:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-kernel, cbe-oss-dev, linuxppc-dev, netdev, mingo, tglx
In-Reply-To: <1179362985.32247.252.camel@localhost.localdomain>
On Thu, May 17, 2007 at 10:49:45AM +1000, Benjamin Herrenschmidt wrote:
>
> > I do not know why sk_buff->head would be null, or
> > would be set in a racy kind of way, or why the rt patches
> > would cause this. But the evidence implicates that.
>
> Would it be possible that a locking bug in spidernet would cause it
> under some circumstances to get a stale skb pointer ?
The skb pointer should be brand-spanking new/fresh.
It is passed to spidernet by the netdev->hard_start_xmit
callback:
netdev->hard_start_xmit = &spider_net_xmit;
I'd expect that anything that hard_start_xmit() passed to
a device driver should have a fully valid skb. Locking
problems in spidernet could cause it to work with the wrong
skb; however, in this case, the skb pointer is passed
unmodified, directly to the spot where it fails.
Maybe there is some "make ip header fresh and clean on skb" call
that should have been made; if so, I don't know what it is.
--linas
^ permalink raw reply
* Re: [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Kumar Gala @ 2007-05-17 17:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, i2c
In-Reply-To: <464C871C.4090300@freescale.com>
On May 17, 2007, at 11:47 AM, Scott Wood wrote:
> Kumar Gala wrote:
>> On May 17, 2007, at 11:17 AM, Scott Wood wrote:
>>> Kumar Gala wrote:
>>>> As I've stated before, we need a bus number as well so we can
>>>> handle things like I2C switches and muxes.
>>>
>>> Is this something we handle now? If not, then it's really not
>>> within the scope of this patchset. If so, how am I breaking it?
>> We don't handle i2c devices in the dev tree today. If you are
>> going to propose a solution it should work for all cases that
>> people are aware of even if linux doesn't support the functionality.
>
> But we do handle i2c *controllers* in the device tree, and that's
> where a bus number property would go. Given that we don't have a
> binding for non-toplevel i2c buses, and I'm not adding one, I don't
> see the relevance. Note that adding a bus number property makes
> zero sense for toplevel buses, as at that level the bus number is
> just a fiction maintained by Linux for user API and device
> preregistration purposes.
The only support we have for i2c controllers is to support one
specific i2c controller from Freescale.
If you aren't going to provide a complete solution why are you
prosing one? I'm tired of this put stuff in the device tree but only
as much as I need to do my particular thing. The device tree is just
as important an interface point as the kernel/user space interfaces
and we should treat it as such. If people aren't willing to work to
a complete solution than they should stop proposing changes.
> It's not a matter of the binding only covering some cases; it's a
> matter of the binding being for one thing (i2c devices) and not
> another (multiplexed i2c buses).
But once you introduce the concept of i2c devices you introduce the
possibility of hierarchies. For example, tell me how I'd describe
the following device http://www.nxp.com/pip/PCA9548ABS.html and any
i2c devices connected to it?
>> If only some subset of cases are handled what good is the device
>> tree to a user? They will just have to figure out if their usage
>> is supported or not and if not find some other solution that
>> works for them.
>
> ...just as they'll have to figure out if a binding exists for
> device type $FOO.
True, but if I go look at the PCI OF spec I have some faith that its
complete and will cover my needs.
As I've been thinking about this I think trying to even describe i2c
devices in the device tree is point less. Since I2C devices have no
way of uniquely identifying themselves we are looking at taking on
the role of device name registrar and if someone is willing to do
that great, but I doubt anyone truly is.
- k
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Wade Farnsworth @ 2007-05-17 16:58 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <744CD970-5421-47D6-A30A-C7C79BE21BE8@kernel.crashing.org>
On Thu, 2007-05-17 at 11:14 -0500, Kumar Gala wrote:
> On May 17, 2007, at 11:03 AM, Wade Farnsworth wrote:
>
> > On Thu, 2007-05-17 at 10:50 +0800, Zhang Wei-r63237 wrote:
> >> Hi,
> >>
> >> If you add below sector to pci@8000, please remove the interrupt-map
> >> sector from pci@8000.
> >
> > Correct me if I'm wrong, but I think if the interrupt-map for pci@8000
> > is removed then the pci devices on the revision 1.0 board will not get
> > the correct interrupts. I don't currently have a rev 1.0 to test
> > though. Can someone with a rev 1.0 HPCN board confirm this?
>
> If I'm understanding things this might best be handled by two
> different dts. Is this because of board changes or chip/silicon
> changes?
>
> - k
>
Yes. On rev 1.0 boards, all of the devices on the south bridge are on
bus 0, while on rev 1.02, the devices on the southbridge are on bus 2.
I'd like to use the same dts for both rev's if possible. But if there
is a reason why they shouldn't, I suppose I could create a separate dts.
--Wade
^ permalink raw reply
* Re: [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Scott Wood @ 2007-05-17 16:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, i2c
In-Reply-To: <FFBD3A3A-ADBE-4DC8-A1A1-4163367244D5@kernel.crashing.org>
Kumar Gala wrote:
> On May 17, 2007, at 11:17 AM, Scott Wood wrote:
>> Kumar Gala wrote:
>>> As I've stated before, we need a bus number as well so we can
>>> handle things like I2C switches and muxes.
>>
>> Is this something we handle now? If not, then it's really not within
>> the scope of this patchset. If so, how am I breaking it?
>
> We don't handle i2c devices in the dev tree today. If you are going to
> propose a solution it should work for all cases that people are aware
> of even if linux doesn't support the functionality.
But we do handle i2c *controllers* in the device tree, and that's where
a bus number property would go. Given that we don't have a binding for
non-toplevel i2c buses, and I'm not adding one, I don't see the
relevance. Note that adding a bus number property makes zero sense for
toplevel buses, as at that level the bus number is just a fiction
maintained by Linux for user API and device preregistration purposes.
It's not a matter of the binding only covering some cases; it's a matter
of the binding being for one thing (i2c devices) and not another
(multiplexed i2c buses).
> If only some subset of cases are handled what good is the device tree
> to a user? They will just have to figure out if their usage is
> supported or not and if not find some other solution that works for them.
...just as they'll have to figure out if a binding exists for device
type $FOO.
-Scott
^ permalink raw reply
* Re: eeh bug
From: Linas Vepstas @ 2007-05-17 16:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1179377946.32247.281.camel@localhost.localdomain>
On Thu, May 17, 2007 at 02:59:06PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2007-05-17 at 14:46 +1000, Benjamin Herrenschmidt wrote:
> >
> > When an RTAS PCI config space call returns all f's, we do an eeh error
> > check by calling eeh_dn_check_failure(pdn->node, NULL);
> >
> > The problem is that second argument... NULL for the pci_dev *. It looks
> > like the EEH code will try to printk pci_name of that and later on
> > dereference it within eehd, thus causing an oops.
>
> Ok, so I just added a
>
> if (dev == NULL)
> dev = pdn->pcidev;
>
> To eeh_dn_check_failure(), and that fixes one of the NULL (name
> printing), but I get another one a bit later, in pci_find_capability
> called from eeh_slot_error_detail called from handle_eeh_events.
> (Probably in gather_pci_data).
OK, clearly I have been sloppy. The initial eeh design used pci_dev
for everything; and as time went on, I realized that the device node
made a better fit for what needed to be manipulated. So the code
migrated in that direction, but not unambiguously; it tried to
keep allegience to both ways of identifying a slot.
> One thing that looks suspicions is that just before that I see:
>
> EEH: of node=/pci/@8000000200000d3/pci@2,4
>
> Which is not a device but the bridge above it...
That's the "partition endpoint", which is what the firmware wants.
There's some ambiguity, as older systems with EADS and newer
direct-attached P5IOC slots have different relationships between
the "partition endpoint", the device, the slot, the bridge and
PHB; which of these are equivalent and which are subordinate
can be confusing.
> we should probably not sure
> pci_find_capability in that code anyway and implent our own version
> using RTAS in case we don't have a pci_dev around, don't you think ?
I'll take a look. Usually, there's no pci_dev only when its a slot
with no device plugged into it; these can still receive EEH errors
during config space i/o to the bridge (I presume that the justification
is when aluminum scrap shorts out a pci connector or something like
that). In all other cases, there's a pci_dev, which is why the
bug slipped by.
--linas
>
^ permalink raw reply
* Re: [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Kumar Gala @ 2007-05-17 16:39 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, i2c
In-Reply-To: <464C800C.20400@freescale.com>
On May 17, 2007, at 11:17 AM, Scott Wood wrote:
> Kumar Gala wrote:
>>> diff --git a/Documentation/powerpc/booting-without-of.txt b/
>>> Documentation/powerpc/booting-without-of.txt
>>> index b49ce16..67026ad 100644
>>> --- a/Documentation/powerpc/booting-without-of.txt
>>> +++ b/Documentation/powerpc/booting-without-of.txt
>>> @@ -1257,6 +1257,8 @@ platforms are moved over to use the
>>> flattened- device-tree model.
>>>
>>> e) I2C
>>>
>>> + e1) I2C Controller
>>> +
>>> Required properties :
>>>
>>> - device_type : Should be "i2c"
>>> @@ -1277,6 +1279,10 @@ platforms are moved over to use the
>>> flattened-device-tree model.
>>> a digital filter sampling rate register
>>> - fsl5200-clocking : boolean; if defined, indicated that
>>> this device
>>> uses the FSL 5200 clocking mechanism.
>>> + - #address-cells : should exist and be 1 if I2C devices are
>>> declared
>>> + in the device tree.
>>> + - #size-cells : should exist and be 0 if I2C devices are
>>> declared
>>> + in the device tree.
>> As I've stated before, we need a bus number as well so we can
>> handle things like I2C switches and muxes.
>
> Is this something we handle now? If not, then it's really not
> within the scope of this patchset. If so, how am I breaking it?
We don't handle i2c devices in the dev tree today. If you are going
to propose a solution it should work for all cases that people are
aware of even if linux doesn't support the functionality.
If only some subset of cases are handled what good is the device tree
to a user? They will just have to figure out if their usage is
supported or not and if not find some other solution that works for
them.
- k
^ permalink raw reply
* Re: [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Scott Wood @ 2007-05-17 16:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, i2c
In-Reply-To: <FB8DD3C1-A095-4ABB-9E74-7EC66A43D983@kernel.crashing.org>
Kumar Gala wrote:
>> diff --git a/Documentation/powerpc/booting-without-of.txt b/
>> Documentation/powerpc/booting-without-of.txt
>> index b49ce16..67026ad 100644
>> --- a/Documentation/powerpc/booting-without-of.txt
>> +++ b/Documentation/powerpc/booting-without-of.txt
>> @@ -1257,6 +1257,8 @@ platforms are moved over to use the flattened-
>> device-tree model.
>>
>> e) I2C
>>
>> + e1) I2C Controller
>> +
>> Required properties :
>>
>> - device_type : Should be "i2c"
>> @@ -1277,6 +1279,10 @@ platforms are moved over to use the
>> flattened-device-tree model.
>> a digital filter sampling rate register
>> - fsl5200-clocking : boolean; if defined, indicated that this
>> device
>> uses the FSL 5200 clocking mechanism.
>> + - #address-cells : should exist and be 1 if I2C devices are
>> declared
>> + in the device tree.
>> + - #size-cells : should exist and be 0 if I2C devices are declared
>> + in the device tree.
>
>
> As I've stated before, we need a bus number as well so we can handle
> things like I2C switches and muxes.
Is this something we handle now? If not, then it's really not within
the scope of this patchset. If so, how am I breaking it?
-Scott
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Kumar Gala @ 2007-05-17 16:14 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <1179417813.8132.250.camel@rhino>
On May 17, 2007, at 11:03 AM, Wade Farnsworth wrote:
> On Thu, 2007-05-17 at 10:50 +0800, Zhang Wei-r63237 wrote:
>> Hi,
>>
>> If you add below sector to pci@8000, please remove the interrupt-map
>> sector from pci@8000.
>
> Correct me if I'm wrong, but I think if the interrupt-map for pci@8000
> is removed then the pci devices on the revision 1.0 board will not get
> the correct interrupts. I don't currently have a rev 1.0 to test
> though. Can someone with a rev 1.0 HPCN board confirm this?
If I'm understanding things this might best be handled by two
different dts. Is this because of board changes or chip/silicon
changes?
- k
^ permalink raw reply
* Re: [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Kumar Gala @ 2007-05-17 16:12 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, i2c
In-Reply-To: <20070517143846.GC29795@ld0162-tx32.am.freescale.net>
On May 17, 2007, at 9:38 AM, Scott Wood wrote:
> Document the use of device trees to describe devices on an I2C bus,
> which
> will be used with David Brownell's "new style" I2C binding patches.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> Documentation/powerpc/booting-without-of.txt | 34 +++++++++++++++
> +++++++++++
> 1 files changed, 34 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/
> Documentation/powerpc/booting-without-of.txt
> index b49ce16..67026ad 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -1257,6 +1257,8 @@ platforms are moved over to use the flattened-
> device-tree model.
>
> e) I2C
>
> + e1) I2C Controller
> +
> Required properties :
>
> - device_type : Should be "i2c"
> @@ -1277,6 +1279,10 @@ platforms are moved over to use the
> flattened-device-tree model.
> a digital filter sampling rate register
> - fsl5200-clocking : boolean; if defined, indicated that this
> device
> uses the FSL 5200 clocking mechanism.
> + - #address-cells : should exist and be 1 if I2C devices are
> declared
> + in the device tree.
> + - #size-cells : should exist and be 0 if I2C devices are declared
> + in the device tree.
As I've stated before, we need a bus number as well so we can handle
things like I2C switches and muxes.
- k
^ 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