* Problem with 64-bit variables on ppc405
From: Mirek23 @ 2007-11-19 20:37 UTC (permalink / raw)
To: linuxppc-embedded
Dear All,
I have successfully build crosstools (gcc-4.0.2-glibc-2.3.2) for my ppc 405
processor (part of xilinx virtex-4). I have compiled the Linux kernel
2.6.23rc2 and busy box 1.4.2.
All together works fin but I am facing the problem with the variables
declared in C as double and long long.
Doubles and long long are 8 bytes long but the byte order
differs on my host linux Intel PC from this what I have on the target linux
ppc 405.
double , long long byte order looks like below:
linux intel x86 ppc405
1,2,3,4,5,6,7,8 5,6,7,8,1,2,3,4
int and long types in 'C' (4 byte variables) have the same byte order on
both platforms.
It seems to be that 64-bit variables have different order. I do not know if
it comes from:
1. the configuration of the crosstools (ie. the way how the gcc and glibc is
built)
2. the kernel configuration.
The ppc 405 does not have the FPU built in so I have set in the kernel:
processor->math emulation
I did not set anything concerning FPU in Crosstools.
The Crosstools configuration file demo-powerpc-405.sh looks like:
#!/bin/sh
# This script has one line for each known working toolchain
# for this architecture. Uncomment the one you want.
# Generated by generate-demo.pl from buildlogs/all.dats.txt
set -ex
TARBALLS_DIR=$HOME/downloads
RESULT_TOP=/opt/crosstool
export TARBALLS_DIR RESULT_TOP
GCC_LANGUAGES="c,c++"
export GCC_LANGUAGES
# Really, you should do the mkdir before running this,
# and chown /opt/crosstool to yourself so you don't need to run as root.
mkdir -p $RESULT_TOP
eval `cat powerpc-405.dat gcc-4.0.2-glibc-2.3.2.dat` sh all.sh --notest
Does anybody have an idea how to sort out this problem to have byte order
for
64-bit variables on ppc405 the same as for linux on intel x86.
Best Regards
Mirek
--
View this message in context: http://www.nabble.com/Problem-with-64-bit-variables-on-ppc405-tf4839313.html#a13844837
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Fix 8xx build breakage due to _tlbie changes
From: Benjamin Herrenschmidt @ 2007-11-19 19:50 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071119060623.67387f2c@vader.jdub.homelinux.org>
> > Index: linux-work/arch/powerpc/mm/mmu_decl.h
> > ===================================================================
> > --- linux-work.orig/arch/powerpc/mm/mmu_decl.h 2007-11-15 14:09:16.000000000 +1100
> > +++ linux-work/arch/powerpc/mm/mmu_decl.h 2007-11-15 14:14:29.000000000 +1100
> > @@ -56,7 +56,7 @@ extern unsigned long total_lowmem;
> > * architectures. -- Dan
> > */
> > #if defined(CONFIG_8xx)
> > -#define flush_HPTE(X, va, pg) _tlbie(va)
> > +#define flush_HPTE(X, va, pg) _tlbie(va, 0, /* 8xx doesn't care about PID */)
>
> Spurious ','?
Weird, it did build ...
Ben.
^ permalink raw reply
* Re: [RFC/PATCH 1/9] powerpc: Make isa_mem_base common to 32 and 64 bits
From: Benjamin Herrenschmidt @ 2007-11-19 19:49 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev
In-Reply-To: <20071119103254.GA19708@lst.de>
On Mon, 2007-11-19 at 11:32 +0100, Christoph Hellwig wrote:
> On Mon, Nov 19, 2007 at 07:25:00PM +1100, Benjamin Herrenschmidt wrote:
> > +/* ISA Memory physical address (or 0 if none) */
> > +resource_size_t isa_mem_base = 0;
>
> No need to initialize this.
True. I copy/pasted as-is but you are right, I can remove the
initializer.
Ben.
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Grant Likely @ 2007-11-19 19:28 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <9e4733910711191120l45d9257bwf4ccf8c7365393d0@mail.gmail.com>
On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > You might be stuck with using either a platform_device or an
> > of_platform_device as a stepping stone to creating the device on the
> > ALSA fabric driver.
>
> I also concluded that I need a of_platform stepping stone.
>
> There are several ways this could be done, which one is the right one?
> a) fabric is global, create a global device node for it and implement
> it as a of_platform device
This is really board level description stuff. I'd make the node
global off the root myself and use whatever linkage you think
appropriate to get you to the codec nodes (phandle's most likely)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Jon Smirl @ 2007-11-19 19:20 UTC (permalink / raw)
To: Grant Likely; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <fa686aa40711190933r3cbeb51bw7b9073a40f8396ed@mail.gmail.com>
On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > > On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > > > On 11/19/07, Timur Tabi <timur@freescale.com> wrote:
> > > > > > Jon Smirl wrote:
> > > > > >
> > > > > > > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > > > > > > A fabric driver tells specifically how a generic codec is wired into
> > > > > > > the board. What I haven't been able figure out is how to load the
> > > > > > > right fabric driver.
> > > > > >
> > > > > > Do not use the device tree to load the fabric driver!
> > > > >
> > > > > Heh, technically you can't use the device tree to load any device
> > > > > drivers, it's just a data structure. :-)
> > > > >
> > > > > You probably mean "don't use the of_platform bus to load the fabric
> > > > > driver". He still needs to use the data in the device tree to decide
> > > > > what fabric drivers to use. of_platform_bus would be awkward to use
> > > > > for this because the node describing the fabric doesn't cleanly sit on
> > > > > any particular bus (ie. it describes the board; it does not describe
> > > > > the device).
> > > > >
> > > > > In this case; it probably is appropriate to have the platform code
> > > > > instantiate a platform_device for the fabric (instead of an
> > > > > of_platform device) which the fabric driver can bind against.
> > > >
> > > > First, I have platform bus turned off in my builds. Platform bus is a
> > > > place where cruft accumulates that really belongs somewhere else. For
> > > > example when I turned it off I discovered that there was a PC speaker
> > > > driver in my kernel and well as several drivers from 82xx chips.
> > > >
> > > > ALSA creates it own bus like i2c. My fabric driver sits on this bus.,
> > > > Kconfig attributes control if it is built-in. I've altered the i2c
> > > > code to look for child device tree nodes and then load the appropriate
> > > > drivers.
> > >
> > > Can't you then instantiate the ALSA bus device in your board platform
> > > code? Then when the driver is registered, the bus should call it's
> > > probe routine.
> >
> > Yes, I can do that. I have just been resisting creating a code linkage
> > from arch/powerpc/platform/xx to sound/alsa/soc/powerpc. I also need
> > to create the fabric driver after alsa has made the bus,
> > subsys_initcall(asoc_bus_init);
>
> Hmmm, you could add a drivers_initcall to the platform code, but that
> only works if the ALSA code is compiled statically. It doesn't work
> for modules. :-(
>
> You might be stuck with using either a platform_device or an
> of_platform_device as a stepping stone to creating the device on the
> ALSA fabric driver.
I also concluded that I need a of_platform stepping stone.
There are several ways this could be done, which one is the right one?
a) fabric is global, create a global device node for it and implement
it as a of_platform device
b) fabric is per audio bus, make it an attribute or child node under
i2s, ac97, spi. This is messy since it can appear in many places. This
is the apple layout-id scheme.
c) fabric is per codec entry. make it an attribute or child node under
the codec node.
d) after I load the codec node, walk up the device tree to the root
node and then use the compatible string in the root node to trigger
the specific fabric driver. This one avoids making obviously redundant
attributes down lower in the tree.
I need things to initialize in this order. All of these can be modules.
1) alsa subsystem
2) i2c ac97 bus
3) codec driver
4) fabric - it then glues everything together in alsa.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 4/21] ide/Kconfig: fix mpc8xx host driver dependencies
From: Sergei Shtylyov @ 2007-11-19 18:58 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, linuxppc-dev
In-Reply-To: <200711182315.19408.bzolnier@gmail.com>
Bartlomiej Zolnierkiewicz wrote:
> Only LWMON, IVMS8, IVML24 and TQM8xxL platforms have the needed
> defines (IDE0_BASE_OFFSET and friends) in the platform header file.
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
MBR, Sergei
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Grant Likely @ 2007-11-19 18:55 UTC (permalink / raw)
To: Scott Wood; +Cc: PowerPC dev list
In-Reply-To: <20071119170521.GA4368@loki.buserror.net>
On 11/19/07, Scott Wood <scottwood@freescale.com> wrote:
> On Mon, Nov 19, 2007 at 04:31:57PM +0000, Matt Sealey wrote:
> > I never said drivers should depend on it but why do you want to name
> > an i2s bus as "i2s" or the i2c bus as "i2c"?
>
> Because that's what they are?
>
> > There are far, far more descriptive names that can be used. i2s is
> > basically audio, so why not "audio" or "sound" or "headphone"?
>
> For i2s, that may be reasonable, but i2c can have several devices under it.
>
> > Why is gpt a "gpt" and not a "timer", it defeats the whole object
> > of having a name for it. Since drivers never switch on it, why not
> > give them real names?
>
> That one *should* be timer. Ask whoever did the device tree for it. :-P
That one's my fault.
sorry.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* RE: [PATCH] Xilinx TEMAC driver
From: Koss, Mike (Mission Systems) @ 2007-11-19 18:07 UTC (permalink / raw)
To: John Williams, Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <47392A2A.7020200@itee.uq.edu.au>
>> On 7/24/07, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
>>=20
>>> Hopefully this is not too much of a mess.
>> Hooray! Thanks for posting your work. I'm keen to try this on my=20
>> platform. Comments below.
>>=20
> [snip]
> Any progress on the ll_temac driver since July? In EDK9.2, ll_temac
is really the only supported ethernet solution, apart from ethernet lite
(yuck).
> If there's a PPC version in a reasonable state, i'm happy to see
what's requierd to port it across to MicroBlaze.
> cheers,
> John
John,
I have a ll_temac for CDMAC version that I made for >2.6.19 that used
the old wrapper from a MontaVista 2.4 kernel. It was tested (not overly
stressed) and working at speeds > 100Mb. I plan on moving it to a
unified source once I had a LocalLink TEMAC that would support my
hardware. Xilinx did not support ll_temac w/ RGMII or SGMII which are
both found on the ML410 for Gigabit.
I currently use David's driver with much success now for the plb_temac.
I have a modified version that has been mostly cleaned up. I did remove
the ll stuff since it was for a Pico(??) LocalLink TEMAC that I could
not find, and not the Xilinx LocalLink TEMAC w/ CDMAC, which is what I
was interested in. If interested, I could finish the clean-up on it and
post a patch for it (once I figure out how to actually make the patch
:P). Right now what mainly remains is finish grouping the functions for
FIFO and starting support for DMA.
-- Mike
^ permalink raw reply
* Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
From: Torsten Kaiser @ 2007-11-19 18:24 UTC (permalink / raw)
To: Andrew Morton
Cc: Jan Blunck, Peter Zijlstra, steved, LKML, Kamalesh Babulal,
linuxppc-dev, nfs, Ingo Molnar, Trond Myklebust, Balbir Singh
In-Reply-To: <20071119010002.9387d36b.akpm@linux-foundation.org>
On Nov 19, 2007 10:00 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Mon, 19 Nov 2007 08:15:48 +0100 "Torsten Kaiser" <just.for.lkml@googlemail.com> wrote:
> > On Nov 18, 2007 8:18 PM, Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> > > I had already fixed that one in my own stack. Attached are the 3 patches
> > > that I've got. 1 from SteveD, 2 fixes.
> >
> > Moving the init_waitqueue_head() like patch
> > linux-2.6.24-006-fix_to_fix_sillyrename_bug_on_umount.dif and applying
> > linux-2.6.24-007-fix_nfs_free_unlinkdata.dif lets my testcase work.
> > Also lockdep no longer complains about the non-static key.
>
> Thanks.
>
> To avoid goofups, could you please send the full fix against 2.6.24-rc2-mm1?
Umm... As I applied this changes manually there is a not insignificant
change of goofups on my part...
For the hang problem I think Tronds suggestion with replacing the
patches from -mm with fresh versions would be the best.
Anyway, currently I have the patch from
http://lkml.org/lkml/2007/11/16/74 to fix the can't-create-files-bug.
To fix the hang bug I used Tronds
linux-2.6.24-007-fix_nfs_free_unlinkdata.dif and the first two hunks
from linux-2.6.24-006-fix_to_fix_sillyrename_bug_on_umount.dif.
Torsten
The needed 2 hunks for reference:
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -594,9 +594,6 @@ static int nfs_init_server(struct nfs_server *server,
/* Create a client RPC handle for the NFSv3 ACL management interface */
nfs_init_server_aclclient(server);
- init_waitqueue_head(&server->active_wq);
- atomic_set(&server->active, 0);
-
dprintk("<-- nfs_init_server() = 0 [new %p]\n", clp);
return 0;
@@ -736,6 +733,9 @@ static struct nfs_server *nfs_alloc_server(void)
INIT_LIST_HEAD(&server->client_link);
INIT_LIST_HEAD(&server->master_link);
+ init_waitqueue_head(&server->active_wq);
+ atomic_set(&server->active, 0);
+
server->io_stats = nfs_alloc_iostats();
if (!server->io_stats) {
kfree(server);
^ permalink raw reply
* Re: hangs after "Freeing unused kernel memory"
From: Linas Vepstas @ 2007-11-19 17:51 UTC (permalink / raw)
To: Siva Prasad; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <D83235F0F3C86D4D889D8B9A0DA8C6D7F73FC8@corpexc01.corp.networkrobots.com>
On Thu, Nov 15, 2007 at 04:00:09PM -0800, Siva Prasad wrote:
> Hi,
>
> This sounds like a familiar problem, but could not get answers in posts
> that came up in google search.
>
> My system hangs after printing the message "Freeing unused kernel
> memory". It should execute init after that, but not sure what exactly is
> happening. Appreciate if some one can throw few ideas to try out.
It might not be a hang, it might be simply that you loose the console.
If this is a redhat system, and you didn't tweak initrd and udev just
right, this can happen.
Try doing this:
mount --bind / /mnt
cp -a /dev/null /mnt/dev
cp -a /dev/console /mnt/dev
cp -a /dev/hv* /mnt/dev
umount /mnt
> Seems it is actually hanging when it makes the call "
> run_init_process(ramdisk_execute_command)" in init/main.c
Then again, your initrd might be corrupted.
--linas
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Grant Likely @ 2007-11-19 17:33 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <9e4733910711190851g3e1f2ef9k5f87c7c2dae929ef@mail.gmail.com>
On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > > On 11/19/07, Timur Tabi <timur@freescale.com> wrote:
> > > > > Jon Smirl wrote:
> > > > >
> > > > > > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > > > > > A fabric driver tells specifically how a generic codec is wired into
> > > > > > the board. What I haven't been able figure out is how to load the
> > > > > > right fabric driver.
> > > > >
> > > > > Do not use the device tree to load the fabric driver!
> > > >
> > > > Heh, technically you can't use the device tree to load any device
> > > > drivers, it's just a data structure. :-)
> > > >
> > > > You probably mean "don't use the of_platform bus to load the fabric
> > > > driver". He still needs to use the data in the device tree to decide
> > > > what fabric drivers to use. of_platform_bus would be awkward to use
> > > > for this because the node describing the fabric doesn't cleanly sit on
> > > > any particular bus (ie. it describes the board; it does not describe
> > > > the device).
> > > >
> > > > In this case; it probably is appropriate to have the platform code
> > > > instantiate a platform_device for the fabric (instead of an
> > > > of_platform device) which the fabric driver can bind against.
> > >
> > > First, I have platform bus turned off in my builds. Platform bus is a
> > > place where cruft accumulates that really belongs somewhere else. For
> > > example when I turned it off I discovered that there was a PC speaker
> > > driver in my kernel and well as several drivers from 82xx chips.
> > >
> > > ALSA creates it own bus like i2c. My fabric driver sits on this bus.,
> > > Kconfig attributes control if it is built-in. I've altered the i2c
> > > code to look for child device tree nodes and then load the appropriate
> > > drivers.
> >
> > Can't you then instantiate the ALSA bus device in your board platform
> > code? Then when the driver is registered, the bus should call it's
> > probe routine.
>
> Yes, I can do that. I have just been resisting creating a code linkage
> from arch/powerpc/platform/xx to sound/alsa/soc/powerpc. I also need
> to create the fabric driver after alsa has made the bus,
> subsys_initcall(asoc_bus_init);
Hmmm, you could add a drivers_initcall to the platform code, but that
only works if the ALSA code is compiled statically. It doesn't work
for modules. :-(
You might be stuck with using either a platform_device or an
of_platform_device as a stepping stone to creating the device on the
ALSA fabric driver.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Scott Wood @ 2007-11-19 17:05 UTC (permalink / raw)
To: Matt Sealey; +Cc: PowerPC dev list
In-Reply-To: <4741BA7D.10608@genesi-usa.com>
On Mon, Nov 19, 2007 at 04:31:57PM +0000, Matt Sealey wrote:
> I never said drivers should depend on it but why do you want to name
> an i2s bus as "i2s" or the i2c bus as "i2c"?
Because that's what they are?
> There are far, far more descriptive names that can be used. i2s is
> basically audio, so why not "audio" or "sound" or "headphone"?
For i2s, that may be reasonable, but i2c can have several devices under it.
> Why is gpt a "gpt" and not a "timer", it defeats the whole object
> of having a name for it. Since drivers never switch on it, why not
> give them real names?
That one *should* be timer. Ask whoever did the device tree for it. :-P
> > device_type - indicates the open firmware method interface for the
> > device. Therefore, meaningless in flattened trees. No new driver
> > should use this.
>
> .. you seem to think you must only design for the guys making Linux
> flattened device trees. I'm sorry, but I am not one of those guys and
> I am much more concerned with how this will affect the OF device tree
> and the usage for anyone else.
>
> Meaningless in flattened device trees, but useful information in real
> OF device trees, do you implement it or not? I'd say, yes.
Yes, if you have real OF and provide the corresponding method interface.
That doesn't mean the driver should match on it if it doesn't depend on the
method interface.
> > compatible - *this* is the one for driver selection. It describes the
> > hardware level interface(s) of the device.
>
> Compatible is meant to list alternative, compatible devices as a
> *supplement* to device_type. device_type is your "primary" and
> compatible is your "secondary".
No, please read the spec:
“compatible”
Standard property name to define alternate “name” property values.
No mention of device_type anywhere in the definition.
The generic names recommendation further suggests that compatible always be
used for matching.
> I don't see why "model" can't encode the particular revision of the
> hardware in this way when it comes to the audio group of features on
> his board. After all, if you are looking at a "digispeaker,flinger"
> (I made that name up) then you need to know depending on the board
> or even based on weird configurability options of the board, what
> certain things may be - Apple used layout-id and a number. Why NOT
> encode the "model" in the "model"?
>
> Why choose some magical, new property, which then has to be further
> standardised for no reason?
"compatible" is not a magical, new property. I'm not going to defend what
Apple did...
> I also think that specifying an audio codec - after all the Open
> Firmware standard defines an audio interface and device tree
> requirements for it, even if they are methods that we don't
> implement and you don't care about - as a function of it's
> control interface is so backwards it doesn't bare thinking about.
It's how the device tree works. Devices go underneath the bus (or other
attachment interface) that they're on. If you have an audio codec that has
an i2c interface and an soc interface, then you have two nodes, because
you're on two buses.
> If you want to output audio you do it through most audio
> controllers as a simple transfer of PCM data. Be it Creative
> or Freescale I2S or AC97, you push data at some port/fifo
> and it plays a sound. It is NOT defined by i2c control ports,
> you don't ever use those to *play* audio.
You certainly do use the i2c ports in order to do anything with the device
underneath the i2c bus.
> It may also be very, very true that a codec DOES NOT REQUIRE
> implementation of it's control interface, or that control interface could
> be connected to some other chip which handles initial configuration (like
> a boot sequencer eeprom) and not to a system bus.
Sure... in that case, then that's *not the bus it's on*. There's still some
register set somewhere that software uses to shove data at the codec; that's
where the node should go.
-Scott
^ permalink raw reply
* Re: Oops: of_platform_serial_probe
From: Arnd Bergmann @ 2007-11-19 16:56 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <474193B8.9060007@anagramm.de>
On Monday 19 November 2007, Clemens Koller wrote:
> Unable to handle kernel paging request for data at address 0x00000000
> Faulting instruction address: 0xc018f03c
> Oops: Kernel access of bad area, sig: 11 [#1]
> MPC85xx ADS
> Modules linked in:
> NIP: c018f03c LR: c018f00c CTR: c00127b4
> REGS: c0821cf0 TRAP: 0300 =A0 Not tainted =A0(2.6.24-rc2-ge6a5c27f)
> MSR: 00029000 <EE,ME> =A0CR: 42022088 =A0XER: 20000000
> DEAR: 00000000, ESR: 00000000
> TASK =3D c081e000[1] 'swapper' THREAD: c0820000
> GPR00: b1000000 c0821da0 c081e000 c0833e10 00000004 c0821d80 c03d3064 c05=
eea80
> GPR08: 00000200 00000002 0000002a 13ab6680 82022042 00000000 c03318a4 c03=
3188c
> GPR16: c0331908 c03318f0 c03a0e30 c0331930 c033191c 007fff00 0ffeccbc c03=
a0000
> GPR24: c0821dc4 00000000 00000003 c0934cf8 cffffba8 00000000 c0833e00 c07=
fdc6c
> NIP [c018f03c] of_platform_serial_probe+0x118/0x1e4
> LR [c018f00c] of_platform_serial_probe+0xe8/0x1e4
> Call Trace:
Ok, that is a NULL pointer access, probably somewhere in the
of_platform_serial_setup that can be inlined. Please post the
device tree entries for your serial ports so we can see what
goes wrong there.
One potential problem that I can see is a missing 'current-speed'
property in your tree, which would cause this behavior. It looks
like many device trees set this, but it is not required by all
bindings. If that's the case, the patch below should fix your
problem, but you probably want to set the current-speed anyway,
according to your boot loader settings.
Arnd <><
=2D-- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -56,7 +56,8 @@ static int __devinit of_platform_serial_setup(struct of_d=
evice *ofdev,
port->flags =3D UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
| UPF_FIXED_PORT;
port->dev =3D &ofdev->dev;
=2D port->custom_divisor =3D *clk / (16 * (*spd));
+ if (spd)
+ port->custom_divisor =3D *clk / (16 * (*spd));
return 0;
}
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Matt Sealey @ 2007-11-19 16:58 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: PowerPC dev list
In-Reply-To: <621f1d7bb87a49559d22162314b98398@kernel.crashing.org>
Segher Boessenkool wrote:
>> And I forgot the rant you guys usually get - for god's sake, why isn't
>> anyone using the "model" property?
>
> Probably because it isn't useful all that often.
>
>> sound@0 {
>> \\ this is our magic audio fabric
>> device_type = "digispeaker,flinger";
>
> This is wrong in so many ways; see David's mail for a start.
Why? I'm sorry but I am living in the real world where we have real
firmwares and real dynamic device trees here. You can't just say
"this is wrong because it has a device_type".
>> \\ and this defines the layout Jon picked for the DACs
>> \\ just like Apple's layout-id value
>> model = "flinger,2"
>
> "flinger" is some company that sells something they call the "2"?
> Interesting.
No, but who cares of the format of the model? It's for information -
in this case it's just there so that Jon can find out what "layout"
his codec, control interface, GPIOs, ports on the board, mixer
names, what colour the sky was on that day in June when he met his
wife-to-be, the name of his first dog, whatever information he needs
to implement on ANY driver model on ANY operating system is on that
particular version.
Maybe it should be digispeaker,2 or digispeaker,666 - who cares?
It's for the driver to know what it means.
I suggest it because I think Apple's "layout-id" is cryptic and
ridiculous duplication. Jon suggested to me a couple days back
that the layout-id is so model-specific (it increments each time
they brought out a new board, so it is synchronised with the
root "model" property!) that it's redundant. He suggested using
the root "model" property to switch his driver on the layout.
In this scenario, why not use the "model" property to keep the
audio driver more self-contained here? That was the theory
behind it.
> "model" should be the real-world exact model name/number of the device.
Well, on this example, it's quite obvious it's an MPC5200B I2S bus,
but you're not describing solely the i2s bus (although in the
example it will operate with a standard mpc5200b-psc-i2s driver)
but the entire audio solution and indirectly how to program that
audio solution (ta-da!) - i2s bus, pcm codec, it's control interface,
and anything else besides, which is...
>> Isn't the primary concern of an audio codec, to play audio?
>
> And the primary purpose of the device tree is to describe the hardware,
> and (indirectly) how to program it.
.. exactly what it does.
> For an audio codec that has I2C and I2S connections, the interface
> over which you program it is I2C.
What if you don't connect I2C to something Linux can access directly?
> There are other technicalities, too; for example, if the codec node
> would be a child node of the I2S bus, you cannot have two codecs with
> the same name on one such bus (since that bus isn't a "bus" really,
> it's more like a broadcast interface; it cannot address separate devices
> on that "bus", so in the device tree the codecs wouldn't get a "reg",
> etc.)
*shrug* as an example..
>> Therefore, shouldn't the audio codec point back to it's control
>> interface?
>
> No. The codec node _is_ the "control interface".
I think that flies in the face of the implementation of a bunch of
codecs.
>> Also, why give the name as 'i2s-handle'?
>
> Why not?
>
>> Surely it could be any interface.
>
> No it cannot; this property is only present for audio codecs that have
> an I2S bus (and not even all those, it is dependent on the device binding
> in use).
See below.
>> In reverse, it would be, perhaps, as
>> above, i2c-handle, but then what if you change the interface
>> type (for instance a bunch of Wolfson codecs can do i2c and
>> spi for control). Your property name is obselete, then and
>> drivers will need to switch on property names to find out
>> which control interface is present.
>
> That's another great argument against doing as you suggest, yes.
Why? The i2s codec sits on the i2s bus. You're right there is no
addressing on i2s it just has a stream of auduo going through it.
The i2s bus is one thing. This defines a PCM transport. This is
standardised.
The codec node defines which PCM/DAC you have on the end. This
DAC may have certain features - it may only have certain sample
rates supported, or may only support certain clock speeds. This
is what the codec node under the bus is for.
The codec node references the package handle of it's control
interface. If you want to play audio - well, go ahead, stream
some audio to the i2s bus, based on the abilities of the codec
(which are well defined in the datasheet you'd hope). You may
even use the OF standard properties for a "sound" node to define
these too - after all, it has a binding already and it would
improve driver support.
If you want to fiddle with it you need control interface, but
the primary purpose of an *audio device* is to play audio.
It is not to switch mixers on and off and change bass boost, that
is a totally secondary feature of an audio output or input
device, which may not even be present.
>> What they should really do, is be told where their control
>> interface handle is, then you can look at that handle and
>> the device it contains
>
> What you *should* do is just look at the parent node if you want to
> know how to talk to the device. This is the same for *all* nodes in
> *all* device trees.
Sorry Segher but you argued against this last time we had this
discussion. You said that all device nodes should be self-contained
and looking elsewhere in the tree is ridiculous.
What if you have a chip which has an SPI control interface, and
uses a custom FIFO setup to stream audio? What do you use then,
i2s-handle? Ha ha ha. Don't encode bus names in properties. They
should be descriptive. i2s-handle would point to a node which
has a device_type (on real firmware) and compatible property which
gives you ALL the information you need to determine
>> Remember, it doesn't matter what NAME you give it, the name
>> is for people to read,
>
> Not only. When the generic naming recommended practice is in use, "name"
> can be used to find all nodes of a certain type. Neither "name" nor
> "device_type" should be used for device driver matching though;
Then, no real Open Firmware implementation can work. What you need to
do, then is repeat the device_type information in the compatible
property on real firmwares. This is dumb. Stop sidelining real firmwares
for the sake of the Linux device tree.
> "compatible" is for that.
Why don't we propose a solution then? device_type is the type of
device you're looking at. This might be chrp,iic or it might be
fsl,i2c or it could be something else. Write this into your device
tree spec. This is important for real firmwares and other operating
systems which try and conform to IEEE 1275.
Then get your fdt blob builder and fix it so that it concatenates
the device_type value into the compatible property, and ditches
the device_type value for FDT's.
Don't start killing off part of the Open Firmware spec for the sake
of it. If you expect real Open Firmware developers to actually pay
attention to the Linux device tree specs it needs to take them into
account and not just run off on the justification that it was
"decided by the community so it's canon" - you need to design the
trees based on users of the technology.
> [As a historic note, before the "generic naming" thing, "name" was used
> for exactly what the first entry in "compatible" is used for now. But
> let's try to forget that, okay?]
>
>> device_type is what you search for,
>
> Unless you are programming in "real" Open Firmware itself, you do _not_
> search for "device_type". Ever.
Hello, we license one, so we're concerned about this.
Last time we shipped a real Open Firmware itself, you were the biggest
opponent on getting the device tree checked and standardised. Now you
want to just remove features, I don't see how we should even care if
you're going to be like that, but you're forcing us to do your bidding
against better knowledge.
When you have your own firmware to play with you can do what you like
with it, you can remove the property.. and Linux can happily support
it, but we *really* need to support other systems here and defining
things in backwards Linux ways is bad.
>> and model is to give you the enviable ability
>> to define PRECISELY what you are looking at beyond a chip
>> name.
>
> When a device driver uses "model" for anything, it is typically because
> "compatible" says the device is a member of some family of devices that
> all behave identically, but uh-oh, this isn't actually true.
>
> It's also not all that great for human readers, since the format is
> vendor-specific.
It's hard to define a value which describes something human readable
yet being simple to parse by a machine. Remember the whole justification
for XML? I don't think "model" (or by that regard, name, device_type
or compatible) *MUST* be human readable, but where and if it can be,
it should be.
name = some pretty name to differentiate it from something else in
the device tree. Not searchable, but just pretty in the output of
'.properties'
device_type = primary driver switch to look for the device, since it's
part of the OF spec, we have to implement it on our firmware. you
needn't in FDTs, but, please help us out on this.
compatible = if you don't find it in device_type, look here. I don't
think it should need to repeat device_type on real OF implementations.
model = you found the driver but you're concerned about some very
exact functionality which may not be present or software-detectable,
so you encode it here. Be that the SVR, be that the full part number
lasered into the die of the chip, be it mpc5200b,1.4 - this is up
to the guy who designed the hardware and the driver SHOULD be able
to use it AT IT'S OPTION to handle certain quirks, layout issues or
bugs in the device.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Jon Smirl @ 2007-11-19 16:55 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <4741BD5D.2090502@freescale.com>
On 11/19/07, Timur Tabi <timur@freescale.com> wrote:
> Grant Likely wrote:
>
> > You probably mean "don't use the of_platform bus to load the fabric
> > driver".
>
> Yes, that is what I meant.
>
> > He still needs to use the data in the device tree to decide
> > what fabric drivers to use.
>
> I'm not sure about that. The fabric driver is tied to the platform itself,
> mostly because the fabric driver isn't really a device driver. It's a
> platform driver, in that its job is to initialize the other device drivers, or
> make sure the kernel initializes them. It's also responsible for telling ALSA
> which driver does what and how they're connected.
>
> With the current version of ASoC (V1), I don't think it's possible to have an
> independent platform driver. V2 is in development, but it's not ready yet and
> I haven't had a chance to study it. V2 is intended to address the problems
> that a device tree model raises.
I'm using the v2 code. The v2 code is modeled after the i2c bus code
which is the correct way to do drivers for open firmware.
v1 creates asoc core as a platform device which was completely wrong
since it is a driver core, not a device. That is fixed in v2 where it
initializes with a subsysinit() call and then creates a bus. The whole
driver organization of v2 is superior to v1. Open firmware support was
the main motivation behind v2.
>
> > In this case; it probably is appropriate to have the platform code
> > instantiate a platform_device for the fabric (instead of an
> > of_platform device) which the fabric driver can bind against.
> >
> > Another option is to explicitly call of_platform_device_create in the
> > platform code on the fabric node (which should be a child of the root
> > node) so that you can have an of_platform_bus fabric driver.
>
> I don't fully understand platform drivers. Do we really need a full-blown OF
> platform driver for this?
>
> --
> Timur Tabi
> Linux Kernel Developer @ Freescale
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Grant Likely @ 2007-11-19 16:53 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <4741BD5D.2090502@freescale.com>
On 11/19/07, Timur Tabi <timur@freescale.com> wrote:
> Grant Likely wrote:
>
> > You probably mean "don't use the of_platform bus to load the fabric
> > driver".
>
> Yes, that is what I meant.
>
> > He still needs to use the data in the device tree to decide
> > what fabric drivers to use.
>
> I'm not sure about that. The fabric driver is tied to the platform itself,
> mostly because the fabric driver isn't really a device driver. It's a
> platform driver, in that its job is to initialize the other device drivers, or
> make sure the kernel initializes them. It's also responsible for telling ALSA
> which driver does what and how they're connected.
>
Even it it's just based on the board "model" property; that's still
deciding what the ALSA fabric is based on data in the device tree.
:-)
> > Another option is to explicitly call of_platform_device_create in the
> > platform code on the fabric node (which should be a child of the root
> > node) so that you can have an of_platform_bus fabric driver.
>
> I don't fully understand platform drivers. Do we really need a full-blown OF
> platform driver for this?
Both the platform bus and the of_platform bus do exactly the same
thing in a simple manner. They allow devices to be matched with
drivers. It is a low overhead mechanism.
In both cases, devices carry with them some metadata to describe the
devices. For platform devices, that meta data is a resource structure
and a device specific pdata structure. For of_platform devices, the
metadata is a pointer to a device tree node.
That's it. Using either mechanism allows the platform code to say
"these devices are present" without having to explicitly call routines
into the driver. In other words; it can provide late binding of
drivers to devices.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Jon Smirl @ 2007-11-19 16:51 UTC (permalink / raw)
To: Grant Likely; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <fa686aa40711190831s2e59ab05h63d10ec8a24eaad5@mail.gmail.com>
On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > On 11/19/07, Timur Tabi <timur@freescale.com> wrote:
> > > > Jon Smirl wrote:
> > > >
> > > > > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > > > > A fabric driver tells specifically how a generic codec is wired into
> > > > > the board. What I haven't been able figure out is how to load the
> > > > > right fabric driver.
> > > >
> > > > Do not use the device tree to load the fabric driver!
> > >
> > > Heh, technically you can't use the device tree to load any device
> > > drivers, it's just a data structure. :-)
> > >
> > > You probably mean "don't use the of_platform bus to load the fabric
> > > driver". He still needs to use the data in the device tree to decide
> > > what fabric drivers to use. of_platform_bus would be awkward to use
> > > for this because the node describing the fabric doesn't cleanly sit on
> > > any particular bus (ie. it describes the board; it does not describe
> > > the device).
> > >
> > > In this case; it probably is appropriate to have the platform code
> > > instantiate a platform_device for the fabric (instead of an
> > > of_platform device) which the fabric driver can bind against.
> >
> > First, I have platform bus turned off in my builds. Platform bus is a
> > place where cruft accumulates that really belongs somewhere else. For
> > example when I turned it off I discovered that there was a PC speaker
> > driver in my kernel and well as several drivers from 82xx chips.
> >
> > ALSA creates it own bus like i2c. My fabric driver sits on this bus.,
> > Kconfig attributes control if it is built-in. I've altered the i2c
> > code to look for child device tree nodes and then load the appropriate
> > drivers.
>
> Can't you then instantiate the ALSA bus device in your board platform
> code? Then when the driver is registered, the bus should call it's
> probe routine.
Yes, I can do that. I have just been resisting creating a code linkage
from arch/powerpc/platform/xx to sound/alsa/soc/powerpc. I also need
to create the fabric driver after alsa has made the bus,
subsys_initcall(asoc_bus_init);
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Timur Tabi @ 2007-11-19 16:45 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910711190800t5dc9bc40q1b58feae4ff364d0@mail.gmail.com>
Jon Smirl wrote:
> Now how do I pick which fabric driver to initialize?
I'm doing it via a Kconfig option. For ASoC V1, I think that's the only way
that works.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Timur Tabi @ 2007-11-19 16:44 UTC (permalink / raw)
To: Grant Likely; +Cc: PowerPC dev list
In-Reply-To: <fa686aa40711190733vd1ffac0k62bf32186eb57aff@mail.gmail.com>
Grant Likely wrote:
> You probably mean "don't use the of_platform bus to load the fabric
> driver".
Yes, that is what I meant.
> He still needs to use the data in the device tree to decide
> what fabric drivers to use.
I'm not sure about that. The fabric driver is tied to the platform itself,
mostly because the fabric driver isn't really a device driver. It's a
platform driver, in that its job is to initialize the other device drivers, or
make sure the kernel initializes them. It's also responsible for telling ALSA
which driver does what and how they're connected.
With the current version of ASoC (V1), I don't think it's possible to have an
independent platform driver. V2 is in development, but it's not ready yet and
I haven't had a chance to study it. V2 is intended to address the problems
that a device tree model raises.
> In this case; it probably is appropriate to have the platform code
> instantiate a platform_device for the fabric (instead of an
> of_platform device) which the fabric driver can bind against.
>
> Another option is to explicitly call of_platform_device_create in the
> platform code on the fabric node (which should be a child of the root
> node) so that you can have an of_platform_bus fabric driver.
I don't fully understand platform drivers. Do we really need a full-blown OF
platform driver for this?
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: Oops: of_platform_serial_probe
From: Timur Tabi @ 2007-11-19 16:34 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <4741B934.90400@anagramm.de>
Clemens Koller wrote:
> Timur Tabi schrieb:
> > Clemens Koller wrote:
> >
> >> I guess I didn't configure the OF serial right in the .dts but it still
> >> shouldn't crash. My .config is attached.
> >
> > Try disabling CONFIG_SERIAL_OF_PLATFORM. I don't think it means what
> > you think it means.
>
> Thanks, disabling CONFIG_SERIAL_OF_PLATFORM helps. but it still
> shouldn't crash...
That's a bug in the OF serial driver. It's expecting fields in the serial
node that don't exist. You are right, however. The driver should at least
check for NULL pointers. If I had any hardware that used that driver, I would
fix it myself.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Matt Sealey @ 2007-11-19 16:31 UTC (permalink / raw)
To: Matt Sealey, Jon Smirl, PowerPC dev list
In-Reply-To: <20071119001209.GD20794@localhost.localdomain>
David Gibson wrote:
> On Sun, Nov 18, 2007 at 11:31:13PM +0000, Matt Sealey wrote:
>
> Gah! For the benefit of others on this list who may be misled.
>
> *Neither* of you correctly understands the device tree, what I've seen
> of *both* your suggested approaches is crap.
>
> The device tree describes the _hardware_. If you start reasoning
> about how to lay out the device tree based on your driver model,
> you're already wrong.
>
> Matt, the various properties you list do not mean what you think they
> mean.
No, David, I understand exactly what they mean, in the context of
a guy who works on Open Firmware, real Open Firmware, as was standardised
12 years ago.
Not your whacky newspeak device trees, which to be fair, are a good
idea, but it seems you all have tried to change something for the
sake of changing something.
> name - should be named according to the generic names convention.
> It's pretty much arbitrary, meant for human readability of the device
> tree. Drivers should not depend on it (some do, historically, but new
> drivers and trees should not).
I never said drivers should depend on it but why do you want to name
an i2s bus as "i2s" or the i2c bus as "i2c"? There are far, far more
descriptive names that can be used. i2s is basically audio, so why
not "audio" or "sound" or "headphone"?
Why is gpt a "gpt" and not a "timer", it defeats the whole object
of having a name for it. Since drivers never switch on it, why not
give them real names?
> device_type - indicates the open firmware method interface for the
> device. Therefore, meaningless in flattened trees. No new driver
> should use this.
.. you seem to think you must only design for the guys making Linux
flattened device trees. I'm sorry, but I am not one of those guys and
I am much more concerned with how this will affect the OF device tree
and the usage for anyone else.
Meaningless in flattened device trees, but useful information in real
OF device trees, do you implement it or not? I'd say, yes. Even if
you don't agree with "real firmware", you can't just ignore it, shrug
it away and say it doesn't matter.
Jon's fabric driver should be looking for "digispeaker,flinger"
and nothing else. The name doesn't matter but I called it "sound"
because it's far, FAR more descriptive than "i2s", and of course
both the device_type and compatible properties report exactly what
Jon will need to write a driver which handles, however that might
be, his audio codec subsystem - pcm, control, magic gpios, or
whatever.
If there is an Open Firmware standard for it, I would use that name,
then it gives everyone a rough idea of what to expect. Open Firmware
developers can then CHOOSE TO IMPLEMENT THE STANDARD METHODS, and
Linux device tree authors can just ignore it.
You are cutting out a working specification for the sake of some
arbitrary simplification.
> compatible - *this* is the one for driver selection. It describes the
> hardware level interface(s) of the device.
Compatible is meant to list alternative, compatible devices as a
*supplement* to device_type. device_type is your "primary" and
compatible is your "secondary". In this case, device_type is
exactly what Jon wants, something to mark out that the audio device
is his board design and requires special work (it is not merely an
i2s bus that you can just "use" - although throwing PCM data at it
would work, who knows what mixer it goes to, and what controls are
needed to define the bitrate or other features)
> model - usually just for debugging / diagnosis / human-readable
> purposes, describes exact model / revision of the hardware. It can be
> used to enable driver quirks / workarounds for when various devices
> are supposed to be compatible (as encoded in 'compatible') but
> aren't, due to hardware bugs. However, you should never aim to use it
> this way in design.
I don't see why "model" can't encode the particular revision of the
hardware in this way when it comes to the audio group of features on
his board. After all, if you are looking at a "digispeaker,flinger"
(I made that name up) then you need to know depending on the board
or even based on weird configurability options of the board, what
certain things may be - Apple used layout-id and a number. Why NOT
encode the "model" in the "model"?
Why choose some magical, new property, which then has to be further
standardised for no reason?
I also think that specifying an audio codec - after all the Open
Firmware standard defines an audio interface and device tree
requirements for it, even if they are methods that we don't
implement and you don't care about - as a function of it's
control interface is so backwards it doesn't bare thinking about.
If you want to output audio you do it through most audio
controllers as a simple transfer of PCM data. Be it Creative
or Freescale I2S or AC97, you push data at some port/fifo
and it plays a sound. It is NOT defined by i2c control ports,
you don't ever use those to *play* audio. It may also be very,
very true that a codec DOES NOT REQUIRE implementation of it's
control interface, or that control interface could be connected
to some other chip which handles initial configuration (like
a boot sequencer eeprom) and not to a system bus.
Therefore, pcm audio codecs as subordinate of control interfaces
is a dumb idea. Nuff said, I think.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Grant Likely @ 2007-11-19 16:31 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <9e4733910711190800t5dc9bc40q1b58feae4ff364d0@mail.gmail.com>
On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On 11/19/07, Timur Tabi <timur@freescale.com> wrote:
> > > Jon Smirl wrote:
> > >
> > > > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > > > A fabric driver tells specifically how a generic codec is wired into
> > > > the board. What I haven't been able figure out is how to load the
> > > > right fabric driver.
> > >
> > > Do not use the device tree to load the fabric driver!
> >
> > Heh, technically you can't use the device tree to load any device
> > drivers, it's just a data structure. :-)
> >
> > You probably mean "don't use the of_platform bus to load the fabric
> > driver". He still needs to use the data in the device tree to decide
> > what fabric drivers to use. of_platform_bus would be awkward to use
> > for this because the node describing the fabric doesn't cleanly sit on
> > any particular bus (ie. it describes the board; it does not describe
> > the device).
> >
> > In this case; it probably is appropriate to have the platform code
> > instantiate a platform_device for the fabric (instead of an
> > of_platform device) which the fabric driver can bind against.
>
> First, I have platform bus turned off in my builds. Platform bus is a
> place where cruft accumulates that really belongs somewhere else. For
> example when I turned it off I discovered that there was a PC speaker
> driver in my kernel and well as several drivers from 82xx chips.
>
> ALSA creates it own bus like i2c. My fabric driver sits on this bus.,
> Kconfig attributes control if it is built-in. I've altered the i2c
> code to look for child device tree nodes and then load the appropriate
> drivers.
Can't you then instantiate the ALSA bus device in your board platform
code? Then when the driver is registered, the bus should call it's
probe routine.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Oops: of_platform_serial_probe
From: Clemens Koller @ 2007-11-19 16:26 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-embedded
In-Reply-To: <4741A617.1060207@freescale.com>
Timur Tabi schrieb:
> Clemens Koller wrote:
>
>> I guess I didn't configure the OF serial right in the .dts but it still
>> shouldn't crash. My .config is attached.
>
> Try disabling CONFIG_SERIAL_OF_PLATFORM. I don't think it means what
> you think it means.
Thanks, disabling CONFIG_SERIAL_OF_PLATFORM helps. but it still shouldn't crash...
Regards,
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: how to improve linux tcp/ip(UDP) efficiency on mpc8541 833Mhz.
From: Detlev Zundel @ 2007-11-19 15:10 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <47407CCB.80503@chello.nl>
Hi,
> We use a 8250 and 8270 of which the performance is highly limited by the
> bandwidth of the memory to the very small internal cache.
> I once modified a driver into a "polling" method polling the device
> every millisecond. The amount of messages processed trippled this way!
> On full speed the console could even be used for "normal" operation (in
> contrairy to the interrupt driver driver).
> The penalties are obvious: When the bandwith used is low the delay for
> polled messages is higher and the CPU overhead is higher.
Just look at the NAPI[1] (New-NAPI in the latest incarnation) linux
layer for network drivers. The upshot of this is that where "old"
drivers pull data from the network card onto the kernel network
backlog on interrupt time, NAPI drivers only set an internal flag so
they want to get polled by the kernel when it is ready and basically
disable further interrupts. They are enabled again by the time the
driver was able to post all packets up to the network stack.
This effectively gives low latencies on low network load because it
more or less stays being interrupt driven but it turns into polling
mode on high network loads and thus prevents interrupt live lock
situations.
Adapting the network driver in question to NNAPI should improve the
performance of the whole system quite a bit.
Best wishes
Detlev
[1] http://www.linux-foundation.org/en/Net:NAPI
--
Indeed, the author firmly believes that the best serious work is also
good fun. We needn't apologize if we enjoy doing research.
-- Donald Knuth
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Jon Smirl @ 2007-11-19 16:00 UTC (permalink / raw)
To: Grant Likely; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <fa686aa40711190733vd1ffac0k62bf32186eb57aff@mail.gmail.com>
On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 11/19/07, Timur Tabi <timur@freescale.com> wrote:
> > Jon Smirl wrote:
> >
> > > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > > A fabric driver tells specifically how a generic codec is wired into
> > > the board. What I haven't been able figure out is how to load the
> > > right fabric driver.
> >
> > Do not use the device tree to load the fabric driver!
>
> Heh, technically you can't use the device tree to load any device
> drivers, it's just a data structure. :-)
>
> You probably mean "don't use the of_platform bus to load the fabric
> driver". He still needs to use the data in the device tree to decide
> what fabric drivers to use. of_platform_bus would be awkward to use
> for this because the node describing the fabric doesn't cleanly sit on
> any particular bus (ie. it describes the board; it does not describe
> the device).
>
> In this case; it probably is appropriate to have the platform code
> instantiate a platform_device for the fabric (instead of an
> of_platform device) which the fabric driver can bind against.
First, I have platform bus turned off in my builds. Platform bus is a
place where cruft accumulates that really belongs somewhere else. For
example when I turned it off I discovered that there was a PC speaker
driver in my kernel and well as several drivers from 82xx chips.
ALSA creates it own bus like i2c. My fabric driver sits on this bus.,
Kconfig attributes control if it is built-in. I've altered the i2c
code to look for child device tree nodes and then load the appropriate
drivers.
static void of_register_i2c_devices(struct i2c_adapter *adap, struct
device_node *adap_node)
{
struct device_node *node = NULL;
while ((node = of_get_next_child(adap_node, node))) {
struct i2c_board_info info;
const u32 *addr;
const char *compatible;
int len;
addr = of_get_property(node, "reg", &len);
if (!addr || len < sizeof(int) || *addr > (1 << 10) - 1) {
printk(KERN_WARNING "i2c-mpc.c: invalid entry, missing reg attribute\n");
continue;
}
info.irq = irq_of_parse_and_map(node, 0);
if (info.irq == NO_IRQ)
info.irq = -1;
compatible = of_get_property(node, "compatible", &len);
if (!compatible) {
printk(KERN_WARNING "i2c-mpc.c: invalid entry, missing compatible
attribute\n");
continue;
}
strncpy(info.driver_name, compatible, sizeof(info.driver_name));
info.type[0] = '\0';
info.platform_data = NULL;
info.addr = *addr;
i2c_new_device(adap, &info);
}
}
I have a similar loop in the ac97 driver for loading codecs it controls.
So now I'm at this point:
i2c bus driver loaded, initialized from of
i2s bus driver loaded, initialized from of
tas5504 codec loaded onto i2c, initialized from i2c loop above
multiple fabric drivers loaded onto the alsa bus
Now how do I pick which fabric driver to initialize?
Codec and i2s are also attached to alsa bus.
>
> Another option is to explicitly call of_platform_device_create in the
> platform code on the fabric node (which should be a child of the root
> node) so that you can have an of_platform_bus fabric driver.
>
> Cheers,
> g.
>
> >
> > The layout of the hardware and the relationship between the I2S, I2C, codec,
> > and whatever device is determined by *both* the fabric driver and the device
> > tree. The information about the devices itself, and *some* information about
> > their relationship is stored in the device tree. Everything else is in the
> > fabric driver.
> >
> > The design of the device tree is already locked in stone, so to speak. The DT
> > can only store what it is allowed to store. If there's something more that
> > you need, you'll have to put it in the fabric driver.
> >
> > If I weren't on vacation this week, I'd email you my code. It's almost done
> > and it demonstrates what I'm thinking.
> >
> > --
> > Timur Tabi
> > Linux Kernel Developer @ Freescale
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>
--
Jon Smirl
jonsmirl@gmail.com
^ 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