* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Sergei Shtylyov @ 2007-05-18 15:06 UTC (permalink / raw)
To: Daniel Walker; +Cc: linuxppc-dev, tglx, mingo, linux-kernel
In-Reply-To: <1179500217.20519.53.camel@imap.mvista.com>
Daniel Walker 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?
> There is if the main clocksource has some issues where it can't be used.
You mean, having more than one clocksource is *useful* in this case?
> On x86 there are lots of different issues with the clocks, so they have
> to get switches once in a while. For instance, if the TSC changes
> frequencies then it can't be used, or if the TSC stops in different
> power states , it can't be used..
Yeah, and there's the rating systems for both clock sources/events.
> Anything like that on PowerPC?
Well, the decrementer frequency may change, at least in theory (if the bus
clock changes).
> Daniel
WBR, Sergei
^ permalink raw reply
* Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Jean Delvare @ 2007-05-18 15:15 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, i2c
In-Reply-To: <5B363A90-5528-4441-BBF9-9C6D8833D938@kernel.crashing.org>
Hi Kumar,
On Thu, 17 May 2007 12:21:02 -0500, Kumar Gala wrote:
> 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.
This is exactly how free software development works. If people were
only proposing complete solutions, Linux would not even exist. Things
happen exactly because people write what they need and contribute what
they wrote. If you think it's not enough for your own needs (present or
future), then _you_ get to do the extra work.
Thanks,
--
Jean Delvare
^ permalink raw reply
* Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Jean Delvare @ 2007-05-18 15:19 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, i2c
In-Reply-To: <8183195dad79296e3986f561bf929067@kernel.crashing.org>
On Thu, 17 May 2007 21:18:15 +0200, Segher Boessenkool wrote:
> > + Required properties :
> > +
> > + - reg : Unshifted 7-bit I2C address for the device
>
> What about 10-bit addressing, etc.?
Who needs this? Support for 10-bit I2C addressing has been broken for
years and nobody seems to care.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Jerry Van Baren @ 2007-05-18 15:22 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <464DB986.20205@freescale.com>
Timur Tabi wrote:
> David Gibson wrote:
>> On Thu, May 17, 2007 at 01:46:26PM -0500, Timur Tabi wrote:
>>> 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
>> Erm... how would you encode such conditionals in the dtb?
>
> We'll propose a spec once we have everything figured out. Our current idea is to allow
> any node or property to have a conditional attached to it. U-Boot will then scan the
> device tree, evaluate the conditional, and if it's false, delete the particular node/property.
>
> U-Boot will be also be expanded to include the concept of "hardware options", whether the
> user and/or board-specific code can tell U-Boot that hardware option X is set to value Y.
> The conditions in the device tree will be of the form "X == Y" (or X != Y, X > Y, etc).
>
> For instance, on some board, if jumper 22 is on, then it means that the USB port is
> enabled. If it's possible for software to scan the status of J22, then the board-specific
> code will do that, and it will create an environment variable "J22=ON". The USB node in
> the device tree will have the conditional "J22 = ON".
I am skeptical.
If hardware can discover configuration details, u-boot software, using
libfdt, can modify existing and add new configuration items to the fdt
(modify properties, create nodes, add properties, select the proper fdt
snippets and merge them into the base fdt).
As I understand it, this is what OF does. Stuff that isn't probable
needs to be hardcoded in the base fdt. Stuff that is configurable
should be probed and the pieces of fdt generated/selected and added to
the base fdt.
U-Boot: OF without the RPN. ;-)
>> I really
>> don't like the idea of having a generalized conditional
>> parser/evaluator built into the bootwrapper.
>
> Well, let us present the full proposal with our reasonings when we're ready. I don't want
> to engage in speculative debate.
Oops, too late. :-D
>> What I'd been thinking for situations like this is to fold two dtbs
>> into the bootwrapper and have it select between them based on on board
>> revision (assuming that can be deduced from registers somehow).
>
> Our idea is very similar, but just more standardized and more granular.
Best regards,
gvb
^ permalink raw reply
* Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Jean Delvare @ 2007-05-18 15:27 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, i2c
In-Reply-To: <464CADBB.9050500@freescale.com>
Hi Scott,
On Thu, 17 May 2007 14:32:11 -0500, Scott Wood wrote:
> (and the
> i2c code in Linux should be fixed to allow drivers to specify multiple
> match names).
Back when David proposed his new-style i2c code, I had the same
objection. But we addressed the need differently. If you look at struct
i2c_board_info, you'll see two string fields, driver_name and type. The
former specifies the driver name, the second specifies the exact device
variant. For drivers which support several device variants, the
platform code should fill both fields.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Matt Sealey @ 2007-05-18 15:37 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linux-kernel, linuxppc-dev, mingo
In-Reply-To: <1179499713.12981.75.camel@chaos>
I already have that stuff, but it only implements the decrementer (in fact
it's the patch submitted at the beginning of this thread).
I got it because I was far more interested in the GPIO handling..
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Thomas Gleixner wrote:
> On Fri, 2007-05-18 at 15:28 +0100, Matt Sealey wrote:
>>>> I guess the real question is, how high resolution does a high resolution
>>>> timer need to be,
>>> In the order of microseconds.
>> I think both the MPC52xx GPT0-7 and the SLT0-1 fulfil this fairly
>> easily.
>
> There is some basic work for MPC5200 available:
>
> http://www.pengutronix.de/oselas/bsp/phytec/index_en.html#phyCORE-MPC5200B-tiny
>
> tglx
>
>
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Daniel Walker @ 2007-05-18 15:39 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, tglx, mingo, linux-kernel
In-Reply-To: <464DC0DC.7050809@ru.mvista.com>
On Fri, 2007-05-18 at 19:06 +0400, Sergei Shtylyov wrote:
> Daniel Walker 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?
>
> > There is if the main clocksource has some issues where it can't be used.
>
> You mean, having more than one clocksource is *useful* in this case?
Yes.
> Well, the decrementer frequency may change, at least in theory (if the bus
> clock changes).
Does that happen very often?
Daniel
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Sergei Shtylyov @ 2007-05-18 15:48 UTC (permalink / raw)
To: Daniel Walker; +Cc: linuxppc-dev, tglx, mingo, linux-kernel
In-Reply-To: <1179502773.20519.56.camel@imap.mvista.com>
Hello.
Daniel Walker wrote:
>> Well, the decrementer frequency may change, at least in theory (if the bus
>>clock changes).
> Does that happen very often?
Never, I hope. :-)
> Daniel
WBR, Sergei
^ permalink raw reply
* Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Scott Wood @ 2007-05-18 15:58 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, i2c
In-Reply-To: <20070518172711.2db7fc92@hyperion.delvare>
Jean Delvare wrote:
> Hi Scott,
>
> On Thu, 17 May 2007 14:32:11 -0500, Scott Wood wrote:
>
>>(and the
>>i2c code in Linux should be fixed to allow drivers to specify multiple
>>match names).
>
>
> Back when David proposed his new-style i2c code, I had the same
> objection. But we addressed the need differently. If you look at struct
> i2c_board_info, you'll see two string fields, driver_name and type. The
> former specifies the driver name, the second specifies the exact device
> variant. For drivers which support several device variants, the
> platform code should fill both fields.
But that still requires the platform to know the driver name, rather
than matching any driver which knows about the type. This prevents the
use of OS-independent device trees (such as in Open Firmware), which
cannot know specific Linux driver names, without something hacky like a
type-to-driver table in the device tree code.
-Scott
^ permalink raw reply
* Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Kumar Gala @ 2007-05-18 16:24 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, i2c
In-Reply-To: <20070518171555.543f9bdc@hyperion.delvare>
On May 18, 2007, at 10:15 AM, Jean Delvare wrote:
> Hi Kumar,
>
> On Thu, 17 May 2007 12:21:02 -0500, Kumar Gala wrote:
>> 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.
>
> This is exactly how free software development works. If people were
> only proposing complete solutions, Linux would not even exist. Things
> happen exactly because people write what they need and contribute what
> they wrote. If you think it's not enough for your own needs
> (present or
> future), then _you_ get to do the extra work.
I guess my gripe is about proposing a solution and not willing to
extend it in light of people providing issues with it. Last time I
check we don't put things into the kernel w/o any review and if
people have issues that are reasonable they get hashed out. It seems
that the onus is on the initial submitter to either show that what
they are providing is sufficient and w/o issue or incorporate the
feedback.
More specifically, we have a way to specify what devices are connect
on I2C today. I'm not convinced there is any value in creating yet
another mechanism, especially in an interface that in theory should
be linux agnostic.
- k
^ permalink raw reply
* Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Kumar Gala @ 2007-05-18 16:29 UTC (permalink / raw)
To: Scott Wood; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <464DCD0E.9000706@freescale.com>
On May 18, 2007, at 10:58 AM, Scott Wood wrote:
> Jean Delvare wrote:
>> Hi Scott,
>>
>> On Thu, 17 May 2007 14:32:11 -0500, Scott Wood wrote:
>>
>>> (and the
>>> i2c code in Linux should be fixed to allow drivers to specify
>>> multiple
>>> match names).
>>
>>
>> Back when David proposed his new-style i2c code, I had the same
>> objection. But we addressed the need differently. If you look at
>> struct
>> i2c_board_info, you'll see two string fields, driver_name and
>> type. The
>> former specifies the driver name, the second specifies the exact
>> device
>> variant. For drivers which support several device variants, the
>> platform code should fill both fields.
>
> But that still requires the platform to know the driver name, rather
> than matching any driver which knows about the type. This prevents
> the
> use of OS-independent device trees (such as in Open Firmware), which
> cannot know specific Linux driver names, without something hacky
> like a
> type-to-driver table in the device tree code.
And this is why I don't think there is any value in trying to put I2C
devices in the device tree. The linux mechanism is specific to
Linux, and is based on Linux created names. To provide something
more generic someone would have to take on the task of providing a
more global registry of names for devices and I just don't see anyone
doing that.
Can someone explain to me why setting up i2c_board_info in the board
specific code isn't sufficient?
- k
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Kumar Gala @ 2007-05-18 16:31 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linux-kernel, linuxppc-dev, mingo
In-Reply-To: <1179499713.12981.75.camel@chaos>
On May 18, 2007, at 9:48 AM, Thomas Gleixner wrote:
> On Fri, 2007-05-18 at 15:28 +0100, Matt Sealey wrote:
>>>> I guess the real question is, how high resolution does a high
>>>> resolution
>>>> timer need to be,
>>>
>>> In the order of microseconds.
>>
>> I think both the MPC52xx GPT0-7 and the SLT0-1 fulfil this fairly
>> easily.
>
> There is some basic work for MPC5200 available:
>
> http://www.pengutronix.de/oselas/bsp/phytec/index_en.html#phyCORE-
> MPC5200B-tiny
I asked this earlier, but figured you might have a better insight.
Is their value in having 'drivers' for more than one clock source?
I'd say most (of not all) the PPC SoCs have timers on the system side
that we could provide drivers for, I'm just not sure if that does
anything for anyone.
- k
^ permalink raw reply
* Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Jean Delvare @ 2007-05-18 16:31 UTC (permalink / raw)
To: Scott Wood; +Cc: David Brownell, linuxppc-dev, i2c
In-Reply-To: <464DCD0E.9000706@freescale.com>
On Fri, 18 May 2007 10:58:06 -0500, Scott Wood wrote:
> Jean Delvare wrote:
> > On Thu, 17 May 2007 14:32:11 -0500, Scott Wood wrote:
> >
> >>(and the
> >>i2c code in Linux should be fixed to allow drivers to specify multiple
> >>match names).
> >
> >
> > Back when David proposed his new-style i2c code, I had the same
> > objection. But we addressed the need differently. If you look at struct
> > i2c_board_info, you'll see two string fields, driver_name and type. The
> > former specifies the driver name, the second specifies the exact device
> > variant. For drivers which support several device variants, the
> > platform code should fill both fields.
>
> But that still requires the platform to know the driver name, rather
> than matching any driver which knows about the type. This prevents the
> use of OS-independent device trees (such as in Open Firmware), which
> cannot know specific Linux driver names, without something hacky like a
> type-to-driver table in the device tree code.
Oh well, this was also the reason why I objected to David's approach in
the first place. If you dig back in the i2c list archive, you'll find
that I was asking for exactly the same thing you do now: that each i2c
driver would export a list of supported devices, and the i2c-core would
match a device name against that list (independent of the driver name.)
It felt more flexible, but I wondered how useful it would be in
practice, and finally gave up and David had the last word. If you had
shown up back then rather than now...
I am not familiar with Open Firmware. How standard is it? How realistic
would it be to use their device naming in the Linux kernel? Are there
other subsystem doing this? Are there other OSes using it, in
particular for I2C?
We have something which works now, even if that's not what you and I
had in mind, so I don't really want to change it without solid reasons.
--
Jean Delvare
^ permalink raw reply
* Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Scott Wood @ 2007-05-18 16:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <D50C4D36-CEA5-4F7F-8A4C-CC747DF85865@kernel.crashing.org>
Kumar Gala wrote:
> I guess my gripe is about proposing a solution and not willing to
> extend it in light of people providing issues with it.
I'm perfectly willing to extend it if you let me know what you think is
needed, rather than just saying "switches and muxes". What
*specifically* would they need beyond what I proposed?
> Last time I
> check we don't put things into the kernel w/o any review and if people
> have issues that are reasonable they get hashed out. It seems that the
> onus is on the initial submitter to either show that what they are
> providing is sufficient and w/o issue or incorporate the feedback.
Give me something I can incorporate, then. My gripe is when the
feedback is "don't bother" based on unspecified problems with a
configuration more complex than what it was intended to address (but
still, AFAICT, not outside its ability to address).
> More specifically, we have a way to specify what devices are connect on
> I2C today. I'm not convinced there is any value in creating yet
> another mechanism, especially in an interface that in theory should be
> linux agnostic.
We had a way to specify platform devices before, too. If the device
tree isn't worthwhile for i2c devices, why is it worthwhile for soc
devices? It seems to me that non-probable chips like i2c devices are
precisely the kind of thing that the device tree is useful for.
-Scott
^ permalink raw reply
* Re: [PATCH 2/5] Add legacy devices to mpc8641_hpcn.dts
From: Jon Loeliger @ 2007-05-18 16:44 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <0c3907573f12a0731d03335fe3334363@kernel.crashing.org>
On Wed, 2007-05-16 at 18:40, Segher Boessenkool wrote:
> > Is there a recommended "compatible" property for a standard PC-like
> > CMOS
> > RTC?
>
> None in the bindings that I know of. It typically would
> be the model name/number of the oldest chip used, or one
> that is very commonly used.
And I haven't actually gotten it to work yet either...
Am I missing something? Like a CONFIG_ option beyond
the RTC and CMOS variant that is necessary?
Dumbly,
jdl
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Thomas Gleixner @ 2007-05-18 16:50 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-kernel, linuxppc-dev, mingo
In-Reply-To: <32E780BE-58B7-4303-AA49-1852C4C7EB50@kernel.crashing.org>
On Fri, 2007-05-18 at 11:31 -0500, Kumar Gala wrote:
> I asked this earlier, but figured you might have a better insight.
> Is their value in having 'drivers' for more than one clock source?
> I'd say most (of not all) the PPC SoCs have timers on the system side
> that we could provide drivers for, I'm just not sure if that does
> anything for anyone.
Not necessarily for the tick/highres stuff, but clock events allows
other users as well to utilize such facilities. We have no users yet,
but there are drivers, which utilize special timer hardware with nice
#ifdeffery to allow the driver to be shared. This might be a useful
thing for such stuff.
tglx
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Scott Wood @ 2007-05-18 16:46 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <464DB986.20205@freescale.com>
On Fri, May 18, 2007 at 09:34:46AM -0500, Timur Tabi wrote:
> We'll propose a spec once we have everything figured out. Our current
> idea is to allow any node or property to have a conditional attached to
> it. U-Boot will then scan the device tree, evaluate the conditional,
> and if it's false, delete the particular node/property.
>
> U-Boot will be also be expanded to include the concept of "hardware
> options", whether the user and/or board-specific code can tell U-Boot
> that hardware option X is set to value Y. The conditions in the device
> tree will be of the form "X == Y" (or X != Y, X > Y, etc).
>
> For instance, on some board, if jumper 22 is on, then it means that the
> USB port is enabled. If it's possible for software to scan the status
> of J22, then the board-specific code will do that, and it will create
> an environment variable "J22=ON". The USB node in the device tree will
> have the conditional "J22 = ON".
I'd like to point out that what I originally proposed was much simpler
than this; it simply allowed a special section of the device tree to list
jumpers and other hw options, and associate a device tree fragment with
each possibility. Something like this:
u-boot,hwoptions {
J1 {
description = "USB PHY selector";
off {
description = "USB internal PHY";
tree {
&usb {
phy_type = "utmi_wide";
};
};
};
on {
description = "USB external PHY";
tree {
&usb {
phy_type = "ulpi";
};
};
};
};
};
The fragment that corresponds to the option that is either detected
automatically or specified by the user on the command line gets merged
into the main dts. The u-boot,hwoptions tree gets removed before passing
to the kernel, to avoid confusion. The descriptions can be used to
provide interactive help text, as an alternative to having to fetch the
manual to find jumper information.
I agreed with using conditionals at the dtc level, and having dtc
transform it into the above at the dtb level. I'm not quite comfortable
with having general conditional expressions at the binary level.
-Scott
^ permalink raw reply
* [PATCH] powerpc: smp_call_function might switch cpu
From: Hugh Dickins @ 2007-05-18 16:47 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
smp_call_function_map() was not safe against preemption to another
cpu: its test for removing self from map was outside the spinlock.
Rearrange it a little to fix that.
smp_call_function_single() was also wrong: now get_cpu() before
excluding self, as other architectures do.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
---
I guess most callers actually have preemption disabled already: I only
noticed this for the first time in 2.6.22-rc1-mm1, where mm/page_alloc.c
has a drain_all_local_pages(), which triggered a warning with my PowerPC
DEBUG_PREEMPT patch.
arch/powerpc/kernel/smp.c | 34 ++++++++++++++++++----------------
1 file changed, 18 insertions(+), 16 deletions(-)
--- 2.6.22-rc1-git7/arch/powerpc/kernel/smp.c 2007-05-13 05:40:52.000000000 +0100
+++ linux/arch/powerpc/kernel/smp.c 2007-05-18 17:07:51.000000000 +0100
@@ -201,13 +201,6 @@ int smp_call_function_map(void (*func) (
/* Can deadlock when called with interrupts disabled */
WARN_ON(irqs_disabled());
- /* remove 'self' from the map */
- if (cpu_isset(smp_processor_id(), map))
- cpu_clear(smp_processor_id(), map);
-
- /* sanity check the map, remove any non-online processors. */
- cpus_and(map, map, cpu_online_map);
-
if (unlikely(smp_ops == NULL))
return ret;
@@ -222,10 +215,17 @@ int smp_call_function_map(void (*func) (
/* Must grab online cpu count with preempt disabled, otherwise
* it can change. */
num_cpus = num_online_cpus() - 1;
- if (!num_cpus || cpus_empty(map)) {
- ret = 0;
- goto out;
- }
+ if (!num_cpus)
+ goto done;
+
+ /* remove 'self' from the map */
+ if (cpu_isset(smp_processor_id(), map))
+ cpu_clear(smp_processor_id(), map);
+
+ /* sanity check the map, remove any non-online processors. */
+ cpus_and(map, map, cpu_online_map);
+ if (cpus_empty(map))
+ goto done;
call_data = &data;
smp_wmb();
@@ -263,6 +263,7 @@ int smp_call_function_map(void (*func) (
}
}
+ done:
ret = 0;
out:
@@ -282,16 +283,17 @@ EXPORT_SYMBOL(smp_call_function);
int smp_call_function_single(int cpu, void (*func) (void *info), void *info, int nonatomic,
int wait)
{
- cpumask_t map=CPU_MASK_NONE;
+ cpumask_t map = CPU_MASK_NONE;
+ int ret = -EBUSY;
if (!cpu_online(cpu))
return -EINVAL;
- if (cpu == smp_processor_id())
- return -EBUSY;
-
cpu_set(cpu, map);
- return smp_call_function_map(func,info,nonatomic,wait,map);
+ if (cpu != get_cpu())
+ ret = smp_call_function_map(func,info,nonatomic,wait,map);
+ put_cpu();
+ return ret;
}
EXPORT_SYMBOL(smp_call_function_single);
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Matt Sealey @ 2007-05-18 16:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-kernel, linuxppc-dev, Thomas Gleixner, mingo
In-Reply-To: <32E780BE-58B7-4303-AA49-1852C4C7EB50@kernel.crashing.org>
Kumar Gala wrote:
>
> On May 18, 2007, at 9:48 AM, Thomas Gleixner wrote:
>
>> On Fri, 2007-05-18 at 15:28 +0100, Matt Sealey wrote:
>>>
>>> I think both the MPC52xx GPT0-7 and the SLT0-1 fulfil this fairly
>>> easily.
>>
>> There is some basic work for MPC5200 available:
>>
>> http://www.pengutronix.de/oselas/bsp/phytec/index_en.html#phyCORE-MPC5200B-tiny
>>
>
> I asked this earlier, but figured you might have a better insight. Is
> their value in having 'drivers' for more than one clock source? I'd say
> most (of not all) the PPC SoCs have timers on the system side that we
> could provide drivers for, I'm just not sure if that does anything for
> anyone.
As I asked after, I'm also very intrigued as to what is going to end
up using these timers, but likewise, not much use writing a driver if
everyone can use the extremely high resolution decrementer all at
once..
As I said before too, at least Intel has decided there is a great need
for up to 256 high resolution timer sources on a system, but since this
is a fairly new concept to Linux (and hrtimers and dynticks too) it
only seems to be used in the case of i8254/RTC emulation, mostly on
x86-64.
I'm looking at it now and finding "users" of hrtimers is looking very
thin on the ground. Maybe it's justified on the basis that more is
better, and having support is preferable to not having it (even if
nobody really uses it) but it seems the entire gamut of timing
possibility in Linux can be handled through a simple, and single,
high resolution timer and a queue of events..
So do we need some more? :D
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Kumar Gala @ 2007-05-18 16:51 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17997.17543.725526.907770@cargo.ozlabs.ibm.com>
On May 18, 2007, at 1:15 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> Sorry for the headache, I thought I had built an ARCH=ppc kernel.
>> This is now fixed in my tree so if you haven't pulled it you'll get
>> the fix.
>>
>> Also, added a ppc_ksysm.c fix to remove a duplicate export symbol.
>
> Hmmm. I had pulled your tree, and I ended up rebasing your commits on
> top of Linus' current master and adding some more commits on top of
> that. I'm about to send a pull request to Linus for that lot. The
> arch/ppc changes can go in the next lot.
No problem, I'll merge the two patches and rebase on your latest
tree. We'll pull in the fixes for the MODPOST warnings as well in
the next go around since I think Sam's __initref_ok fixes will be in
by then.
- k
^ permalink raw reply
* RE: BDI2000 configuration file for MPC8313E-RDB
From: Leonid @ 2007-05-18 16:54 UTC (permalink / raw)
To: Frank Prepelica, linuxppc-embedded
In-Reply-To: <29DC34A6B43468409F5A371CFE34E84917683B@ex01.ads.ubidyne.de>
On Thursday, May 17, 2007 11:00 PM Frank Prepelica wrote:
> Hi Leonid,
> firstly, thanks for reply!
You are very welcome.
> But, are you sure that I cannot access NAND memory via=20
> BDI2000?=20
In the first place, let me quote Ruedi Dummermuth from Abatron, BDI2000
vendor:
> > Leonid asked:
> > And here most important question comes: for our actual HW we are
going=20
> > to use ST-Micro NAND flash, one of NAND512-B, NAND01G-B, NAND02G-B,=20
> > NAND04G-B and NAND08G-B. Is BDI2000 capable of programming these=20
> > flashes? What changes in .cfg file are required?
> Sorry, but the BDI does not support programming any NAND flash.
> You can write your own driver. Then load the data and the driver into=20
> SDRAM via the BDI and execute it.
This passage also has a suggestion how you can use BDI2000 to program
NAND indirectly: load NAND-capable software to RAM.
> Because I used BDI2000 with the MPC8343M Board=20
> and there is "only" 64MB NAND memory. Thus I stored the=20
> U-Boot (image was broken) into the flash memory.
I'm afraid I didn't understand you. Are you saying that you actually
were able to program NAND using BDI2000? I would like to know how you
achieved that. I suspect that was some kind of "indirect" procedure,
Ruedi wrote about, but please provide details.
See, it's not a question that BDI2000 can be used with board which has
NAND flash on it, just it's not capable of NAND direct programming as it
does in the case of NOR flash.
I also have AMCC Sequoia board with both NOR and NAND flash. On this
board you can boot u-boot from NOR first and use it to program NAND.
Regards,
Leonid.
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Matt Sealey @ 2007-05-18 16:55 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linux-kernel, linuxppc-dev, mingo
In-Reply-To: <1179507059.12981.81.camel@chaos>
Thomas Gleixner wrote:
> On Fri, 2007-05-18 at 11:31 -0500, Kumar Gala wrote:
>> I asked this earlier, but figured you might have a better insight.
>> Is their value in having 'drivers' for more than one clock source?
>> I'd say most (of not all) the PPC SoCs have timers on the system side
>> that we could provide drivers for, I'm just not sure if that does
>> anything for anyone.
>
> Not necessarily for the tick/highres stuff, but clock events allows
> other users as well to utilize such facilities. We have no users yet,
> but there are drivers, which utilize special timer hardware with nice
> #ifdeffery to allow the driver to be shared. This might be a useful
> thing for such stuff.
*ahem*
Please indulge my laziness and recommend me one or two to look at? I'm
no good at guessing what to grep for to find an example (I wonder if
we have any candidates in the ppc tree mostly..)
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Kumar Gala @ 2007-05-18 16:56 UTC (permalink / raw)
To: Jean Delvare; +Cc: David Brownell, i2c, linuxppc-dev
In-Reply-To: <20070518183140.4644ffc6@hyperion.delvare>
On May 18, 2007, at 11:31 AM, Jean Delvare wrote:
> On Fri, 18 May 2007 10:58:06 -0500, Scott Wood wrote:
>> Jean Delvare wrote:
>>> On Thu, 17 May 2007 14:32:11 -0500, Scott Wood wrote:
>>>
>>>> (and the
>>>> i2c code in Linux should be fixed to allow drivers to specify
>>>> multiple
>>>> match names).
>>>
>>>
>>> Back when David proposed his new-style i2c code, I had the same
>>> objection. But we addressed the need differently. If you look at
>>> struct
>>> i2c_board_info, you'll see two string fields, driver_name and
>>> type. The
>>> former specifies the driver name, the second specifies the exact
>>> device
>>> variant. For drivers which support several device variants, the
>>> platform code should fill both fields.
>>
>> But that still requires the platform to know the driver name, rather
>> than matching any driver which knows about the type. This
>> prevents the
>> use of OS-independent device trees (such as in Open Firmware), which
>> cannot know specific Linux driver names, without something hacky
>> like a
>> type-to-driver table in the device tree code.
>
> Oh well, this was also the reason why I objected to David's
> approach in
> the first place. If you dig back in the i2c list archive, you'll find
> that I was asking for exactly the same thing you do now: that each i2c
> driver would export a list of supported devices, and the i2c-core
> would
> match a device name against that list (independent of the driver
> name.)
> It felt more flexible, but I wondered how useful it would be in
> practice, and finally gave up and David had the last word. If you had
> shown up back then rather than now...
>
> I am not familiar with Open Firmware. How standard is it? How
> realistic
> would it be to use their device naming in the Linux kernel? Are there
> other subsystem doing this? Are there other OSes using it, in
> particular for I2C?
OF doesn't have any particular bindings that already exist for I2C.
If it had I might be more in favor of trying to make Linux work with it.
Here's a link to give you some idea of what bindings exist already
for OF:
http://openbios.info/Bindings
> We have something which works now, even if that's not what you and I
> had in mind, so I don't really want to change it without solid
> reasons.
agreed.
- k
^ permalink raw reply
* Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Kumar Gala @ 2007-05-18 17:10 UTC (permalink / raw)
To: Scott Wood; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <464DD5E3.1060301@freescale.com>
On May 18, 2007, at 11:35 AM, Scott Wood wrote:
> Kumar Gala wrote:
>> I guess my gripe is about proposing a solution and not willing to
>> extend it in light of people providing issues with it.
>
> I'm perfectly willing to extend it if you let me know what you
> think is needed, rather than just saying "switches and muxes".
> What *specifically* would they need beyond what I proposed?
I provided you an example device and asked you to explain how it
would be described in what you are proposing.
>> Last time I check we don't put things into the kernel w/o any
>> review and if people have issues that are reasonable they get
>> hashed out. It seems that the onus is on the initial submitter
>> to either show that what they are providing is sufficient and w/o
>> issue or incorporate the feedback.
>
> Give me something I can incorporate, then. My gripe is when the
> feedback is "don't bother" based on unspecified problems with a
> configuration more complex than what it was intended to address
> (but still, AFAICT, not outside its ability to address).
I never said don't bother because you didn't cover the switch/mux
case. I said don't bother because I don't see what the value is
creating a namespace that no one is going to manage and thus will end
up most likely being linux specific, and linux already provides a
solution for the problem.
>> More specifically, we have a way to specify what devices are
>> connect on I2C today. I'm not convinced there is any value in
>> creating yet another mechanism, especially in an interface that
>> in theory should be linux agnostic.
>
> We had a way to specify platform devices before, too. If the
> device tree isn't worthwhile for i2c devices, why is it worthwhile
> for soc devices? It seems to me that non-probable chips like i2c
> devices are precisely the kind of thing that the device tree is
> useful for.
I dont believe anyone has ever said that platform devices have to be
in the device tree. We've been putting them their because we are
going to act as the registry for the devices. The number of devices
on all the various Freescale/AMCC/IBM PPC SoCs is likely a very small
number compared to all I2C devices.
For I2C specifically we already have both a dynamic way (kernel cmd
line) and static (i2c_board_info) to specify the i2c devices, why do
we need yet another?
- k
^ permalink raw reply
* Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Scott Wood @ 2007-05-18 17:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <6F8D3143-423D-45FA-9F40-00BF770831F2@kernel.crashing.org>
Kumar Gala wrote:
>
> On May 18, 2007, at 11:35 AM, Scott Wood wrote:
>
>> Kumar Gala wrote:
>>
>>> I guess my gripe is about proposing a solution and not willing to
>>> extend it in light of people providing issues with it.
>>
>>
>> I'm perfectly willing to extend it if you let me know what you think
>> is needed, rather than just saying "switches and muxes". What
>> *specifically* would they need beyond what I proposed?
>
>
> I provided you an example device and asked you to explain how it would
> be described in what you are proposing.
And I did. What did you find lacking in the device tree fragment I
suggested?
> I never said don't bother because you didn't cover the switch/mux
> case. I said don't bother because I don't see what the value is
> creating a namespace that no one is going to manage and thus will end
> up most likely being linux specific, and linux already provides a
> solution for the problem.
Given that power.org is attempting to do further standardization of the
device tree for embedded applications, I'd be surprised if there weren't
a way we could have them act as a registry.
> For I2C specifically we already have both a dynamic way (kernel cmd
> line) and static (i2c_board_info) to specify the i2c devices, why do we
> need yet another?
This uses i2c_board_info; it doesn't replace it.
-Scott
^ 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