Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> Note: I use msleep_interruptible(1); just like napi_disable(). However
> I'm not too happy that the "hot" loop that results of a pending signal
> here will spin without even a cpu_relax ... what do you guys think would
> be the best way to handl
dtc supports the use of C-style escapes (\n, \t and so forth) in
string property definitions via the data_copy_escape_string()
function. However, while it supports the most common escape
characters, it doesn't support the full set that C does, which is a
potential gotcha.
Worse, a bug in the lexe
On Oct 16, 2007, at 1:00 AM, Benjamin Herrenschmidt wrote:
>
>> You must have missed the thread where various people where
>> complaining
>> about how powerpc is the only architecture where they can't build
>> kernels without some external tool that they don't have, etc., etc.
>>
>> We thought
On Oct 16, 2007, at 1:01 AM, Benjamin Herrenschmidt wrote:
>
> On Tue, 2007-10-16 at 00:50 -0500, Kumar Gala wrote:
>> Just out of interest who's complaining? We don't include mkimage
>> for
>> u-boot related builds and I haven't seen any gripes related to that.
>
> It's a pain in the neck since
On Tuesday 16 October 2007, Kumar Gala wrote:
> On Oct 16, 2007, at 12:28 AM, Stefan Roese wrote:
> > On Tuesday 16 October 2007, Kumar Gala wrote:
> I'm willing to look into doing the port over, but would need some
> help testing.
> >>>
> >>> Yes, it would be greatly appreciated if you c
Dear Kumar,
in message <[EMAIL PROTECTED]> you wrote:
>
> >> 1. what processors does this actually support/run on. I'm guessing
> >> MPC8541, MPC8555? But not really sure
> >
> > IIRC there are 4 different versions of the board:
> > - 8540, 8541, 8555 & 8560
>
> do they all boot/run with the c
On Tue, 2007-10-16 at 00:50 -0500, Kumar Gala wrote:
> Just out of interest who's complaining? We don't include mkimage
> for
> u-boot related builds and I haven't seen any gripes related to that.
It's a pain in the neck since those are built even for things that don't
need them (such as 4xx w
> You must have missed the thread where various people where complaining
> about how powerpc is the only architecture where they can't build
> kernels without some external tool that they don't have, etc., etc.
>
> We thought about shipping compiled DTBs for various platforms, but the
> problem t
On Oct 16, 2007, at 12:28 AM, Stefan Roese wrote:
> On Tuesday 16 October 2007, Kumar Gala wrote:
I'm willing to look into doing the port over, but would need some
help testing.
>>>
>>> Yes, it would be greatly appreciated if you could start this
>>> TQM85xx port. I
>>> will of course d
net: Add __napi_sycnhronize() to sync with napi poll
The EMAC driver which needs to handle multiple devices with one
NAPI instance implements its own per-channel disable bit. However,
when setting such a bit, it needs to synchronize with the poller
(that is make sure that any pending poller instan
On Oct 16, 2007, at 12:39 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> Dare I ask why we are including dtc in the kernel source tree? We
>> don't really have precedence for this and there are users outside of
>> linux for dtc.
>
> You must have missed the thread where various people where
net: Fix new EMAC driver for NAPI changes
This fixes the new EMAC driver for the NAPI updates. The previous patch
by Roland Dreier (already applied) to do that doesn't actually work. This
applies on top of it makes it work on my test Ebony machine.
This patch depends on "net: Add __napi_sycnhroni
net: Add __napi_sycnhronize() to sync with napi poll
The EMAC driver which needs to handle multiple devices with one
NAPI instance implements its own per-channel disable bit. However,
when setting such a bit, it needs to synchronize with the poller
(that is make sure that any pending poller instan
Kumar Gala writes:
> Dare I ask why we are including dtc in the kernel source tree? We
> don't really have precedence for this and there are users outside of
> linux for dtc.
You must have missed the thread where various people where complaining
about how powerpc is the only architecture whe
On Tuesday 16 October 2007, Kumar Gala wrote:
> >> I'm willing to look into doing the port over, but would need some
> >> help testing.
> >
> > Yes, it would be greatly appreciated if you could start this
> > TQM85xx port. I
> > will of course do the testing.
>
> Ok, for the TQM85xx code in arch/pp
On Tue, Oct 16, 2007 at 12:08:06AM -0500, Kumar Gala wrote:
>
> On Oct 16, 2007, at 12:02 AM, David Gibson wrote:
>
> > This very large patch incorporates a copy of dtc into the kernel
> > source, in arch/powerpc/boot/dtc-src. This means that dtc is no
> > longer an external dependency to build
On Oct 15, 2007, at 11:33 AM, Grant Likely wrote:
> From: Grant Likely <[EMAIL PROTECTED]>
>
> USB support for the 8349itx got added a while back; but the defconfig
> never got updated. This patch updates defconfig and adds the
> appropriate
> USB config options.
>
> Signed-off-by: Grant Likel
On Oct 15, 2007, at 7:07 PM, Kumar Gala wrote:
> I was wondering if you cared about the following boards existing in
> arch/powerpc:
>
> * STX GP3
I have GP3 and GP3-SSA for testing.
If you can make a first pass at the changes
I'll debug and finish.
Thanks.
-- Dan
On Oct 16, 2007, at 12:02 AM, David Gibson wrote:
> This very large patch incorporates a copy of dtc into the kernel
> source, in arch/powerpc/boot/dtc-src. This means that dtc is no
> longer an external dependency to build kernels with configurations
> which need a dtb file.
>
> Signed-off-by:
On Oct 15, 2007, at 11:40 PM, Stefan Roese wrote:
> Hi Kumar,
>
> On Tuesday 16 October 2007, Kumar Gala wrote:
>> I was wondering if you cared about the following boards existing in
>> arch/powerpc:
>>
>> * STX GP3
>> * TQM 85xx
>> * SBC 8560
>>
>> I'm told WR doesn't care about the SBC 8560, so
This very large patch incorporates a copy of dtc into the kernel
source, in arch/powerpc/boot/dtc-src. This means that dtc is no
longer an external dependency to build kernels with configurations
which need a dtb file.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Too big for the list, full pa
Hi Kumar,
On Tuesday 16 October 2007, Kumar Gala wrote:
> I was wondering if you cared about the following boards existing in
> arch/powerpc:
>
> * STX GP3
> * TQM 85xx
> * SBC 8560
>
> I'm told WR doesn't care about the SBC 8560, so I'll see if David does.
>
> I'm willing to look into doing the p
On 10/15/07, David Gibson <[EMAIL PROTECTED]> wrote:
> As the inventor of "linux,network-index", please don't invent
> "linux,i2c-index". linux,network-index was and is a hack - it's
> badness is limited by the fact that it's essentially local to the
> bootwrapper. It's only used in the bootwrapp
This patch adds functions for dealing with the compatible property.
fdt_node_check_compatible() can be used to determine whether a node is
compatible with a given string and fdt_node_offset_by_compatible()
locates nodes with a given compatible string.
Testcases for these functions are also include
The dtc/libfdt testsuite creates a number of .dtb files during its
run. To ensure a clean test run, these are currently deleted before
each group of tests.
This is, in fact, a mistake, since if something goes wrong in the
first group of tests, deleting the .dtb at the beginning of the second
grou
libfdt.h currently includes fdt.h, then libfdt_env.h. This is
incorrect, because depending on the environment into which libfdt is
embedded, libfdt_env.h may be needed to define datatypes used in
fdt.h. This patch corrects the problem.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
---
I've se
This cleans up the formatting in the vDSO linker script, mostly just the
use of whitespace. It's intended to approximate the kernel standard
conventions for indenting C, treating elements of the linker script about
like initialized variable definitions.
Signed-off-by: Roland McGrath <[EMAIL PROT
This cleans up the formatting in the vDSO linker script, mostly just the
use of whitespace. It's intended to approximate the kernel standard
conventions for indenting C, treating elements of the linker script about
like initialized variable definitions.
Signed-off-by: Roland McGrath <[EMAIL PROT
On Mon, Oct 15, 2007 at 09:02:09PM -0600, Grant Likely wrote:
> On 10/15/07, David Gibson <[EMAIL PROTECTED]> wrote:
> > On Mon, Oct 15, 2007 at 11:14:44AM -0600, Grant Likely wrote:
> > > On 10/15/07, Olof Johansson <[EMAIL PROTECTED]> wrote:
> > > > On Mon, Oct 15, 2007 at 10:08:44AM -0600, Grant
On Mon, Oct 15, 2007 at 01:13:14PM -0600, Grant Likely wrote:
> On 10/15/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> > On Mon, Oct 15, 2007 at 10:57:48AM -0600, Grant Likely wrote:
> > > Segher is recommending that we use an aliases node as per the open
> > > firmware example for this. I think in
On 10/15/07, David Gibson <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 15, 2007 at 11:14:44AM -0600, Grant Likely wrote:
> > On 10/15/07, Olof Johansson <[EMAIL PROTECTED]> wrote:
> > > On Mon, Oct 15, 2007 at 10:08:44AM -0600, Grant Likely wrote:
> > > > Adding the Linux expected device tree bindings
On Mon, Oct 15, 2007 at 11:14:44AM -0600, Grant Likely wrote:
> On 10/15/07, Olof Johansson <[EMAIL PROTECTED]> wrote:
> > On Mon, Oct 15, 2007 at 10:08:44AM -0600, Grant Likely wrote:
> > > Adding the Linux expected device tree bindings to
> > > booting-without-of.txt seems to be getting a little
On Mon, Oct 15, 2007 at 10:56:50PM +0800, Li Yang wrote:
> Signed-off-by: Li Yang <[EMAIL PROTECTED]>
[snip]
> + [EMAIL PROTECTED] {
> + device_type = "mdio";
> + compatible = "gianfar";
> + reg = <24520 20>;
> +
On Mon, Oct 15, 2007 at 01:00:24PM -0500, Kumar Gala wrote:
>
> On Oct 15, 2007, at 12:33 PM, Sergei Shtylyov wrote:
>
> > Anton Vorontsov wrote:
> >
> >> MPC8568E-MDS have 1 32MB Spansion x16 CFI flash chip. Let's use it.
> >
> >> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> >
> >> diff
>Eh... poor you. Tony got clockevent driver reengineered for no apparent
> reason. And he's introduced the jiffy drift by deleting the main loop from
> timer_interrupt(). Yet this borken version was preferred to what was known
> working since about 2.6.18 and included into 2.6.21-rt patchs
On Mon, Oct 15, 2007 at 05:54:51PM -0500, Scott Wood wrote:
> Olof Johansson wrote:
>> Setup i2c_board_info based on device tree contents. This has to be
>> a device_initcall since we need PCI to be probed by the time we
>> run it, but before the actual driver is initialized.
>
> Can we factor at l
Sergei Shtylyov writes:
>Eh... poor you. Tony got clockevent driver reengineered for no apparent
> reason. And he's introduced the jiffy drift by deleting the main loop from
> timer_interrupt().
The main loop in timer_interrupt() became unnecessary, because
update_wall_time contains an equ
Rune Torgersen writes:
> The main couse is that our main bus frequency cannort be divided into
> 1kHz evently by the decrementer.
> Main bus freq = 99532800 Hz.
> Decrementer then becomes 24883, which gives us 91.9624485600nsec per
> jiffy.
> That is not a number easilly converted into time wi
Sergei Shtylyov writes:
> I don't see my own signoff or at least a reference to my prior work in
> this patch or even at -rt patch -- despite this code ha clearly borrowed from
> it. And I'm not sure why this crippled version (lacking 40x/ Book E specific
> clockevents implementation) is pref
In message <[EMAIL PROTECTED]> you wrote:
>
> what is the reasonable can-driver for a mpc5200b?
socket-can.
> I have seen for the peak-3.17 driver a port for the mpc5200 from denx on their
> website, but with kernel 2.6.23 I dont have a chance to use this?
No, but socket-can is part of our kern
Dear Kumar,
in message <[EMAIL PROTECTED]> you wrote:
>
> I was wondering if you cared about the following boards existing in
> arch/powerpc:
>
...
> * TQM 85xx
...
We definitely care about the TQM8xx{L,M,D}, TQM5200, TQM82xx, TQM834x,
TQM85xx and TQM86xx boards.
> I'm willing to look into d
On Tue, 2007-10-16 at 06:54 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2007-10-15 at 14:34 -0400, Jeff Garzik wrote:
> > Michael Ellerman wrote:
> > > Now that dcr_host_t contains the base address, we can use that in the
> > > ibm_newemac code, rather than storing it separately.
> > >
> > > Si
Guys,
I was wondering if you cared about the following boards existing in
arch/powerpc:
* STX GP3
* TQM 85xx
* SBC 8560
I'm told WR doesn't care about the SBC 8560, so I'll see if David does.
I'm willing to look into doing the port over, but would need some
help testing.
- k
__
On Mon, 2007-10-15 at 22:07 +0400, Sergei Shtylyov wrote:
> > Proper approach is to rip off what is altready in -rt there and
> replace
> > it with Tony patch set.
>
> Tony's patchset is broken at places compared to what is in -rt. So
> that
> would be proper *double standard* approach. :-/
On Tue, 2007-10-16 at 07:05 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2007-10-15 at 15:04 -0400, Jeff Garzik wrote:
> > I would ideally like a single active patch generator (even if they
> > are
> > merely reviewed others work sometimes).
> >
> > Outside of that, I'm hoping you and the other
Olof Johansson wrote:
> Setup i2c_board_info based on device tree contents. This has to be
> a device_initcall since we need PCI to be probed by the time we
> run it, but before the actual driver is initialized.
Can we factor at least some of this stuff out into common code?
We certainly shouldn'
Setup i2c_board_info based on device tree contents. This has to be
a device_initcall since we need PCI to be probed by the time we
run it, but before the actual driver is initialized.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
---
Turns out some old firmwares don't create the device nod
> From: Benjamin Herrenschmidt
> > Things have changed a lot since I last delved deep into
> > this to try to
> > ge an accurate freerunning clock (2.6.12).
>
> Hrm... 2.6.18 doesn't have clock sources in the first place,
> what kernel
> are you using ?
>
2.6.18
And I'm starting at the clock
On Mon, 2007-10-15 at 16:50 -0500, Rune Torgersen wrote:
> Huh? Not in 2.6.18/arch/ppc at least, unless I'm completely
> misundrstanding the code.
> ppc/powerpc seems to be using clocksource_jiffies as the clock source,
> and teh gettimeofday gets xtime + a offset from last jiffie, and xtime
> is
> From: Benjamin Herrenschmidt>
> > The TB register is only ued for offsets from the last
> jiffie, not as a
> > continous offset, so then it works out pretty good.
>
> The date is derived from the absolute TB value though...
Huh? Not in 2.6.18/arch/ppc at least, unless I'm completely
misundrsta
On Fri, 12 Oct 2007 16:51:04 +0200
Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> -if (mode_option || (mode_option = global_mode_option)) {
> +if (mode_option || (mode_option = fb_mode_option)) {
I guess that equals-which-looks-like-it-should-be-equals-equals really
is intended to be an
Now we have high res timers on ppc64 I thought Id test them. It turns
out compat_sys_nanosleep hasnt been converted to the hrtimer code and so
is limited to HZ resolution.
The follow patch converts compat_sys_nanosleep to use high res timers.
Signed-off-by: Anton Blanchard <[EMAIL PROTECTED]>
--
On Mon, 2007-10-15 at 15:04 -0400, Jeff Garzik wrote:
> I would ideally like a single active patch generator (even if they
> are
> merely reviewed others work sometimes).
>
> Outside of that, I'm hoping you and the other people listed making
> changes will self-organize without my help :)
Josh
On 10/15/07, Matt Sealey <[EMAIL PROTECTED]> wrote:
>
> Grant Likely wrote:
> > On 10/15/07, Matt Sealey <[EMAIL PROTECTED]> wrote:
> >> My nits:
> >>
> >> Grant Likely wrote:
> >>> From: Sylvain Munaut <[EMAIL PROTECTED]>
> >>> +static int __devinit
> >>> +bcom_engine_init(void)
> >> Why "bcom" an
Hi,
> If it's common to call sys_nanosleep with a NULL rmtp argument, we could
> save a few cycles using
>
> return hrtimer_nanosleep(&tu, rmtp ? &rmp : NULL, HRTIMER_MODE_REL,
> CLOCK_MONOTONIC);
Good idea, patches updated.
> I think it would be better he
On Mon, 2007-10-15 at 14:53 -0400, Jeff Garzik wrote:
> Roland Dreier (2):
>ibm_new_emac: Nuke SET_MODULE_OWNER() use
>ibm_emac: Convert to use napi_struct independent of struct
> net_device
>
Wow, I'd have loved to be CCed at least on the last one since I was
about to do just th
On Fri, 2007-10-12 at 17:04 +0400, Valentine Barshak wrote:
> Fix build RGMII error: use of_device_is_compatible()
> insteadof now deprecated device_is_compatible() function.
>
> Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> d
On Mon, 2007-10-15 at 12:26 -0500, Josh Boyer wrote:
> On Fri, 12 Oct 2007 17:03:05 +0400
> Valentine Barshak <[EMAIL PROTECTED]> wrote:
>
> > This patch enables NEW EMAC support for PowerPC 440EPx Sequoia board
> > and adds BCM5248 and Marvell 88E PHY support to NEW EMAC driver.
> > These PH
On Fri, 2007-10-12 at 17:03 +0400, Valentine Barshak wrote:
> This patch enables NEW EMAC support for PowerPC 440EPx Sequoia board
> and adds BCM5248 and Marvell 88E PHY support to NEW EMAC driver.
> These PHY chips are used on PowerPC440EPx boards.
> The PHY code is based on the previous work
On Mon, 2007-10-15 at 11:49 -0500, Rune Torgersen wrote:
>
> The main couse is that our main bus frequency cannort be divided into
> 1kHz evently by the decrementer.
> Main bus freq = 99532800 Hz.
> Decrementer then becomes 24883, which gives us 91.9624485600nsec
> per
> jiffy.
> That is not
On Mon, 2007-10-15 at 14:34 -0400, Jeff Garzik wrote:
> Michael Ellerman wrote:
> > Now that dcr_host_t contains the base address, we can use that in the
> > ibm_newemac code, rather than storing it separately.
> >
> > Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
> > ---
> > drivers/net/i
Matt Sealey wrote:
> call a PSC, we wouldn't be making structures called
> mpc52xx_programmable_serial_controller,
> that's redundant, I don't think calling it "bestcomm" (which is it's name)
> over
> "bcom" (which isn't) works to anyone's advantage here.
Disadvantage, even. Damn autocorrectin
Grant Likely wrote:
> On 10/15/07, Scott Wood <[EMAIL PROTECTED]> wrote:
>> Don't Do That(tm). If you use this mechanism, and an adapter node
>> doesn't have a bus number, then it doesn't get to pre-register devices,
>> but instead must use i2c_new_device.
>
> Even that doesn't work. For example
Grant Likely wrote:
> On 10/15/07, Matt Sealey <[EMAIL PROTECTED]> wrote:
>> My nits:
>>
>> Grant Likely wrote:
>>> From: Sylvain Munaut <[EMAIL PROTECTED]>
>>> +static int __devinit
>>> +bcom_engine_init(void)
>> Why "bcom" and not "bestcomm"?
>
> I can type 'bcom' twice as fast. :-) bcom is a
On 10/15/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
> > On 10/15/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> >> For associating a device node with a human readable label, I'd
> >> prefer a "label" property in the device node, rather than doing it
> >> backwards with aliases.
>
Hi Stefan,
On Mon, 15 Oct 2007 15:28:54 +0200, Stefan Roese wrote:
> Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> ---
> drivers/i2c/busses/i2c-ibm_iic.c | 192
> +++---
> drivers/i2c/busses/i2c-ibm_iic.h |8 +-
> 2 files changed, 100 insertions(+), 100 d
From: Grant Likely <[EMAIL PROTECTED]>
USB support for the 8349itx got added a while back; but the defconfig
never got updated. This patch updates defconfig and adds the appropriate
USB config options.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
CC: Scott Wood <[EMAIL PROTECTED]>
CC: Kumar G
Grant Likely wrote:
> On 10/15/07, Scott Wood <[EMAIL PROTECTED]> wrote:
>> For associating a device node with a human readable label, I'd
>> prefer a "label" property in the device node, rather than doing it
>> backwards with aliases.
>
> Here the corresponding problem; having to scan every devic
On 10/15/07, Arnd Bergmann <[EMAIL PROTECTED]> wrote:
> On Monday 15 October 2007, Grant Likely wrote:
> > From: Grant Likely <[EMAIL PROTECTED]>
> >
> > Here's my second version of xilinx device tree bindings. Please review
> > and comment. I'd like to push these out to Paulus in the next couple
On 10/15/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
> > On 10/15/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> >> On Mon, Oct 15, 2007 at 10:57:48AM -0600, Grant Likely wrote:
> >>> Segher is recommending that we use an aliases node as per the open
> >>> firmware example for this
Grant Likely wrote:
> On 10/15/07, Scott Wood <[EMAIL PROTECTED]> wrote:
>> On Mon, Oct 15, 2007 at 10:57:48AM -0600, Grant Likely wrote:
>>> Segher is recommending that we use an aliases node as per the open
>>> firmware example for this. I think in this case it would look
>>> something like this
Eugene Surovegin wrote:
> On Mon, Oct 15, 2007 at 01:53:40PM -0500, Scott Wood wrote:
>> Though, I don't see what the problem with the original approach is,
>> as long as the numbers are chosen in the same way when registering
>> i2c clients based on the children of the adapter node. There's no
>>
On Monday 15 October 2007, Grant Likely wrote:
> From: Grant Likely <[EMAIL PROTECTED]>
>
> Here's my second version of xilinx device tree bindings. Please review
> and comment. I'd like to push these out to Paulus in the next couple
> of days.
There are a few more properties that I can imagine
On 10/15/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Domen Puncer wrote:
> > Hello!
> >
> > If there are no objections, I would like to get this merged
> > when bestcomm goes in (any time now?).
> >
> > It's split into four parts:
> > 1 - device tree
> > 2 - small bestcomm change
> > 3 - the actua
On 10/15/07, Eugene Surovegin <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 15, 2007 at 01:53:40PM -0500, Scott Wood wrote:
> > Though, I don't see what the problem with the original approach is, as long
> > as the numbers are chosen in the same way when registering i2c clients based
> > on the children
On 10/15/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 15, 2007 at 10:57:48AM -0600, Grant Likely wrote:
> > Segher is recommending that we use an aliases node as per the open
> > firmware example for this. I think in this case it would look
> > something like this (but I'm not the exper
On Mon, Oct 15, 2007 at 01:53:40PM -0500, Scott Wood wrote:
> Though, I don't see what the problem with the original approach is, as long
> as the numbers are chosen in the same way when registering i2c clients based
> on the children of the adapter node. There's no concept in the hardware
> itsel
Kumar Gala wrote:
>
> On Oct 15, 2007, at 1:47 PM, Scott Wood wrote:
>
>> On Mon, Oct 15, 2007 at 07:57:30PM +0400, Anton Vorontsov wrote:
>>> On Mon, Oct 15, 2007 at 07:42:12PM +0400, Sergei Shtylyov wrote:
Is the entity described as "localbus" indeed so *board* specific?
>>>
>>> That's
On Oct 15, 2007, at 1:47 PM, Scott Wood wrote:
> On Mon, Oct 15, 2007 at 07:57:30PM +0400, Anton Vorontsov wrote:
>> On Mon, Oct 15, 2007 at 07:42:12PM +0400, Sergei Shtylyov wrote:
>>>Is the entity described as "localbus" indeed so *board* specific?
>>
>> That's what booting-without-of.txt g
Domen Puncer wrote:
> Hello!
>
> If there are no objections, I would like to get this merged
> when bestcomm goes in (any time now?).
>
> It's split into four parts:
> 1 - device tree
> 2 - small bestcomm change
> 3 - the actual driver
> 4 - phy part of the driver
patches #3 and #4 need to be co
Josh Boyer wrote:
> On Mon, 15 Oct 2007 14:53:26 -0400
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
Seems sane to me -- ACK -- but we have multiple people sending me
patches for a single driver. That's normal for janitorial cleanups
across the whole tree, but discouraged when multiple
On Mon, Oct 15, 2007 at 10:57:48AM -0600, Grant Likely wrote:
> Segher is recommending that we use an aliases node as per the open
> firmware example for this. I think in this case it would look
> something like this (but I'm not the expert):
>
> aliases {
> IIC0 = "/path/to/bus/[EMAIL PROTE
On Mon, 15 Oct 2007 14:53:26 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >> Seems sane to me -- ACK -- but we have multiple people sending me
> >> patches for a single driver. That's normal for janitorial cleanups
> >> across the whole tree, but discouraged when multiple people are actively
Josh Boyer wrote:
> On Mon, 15 Oct 2007 14:27:23 -0400
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
>> Valentine Barshak wrote:
>>> This patch adds BCM5248 and Marvell 88E PHY support to NEW EMAC driver.
>>> These PHY chips are used on PowerPC 440EPx boards.
>>> The PHY code is based on the prev
Emil Medve wrote:
> drivers/net/ucc_geth.c: In function 'ucc_geth_rx':
> drivers/net/ucc_geth.c:3483: error: 'dev' undeclared (first use in this
> function)
> drivers/net/ucc_geth.c:3483: error: (Each undeclared identifier is reported
> only once
> drivers/net/ucc_geth.c:3483: error: for each fun
On Mon, 15 Oct 2007 14:27:23 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Valentine Barshak wrote:
> > This patch adds BCM5248 and Marvell 88E PHY support to NEW EMAC driver.
> > These PHY chips are used on PowerPC 440EPx boards.
> > The PHY code is based on the previous work by Stefan Roese
On Mon, Oct 15, 2007 at 07:57:30PM +0400, Anton Vorontsov wrote:
> On Mon, Oct 15, 2007 at 07:42:12PM +0400, Sergei Shtylyov wrote:
> >Is the entity described as "localbus" indeed so *board* specific?
>
> That's what booting-without-of.txt gives as an example.
The board should have been left
Michael Ellerman wrote:
> Now that dcr_host_t contains the base address, we can use that in the
> ibm_newemac code, rather than storing it separately.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
> ---
> drivers/net/ibm_newemac/mal.c |9 +
> drivers/net/ibm_newemac/mal.h |
Hello, I wrote:
>>@@ -797,6 +796,53 @@ void __init clocksource_init(void)
>> clock->name, clock->mult, clock->shift);
>> }
>>+static int decrementer_set_next_event(unsigned long evt,
>>+ struct clock_event_device *dev)
>>+{
>>+ set_dec(evt);
>
Valentine Barshak wrote:
> This patch adds BCM5248 and Marvell 88E PHY support to NEW EMAC driver.
> These PHY chips are used on PowerPC 440EPx boards.
> The PHY code is based on the previous work by Stefan Roese <[EMAIL PROTECTED]>
>
> Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> Signed-
This patch enables NEW EMAC support for PowerPC 440EPx Sequoia board.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/44x/Kconfig |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
--- linux.orig/arch/powerpc/platforms/44x/Kconfig 2007-07-30
1
Benjamin Herrenschmidt wrote:
>>>I'm about to release a new -rt patch based on -rc8. This patch series
>>>blew up totally in trying to get it applied. I'm leaving it out, so after
>>>I release the next series, could you update these patches.
>>No wonder here: the -rt patch already has much of
Hello.
Thomas Gleixner wrote:
>>>No wonder here: the -rt patch already has much of this code since around
>>>2.6.21. They have been submitted by me, mostly... and this patchset is
>>>against the Linus' tree.
>>That would explain it ;-)
>>I was searching the linux-rt-users mailing list for
This patch adds BCM5248 and Marvell 88E PHY support to NEW EMAC driver.
These PHY chips are used on PowerPC 440EPx boards.
The PHY code is based on the previous work by Stefan Roese <[EMAIL PROTECTED]>
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
Signed-off-by: Valentine Barshak <[EMAIL PRO
On Oct 15, 2007, at 12:33 PM, Sergei Shtylyov wrote:
> Anton Vorontsov wrote:
>
>> MPC8568E-MDS have 1 32MB Spansion x16 CFI flash chip. Let's use it.
>
>> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
>
>> diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/
>> boot/dts/mpc856
For anyone using my git tree I've rebased it now that the merge
window for 2.6.24 is ongoing and removed all branches.
The master/HEAD now is in sync with Linus's tree. I'll be starting
of a fixes-2.6.24 branch at some point as well as for-2.6.25 branch.
I'll try to keep the master branch as
Hello.
Tony Breeds wrote:
> Signed-off-by: Tony Breeds <[EMAIL PROTECTED]>
I don't see my own signoff or at least a reference to my prior work in
this patch or even at -rt patch -- despite this code ha clearly borrowed from
it. And I'm not sure why this crippled version (lacking 40x/ Book E
Hi,
On Mon, Oct 15, 2007 at 11:14:44AM -0600, Grant Likely wrote:
> On 10/15/07, Olof Johansson <[EMAIL PROTECTED]> wrote:
> >
> > The flat device tree is, in spite of what some people would like it to be,
> > not open firmware, nor is it the same as their bindings. So I think we'd
> > be doing ou
Anton Vorontsov wrote:
> MPC8568E-MDS have 1 32MB Spansion x16 CFI flash chip. Let's use it.
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts
> b/arch/powerpc/boot/dts/mpc8568mds.dts
> index 8e15dba..1198363 100644
> --- a/arch/powerpc/boo
On Fri, 12 Oct 2007 17:03:05 +0400
Valentine Barshak <[EMAIL PROTECTED]> wrote:
> This patch enables NEW EMAC support for PowerPC 440EPx Sequoia board
> and adds BCM5248 and Marvell 88E PHY support to NEW EMAC driver.
> These PHY chips are used on PowerPC440EPx boards.
> The PHY code is based
1 - 100 of 164 matches
Mail list logo
