* RE: MPC8245 with its internal UART
From: Heiko Schocher @ 2005-12-13 8:01 UTC (permalink / raw)
To: HappyPhot; +Cc: linuxppc-embedded
In-Reply-To: <003201c5ffb9$fe0d6310$0760120a@photon>
Hello,
On Tuesday, December 13, 2005 8:51 AM HappyPhot wrote:
> Hi,
> I get this one "linuxppc_2_4_devel-2005-10-25-1440.tar.bz2"
> and try "make CPC45_defconfig". But it shows "No rule to make target
> ...." Did I do something wrong ?
Try "make CPC45_config"
It works fine on my PC ...
Bets regards,
Heiko
^ permalink raw reply
* Re: Can we compile them with eldk and debug them with BDI2000?
From: Wolfgang Denk @ 2005-12-13 8:18 UTC (permalink / raw)
To: zengshuai; +Cc: ppc
In-Reply-To: <31064960.1134445714325.JavaMail.postfix@mx3.mail.sohu.com>
In message <31064960.1134445714325.JavaMail.postfix@mx3.mail.sohu.com> you wrote:
> thanks a lot.Would you give me more inf,please?
I'm afraid this is off topic on this list.
> There were a test.c.
> When we use "ppc_6xx-gcc -o test test.c",we can get a "test" which can running in Linux.
> How can we get a "test" which can running in bareboard and be debuged using the BDI2000?
> Would you give a flag example?
See the U-Boot source code. U-Boot itself is just such a bare-silicon
application program (a pretty complex one, though). Also see the
examples/ directory which contains code for several simple standalone
applications within the U-Boot context.
Note that you will have to understand how the linker works, and know
exactly what you are doing.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Four thousand throats may be cut in one night by a running man.
-- Klingon Soldier, "Day of the Dove", stardate unknown
^ permalink raw reply
* HZ manipulation
From: Wojciech Kromer @ 2005-12-13 8:31 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]
I have 2.4.25 kernel from denx.de and latest uClibc running on mpc8248.
I'm trying to change HZ value, but still have strange results with
simple test
Recompiling whole uClibc does not change the results.
What could be wrong?
with HZ==1000:
#
alarm_test
alarm fired after
0.099092s
slept 0.999769s
with HZ==500:
#
alarm_test
alarm fired after
0.199622s
slept 0.999761s
with HZ==100:
# alarm_test
alarm fired after 0.999693s
slept 0.999760s
- here is procesor id :
... by kernel:
# cat /proc/cpuinfo
processor : 0
cpu : 8280
core clock : 400 MHz
CPM clock : 200 MHz
bus clock : 100 MHz
revision : 32.20 (pvr 8082 2014)
bogomips : 266.24
... and by u-boot:
MPC8248 Reset Status: External Soft, External
Hard
MPC8248 Clock
Configuration
- Bus-to-Core Mult 4x, VCO Div 2, 60x Bus Freq 25-75 , Core Freq
100-300
- dfbrg 1, corecnf 0x1a, busdf 3, cpmdf 1, plldf 0, pllmf
3
- vco_out 400000000, scc_clk 100000000, brg_clk
25000000
- cpu_clk 400000000, cpm_clk 200000000, bus_clk
100000000
- pci_clk
66666666
CPU: MPC8248 (HiP7 Rev 14, Mask 1.0 1K50M) at 400 MHz
- test code included
[-- Attachment #2: alarm_test.c --]
[-- Type: text/x-csrc, Size: 908 bytes --]
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <sys/time.h>
static void sighand(int sig)
{
}
int main()
{
struct timeval tv1, tv2;
sigset_t set;
sigfillset(&set);
sigdelset(&set, SIGALRM);
sigdelset(&set, SIGINT);
signal(SIGALRM, sighand);
gettimeofday(&tv1, NULL);
alarm(1);
sigsuspend(&set);
gettimeofday(&tv2, NULL);
tv1.tv_sec = tv2.tv_sec - tv1.tv_sec - (tv2.tv_usec < tv1.tv_usec);
tv1.tv_usec = tv2.tv_usec - tv1.tv_usec + (tv2.tv_usec < tv1.tv_usec) * 1000000;
printf("alarm fired after %ld.%06lds\n",tv1.tv_sec, tv1.tv_usec);
//--------------------
gettimeofday(&tv1, NULL);
sleep(1);
gettimeofday(&tv2, NULL);
tv1.tv_sec = tv2.tv_sec - tv1.tv_sec - (tv2.tv_usec < tv1.tv_usec);
tv1.tv_usec = tv2.tv_usec - tv1.tv_usec + (tv2.tv_usec < tv1.tv_usec) * 1000000;
printf("slept %ld.%06lds\n",tv1.tv_sec, tv1.tv_usec);
return 0;
}
^ permalink raw reply
* Re: HZ manipulation
From: Wojciech Kromer @ 2005-12-13 13:36 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <439E86DC.4010901@dgt.com.pl>
Found it!
Sorry, It was my error.
I have few #ifdef-s to determine HZ value depend on selected board,
but in some (for example itimer.c and timer.c) files <linux/config.h> is
NOT included
before <asm/param.h> is included sowhere in the dark....
So some code was compiled with default value
^ permalink raw reply
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
From: Simon Richter @ 2005-12-13 13:34 UTC (permalink / raw)
To: Adrian Bunk
Cc: tony.luck, linux-ia64, grundler, matthew, linux-kernel,
linuxppc-dev, lethal, linux-mtd, dwmw2, kkojima, parisc-linux
In-Reply-To: <20051213001028.GS23349@stusta.de>
[-- Attachment #1: Type: text/plain, Size: 752 bytes --]
Hi,
Adrian Bunk wrote:
>>It's a problem introduced by your patch because the resulting defconfig
>>file becomes _wrong_ by your change, and other changes in the defconfig
>>are thereby hidden.
>>...
> No, CONFIG_BROKEN=y in a defconfig file is a bug.
Indeed, but that's not the point. A defconfig file should be the result
of running one of the various configuration targets; yours are
hand-patched. If you run the defconfig target, it will copy the config
file and run oldconfig, thus resulting in a different configuration file
(because options may now be gone and hence disabled) than what was in
the defconfig, and thus people may come to the wrong conclusion that if
a driver is enabled in a defconfig file, it will be built.
Simon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply
* Re: ibm emac driver update
From: Simon Haynes @ 2005-12-13 14:35 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051212181457.GA30505@gate.ebshome.net>
Eugine,
Thanks for the reply. I am not familiar with git and I do not
have it installed on my system. I have looked for rpms and
tried to build git. It seems that I will need to make a lot of changes
to my system to get this going.
In a response from Wolfgang he lists a url which can be used to access
his git tree via a browser. I can not find these patch files on his git tree
but I was wondering if you made the files available in a similar way.
Alternatively can you mail the file to me ?
Or can you tell me if the files are somewhere on
http://www.denx.de/cgi-bin/gitweb.cgi?p=linux-2.6-denx.git
If not I guess I will just have to get all the bits together to run
git and learn how to drive it.
Many Thanks
Simon.
On Monday 12 December 2005 18:14, Eugene Surovegin wrote:
> On Mon, Dec 12, 2005 at 05:26:34PM +0000, Simon Haynes wrote:
> > I am running a Ebony board with linux-2.6.12-rc1 and I amd having
> > intermittent network problems. Having searched the archives it would seem
> > that the driver for the IBM EMAC is buggy ?
> >
> > I have tried to patch my kernel with
> >
> > http://kernel.ebsname.net/emac/4xx_napi_emac.diff
> >
> > I believe this is almost a total driver re-write. Is this correct ?
> >
> > After having a couple of problems applying the patch, Kconfig and
> > ibm_emac_core.c. I fixed up the original code and applied the patch.
> >
> > On compilation the build fails with missing references to kzalloc,
> > which I guess I could easily fix with kmalloc and memset.
> >
> > However there is also an undefined field, dcr_base, in the
> > ocp_func_mal_data structure. This structure appears to be defined in
> > include/asm/ibm_ocp.h and this file does not appear to be changed by the
> > patch. I guess this patch is for a later kernel.
> >
> > Can anyone point me in the direction of a suitable patch for this kernel
> > ?
>
> I'm not sure about 2.6.12-rc1, but you can try GIT tree/patches at
> http://kernel.ebshome.net.
>
> Hint: you can assume that in addition to emac_3-2.6-28.diff, there are
> also emac_3-2.6-NN.diff (NN < 28) on my website which were made for
> earlier kernel versions :).
>
> Alternatively, you can backport all relevant stuff from current 2.6 or
> you can pay someone to do this for you.
^ permalink raw reply
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
From: Adrian Bunk @ 2005-12-13 14:00 UTC (permalink / raw)
To: Simon Richter
Cc: tony.luck, linux-ia64, grundler, matthew, linux-kernel,
linuxppc-dev, lethal, linux-mtd, dwmw2, kkojima, parisc-linux
In-Reply-To: <439ECDCC.80707@hogyros.de>
On Tue, Dec 13, 2005 at 02:34:04PM +0100, Simon Richter wrote:
> Hi,
Hi Simon,
> Adrian Bunk wrote:
>
> >>It's a problem introduced by your patch because the resulting defconfig
> >>file becomes _wrong_ by your change, and other changes in the defconfig
> >>are thereby hidden.
> >>...
>
> >No, CONFIG_BROKEN=y in a defconfig file is a bug.
>
> Indeed, but that's not the point. A defconfig file should be the result
> of running one of the various configuration targets; yours are
> hand-patched. If you run the defconfig target, it will copy the config
> file and run oldconfig, thus resulting in a different configuration file
> (because options may now be gone and hence disabled) than what was in
> the defconfig, and thus people may come to the wrong conclusion that if
> a driver is enabled in a defconfig file, it will be built.
defconfig files are virtually never a configuration for the kernel they
are shipped with since they aren't updated every time some configuration
option is changed.
Consider a defconfig with CONFIG_BROKEN=n, and a driver that is enabled
in this defconfig gets for some reason marked as broken in the Kconfig
file - this will give exactly the same result as the one you describe.
> Simon
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: chrdevs[] explained
From: Kumar Gala @ 2005-12-13 14:40 UTC (permalink / raw)
To: Gabe.Johnson; +Cc: linuxppc-embedded
In-Reply-To: <OFDEA31089.DE015378-ON862570D5.005B4F12-862570D5.005B7940@microware.com>
On Dec 12, 2005, at 10:38 AM, Gabe.Johnson@radisys.com wrote:
>
> Could someone explain to me the chrdevs array found in fs/
> char_dev.c how does that get populated and with what does it get
> populated?
This is a pretty generic kernel question, I would suggest posting to
linux-kernel as it not really powerpc specific.
- kumar
^ permalink raw reply
* Re: [PATCH] powerpc: Update MPIC workarounds
From: Olof Johansson @ 2005-12-13 16:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc64-dev, linuxppc-dev list
In-Reply-To: <1134457469.6989.189.camel@gaston>
On Tue, Dec 13, 2005 at 06:04:29PM +1100, Benjamin Herrenschmidt wrote:
> From: Segher Boessenkool <segher@kernel.crashing.org>
>
> Cleanup the MPIC IO-APIC workarounds, make them a bit more generic,
> smaller and faster.
I really don't like all the hand-coded constants in this code. They're
all over the place, and there's no descriptions of what they are there
for. Lots of hardcoded offsets, etc. Since this is a cleanup, wouldn't
it be a good time to use symbolic constands and/or comment them up a
bit?
> Index: linux-work/arch/powerpc/sysdev/mpic.c
> ===================================================================
> --- linux-work.orig/arch/powerpc/sysdev/mpic.c 2005-12-06 16:17:43.000000000 +1100
> +++ linux-work/arch/powerpc/sysdev/mpic.c 2005-12-07 13:30:45.000000000 +1100
> @@ -175,57 +175,57 @@ static inline int mpic_is_ht_interrupt(s
> return mpic->fixups[source_no].base != NULL;
> }
>
> +
> static inline void mpic_apic_end_irq(struct mpic *mpic, unsigned int source_no)
> {
> struct mpic_irq_fixup *fixup = &mpic->fixups[source_no];
> - u32 tmp;
>
> spin_lock(&mpic->fixup_lock);
> - writeb(0x11 + 2 * fixup->irq, fixup->base);
> - tmp = readl(fixup->base + 2);
> - writel(tmp | 0x80000000ul, fixup->base + 2);
> - /* config writes shouldn't be posted but let's be safe ... */
> - (void)readl(fixup->base + 2);
> + writeb(0x11 + 2 * fixup->irq, fixup->base + 2);
> + writel(fixup->data, fixup->base + 4);
This seems like a functional change: Previous code wrote at base, new at
base+2?
-Olof
^ permalink raw reply
* how to define BASE_BAUD
From: HappyPhot @ 2005-12-13 17:19 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Can anybody tell me how to define the "BASE_BAUD" value
for the "struct serial_state rs_table[]" ?
It seems has different value for each platform !!
thank you,
/HappyPhot
^ permalink raw reply
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
From: Russell King @ 2005-12-13 17:31 UTC (permalink / raw)
To: Adrian Bunk
Cc: tony.luck, linux-ia64, grundler, matthew, linux-kernel,
linuxppc-dev, lethal, linux-mtd, dwmw2, kkojima, parisc-linux
In-Reply-To: <20051213140001.GG23349@stusta.de>
On Tue, Dec 13, 2005 at 03:00:01PM +0100, Adrian Bunk wrote:
> defconfig files are virtually never a configuration for the kernel they
> are shipped with since they aren't updated every time some configuration
> option is changed.
>
> Consider a defconfig with CONFIG_BROKEN=n, and a driver that is enabled
> in this defconfig gets for some reason marked as broken in the Kconfig
> file - this will give exactly the same result as the one you describe.
Adrian,
The defconfig files in arch/arm/configs are for platform configurations
and are provided by the platform maintainers as a _working_ configuration
for their platform. They're not "defconfigs". They got called
"defconfigs" as a result of the kbuild "cleanups". Please don't confuse
them as such.
If, in order to have a working platform configuration, they deem that
CONFIG_BROKEN must be enabled, then that's the way it is.
Therefore, I request that either you leave the ARM platform configurations
well alone, or follow the advice I've given so that we can _properly_
assess the impact of your changes.
Thanks.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: ibm emac driver update
From: Simon Haynes @ 2005-12-13 18:44 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
In-Reply-To: <20051212181457.GA30505@gate.ebshome.net>
On Monday 12 December 2005 18:14, Eugene Surovegin wrote:
> On Mon, Dec 12, 2005 at 05:26:34PM +0000, Simon Haynes wrote:
> > I am running a Ebony board with linux-2.6.12-rc1 and I amd having
> > intermittent network problems. Having searched the archives it would seem
> > that the driver for the IBM EMAC is buggy ?
> >
> > I have tried to patch my kernel with
> >
> > http://kernel.ebsname.net/emac/4xx_napi_emac.diff
> >
> > I believe this is almost a total driver re-write. Is this correct ?
> >
> > After having a couple of problems applying the patch, Kconfig and
> > ibm_emac_core.c. I fixed up the original code and applied the patch.
> >
> > On compilation the build fails with missing references to kzalloc,
> > which I guess I could easily fix with kmalloc and memset.
> >
> > However there is also an undefined field, dcr_base, in the
> > ocp_func_mal_data structure. This structure appears to be defined in
> > include/asm/ibm_ocp.h and this file does not appear to be changed by the
> > patch. I guess this patch is for a later kernel.
> >
> > Can anyone point me in the direction of a suitable patch for this kernel
> > ?
>
> I'm not sure about 2.6.12-rc1, but you can try GIT tree/patches at
> http://kernel.ebshome.net.
>
> Hint: you can assume that in addition to emac_3-2.6-28.diff, there are
> also emac_3-2.6-NN.diff (NN < 28) on my website which were made for
> earlier kernel versions :).
>
> Alternatively, you can backport all relevant stuff from current 2.6 or
> you can pay someone to do this for you.
I have eventually got git going. I am not familiar with it but following a
tutorial I did
git clone rsync://kernel.ebshome.net/linux-2.6-emac.git
cd linux-2.6-emac
git checkout
I then ran find looking for a patches dir and could not find one.
Could you please tell me how to locate the emac_3-2.6-NN.diff files.
Cheers
Simon
^ permalink raw reply
* [2.6 patch] don't allow users to set CONFIG_BROKEN=y
From: Adrian Bunk @ 2005-12-13 18:05 UTC (permalink / raw)
To: Simon Richter, linux-kernel, tony.luck, linux-ia64, matthew,
grundler, parisc-linux, paulus, linuxppc-dev, lethal, kkojima,
dwmw2, linux-mtd
In-Reply-To: <20051213173112.GA24094@flint.arm.linux.org.uk>
On Tue, Dec 13, 2005 at 05:31:12PM +0000, Russell King wrote:
> On Tue, Dec 13, 2005 at 03:00:01PM +0100, Adrian Bunk wrote:
> > defconfig files are virtually never a configuration for the kernel they
> > are shipped with since they aren't updated every time some configuration
> > option is changed.
> >
> > Consider a defconfig with CONFIG_BROKEN=n, and a driver that is enabled
> > in this defconfig gets for some reason marked as broken in the Kconfig
> > file - this will give exactly the same result as the one you describe.
>
> Adrian,
Hi Russell,
> The defconfig files in arch/arm/configs are for platform configurations
> and are provided by the platform maintainers as a _working_ configuration
> for their platform. They're not "defconfigs". They got called
> "defconfigs" as a result of the kbuild "cleanups". Please don't confuse
> them as such.
>
> If, in order to have a working platform configuration, they deem that
> CONFIG_BROKEN must be enabled, then that's the way it is.
if a working platform configuration configuration requires
CONFIG_BROKEN=y, the problem is a bug that should be fixed properly.
We are talking about a class of bugs that can usually be easily fixed if
reported - so why aren't they reported?
The MTD_SHARP case is a good example, because otherwise I might have
soon sent a patch that would have removed this driver with the rationale
"both marked as obsolete and BROKEN can clearly be removed".
> Therefore, I request that either you leave the ARM platform configurations
> well alone, or follow the advice I've given so that we can _properly_
> assess the impact of your changes.
Unless someone can tell me a valid case for enabling BROKEN that does
both create a working configuration and not hide real issues it seems
the approch below might be the way to go.
Yes, you might dislike this at the first sight.
But if you consider that although this might result in a short-term
breakage of some configurations, this will also result in proper bug
reports and fixing of the wrong BROKEN dependency bugs, I hope you agree
that this will actually improve the situation.
> Thanks.
cu
Adrian
<-- snip -->
Do not allow people to create configurations with CONFIG_BROKEN=y.
The sole reason for CONFIG_BROKEN=y would be if you are working on
fixing a broken driver, but in this case editing the Kconfig file is
trivial.
Never ever should a user enable CONFIG_BROKEN.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.15-rc5-mm2-full/init/Kconfig.old 2005-12-13 18:48:40.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/init/Kconfig 2005-12-13 18:48:52.000000000 +0100
@@ -31,19 +31,8 @@
you say Y here, you will be offered the choice of using features or
drivers that are currently considered to be in the alpha-test phase.
-config CLEAN_COMPILE
- bool "Select only drivers expected to compile cleanly" if EXPERIMENTAL
- default y
- help
- Select this option if you don't even want to see the option
- to configure known-broken drivers.
-
- If unsure, say Y
-
config BROKEN
bool
- depends on !CLEAN_COMPILE
- default y
config BROKEN_ON_SMP
bool
^ permalink raw reply
* MPC5200 RTC
From: bennett78 @ 2005-12-13 18:10 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20051207195112.06457353A66@atlas.denx.de>
[-- Attachment #1.1: Type: text/plain, Size: 1147 bytes --]
* The /dev/rtc interface will block on reads until an interrupt
* has been received. If a RTC interrupt has already happened,
* it will output an unsigned long and then block.
Paul Gortmaker's rtctest (included below) works really well on my x86
machine (driver/char/rtc.c) as a nice way for a user process to wait on
ticks
of a programable frequency (via ioctl).
Under Denx linuxppc_2_4_devel MPC5200 I've tried:
driver/char/rtc.c - kernel panics
seems to need a RTC_IRQ to be defined
include/linux/mc14681rtc.h mentions #define RTC_IRQ 8 ?
CONFIG_PPC_RTC also panics
driver/char/genrtc.c (with #define CONFIG_GEN_RTC_X)
sort of works but I get the following:
gen_rtc_interrupt: system delaying clock ticks?
The internal MPC5200 RTC doesn't seem supported.
I see a lot of references to external RTCs, probably because
the standby power for the 5200 is high. I would like to
use a timer as the RTC interrupt and add an external RTC
later as a time reference (none on Lite5200 dev brd).
How best can I assign a GPTx as an interrupt? other than re-write
genrtc.c?
thanks,
Frank Bennett
*//*
[-- Attachment #1.2: Type: text/html, Size: 1820 bytes --]
[-- Attachment #2: rtctest.c --]
[-- Type: text/x-c, Size: 4562 bytes --]
/*
* Real Time Clock Driver Test/Example Program
*
* Compile with:
* gcc -s -Wall -Wstrict-prototypes rtctest.c -o rtctest
*
* Copyright (C) 1996, Paul Gortmaker.
*
* Released under the GNU General Public License, version 2,
* included herein by reference.
*
*/
#define spinlock_t int
#include <stdio.h>
#include <linux/mc146818rtc.h>
#include <sys/ioctl.h>
#include <sys/time.h>
#include <sys/types.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>
void main(void) {
int i, fd, retval, irqcount = 0;
unsigned long tmp, data;
struct rtc_time rtc_tm;
fd = open ("/dev/rtc", O_RDONLY);
if (fd == -1) {
perror("/dev/rtc");
exit(errno);
}
fprintf(stderr, "\n\t\t\tRTC Driver Test Example.\n\n");
/* Turn on update interrupts (one per second) */
retval = ioctl(fd, RTC_UIE_ON, 0);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
fprintf(stderr, "Counting 5 update (1/sec) interrupts from reading /dev/rtc:");
fflush(stderr);
for (i=1; i<6; i++) {
/* This read will block */
retval = read(fd, &data, sizeof(unsigned long));
if (retval == -1) {
perror("read");
exit(errno);
}
fprintf(stderr, " %d",i);
fflush(stderr);
irqcount++;
}
fprintf(stderr, "\nAgain, from using select(2) on /dev/rtc:");
fflush(stderr);
for (i=1; i<6; i++) {
struct timeval tv = {5, 0}; /* 5 second timeout on select */
fd_set readfds;
FD_ZERO(&readfds);
FD_SET(fd, &readfds);
/* The select will wait until an RTC interrupt happens. */
retval = select(fd+1, &readfds, NULL, NULL, &tv);
if (retval == -1) {
perror("select");
exit(errno);
}
/* This read won't block unlike the select-less case above. */
retval = read(fd, &data, sizeof(unsigned long));
if (retval == -1) {
perror("read");
exit(errno);
}
fprintf(stderr, " %d",i);
fflush(stderr);
irqcount++;
}
/* Turn off update interrupts */
retval = ioctl(fd, RTC_UIE_OFF, 0);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
/* Read the RTC time/date */
retval = ioctl(fd, RTC_RD_TIME, &rtc_tm);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
fprintf(stderr, "\n\nCurrent RTC date/time is %d-%d-%d, %02d:%02d:%02d.\n",
rtc_tm.tm_mday, rtc_tm.tm_mon + 1, rtc_tm.tm_year + 1900,
rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);
/* Set the alarm to 5 sec in the future, and check for rollover */
rtc_tm.tm_sec += 5;
if (rtc_tm.tm_sec >= 60) {
rtc_tm.tm_sec %= 60;
rtc_tm.tm_min++;
}
if (rtc_tm.tm_min == 60) {
rtc_tm.tm_min = 0;
rtc_tm.tm_hour++;
}
if (rtc_tm.tm_hour == 24)
rtc_tm.tm_hour = 0;
retval = ioctl(fd, RTC_ALM_SET, &rtc_tm);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
/* Read the current alarm settings */
retval = ioctl(fd, RTC_ALM_READ, &rtc_tm);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
fprintf(stderr, "Alarm time now set to %02d:%02d:%02d.\n",
rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);
/* Enable alarm interrupts */
retval = ioctl(fd, RTC_AIE_ON, 0);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
fprintf(stderr, "Waiting 5 seconds for alarm...");
fflush(stderr);
/* This blocks until the alarm ring causes an interrupt */
retval = read(fd, &data, sizeof(unsigned long));
if (retval == -1) {
perror("read");
exit(errno);
}
irqcount++;
fprintf(stderr, " okay. Alarm rang.\n");
/* Disable alarm interrupts */
retval = ioctl(fd, RTC_AIE_OFF, 0);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
/* Read periodic IRQ rate */
retval = ioctl(fd, RTC_IRQP_READ, &tmp);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
fprintf(stderr, "\nPeriodic IRQ rate was %ldHz.\n", tmp);
fprintf(stderr, "Counting 20 interrupts at:");
fflush(stderr);
/* The frequencies 128Hz, 256Hz, ... 8192Hz are only allowed for root. */
for (tmp=2; tmp<=64; tmp*=2) {
retval = ioctl(fd, RTC_IRQP_SET, tmp);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
fprintf(stderr, "\n%ldHz:\t", tmp);
fflush(stderr);
/* Enable periodic interrupts */
retval = ioctl(fd, RTC_PIE_ON, 0);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
for (i=1; i<21; i++) {
/* This blocks */
retval = read(fd, &data, sizeof(unsigned long));
if (retval == -1) {
perror("read");
exit(errno);
}
fprintf(stderr, " %d",i);
fflush(stderr);
irqcount++;
}
/* Disable periodic interrupts */
retval = ioctl(fd, RTC_PIE_OFF, 0);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
}
fprintf(stderr, "\n\n\t\t\t *** Test complete ***\n");
fprintf(stderr, "\nTyping \"cat /proc/interrupts\" will show %d more events on IRQ 8.\n\n",
irqcount);
close(fd);
} /* end main */
^ permalink raw reply
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
From: Geert Uytterhoeven @ 2005-12-13 18:28 UTC (permalink / raw)
To: Adrian Bunk
Cc: tony.luck, linux-ia64, grundler, matthew,
Linux Kernel Development, Linux/PPC Development, lethal,
linux-mtd, dwmw2, kkojima, parisc-linux
In-Reply-To: <20051213180551.GN23349@stusta.de>
On Tue, 13 Dec 2005, Adrian Bunk wrote:
> Do not allow people to create configurations with CONFIG_BROKEN=y.
>
> The sole reason for CONFIG_BROKEN=y would be if you are working on
> fixing a broken driver, but in this case editing the Kconfig file is
> trivial.
>
> Never ever should a user enable CONFIG_BROKEN.
^^^^
OK, a user, not an expert. Let's assume users don't enable EXPERIMENTAL.
But I'd like to at least have the possibility to enable broken drivers, even if
it's just for compile regression tests.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
From: Adrian Bunk @ 2005-12-13 18:51 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: tony.luck, linux-ia64, grundler, matthew,
Linux Kernel Development, Linux/PPC Development, lethal,
linux-mtd, dwmw2, kkojima, parisc-linux
In-Reply-To: <Pine.LNX.4.62.0512131926530.17990@pademelon.sonytel.be>
On Tue, Dec 13, 2005 at 07:28:41PM +0100, Geert Uytterhoeven wrote:
> On Tue, 13 Dec 2005, Adrian Bunk wrote:
> > Do not allow people to create configurations with CONFIG_BROKEN=y.
> >
> > The sole reason for CONFIG_BROKEN=y would be if you are working on
> > fixing a broken driver, but in this case editing the Kconfig file is
> > trivial.
> >
> > Never ever should a user enable CONFIG_BROKEN.
> ^^^^
> OK, a user, not an expert. Let's assume users don't enable EXPERIMENTAL.
Let's assume users don't have any hardware (e.g. several SATA drivers)
that requires EXPERIMENTAL...
> But I'd like to at least have the possibility to enable broken drivers, even if
> it's just for compile regression tests.
If a kernel developer really wants to enable BROKEN drivers, my patch
still gives them the possibility to do so with a trivial edit of
init/Kconfig.
> Gr{oetje,eeting}s,
>
> Geert
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
From: Jesper Juhl @ 2005-12-13 18:59 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: tony.luck, linux-ia64, grundler, matthew,
Linux Kernel Development, Adrian Bunk, Linux/PPC Development,
lethal, linux-mtd, dwmw2, kkojima, parisc-linux
In-Reply-To: <Pine.LNX.4.62.0512131926530.17990@pademelon.sonytel.be>
On 12/13/05, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, 13 Dec 2005, Adrian Bunk wrote:
> > Do not allow people to create configurations with CONFIG_BROKEN=3Dy.
> >
> > The sole reason for CONFIG_BROKEN=3Dy would be if you are working on
> > fixing a broken driver, but in this case editing the Kconfig file is
> > trivial.
> >
> > Never ever should a user enable CONFIG_BROKEN.
> ^^^^
> OK, a user, not an expert. Let's assume users don't enable EXPERIMENTAL.
>
> But I'd like to at least have the possibility to enable broken drivers, e=
ven if
> it's just for compile regression tests.
>
I agree, and it's very convenient to be able to enable it in
menuconfig etc. Perhaps CONFIG_BROKEN should just be moved to kernel
hacking instead...?
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply
* patch pci-export-pci_cfg_space_size.patch added to gregkh-2.6 tree
From: gregkh @ 2005-12-13 19:48 UTC (permalink / raw)
To: benh, greg, gregkh, linux-pci, linuxppc-dev, linuxppc64-dev,
paulus
In-Reply-To: <1134457757.6989.195.camel@gaston>
This is a note to let you know that I've just added the patch titled
Subject: [PATCH] PCI: Export pci_cfg_space_size
to my gregkh-2.6 tree. Its filename is
pci-export-pci_cfg_space_size.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/
Patches currently in gregkh-2.6 which might be from benh@kernel.crashing.org are
i2c/i2c-drop-driver-owner-and-name-04-macintosh.patch
pci/pci-export-pci_cfg_space_size.patch
>From benh@kernel.crashing.org Mon Dec 12 23:16:21 2005
Subject: [PATCH] PCI: Export pci_cfg_space_size
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Greg KH <greg@kroah.com>, Paul Mackerras <paulus@samba.org>
Cc: linux-pci <linux-pci@atrey.karlin.mff.cuni.cz>, linuxppc64-dev <linuxppc64-dev@ozlabs.org>, linuxppc-dev list <linuxppc-dev@ozlabs.org>
Date: Tue, 13 Dec 2005 18:09:16 +1100
Message-Id: <1134457757.6989.195.camel@gaston>
The powerpc PCI code sets up the PCI tree without doing config space
accesses in most cases, from the firmware tree. However, it still wants
to call pci_cfg_space_size() under some conditions, thus it needs to
be made non-static (though I don't see a point to export it to modules).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/pci/probe.c | 2 +-
include/linux/pci.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
--- gregkh-2.6.orig/drivers/pci/probe.c
+++ gregkh-2.6/drivers/pci/probe.c
@@ -717,7 +717,7 @@ static void pci_release_dev(struct devic
* reading the dword at 0x100 which must either be 0 or a valid extended
* capability header.
*/
-static int pci_cfg_space_size(struct pci_dev *dev)
+int pci_cfg_space_size(struct pci_dev *dev)
{
int pos;
u32 status;
--- gregkh-2.6.orig/include/linux/pci.h
+++ gregkh-2.6/include/linux/pci.h
@@ -514,6 +514,7 @@ int pci_scan_bridge(struct pci_bus *bus,
void pci_walk_bus(struct pci_bus *top, void (*cb)(struct pci_dev *, void *),
void *userdata);
+int pci_cfg_space_size(struct pci_dev *dev);
/* kmem_cache style wrapper around pci_alloc_consistent() */
^ permalink raw reply
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
From: Russell King @ 2005-12-13 20:01 UTC (permalink / raw)
To: Adrian Bunk
Cc: tony.luck, linux-ia64, grundler, matthew, linux-kernel,
linuxppc-dev, lethal, linux-mtd, dwmw2, kkojima, parisc-linux
In-Reply-To: <20051213180551.GN23349@stusta.de>
On Tue, Dec 13, 2005 at 07:05:52PM +0100, Adrian Bunk wrote:
> On Tue, Dec 13, 2005 at 05:31:12PM +0000, Russell King wrote:
> > The defconfig files in arch/arm/configs are for platform configurations
> > and are provided by the platform maintainers as a _working_ configuration
> > for their platform. They're not "defconfigs". They got called
> > "defconfigs" as a result of the kbuild "cleanups". Please don't confuse
> > them as such.
> >
> > If, in order to have a working platform configuration, they deem that
> > CONFIG_BROKEN must be enabled, then that's the way it is.
>
> if a working platform configuration configuration requires
> CONFIG_BROKEN=y, the problem is a bug that should be fixed properly.
Maybe they're only broken for a small subset of platforms, and someone
added a BROKEN without properly considering whether it should be global
or not?
I don't disagree with the overall notion that CONFIG_BROKEN should not
be set _where_ _possible_. However, if it needs to be set to get the
required options, then that's what needs to happen until such time that
the above is corrected.
However - and now to the main bug bear - how can we tell what is really
broken if you _just_ change the default configuration file settings for
CONFIG_BROKEN? What happens is that, on review, we see a simple change.
We'd assume that it has little impact, and we accept that change.
Maybe a month or two down the line, someone whines that their platform
doesn't work for some reason, and it's tracked down to this and the
resulting fallout from disabling CONFIG_BROKEN.
That means that the original review was _worthless_. It wasn't a
review at all.
So, what I am trying to get across is the need to show the _full_ set
of changes to a default configuratoin when you disable CONFIG_BROKEN,
which is trivially producable if you run the script I've already posted.
You can even use that in conjunction with your present patch to produce
a patch which shows _exactly_ _everything_ which changes as a result of
disabling CONFIG_BROKEN. Surely giving reviewers the _full_ story is
far better than half a story, and should be something that any change
to the kernel strives for.
If not, what's the point of the original change?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
From: Adrian Bunk @ 2005-12-13 20:19 UTC (permalink / raw)
To: Simon Richter, linux-kernel, tony.luck, linux-ia64, matthew,
grundler, parisc-linux, paulus, linuxppc-dev, lethal, kkojima,
dwmw2, linux-mtd
In-Reply-To: <20051213200106.GC24094@flint.arm.linux.org.uk>
On Tue, Dec 13, 2005 at 08:01:06PM +0000, Russell King wrote:
> On Tue, Dec 13, 2005 at 07:05:52PM +0100, Adrian Bunk wrote:
> > On Tue, Dec 13, 2005 at 05:31:12PM +0000, Russell King wrote:
> > > The defconfig files in arch/arm/configs are for platform configurations
> > > and are provided by the platform maintainers as a _working_ configuration
> > > for their platform. They're not "defconfigs". They got called
> > > "defconfigs" as a result of the kbuild "cleanups". Please don't confuse
> > > them as such.
> > >
> > > If, in order to have a working platform configuration, they deem that
> > > CONFIG_BROKEN must be enabled, then that's the way it is.
> >
> > if a working platform configuration configuration requires
> > CONFIG_BROKEN=y, the problem is a bug that should be fixed properly.
>
> Maybe they're only broken for a small subset of platforms, and someone
> added a BROKEN without properly considering whether it should be global
> or not?
>
> I don't disagree with the overall notion that CONFIG_BROKEN should not
> be set _where_ _possible_. However, if it needs to be set to get the
> required options, then that's what needs to happen until such time that
> the above is corrected.
Where is the bug report from the person who set CONFIG_BROKEN=y in the
collie defconfig that the BROKEN dependency on MTD_SHARP was wrong?
> However - and now to the main bug bear - how can we tell what is really
> broken if you _just_ change the default configuration file settings for
> CONFIG_BROKEN? What happens is that, on review, we see a simple change.
> We'd assume that it has little impact, and we accept that change.
>
> Maybe a month or two down the line, someone whines that their platform
> doesn't work for some reason, and it's tracked down to this and the
> resulting fallout from disabling CONFIG_BROKEN.
The whining is the bug report the person who set the CONFIG_BROKEN=y in
the defconfig didn't send.
And things would have been even worse if I had sent a patch erasing
MTD_SHARP from the kernel because code "both marked as obsolete and
BROKEN can clearly be removed" and the code was therefore completely
removed two months before the first person whined?
> That means that the original review was _worthless_. It wasn't a
> review at all.
>
> So, what I am trying to get across is the need to show the _full_ set
> of changes to a default configuratoin when you disable CONFIG_BROKEN,
> which is trivially producable if you run the script I've already posted.
>
> You can even use that in conjunction with your present patch to produce
> a patch which shows _exactly_ _everything_ which changes as a result of
> disabling CONFIG_BROKEN. Surely giving reviewers the _full_ story is
> far better than half a story, and should be something that any change
> to the kernel strives for.
>
> If not, what's the point of the original change?
The point is that I haven't yet heard any good reason for
CONFIG_BROKEN=y in a defconfig.
No, it's not a good reason if someone used it as a workaround instead of
sending a bug report that would result in a fixing of the wrong BROKEN
dependency.
Where is the bug report of the person setting CONFIG_BROKEN=y in the
collie defconfig that the MTD_SHARP dependency on BROKEN was wrong?
> Russell King
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH] powerpc: Update MPIC workarounds
From: Benjamin Herrenschmidt @ 2005-12-13 20:23 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc64-dev, linuxppc-dev list
In-Reply-To: <20051213165807.GA7468@pb15.lixom.net>
On Tue, 2005-12-13 at 08:58 -0800, Olof Johansson wrote:
> On Tue, Dec 13, 2005 at 06:04:29PM +1100, Benjamin Herrenschmidt wrote:
> > From: Segher Boessenkool <segher@kernel.crashing.org>
> >
> > Cleanup the MPIC IO-APIC workarounds, make them a bit more generic,
> > smaller and faster.
>
> I really don't like all the hand-coded constants in this code. They're
> all over the place, and there's no descriptions of what they are there
> for. Lots of hardcoded offsets, etc. Since this is a cleanup, wouldn't
> it be a good time to use symbolic constands and/or comment them up a
> bit?
Heh, welcome to segher world :) I'll add more comments & symbolic
constants in the other patch that applies on top of this one.
> > Index: linux-work/arch/powerpc/sysdev/mpic.c
> > ===================================================================
> > --- linux-work.orig/arch/powerpc/sysdev/mpic.c 2005-12-06 16:17:43.000000000 +1100
> > +++ linux-work/arch/powerpc/sysdev/mpic.c 2005-12-07 13:30:45.000000000 +1100
> > @@ -175,57 +175,57 @@ static inline int mpic_is_ht_interrupt(s
> > return mpic->fixups[source_no].base != NULL;
> > }
> >
> > +
> > static inline void mpic_apic_end_irq(struct mpic *mpic, unsigned int source_no)
> > {
> > struct mpic_irq_fixup *fixup = &mpic->fixups[source_no];
> > - u32 tmp;
> >
> > spin_lock(&mpic->fixup_lock);
> > - writeb(0x11 + 2 * fixup->irq, fixup->base);
> > - tmp = readl(fixup->base + 2);
> > - writel(tmp | 0x80000000ul, fixup->base + 2);
> > - /* config writes shouldn't be posted but let's be safe ... */
> > - (void)readl(fixup->base + 2);
> > + writeb(0x11 + 2 * fixup->irq, fixup->base + 2);
> > + writel(fixup->data, fixup->base + 4);
>
> This seems like a functional change: Previous code wrote at base, new at
> base+2?
Hrm... I have to double check but I think the previous code hard coded
the bases for the 2 known APICs (incuding the +2) while the new code
properly scans the PCI capabilities and thus gets the capability base
instead, which is better (but needs +2 / +4). I suppose I could
pre-offset by 2 at discovery time to avoid an addition but I'm not sure
it's worth it.
Ben.
^ permalink raw reply
* [PATCH] powerpc: Provide PCI OF functions even if we dont have true OF
From: Kumar Gala @ 2005-12-13 20:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
If we are building an arch/powerpc kernel we dont neccesarily
have a full OF implementation (and thus dont set CONFIG_PPC_OF)
but can use the OF PCI functions
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit 761e102769add7e86d510f7605c06f4a82575015
tree e62bfa889a1789289e9fc031d8f883cb2291c6a4
parent 5ce33c8a0b8087f0c554a417efb907d35892e58b
author Kumar Gala <galak@kernel.crashing.org> Tue, 13 Dec 2005 14:40:11 -0600
committer Kumar Gala <galak@kernel.crashing.org> Tue, 13 Dec 2005 14:40:11 -0600
arch/ppc/kernel/pci.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/ppc/kernel/pci.c b/arch/ppc/kernel/pci.c
index af36400..df4b11c 100644
--- a/arch/ppc/kernel/pci.c
+++ b/arch/ppc/kernel/pci.c
@@ -46,7 +46,7 @@ static void pcibios_fixup_resources(stru
static void fixup_broken_pcnet32(struct pci_dev* dev);
static int reparent_resources(struct resource *parent, struct resource *res);
static void fixup_cpc710_pci64(struct pci_dev* dev);
-#ifdef CONFIG_PPC_OF
+#if defined(CONFIG_PPC_OF) || defined(CONFIG_PPC_MERGE)
static u8* pci_to_OF_bus_map;
#endif
@@ -626,7 +626,7 @@ pcibios_alloc_controller(void)
return hose;
}
-#ifdef CONFIG_PPC_OF
+#if defined(CONFIG_PPC_OF) || defined(CONFIG_PPC_MERGE)
/*
* Functions below are used on OpenFirmware machines.
*/
@@ -1027,7 +1027,7 @@ void pcibios_make_OF_bus_map(void)
/* Add sysfs properties */
void pcibios_add_platform_entries(struct pci_dev *pdev)
{
-#ifdef CONFIG_PPC_OF
+#if defined(CONFIG_PPC_OF) || defined(CONFIG_PPC_MERGE)
device_create_file(&pdev->dev, &dev_attr_devspec);
#endif /* CONFIG_PPC_OF */
}
^ permalink raw reply related
* [PATCH] powerpc: Detect prefetchable windows in pci_process_bridge_OF_ranges
From: Kumar Gala @ 2005-12-13 20:46 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Added the ability to determine if an outbound window in the PCI host
controller is for prefetchable memory and report it as such.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit 6a050a749ac14613057a2adec0e3dbaa7697a824
tree 254dedb89aac5444c6d387bd1b6ef20c954538a5
parent 761e102769add7e86d510f7605c06f4a82575015
author Kumar Gala <galak@kernel.crashing.org> Tue, 13 Dec 2005 14:46:34 -0600
committer Kumar Gala <galak@kernel.crashing.org> Tue, 13 Dec 2005 14:46:34 -0600
arch/ppc/kernel/pci.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/ppc/kernel/pci.c b/arch/ppc/kernel/pci.c
index df4b11c..8a58fe8 100644
--- a/arch/ppc/kernel/pci.c
+++ b/arch/ppc/kernel/pci.c
@@ -941,7 +941,7 @@ pci_process_bridge_OF_ranges(struct pci_
while (ranges && (rlen -= np * sizeof(unsigned int)) >= 0) {
res = NULL;
size = ranges[na+4];
- switch (ranges[0] >> 24) {
+ switch ((ranges[0] >> 24) & 0x3) {
case 1: /* I/O space */
if (ranges[2] != 0)
break;
@@ -955,6 +955,8 @@ pci_process_bridge_OF_ranges(struct pci_
res = &hose->io_resource;
res->flags = IORESOURCE_IO;
res->start = ranges[2];
+ DBG("PCI: IO 0x%lx -> 0x%lx\n",
+ res->start, res->start + size - 1);
break;
case 2: /* memory space */
memno = 0;
@@ -972,7 +974,11 @@ pci_process_bridge_OF_ranges(struct pci_
if (memno < 3) {
res = &hose->mem_resources[memno];
res->flags = IORESOURCE_MEM;
+ if(ranges[0] & 0x40000000)
+ res->flags |= IORESOURCE_PREFETCH;
res->start = ranges[na+2];
+ DBG("PCI: MEM[%d] 0x%lx -> 0x%lx\n", memno,
+ res->start, res->start + size - 1);
}
break;
}
^ permalink raw reply related
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
From: Russell King @ 2005-12-13 22:01 UTC (permalink / raw)
To: Adrian Bunk
Cc: tony.luck, linux-ia64, grundler, matthew, linux-kernel,
linuxppc-dev, lethal, linux-mtd, dwmw2, kkojima, parisc-linux
In-Reply-To: <20051213201920.GT23349@stusta.de>
On Tue, Dec 13, 2005 at 09:19:20PM +0100, Adrian Bunk wrote:
> On Tue, Dec 13, 2005 at 08:01:06PM +0000, Russell King wrote:
> > That means that the original review was _worthless_. It wasn't a
> > review at all.
> >
> > So, what I am trying to get across is the need to show the _full_ set
> > of changes to a default configuratoin when you disable CONFIG_BROKEN,
> > which is trivially producable if you run the script I've already posted.
> >
> > You can even use that in conjunction with your present patch to produce
> > a patch which shows _exactly_ _everything_ which changes as a result of
> > disabling CONFIG_BROKEN. Surely giving reviewers the _full_ story is
> > far better than half a story, and should be something that any change
> > to the kernel strives for.
> >
> > If not, what's the point of the original change?
>
> The point is that I haven't yet heard any good reason for
> CONFIG_BROKEN=y in a defconfig.
I'm sorry, I feel like I'm beating my head against a brick wall. I
have said everything that needs to be said, and made my position on
this patch crystal clear.
The patch to the ARM configuration files is nacked as it stands.
Please go back and rework it along the guidelines I've pointed out
several times in this thread and maybe then it becomes acceptable.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* [PATCH 2.6 1/2] usb/input: Add relayfs support to appletouch driver
From: Michael Hanselmann @ 2005-12-13 22:36 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-input, linuxppc-dev, kernel-stuff
This patch adds support for relayfs to the appletouch driver to make
debugging easier.
Signed-off-by: Michael Hanselmann <linux-kernel@hansmi.ch>
Acked-by: Rene Nussbaumer <linux-kernel@killerfox.forkbomb.ch>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
---
diff -Npur linux-2.6.15-rc5.orig/Documentation/input/appletouch.txt linux-2.6.15-rc5/Documentation/input/appletouch.txt
--- linux-2.6.15-rc5.orig/Documentation/input/appletouch.txt 2005-12-13 00:09:24.000000000 +0100
+++ linux-2.6.15-rc5/Documentation/input/appletouch.txt 2005-12-13 21:28:26.000000000 +0100
@@ -77,6 +78,8 @@ full tracing (each sample is being trace
or
echo "1" > /sys/module/appletouch/parameters/debug
+To make debugging easier, the driver also supports the relayfs filesystem.
+
Links:
------
diff -Npur linux-2.6.15-rc5.orig/drivers/usb/input/appletouch.txt linux-2.6.15-rc5/drivers/usb/input/appletouch.txt
--- linux-2.6.15-rc5.orig/drivers/usb/input/appletouch.c 2005-12-13 00:09:24.000000000 +0100
+++ linux-2.6.15-rc5/drivers/usb/input/appletouch.c 2005-12-13 22:41:28.000000000 +0100
@@ -6,9 +6,18 @@
* Copyright (C) 2005 Stelian Pop (stelian@popies.net)
* Copyright (C) 2005 Frank Arnold (frank@scirocco-5v-turbo.de)
* Copyright (C) 2005 Peter Osterlund (petero2@telia.com)
+ * Copyright (C) 2005 Parag Warudkar (parag.warudkar@gmail.com)
+ * Copyright (C) 2005 Michael Hanselmann (linux-kernel@hansmi.ch)
*
* Thanks to Alex Harper <basilisk@foobox.net> for his inputs.
*
+ * Nov 2005 - Parag Warudkar
+ * o Added ability to export data via relayfs
+ *
+ * Nov/Dec 2005 - Michael Hanselmann
+ * o Compile relayfs support only if enabled in the kernel
+ * o Enable relayfs only if requested by the user
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
@@ -35,6 +44,10 @@
#include <linux/input.h>
#include <linux/usb_input.h>
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+#include <linux/relayfs_fs.h>
+#endif
+
/* Apple has powerbooks which have the keyboard with different Product IDs */
#define APPLE_VENDOR_ID 0x05AC
@@ -57,6 +70,11 @@ static struct usb_device_id atp_table []
};
MODULE_DEVICE_TABLE (usb, atp_table);
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+struct rchan* rch = NULL;
+struct rchan_callbacks* rcb = NULL;
+#endif
+
/* size of a USB urb transfer */
#define ATP_DATASIZE 81
@@ -73,6 +91,7 @@ MODULE_DEVICE_TABLE (usb, atp_table);
/* maximum pressure this driver will report */
#define ATP_PRESSURE 300
+
/*
* multiplication factor for the X and Y coordinates.
* We try to keep the touchpad aspect ratio while still doing only simple
@@ -124,7 +143,7 @@ struct atp {
if (debug) printk(format, ##a); \
} while (0)
-MODULE_AUTHOR("Johannes Berg, Stelian Pop, Frank Arnold");
+MODULE_AUTHOR("Johannes Berg, Stelian Pop, Frank Arnold, Parag Warudkar, Michael Hanselmann");
MODULE_DESCRIPTION("Apple PowerBooks USB touchpad driver");
MODULE_LICENSE("GPL");
@@ -132,6 +151,12 @@ static int debug = 1;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "Activate debugging output");
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+static int relayfs = 0;
+module_param(relayfs, int, 0644);
+MODULE_PARM_DESC(relayfs, "Activate relayfs support");
+#endif
+
static int atp_calculate_abs(int *xy_sensors, int nb_sensors, int fact,
int *z, int *fingers)
{
@@ -194,6 +219,13 @@ static void atp_complete(struct urb* urb
goto exit;
}
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+ /* "rch" is NULL if relayfs is not enabled */
+ if (rch && dev->data) {
+ relay_write(rch, dev->data, dev->urb->actual_length);
+ }
+#endif
+
/* reorder the sensors values */
for (i = 0; i < 8; i++) {
/* X values */
@@ -463,11 +495,43 @@ static struct usb_driver atp_driver = {
static int __init atp_init(void)
{
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+ rcb = NULL;
+ rch = NULL;
+
+ if (relayfs) {
+ rcb = kmalloc(sizeof(struct rchan_callbacks), GFP_KERNEL);
+ if (!rcb)
+ return -ENOMEM;
+
+ rcb->subbuf_start = NULL;
+ rcb->buf_mapped = NULL;
+ rcb->buf_unmapped = NULL;
+
+ rch = relay_open("atpdata", NULL, 256, 256, NULL);
+ if (!rch) {
+ kfree(rcb);
+ return -ENOMEM;
+ }
+
+ printk("appletouch: Relayfs enabled.\n");
+ } else {
+ printk("appletouch: Relayfs disabled.\n");
+ }
+#endif
+
return usb_register(&atp_driver);
}
static void __exit atp_exit(void)
{
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+ if(rch)
+ relay_close(rch);
+ if(rcb)
+ kfree(rcb);
+#endif
+
usb_deregister(&atp_driver);
}
^ 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