* How to create custom ramdisk
From: Neeraj Garg @ 2008-07-22 13:12 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 250 bytes --]
Hi,
I want to create a custom ramdisk (initrd which can be placed in
arch/ppc/boot/images). Can anybody guide me steps to built the same. My
host have RHEL-4.
--
-------------------------------------------------------------------
Neeraj Garg
[-- Attachment #2: Type: text/html, Size: 606 bytes --]
^ permalink raw reply
* Re: [git pull] Please pull from powerpc.git merge branch
From: Kumar Gala @ 2008-07-22 13:11 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev list, akpm, Linus Torvalds, Linux Kernel list
In-Reply-To: <1216711931.11027.193.camel@pasglop>
On Jul 22, 2008, at 2:32 AM, Benjamin Herrenschmidt wrote:
> Hi Linus !
>
> Here's the second batch of powerpc updates. I should have a last one
> before the end of the merge window for things that are stealing
> dealing
> with conflicts or dependencies but we are getting there.
>
> So please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
>
> Hopefully this one shouldn't whack the main Makefile :-)
>
> Note a couple of fbdev updates. One is an offb change by me, this is
> a powerpc specific driver so that shouldn't affect anybody else, and
> one is the ps3 specific fbdev by Geoff, so again, there should be
> no collateral damage.
>
> Some drivers/net changes to freescale specific drivers are coming from
> Kumar's tree. Kumar, I merged them, however, shouldn't we have Jeff's
> ack on these things or is it ok as long as those are arch specific
> drivers and the changes boring ?
they had jeff's ack. I just didn't update the commits, my bad and
I'll fix that in the future.
- k
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Misbah khan @ 2008-07-22 13:22 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4885AC94.7050501@coritel.it>
Hi All ...
First of all let me thank you for your valuable suggessions ...
1. I wanted to allocate 9MB in kernel and wanted that memory to be mapped to
the physically continews SDRAM memory. but till now i could not found a way
to do so ???
2. So i thought to use ioremap to map SDRAM and make it accessible to user
using mmap technique but there is only one doubt and that is will it be
secure and stable and whether it is a right way of doing ???
3. Now i have allocated 3MB of memory in kernel for simulation purpose in
dma region and writing to 1 MB at a time in the driver and reading it in the
application this works good in the Linux PC where as in the board i could
just read '/0' char always .
4. When i do ioremap to a cpld memory mapped reg (as i am using simul board
which does not have the actual SDRAM mapping ) i could read write to it but
in the application i can read a value of '/0' always
5. Can i actually do ioremap to 9 MB SDRAM memory and map it to the user
using function remap_pfn_range() ???
I am sorry Stornelli
--- Since there is a time criticality hence i am not able to look the driver
books and documentation as of now and trying my little knowledge and your
suggessions ....
------ Misbah <><
Marco Stornelli wrote:
>
>> On Tuesday 22 July 2008, Misbah khan wrote:
>>> I am getting kernel panic while trying these as suggested by you ,the
>>> following points will elaborate my concern :-
>>> i am allocating memory using vmalloc and remaping to the SDRAM area as
>>> :-
>>>
>>> buf_area = vmalloc(sizeof(circularbuffer_S));
>>> if(!buf_area)
>>> {
>>> printk(KERN_ALERT"vmalloc failed \n");
>>> return -1;
>>> }
>>>
>>> buf_area = (circularbuffer_S *)ioremap(7700000,900000);
>>> if(!buf_area)
>>> {
>>> printk(KERN_ALERT"ioremap failed \n");
>>> return -1;
>>> }
>
> Misbah I suggest you, before to write in a Linux mailing list, to read
> Understanding the Linux kernel, Linux device drivers, Understanding the
> Linux virtual memory manager and so on, to study them very well, to
> think well about your problem and then ask for help in a mailing list.
>
> Regards,
>
> --
> Marco Stornelli
> Embedded Software Engineer
> CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
> http://www.coritel.it
>
> marco.stornelli@coritel.it
> +39 06 72582838
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/how-to-allocate-9MB-of-memory-in-kernel---tp18503022p18587466.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 10/16 v3] powerpc: iommu enablement for CMO
From: Robert Jennings @ 2008-07-22 13:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Brian King, linuxppc-dev, David Darrington
In-Reply-To: <18565.26804.757649.584391@cargo.ozlabs.ibm.com>
* Paul Mackerras (paulus@samba.org) wrote:
> Robert Jennings writes:
>
> > To support Cooperative Memory Overcommitment (CMO), we need to check
> > for failure from some of the tce hcalls.
>
> This patch runs into context mismatches because of changes made by
> Michael Ellerman's patch "Fix sparse warnings in
> arch/powerpc/platforms/pseries" (now in Linus' tree), which changed
> code like
>
> if (condition)
> return function_returning_void(args);
>
> into
>
> if (condition) {
> function_returning_void(args);
> return;
> }
>
> which will cause problems for your patch. Please check if any of
> these changes need to be undone again.
I do need to revert those changes, the return values will no longer be
void. I'll get those tested and posted. Thanks.
--Rob Jennings
^ permalink raw reply
* Re: [PATCH 10/16 v3] [v2] powerpc: iommu enablement for CMO
From: Robert Jennings @ 2008-07-22 13:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Brian King, David Darrington, linuxppc-dev
In-Reply-To: <18565.27216.228641.108772@cargo.ozlabs.ibm.com>
* Paul Mackerras (paulus@samba.org) wrote:
> Robert Jennings writes:
>
> > Minor change to add a call to align the return from the device's
> > get_desired_dma() function with IOMMU_PAGE_ALIGN(). Also removed a
> > comment referring to a non-existent structure member.
>
> Anyway, my first comment is that the first paragraph of the
> description ("Minor change to ...") is not appropriate for the git
> tree and will have to be edited before the patch is applied. If the
> extra changes are worth describing, describe them (in stand-alone
> fashion) in the description; otherwise put things like this after the
> line of three dashes, which terminates the description.
I'll correct this with the other changes that need to be made.
> > +static int vio_dma_iommu_map_sg(struct device *dev, struct scatterlist *sglist,
> > + int nelems, enum dma_data_direction direction)
>
> This function, and the related unmap_sg, map_single and unmap_single
> functions, now take an extra "struct dma_attrs *attrs" argument since
> Mark Nelson's patch "powerpc/dma: implement new dma_*map*_attrs()
> interfaces" went in (and it's now in Linus' tree). You need to roll
> something like the patch below in with the 11/16 patch.
I'll repost with updates to add the dma_attrs field.
--Rob
^ permalink raw reply
* Help: Kernel BUG with U-boot 1.1.4 and kernel 2.6.23 scanning PCIe on a MPC8641D board
From: joachim.bader @ 2008-07-22 13:33 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 11963 bytes --]
Hello folks,
we run a proprietary board with Freescale MPC8641D using U-boot 1.1.4 and
Linux kernel 2.6.23
First of all, we are no experts in PCIe-Bus handling and management.
We started with the problem that U-Boot was able to scan the devices
connected to PCIe-Bus where the kernel fails.
Using the information provided by Vince Asbridge regarding the different
numbering of devices on PCIe bus by U-Boot and kernel we were able to get
the kernel up recognizing the devices correctly.
Thanks for this info.
But now we are blocked by an exception in kernel mode during
initialisation of the PCIe-Buses and devices. We instrumented the kernel
additional to the standard print outs to get more information and to
understand the behavior of the scan and allocation process. But now we get
lost. I assume that the problem is caused by the transparent bridges.
I appent here after the trace log. Perhaps someone knows this problem
already or can give me a hint .
I read in the logs some messages that 2.6.23 does contain some bugs
related to PCIe and it would be a good choice to upgrade to 2.6.25. Is
this one of that cases?
Currently we would like to prevent switching the kernel version.
Any help is appreciated.
Thanks in advance.
Joachim
--
Dipl.-Ing. Joachim Bader
Research & Technology
Cockpit and Display Systems
Diehl Aerospace GmbH
An der Sandelmuehle 13
D-60439 Frankfurt
Phone +49-69-5805-1270
Fax +49-69-5805-1400
e-mail: joachim.bader@diehl-aerospace.de
http://www.diehl-aerospace.de
------ TRACE LOG --------
Load address: 0x1000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
############
done
Bytes transferred = 1389893 (153545 hex)
## Booting image at 01000000 ...
Image Name: Linux-2.6.23
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1389829 Bytes = 1.3 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x0FF9B968 => set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFF9B
bd address = 0x0FF9BFB0
memstart = 0x00000000
memsize = 0x20000000
flashstart = 0xF0000000
flashsize = 0x10000000
flashoffset = 0x00000000
sramstart = 0x00000000
sramsize = 0x00000000
bootflags = 0x00000001
intfreq = 990 MHz
busfreq = 396 MHz
ethaddr = 00:E0:0C:00:00:10
eth1addr = 00:E0:0C:00:01:10
eth2addr = 00:E0:0C:00:02:10
eth3addr = 00:E0:0C:00:03:10
IP addr = 172.30.222.10
baudrate = 115200 bps
No initrd
## Transferring control to Linux (at address 00000000) ...
Linux Kernel Parameters:
of_flat_tree: 007fde60 = d00dfeed
kernel: 00000000 = 60000000
Using MPC86xx HPCN machine description
Total memory = 512MB; using 1024kB for hash table (at cff00000)
Linux version 2.6.23 (vowinkel@ariadne) (gcc version 3.3.2) #94 Tue Jul 22
14:43:39 CEST 2008
console [udbg0] enabled
setup_arch: bootmem
mpc86xx_hpcn_setup_arch()
Found FSL PCI host bridge at 0x00000000d4008000.Firmware bus number:
0->254
Dump of resource ranges:
len=12
0x02000000
0x00000000
0x40000000
0x40000000
0x00000000
0x10000000
0x01000000
0x00000000
0x00000000
0x5e000000
0x00000000
0x01000000
PCI: MEM[0] 0x40000000 -> 0x4fffffff
PCI: IO Phys = 0x5e000000
PCI: IO Virt = 0x5e000000
PCI: IO 0x0 -> 0xffffff
Found FSL PCI host bridge at 0x00000000d4009000.Firmware bus number:
0->254
Dump of resource ranges:
len=12
0x02000000
0x00000000
0x80000000
0x80000000
0x00000000
0x10000000
0x01000000
0x00000000
0x00000000
0x9e000000
0x00000000
0x 1000000
PCI: MEM[0] 0x80000000 -> 0x8fffffff
PCI: IO Phys = 0x9e000000
PCI: IO Virt = 0x9e000000
PCI: IO 0x0 -> 0xffffff
MPC86xx HPCN board from Freescale Semiconductor
arch: exit
Zone PFN ranges:
DMA 0 -> 131072
Normal 131072 -> 131072
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 131072
Built 1 zonelists in Zone order. Total pages: 130048
Kernel command line: root=/dev/nfs rw
nfsroot=172.30.222.1:/data/home/pub/taurus10
ip=172.30.222.10:172.30.222.1:172.30.222.1:255.255.255.0:taurus:eth2:off
console=ttyS0,115200
mpic: Setting up MPIC " MPIC " version 1.2 at d4040000, max 2 CPUs
mpic: ISU size: 88, shift: 7, mask: 7f
mpic: Initializing for 88 sources
PID hash table entries: 2048 (order: 11, 8192 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 515328k/524288k available (2712k kernel code, 8620k reserved, 144k
data, 140k bss, 136k init)
Mount-cache hash table entries: 512
====== bus.c -> registering device: ID = 'platform'
NET: Registered protocol family 16
====== bus.c -> registering device: ID = 'vtcon0'
====== bus.c -> registering device: ID = 'fsl-gianfar_mdio.35'
====== bus.c -> registering device: ID = 'fsl-gianfar.1'
====== bus.c -> registering device: ID = 'fsl-gianfar.2'
====== bus.c -> registering device: ID = 'fsl-gianfar.3'
====== bus.c -> registering device: ID = 'fsl-gianfar.4'
====== bus.c -> registering device: ID = 'fsl-i2c.1'
====== bus.c -> registering device: ID = 'fsl-i2c.2'
====== bus.c -> registering device: ID = 'fsl-hydra.1'
PCI: Probing PCI hardware
====== bus.c -> registering device: ID = 'pci0000:00'
PCI: 0000:00:00.0: class b20 doesn't match header type 01. Ignoring class.
PCI: Transparent bridge - 0000:00:00.0
====== bus.c -> registering device: ID = '0000:00:00.0'
====== bus.c -> registering device: ID = '0000:01:00.0'
====== bus.c -> registering device: ID = '0000:02:01.0'
====== bus.c -> registering device: ID = '0000:02:02.0'
====== bus.c -> registering device: ID = 'pci0001:05'
PCI: 0001:05:00.0: class b20 doesn't match header type 01. Ignoring class.
PCI: Transparent bridge - 0001:05:00.0
====== bus.c -> registering device: ID = '0001:05:00.0'
====== bus.c -> registering device: ID = '0001:06:00.0'
====== bus.c -> registering device: ID = '0001:07:01.0'
====== bus.c -> registering device: ID = '0001:07:02.0'
====== bus.c -> registering device: ID = '0001:07:03.0'
====== bus.c -> registering device: ID = '0001:09:00.0'
====== bus.c -> registering device: ID = '0001:0a:04.0'
====== bus.c -> registering device: ID = '0001:0a:04.1'
====== bus.c -> registering device: ID = '0001:0a:04.2'
Res: 0xC02F5040
Start: 0x0
End: 0xFFFFFF
Name: /soc8641@d4000000/pcie@8000
Flags: 0x100
Par: 0xC02AB2A4
Start: 0x0
End: 0xFFFFFFFF
Name: PCI IO
Flags: 0x100
PCI: bridge rsrc 0..ffffff (100), parent c02ab2a4
Res: 0xC02F505C
Start: 0x40000000
End: 0x4FFFFFFF
Name: /soc8641@d4000000/pcie@8000
Flags: 0x200
Par: 0xC02AB2C0
Start: 0x0
End: 0xFFFFFFFF
Name: PCI mem
Flags: 0x200
PCI: bridge rsrc 40000000..4fffffff (200), parent c02ab2c0
Res: 0xDFFE32C8
Start: 0x0
End: 0xFFFFFF
Name: PCI Bus #01
Flags: 0x100
Par: 0xC02F5040
Start: 0x0
End: 0xFFFFFF
Name: /soc8641@d4000000/pcie@8000
Flags: 0x100
PCI: bridge rsrc 0..ffffff (100), parent c02f5040
Res: 0xDFFE32E4
Start: 0x40000000
End: 0x4FFFFFFF
Name: PCI Bus #01
Flags: 0x200
Par: 0xC02F505C
Start: 0x40000000
End: 0x4FFFFFFF
Name: /soc8641@d4000000/pcie@8000
Flags: 0x200
PCI: bridge rsrc 40000000..4fffffff (200), parent c02f505c
Res: 0xC02FA040
Start: 0xFF000000
End: 0xFFFFFFFF
Name: /soc8641@d4000000/pcie@9000
Flags: 0x100
Par: 0xC02AB2A4
Start: 0x0
End: 0xFFFFFFFF
Name: PCI IO
Flags: 0x100
PCI: bridge rsrc ff000000..ffffffff (100), parent c02ab2a4
Res: 0xC02FA05C
Start: 0x80000000
End: 0x8FFFFFFF
Name: /soc8641@d4000000/pcie@9000
Flags: 0x200
Par: 0xC02AB2C0
Start: 0x0
End: 0xFFFFFFFF
Name: PCI mem
Flags: 0x200
PCI: bridge rsrc 80000000..8fffffff (200), parent c02ab2c0
Res: 0xDFFE1360
Start: 0xFF000000
End: 0xFFFFFFFF
Name: PCI Bus #06
Flags: 0x100
Par: 0xC02FA040
Start: 0xFF000000
End: 0xFFFFFFFF
Name: /soc8641@d4000000/pcie@9000
Flags: 0x100
PCI: bridge rsrc ff000000..ffffffff (100), parent c02fa040
Res: 0xDFFE137C
Start: 0x80000000
End: 0x8FFFFFFF
Name: PCI Bus #06
Flags: 0x200
Par: 0xC02FA05C
Start: 0x80000000
End: 0x8FFFFFFF
Name: /soc8641@d4000000/pcie@9000
Flags: 0x200
PCI: bridge rsrc 80000000..8fffffff (200), parent c02fa05c
Res: 0xDFFE0AD8
Start: 0xFF000000
End: 0xFF000FFF
Name: PCI Bus #0a
Flags: 0x101
Par: 0x0
PCI: bridge rsrc ff000000..ff000fff (101), parent 00000000
PCI: Cannot allocate resource region 0 of PCI bridge 10
Res: 0xDFFE0AF4
Start: 0x0
End: 0xFFFFF
Name: PCI Bus #0a
Flags: 0x200
Par: 0x0PCI: bridge rsrc 0..fffff (200), parent 00000000
PCI: Cannot allocate resource region 1 of PCI bridge 10
Res: 0xDFFE0B10
Start: 0x0
End: 0xFFFFF
Name: PCI Bus #0a
Flags: 0x1201
Par: 0x0PCI: bridge rsrc 0..fffff (1201), parent 00000000
PCI: Cannot allocate resource region 2 of PCI bridge 10
PCI: Cannot allocate resource region 0 of device 0000:01:00.0
PCI: Cannot allocate resource region 0 of device 0001:06:00.0
PCI: Cannot allocate resource region 0 of device 0001:09:00.0
PCI: Cannot allocate resource region 0 of device 0001:0a:04.0
PCI: Cannot allocate resource region 0 of device 0001:0a:04.1
PCI: Cannot allocate resource region 0 of device 0001:0a:04.2
PCI: Failed to allocate mem resource #0:2000@0 for 0001:09:00.0
------------[ cut here ]------------
Kernel BUG at c028c504 [verbose debug info unavailable]
Oops: Exception in kernel mode, sig: 5 [#1]
MPC86xx HPCN
NIP: c028c504 LR: c028c504 CTR: c00115b4
REGS: dffc1e40 TRAP: 0700 Not tainted (2.6.23)
MSR: 00029032 <EE,ME,IR,DR> CR: 22008022 XER: 00000000
TASK = dfff0830[1] 'swapper' THREAD: dffc0000
GPR00: c028c504 dffc1ef0 dfff0830 fffffff4 00000001 00000001 00000000
c02d0000
GPR08: 00003379 c02ab200 00000000 c02b0000 22008022 f7fbfffc 0fffa100
00000001
GPR16: 00000001 ffffffff 007fff00 c02a0000 c02a0000 c02a0000 00000002
0ff9ea08
GPR24: c02d0000 c02d0000 000000ff c02d0000 c02d2e88 dffe0814 00000000
dffe0a14
NIP [c028c504] pcibios_assign_resources+0xb8/0xe4
LR [c028c504] pcibios_assign_resources+0xb8/0xe4
Call Trace:
[dffc1ef0] [c028c504] pcibios_assign_resources+0xb8/0xe4 (unreliable)
[dffc1f10] [c028cb24] pcibios_init+0x120/0x164
[dffc1f40] [c0284884] do_initcalls+0x58/0x20c
[dffc1fd0] [c0284afc] kernel_init+0x4c/0xa4
[dffc1ff0] [c0011580] kernel_thread+0x44/0x60
Instruction dump:
2c000000 41820018 7c0803a6 4e800021 2c030000 40820020 813f000c 552000c2
7fa3eb78 7fc4f378 901f000c 4be925c5 <0f030000> 3bde0001 3bff001c 2c1e0005
Kernel panic - not syncing: Attempted to kill init!
Rebooting in 180 seconds.
_______________________________________________________________________________________________________________________
Der Inhalt dieser E-Mail ist für den Absender rechtlich nicht verbindlich.
Informieren Sie uns bitte, wenn Sie diese E-Mail fälschlicherweise erhalten haben (Fax: +49-69-5805-1399). Bitte löschen Sie in diesem Fall die Nachricht. Jede Form der weiteren Benutzung ist untersagt.
The content of this e-mail is not legally binding upon the sender.
If this e-mail was transmitted to you by error, then please inform us accordingly (Fax: +49-69-5805-1399). In such case you are requested to erase the message. Any use of such e-mail message is strictly prohibited.
[-- Attachment #2: Type: text/html, Size: 26290 bytes --]
^ permalink raw reply
* Re: [alsa-devel] [PATCH v3 0/3] ALSA SoC: MPC5200 audio driver
From: Jon Smirl @ 2008-07-22 13:38 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, alsa-devel, liam.girdwood, timur
In-Reply-To: <20080722092646.GA7251@sirena.org.uk>
On 7/22/08, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> On Tue, Jul 22, 2008 at 12:58:09AM -0600, Grant Likely wrote:
>
> > Here is the latest series for adding MPC5200 I2S and TI AIC26 codec
> > support to ALSA SoC. I believe all the comments are addressed and I
> > hope that this series is now ready to be merged. I would really like
> > to see these ones land in 2.6.27.
>
>
> That might be a bit of a push given how far into the merge window we
> are and Takashi's holiday this week, though as they are new drivers
> things could be a bit more relaxed.
These drivers are going to get hit with immediate patches. The DMA is
not broken out so that AC97 support can be fixed for the Efika.
I haven't touched these up for the driver that was just posted.
From: Jon Smirl <jonsmirl@gmail.com>
---
include/sound/soc-of.h | 2 +
sound/soc/fsl/mpc5200_psc_i2s.c | 93 ++++++++++++++++++++++++++++++++-------
sound/soc/fsl/mpc5200_psc_i2s.h | 13 +++++
sound/soc/soc-of.c | 26 +++++++++--
4 files changed, 112 insertions(+), 22 deletions(-)
create mode 100644 sound/soc/fsl/mpc5200_psc_i2s.h
diff --git a/include/sound/soc-of.h b/include/sound/soc-of.h
index a963032..15f0b8d 100644
--- a/include/sound/soc-of.h
+++ b/include/sound/soc-of.h
@@ -17,5 +17,7 @@ int of_snd_soc_register_codec(struct
snd_soc_codec_device *codec_dev,
int of_snd_soc_register_platform(struct snd_soc_platform *platform,
struct device_node *node,
struct snd_soc_cpu_dai *cpu_dai);
+
+void of_snd_soc_register_machine(char *name, struct snd_soc_ops *ops);
#endif /* _INCLUDE_SOC_OF_H_ */
diff --git a/sound/soc/fsl/mpc5200_psc_i2s.c b/sound/soc/fsl/mpc5200_psc_i2s.c
index 81d0933..a34961a 100644
--- a/sound/soc/fsl/mpc5200_psc_i2s.c
+++ b/sound/soc/fsl/mpc5200_psc_i2s.c
@@ -5,6 +5,8 @@
* Copyright (C) 2008 Secret Lab Technologies Ltd.
*/
+#define DEBUG
+
#include <linux/init.h>
#include <linux/module.h>
#include <linux/interrupt.h>
@@ -23,8 +25,12 @@
#include <sysdev/bestcomm/bestcomm.h>
#include <sysdev/bestcomm/gen_bd.h>
+#include <asm/time.h>
+#include <asm/mpc52xx.h>
#include <asm/mpc52xx_psc.h>
+#include "mpc5200_psc_i2s.h"
+
MODULE_AUTHOR("Grant Likely <grant.likely@secretlab.ca>");
MODULE_DESCRIPTION("Freescale MPC5200 PSC in I2S mode ASoC Driver");
MODULE_LICENSE("GPL");
@@ -90,8 +96,10 @@ struct psc_i2s {
struct mpc52xx_psc_fifo __iomem *fifo_regs;
unsigned int irq;
struct device *dev;
+ u32 sicr;
struct snd_soc_cpu_dai dai;
spinlock_t lock;
+ uint sysclk;
/* per-stream data */
struct psc_i2s_stream playback_stream;
@@ -210,9 +218,7 @@ static int psc_i2s_startup(struct
snd_pcm_substream *substream)
out_8(®s->command, 4 << 4); /* reset error */
/* Default to CODEC8 mode */
- out_be32(®s->sicr,
- MPC52xx_PSC_SICR_DTS1 | MPC52xx_PSC_SICR_I2S |
- MPC52xx_PSC_SICR_CLKPOL | MPC52xx_PSC_SICR_SIM_CODEC_8);
+ out_be32(®s->sicr, psc_i2s->sicr | MPC52xx_PSC_SICR_SIM_CODEC_8);
/* First write: RxRdy (FIFO Alarm) generates receive FIFO interrupt */
/* Second write to mode: register Normal mode for non loopback */
@@ -249,7 +255,7 @@ static int psc_i2s_hw_params(struct
snd_pcm_substream *substream,
{
struct snd_soc_pcm_runtime *rtd = substream->private_data;
struct psc_i2s *psc_i2s = rtd->dai->cpu_dai->private_data;
- u32 sicr;
+ u32 sicr, bits, framesync, bitclk, value;
dev_dbg(psc_i2s->dev, "%s(substream=%p) p_size=%i p_bytes=%i"
" periods=%i buffer_size=%i buffer_bytes=%i\n",
@@ -257,26 +263,46 @@ static int psc_i2s_hw_params(struct
snd_pcm_substream *substream,
params_period_bytes(params), params_periods(params),
params_buffer_size(params), params_buffer_bytes(params));
- sicr = MPC52xx_PSC_SICR_DTS1 |
- MPC52xx_PSC_SICR_I2S | MPC52xx_PSC_SICR_CLKPOL;
+ sicr = psc_i2s->sicr;
switch (params_format(params)) {
case SNDRV_PCM_FORMAT_S8:
sicr |= MPC52xx_PSC_SICR_SIM_CODEC_8;
+ bits = 8;
break;
case SNDRV_PCM_FORMAT_S16_BE:
sicr |= MPC52xx_PSC_SICR_SIM_CODEC_16;
+ bits = 16;
break;
case SNDRV_PCM_FORMAT_S24_BE:
sicr |= MPC52xx_PSC_SICR_SIM_CODEC_24;
+ bits = 24;
break;
case SNDRV_PCM_FORMAT_S32_BE:
sicr |= MPC52xx_PSC_SICR_SIM_CODEC_32;
+ bits = 32;
break;
default:
dev_dbg(psc_i2s->dev, "invalid format\n");
return -EINVAL;
}
out_be32(&psc_i2s->psc_regs->sicr, sicr);
+
+ if (psc_i2s->sysclk) {
+ framesync = bits * 2;
+ bitclk = (psc_i2s->sysclk) / (params_rate(params) * framesync);
+
+ /* bitclk field is byte swapped due to mpc5200/b compatibility */
+ value = ((framesync - 1) << 24) |
+ (((bitclk - 1) & 0xFF) << 16) | ((bitclk - 1) & 0xFF00);
+
+ dev_dbg(psc_i2s->dev, "%s(substream=%p) rate=%i sysclk=%i"
+ " framesync=%i bitclk=%i reg=%X\n",
+ __FUNCTION__, substream, params_rate(params), psc_i2s->sysclk,
+ framesync, bitclk, value);
+
+ out_be32(&psc_i2s->psc_regs->ccr, value);
+ out_8(&psc_i2s->psc_regs->ctur, bits - 1);
+ }
//rc = snd_pcm_lib_malloc_pages(substream, params_buffer_bytes(params));
//if (rc) {
@@ -463,9 +489,29 @@ static int psc_i2s_set_sysclk(struct
snd_soc_cpu_dai *cpu_dai,
int clk_id, unsigned int freq, int dir)
{
struct psc_i2s *psc_i2s = cpu_dai->private_data;
- dev_dbg(psc_i2s->dev, "psc_i2s_set_sysclk(cpu_dai=%p, dir=%i)\n",
- cpu_dai, dir);
- return (dir == SND_SOC_CLOCK_IN) ? 0 : -EINVAL;
+ int clkdiv, err;
+ dev_dbg(psc_i2s->dev, "psc_i2s_set_sysclk(cpu_dai=%p, freq=%u, dir=%i)\n",
+ cpu_dai, freq, dir);
+ if (dir == SND_SOC_CLOCK_OUT) {
+ psc_i2s->sysclk = freq;
+ if (clk_id == MPC52xx_CLK_CELLSLAVE) {
+ psc_i2s->sicr |= MPC52xx_PSC_SICR_CELLSLAVE | MPC52xx_PSC_SICR_GENCLK;
+ } else { /* MPC52xx_CLK_INTERNAL */
+ psc_i2s->sicr &= ~MPC52xx_PSC_SICR_CELLSLAVE;
+ psc_i2s->sicr |= MPC52xx_PSC_SICR_GENCLK;
+
+ clkdiv = ppc_proc_freq / freq;
+ err = ppc_proc_freq % freq;
+ if (err > freq / 2)
+ clkdiv++;
+
+ dev_dbg(psc_i2s->dev, "psc_i2s_set_sysclk(clkdiv %d freq error=%ldHz)\n",
+ clkdiv, (ppc_proc_freq / clkdiv - freq));
+
+ return mpc52xx_set_psc_clkdiv(psc_i2s->dai.id + 1, clkdiv);
+ }
+ }
+ return 0;
}
/**
@@ -660,14 +706,15 @@ static int psc_i2s_pcm_new(struct snd_card
*card, struct snd_soc_codec_dai *dai,
return -ENOMEM;
}
- rc = snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, pcm->dev, size,
- &pcm->streams[1].substream->dma_buffer);
- if (rc) {
- snd_dma_free_pages(&pcm->streams[0].substream->dma_buffer);
- dev_err(card->dev, "Can't allocate capture DMA buffer\n");
- return -ENOMEM;
+ if (pcm->streams[1].substream != NULL) { /* only allocate if the is
a capture stream */
+ rc = snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, pcm->dev, size,
+ &pcm->streams[1].substream->dma_buffer);
+ if (rc) {
+ snd_dma_free_pages(&pcm->streams[0].substream->dma_buffer);
+ dev_err(card->dev, "Can't allocate capture DMA buffer\n");
+ return -ENOMEM;
+ }
}
-
return 0;
}
@@ -829,6 +876,18 @@ static int __devinit psc_i2s_of_probe(struct of_device *op,
return -ENODEV;
}
+ /* Disable all interrupts and reset the PSC */
+ out_be16(&psc_i2s->psc_regs->mpc52xx_psc_imr, 0);
+ out_8(&psc_i2s->psc_regs->command, 3 << 4); /* reset transmitter */
+ out_8(&psc_i2s->psc_regs->command, 2 << 4); /* reset receiver */
+ out_8(&psc_i2s->psc_regs->command, 1 << 4); /* reset mode */
+ out_8(&psc_i2s->psc_regs->command, 4 << 4); /* reset error */
+
+ /* Default to CODEC8 mode */
+ psc_i2s->sicr = MPC52xx_PSC_SICR_DTS1 | MPC52xx_PSC_SICR_I2S |
+ MPC52xx_PSC_SICR_CLKPOL;
+ out_be32(&psc_i2s->psc_regs->sicr, psc_i2s->sicr |
MPC52xx_PSC_SICR_SIM_CODEC_8);
+
/* Save what we've done so it can be found again later */
dev_set_drvdata(&op->dev, psc_i2s);
@@ -865,7 +924,7 @@ static int __devexit psc_i2s_of_remove(struct of_device *op)
/* Match table for of_platform binding */
static struct of_device_id psc_i2s_match[] __devinitdata = {
- { .compatible = "fsl,mpc5200-psc-i2s", },
+ { .compatible = "fsl,mpc5200b-psc-i2s", },
{}
};
MODULE_DEVICE_TABLE(of, psc_i2s_match);
diff --git a/sound/soc/fsl/mpc5200_psc_i2s.h b/sound/soc/fsl/mpc5200_psc_i2s.h
new file mode 100644
index 0000000..0e0a84e
--- /dev/null
+++ b/sound/soc/fsl/mpc5200_psc_i2s.h
@@ -0,0 +1,13 @@
+/*
+ * Freescale MPC5200 PSC in I2S mode
+ * ALSA SoC Digital Audio Interface (DAI) driver
+ *
+ */
+
+#ifndef __SOUND_SOC_FSL_MPC52xx_PSC_I2S_H__
+#define __SOUND_SOC_FSL_MPC52xx_PSC_I2S_H__
+
+#define MPC52xx_CLK_INTERNAL 0
+#define MPC52xx_CLK_CELLSLAVE 1
+
+#endif /* __SOUND_SOC_FSL_MPC52xx_PSC_I2S_H__ */
diff --git a/sound/soc/soc-of.c b/sound/soc/soc-of.c
index 9694979..3d21ed0 100644
--- a/sound/soc/soc-of.c
+++ b/sound/soc/soc-of.c
@@ -38,8 +38,8 @@ struct of_snd_soc_device {
struct device_node *codec_node;
};
-static struct snd_soc_ops of_snd_soc_ops = {
-};
+static struct snd_soc_ops *machine_ops = NULL;
+static char *machine_name = NULL;
static struct of_snd_soc_device *
of_snd_soc_get_device(struct device_node *codec_node)
@@ -61,7 +61,7 @@ of_snd_soc_get_device(struct device_node *codec_node)
of_soc->machine.dai_link = &of_soc->dai_link;
of_soc->machine.num_links = 1;
of_soc->device.machine = &of_soc->machine;
- of_soc->dai_link.ops = &of_snd_soc_ops;
+ of_soc->dai_link.ops = machine_ops;
list_add(&of_soc->list, &of_snd_soc_device_list);
return of_soc;
@@ -74,7 +74,7 @@ static void of_snd_soc_register_device(struct
of_snd_soc_device *of_soc)
/* Only register the device if both the codec and platform have
* been registered */
- if ((!of_soc->device.codec_data) || (!of_soc->platform_node))
+ if ((!of_soc->device.codec_data) || (!of_soc->platform_node) || !machine_name)
return;
pr_info("platform<-->codec match achieved; registering machine\n");
@@ -159,7 +159,7 @@ int of_snd_soc_register_platform(struct
snd_soc_platform *platform,
of_soc->platform_node = node;
of_soc->dai_link.cpu_dai = cpu_dai;
of_soc->device.platform = platform;
- of_soc->machine.name = of_soc->dai_link.cpu_dai->name;
+ of_soc->machine.name = machine_name;
/* Now try to register the SoC device */
of_snd_soc_register_device(of_soc);
@@ -169,3 +169,19 @@ int of_snd_soc_register_platform(struct
snd_soc_platform *platform,
return rc;
}
EXPORT_SYMBOL_GPL(of_snd_soc_register_platform);
+
+void of_snd_soc_register_machine(char *name, struct snd_soc_ops *ops)
+{
+ struct of_snd_soc_device *of_soc;
+
+ machine_name = name;
+ machine_ops = ops;
+
+ list_for_each_entry(of_soc, &of_snd_soc_device_list, list) {
+ of_soc->dai_link.ops = machine_ops;
+ of_soc->machine.name = machine_name;
+ of_snd_soc_register_device(of_soc);
+ }
+
+}
+EXPORT_SYMBOL_GPL(of_snd_soc_register_machine);
>
> Takashi, I'll queue these (and other ASoC patches) for submission in
> bulk once you return.
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply related
* latest tree build failure -- cpm uart & gpio
From: Kumar Gala @ 2008-07-22 13:54 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: Linux Kernel list, Alan Cox
can someone look at the following compile failure in linus's tree.
I'm guessing part of this has to do with Alan's tty changes (and might
already be addressed?).
include/asm-generic/gpio.h:131: error: implicit declaration of
function 'gpio_get_value'
include/asm-generic/gpio.h:137: error: implicit declaration of
function 'gpio_set_value'
make[4]: *** [drivers/net/fs_enet/fs_enet-main.o] Error 1
drivers/serial/cpm_uart/cpm_uart_core.c:212: error: 'struct uart_info'
has no member named 'tty'
make[4]: *** [drivers/serial/cpm_uart/cpm_uart_core.o] Error 1
make[3]: *** [drivers/serial/cpm_uart] Error 2
make[3]: *** [drivers/net/fs_enet] Error 2
make[2]: *** [drivers/net] Error 2
make[2]: *** [drivers/serial] Error 2
make[1]: *** [drivers] Error 2
make: *** [sub-make] Error 2
- k
^ permalink raw reply
* Re: latest tree build failure -- cpm uart & gpio
From: Alan Cox @ 2008-07-22 13:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Linux Kernel list
In-Reply-To: <FBE46DB6-A457-4AD8-9D6E-9D639AD04325@freescale.com>
On Tue, 22 Jul 2008 08:54:16 -0500
Kumar Gala <kumar.gala@freescale.com> wrote:
> can someone look at the following compile failure in linus's tree.
> I'm guessing part of this has to do with Alan's tty changes (and might
> already be addressed?).
>
> include/asm-generic/gpio.h:131: error: implicit declaration of
> function 'gpio_get_value'
> include/asm-generic/gpio.h:137: error: implicit declaration of
> function 'gpio_set_value'
These are not
> make[4]: *** [drivers/net/fs_enet/fs_enet-main.o] Error 1
> drivers/serial/cpm_uart/cpm_uart_core.c:212: error: 'struct uart_info'
> has no member named 'tty'
That one is and hasn't been addressed so I wil do it right now.
^ permalink raw reply
* Re: [alsa-devel] [PATCH v3 0/3] ALSA SoC: MPC5200 audio driver
From: Mark Brown @ 2008-07-22 14:10 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, timur, liam.girdwood
In-Reply-To: <9e4733910807220638u5cf48424l92ba780ecd9e3d9d@mail.gmail.com>
On Tue, Jul 22, 2008 at 09:38:11AM -0400, Jon Smirl wrote:
> These drivers are going to get hit with immediate patches. The DMA is
> not broken out so that AC97 support can be fixed for the Efika.
Further updates shouldn't present a problem - if anything, it should be
easier easier to review incremental patches.
^ permalink raw reply
* Re: radeonfb, dedicate memory to something else
From: Jon Smirl @ 2008-07-22 14:25 UTC (permalink / raw)
To: Matt Sealey; +Cc: ppc-dev, Michel Dänzer
In-Reply-To: <4885A2C2.4060603@genesi-usa.com>
On 7/22/08, Matt Sealey <matt@genesi-usa.com> wrote:
> Michel D=E4nzer wrote:
>
> > On Tue, 2008-07-22 at 09:31 +0100, Matt Sealey wrote:
> >
> > > or other graphics drivers can be told "please only use the first 32MB=
"
> and
> > > then either manually or automatically, map the rest as ramdisk.
> > >
> >
> > You can limit the amount of video RAM used by X using the VideoRam
> > directive in xorg.conf(5).
> >
>
>
> Is it safe to poke around in radeon_identify_vram and maybe supply a ker=
nel
> argument videomem=3D32M and let it check, if it's bigger, then limit it,=
and
> if not, keep the old size in rinfo->video_ram?
>
> Can/could this be moved to all relevant framebuffer drivers?
>
>
> > GART doesn't have anything to do with this. I suspect he was thinking o=
f
> > the PCI BARs not covering all video RAM.
> >
>
> That's certainly not the case here.
Yes, I'm forgetting how graphics work. If you can map all of VRAM into
the PCI address space then you don't have to worry about sharing the
window with X.
> Ah okay. So now.. how do we do this for framebuffers?
My memory is suspect, but first you would need to make sure all of
VRAM is mapped. Then there is a value in fb that says how much of the
VRAM it is using. Anything above the max is fair game if X isn't
running. Note that the amount of VRAM in use by fbdev is a function of
which display mode it is in.
>
> --
> Matt Sealey <matt@genesi-usa.com>
> Genesi, Manager, Developer Relations
>
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [alsa-devel] [PATCH v3 0/3] ALSA SoC: MPC5200 audio driver
From: Jon Smirl @ 2008-07-22 14:52 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, alsa-devel, liam.girdwood, timur,
Mark Brown
In-Reply-To: <20080722141027.GB12555@sirena.org.uk>
On 7/22/08, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> On Tue, Jul 22, 2008 at 09:38:11AM -0400, Jon Smirl wrote:
>
> > These drivers are going to get hit with immediate patches. The DMA is
> > not broken out so that AC97 support can be fixed for the Efika.
>
> Further updates shouldn't present a problem - if anything, it should be
> easier easier to review incremental patches.
I'm just going to ignore 2.6.27 and wait for 2.6.28. This driver only
partially implement i2s support and assumes external clocking. There's
no way to add a ASOC machine driver. It's not a general purpose
driver. Adding the rest of the features probably means device tree
changes.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: latest tree build failure -- cpm uart & gpio
From: Anton Vorontsov @ 2008-07-22 14:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: David Brownell, linuxppc-dev list, Linux Kernel list, Alan Cox
In-Reply-To: <FBE46DB6-A457-4AD8-9D6E-9D639AD04325@freescale.com>
On Tue, Jul 22, 2008 at 08:54:16AM -0500, Kumar Gala wrote:
> can someone look at the following compile failure in linus's tree. I'm
> guessing part of this has to do with Alan's tty changes (and might
> already be addressed?).
>
> include/asm-generic/gpio.h:131: error: implicit declaration of function
> 'gpio_get_value'
> include/asm-generic/gpio.h:137: error: implicit declaration of function
> 'gpio_set_value'
I think this patch should help:
[OF] of_gpio: should use new <linux/gpio.h> header
http://patchwork.ozlabs.org/linuxppc/patch?id=18750
David, can you please Ack it? See Benjamin's mail:
http://ozlabs.org/pipermail/linuxppc-dev/2008-July/060109.html
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: going to OLS?
From: Becky Bruce @ 2008-07-22 14:55 UTC (permalink / raw)
To: Sean MacLennan, Grant Likely, Wolfgang Denk, Stefan Roese,
Geert Uytterhoeven
Cc: linuxppc-dev
In-Reply-To: <20080721162446.2c23ab01@lappy.seanm.ca>
So,
There doesn't seem to be an official plan, so I'm making one....
Kumar, Andy, and I will be at the Black Thorn at 7:30-ish this
evening. Anybody that wants to join us welcome.
Cheers,
Becky
On Jul 21, 2008, at 4:24 PM, Sean MacLennan wrote:
> On Mon, 21 Jul 2008 14:15:53 -0600
> "Grant Likely" <grant.likely@secretlab.ca> wrote:
>
>> BTW, if anyone else wants to receive the contact phone list, then
>> send
>> me your phone number ASAP. I'll be sending it out this evening.
>
> My home phone number is 613-728-1680.
>
> Cheers,
> Sean
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Mikrotik RouterBoard 333
From: Scott Wood @ 2008-07-22 14:56 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev
In-Reply-To: <48854C02.7000307@gmail.com>
Jerry Van Baren wrote:
> Scott Wood wrote:
>> On Sun, Jul 13, 2008 at 08:44:46PM -0400, Jerry Van Baren wrote:
>>> I'm a half-ack. ;-) I'm partial to u-boot's implementation rather
>>> than using a bootwrapper for obvious reasons. The u-boot
>>> implementation takes the blob as a boot parameter and passes it
>>> along to the kernel after doing appropriate (optional) fixups.
>>
>> And if those fixups expect a malformed device tree?
>
> Oops, very bad choice of terms on my part. :-( The fixups I referred
> to are mostly "fill in the blank" things like setting the various
> clocks, MAC information, PCI information, etc. to the correct values
> based on hardware probing or a priori knowledge. U-boot does not
> (should not / will not!) fix broken device trees. A broken tree w/ the
> u-boot methodology is fixed by loading a corrected one, not requiring a
> full rebuild and reload of the firmware.
No, I understand what you meant -- I mean cases where u-boot expects the
"blanks" to be somewhere other than where they are. This has happened
in the past, with mac-address v. local-mac-address, finding the SOC
node, duplicate /chosen nodes, etc.
> If all else fails, u-boot is GPLed and the user is able to get the
> source and fix it (well, at least for 3 years after purchasing the
> hardware).
Regardless of that, if all else fails, one can ignore the firmware's
tree and use a bootwrapper-provided tree.
> There are advantages and disadvantages to u-boot and boot-wrapper
> methods. There are nothing but disadvantages to having the blob
> physically a part of the firmware (with a double whammy if the firmware
> source is not readily available).
The advantage is that the firmware will be kept in sync with the tree
it's trying to patch.
-Scott
^ permalink raw reply
* Re: [alsa-devel] [PATCH v3 0/3] ALSA SoC: MPC5200 audio driver
From: Timur Tabi @ 2008-07-22 15:14 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, Mark Brown, liam.girdwood
In-Reply-To: <9e4733910807220752o4d220f90o770d55e70f493642@mail.gmail.com>
Jon Smirl wrote:
> I'm just going to ignore 2.6.27 and wait for 2.6.28.
2.6.28 might have ASoC V2, or at least portions of it. You might want to just
port your driver to ASoC V2 like I did and not worry about it.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Arnd Bergmann @ 2008-07-22 15:12 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Misbah khan
In-Reply-To: <18587466.post@talk.nabble.com>
On Tuesday 22 July 2008, Misbah khan wrote:
> First of all let me thank you for your valuable suggessions ...
>
> 1. I wanted to allocate 9MB in kernel and wanted that memory to be mapped to
> the physically continews SDRAM memory. but till now i could not found a way
> to do so ???
>
> 2. So i thought to use ioremap to map SDRAM and make it accessible to user
> using mmap technique but there is only one doubt and that is will it be
> secure and stable and whether it is a right way of doing ???
As I have told you a few times now, you *either* allocate the memory *or*
ioremap it, NOT BOTH!!!
If you SDRAM is you main memory, you need vmalloc and remap_vmalloc_range.
If the SDRAM is not your main memory but some I/O attached buffer, you need
ioremap/of_iomap and remap_pfn_range.
Arnd <><
^ permalink raw reply
* [PATCH] fs_enet: Remove unused fields in the fs_mii_bb_platform_info structure.
From: Laurent Pinchart @ 2008-07-22 15:43 UTC (permalink / raw)
To: linuxppc-dev, netdev; +Cc: jgarzik, vbordug
[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]
The mdio_port, mdio_bit, mdc_port and mdc_bit fields in the
fs_mii_bb_platform_info structure are left-overs from the move to the Phy
Abstraction Layer subsystem. They are not used anymore and can be safely
removed.
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
---
include/linux/fs_enet_pd.h | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/include/linux/fs_enet_pd.h b/include/linux/fs_enet_pd.h
index 9bc045b..decc4b5 100644
--- a/include/linux/fs_enet_pd.h
+++ b/include/linux/fs_enet_pd.h
@@ -103,10 +103,6 @@ struct fs_mii_bb_platform_info {
struct fs_mii_bit mdio_dir;
struct fs_mii_bit mdio_dat;
struct fs_mii_bit mdc_dat;
- int mdio_port; /* port & bit for MDIO */
- int mdio_bit;
- int mdc_port; /* port & bit for MDC */
- int mdc_bit;
int delay; /* delay in us */
int irq[32]; /* irqs per phy's */
};
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* Re: [PATCH] serial: fix struct uart_info change fallout
From: Stephen Rothwell @ 2008-07-22 15:49 UTC (permalink / raw)
To: Alan Cox; +Cc: ppc-dev, linux-next, Linus Torvalds, LKML
In-Reply-To: <20080722114436.2c13edea@lxorguk.ukuu.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]
Hi Alan,
On Tue, 22 Jul 2008 11:44:36 +0100 Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> > What is your problem with the linux-next tree. The problem was
> > discovered and reported when I first merged the ttydev tree into
> > linux-next on July 1. The fixes were in linux-next on July 2.
>
> Yes .. and ? The clashes kept happening despite that when I was doing the
> merges (and going on holiday for a week and trying to sort it out with
> limited time and internet access)
>
> Sorry I don't follow your line of discussion at all here ?
I interpreted your "So much for the linux-next tree" as saying "well,
that has been no help". I am sorry if I got that wrong.
But my point above is that you had a fix for the current breakage in
Linus' tree a couple of weeks before you sent the patches to Linus that
broke the powerpc build (i.e. linux-next did its job) and yet you didn't
combine the fix with the original patch or send the fix with the original
patch. So we end up with a powerpc tree that won't build in the middle
of the merge window while more powerpc patches are trying to be
tested ... I understand that this could easily happen because of
forgetfulness, tiredness or accident.
More care was needed.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] cpm2: Rework baud rate generators configuration to support external clocks.
From: Laurent Pinchart @ 2008-07-22 16:00 UTC (permalink / raw)
To: linuxppc-dev list, kumar.gala; +Cc: vbordug
The CPM2 BRG setup functions cpm_setbrg and cpm2_fastbrg don't support external
clocks. This patch adds a new exported __cpm2_setbrg function that takes the
clock rate and clock source as extra parameters, and moves cpm_setbrg and
cpm2_fastbrg to include/asm-powerpc/cpm2.h where they become inline wrappers
around __cpm2_setbrg.
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
---
arch/powerpc/sysdev/cpm2.c | 34 +++----------------------------
include/asm-powerpc/cpm2.h | 46 +++++++++++++++++++++++++++++++------------
2 files changed, 37 insertions(+), 43 deletions(-)
diff --git a/arch/powerpc/sysdev/cpm2.c b/arch/powerpc/sysdev/cpm2.c
index 9311778..f1c3395 100644
--- a/arch/powerpc/sysdev/cpm2.c
+++ b/arch/powerpc/sysdev/cpm2.c
@@ -115,16 +115,10 @@ EXPORT_SYMBOL(cpm_command);
* Baud rate clocks are zero-based in the driver code (as that maps
* to port numbers). Documentation uses 1-based numbering.
*/
-#define BRG_INT_CLK (get_brgfreq())
-#define BRG_UART_CLK (BRG_INT_CLK/16)
-
-/* This function is used by UARTS, or anything else that uses a 16x
- * oversampled clock.
- */
-void
-cpm_setbrg(uint brg, uint rate)
+void __cpm2_setbrg(uint brg, uint rate, uint clk, int div16, int src)
{
u32 __iomem *bp;
+ u32 val;
/* This is good enough to get SMCs running.....
*/
@@ -135,34 +129,14 @@ cpm_setbrg(uint brg, uint rate)
brg -= 4;
}
bp += brg;
- out_be32(bp, (((BRG_UART_CLK / rate) - 1) << 1) | CPM_BRG_EN);
-
- cpm2_unmap(bp);
-}
-
-/* This function is used to set high speed synchronous baud rate
- * clocks.
- */
-void
-cpm2_fastbrg(uint brg, uint rate, int div16)
-{
- u32 __iomem *bp;
- u32 val;
-
- if (brg < 4) {
- bp = cpm2_map_size(im_brgc1, 16);
- } else {
- bp = cpm2_map_size(im_brgc5, 16);
- brg -= 4;
- }
- bp += brg;
- val = ((BRG_INT_CLK / rate) << 1) | CPM_BRG_EN;
+ val = (((clk / rate) - 1) << 1) | CPM_BRG_EN | src;
if (div16)
val |= CPM_BRG_DIV16;
out_be32(bp, val);
cpm2_unmap(bp);
}
+EXPORT_SYMBOL(__cpm2_setbrg);
int cpm2_clk_setup(enum cpm_clk_target target, int clock, int mode)
{
diff --git a/include/asm-powerpc/cpm2.h b/include/asm-powerpc/cpm2.h
index 4c85ed9..dab9949 100644
--- a/include/asm-powerpc/cpm2.h
+++ b/include/asm-powerpc/cpm2.h
@@ -12,6 +12,7 @@
#include <asm/immap_cpm2.h>
#include <asm/cpm.h>
+#include <sysdev/fsl_soc.h>
#ifdef CONFIG_PPC_85xx
#define CPM_MAP_ADDR (get_immrbase() + 0x80000)
@@ -119,10 +120,40 @@ extern void cpm_dpdump(void);
extern void *cpm_dpram_addr(unsigned long offset);
#endif
-extern void cpm_setbrg(uint brg, uint rate);
-extern void cpm2_fastbrg(uint brg, uint rate, int div16);
extern void cpm2_reset(void);
+/* Baud rate generators.
+*/
+#define CPM_BRG_RST ((uint)0x00020000)
+#define CPM_BRG_EN ((uint)0x00010000)
+#define CPM_BRG_EXTC_INT ((uint)0x00000000)
+#define CPM_BRG_EXTC_CLK3_9 ((uint)0x00004000)
+#define CPM_BRG_EXTC_CLK5_15 ((uint)0x00008000)
+#define CPM_BRG_ATB ((uint)0x00002000)
+#define CPM_BRG_CD_MASK ((uint)0x00001ffe)
+#define CPM_BRG_DIV16 ((uint)0x00000001)
+
+#define CPM2_BRG_INT_CLK (get_brgfreq())
+#define CPM2_BRG_UART_CLK (CPM2_BRG_INT_CLK/16)
+
+extern void __cpm2_setbrg(uint brg, uint rate, uint clk, int div16, int src);
+
+/* This function is used by UARTS, or anything else that uses a 16x
+ * oversampled clock.
+ */
+static inline void cpm_setbrg(uint brg, uint rate)
+{
+ __cpm2_setbrg(brg, rate, CPM2_BRG_UART_CLK, 0, CPM_BRG_EXTC_INT);
+}
+
+/* This function is used to set high speed synchronous baud rate
+ * clocks.
+ */
+static inline void cpm2_fastbrg(uint brg, uint rate, int div16)
+{
+ __cpm2_setbrg(brg, rate, CPM2_BRG_INT_CLK, div16, CPM_BRG_EXTC_INT);
+}
+
/* Function code bits, usually generic to devices.
*/
#define CPMFCR_GBL ((u_char)0x20) /* Set memory snooping */
@@ -221,17 +252,6 @@ typedef struct smc_uart {
#define SMCM_TX ((unsigned char)0x02)
#define SMCM_RX ((unsigned char)0x01)
-/* Baud rate generators.
-*/
-#define CPM_BRG_RST ((uint)0x00020000)
-#define CPM_BRG_EN ((uint)0x00010000)
-#define CPM_BRG_EXTC_INT ((uint)0x00000000)
-#define CPM_BRG_EXTC_CLK3_9 ((uint)0x00004000)
-#define CPM_BRG_EXTC_CLK5_15 ((uint)0x00008000)
-#define CPM_BRG_ATB ((uint)0x00002000)
-#define CPM_BRG_CD_MASK ((uint)0x00001ffe)
-#define CPM_BRG_DIV16 ((uint)0x00000001)
-
/* SCCs.
*/
#define SCC_GSMRH_IRP ((uint)0x00040000)
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
^ permalink raw reply related
* Re: Calling the kernel from a mini-bootloader
From: Guillaume Dargaud @ 2008-07-22 16:01 UTC (permalink / raw)
To: ppcdev
In-Reply-To: <048601c8ebe8$acbfcc50$ad289e86@LPSC0173W>
Answering to myself to try and provide more background info:
> As a follow up to my previous messages, I now have a working kernel and a
> working bootloader... but not when they are both together.
>
> Case in point:
> - load zImage.elf to DRAM 0x400000 with JTAG debugger. Run it. It runs
> fine.
>
> - Load Bootloader.elf to BRAM 0xFFFF0000 with JTAG debugger. Run it. It
> runs fine (but it doesn't do much yet).
>
> - Now load both of the previous ones, and have the bootloader perform a
> jump to kernel:
void main() {
typedef void tFunc(void);
((tFunc *)0x400000)();
}
Now if the bootloader _only_ contains the above code, the kernel runs
perfectly.
Unfortunately I need to do some things in the bootloader: I use 3 GPIOs to
control a frontal set of LEDs, to get a card number and to load/unload a
serial flash memory. Those operations work. But here is the strange thing
that leads me to believe there are interrupt interferences.
If I just read from a GPIO before launching the kernel, it boots fine, with
a few NFS errors when mounting the rootnfs:
[ 4.360060] Freeing unused kernel memory: 76k init
[ 11.432269] nfs: server 192.168.1.185 not responding, still trying
[ 11.441186] nfs: server 192.168.1.185 OK
init started: BusyBox v1.10.1 (2008-04-24 12:26:38 CEST)
genepy login:
Now if I also write to a 2nd GPIO, I get a lot more NFS errors.
And if I also access the flash through the 3rd GPIO, the kernel hangs:
> loaded at: 00400000 004EA19C
> board data at: 004E8120 004E819C
> relocated to: 0040405C 004040D8
> zimage at: 00404E48 004E7A7E
> avail ram: 004EB000 08000000
>
> Linux/PPC load: console=ttyUL0,115200 rw root=/dev/nfs ip=bootp
> Uncompressing Linux...done.
> Now booting the kernel
>
> But then it hangs for exactly 3 minutes, nothing on the serial port,
> before the bootloader restarts.
> Why should the behavior be different whether it's started from the
> debugger or from my bootloader ?
Now I've defined my hardware project using interrupts on the GPIOs, which I
don't need and frankly they don't make sense for an output GPIO. I would
like to try to compile a kernel without GPIO interrupts, unfortunately the
compilation fails:
$ make ARCH=ppc CROSS_COMPILE=powerpc-linux-uclibc-
[...]
CC arch/ppc/syslib/virtex_devices.o
arch/ppc/syslib/virtex_devices.c:535: error: 'XPAR_INTC_0_GPIO_0_VEC_ID'
undeclared here (not in a function)
Question breakdown:
- do I need interrupts for GPIOs ?
- how can I compile the ppc 2.6.25 kernel without them ?
- Why do I have problems running the kernel if the bootloader makes use of
the GPIOs ?
- does the bootloader need to perform some kind of special cleanup before
calling the kernel ?
Thanks a lot for shedding a light on those mysteries.
--
Guillaume Dargaud
http://www.gdargaud.net/
^ permalink raw reply
* Re: UIO not working on ppc405 onchip registers
From: super.firetwister @ 2008-07-22 16:20 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linuxppc-dev@ozlabs.org, linux-embedded@vger.kernel.org
In-Reply-To: <200807220947.43074.super.firetwister@gmail.com>
On Tuesday 22 July 2008, super.firetwister@gmail.com wrote:
> Hello Uwe,
>
> On Tuesday 22 July 2008, Uwe Kleine-K=F6nig wrote:
> > I don't know powerpc in general nor ppc405ep in detail but IIRC arm has
> > problems if some memory is mapped twice. Might this be the problem
> > here?
>
> Maybee, the emac0 (0xef600800) and emac1 (0xef600900) get mapped as well,
> because AFAIK I have to map a whole pagesize (0x1000).
Same problem without emac module loaded.
Did anybody tried to reproduce the problem?
Regards
Markus
^ permalink raw reply
* Re: [PATCH] serial: fix struct uart_info change fallout
From: Alan Cox @ 2008-07-22 15:59 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, linux-next, Linus Torvalds, LKML
In-Reply-To: <20080723014910.7351c495.sfr@canb.auug.org.au>
> I interpreted your "So much for the linux-next tree" as saying "well,
> that has been no help". I am sorry if I got that wrong.
True it didn't help in the merge that much this time. I don't think that
is a problem with the linux-next tree but one of the lack of tty
maintainer and tty tree letting the confusion occur in the first place -
plus a large quantity of first time around ineptness on my part.
> But my point above is that you had a fix for the current breakage in
> Linus' tree a couple of weeks before you sent the patches to Linus that
> broke the powerpc build (i.e. linux-next did its job) and yet you didn't
> combine the fix with the original patch or send the fix with the original
> patch. So we end up with a powerpc tree that won't build in the middle
> of the merge window while more powerpc patches are trying to be
> tested ... I understand that this could easily happen because of
> forgetfulness, tiredness or accident.
I really expected to get the rest merged within an hour or two, but then
it broke, then I was travelling and each time I got wireless access to
resync the tree and work on it - it broke again and again and again.
Next time I will bump the patch up the pile and get it out earlier when
that occurs.
Alan
^ permalink raw reply
* Re: [PATCH] serial: fix struct uart_info change fallout
From: Stephen Rothwell @ 2008-07-22 16:22 UTC (permalink / raw)
To: Alan Cox; +Cc: ppc-dev, linux-next, Linus Torvalds, LKML
In-Reply-To: <20080722165929.717e38d4@lxorguk.ukuu.org.uk>
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
Hi Alan,
On Tue, 22 Jul 2008 16:59:29 +0100 Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> I really expected to get the rest merged within an hour or two, but then
> it broke, then I was travelling and each time I got wireless access to
> resync the tree and work on it - it broke again and again and again.
>
> Next time I will bump the patch up the pile and get it out earlier when
> that occurs.
Excellent.
Just asking: do you have an aversion for merging fixes back into
patches? Not a problem, just so I know. Different people work
differently.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Jon Smirl @ 2008-07-22 16:38 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, broonie, timur, liam.girdwood
In-Reply-To: <20080722065352.7306.60679.stgit@trillian.secretlab.ca>
On 7/22/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Simple utility layer for creating ASoC machine instances based on data
> in the OpenFirmware device tree. OF aware platform drivers and codec
> drivers register themselves with this framework and the framework
> automatically instantiates a machine driver. At the moment, the driver
> is not very capable and it is expected to be extended as more features
> are needed for specifying the configuration in the device tree.
>
> This is most likely temporary glue code to work around limitations in
> the ASoC v1 framework. When v2 is merged, most of this driver will
> need to be reworked.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> include/sound/soc-of-simple.h | 21 +++++
> sound/soc/fsl/Kconfig | 3 +
> sound/soc/fsl/Makefile | 3 +
> sound/soc/fsl/soc-of-simple.c | 171 +++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 198 insertions(+), 0 deletions(-)
>
> diff --git a/include/sound/soc-of-simple.h b/include/sound/soc-of-simple.h
> new file mode 100644
> index 0000000..696fc51
> --- /dev/null
> +++ b/include/sound/soc-of-simple.h
> @@ -0,0 +1,21 @@
> +/*
> + * OF helpers for ALSA SoC
> + *
> + * Copyright (C) 2008, Secret Lab Technologies Ltd.
> + */
> +
> +#ifndef _INCLUDE_SOC_OF_H_
> +#define _INCLUDE_SOC_OF_H_
> +
> +#include <linux/of.h>
> +#include <sound/soc.h>
> +
> +int of_snd_soc_register_codec(struct snd_soc_codec_device *codec_dev,
> + void *codec_data, struct snd_soc_dai *dai,
> + struct device_node *node);
> +
> +int of_snd_soc_register_platform(struct snd_soc_platform *platform,
> + struct device_node *node,
> + struct snd_soc_dai *cpu_dai);
> +
This doesn't compile for me. Where is struct snd_soc_dai being defined?
It used to be....
+int of_snd_soc_register_codec(struct snd_soc_codec_device *codec_dev,
+ void *codec_data, struct snd_soc_codec_dai *dai,
+ struct device_node *node);
+
+int of_snd_soc_register_platform(struct snd_soc_platform *platform,
+ struct device_node *node,
+ struct snd_soc_cpu_dai *cpu_dai);
> +#endif /* _INCLUDE_SOC_OF_H_ */
> diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
> index 3368ace..398f002 100644
> --- a/sound/soc/fsl/Kconfig
> +++ b/sound/soc/fsl/Kconfig
> @@ -1,3 +1,6 @@
> +config SND_SOC_OF_SIMPLE
> + tristate
> +
> config SND_SOC_MPC8610
> bool "ALSA SoC support for the MPC8610 SOC"
> depends on MPC8610_HPCD
> diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
> index 62f680a..aa2100b 100644
> --- a/sound/soc/fsl/Makefile
> +++ b/sound/soc/fsl/Makefile
> @@ -1,3 +1,6 @@
> +# Simple machine driver that extracts configuration from the OF device tree
> +obj-$(CONFIG_SND_SOC_OF_SIMPLE) += soc-of-simple.o
> +
> # MPC8610 HPCD Machine Support
> obj-$(CONFIG_SND_SOC_MPC8610_HPCD) += mpc8610_hpcd.o
>
> diff --git a/sound/soc/fsl/soc-of-simple.c b/sound/soc/fsl/soc-of-simple.c
> new file mode 100644
> index 0000000..0382fda
> --- /dev/null
> +++ b/sound/soc/fsl/soc-of-simple.c
> @@ -0,0 +1,171 @@
> +/*
> + * OF helpers for ALSA SoC Layer
> + *
> + * Copyright (C) 2008, Secret Lab Technologies Ltd.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/moduleparam.h>
> +#include <linux/init.h>
> +#include <linux/delay.h>
> +#include <linux/pm.h>
> +#include <linux/bitops.h>
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <sound/core.h>
> +#include <sound/pcm.h>
> +#include <sound/pcm_params.h>
> +#include <sound/soc.h>
> +#include <sound/soc-of-simple.h>
> +#include <sound/initval.h>
> +
> +MODULE_AUTHOR("Grant Likely <grant.likely@secretlab.ca>");
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("ALSA SoC OpenFirmware bindings");
> +
> +static DEFINE_MUTEX(of_snd_soc_mutex);
> +static LIST_HEAD(of_snd_soc_device_list);
> +static int of_snd_soc_next_index;
> +
> +struct of_snd_soc_device {
> + int id;
> + struct list_head list;
> + struct snd_soc_device device;
> + struct snd_soc_machine machine;
> + struct snd_soc_dai_link dai_link;
> + struct platform_device *pdev;
> + struct device_node *platform_node;
> + struct device_node *codec_node;
> +};
> +
> +static struct snd_soc_ops of_snd_soc_ops = {
> +};
> +
> +static struct of_snd_soc_device *
> +of_snd_soc_get_device(struct device_node *codec_node)
> +{
> + struct of_snd_soc_device *of_soc;
> +
> + list_for_each_entry(of_soc, &of_snd_soc_device_list, list) {
> + if (of_soc->codec_node == codec_node)
> + return of_soc;
> + }
> +
> + of_soc = kzalloc(sizeof(struct of_snd_soc_device), GFP_KERNEL);
> + if (!of_soc)
> + return NULL;
> +
> + /* Initialize the structure and add it to the global list */
> + of_soc->codec_node = codec_node;
> + of_soc->id = of_snd_soc_next_index++;
> + of_soc->machine.dai_link = &of_soc->dai_link;
> + of_soc->machine.num_links = 1;
> + of_soc->device.machine = &of_soc->machine;
> + of_soc->dai_link.ops = &of_snd_soc_ops;
> + list_add(&of_soc->list, &of_snd_soc_device_list);
> +
> + return of_soc;
> +}
> +
> +static void of_snd_soc_register_device(struct of_snd_soc_device *of_soc)
> +{
> + struct platform_device *pdev;
> + int rc;
> +
> + /* Only register the device if both the codec and platform have
> + * been registered */
> + if ((!of_soc->device.codec_data) || (!of_soc->platform_node))
> + return;
> +
> + pr_info("platform<-->codec match achieved; registering machine\n");
> +
> + pdev = platform_device_alloc("soc-audio", of_soc->id);
> + if (!pdev) {
> + pr_err("of_soc: platform_device_alloc() failed\n");
> + return;
> + }
> +
> + pdev->dev.platform_data = of_soc;
> + platform_set_drvdata(pdev, &of_soc->device);
> + of_soc->device.dev = &pdev->dev;
> +
> + /* The ASoC device is complete; register it */
> + rc = platform_device_add(pdev);
> + if (rc) {
> + pr_err("of_soc: platform_device_add() failed\n");
> + return;
> + }
> +
> +}
> +
> +int of_snd_soc_register_codec(struct snd_soc_codec_device *codec_dev,
> + void *codec_data, struct snd_soc_dai *dai,
> + struct device_node *node)
> +{
> + struct of_snd_soc_device *of_soc;
> + int rc = 0;
> +
> + pr_info("registering ASoC codec driver: %s\n", node->full_name);
> +
> + mutex_lock(&of_snd_soc_mutex);
> + of_soc = of_snd_soc_get_device(node);
> + if (!of_soc) {
> + rc = -ENOMEM;
> + goto out;
> + }
> +
> + /* Store the codec data */
> + of_soc->device.codec_data = codec_data;
> + of_soc->device.codec_dev = codec_dev;
> + of_soc->dai_link.name = (char *)node->name;
> + of_soc->dai_link.stream_name = (char *)node->name;
> + of_soc->dai_link.codec_dai = dai;
> +
> + /* Now try to register the SoC device */
> + of_snd_soc_register_device(of_soc);
> +
> + out:
> + mutex_unlock(&of_snd_soc_mutex);
> + return rc;
> +}
> +EXPORT_SYMBOL_GPL(of_snd_soc_register_codec);
> +
> +int of_snd_soc_register_platform(struct snd_soc_platform *platform,
> + struct device_node *node,
> + struct snd_soc_dai *cpu_dai)
> +{
> + struct of_snd_soc_device *of_soc;
> + struct device_node *codec_node;
> + const phandle *handle;
> + int len, rc = 0;
> +
> + pr_info("registering ASoC platform driver: %s\n", node->full_name);
> +
> + handle = of_get_property(node, "codec-handle", &len);
> + if (!handle || len < sizeof(handle))
> + return -ENODEV;
> + codec_node = of_find_node_by_phandle(*handle);
> + if (!codec_node)
> + return -ENODEV;
> + pr_info("looking for codec: %s\n", codec_node->full_name);
> +
> + mutex_lock(&of_snd_soc_mutex);
> + of_soc = of_snd_soc_get_device(codec_node);
> + if (!of_soc) {
> + rc = -ENOMEM;
> + goto out;
> + }
> +
> + of_soc->platform_node = node;
> + of_soc->dai_link.cpu_dai = cpu_dai;
> + of_soc->device.platform = platform;
> + of_soc->machine.name = of_soc->dai_link.cpu_dai->name;
> +
> + /* Now try to register the SoC device */
> + of_snd_soc_register_device(of_soc);
> +
> + out:
> + mutex_unlock(&of_snd_soc_mutex);
> + return rc;
> +}
> +EXPORT_SYMBOL_GPL(of_snd_soc_register_platform);
>
>
--
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