* Problem getting code from git repository
From: Marty @ GMail @ 2006-01-23 20:56 UTC (permalink / raw)
To: linuxppc-embedded
V2hlbiBJIGF0dGVtcHQgdG8gcmV0cmlldmUgdGhlIGN1cnJlbnQgc291cmNlIGZyb20gdGhlIGdp
dCByZXBvc2l0b3J5CkkgZ2V0IHRoZSBmb2xsb3dpbmcKCkFueSBzdWdnZXN0aW9ucyA/Pz8gIE1h
cnRpbgoKCgp3ZWRlcG9obEB1YnVudHU6L29wdC9lbGRrL3BwY182eHgvdXNyL3NyYyQgY2ctY2xv
bmUKaHR0cDovL3d3dy5kZW54LmRlL2dpdC9saW51eC0yLjYtZGVueC5naXQgbGludXgtMi42LWRl
bnguZ2l0LwpkZWZhdWx0aW5nIHRvIGxvY2FsIHN0b3JhZ2UgYXJlYQoxMzoyMzo1NSBVUkw6aHR0
cDovL3d3dy5kZW54LmRlL2dpdC9saW51eC0yLjYtZGVueC5naXQvcmVmcy9oZWFkcy9tYXN0ZXIK
WzQxLzQxXSAtPiAicmVmcy9oZWFkcy9vcmlnaW4iIFsxXQplcnJvcjogRmlsZSAxYzA2Y2Y1YTk4
NTFhODM0OTNmNWI1ZjM3NDliNGNlZDRlMDdhZjI5CihodHRwOi8vd3d3LmRlbnguZGUvZ2l0L2xp
bnV4LTIuNi1kZW54LmdpdC9vYmplY3RzLzFjLzA2Y2Y1YTk4NTFhODM0OTNmNWI1ZjM3NDliNGNl
ZDRlMDdhZjI5KQpjb3JydXB0CgpDYW5ub3Qgb2J0YWluIG5lZWRlZCBjb21taXQgMWMwNmNmNWE5
ODUxYTgzNDkzZjViNWYzNzQ5YjRjZWQ0ZTA3YWYyOQp3aGlsZSBwcm9jZXNzaW5nIGNvbW1pdCAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwLgplcnJvcjogY2Fubm90IG1h
cCBzaGExIGZpbGUgMWMwNmNmNWE5ODUxYTgzNDkzZjViNWYzNzQ5YjRjZWQ0ZTA3YWYyOQpjZy1w
dWxsOiBvYmplY3RzIHB1bGwgZmFpbGVkCmNnLWluaXQ6IHB1bGwgZmFpbGVkCndlZGVwb2hsQHVi
dW50dTovb3B0L2VsZGsvcHBjXzZ4eC91c3Ivc3JjJAo=
^ permalink raw reply
* RE: u-boot debugging
From: sri.dharmasanam @ 2006-01-23 18:42 UTC (permalink / raw)
To: albert.david, linuxppc-embedded
I agree that there was no need to take things personally here. Perhaps =
the reader didn't understand what oxymoron meant.
Debug tools is often a hotly disputed issue and it would have been nice =
to hear more thoughts (technical and business related) on a forum such =
as this.
Regards,
_Sri
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org =
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Albert David
Sent: Sunday, January 22, 2006 2:11 AM
To: linuxppc-embedded@ozlabs.org
Subject: u-boot debugging
>> On Friday 20 January 2006 08:00 pm, AtulAtulhSabharwalte:
>> > First learn to communicate in English. I can give you 25 Us
>> cents as I
>> > cannot afford 1 Mark. You are not work even a Mark.
>>
>> The complete lack of civility in this remark is inexcusable in
>> a public forum.
>> Herr DenkDenk provided an incredibly valuable service to the
>> community, and
>> deserves more respect than this.
>I agree whole heartily Glenn...
glenn and frank,
even me too! i agree with you.
Best regards,
Albert David.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH 4/9] Migrate ML300 reference design to the platform bus
From: Andrei Konovalov @ 2006-01-23 17:31 UTC (permalink / raw)
To: Grant C. Likely; +Cc: linuxppc-embedded
In-Reply-To: <20060119081303.GA24908@weasley-twins.secretlab.ca>
Hi Grant,
Grant C. Likely wrote:
> Signed-off-by: Grant C. Likely <grant.likely@secretlab.ca>
>
> ---
>
> arch/ppc/Kconfig.debug | 2 -
> arch/ppc/platforms/4xx/xilinx_ml300.c | 74 +++++++++++++++++++++++----------
> arch/ppc/platforms/4xx/xilinx_ml300.h | 2 -
> arch/ppc/syslib/Makefile | 2 -
> 4 files changed, 55 insertions(+), 25 deletions(-)
<snip>
> +/* Board specifications structures */
> +struct ppc_sys_spec *cur_ppc_sys_spec;
> +struct ppc_sys_spec ppc_sys_specs[] = {
> + {
> + /* Only one entry, always assume the same design */
> + .ppc_sys_name = "Xilinx ML300 Reference Design",
> + .mask = 0x00000000,
> + .value = 0x00000000,
"Always assume the same design" could be a considerable limitation
for the Virtex FPGAs.
<snip>
> @@ -131,6 +159,8 @@ platform_init(unsigned long r3, unsigned
> {
> ppc4xx_init(r3, r4, r5, r6, r7);
>
> + identify_ppc_sys_by_id(mfspr(SPRN_PVR));
This is OK for the single ppc_sys_specs[] case, but in general
I am not sure using PVR to identify the system makes much sense
in case of Virtex FPGAs. IIRC, for the mpc8xxx Freescale SOCs PVR
gives enough information to determine what on-chip peripherals are
present (but not how multi-function peripherals like SCC are configured).
In case of Xilinx the situation is worse: depending on the bitstream
loaded into the FPGA, the same chip (the same PVR) and the board
can have several sets of on-chip peripherals which could be completely
different from each other. And knowing the PVR value alone puts no limitation
on what peripherals could get into the FPGA (unless e.g. a Virtex-4 specific
hardware block is used by an IP - like in case of TEMAC).
What do you think?
So far I've used a fairly dumb code like:
static int __init xilinx_platform_init(void)
{
#ifdef XPAR_EMAC_0_BASEADDR
memcpy(xemac_0_pdata.mac_addr, __res.bi_enetaddr, 6);
platform_device_register(&xilinx_emac_0_device);
#endif /* XPAR_EMAC_0_BASEADDR */
#ifdef XPAR_TEMAC_0_BASEADDR
memcpy(xtemac_0_pdata.mac_addr, __res.bi_enetaddr, 6);
platform_device_register(&xilinx_temac_0_device);
#endif /* XPAR_TEMAC_0_BASEADDR */
#ifdef XPAR_TFT_0_BASEADDR
platform_device_register(&xilinx_lcd_0_device);
#endif /* XPAR_TFT_0_BASEADDR */
#ifdef XPAR_GPIO_0_BASEADDR
platform_device_register(&xilinx_gpio_0_device);
#endif /* XPAR_GPIO_0_BASEADDR */
#ifdef XPAR_GPIO_1_BASEADDR
platform_device_register(&xilinx_gpio_1_device);
#endif /* XPAR_GPIO_1_BASEADDR */
#ifdef XPAR_PS2_0_BASEADDR
platform_device_register(&xilinx_ps2_0_device);
#endif /* XPAR_PS2_0_BASEADDR */
#ifdef XPAR_PS2_1_BASEADDR
platform_device_register(&xilinx_ps2_1_device);
#endif /* XPAR_PS2_1_BASEADDR */
return 0;
}
- to associate the devices to the drivers (the drivers
call driver_register() from their module_init function).
This helps me holding all that ugly stuff in one file
(this single file can be used by multiple boards),
and should make it easier to switch to something using
the flattened device tree parsing when the OF DT comes
into play.
Probably using ppc_sys infrastructure now has some advantages,
but they are not evident to me.
Thanks,
Andrei
^ permalink raw reply
* Trouble with SMC serial port in ppc/boot/simple on Embedded Planet 8248 board
From: Laurent Pinchart @ 2006-01-23 16:24 UTC (permalink / raw)
To: linuxppc-embedded
Hi everybody,
I'm trying to port the Linux kernel (2.6.15.1) to the Embedded Planet 8248
board. The board has a proprietary boot loader and uses SMC1 has a serial
console.
After some work (2.6.15.1 has a nasty bug related to relocation which has been
fixed in the git tree), I have been able to load and start the kernel image.
Unfortunately, the early serial output is lost. Here is the kernel boot
messages I get with 2.6.15.1 :
-----------------------------------------------------------------------------
Embedded Planet EP8248 PowerPC port
Built 1 zonelists
Kernel command line: console=ttyCPM0,9600n8 root=/dev/ram0 rw
PID hash table entries: 4096 (order: 12, 65536 bytes)
Warning: real time clock seems stuck!
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 777088k available (1520k kernel code, 440k data, 96k init, 0k highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
-----------------------------------------------------------------------------
And here is the same with the modified 2.6.10-pre3 kernel shipped with the
board:
-----------------------------------------------------------------------------
loaded at: 00200000 002D01E8
relocated to: 00400000 004D01E8
board data at: 004CE12C 004CE168
relocated to: 0040509C 004050D8
zimage at: 00405A31 004CD2C4
avail ram: 004D1000 01000000
Linux/PPC load: console=ttyCPM0,9600n8 root=/dev/ram0 rw
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.6.10-rc3 (laurent@pclaurent) (gcc version 3.4.1) #5 Thu Jan 19
15:25:42 CET 2006
Embedded Planet EP8248 PowerPC port
Built 1 zonelists
[...]
-----------------------------------------------------------------------------
Early boot messages (printed with puts in ppc/boot/simple/misc-embedded.c) are
lost.
I compared the Embedded Planet kernel with the 2.6.10-rc3 from kernel.org,
haven't seen any big change related to the SMC serial port. Embedded Planet
uses BRGC7 instead of BRGC1 for SMC1, but that didn't work better for me.
I of course enabled the RS232 transceivers in the board control and status
registers (BCSR).
Could anyone give me any pointer to where I should look at ?
Thanks in advance,
Laurent Pinchart
^ permalink raw reply
* Registers read-only
From: Moloko Vellocet @ 2006-01-23 15:15 UTC (permalink / raw)
To: linuxppc-embedded
Hi, I'm writing a driver to manage the serial communication in a
MPC5200 board, but the interrupt I don't have obtained the call to
interrupt routine, I've configured the registers in the initialization
code as the following:
#define REG_MBAR MPC5xxx_MBAR
#define REG_BASE_PSC MPC5xxx_PSC3
#define REG_CR (REG_BASE_PSC + 0x08)
#define REG_RXTX (REG_BASE_PSC + 0x0C)
#define REG_IMR (REG_BASE_PSC + 0x14)
#define REG_SICR (REG_BASE_PSC + 0x40)
#define REG_RFALARM (REG_BASE_PSC + 0x6E)
#define REG_TFALARM (REG_BASE_PSC + 0x8E)
outb(0x0A, REG_CR);
wmb();
printk("REG_CR=3D%x\n", inb(REG_CR));
rmb();
outb(0x221000, REG_SICR);
wmb();
printk("REG_SICR=3D%x\n", inb(REG_SICR));
rmb();
outb(0x0004, REG_RFALARM);
wmb();
printk("REG_RFALARM=3D%x\n", inb(REG_RFALARM));
rmb();
outb(0x0004, REG_TFALARM);
wmb();
printk("REG_TFALARM=3D%x\n", inb(REG_TFALARM));
rmb();
outb(0x00000300, REG_IMR);
wmb();
printk("REG_IMR=3D%x\n", inb(REG_IMR));
rmb();
I'm getting always:
REG_CR=3D0
REG_SICR=3D0
REG_RFALARM=3D0
REG_TFALARM=3D0
REG_IMR=3D0
I have to configure 'port config' register doing a 'or' with the
actual value in the register, but I can't get the values contained in
the registers. Are the register write-only.
I've registered the following interrupts:
if ((err =3D request_irq(MPC5xxx_IR_RX_IRQ, /*RX_IRQ_NUMBER,*/
interrupt_handler,
SA_INTERRUPT,
DEVICE_NAME,
NULL)) < 0)
goto fail_rx_req_irq;
if ((err =3D request_irq(MPC5xxx_IR_TX_IRQ, /*TX_IRQ_NUMBER,*/
interrupt_handler_tx,
SA_INTERRUPT,
DEVICE_NAME,
NULL)) < 0)
goto fail_tx_req_irq;
But the interrupts are not activated when I execute a ioctl to the
board the interrupt handler are not called.
Does anyone know the problem with this code?
--
_______________________________
Allann J. O. Silva
Genius Instituto de Tecnologia
Tel.:+55 (92) 3614-6586
www.genius.org.br
_______________________________
"I received the fundamentals of my education in school, but that was
not enough. My real education, the superstructure, the details, the
true architecture, I got out of the public library. For an
impoverished child whose family could not afford to buy books, the
library was the open door to wonder and achievement, and I can never
be sufficiently grateful that I had the wit to charge through that
door and make the most of it." (from I. Asimov, 1994)
^ permalink raw reply
* [PATCH] powerpc: Fix sigmask handling in sys_sigsuspend.
From: Heiko Carstens @ 2006-01-23 12:07 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, David Woodhouse, linux-kernel
From: Heiko Carstens <heiko.carstens@de.ibm.com>
Better save the sigmask instead of throwing it away so it can be restored.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
---
Completely untested. Just noticed this when adding TIF_RESTORE_SIGMASK
support for s390.
arch/powerpc/kernel/signal_32.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index 3747ab0..c6d0595 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -254,11 +254,9 @@ int do_signal(sigset_t *oldset, struct p
*/
long sys_sigsuspend(old_sigset_t mask)
{
- sigset_t saveset;
-
mask &= _BLOCKABLE;
spin_lock_irq(¤t->sighand->siglock);
- saveset = current->blocked;
+ current->saved_sigmask = current->blocked;
siginitset(¤t->blocked, mask);
recalc_sigpending();
spin_unlock_irq(¤t->sighand->siglock);
^ permalink raw reply related
* Re: u-boot debugging
From: Atul Sabharwal @ 2006-01-23 14:10 UTC (permalink / raw)
To: Albert David, linuxppc-embedded
In-Reply-To: <61124de70601220210i718fbc9cm85cdd282e739555e@mail.gmail.com>
>>Herr DenkDenk provided an incredibly valuable service to the
>>community, and deserves more respect than this.
I agree with the latter but he cannot insult others to retain his sphere
of influence... And read my other e-mail which describes the main
problem... Its easy to join a band wagon but be sure if you are on the
right train. Not sinulting Wolf but I had to resort to this approach to
explain the insult in his remark. Besides, as usual, lot of people have
short memories. They dont scan the entire e-mail thread to see where
the e-mail chain went wrong. Who instigated the whole insult cycle.
And for the record, I did not insult wolf. He insulted me. I just humor
& ridicule to convey my across. Rest is your interpretation...
--
Atul
----- Original Message -----
From: "Albert David" <albert.david@gmail.com>
To: <linuxppc-embedded@ozlabs.org>
Sent: Sunday, January 22, 2006 2:10 AM
Subject: u-boot debugging
>> On Friday 20 January 2006 08:00 pm, AtulAtulhSabharwalte:
>> > First learn to communicate in English. I can give you 25 Us
>> cents as I
>> > cannot afford 1 Mark. You are not work even a Mark.
>>
>> The complete lack of civility in this remark is inexcusable in
>> a public forum.
>> Herr DenkDenk provided an incredibly valuable service to the
>> community, and
>> deserves more respect than this.
>I agree whole heartily Glenn...
glenn and frank,
even me too! i agree with you.
Best regards,
Albert David.
^ permalink raw reply
* Re: u-boot debugging
From: Atul Sabharwal @ 2006-01-23 13:44 UTC (permalink / raw)
To: David Jander, linuxppc-embedded
In-Reply-To: <200601231032.38295.david.jander@protonic.nl>
> I detect an increasing amount of resentment in your words, and that is not
> good as far as my experience goes...
This is true... I have had quite a few bad experiences with open source
product.
e.g. RH 6.2 the loop back driver would flush data to the driver every second
time.
People at work would change compiler, graphic settings on me... Swap ln
commnad
options.... crack linux md5 passwords... break gid/uid settings... steal
my linux CD
roms... This happened to me at my ex-employer for about 2.5 years for
sure...
6 years in total (on my windows box with USB scanner, printers, boot sector
crashes,
file/pdf corruption... Besides the usual of getting SPAM, virus, trojans
etc... The latter
is okay but the rest is strange... ). Now when you are on a schedule
deadline, how many
bugs can one fix... Code which runs on one day does not on another day...
Its like
somebody (internally) is trying to sabotage my project or changing code
without knowing
what they are doing... They could be doing this just to get rid of me
either (which I dont
know ) as I dont know *who*. In the past, I used to just take my network
cable off and
not be bothered with personal backups but on a shared network with clearcase
I cant
go offline. Cannot upgrade from 9.0 to Fedora... Each day, there are
different problems
with the machine...
So, this is the prime basis of resentment in my words. Its kind of happening
again.
There are routines in u-boot e.g. cpu_post_exec_02 and cpu_post_exec_04
which use a
stackless approach to copy a function to a given address, execute them and
pass the values
back to the calling app. It was working the other day and now its not. I
test the first instruction
it has to execute and it was supposed to be 0x38000000 and it shows as
0x38000331. I mentioned
it to my peer and next day its different. I dont like hidden resources on
my project but dont know
if I should ask ? If its by design or by coincidence... Generally hidden
resources(unless very skilled
& dillignet) cause more harm than help...
I am not sure about gdb protocol support for Metrowerks but it should be an
easy extension. Just
like changing the Phy on BDI should be easy change. Not sure if it has a
FPGA or ASIC or some
controller driving the JTAG chain. JTAG on BDI (is probably 12 or 16MHz) so
its faster than
a 10Mbps ethernet link. They were just saving cost as JTAG chain
address/data cycles are long
so one wont get a full 10MHz data transfer. JTAG by itself can go to 40MHz
so, the next rev of
BDI can go with a faster JTAG chain and 100Mbps link or a USB link.
Advantages of Metwerks so far :
1. Comes with the reference board from Freescale with 1 month license.
2. I did not get any help from BDI to setup the config file for 870/885
processor.
3. BDI did not program the AMD 29F style flash part.
4. BDI does not program the micro IC chip on Xscale. If one wants to debug
loadable modules
using BDI it did not happen as it does before mounting the initial ram
disk. Seemed like
a VECTOR LO/HIGH problem which their FAE did not or was not willing to
explain. Too much
pain for the effort required to resolve the problem with external
folks...
5. On 8540, the BDI only worked with single stepping or running to a break
point 5-10 instructions
away. Not sure what was the problem as I had to relocate the entire
U-boot code to run from
a pre-init DDR RAM instead of a swizzled flash in 5-7 days with no PPC
experience. Just schedule
pressure becuase of lack of planning on other people's part. On top of
that, the mgmt wanted me to
limit hours. Not sure if to keep me less stressed or just be cheap!!
6. Based on the above experience with BDI, I recommended Metrowerks. On my
project, one of
the reference board was busted. We could not get it fixed. Each board
was $2.5K each but they
were useless. The software CD ROM was erased by someone (which had all
the manuals).
Somebody broke into my car and started smoking ciggerettes.
So, what should I say. How far can one complain. I just told the
psychologist that someone is giving me
a hard time. Its definitely not any disorder.... Generally as engineer, we
can differentiate between a
bug a feature and a hack. When a hack (or a hacker) is trying to hinder
your progress or cause grief
or spoof a website so that you have wrong u-boot code, the individual is in
trouble. Based on probability,
its usually somone from the inside who changes code, crashes your
CVS/clearcase or modifies code
without a trace(perfect bug fix or hack by clearing logs or buffer underrun
problem to hack). The cable
off solution along with shutting down all the server apps was an easy
solution as the kernel is not listening
to sockets (since http server is gone from 2.4 kernel). And if the site is
spoofed, its usually your area ISP who can help. (e.g. if you google for
u-boot on source forge you only get u-boot 1.0.0 and if you access the site
directly, you get access to 1.1.2 & 1.1.3). Thats the main reason for the
resentment.
Now, all one can do in these situations is complain. Now if the complain
falls on deaf ears, what more can
you do. Typical answer is that you are working too hard. But this is an
easy forced attrition method.
So, now if processors have a wireless link, forced attrition would be a
common problem.
And I am still objective. Wolf does not maintain the sourceforge site. He
is just the moderator or main
contributor. And we are not using VPN's globally to reduce spoof web site
problem as many open source
projects could have excess bugs in them...
--
Atul
^ permalink raw reply
* Re: [PATCH 001/001 Updated] PMAC HD runtime blinking control
From: Benjamin Herrenschmidt @ 2006-01-23 13:47 UTC (permalink / raw)
To: Cedric Pradalier; +Cc: Linuxppc-dev, debian-powerpc
In-Reply-To: <20060123233823.3f0dbad5.cedric.pradalier@inrialpes.fr>
> The key I could not understand was that hwif->gendev is
> only initialised in the probe. So I had to move the
> device creation after that.
>
> Currently, it is blinking by default. Should it be that
> way? I guess so, since it is activated by a kernel config
> option. It is easy to change if required.
Yes. In fact, by enabled default for ATA disks and by disabled for ATAPI
would make sense...
Also, we should think a bit about the file name... "blinking_led" isn't
terrific for something that will end up in a non-ppc specific location.
Or maybe on the contrary it's good ... what about "activity_led"
rather ?
> Anyway, here is the updated patch.
>
> signed-off-by: Cedric Pradalier <cedric.pradalier@free.fr>
> ---
> --- drivers/ide/ppc/pmac.c.orig 2006-01-03 13:21:10.000000000 +1000
> +++ drivers/ide/ppc/pmac.c 2006-01-23 23:32:18.000000000 +1000
> @@ -36,6 +36,11 @@
> #include <linux/pmu.h>
> #include <linux/scatterlist.h>
>
> +#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
> +#include <linux/device.h>
> +#include <asm/of_device.h>
> +#endif
> +
> #include <asm/prom.h>
> #include <asm/io.h>
> #include <asm/dbdma.h>
> @@ -427,6 +432,15 @@ static void pmac_ide_kauai_selectproc(id
>
> #ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
>
> +MODULE_AUTHOR("Paul Mackerras & Ben. Herrenschmidt");
> +MODULE_DESCRIPTION("Support for IDE interfaces on PowerMacs");
> +MODULE_LICENSE("GPL");
> +
> +static int blinking_led = 1;
> +module_param_named(noblink,blinking_led, invbool, 0666);
> +MODULE_PARM_DESC(noblink,"Enable/Disable blinking led [Default: enabled]");
> +
> +
> /* Set to 50ms minimum led-on time (also used to limit frequency
> * of requests sent to the PMU
> */
> @@ -437,8 +451,7 @@ static spinlock_t pmu_blink_lock;
> static unsigned long pmu_blink_stoptime;
> static int pmu_blink_ledstate;
> static struct timer_list pmu_blink_timer;
> -static int pmu_ide_blink_enabled;
> -
> +static int pmu_ide_blink_enabled = 0;
>
> static void
> pmu_hd_blink_timeout(unsigned long data)
> @@ -468,6 +481,8 @@ static void
> pmu_hd_kick_blink(void *data, int rw)
> {
> unsigned long flags;
> + if (!blinking_led)
> + return;
>
> pmu_blink_stoptime = jiffies + PMU_HD_BLINK_TIME;
> wmb();
> @@ -483,6 +498,26 @@ pmu_hd_kick_blink(void *data, int rw)
> spin_unlock_irqrestore(&pmu_blink_lock, flags);
> }
>
> +static ssize_t show_blinkingled_activity(struct device *dev, struct device_attribute *attr, char *buf)\
> +{
> + return sprintf(buf, "%c\n", blinking_led?'1':'0');
> +}
> +
> +static ssize_t set_blinkingled_activity(struct device *dev, struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + int blink;
> + if (sscanf (buf, "%d", &blink) != 1)
> + return -EINVAL;
> + blinking_led = (blink != 0);
> + printk(KERN_INFO "pmac blinking led initialized (blink %s)\n",
> + blinking_led?"enabled":"disabled");
> + return count;
> +}
> +
> +static DEVICE_ATTR (blinking_led, S_IRUGO | S_IWUSR,
> + show_blinkingled_activity, set_blinkingled_activity);
> +
> static int
> pmu_hd_blink_init(void)
> {
> @@ -516,6 +551,9 @@ pmu_hd_blink_init(void)
> init_timer(&pmu_blink_timer);
> pmu_blink_timer.function = pmu_hd_blink_timeout;
>
> + printk(KERN_INFO "pmac blinking led initialized (blink %s)\n",
> + blinking_led?"enabled":"disabled");
> +
> return 1;
> }
>
> @@ -1271,7 +1309,7 @@ static int
> pmac_ide_setup_device(pmac_ide_hwif_t *pmif, ide_hwif_t *hwif)
> {
> struct device_node *np = pmif->node;
> - int *bidp, i;
> + int *bidp;
>
> pmif->cable_80 = 0;
> pmif->broken_dma = pmif->broken_dma_warn = 0;
> @@ -1401,6 +1439,12 @@ pmac_ide_setup_device(pmac_ide_hwif_t *p
> /* We probe the hwif now */
> probe_hwif_init(hwif);
>
> +#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
> + /* We wait till here to have the gendev initialized in hwif */
> + device_create_file (&hwif->gendev, &dev_attr_blinking_led);
> +#endif
> +
> +
> return 0;
> }
>
^ permalink raw reply
* [PATCH 001/001 Updated] PMAC HD runtime blinking control
From: Cedric Pradalier @ 2006-01-23 13:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linuxppc-dev, debian-powerpc
In-Reply-To: <1137898193.12998.83.camel@localhost.localdomain>
According to Benjamin Herrenschmidt, on Sun, 22 Jan 2006
13:49:53 +1100,
>On Sun, 2006-01-22 at 12:19 +1000, Cedric Pradalier wrote:
>> Hi,
>>
>> I've finally spend the time to mend the patch for control of
>> the HD led blinking at runtime. This is a patch against
>> 2.6.15
>>
>> The sysfs entry is attached to the PCI device and to the
>> MACIO device if available. I think that was what Ben was
>> asking for:
>
>Heh, nice :) Almost ! It would be better if it was attached to the sysfs
>node of the ide interface, you can find it in the HWIF array after
>probe, but I won't be too much of a pain about that for now :)
>
>Ben.
>
>
OK, I think now I got it.
pradalie@lauren-ph:~$ find /sys/ | grep blink
/sys/devices/pci0001:10/0001:10:17.0/0.80000000:mac-io/0.0001f000:ata-4/ide0/blinking_led
The key I could not understand was that hwif->gendev is
only initialised in the probe. So I had to move the
device creation after that.
Currently, it is blinking by default. Should it be that
way? I guess so, since it is activated by a kernel config
option. It is easy to change if required.
Anyway, here is the updated patch.
signed-off-by: Cedric Pradalier <cedric.pradalier@free.fr>
---
--- drivers/ide/ppc/pmac.c.orig 2006-01-03 13:21:10.000000000 +1000
+++ drivers/ide/ppc/pmac.c 2006-01-23 23:32:18.000000000 +1000
@@ -36,6 +36,11 @@
#include <linux/pmu.h>
#include <linux/scatterlist.h>
+#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
+#include <linux/device.h>
+#include <asm/of_device.h>
+#endif
+
#include <asm/prom.h>
#include <asm/io.h>
#include <asm/dbdma.h>
@@ -427,6 +432,15 @@ static void pmac_ide_kauai_selectproc(id
#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
+MODULE_AUTHOR("Paul Mackerras & Ben. Herrenschmidt");
+MODULE_DESCRIPTION("Support for IDE interfaces on PowerMacs");
+MODULE_LICENSE("GPL");
+
+static int blinking_led = 1;
+module_param_named(noblink,blinking_led, invbool, 0666);
+MODULE_PARM_DESC(noblink,"Enable/Disable blinking led [Default: enabled]");
+
+
/* Set to 50ms minimum led-on time (also used to limit frequency
* of requests sent to the PMU
*/
@@ -437,8 +451,7 @@ static spinlock_t pmu_blink_lock;
static unsigned long pmu_blink_stoptime;
static int pmu_blink_ledstate;
static struct timer_list pmu_blink_timer;
-static int pmu_ide_blink_enabled;
-
+static int pmu_ide_blink_enabled = 0;
static void
pmu_hd_blink_timeout(unsigned long data)
@@ -468,6 +481,8 @@ static void
pmu_hd_kick_blink(void *data, int rw)
{
unsigned long flags;
+ if (!blinking_led)
+ return;
pmu_blink_stoptime = jiffies + PMU_HD_BLINK_TIME;
wmb();
@@ -483,6 +498,26 @@ pmu_hd_kick_blink(void *data, int rw)
spin_unlock_irqrestore(&pmu_blink_lock, flags);
}
+static ssize_t show_blinkingled_activity(struct device *dev, struct device_attribute *attr, char *buf)\
+{
+ return sprintf(buf, "%c\n", blinking_led?'1':'0');
+}
+
+static ssize_t set_blinkingled_activity(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ int blink;
+ if (sscanf (buf, "%d", &blink) != 1)
+ return -EINVAL;
+ blinking_led = (blink != 0);
+ printk(KERN_INFO "pmac blinking led initialized (blink %s)\n",
+ blinking_led?"enabled":"disabled");
+ return count;
+}
+
+static DEVICE_ATTR (blinking_led, S_IRUGO | S_IWUSR,
+ show_blinkingled_activity, set_blinkingled_activity);
+
static int
pmu_hd_blink_init(void)
{
@@ -516,6 +551,9 @@ pmu_hd_blink_init(void)
init_timer(&pmu_blink_timer);
pmu_blink_timer.function = pmu_hd_blink_timeout;
+ printk(KERN_INFO "pmac blinking led initialized (blink %s)\n",
+ blinking_led?"enabled":"disabled");
+
return 1;
}
@@ -1271,7 +1309,7 @@ static int
pmac_ide_setup_device(pmac_ide_hwif_t *pmif, ide_hwif_t *hwif)
{
struct device_node *np = pmif->node;
- int *bidp, i;
+ int *bidp;
pmif->cable_80 = 0;
pmif->broken_dma = pmif->broken_dma_warn = 0;
@@ -1401,6 +1439,12 @@ pmac_ide_setup_device(pmac_ide_hwif_t *p
/* We probe the hwif now */
probe_hwif_init(hwif);
+#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
+ /* We wait till here to have the gendev initialized in hwif */
+ device_create_file (&hwif->gendev, &dev_attr_blinking_led);
+#endif
+
+
return 0;
}
^ permalink raw reply
* Re: [Alsa-devel] RFC: OSS driver removal, a slightly different approach
From: Ben Collins @ 2006-01-23 13:12 UTC (permalink / raw)
To: Takashi Iwai
Cc: alsa-devel, linux-kernel, Adrian Bunk, linuxppc-dev, Olaf Hering
In-Reply-To: <s5hd5ijyw2q.wl%tiwai@suse.de>
On Mon, 2006-01-23 at 13:20 +0100, Takashi Iwai wrote:
> > > > > Can someone from the ppc developers drop me a small note whether
> > > > > SND_POWERMAC completely replaces DMASOUND_PMAC?
> > > >
> > > > It doesnt. Some tumbler models work only after one plug/unplug cycle of
> > > > the headphone. early powerbooks report/handle the mute settings
> > > > incorrectly. there are likely more bugs.
> > >
> > > Interesting... Ben Collins hacked something to have Toonie work as a
> > > "default" driver for non supported machine and saw that problem too, I
> > > think he fixes it, I'll check with him what's up there and if his fix
> > > applied to tumbler.c as well.
> >
> > My "fix" was basically the result of converting to the platform
> > functions. It's hit or miss whether this works with tumbler too.
> >
> > You can try the Ubuntu kernel packages (they can be unpacked and used on
> > non Ubuntu systems pretty easily) to see if it works for you. Tumbler
> > platform function conversion isn't even tested, so I'd be happy to hear
> > any feedback.
>
> Don't forget to forward your patches to alsa-devel or me ;)
I'm passing everything through to BenH, especially since it's all using
functions new in his ppc tree.
Update on this "fix", it worked only because platform function
interrupts weren't enabled. Now that they are, it's back to the same old
thing.
At least that's a clue, though.
--
Ben Collins
Kernel Developer - Ubuntu Linux
^ permalink raw reply
* Re: [Alsa-devel] RFC: OSS driver removal, a slightly different approach
From: Takashi Iwai @ 2006-01-23 12:20 UTC (permalink / raw)
To: Ben Collins
Cc: alsa-devel, Ben Collins, linux-kernel, Adrian Bunk, linuxppc-dev,
Olaf Hering
In-Reply-To: <1137799330.13530.30.camel@grayson>
At Fri, 20 Jan 2006 18:22:10 -0500,
Ben Collins wrote:
>
> On Sat, 2006-01-21 at 10:16 +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2006-01-20 at 22:29 +0100, Olaf Hering wrote:
> > > On Fri, Jan 20, Adrian Bunk wrote:
> > >
> > >
> > > > Can someone from the ppc developers drop me a small note whether
> > > > SND_POWERMAC completely replaces DMASOUND_PMAC?
> > >
> > > It doesnt. Some tumbler models work only after one plug/unplug cycle of
> > > the headphone. early powerbooks report/handle the mute settings
> > > incorrectly. there are likely more bugs.
> >
> > Interesting... Ben Collins hacked something to have Toonie work as a
> > "default" driver for non supported machine and saw that problem too, I
> > think he fixes it, I'll check with him what's up there and if his fix
> > applied to tumbler.c as well.
>
> My "fix" was basically the result of converting to the platform
> functions. It's hit or miss whether this works with tumbler too.
>
> You can try the Ubuntu kernel packages (they can be unpacked and used on
> non Ubuntu systems pretty easily) to see if it works for you. Tumbler
> platform function conversion isn't even tested, so I'd be happy to hear
> any feedback.
Don't forget to forward your patches to alsa-devel or me ;)
thanks,
Takashi
^ permalink raw reply
* Re: u-boot debugging
From: David Jander @ 2006-01-23 9:32 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Atul Sabharwal
In-Reply-To: <005301c61e54$aadb1b10$02c0650a@ATULSPC>
On Saturday 21 January 2006 07:34, Atul Sabharwal wrote:
> You have a conflict of interest as you are just pissed with Metrowerks
> as they are your competitors. Open source is about free speech and
> not for people with vested interests. You seem to be one of the guys
> with vested interest.
Everybody has their interests. Even OSS programmers have interests, if not
always of economical nature. I don't think Mr. Denk has any more reasons to
"be pissed" with Metrowerks than you might have reasons to "be pissed" with
DENX or Abatron.
> You cannot repress people and tell them *oxymorons* or ninkampoops...
> If you do the cost benefit analysis between BDI and Metrowerks debugger,
> its the same. And their UI is better than ddd and works with a BDI also.
> So, if you consider all aspects, its a better product.
That is a very subjective observation. Here is a slightly more objective one
for you: BDI can use almost any UI that supports gdb, and there are quite a
lot. Not only DDD. Does Metrowerks offer you that amount of choice?
> And opensource is used all over the globe including the Asian subcontinent.
> And there are still sites which use hubs as people dont have the excess
> money
> to throw away on legacy products. Just sitting in your small cube does not
> give
> insight to global technology trends...
Well, I suppose using a 10Mbps switch shouldn't cost much more than a 100Mbps
hub, and you almost said it yourself, that it would be more efficient in a
crowded network ;-)
What I really wonder is what the choice between a switch and a hub has to do
with "global technology trends".
I detect an increasing amount of resentment in your words, and that is not
good as far as my experience goes.
Greetings,
--
David Jander
^ permalink raw reply
* RE: u-boot debugging
From: Alexandre BASTOS @ 2006-01-23 9:25 UTC (permalink / raw)
To: atul.sabharwal; +Cc: linuxppc-embedded
In-Reply-To: <4A062D477D842B4C8FC48EA5AF2D41F201AC2CF4@us-bv-m23.global.tektronix.net>
> First learn to communicate in English. I can give you 25 Us cents as I
> cannot afford 1 Mark. You are not work even a Mark.
>
What in the hell is this. Please, there are some here who don't speak
a perfect english but try to use it as a common language to exchange.
I feel also offended about this.
And please, read something apart from user manuals ... mark is no longer
the german currency. Euro, ... you know?
Un saudo
Alex Bastos
^ permalink raw reply
* RE: u-boot debugging
From: Paula Saameño @ 2006-01-23 7:48 UTC (permalink / raw)
To: 20060122082849.66877.qmail, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 101 bytes --]
I do as well, Glenn... He gave me so much help in my learning and he only
deserves good comments!!
[-- Attachment #2: Type: text/html, Size: 104 bytes --]
^ permalink raw reply
* 2.4.x vs 2.6.x performance
From: Frank @ 2006-01-23 4:24 UTC (permalink / raw)
To: linuxppc-embedded
I remember reading a while back that the 2.6 kernel is
considerably slower then the 2.4 kernel (Wolfgang Denx). Has
anybody taken any performance measurements on a later kernel
version to see if the above still hods true?
I'm thinking about moving to 2.6 since a lot of open source
projects have stopped suporting the 2.4 kernel.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH 001/001] PMAC HD runtime blinking control
From: Benjamin Herrenschmidt @ 2006-01-22 21:59 UTC (permalink / raw)
To: Arkadiusz Miskiewicz; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <200601221256.25685.arekm@pld-linux.org>
On Sun, 2006-01-22 at 12:56 +0100, Arkadiusz Miskiewicz wrote:
> On Sunday 22 January 2006 03:19, Cedric Pradalier wrote:
> > Hi,
> >
> > I've finally spend the time to mend the patch for control of
> > the HD led blinking at runtime. This is a patch against
> > 2.6.15
>
> I wonder if it's also possible to disable blinking when laptop sleeps?
Not that I know.. this is entirely done by the PMU.
Ben.
^ permalink raw reply
* [PATCH] cleanup pmac_newworld variable usage
From: Olaf Hering @ 2006-01-22 21:19 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
remove extern declarations of pmac_newworld
move pmac_newworld to bss
if there is any "interrupt-controller" device, then it is newworld.
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/kernel/ppc_ksyms.c | 1 -
arch/powerpc/platforms/powermac/setup.c | 8 ++++----
2 files changed, 4 insertions(+), 5 deletions(-)
Index: linux-2.6.16-rc1-olh/arch/powerpc/kernel/ppc_ksyms.c
===================================================================
--- linux-2.6.16-rc1-olh.orig/arch/powerpc/kernel/ppc_ksyms.c
+++ linux-2.6.16-rc1-olh/arch/powerpc/kernel/ppc_ksyms.c
@@ -57,7 +57,6 @@ extern void machine_check_exception(stru
extern void alignment_exception(struct pt_regs *regs);
extern void program_check_exception(struct pt_regs *regs);
extern void single_step_exception(struct pt_regs *regs);
-extern int pmac_newworld;
extern int sys_sigreturn(struct pt_regs *regs);
EXPORT_SYMBOL(clear_pages);
Index: linux-2.6.16-rc1-olh/arch/powerpc/platforms/powermac/setup.c
===================================================================
--- linux-2.6.16-rc1-olh.orig/arch/powerpc/platforms/powermac/setup.c
+++ linux-2.6.16-rc1-olh/arch/powerpc/platforms/powermac/setup.c
@@ -88,11 +88,10 @@ int ppc_override_l2cr = 0;
int ppc_override_l2cr_value;
int has_l2cache = 0;
-int pmac_newworld = 1;
+int pmac_newworld;
static int current_root_goodness = -1;
-extern int pmac_newworld;
extern struct machdep_calls pmac_md;
#define DEFAULT_ROOT_DEVICE Root_SDA1 /* sda1 - slightly silly choice */
@@ -310,9 +309,10 @@ static void __init pmac_setup_arch(void)
for (ic = NULL; (ic = of_find_all_nodes(ic)) != NULL; )
if (get_property(ic, "interrupt-controller", NULL))
break;
- pmac_newworld = (ic != NULL);
- if (ic)
+ if (ic) {
+ pmac_newworld = 1;
of_node_put(ic);
+ }
/* Lookup PCI hosts */
pmac_pci_init();
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: [PATCH 001/001] PMAC HD runtime blinking control
From: Arkadiusz Miskiewicz @ 2006-01-22 11:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: debian-powerpc
In-Reply-To: <20060122121907.792abc72.cedric.pradalier@free.fr>
On Sunday 22 January 2006 03:19, Cedric Pradalier wrote:
> Hi,
>
> I've finally spend the time to mend the patch for control of
> the HD led blinking at runtime. This is a patch against
> 2.6.15
I wonder if it's also possible to disable blinking when laptop sleeps?
=2D-=20
Arkadiusz Mi=B6kiewicz PLD/Linux Team
http://www.t17.ds.pwr.wroc.pl/~misiek/ http://ftp.pld-linux.org/
^ permalink raw reply
* u-boot debugging
From: Albert David @ 2006-01-22 10:10 UTC (permalink / raw)
To: linuxppc-embedded
>> On Friday 20 January 2006 08:00 pm, AtulAtulhSabharwalte:
>> > First learn to communicate in English. I can give you 25 Us
>> cents as I
>> > cannot afford 1 Mark. You are not work even a Mark.
>>
>> The complete lack of civility in this remark is inexcusable in
>> a public forum.
>> Herr DenkDenk provided an incredibly valuable service to the
>> community, and
>> deserves more respect than this.
>I agree whole heartily Glenn...
glenn and frank,
even me too! i agree with you.
Best regards,
Albert David.
^ permalink raw reply
* spinlockup detection on POWER3
From: Olaf Hering @ 2006-01-22 8:38 UTC (permalink / raw)
To: linuxppc-dev
Does the CONFIG_DEBUG_SPINLOCK code somehow depend on the cpu type?
It triggers alot on a p270 POWER3 box, even during early boot. I dont
see it on POWE4/5.
This is with 2.6.15+
...
PCI: Probing PCI hardware
Failed to request PCI IO region on PCI domain 0000
IOMMU table initialized, virtual merging enabled
ISA bridge at 0000:00:0b.0
mapping IO f8000000 -> d000080000000000, size: 1000000
mapping IO f9000000 -> d000080001000000, size: 1000000
PCI: Probing PCI hardware done
usbcore: registered new driver usbfs
usbcore: registered new driver hub
TC classifier action (bugs to netdev@vger.kernel.org cc hadi@cyberus.ca)
IBM eBus Device Driver
RTAS daemon started
audit: initializing netlink socket (disabled)
audit(1137918797.139:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Using unsupported 1024x768 display at c0000000, depth=8, pitch=1024
Console: switching to colour frame buffer device 128x48
fb0: Open Firmware frame buffer device on /pci@fef00000/display@f
HVSI: registered 0 devices
Generic RTC Driver v1.07
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
BUG: spinlock lockup on CPU#3, hotplug/1384, c000000000456900
Call Trace:
[C00000003FD37900] [C00000000000ED88] .show_stack+0x68/0x1b0 (unreliable)
[C00000003FD379A0] [C0000000001C9780] ._raw_spin_lock+0x110/0x150
[C00000003FD37A20] [C000000000369960] .lock_kernel+0x3c/0x64
[C00000003FD37AA0] [C0000000000CF8D8] .chrdev_open+0x1b4/0x268
[C00000003FD37B50] [C0000000000C0538] .__dentry_open+0x160/0x300
[C00000003FD37C00] [C0000000000C084C] .do_filp_open+0x50/0x70
[C00000003FD37D00] [C0000000000C08E0] .do_sys_open+0x74/0x12c
[C00000003FD37DB0] [C0000000000FCB24] .compat_sys_open+0x24/0x38
[C00000003FD37E30] [C0000000000086F8] syscall_exit+0x0/0x40
serial8250.0: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
serial8250.0: ttyS2 at I/O 0x898 (irq = 15) is a 16550A
pmac_zilog: 0.6 (Benjamin Herrenschmidt <benh@kernel.crashing.org>)
RAMDISK driver initialized: 16 RAM disks of 123456K size 1024 blocksize
loop: loaded (max 8 devices)
input: Macintosh mouse button emulation as /class/input/input0
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
mice: PS/2 mouse device common for all mice
input: AT Raw Set 2 keyboard as /class/input/input1
...
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* RE: u-boot debugging
From: Frank @ 2006-01-22 8:28 UTC (permalink / raw)
To: Glenn Burkhardt, linuxppc-embedded; +Cc: atul.sabharwal
In-Reply-To: <200601210920.01703.glenn@aoi-industries.com>
--- Glenn BurkBurkhardtenglenn-aoiustries.com> wrote:
> On Friday 20 January 2006 08:00 pm, AtulAtulhSabharwalte:
> > First learn to communicate in English. I can give you 25 Us
> cents as I
> > cannot afford 1 Mark. You are not work even a Mark.
>
> The complete lack of civility in this remark is inexcusable in
> a public forum.
> Herr DenkDenk provided an incredibly valuable service to the
> community, and
> deserves more respect than this.
I agree whole heartily Glenn...
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH 001/001] PMAC HD runtime blinking control
From: Benjamin Herrenschmidt @ 2006-01-22 8:25 UTC (permalink / raw)
To: Cedric Pradalier; +Cc: Linuxppc-dev
In-Reply-To: <20060122181126.357df500.cedric.pradalier@inrialpes.fr>
On Sun, 2006-01-22 at 18:11 +1000, Cedric Pradalier wrote:
> In ide_hwif_t, I'm using the pci_dev. Where in the pci_dev
> can I find ide0? or is it somewhere else in ide_hwif_t?
Yah, I think it's in there (in ide_hwif_t)
> For the HWIF array, I guess you're talking about ide_hwifs.
> How do I identify the interface itself there?
well, depends what you are working from... pmif has an index into it
for example...
> Hmm, plenty of questions. I hope at least one is relevant
> for this problem...
>
> Thanks
> --
> Cedric
^ permalink raw reply
* Re: [PATCH 001/001] PMAC HD runtime blinking control
From: Cedric Pradalier @ 2006-01-22 8:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linuxppc-dev
In-Reply-To: <1137898193.12998.83.camel@localhost.localdomain>
According to Benjamin Herrenschmidt, on Sun, 22 Jan 2006
13:49:53 +1100,
>On Sun, 2006-01-22 at 12:19 +1000, Cedric Pradalier wrote:
>> Hi,
>>
>> I've finally spend the time to mend the patch for control of
>> the HD led blinking at runtime. This is a patch against
>> 2.6.15
>>
>> The sysfs entry is attached to the PCI device and to the
>> MACIO device if available. I think that was what Ben was
>> asking for:
>
>Heh, nice :) Almost ! It would be better if it was attached to the sysfs
>node of the ide interface, you can find it in the HWIF array after
>probe, but I won't be too much of a pain about that for now :)
>
Yep, now I remember, that was what you where asking for.
Can you give me an idea of the sysfs path you're expecting?
Is it in
bus/ide/...,
bus/pci/drivers/ide-pmac,
bus/pci/drivers/ide-disk
devices/pci0001:10/0001:10:17.0/0.80000000:mac-io/0.0001f000:ata-4/ide0
I would guess on the latter.
For now I'm using the pmif->mdev->ofdev.dev as attachment
device, which brings me into 0.0001f000:ata-4
What in pmif can brings me to the ide0? pmif->node? Or one
of its siblings?
In ide_hwif_t, I'm using the pci_dev. Where in the pci_dev
can I find ide0? or is it somewhere else in ide_hwif_t?
For the HWIF array, I guess you're talking about ide_hwifs.
How do I identify the interface itself there?
Hmm, plenty of questions. I hope at least one is relevant
for this problem...
Thanks
--
Cedric
^ permalink raw reply
* [PATCH] Check for altname == NULL in snd-pmac-gpio.c
From: Ben Collins @ 2006-01-22 4:43 UTC (permalink / raw)
To: Linuxppc-dev
Since callers don't have to pass altname, snd-pmac-gpio.c should have
been checking for NULL, and it wasn't.
Also, fixes the pmf_unregister_irq_client() call to match the previous
patch.
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
diff --git a/sound/ppc/snd-pmac-gpio.c b/sound/ppc/snd-pmac-gpio.c
index 25ef5e9..480e1ca 100644
--- a/sound/ppc/snd-pmac-gpio.c
+++ b/sound/ppc/snd-pmac-gpio.c
@@ -41,7 +41,7 @@ static struct pmf_function *get_audio_pf
return NULL;
pfunc = pmf_find_function(np, name);
- if (pfunc == NULL && altname != NULL)
+ if (pfunc == NULL && altname)
pfunc = pmf_find_function(np, altname);
return pfunc;
@@ -58,10 +58,10 @@ static struct device_node *find_audio_gp
for (np = np->child; np; np = np->sibling) {
char *property = get_property(np, "audio-gpio", NULL);
if (property && (strcmp(property, name) == 0 ||
- strcmp(property, altname) == 0))
+ (altname && strcmp(property, altname) == 0)))
break;
if (device_is_compatible(np, name) ||
- device_is_compatible(np, altname))
+ (altname && device_is_compatible(np, altname)))
break;
}
@@ -136,11 +136,7 @@ void snd_pmac_free_gpio(snd_pmac_gpio_t
{
if (gp->pfunc != NULL) {
if (gp->irq_client.owner == THIS_MODULE) {
- /* XXX: pmf_unregister_irq_client doesn't use its
- * first two arguments. We only need to send it
- * the irq_client. WATCH FOR THIS CHANGING!
- */
- pmf_unregister_irq_client(NULL, NULL, &gp->irq_client);
+ pmf_unregister_irq_client(&gp->irq_client);
gp->irq_client.owner = NULL;
}
@@ -233,7 +229,7 @@ int snd_pmac_request_irq(snd_pmac_gpio_t
if ((np = find_devices("i2s-a"))) {
ret = pmf_register_irq_client(np, gp->name, &gp->irq_client);
- if (ret < 0)
+ if (ret < 0 && gp->altname)
ret = pmf_register_irq_client(np, gp->altname, &gp->irq_client);
}
if (ret < 0)
--
Ben Collins
Kernel Developer - Ubuntu Linux
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox