* Re: 8xx SMC1 problem
From: Wolfgang Denk @ 2006-03-16 20:10 UTC (permalink / raw)
To: Björn Östby; +Cc: linuxppc-embedded
In-Reply-To: <004B1D7A5257174C9044A1B7BD0E60ED0178CC68@ratatosk.combitechsystems.com>
In message <004B1D7A5257174C9044A1B7BD0E60ED0178CC68@ratatosk.combitechsystems.com> you wrote:
>
> First of, I have three serial ports (SMC1, SMC2 and SCC3) and they all work
> fine when the console is on SMC1. I have gadgets connected to SMC2 and SCC
> 3 and now I need SMC1 for yet another device. So I have undefined CONFIG_SE
> RIAL_CONSOLE in the kernel config and I jump out of u-boot (which have the
> console on SMC1) with the argument "console=none".
And did you make sure that no other process is accessing ttyS0 ?
> When logging in (via telnet) ttyS0 works no more (but S1 and S2 does). At r
> andom bootups, it is possible to open the port but it is no good for read o
> r write.
>
> Can anybody give me some advise on how to enable SMC1 but at the same time
> don't have a console on it?
We did the same (passing console=null) in a couple of configurations
and had no problems using SMC1 as standard serial port. Try *not*
undefining CONFIG_SERIAL_CONSOLE.
And please keep your line length < 72 characters or so.
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
A committee is a life form with six or more legs and no brain.
-- Lazarus Long, "Time Enough For Love"
^ permalink raw reply
* Re: glibc, Perl for ppc440GX - compile problems
From: Wolfgang Denk @ 2006-03-16 20:07 UTC (permalink / raw)
To: powerpc440; +Cc: linuxppc-embedded
In-Reply-To: <44198DCB.90508@googlemail.com>
In message <44198DCB.90508@googlemail.com> you wrote:
>
> I'm trying to compile glibc-2.4 on my system but I have the error:
In your subject you mention Perl - what has glibc to do with it?
> ....
> running configure fragment for sysdeps/powerpc/powerpc32/elf
> checking for powerpc32 TLS support... yes
> running configure fragment for sysdeps/unix/sysv/linux/powerpc
> checking whether gcc -g -O2 -mlong-double-128 uses IBM extended format... no
> checking whether gcc -g -O2 supports -mabi=ibmlongdouble... no
> configure: error: this configuration requires -mlong-double-128 IBM
> extended format support
Are you running the native compiler on the board, or the cross
compiler? Did you apply all eventually needed patches?
> compiler : GCC 4.0.0 (DENX ELDK 4.0 4.0.0-1), the CPU is PPC440GX,
> Ocotea based board with own design.
Which architecture did you select? ppc_4xx- ??
> I'm thinking that, the 440GX is not gut supported from GCC 4.0.0 compiler.
> Do anobody already compile glibc and Perl for this platform, or can I
> find from somewhere .RPM packages?
We build Perl without any problems.
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
A meeting is an event at which the minutes are kept and the hours are
lost.
^ permalink raw reply
* Re: AW: kernel support for the MPC5200b
From: Wolfgang Denk @ 2006-03-16 20:01 UTC (permalink / raw)
To: achim.machura; +Cc: Linuxppc-Embedded (E-Mail)
In-Reply-To: <002401c648d6$5b808b70$34f1ff0a@beint.local>
In message <002401c648d6$5b808b70$34f1ff0a@beint.local> you wrote:
>
> > I want to run the Linux kernel on a device based on the Freescale
> MPC5200b, based on the MPC603e series G2_LE core.
>
> Look at www.denx.de there is support for 2.4 and 2.6
Actually we support only 2.4 on the MPC5200. The current 2.6 port has
a couple of known issues, and I cannot recommend it for any
commercial project yet.
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
An Ada exception is when a routine gets in trouble and says
'Beam me up, Scotty'.
^ permalink raw reply
* i2c-bus@0 twice?
From: Johannes Berg @ 2006-03-15 18:29 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 402 bytes --]
johannes@quad:/proc/device-tree/ht@0,f2000000/pci@8/mac-io@7/i2c@18000$ ls
AAPL,address built-in i2c-bus@0 linux,phandle
AAPL,address-step compatible interrupt-parent name
AAPL,i2c-rate device_type interrupts reg
#address-cells i2c-bus@0 linux,device #size-cells
Somewhat odd that i2c-bus@0 exists twice :) Anyone have an explanation?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* 8xx SMC1 problem
From: Björn Östby @ 2006-03-16 17:23 UTC (permalink / raw)
To: linuxppc-embedded
Hello everyone,
I have a question regarding the serial init of ttyS0 on a tqm8xx based =
board (823) in denx kernel 2.4.25.
First of, I have three serial ports (SMC1, SMC2 and SCC3) and they all =
work fine when the console is on SMC1. I have gadgets connected to SMC2 =
and SCC3 and now I need SMC1 for yet another device. So I have undefined =
CONFIG_SERIAL_CONSOLE in the kernel config and I jump out of u-boot =
(which have the console on SMC1) with the argument "console=3Dnone".
When logging in (via telnet) ttyS0 works no more (but S1 and S2 does). =
At random bootups, it is possible to open the port but it is no good for =
read or write.
Can anybody give me some advise on how to enable SMC1 but at the same =
time don't have a console on it?
Regards,
Bj=F6rn
^ permalink raw reply
* glibc, Perl for ppc440GX - compile problems
From: powerpc440 @ 2006-03-16 16:09 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.5.1142470804.1007.linuxppc-embedded@ozlabs.org>
Hello,
I'm trying to compile glibc-2.4 on my system but I have the error:
....
running configure fragment for sysdeps/powerpc/powerpc32/elf
checking for powerpc32 TLS support... yes
running configure fragment for sysdeps/unix/sysv/linux/powerpc
checking whether gcc -g -O2 -mlong-double-128 uses IBM extended format... no
checking whether gcc -g -O2 supports -mabi=ibmlongdouble... no
configure: error: this configuration requires -mlong-double-128 IBM
extended format support
compiler : GCC 4.0.0 (DENX ELDK 4.0 4.0.0-1), the CPU is PPC440GX,
Ocotea based board with own design.
I'm thinking that, the 440GX is not gut supported from GCC 4.0.0 compiler.
Do anobody already compile glibc and Perl for this platform, or can I
find from somewhere .RPM packages?
Regards,
Zhivko
^ permalink raw reply
* please pull powerpc-merge.git
From: Paul Mackerras @ 2006-03-16 10:53 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
I have redone the powerpc-merge.git tree and eliminated one
unnecessary merge that I had in there. I have pushed it up to
kernel.org using git push, and I have done a test pull to check that
it is all OK this time. So please do a pull from
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc-merge.git
There are the same set of commits in there as I listed in my last pull
request.
Thanks,
Paul.
^ permalink raw reply
* AW: kernel support for the MPC5200b
From: Achim Machura @ 2006-03-16 8:48 UTC (permalink / raw)
To: 'Henry Quinn'; +Cc: Linuxppc-Embedded (E-Mail)
In-Reply-To: <20060316061222.A93517A44CC@mail.sse.co.za>
Hello
> I want to run the Linux kernel on a device based on the Freescale
MPC5200b, based on the MPC603e series G2_LE core.
Look at www.denx.de there is support for 2.4 and 2.6
Achim
^ permalink raw reply
* SCC4 MPC8247 BD's
From: somshekar chandrashekar kadam @ 2006-03-16 7:55 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 419 bytes --]
Hi ,
I am using MPC8247 on a custom board , with FCC2 and SCC4 for ethernet and scc2 for serial console ,
if increase buffer descirptor size from 4 to 8 ,, kernel panics after some pings ,, increasing number of buffer diesciptor should not ne a problem , as far as i know , correct me if i am wrong . or there something else i should look into. please guide
thanks A Lot In Advance
Rgerds
Neelu
[-- Attachment #2: Type: text/html, Size: 799 bytes --]
^ permalink raw reply
* kernel support for the MPC5200b
From: Henry Quinn @ 2006-03-16 6:08 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 535 bytes --]
Hello all
I want to run the Linux kernel on a device based on the Freescale MPC5200b,
based on the MPC603e series G2_LE core.
What I don't understand is whether support for this processor is built into
the kernel or not, can one take a stock kernel from
www.kernel.org <http://www.kernel.org/> and compile it to run on this
processor or are there a series of patches that one needs to apply before
the
kernel will run on this processor?
I'd be really grateful if someone can clear this issue up for me.
Regards
Henry
[-- Attachment #2: Type: text/html, Size: 2921 bytes --]
^ permalink raw reply
* Re: dtc: .quad asm directive generation
From: David Gibson @ 2006-03-16 2:05 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <20060316015924.GA32493@mag.az.mvista.com>
On Wed, Mar 15, 2006 at 06:59:24PM -0700, Mark A. Greer wrote:
> On Thu, Mar 16, 2006 at 11:49:48AM +1100, David Gibson wrote:
> > On Wed, Mar 15, 2006 at 05:00:59PM -0700, Mark A. Greer wrote:
> > > On Tue, Mar 14, 2006 at 06:06:57PM -0600, Jon Loeliger wrote:
> > > >
> > > > For 9 months nothing. Dave abdicates his DTC maintainer role to me.
> > >
> > > Jon,
> > >
> > > I can't find dtc under ~dgibson on ozlabs anymore. Do you have it
> > > somewhere now?
> >
> > Ah, bother. I did arrange for one of the old addresses of the tree to
> > keep working, but forgot that it wasn't the one which had been widely
> > announced. Just a minute, I'll send an announcement to the lists.
>
> Okay, thanks guys.
>
> Here is a patch that fixes a problem I'm having with asm output. My
> host system is a x86 box so its 32-bit, little endian.
>
> Disclaimer: Everything below is AFAICT.
>
> The problem is that asm_emit_cell() was swapping its asm output when
> it shouldn't be (because the assembler will do the necessary swapping).
> The cell values (asm_emit_cell()) are different from the data values
> (asm_emit_data()) because the cell values are generated within the
> program and don't get swapped like the data values read from the dts file.
> They should be left as they are so that the assembler will swap them,
> if necessary. For example, when the property length field was 4,
> the asm output contained ".long 0x4000000" and sent the kernel prom.c
> dt parsing code into the weeds.
>
> The dtb output is correct.
>
> Did any of that make sense?
Ah, yes, that be32_to_cpu() is, indeed, complete crap.
> /me knows he's rambling...
>
> Anyway, here is a simple patch the fixes it for me (i.e., the
> cross-assembled asm output matches the dtb).
>
> Mark
> ---
>
> diff -Nurp dtc/flattree.c dtc_new/flattree.c
> --- dtc/flattree.c 2006-02-24 10:57:56.000000000 -0700
> +++ dtc_new/flattree.c 2006-03-15 18:02:07.000000000 -0700
> @@ -121,7 +121,7 @@ static void asm_emit_cell(void *e, cell_
> {
> FILE *f = e;
>
> - fprintf(f, "\t.long\t0x%x\n", be32_to_cpu(val));
> + fprintf(f, "\t.long\t0x%x\n", val);
> }
>
> static void asm_emit_string(void *e, char *str, int len)
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: dtc: .quad asm directive generation
From: Mark A. Greer @ 2006-03-16 1:59 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <20060316004948.GA1512@localhost.localdomain>
On Thu, Mar 16, 2006 at 11:49:48AM +1100, David Gibson wrote:
> On Wed, Mar 15, 2006 at 05:00:59PM -0700, Mark A. Greer wrote:
> > On Tue, Mar 14, 2006 at 06:06:57PM -0600, Jon Loeliger wrote:
> > >
> > > For 9 months nothing. Dave abdicates his DTC maintainer role to me.
> >
> > Jon,
> >
> > I can't find dtc under ~dgibson on ozlabs anymore. Do you have it
> > somewhere now?
>
> Ah, bother. I did arrange for one of the old addresses of the tree to
> keep working, but forgot that it wasn't the one which had been widely
> announced. Just a minute, I'll send an announcement to the lists.
Okay, thanks guys.
Here is a patch that fixes a problem I'm having with asm output. My
host system is a x86 box so its 32-bit, little endian.
Disclaimer: Everything below is AFAICT.
The problem is that asm_emit_cell() was swapping its asm output when
it shouldn't be (because the assembler will do the necessary swapping).
The cell values (asm_emit_cell()) are different from the data values
(asm_emit_data()) because the cell values are generated within the
program and don't get swapped like the data values read from the dts file.
They should be left as they are so that the assembler will swap them,
if necessary. For example, when the property length field was 4,
the asm output contained ".long 0x4000000" and sent the kernel prom.c
dt parsing code into the weeds.
The dtb output is correct.
Did any of that make sense?
/me knows he's rambling...
Anyway, here is a simple patch the fixes it for me (i.e., the
cross-assembled asm output matches the dtb).
Mark
---
diff -Nurp dtc/flattree.c dtc_new/flattree.c
--- dtc/flattree.c 2006-02-24 10:57:56.000000000 -0700
+++ dtc_new/flattree.c 2006-03-15 18:02:07.000000000 -0700
@@ -121,7 +121,7 @@ static void asm_emit_cell(void *e, cell_
{
FILE *f = e;
- fprintf(f, "\t.long\t0x%x\n", be32_to_cpu(val));
+ fprintf(f, "\t.long\t0x%x\n", val);
}
static void asm_emit_string(void *e, char *str, int len)
^ permalink raw reply
* dtc git tree has moved (and maintainership announcement)
From: David Gibson @ 2006-03-16 0:58 UTC (permalink / raw)
To: linuxppc-dev, linuxppc64-dev
For the next six months or so, I will be available intermittently at
best for dtc work. For this reason, Jon Loeliger of Freescale has
agreed to take over dtc maintainership for the interim.
As part of the logistics of this handover, the location of the dtc git
tree has changed. It is now available *only* via git daemon (not http
or rsync, sorry), the address is:
git://ozlabs.org/srv/projects/dtc/dtc.git
There is also now a web page for dtc, although at present there's
basically no information there, at:
http://dtc.ozlabs.org/
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: dtc: .quad asm directive generation
From: Stephen Rothwell @ 2006-03-16 0:56 UTC (permalink / raw)
To: Mark A. Greer; +Cc: Linuxppc-dev, jdl, david
In-Reply-To: <20060316000059.GA29326@mag.az.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 373 bytes --]
On Wed, 15 Mar 2006 17:00:59 -0700 "Mark A. Greer" <mgreer@mvista.com> wrote:
>
> I can't find dtc under ~dgibson on ozlabs anymore. Do you have it
> somewhere now?
http://dtc.ozlabs.org/ has a link to a tarball, or
git://ozlabs.org/~dgibson/git/dtc.git
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: dtc: .quad asm directive generation
From: David Gibson @ 2006-03-16 0:49 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <20060316000059.GA29326@mag.az.mvista.com>
On Wed, Mar 15, 2006 at 05:00:59PM -0700, Mark A. Greer wrote:
> On Tue, Mar 14, 2006 at 06:06:57PM -0600, Jon Loeliger wrote:
> >
> > For 9 months nothing. Dave abdicates his DTC maintainer role to me.
>
> Jon,
>
> I can't find dtc under ~dgibson on ozlabs anymore. Do you have it
> somewhere now?
Ah, bother. I did arrange for one of the old addresses of the tree to
keep working, but forgot that it wasn't the one which had been widely
announced. Just a minute, I'll send an announcement to the lists.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: dtc: .quad asm directive generation
From: Mark A. Greer @ 2006-03-16 0:00 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <E1FJJXV-0005Zf-7r@jdl.com>
On Tue, Mar 14, 2006 at 06:06:57PM -0600, Jon Loeliger wrote:
>
> For 9 months nothing. Dave abdicates his DTC maintainer role to me.
Jon,
I can't find dtc under ~dgibson on ozlabs anymore. Do you have it
somewhere now?
Mark
^ permalink raw reply
* Specify number of SPI received characters
From: Antonio Di Bacco @ 2006-03-15 22:11 UTC (permalink / raw)
To: linuxppc-embedded
Anyone knows, during an SPI transfer (8xx CPU as master and EEPROM as slave ),
how to specify how many characters I want to receive? When should I release
the chip select?
Thank you,
Antonio.
^ permalink raw reply
* Re: buildroot uClibc busybox and associated tool versions
From: Harald Küthe @ 2006-03-15 21:36 UTC (permalink / raw)
To: linuxppc-embedded, white
>>With uclibc Snapshot i get an toolchain, but on the Target:
>>busybox init segfaults during init, at different points.Try a different
>>malloc "version" in the uClibc config.Harald
^ permalink raw reply
* Re: spi support for 8xx in u-boot broken
From: Wolfgang Denk @ 2006-03-15 21:03 UTC (permalink / raw)
To: Antonio Di Bacco; +Cc: linuxppc-embedded
In-Reply-To: <200603152132.05124.antonio.dibacco@aruba.it>
In message <200603152132.05124.antonio.dibacco@aruba.it> you wrote:
> I enabled the SPI COMMAND in u-boot for an 8xx and it doesn't compile. Chipset
Off topic again. Please post U-Boot related questions on the U-Boot
mailing list.
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
"We don't have to protect the environment -- the Second Coming is at
hand." - James Watt
^ permalink raw reply
* Re: mii_send error or at least strange
From: Wolfgang Denk @ 2006-03-15 21:02 UTC (permalink / raw)
To: Antonio Di Bacco; +Cc: linuxppc-embedded
In-Reply-To: <200603152121.21852.antonio.dibacco@aruba.it>
In message <200603152121.21852.antonio.dibacco@aruba.it> you wrote:
> I had a look to mii_send code in u-boot/cpu/mpc8xx/fec.c . It supports both
You are off topic here. Please post U-Boot related questions on the
U-Boot mailing list.
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
Es gibt immer genug fuer die Beduerfnisse aller, aber niemals genug
fuer die Gier einzelner. -- Ghandi
^ permalink raw reply
* Re: please pull powerpc-merge.git
From: Paul Mackerras @ 2006-03-15 20:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0603150748380.3618@g5.osdl.org>
Linus Torvalds writes:
> Umm. What _have_ you done to that tree?
Just stuffed up the objects/info/alternates file. It's fixed now.
> Please just do "git push" to push to master. Use the "-f" flag if you
> want to force it because you did bad things. Don't use rsync. rsync on
> git repos is evil and wrong when there are other alternatives, and leads
> to crap like the above.
OK, will do.
Paul.
^ permalink raw reply
* spi support for 8xx in u-boot broken
From: Antonio Di Bacco @ 2006-03-15 20:32 UTC (permalink / raw)
To: linuxppc-embedded
I enabled the SPI COMMAND in u-boot for an 8xx and it doesn't compile. Chipset
in spi_xfer is not managed correctly!?!
I'm going to modify this code. Anyone is interested?
I know I shouldn't post on this mailing list for u-boot but where can I post?
Bye,
Antonio.
^ permalink raw reply
* mii_send error or at least strange
From: Antonio Di Bacco @ 2006-03-15 20:21 UTC (permalink / raw)
To: linuxppc-embedded
I had a look to mii_send code in u-boot/cpu/mpc8xx/fec.c . It supports both
FEC1 and FEC2 but anyway it seems to write always register mii-data of FEC1,
look here:
/* send command to phy using mii, wait for result */
static uint mii_send(uint mii_cmd)
{
uint mii_reply;
volatile fec_t *ep;
int cnt;
ep = &(((immap_t *)CFG_IMMR)->im_cpm.cp_fec);
ep->fec_mii_data = mii_cmd; /* command to phy */
/* wait for mii complete */
cnt = 0;
while (!(ep->fec_ievent & FEC_ENET_MII)) {
if (++cnt > 1000) {
printf("mii_send STUCK!\n");
break;
}
}
mii_reply = ep->fec_mii_data; /* result from phy */
ep->fec_ievent = FEC_ENET_MII; /* clear MII complete */
#if 0
printf("%s[%d] %s: sent=0x%8.8x, reply=0x%8.8x\n",
__FILE__,__LINE__,__FUNCTION__,mii_cmd,mii_reply);
#endif
return (mii_reply & 0xffff); /* data read from phy */
}
^ permalink raw reply
* Re: RFC: [PATCH Upated]: snd-pmac-gpio interfaces for snd-powermac
From: Johannes Berg @ 2006-03-15 18:00 UTC (permalink / raw)
To: Ben Collins; +Cc: Linuxppc-dev
In-Reply-To: <1137630485.4425.2.camel@grayson>
[-- Attachment #1: Type: text/plain, Size: 2086 bytes --]
Hi,
I have no idea if this is the latest version of this patch, but I
couldn't find any more recent one...
A few of comments inlined below.
> +static struct pmf_function *get_audio_pfunc(const char *name, const char *altname)
> +{
> + struct device_node *np;
> + struct pmf_function *pfunc = NULL;
> +
> + if (! (np = find_devices("i2s-a")))
> + return NULL;
Can we have this function take an explicit device parameter instead? As
it is now, it can only handle the i2s-a soundcard, while the latest
powermacs have two sound cards (codecs?): i2s-a and i2s-c.
> +int snd_pmac_get_gpio(const char *name, const char *altname,
> + snd_pmac_gpio_t *gp)
> +{
> + memset(gp, 0, sizeof(*gp));
> +
> + gp->name = name;
> + gp->altname = altname;
> +
> + /* Platform functions are prefered */
> + if ((gp->pfunc = get_audio_pfunc(name, altname)))
> + return 0;
> +
> + /* Else, fallback to direct gpio */
> + return get_audio_gpio(name, altname, gp);
Maybe there ought to be a way to disable the fallback when we're on
newer chips? I don't grok the sound architecture well enough yet to
tell.
> + /* 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);
Heh, so I'm looking at an old version of this patch. The current
pmf_unregister_irq_client makes this explicit and only takes one
parameter :)
> +int snd_pmac_request_irq(snd_pmac_gpio_t *gp, void (*handler)(void *),
> + void *data)
> +{
> + int ret = -ENODEV;
> + struct device_node *np;
> +
> + gp->irq_client.handler = handler;
> + gp->irq_client.data = data;
> + gp->irq_client.owner = NULL;
> +
> + if (gp->pfunc) {
> + gp->irq_client.owner = THIS_MODULE;
> +
> + if ((np = find_devices("i2s-a"))) {
same comment here as the first one -- the powermac needs to be able to
access i2s-c through this too, I think.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: dtc: .quad asm directive generation
From: Mark A. Greer @ 2006-03-15 17:49 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <E1FJJXV-0005Zf-7r@jdl.com>
On Tue, Mar 14, 2006 at 06:06:57PM -0600, Jon Loeliger wrote:
> So, like, the other day "Mark A. Greer" mumbled:
> > >
> > > And finally, as of, well right about now, until October or so, I'm
> > > expecting to be unavailable, off travelling and things. In the
> > > interim Jon Loeliger of Freescale has agreed to be dtc maintainer.
> >
> > Jon, any comments?
>
> For 9 months nothing. Dave abdicates his DTC maintainer role to me.
> The very next day, all hell breaks loose! Of _course_ I have comments!
>
> Uh, I've been bitten by the difference between the binary and asm
> form of these outputs before as well. Specifically where the reserve
> map included its own layout region as a reserve block. IIRC, though,
> it was a physical versus virtual address problem that, though understood,
> we didn't really resolve.
>
> I was eventually forced to move along, as that was not the battle I
> was looking for. Our U-Boot eventually went to a straight binary
> form that was directly munged into a C array definition and side-stepped
> that issue.
>
> As for the 64-bit-ness problem, I'm willing to accept donated 64-bit
> hardware that would allow me to test the problems you are seeing. :-)
>
> I mean, any patches that drift my way will be considered. :-)
Heh!
Okay, right now the kernel/prom.c code is choking on the dt from the asm
file so I'll figure that out and then start poking into the dtc code and
see what I can figure out.
Mark
^ 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