On Sat 16 Feb 2008 10:33, Stephen Rothwell pondered:
> On Fri, 15 Feb 2008 16:33:50 +0800 "Bryan Wu" <[EMAIL PROTECTED]> wrote:
> >
> > Could you please add Blackfin tree to the linux-next
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/blackfin-2.6.git
> > for-linus
>
> Added,
On Sat 16 Feb 2008 10:33, Stephen Rothwell pondered:
On Fri, 15 Feb 2008 16:33:50 +0800 Bryan Wu [EMAIL PROTECTED] wrote:
Could you please add Blackfin tree to the linux-next
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/blackfin-2.6.git
for-linus
Added, thanks.
And do
On Wed 6 Feb 2008 14:37, Andrew Morton pondered:
> On Wed, 6 Feb 2008 14:12:50 -0500
> Robin Getz <[EMAIL PROTECTED]> wrote:
>
> > On Wed 6 Feb 2008 11:23, Matt Mackall pondered:
> > >
> > > On Wed, 2008-02-06 at 17:18 +
On Tue 5 Feb 2008 14:56, Robin Getz pondered:
> I was wondering where (or if) there were any non-mainlined gadget
> drivers that
> were kept anywhere?
>
> According to (2005)
> http://www.linux-usb.org/gadget/
>
> > Other controller and gadget
On Tue 5 Feb 2008 14:56, Robin Getz pondered:
I was wondering where (or if) there were any non-mainlined gadget
drivers that
were kept anywhere?
According to (2005)
http://www.linux-usb.org/gadget/
Other controller and gadget drivers are in development, but are
unreleased
On Wed 6 Feb 2008 14:37, Andrew Morton pondered:
On Wed, 6 Feb 2008 14:12:50 -0500
Robin Getz [EMAIL PROTECTED] wrote:
On Wed 6 Feb 2008 11:23, Matt Mackall pondered:
On Wed, 2008-02-06 at 17:18 +0200, Adrian Bunk wrote:
Commit 698dd4ba6b12e34e1e432c944c01478c0b2cd773 broke
On Wed 6 Feb 2008 11:23, Matt Mackall pondered:
>
> On Wed, 2008-02-06 at 17:18 +0200, Adrian Bunk wrote:
> > Commit 698dd4ba6b12e34e1e432c944c01478c0b2cd773 broke blackfin:
> >
> > <-- snip -->
> >
> > ...
> > CC mm/vmscan.o
> > In file included from
> >
On Wed 6 Feb 2008 11:23, Matt Mackall pondered:
On Wed, 2008-02-06 at 17:18 +0200, Adrian Bunk wrote:
Commit 698dd4ba6b12e34e1e432c944c01478c0b2cd773 broke blackfin:
-- snip --
...
CC mm/vmscan.o
In file included from
On Thu 31 Jan 2008 12:27, Paulo Marques pondered:
> Robin Getz wrote:
> > When the kernel needs to find out what symbol is at a specific address, it
> > uses kallsyms_lookup() This seems to work pretty well - almost.
> >
> > The problem is today, we don't to remov
When the kernel needs to find out what symbol is at a specific address, it
uses kallsyms_lookup() This seems to work pretty well - almost.
The problem is today, we don't to remove the symbols from the init section
when the init section is freed. There is invalid data in kallsyms_addresses.
The
When the kernel needs to find out what symbol is at a specific address, it
uses kallsyms_lookup() This seems to work pretty well - almost.
The problem is today, we don't to remove the symbols from the init section
when the init section is freed. There is invalid data in kallsyms_addresses.
The
On Thu 31 Jan 2008 12:27, Paulo Marques pondered:
Robin Getz wrote:
When the kernel needs to find out what symbol is at a specific address, it
uses kallsyms_lookup() This seems to work pretty well - almost.
The problem is today, we don't to remove the symbols from the init section
On Wed 30 Jan 2008 06:00, Jiri Slaby pondered:
> On 01/30/2008 11:36 AM, Bryan Wu wrote:
> > From: Mike Frysinger <[EMAIL PROTECTED]>
> >
> > initial char driver for otp memory
> > (only read supported atm ... needs real examples/docs for write support)
> >
> > Signed-off-by: Mike Frysinger
On Wed 30 Jan 2008 06:00, Jiri Slaby pondered:
On 01/30/2008 11:36 AM, Bryan Wu wrote:
From: Mike Frysinger [EMAIL PROTECTED]
initial char driver for otp memory
(only read supported atm ... needs real examples/docs for write support)
Signed-off-by: Mike Frysinger [EMAIL PROTECTED]
tial
> patch.
>
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> CC: Linus Torvalds <[EMAIL PROTECTED]>
> CC: Adrian Bunk <[EMAIL PROTECTED]>
> CC: Randy Dunlap <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED]
> CC: Robin Getz <[EMAIL PROTECTED]>
]
CC: Adrian Bunk [EMAIL PROTECTED]
CC: Randy Dunlap [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
CC: Robin Getz [EMAIL PROTECTED]
Acked-by: Robin Getz [EMAIL PROTECTED]
---
arch/blackfin/Kconfig |4
1 file changed, 4 insertions(+)
Index: linux-2.6-lttng/arch/blackfin/Kconfig
On Fri 11 Jan 2008 12:52, Robin Getz pondered:
> On Fri 11 Jan 2008 04:35, Pierre Ossman pondered:
> > On Fri, 11 Jan 2008 04:08:53 -0500
> > "Mike Frysinger" <[EMAIL PROTECTED]> wrote:
> >
> > > On Jan 11, 2008 3:40 AM, Pierre Ossman <[EMAIL PRO
On Fri 11 Jan 2008 12:52, Robin Getz pondered:
On Fri 11 Jan 2008 04:35, Pierre Ossman pondered:
On Fri, 11 Jan 2008 04:08:53 -0500
Mike Frysinger [EMAIL PROTECTED] wrote:
On Jan 11, 2008 3:40 AM, Pierre Ossman [EMAIL PROTECTED] wrote:
So it's far more probable that you've
On Fri 11 Jan 2008 04:35, Pierre Ossman pondered:
> On Fri, 11 Jan 2008 04:08:53 -0500
> "Mike Frysinger" <[EMAIL PROTECTED]> wrote:
>
> > On Jan 11, 2008 3:40 AM, Pierre Ossman <[EMAIL PROTECTED]> wrote:
> > > So it's far more probable that you've misdiagnosed your error than
> this being the
On Fri 11 Jan 2008 04:35, Pierre Ossman pondered:
On Fri, 11 Jan 2008 04:08:53 -0500
Mike Frysinger [EMAIL PROTECTED] wrote:
On Jan 11, 2008 3:40 AM, Pierre Ossman [EMAIL PROTECTED] wrote:
So it's far more probable that you've misdiagnosed your error than
this being the actual problem.
On Thu 3 Jan 2008 12:04, Richard D pondered:
> Does all USB Host controller hardware have the ability to disable PING?
I think they do. (or at least should)...
http://www.intel.com/technology/usb/download/ehci-r10.pdf
==
4.11 Ping Control (page 88)
USB 2.0 defines an addition to
On Thu 3 Jan 2008 12:04, Richard D pondered:
Does all USB Host controller hardware have the ability to disable PING?
I think they do. (or at least should)...
http://www.intel.com/technology/usb/download/ehci-r10.pdf
==
4.11 Ping Control (page 88)
USB 2.0 defines an addition to
On Wed 2 Jan 2008 22:43, David Brownell pondered:
> This patch might be improved slightly -- in ways that, as I
> understand things, could save some RAM on Blackfin! -- by
> having the BLACKLIST_HUB option get rid of the transaction
> translator support (changing C code not just Kconfig).
> It's
On Wed 2 Jan 2008 13:47, David Brownell pondered:
> On Wednesday 02 January 2008, Robin Getz wrote:
> > From: Robin Getz <[EMAIL PROTECTED]>
> >
> > Allow embedded developers to turn support for USB Hubs off even if
> > they have a full root hub. This saves
From: Robin Getz <[EMAIL PROTECTED]>
Allow embedded developers to turn support for USB Hubs off even if they have a
full root hub. This saves the overhead (RAM and Flash size).
Allow embedded developers the capabilities of the "otg_whitelist.h" - a
product whitelist, so
From: Robin Getz [EMAIL PROTECTED]
Allow embedded developers to turn support for USB Hubs off even if they have a
full root hub. This saves the overhead (RAM and Flash size).
Allow embedded developers the capabilities of the otg_whitelist.h - a
product whitelist, so USB peripherals not listed
On Wed 2 Jan 2008 13:47, David Brownell pondered:
On Wednesday 02 January 2008, Robin Getz wrote:
From: Robin Getz [EMAIL PROTECTED]
Allow embedded developers to turn support for USB Hubs off even if
they have a full root hub. This saves the overhead (RAM and Flash size).
ISTR
On Wed 2 Jan 2008 22:43, David Brownell pondered:
This patch might be improved slightly -- in ways that, as I
understand things, could save some RAM on Blackfin! -- by
having the BLACKLIST_HUB option get rid of the transaction
translator support (changing C code not just Kconfig).
It's pretty
Nick:
In Apr 2006, you sent around some patches
> vm_insert_page and remap_pfn_range loops are really clever, bit
> probably asking a bit too much of most drivers. I was able to get
> rid of most of them without too much trouble.
http://lkml.org/lkml/2006/4/20/196
It doesn't seem like those
Nick:
In Apr 2006, you sent around some patches
vm_insert_page and remap_pfn_range loops are really clever, bit
probably asking a bit too much of most drivers. I was able to get
rid of most of them without too much trouble.
http://lkml.org/lkml/2006/4/20/196
It doesn't seem like those made
On Sat 29 Dec 2007 01:23, Mathieu Desnoyers pondered:
> Ok, and do we really need to make HARDWARE_PM a tristate ? I see that
> part of it must be compiled into the kernel in core .S files. Does it
> really make sense for it to be a module ?
I don't think so.
> Also, op_model_bf533.c sits in the
On Sat 29 Dec 2007 01:23, Mathieu Desnoyers pondered:
Ok, and do we really need to make HARDWARE_PM a tristate ? I see that
part of it must be compiled into the kernel in core .S files. Does it
really make sense for it to be a module ?
I don't think so.
Also, op_model_bf533.c sits in the
On Fri 28 Dec 2007 14:28, Mathieu Desnoyers pondered:
> * Adrian Bunk ([EMAIL PROTECTED]) wrote:
> > On Fri, Dec 28, 2007 at 02:14:04PM -0500, Mathieu Desnoyers wrote:
> > > * Adrian Bunk ([EMAIL PROTECTED]) wrote:
> > > > This patch restores the blackfin Hardware Performance Monitor Profiling
>
On Fri 28 Dec 2007 14:28, Mathieu Desnoyers pondered:
* Adrian Bunk ([EMAIL PROTECTED]) wrote:
On Fri, Dec 28, 2007 at 02:14:04PM -0500, Mathieu Desnoyers wrote:
* Adrian Bunk ([EMAIL PROTECTED]) wrote:
This patch restores the blackfin Hardware Performance Monitor Profiling
support
On Sat 24 Nov 2007 02:15, Bryan Wu pondered:
> On Nov 24, 2007 2:43 PM, David Woodhouse <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, 2007-11-23 at 17:04 -0500, Robin Getz wrote:
> > > It could be a runtime if() but we don't currently have the is_mach() a
On Sat 24 Nov 2007 02:15, Bryan Wu pondered:
On Nov 24, 2007 2:43 PM, David Woodhouse [EMAIL PROTECTED] wrote:
On Fri, 2007-11-23 at 17:04 -0500, Robin Getz wrote:
It could be a runtime if() but we don't currently have the is_mach() all
set up properly today.
This is because
On Fri 23 Nov 2007 16:52, Arjan van de Ven pondered:
> On Fri, 23 Nov 2007 22:25:29 +0800
> "Bryan Wu" <[EMAIL PROTECTED]> wrote:
>
> > On Nov 23, 2007 6:19 PM, David Woodhouse <[EMAIL PROTECTED]> wrote:
> > >
> > > On Fri, 2007-11-23 at 18:14 +0800, Bryan Wu wrote:
> > > >
> > > > +#ifdef
On Fri 23 Nov 2007 16:52, Arjan van de Ven pondered:
On Fri, 23 Nov 2007 22:25:29 +0800
Bryan Wu [EMAIL PROTECTED] wrote:
On Nov 23, 2007 6:19 PM, David Woodhouse [EMAIL PROTECTED] wrote:
On Fri, 2007-11-23 at 18:14 +0800, Bryan Wu wrote:
+#ifdef CONFIG_BF54x
/*
On Mon 29 Oct 2007 18:22, Andrew Morton pondered:
> I hit numerous rejects here. I am not sure which kernel you patched but
> I suspect it was not an up-to-date one.
Sorry about that - I will do so in the future. Thanks for reviewing and fixing
up.
> > --- kernel/kallsyms.c (revision
On Mon 29 Oct 2007 18:22, Andrew Morton pondered:
I hit numerous rejects here. I am not sure which kernel you patched but
I suspect it was not an up-to-date one.
Sorry about that - I will do so in the future. Thanks for reviewing and fixing
up.
--- kernel/kallsyms.c (revision 3780)
From: Robin Getz <[EMAIL PROTECTED]>
when passing a zero address to kallsyms_lookup(), the kernel thought it was a
valid kernel address, even if it is not. This is because is_ksym_addr() called
is_kernel_extratext() and checked against labels that don't exist on many
archs (which d
On Wed 24 Oct 2007 08:36, Robin Getz pondered:
> Paul:
>
> I noticed that when passing a zero address to kallsyms_lookup(), the
> kernel thought it was a valid kernel address, even if it was not for the
> specific architecture it was running on.
>
> This was becaus
On Wed 24 Oct 2007 08:36, Robin Getz pondered:
Paul:
I noticed that when passing a zero address to kallsyms_lookup(), the
kernel thought it was a valid kernel address, even if it was not for the
specific architecture it was running on.
This was because is_kernel_extratext() was checking
From: Robin Getz [EMAIL PROTECTED]
when passing a zero address to kallsyms_lookup(), the kernel thought it was a
valid kernel address, even if it is not. This is because is_ksym_addr() called
is_kernel_extratext() and checked against labels that don't exist on many
archs (which default as zero
Paul:
I noticed that when passing a zero address to kallsyms_lookup(), the kernel
thought it was a valid kernel address, even if it was not for the specific
architecture I was running things on.
This was because is_kernel_extratext() was checking against labels that don't
exist on many archs.
Paul:
I noticed that when passing a zero address to kallsyms_lookup(), the kernel
thought it was a valid kernel address, even if it was not for the specific
architecture I was running things on.
This was because is_kernel_extratext() was checking against labels that don't
exist on many archs.
On Wed 17 Oct 2007 10:07, Jean Delvare pondered:
> Hi Bryan,
>
> On Wed, 17 Oct 2007 15:12:00 +0800, Bryan Wu wrote:
> > Subject: [PATCH try #4] Input/Joystick Driver: add support AD7142
> joystick driver
> > +#define AD7142_I2C_ADDR0x2C
>
> Not worth a define IMHO, as you use it
On Wed 17 Oct 2007 10:07, Jean Delvare pondered:
Hi Bryan,
On Wed, 17 Oct 2007 15:12:00 +0800, Bryan Wu wrote:
Subject: [PATCH try #4] Input/Joystick Driver: add support AD7142
joystick driver
+#define AD7142_I2C_ADDR0x2C
Not worth a define IMHO, as you use it only once and
On Mon 15 Oct 2007 16:33, Andrew Morton pondered:
>
> > Subject: [PATCH 3/3] Blackfin serial driver: this driver enable SPORTs
> on Blackfin emulate UART
>
> That's a bit hard to parse.
>
Blackfin's have a synchronous Serial Peripheral pORT (SPORT).
Unlike SPI, UART, I2C, or CAN interfaces
On Mon 15 Oct 2007 16:33, Andrew Morton pondered:
Subject: [PATCH 3/3] Blackfin serial driver: this driver enable SPORTs
on Blackfin emulate UART
That's a bit hard to parse.
Blackfin's have a synchronous Serial Peripheral pORT (SPORT).
Unlike SPI, UART, I2C, or CAN interfaces which
On Fri 5 Oct 2007 09:13, Ralf Baechle pondered:
> And btw why does Analog list half their employees in the MAINTAINERS
> entry?
> Seems a little over the top ...
Yeah, the original submission got a little carried away...
We can cut that down to just Bryan and the mailing list I think.
-Robin
-
On Fri 5 Oct 2007 09:13, Ralf Baechle pondered:
And btw why does Analog list half their employees in the MAINTAINERS
entry?
Seems a little over the top ...
Yeah, the original submission got a little carried away...
We can cut that down to just Bryan and the mailing list I think.
-Robin
-
To
On Tue 2 Oct 2007 07:30, Kalle Pokki pondered:
> The Blackfin Ethernet MAC driver does not compile. It seems the driver is
> missing some pinmux defines.
>
> CC drivers/net/bfin_mac.o
> drivers/net/bfin_mac.c: In function 'setup_pin_mux':
> drivers/net/bfin_mac.c:275: error: 'P_MII0'
On Tue 2 Oct 2007 07:30, Kalle Pokki pondered:
The Blackfin Ethernet MAC driver does not compile. It seems the driver is
missing some pinmux defines.
CC drivers/net/bfin_mac.o
drivers/net/bfin_mac.c: In function 'setup_pin_mux':
drivers/net/bfin_mac.c:275: error: 'P_MII0' undeclared
On Mon 1 Oct 2007 12:27, [EMAIL PROTECTED] pondered:
> overcommit by default is optimistic that if the program requesting the
> memory actually tries to use it there will be enough (both the fork-exec
> situation and the copy-on-write memory of real forks mean that the
> system ends up useing
On Mon 1 Oct 2007 12:27, [EMAIL PROTECTED] pondered:
overcommit by default is optimistic that if the program requesting the
memory actually tries to use it there will be enough (both the fork-exec
situation and the copy-on-write memory of real forks mean that the
system ends up useing much
On Thu 20 Sep 2007 11:03, David McCullough pondered:
> I would say that (a) is definately not the case. I am sure the BF guys
> will say they have been banging us on the head with changes for a long
> time and getting no where as we considered the changes to severe or out
> of line.
I don't
On Wed 19 Sep 2007 23:54, Paul Mundt pondered:
> On Wed, Sep 19, 2007 at 11:42:53PM -0400, Mike Frysinger wrote:
> > On 9/19/07, Paul Mundt <[EMAIL PROTECTED]> wrote:
> > > On Thu, Sep 20, 2007 at 11:55:25AM +1000, David McCullough wrote:
> > > > Jivin Robin Ge
On Wed 19 Sep 2007 23:54, Paul Mundt pondered:
On Wed, Sep 19, 2007 at 11:42:53PM -0400, Mike Frysinger wrote:
On 9/19/07, Paul Mundt [EMAIL PROTECTED] wrote:
On Thu, Sep 20, 2007 at 11:55:25AM +1000, David McCullough wrote:
Jivin Robin Getz lays it down ...
On Tue 18 Sep 2007 04:09
On Thu 20 Sep 2007 11:03, David McCullough pondered:
I would say that (a) is definately not the case. I am sure the BF guys
will say they have been banging us on the head with changes for a long
time and getting no where as we considered the changes to severe or out
of line.
I don't think we
On Wed 19 Sep 2007 21:55, David McCullough pondered:
> Jivin Robin Getz lays it down ...
> > On Tue 18 Sep 2007 04:09, Bryan Wu pondered:
> > > From: Bernd Schmidt <[EMAIL PROTECTED]>
> > >
> > > This just adds minimum support for the Blackfin relocatio
On Tue 18 Sep 2007 04:09, Bryan Wu pondered:
> From: Bernd Schmidt <[EMAIL PROTECTED]>
>
> This just adds minimum support for the Blackfin relocations,
> since we don't have enough space in each reloc. The idea
> is to store a value with one relocation so that subsequent ones can
> access it.
>
On Tue 18 Sep 2007 04:09, Bryan Wu pondered:
From: Bernd Schmidt [EMAIL PROTECTED]
This just adds minimum support for the Blackfin relocations,
since we don't have enough space in each reloc. The idea
is to store a value with one relocation so that subsequent ones can
access it.
On Wed 19 Sep 2007 21:55, David McCullough pondered:
Jivin Robin Getz lays it down ...
On Tue 18 Sep 2007 04:09, Bryan Wu pondered:
From: Bernd Schmidt [EMAIL PROTECTED]
This just adds minimum support for the Blackfin relocations,
since we don't have enough space in each reloc
On Sat 15 Sep 2007 22:57, Bryan Wu pondered:
>
> - add MDIO functions and register mdio bus
> - add phy abstraction layer (PAL) functions and use PAL API
> - test on STAMP537 board
Today, the Kconfig for the Blackfin just includes:
> config BFIN_MAC
> tristate "Blackfin 536/537
On Sat 15 Sep 2007 22:57, Bryan Wu pondered:
- add MDIO functions and register mdio bus
- add phy abstraction layer (PAL) functions and use PAL API
- test on STAMP537 board
Today, the Kconfig for the Blackfin just includes:
config BFIN_MAC
tristate Blackfin 536/537 on-chip mac
On Thu 13 Sep 2007 14:28, Josh Boyer pondered:
> On 9/12/07, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > Since AMD shunted its flash memory division, the URI in the mtd Kconfig is
> > now
> > broken, so the attached patch points people to Wikipedia.
> >
> > Signed-off-by: Mike Frysinger <[EMAIL
On Thu 13 Sep 2007 14:28, Josh Boyer pondered:
On 9/12/07, Mike Frysinger [EMAIL PROTECTED] wrote:
Since AMD shunted its flash memory division, the URI in the mtd Kconfig is
now
broken, so the attached patch points people to Wikipedia.
Signed-off-by: Mike Frysinger [EMAIL PROTECTED]
On Sat 1 Sep 2007 18:08, Andi Kleen pondered:
> "Mike Frysinger" <[EMAIL PROTECTED]> writes:
>
> > is there any sort of standard for testing and integration into
> > mainline ?
>
> Everybody does their own.
That kind of stinks - and seems to be a potential duplication of effort all
over the
On Sat 1 Sep 2007 18:08, Andi Kleen pondered:
Mike Frysinger [EMAIL PROTECTED] writes:
is there any sort of standard for testing and integration into
mainline ?
Everybody does their own.
That kind of stinks - and seems to be a potential duplication of effort all
over the place.
in
On Fri 31 Aug 2007 17:22, Mike Frysinger pondered:
> is there any sort of standard for testing and integration into
> mainline ? in the Blackfin world, we've been developing little
> external kernel modules and adding them to our own testsuite, but
> often times these things are not Blackfin
On Fri 31 Aug 2007 17:22, Mike Frysinger pondered:
is there any sort of standard for testing and integration into
mainline ? in the Blackfin world, we've been developing little
external kernel modules and adding them to our own testsuite, but
often times these things are not Blackfin
From: Robin Getz <[EMAIL PROTECTED]>
Gerd Hoffmann pointed out that my patch from yesterday can lead
to a null pointer dereference if the kernel is booted with no
console, and no earlyprintk defined. This fixes that issue.
printk.c | 10 ++
1 file changed, 6 insertions
From: Robin Getz [EMAIL PROTECTED]
Gerd Hoffmann pointed out that my patch from yesterday can lead
to a null pointer dereference if the kernel is booted with no
console, and no earlyprintk defined. This fixes that issue.
printk.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions
Try #4... (sorry)
From: Robin Getz <[EMAIL PROTECTED]>
This is a followup to the cleanups for earlyprintk patch from Gerd Hoffmann
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511
This ensures that a bootc
Try #3...
From: Robin Getz <[EMAIL PROTECTED]>
This is a followup to the cleanups for earlyprintk patch from Gerd Hoffmann
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511
This ensures that a bootconsole is unregi
Try #3...
From: Robin Getz [EMAIL PROTECTED]
This is a followup to the cleanups for earlyprintk patch from Gerd Hoffmann
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511
This ensures that a bootconsole is unregistered
Try #4... (sorry)
From: Robin Getz [EMAIL PROTECTED]
This is a followup to the cleanups for earlyprintk patch from Gerd Hoffmann
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511
This ensures that a bootconsole
From: Robin Getz <[EMAIL PROTECTED]>
This is a followup to the cleanups for earlyprintk patch from Gerd Hoffmann
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511
This ensures that a bootconsole is unregi
From: Robin Getz <[EMAIL PROTECTED]>
This is a followup to the cleanups for earlyprintk patch from Gerd Hoffmann
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511
This ensures that a bootconsole is unregi
On Sun 19 Aug 2007 17:54, David Brownell pondered:
> On Saturday 18 August 2007, Robin Getz wrote:
>
> > I don't see how early/late makes the problem easier/worse to debug. No
> > matter when you do it - the driver refuses to install (or at least
> > should).
>
&g
On Sun 19 Aug 2007 17:54, David Brownell pondered:
On Saturday 18 August 2007, Robin Getz wrote:
I don't see how early/late makes the problem easier/worse to debug. No
matter when you do it - the driver refuses to install (or at least
should).
If you arrange to *reliably* detect
From: Robin Getz [EMAIL PROTECTED]
This is a followup to the cleanups for earlyprintk patch from Gerd Hoffmann
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511
This ensures that a bootconsole is unregistered
From: Robin Getz [EMAIL PROTECTED]
This is a followup to the cleanups for earlyprintk patch from Gerd Hoffmann
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511
This ensures that a bootconsole is unregistered
On Fri 17 Aug 2007 18:34, David Brownell pondered:
> On Friday 17 August 2007, Robin Getz wrote:
> > On Fri 17 Aug 2007 14:24, David Brownell pondered:
> > > Just for the record, this is an unusual way to use these calls.
> >
> > That is part of the natural evolutio
On Sat 18 Aug 2007 02:23, Sam Ravnborg pondered:
> > > What was preventing you from just using the x86_64 code here?
> >
> > Some was borrowed - but not much. since we don't support vga, or
> > 16550 UARTs (Blackfin has it's own on-chip UART), I don't think
> > this would work. Everyone
On Sat 18 Aug 2007 02:23, Sam Ravnborg pondered:
What was preventing you from just using the x86_64 code here?
Some was borrowed - but not much. since we don't support vga, or
16550 UARTs (Blackfin has it's own on-chip UART), I don't think
this would work. Everyone implements
On Fri 17 Aug 2007 18:34, David Brownell pondered:
On Friday 17 August 2007, Robin Getz wrote:
On Fri 17 Aug 2007 14:24, David Brownell pondered:
Just for the record, this is an unusual way to use these calls.
That is part of the natural evolution of the kernel isn't it - per
James's
On Fri 17 Aug 2007 17:10, David Brownell pondered:
> On the other hand, maybe you want your "typical" customer to
> be more of a systems integrator than anything else.
We are getting yelled at by our customers (I was on the phone yesterday),
because the kernel build environment we distribute
On Fri 17 Aug 2007 14:24, David Brownell pondered:
> Just for the record, this is an unusual way to use these calls.
That is part of the natural evolution of the kernel isn't it - per James's
keynote at OLS - you release something, and see how people [ab]use it until
it either grows, evolves,
On Fri 17 Aug 2007 17:09, Mike Frysinger pondered:
> On 8/17/07, Robin Getz <[EMAIL PROTECTED]> wrote:
> >
> > Something like:
> >
> > Index: kernel/printk.c
> > ===
> > --- kernel/printk.
On Fri 17 Aug 2007 03:49, Gerd Hoffmann pondered:
> Mike Frysinger wrote:
> >> Hmm, sort of, although I didn't think about the case of no real console
> >> replacing the early console. The intention of the patch is to have a
> >> smooth handover from the boot console to the real console. And,
ed by
* a CPLB. This is needed to ensure we don't get double fault conditions
> -> adds early_printk
Index: linux-2.6.x/include/asm-blackfin/early_printk.h
===
--- linux-2.6.x/include/asm-blackfin/early_printk.h (revision 0)
+++ linux-2.6.x/include/asm-blackfin/
On Fri 17 Aug 2007 13:57, Mike Frysinger pondered:
> On 8/17/07, Robin Getz <[EMAIL PROTECTED]> wrote:
> > +int __init disable_early_printk(void)
> > +{
> > + if (!early_console_initialized)
> > + return 0;
> > +
> >
y_printk.h
===
--- linux-2.6.x/include/asm-blackfin/early_printk.h (revision 0)
+++ linux-2.6.x/include/asm-blackfin/early_printk.h (revision 0)
@@ -0,0 +1,28 @@
+/*
+ * File: include/asm-blackfin/early_printk.h
+ * Author: Robin Getz <[EMAIL PROTECTED]
+ *
+ * Created: 14Aug2007
+
-2.6.x/include/asm-blackfin/early_printk.h (revision 0)
+++ linux-2.6.x/include/asm-blackfin/early_printk.h (revision 0)
@@ -0,0 +1,28 @@
+/*
+ * File: include/asm-blackfin/early_printk.h
+ * Author: Robin Getz [EMAIL PROTECTED]
+ *
+ * Created: 14Aug2007
+ * Description
On Fri 17 Aug 2007 13:57, Mike Frysinger pondered:
On 8/17/07, Robin Getz [EMAIL PROTECTED] wrote:
+int __init disable_early_printk(void)
+{
+ if (!early_console_initialized)
+ return 0;
+
+ printk(KERN_INFO Unregister %s%d\n,
early_console_initialized-name
+ * Author: Robin Getz [EMAIL PROTECTED]
+ *
+ * Created: 14Aug2007
+ * Description: function prototpyes for early printk
+ *
+ * Modified:
+ * Copyright 2004-2007 Analog Devices Inc.
+ *
+ * Bugs: Enter bugs at http://blackfin.uclinux.org/
+ *
+ * This program is free
On Fri 17 Aug 2007 03:49, Gerd Hoffmann pondered:
Mike Frysinger wrote:
Hmm, sort of, although I didn't think about the case of no real console
replacing the early console. The intention of the patch is to have a
smooth handover from the boot console to the real console. And, yes, if
no
On Fri 17 Aug 2007 17:09, Mike Frysinger pondered:
On 8/17/07, Robin Getz [EMAIL PROTECTED] wrote:
Something like:
Index: kernel/printk.c
===
--- kernel/printk.c (revision 3568)
+++ kernel/printk.c (working copy
1 - 100 of 224 matches
Mail list logo
