* Re: [PATCH 1/3] [WATCHDOG] mpc83xx_wdt: add support for MPC86xx CPUs
From: Kumar Gala @ 2008-05-13 1:06 UTC (permalink / raw)
To: cbouatmailru; +Cc: Scott Wood, linuxppc-dev, Wim Van Sebroeck, Timur Tabi
In-Reply-To: <20080512221243.GA1536@zarina>
On May 12, 2008, at 5:12 PM, Anton Vorontsov wrote:
> On Mon, May 12, 2008 at 04:55:16PM -0500, Timur Tabi wrote:
>> Anton Vorontsov wrote:
>>
>>> I don't know the IP block name... what is it for the 83xx/86xx
>>> watchdogs?
>>
>> My point was that we developers should just pick a name and run
>> with it.
>> That's where the name "Elo" came from. None of official Freescale
>> documentation calls the DMA controller on 85xx parts "Elo", but the
>> kernel code does.
>
> Ahh, I see. Ok, my purpose: name the driver for mpc83xx-like watchdogs
> as mpc83xx_wdt.c? :-)
>
> It's less confusion. For example DMA. I really don't know what the
> "Elo" is. Nobody does actually, except the few people who discussed
> Linux Freescale DMA drivers...
I repeat, name it mpc8xxx_wdt.c or fsl_ppc_soc_wdt.c.
- k
^ permalink raw reply
* [PATCH 2/2]: lmb: Make lmb debugging more useful.
From: David Miller @ 2008-05-13 0:41 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mikpe, paulus, linux-kernel
Having to muck with the build and set DEBUG just to
get lmb_dump_all() to print things isn't very useful.
So use pr_info() and use an early boot param
"lmb=debug" so we can simply ask users to reboot
with this option when we need some debugging from
them.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
lib/lmb.c | 33 ++++++++++++++++++++++-----------
1 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/lib/lmb.c b/lib/lmb.c
index 93445dc..867f7b5 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -19,31 +19,42 @@
struct lmb lmb;
+static int lmb_debug;
+
+static int __init early_lmb(char *p)
+{
+ if (p && strstr(p, "debug"))
+ lmb_debug = 1;
+ return 0;
+}
+early_param("lmb", early_lmb);
+
void lmb_dump_all(void)
{
-#ifdef DEBUG
unsigned long i;
- pr_debug("lmb_dump_all:\n");
- pr_debug(" memory.cnt = 0x%lx\n", lmb.memory.cnt);
- pr_debug(" memory.size = 0x%llx\n",
+ if (!lmb_debug)
+ return;
+
+ pr_info("lmb_dump_all:\n");
+ pr_info(" memory.cnt = 0x%lx\n", lmb.memory.cnt);
+ pr_info(" memory.size = 0x%llx\n",
(unsigned long long)lmb.memory.size);
for (i=0; i < lmb.memory.cnt ;i++) {
- pr_debug(" memory.region[0x%x].base = 0x%llx\n",
+ pr_info(" memory.region[0x%lx].base = 0x%llx\n",
i, (unsigned long long)lmb.memory.region[i].base);
- pr_debug(" .size = 0x%llx\n",
+ pr_info(" .size = 0x%llx\n",
(unsigned long long)lmb.memory.region[i].size);
}
- pr_debug(" reserved.cnt = 0x%lx\n", lmb.reserved.cnt);
- pr_debug(" reserved.size = 0x%lx\n", lmb.reserved.size);
+ pr_info(" reserved.cnt = 0x%lx\n", lmb.reserved.cnt);
+ pr_info(" reserved.size = 0x%lx\n", lmb.reserved.size);
for (i=0; i < lmb.reserved.cnt ;i++) {
- pr_debug(" reserved.region[0x%x].base = 0x%llx\n",
+ pr_info(" reserved.region[0x%lx].base = 0x%llx\n",
i, (unsigned long long)lmb.reserved.region[i].base);
- pr_debug(" .size = 0x%llx\n",
+ pr_info(" .size = 0x%llx\n",
(unsigned long long)lmb.reserved.region[i].size);
}
-#endif /* DEBUG */
}
static unsigned long lmb_addrs_overlap(u64 base1, u64 size1, u64 base2,
--
1.5.5.1.57.g5909c
^ permalink raw reply related
* [PATCH 1/2]: lmb: Fix inconsistent alignment of size argument.
From: David Miller @ 2008-05-13 0:41 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mikpe, paulus, linux-kernel
When allocating, if we will align up the size when making
the reservation, we should also align the size for the
check that the space is actually available.
The simplest thing is to just aling the size up from
the beginning, then we can use plain 'size' throughout.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
lib/lmb.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/lib/lmb.c b/lib/lmb.c
index 83287d3..93445dc 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -286,8 +286,7 @@ static u64 __init lmb_alloc_nid_unreserved(u64 start, u64 end,
j = lmb_overlaps_region(&lmb.reserved, base, size);
if (j < 0) {
/* this area isn't reserved, take it */
- if (lmb_add_region(&lmb.reserved, base,
- lmb_align_up(size, align)) < 0)
+ if (lmb_add_region(&lmb.reserved, base, size) < 0)
base = ~(u64)0;
return base;
}
@@ -333,6 +332,10 @@ u64 __init lmb_alloc_nid(u64 size, u64 align, int nid,
struct lmb_region *mem = &lmb.memory;
int i;
+ BUG_ON(0 == size);
+
+ size = lmb_align_up(size, align);
+
for (i = 0; i < mem->cnt; i++) {
u64 ret = lmb_alloc_nid_region(&mem->region[i],
nid_range,
@@ -370,6 +373,8 @@ u64 __init __lmb_alloc_base(u64 size, u64 align, u64 max_addr)
BUG_ON(0 == size);
+ size = lmb_align_up(size, align);
+
/* On some platforms, make sure we allocate lowmem */
/* Note that LMB_REAL_LIMIT may be LMB_ALLOC_ANYWHERE */
if (max_addr == LMB_ALLOC_ANYWHERE)
@@ -393,8 +398,7 @@ u64 __init __lmb_alloc_base(u64 size, u64 align, u64 max_addr)
j = lmb_overlaps_region(&lmb.reserved, base, size);
if (j < 0) {
/* this area isn't reserved, take it */
- if (lmb_add_region(&lmb.reserved, base,
- lmb_align_up(size, align)) < 0)
+ if (lmb_add_region(&lmb.reserved, base, size) < 0)
return 0;
return base;
}
--
1.5.5.1.57.g5909c
^ permalink raw reply related
* [PATCH 0/2]: LMB small bug fix and debugging tidy up.
From: David Miller @ 2008-05-13 0:41 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mikpe, paulus, linux-kernel
While diagnosing Mikael's bug where half of his RAM disappeared
in 2.6.26-rc2 I found one bug (which I don't think fixes his
problem, but waiting for an updated set of debugging logs from
him) and an improvement to the debugging provided by the current
LMB code.
^ permalink raw reply
* Re: [PATCH 5/5] [PPC] provide walk_memory_resource() for ppc
From: Geoff Levand @ 2008-05-13 0:17 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: linuxppc-dev, paulus, lkml, Yasunori Goto
In-Reply-To: <1206664795.19368.13.camel@dyn9047017100.beaverton.ibm.com>
Hi,
I've had some trouble with this change.
Badari Pulavarty wrote:
> Provide walk_memory_resource() for ppc64. PPC maintains
> logic memory region mapping in lmb.memory structures. Walk
> through these structures and do the callbacks for the
> contiguous chunks.
...
> --- linux-2.6.25-rc3.orig/arch/powerpc/mm/mem.c 2008-03-05 10:14:28.000000000 -0800
> +++ linux-2.6.25-rc3/arch/powerpc/mm/mem.c 2008-03-05 10:32:16.000000000 -0800
> @@ -148,19 +148,35 @@ out:
>
> /*
> * walk_memory_resource() needs to make sure there is no holes in a given
> - * memory range. On PPC64, since this range comes from /sysfs, the range
> - * is guaranteed to be valid, non-overlapping and can not contain any
> - * holes. By the time we get here (memory add or remove), /proc/device-tree
> - * is updated and correct. Only reason we need to check against device-tree
> - * would be if we allow user-land to specify a memory range through a
> - * system call/ioctl etc. instead of doing offline/online through /sysfs.
> + * memory range. PPC64 does not maintain the memory layout in /proc/iomem.
> + * Instead it maintains it in lmb.memory structures. Walk through the
> + * memory regions, find holes and callback for contiguous regions.
> */
> int
> walk_memory_resource(unsigned long start_pfn, unsigned long nr_pages, void *arg,
> int (*func)(unsigned long, unsigned long, void *))
> {
> - return (*func)(start_pfn, nr_pages, arg);
> + struct lmb_property res;
> + unsigned long pfn, len;
> + u64 end;
> + int ret = -1;
> +
> + res.base = (u64) start_pfn << PAGE_SHIFT;
> + res.size = (u64) nr_pages << PAGE_SHIFT;
> +
> + end = res.base + res.size - 1;
> + while ((res.base < end) && (lmb_find(&res) >= 0)) {
^^^^^^^^^^^^^^
In the PS3 platform code (arch/pwerpc/platfroms/ps3/mm.c) the hotplug
memory is added like this:
...
result = add_memory(0, start_addr, map.r1.size);
...
result = online_pages(start_pfn, nr_pages);
...
In its work, online_pages() eventually calls walk_memory_resource(),
which has been changed as above to do a test on lmb_find(). I found
that this lmb_find() test always fails for PS3 since add_memory()
does not call lmb_add().
Is it the responsibility of the platform code to call lmb_add(), or
should that be done by add_memory()?
-Geoff
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] 86xx: mpc8610_hpcd: add watchdog node
From: Segher Boessenkool @ 2008-05-12 22:23 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Wim Van Sebroeck, Timur Tabi
In-Reply-To: <20080512185217.GC25818@polina.dev.rtsoft.ru>
> + compatible = "mpc83xx_wdt", "fsl,mpc8610-wdt";
You should put the most specific entry first.
Segher
^ permalink raw reply
* Re: [PATCH 1/3] [WATCHDOG] mpc83xx_wdt: add support for MPC86xx CPUs
From: Anton Vorontsov @ 2008-05-12 22:12 UTC (permalink / raw)
To: Timur Tabi; +Cc: Scott Wood, linuxppc-dev, Wim Van Sebroeck
In-Reply-To: <4828BCC4.3030308@freescale.com>
On Mon, May 12, 2008 at 04:55:16PM -0500, Timur Tabi wrote:
> Anton Vorontsov wrote:
>
>> I don't know the IP block name... what is it for the 83xx/86xx
>> watchdogs?
>
> My point was that we developers should just pick a name and run with it.
> That's where the name "Elo" came from. None of official Freescale
> documentation calls the DMA controller on 85xx parts "Elo", but the
> kernel code does.
Ahh, I see. Ok, my purpose: name the driver for mpc83xx-like watchdogs
as mpc83xx_wdt.c? :-)
It's less confusion. For example DMA. I really don't know what the
"Elo" is. Nobody does actually, except the few people who discussed
Linux Freescale DMA drivers...
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 1/3] [WATCHDOG] mpc83xx_wdt: add support for MPC86xx CPUs
From: Timur Tabi @ 2008-05-12 21:55 UTC (permalink / raw)
To: cbouatmailru; +Cc: Scott Wood, linuxppc-dev, Wim Van Sebroeck
In-Reply-To: <20080512214858.GA30803@zarina>
Anton Vorontsov wrote:
> I don't know the IP block name... what is it for the 83xx/86xx
> watchdogs?
My point was that we developers should just pick a name and run with it.
That's where the name "Elo" came from. None of official Freescale
documentation calls the DMA controller on 85xx parts "Elo", but the
kernel code does.
^ permalink raw reply
* Re: [PATCH 1/3] [WATCHDOG] mpc83xx_wdt: add support for MPC86xx CPUs
From: Anton Vorontsov @ 2008-05-12 21:48 UTC (permalink / raw)
To: Timur Tabi; +Cc: Scott Wood, linuxppc-dev, Wim Van Sebroeck
In-Reply-To: <4828B9D1.9040106@freescale.com>
On Mon, May 12, 2008 at 04:42:41PM -0500, Timur Tabi wrote:
> Anton Vorontsov wrote:
>
>> They're completely different watchdogs...
>
> But the drivers both generally do the same thing, just with different
> timers?
All the watchdogs do the same thing, generally...
> I think the best option is to just pick a name for the IP block that
> mpc83xx_wdt.c supports and use that name for the driver as well.
I don't know the IP block name... what is it for the 83xx/86xx
watchdogs?
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 1/3] [WATCHDOG] mpc83xx_wdt: add support for MPC86xx CPUs
From: Timur Tabi @ 2008-05-12 21:42 UTC (permalink / raw)
To: cbouatmailru; +Cc: Scott Wood, linuxppc-dev, Wim Van Sebroeck
In-Reply-To: <20080512213529.GA27087@zarina>
Anton Vorontsov wrote:
> They're completely different watchdogs...
But the drivers both generally do the same thing, just with different
timers?
I think the best option is to just pick a name for the IP block that
mpc83xx_wdt.c supports and use that name for the driver as well.
^ permalink raw reply
* Re: [PATCH 1/3] [WATCHDOG] mpc83xx_wdt: add support for MPC86xx CPUs
From: Anton Vorontsov @ 2008-05-12 21:35 UTC (permalink / raw)
To: Timur Tabi; +Cc: Scott Wood, linuxppc-dev, Wim Van Sebroeck
In-Reply-To: <4828B4BB.2020403@freescale.com>
On Mon, May 12, 2008 at 04:20:59PM -0500, Timur Tabi wrote:
> Anton Vorontsov wrote:
>> On Mon, May 12, 2008 at 04:01:06PM -0500, Timur Tabi wrote:
>>> Scott Wood wrote:
>>>
>>>> It avoids confusion. I vote for renaming.
>>> Me too. How about fsl_wdt.c?
>>
>> fsl_wdt sounds too generic, I think it would conflict with
>> at least booke_wdt.c.. no?
>
> Yeah, that makes sense. What's the difference between booke_wdt.c and
> mpc83xx_wdt.c?
They're completely different watchdogs...
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 1/3] [WATCHDOG] mpc83xx_wdt: add support for MPC86xx CPUs
From: Timur Tabi @ 2008-05-12 21:20 UTC (permalink / raw)
To: cbouatmailru; +Cc: Scott Wood, linuxppc-dev, Wim Van Sebroeck
In-Reply-To: <20080512211856.GA21532@zarina>
Anton Vorontsov wrote:
> On Mon, May 12, 2008 at 04:01:06PM -0500, Timur Tabi wrote:
>> Scott Wood wrote:
>>
>>> It avoids confusion. I vote for renaming.
>> Me too. How about fsl_wdt.c?
>
> fsl_wdt sounds too generic, I think it would conflict with
> at least booke_wdt.c.. no?
Yeah, that makes sense. What's the difference between booke_wdt.c and
mpc83xx_wdt.c?
^ permalink raw reply
* Re: [PATCH 1/3] [WATCHDOG] mpc83xx_wdt: add support for MPC86xx CPUs
From: Anton Vorontsov @ 2008-05-12 21:18 UTC (permalink / raw)
To: Timur Tabi; +Cc: Scott Wood, linuxppc-dev, Wim Van Sebroeck
In-Reply-To: <4828B012.9090805@freescale.com>
On Mon, May 12, 2008 at 04:01:06PM -0500, Timur Tabi wrote:
> Scott Wood wrote:
>
>> It avoids confusion. I vote for renaming.
>
> Me too. How about fsl_wdt.c?
fsl_wdt sounds too generic, I think it would conflict with
at least booke_wdt.c.. no?
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 1/3] [WATCHDOG] mpc83xx_wdt: add support for MPC86xx CPUs
From: Timur Tabi @ 2008-05-12 21:01 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Wim Van Sebroeck
In-Reply-To: <4828AFBD.1040501@freescale.com>
Scott Wood wrote:
> It avoids confusion. I vote for renaming.
Me too. How about fsl_wdt.c?
Or we could come up with a name for that particular WDT device, like we
did with the 85xx DMA controller.
^ permalink raw reply
* Re: [PATCH 1/3] [WATCHDOG] mpc83xx_wdt: add support for MPC86xx CPUs
From: Scott Wood @ 2008-05-12 20:59 UTC (permalink / raw)
To: cbouatmailru; +Cc: linuxppc-dev, Wim Van Sebroeck, Timur Tabi
In-Reply-To: <20080512205303.GA14198@zarina>
Anton Vorontsov wrote:
> On Mon, May 12, 2008 at 02:24:20PM -0500, Kumar Gala wrote:
>> we should rename it to mpc8xxx_wdt.c
>
> I don't see much sense in renaming the files just because the driver
> now supports another line of processors... Do you really want the rename?
> Please repeat if so.
>
It avoids confusion. I vote for renaming.
-Scott
^ permalink raw reply
* Re: [PATCH 1/3] [WATCHDOG] mpc83xx_wdt: add support for MPC86xx CPUs
From: Anton Vorontsov @ 2008-05-12 20:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Wim Van Sebroeck, Timur Tabi
In-Reply-To: <64629276-8337-4FFE-B3E1-306678BF179D@kernel.crashing.org>
On Mon, May 12, 2008 at 02:24:20PM -0500, Kumar Gala wrote:
>
> On May 12, 2008, at 1:52 PM, Anton Vorontsov wrote:
>
>> On MPC86xx the watchdog could be enabled only at power-on-reset, and
>> could not be disabled afterwards. We must ping the watchdog from the
>> kernel until the userspace handles it.
>>
>> MPC83xx CPUs are only differ in a way that watchdog could be disabled
>> once, but after it was enabled via software it becomes just the same
>> as MPC86xx.
>>
>> Thus, to support MPC86xx I added the kernel timer which pings the
>> watchdog until the userspace opens it.
>>
>> Since we implemented the timer, now we're able to implement proper
>> handling for the CONFIG_WATCHDOG_NOWAYOUT case, for MPC83xx and
>> MPC86xx.
>>
>> Also move the probe code into subsys_initcall, because we want start
>> pinging the watchdog ASAP, and misc devices are available in
>> subsys_initcall.
>>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>> ---
>> drivers/watchdog/Kconfig | 4 +-
>> drivers/watchdog/mpc83xx_wdt.c | 63 +++++++++++++++++++++++++++++++
>> +++++----
>
> we should rename it to mpc8xxx_wdt.c
I don't see much sense in renaming the files just because the driver
now supports another line of processors... Do you really want the rename?
Please repeat if so.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH] POWERPC: Fix uninitialized variable bug in copy_{to|from}_user
From: Nate Case @ 2008-05-12 20:14 UTC (permalink / raw)
To: linuxppc-dev
Calls to copy_to_user() or copy_from_user() can fail
when copying N bytes, where N is a constant less than 8,
but not 1, 2, 4, or 8.
Signed-off-by: Dave Scidmore <dscidmore@xes-inc.com>
Signed-off-by: Nate Case <ncase@xes-inc.com>
---
include/asm-powerpc/uaccess.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-powerpc/uaccess.h b/include/asm-powerpc/uaccess.h
index 8e798e3..1a0736f 100644
--- a/include/asm-powerpc/uaccess.h
+++ b/include/asm-powerpc/uaccess.h
@@ -380,7 +380,7 @@ static inline unsigned long __copy_from_user_inatomic(void *to,
const void __user *from, unsigned long n)
{
if (__builtin_constant_p(n) && (n <= 8)) {
- unsigned long ret;
+ unsigned long ret = 1;
switch (n) {
case 1:
@@ -406,7 +406,7 @@ static inline unsigned long __copy_to_user_inatomic(void __user *to,
const void *from, unsigned long n)
{
if (__builtin_constant_p(n) && (n <= 8)) {
- unsigned long ret;
+ unsigned long ret = 1;
switch (n) {
case 1:
--
1.5.4.4
^ permalink raw reply related
* RE: [PATCH] Xilinx: framebuffer: add compatibility for ml507 dvi core.
From: Stephen Neuendorffer @ 2008-05-12 19:59 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, git-dev
In-Reply-To: <fa686aa40805121246i68c42867k150c5f9e0082598f@mail.gmail.com>
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of
Grant Likely
> Sent: Monday, May 12, 2008 12:46 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org; git-dev
> Subject: Re: [PATCH] Xilinx: framebuffer: add compatibility for ml507
dvi core.
>=20
> On Mon, May 12, 2008 at 1:10 PM, Stephen Neuendorffer
> <stephen.neuendorffer@xilinx.com> wrote:
> >
> > The best possibility that I see is glopping the compatibility
> > information about what cores are compatible with which drivers and
> > generating something. This is moderately better than blindly
treating
> > all cores with the same major version as interface compatible, but
still
> > has the potential to blindly declare that core versions are
compatible
> > when they are not really compatible.
>=20
> That's okay, the device tree conventions provide for that uncertainty.
> If compatible includes both the *exact* version and the oldest known
> *compatible* version (the one the drivers know about) then we're in
> the situation where 99% of the time it just works. For the 1% of the
> time when mistakes are made we still have the necessary information to
> write exceptions in the code to work around bad data. This means code
> only needs to changes when mistakes are discovered, not for every IP
> core uprev.
My argument was that we should do this by truncating the major version,
which is also an established standard that cores *should* follow, but
you didn't like that. :) It makes at least as much sense as expressing
the compatibility of the driver in the tree in terms of compatibility
with some other random driver. In the case of the tft core in
particular, there *is* no other driver AFAIK.
> > I *really* don't want to put this into the device tree generator on
a
> > case-by-case basis, so unless there is something that can be
generated
> > from whatever meta-information EDK has, I think we're going to have
to
> > just have the explicit versions in the drivers for the time being.
>=20
> Can we post process the generated device tree with a table of known
> compatibility strings (or regexps) for adding the older compatible
> values? I don't expect the list will be particularly long or hard to
> maintain and the code to do so should be trivial.
Ug, that's just pushing the problem around.
This seems as much like an argument for putting wildcards in the
compatible bindings in the kernel as anything...
Steve
^ permalink raw reply
* Re: [PATCH] Xilinx: framebuffer: add compatibility for ml507 dvi core.
From: Grant Likely @ 2008-05-12 19:46 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, git-dev
In-Reply-To: <20080512191025.67682630064@mail160-dub.bigfish.com>
On Mon, May 12, 2008 at 1:10 PM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
>
> The best possibility that I see is glopping the compatibility
> information about what cores are compatible with which drivers and
> generating something. This is moderately better than blindly treating
> all cores with the same major version as interface compatible, but still
> has the potential to blindly declare that core versions are compatible
> when they are not really compatible.
That's okay, the device tree conventions provide for that uncertainty.
If compatible includes both the *exact* version and the oldest known
*compatible* version (the one the drivers know about) then we're in
the situation where 99% of the time it just works. For the 1% of the
time when mistakes are made we still have the necessary information to
write exceptions in the code to work around bad data. This means code
only needs to changes when mistakes are discovered, not for every IP
core uprev.
> I *really* don't want to put this into the device tree generator on a
> case-by-case basis, so unless there is something that can be generated
> from whatever meta-information EDK has, I think we're going to have to
> just have the explicit versions in the drivers for the time being.
Can we post process the generated device tree with a table of known
compatibility strings (or regexps) for adding the older compatible
values? I don't expect the list will be particularly long or hard to
maintain and the code to do so should be trivial.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/3] [WATCHDOG] mpc83xx_wdt: add support for MPC86xx CPUs
From: Jochen Friedrich @ 2008-05-12 19:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Wim Van Sebroeck, Timur Tabi
In-Reply-To: <64629276-8337-4FFE-B3E1-306678BF179D@kernel.crashing.org>
Hi Kumar,
>> Also move the probe code into subsys_initcall, because we want start
>> pinging the watchdog ASAP, and misc devices are available in
>> subsys_initcall.
>>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>> ---
>> drivers/watchdog/Kconfig | 4 +-
>> drivers/watchdog/mpc83xx_wdt.c | 63 +++++++++++++++++++++++++++++++
>> +++++----
>
> we should rename it to mpc8xxx_wdt.c
IIRC, even MPC8xx also has the same style of wdt device, just with a different
prescale factor.
Thanks,
Jochen
^ permalink raw reply
* Re: [PATCH 1/3] [WATCHDOG] mpc83xx_wdt: add support for MPC86xx CPUs
From: Kumar Gala @ 2008-05-12 19:24 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Wim Van Sebroeck, Timur Tabi
In-Reply-To: <20080512185206.GA25818@polina.dev.rtsoft.ru>
On May 12, 2008, at 1:52 PM, Anton Vorontsov wrote:
> On MPC86xx the watchdog could be enabled only at power-on-reset, and
> could not be disabled afterwards. We must ping the watchdog from the
> kernel until the userspace handles it.
>
> MPC83xx CPUs are only differ in a way that watchdog could be disabled
> once, but after it was enabled via software it becomes just the same
> as MPC86xx.
>
> Thus, to support MPC86xx I added the kernel timer which pings the
> watchdog until the userspace opens it.
>
> Since we implemented the timer, now we're able to implement proper
> handling for the CONFIG_WATCHDOG_NOWAYOUT case, for MPC83xx and
> MPC86xx.
>
> Also move the probe code into subsys_initcall, because we want start
> pinging the watchdog ASAP, and misc devices are available in
> subsys_initcall.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/watchdog/Kconfig | 4 +-
> drivers/watchdog/mpc83xx_wdt.c | 63 +++++++++++++++++++++++++++++++
> +++++----
we should rename it to mpc8xxx_wdt.c
- k
^ permalink raw reply
* RE: [PATCH] Xilinx: framebuffer: add compatibility for ml507 dvi core.
From: Stephen Neuendorffer @ 2008-05-12 19:10 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, git-dev
In-Reply-To: <fa686aa40805121130n53b14a8fye692e06616dc3bc7@mail.gmail.com>
The best possibility that I see is glopping the compatibility
information about what cores are compatible with which drivers and
generating something. This is moderately better than blindly treating
all cores with the same major version as interface compatible, but still
has the potential to blindly declare that core versions are compatible
when they are not really compatible.
I *really* don't want to put this into the device tree generator on a
case-by-case basis, so unless there is something that can be generated
from whatever meta-information EDK has, I think we're going to have to
just have the explicit versions in the drivers for the time being.
Steve=20
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of
Grant Likely
> Sent: Monday, May 12, 2008 11:30 AM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Xilinx: framebuffer: add compatibility for ml507
dvi core.
>=20
> On Mon, May 12, 2008 at 11:31 AM, Stephen Neuendorffer
> <stephen.neuendorffer@xilinx.com> wrote:
> >
> > Not easily. As we discussed before, there is nowhere that really
> > specifies this information. In some cases I've modified the device
tree
> > generator to understand what is backward compatible, as with
ns16550,
> > but for other cores it makes more sense to me to put this
compatibility
> > information with the driver if it has to be anywhere.
>=20
> The main concern is that the driver will balloon with data which
> impacts the load size for all builds that compile it in. It also
> reduces the impact of minor modifications of the IP cores (ie. the
> kernel still works when I've up-revved an ip core from 1.00a to
> 1.00b.)
>=20
> I understand that it is hard within the EDK TCL scripts context, but
> this is exactly what compatible is designed for and I don't think
> continually adding more versions to the list is sustainable in the
> long term. The more I think about it, the more I'm uneasy about this
> approach.
>=20
> For the time being, I'm going to resist merging this change into my
> tree, but I'll keep it in my "don't forget about this" list. It's not
> going into .26 anyway, so there is no time pressure. Later, when
> we're closer to the .27 merge window, I'll look at it again, but I
> really would prefer to find a way to add to the compatible list.
>=20
> Cheers,
> g.
>=20
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/3] [WATCHDOG] mpc83xx_wdt: add support for MPC86xx CPUs
From: Scott Wood @ 2008-05-12 18:58 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Wim Van Sebroeck, Timur Tabi
In-Reply-To: <20080512185206.GA25818@polina.dev.rtsoft.ru>
Anton Vorontsov wrote:
> + enabled = in_be32(&wd_base->swcrr) & SWCRR_SWEN;
> +#ifdef CONFIG_PPC_86xx
> + if (!enabled) {
> + dev_info(&dev->dev, "could not be enabled by software\n");
> + ret = -ENOSYS;
> + goto err_unmap;
> + }
> +#endif
What happens on an 83xx+86xx multiplatform kernel?
-Scott
^ permalink raw reply
* [PATCH 3/3] [POWERPC] 86xx: mpc8610_hpcd: add watchdog node
From: Anton Vorontsov @ 2008-05-12 18:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Wim Van Sebroeck, Timur Tabi
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index 5030533..67fd2c7 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -195,6 +195,12 @@
fsl,has-rstcr;
};
+ wdt@e4000 {
+ device_type = "watchdog";
+ compatible = "mpc83xx_wdt", "fsl,mpc8610-wdt";
+ reg = <0xe4000 0x100>;
+ };
+
gpio@f000 {
compatible = "fsl,mpc8610-gpio";
reg = <0xf000 0x100>;
--
1.5.5.1
^ permalink raw reply related
* [PATCH 2/3] [POWERPC] fsl_soc: register mpc83xx_wdt for PPC_86xx
From: Anton Vorontsov @ 2008-05-12 18:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Wim Van Sebroeck, Timur Tabi
Since mpc83xx_wdt driver is able to handle MPC86xx watchdogs now,
we want to regster the device appropriately.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/fsl_soc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index a5ceeef..85861c9 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -545,7 +545,7 @@ err:
arch_initcall(fsl_i2c_of_init);
#endif
-#ifdef CONFIG_PPC_83xx
+#if defined(CONFIG_PPC_83xx) || defined(CONFIG_PPC_86xx)
static int __init mpc83xx_wdt_init(void)
{
struct resource r;
--
1.5.5.1
^ permalink raw reply related
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