Re: [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Mon, 2010-04-26 at 15:49 -0500, Timur Tabi wrote: An upcoming change in the architecture of ALSA SoC (ASoC) will require the MPC8610 HPCD's ASoC fabric driver to register as a standard platform driver. Therefore, we need to call platform_device_register_simple() from the board's platform code. Signed-off-by: Timur Tabi ti...@freescale.com --- Gross. Loses the linkage to device-tree etc... which is useful for audio especially. You should at least make sure the device node follows for the target driver to be able to use it :-) I'd like you to sync with Grant work on that matter if you are going to convert of_devices into platform_devices. Cheers, Ben. Kumar, the ASoC mainters are willing to pick up this patch, but they want an ACK from you first. Or, you could pick it up, since by itself it's harmless. arch/powerpc/platforms/86xx/mpc8610_hpcd.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c index 5abe137..66afff3 100644 --- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c +++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c @@ -98,6 +98,9 @@ static int __init mpc8610_declare_of_platform_devices(void) /* Without this call, the SSI device driver won't get probed. */ of_platform_bus_probe(NULL, mpc8610_ids, NULL); + /* Register the platform device for the ASoC fabric driver */ + platform_device_register_simple(snd-soc-mpc8610-hpcd, 0, NULL, 0); + return 0; } machine_device_initcall(mpc86xx_hpcd, mpc8610_declare_of_platform_devices); ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] booke_wdt: Fix build (unconstify watchdog_info)
On Mon, 2010-04-26 at 21:43 +0400, Anton Vorontsov wrote:
commit 42747d712de56cf2087b702d2ad90af114c53138 ([WATCHDOG]
watchdog_info constify) introduced the following build failure:
CC booke_wdt.o
booke_wdt.c: In function 'booke_wdt_init':
booke_wdt.c:220: error: assignment of read-only variable 'ident'
Fix this by removing 'const' qualifier from watchdog_info struct.
Should this go via powerpc.git ? If yes, I'll send to Linus asap.
Cheers,
Ben.
Signed-off-by: Anton Vorontsov avoront...@mvista.com
---
drivers/watchdog/booke_wdt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-
diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c
index 500d383..801ead1 100644
--- a/drivers/watchdog/booke_wdt.c
+++ b/drivers/watchdog/booke_wdt.c
@@ -121,7 +121,7 @@ static ssize_t booke_wdt_write(struct file *file, const
char __user *buf,
return count;
}
-static const struct watchdog_info ident = {
+static struct watchdog_info ident = {
.options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
.identity = PowerPC Book-E Watchdog,
};
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.34-rc3 : Badness at lib/dma-debug.c:820 during ibmvscsi init
On Fri, 2010-04-02 at 15:50 +0900, FUJITA Tomonori wrote:
Thanks, here's the patch in the proper format.
=
From: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
Subject: [PATCH] ibmvscsi: fix DMA API misuse
ibmvscsi uses dma_unmap_single() for buffers mapped via
dma_map_sg(). It works however it's the API violation. The DMA debug
facility complains about it:
Hi folks !
Is this going to be merged via the scsi tree ?
Thanks !
Cheers,
Ben.
http://marc.info/?l=linux-scsim=127018555013151w=2
Reported-by: Sachin Sant sach...@in.ibm.com
Tested-by: Sachin Sant sach...@in.ibm.com
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
---
drivers/scsi/ibmvscsi/ibmvscsi.c | 29 ++---
1 files changed, 2 insertions(+), 27 deletions(-)
diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c
b/drivers/scsi/ibmvscsi/ibmvscsi.c
index dc1bcbe..0856436 100644
--- a/drivers/scsi/ibmvscsi/ibmvscsi.c
+++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
@@ -322,16 +322,6 @@ static void set_srp_direction(struct scsi_cmnd *cmd,
srp_cmd-buf_fmt = fmt;
}
-static void unmap_sg_list(int num_entries,
- struct device *dev,
- struct srp_direct_buf *md)
-{
- int i;
-
- for (i = 0; i num_entries; ++i)
- dma_unmap_single(dev, md[i].va, md[i].len, DMA_BIDIRECTIONAL);
-}
-
/**
* unmap_cmd_data: - Unmap data pointed in srp_cmd based on the format
* @cmd: srp_cmd whose additional_data member will be unmapped
@@ -349,24 +339,9 @@ static void unmap_cmd_data(struct srp_cmd *cmd,
if (out_fmt == SRP_NO_DATA_DESC in_fmt == SRP_NO_DATA_DESC)
return;
- else if (out_fmt == SRP_DATA_DESC_DIRECT ||
- in_fmt == SRP_DATA_DESC_DIRECT) {
- struct srp_direct_buf *data =
- (struct srp_direct_buf *) cmd-add_data;
- dma_unmap_single(dev, data-va, data-len, DMA_BIDIRECTIONAL);
- } else {
- struct srp_indirect_buf *indirect =
- (struct srp_indirect_buf *) cmd-add_data;
- int num_mapped = indirect-table_desc.len /
- sizeof(struct srp_direct_buf);
- if (num_mapped = MAX_INDIRECT_BUFS) {
- unmap_sg_list(num_mapped, dev, indirect-desc_list[0]);
- return;
- }
-
- unmap_sg_list(num_mapped, dev, evt_struct-ext_list);
- }
+ if (evt_struct-cmnd)
+ scsi_dma_unmap(evt_struct-cmnd);
}
static int map_sg_list(struct scsi_cmnd *cmd, int nseg,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RESEND 3/3] i2c/ibm-iic: drop NO_IRQ
On Fri, 2010-04-02 at 02:17 +0200, Wolfram Sang wrote:
Drop NO_IRQ as 0 is the preferred way to describe 'no irq'
(http://lkml.org/lkml/2005/11/21/221). This change is safe, as the driver is
only used on powerpc, where NO_IRQ is 0 anyhow.
Oops... forgot those. Applied, will show up in -next soon.
Cheers,
Ben.
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
Acked-by: Grant Likely grant.lik...@secretlab.ca
Cc: Sean MacLennan smaclen...@pikatech.com
Cc: Ben Dooks ben-li...@fluff.org
---
drivers/i2c/busses/i2c-ibm_iic.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-ibm_iic.c
b/drivers/i2c/busses/i2c-ibm_iic.c
index b1bc6e2..2bef534 100644
--- a/drivers/i2c/busses/i2c-ibm_iic.c
+++ b/drivers/i2c/busses/i2c-ibm_iic.c
@@ -668,12 +668,12 @@ static int __devinit iic_request_irq(struct of_device
*ofdev,
int irq;
if (iic_force_poll)
- return NO_IRQ;
+ return 0;
irq = irq_of_parse_and_map(np, 0);
- if (irq == NO_IRQ) {
+ if (!irq) {
dev_err(ofdev-dev, irq_of_parse_and_map failed\n);
- return NO_IRQ;
+ return 0;
}
/* Disable interrupts until we finish initialization, assumes
@@ -683,7 +683,7 @@ static int __devinit iic_request_irq(struct of_device
*ofdev,
if (request_irq(irq, iic_handler, 0, IBM IIC, dev)) {
dev_err(ofdev-dev, request_irq %d failed\n, irq);
/* Fallback to the polling mode */
- return NO_IRQ;
+ return 0;
}
return irq;
@@ -719,7 +719,7 @@ static int __devinit iic_probe(struct of_device *ofdev,
init_waitqueue_head(dev-wq);
dev-irq = iic_request_irq(ofdev, dev);
- if (dev-irq == NO_IRQ)
+ if (!dev-irq)
dev_warn(ofdev-dev, using polling mode\n);
/* Board specific settings */
@@ -766,7 +766,7 @@ static int __devinit iic_probe(struct of_device *ofdev,
return 0;
error_cleanup:
- if (dev-irq != NO_IRQ) {
+ if (dev-irq) {
iic_interrupt_mode(dev, 0);
free_irq(dev-irq, dev);
}
@@ -790,7 +790,7 @@ static int __devexit iic_remove(struct of_device *ofdev)
i2c_del_adapter(dev-adap);
- if (dev-irq != NO_IRQ) {
+ if (dev-irq) {
iic_interrupt_mode(dev, 0);
free_irq(dev-irq, dev);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RESEND 3/3] i2c/ibm-iic: drop NO_IRQ
On Tue, Apr 27, 2010 at 05:06:14PM +1000, Benjamin Herrenschmidt wrote: On Fri, 2010-04-02 at 02:17 +0200, Wolfram Sang wrote: Drop NO_IRQ as 0 is the preferred way to describe 'no irq' (http://lkml.org/lkml/2005/11/21/221). This change is safe, as the driver is only used on powerpc, where NO_IRQ is 0 anyhow. Oops... forgot those. Applied, will show up in -next soon. Ah, thanks. I also asked Ben Dooks to pick them up, but better twice than never ;) -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: perf top broken on ppc64
Am 27.04.2010 um 02:30 schrieb Ian Munsie imun...@au1.ibm.com: I'm using 32 bit userland and 64 bit kernel on a PowerPC box and it's working for me. Are you building perf from the tip tree? I'm using kvm.git which is pretty close to tip. The version says something 2.6.34-rc3'ish. Has anything significantly changed since then? Either way - I'll give it a try. Hey Alex, Did perf from the tip tree work for you? Howdy, Sorry - I left for vacation without replying :). I tried perf from tip with kvm.git kernel and that did show the same effects. I didn't get around to also try to run the tip kernel, and won't be within this week :o Greetings from Gran Canaria, Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] booke_wdt: Fix build (unconstify watchdog_info)
Hi Ben, commit 42747d712de56cf2087b702d2ad90af114c53138 ([WATCHDOG] watchdog_info constify) introduced the following build failure: CC booke_wdt.o booke_wdt.c: In function 'booke_wdt_init': booke_wdt.c:220: error: assignment of read-only variable 'ident' Fix this by removing 'const' qualifier from watchdog_info struct. Should this go via powerpc.git ? If yes, I'll send to Linus asap. I'm sending watchdog related patches to Linus today. This one will be included. Kind regards, Wim. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RESEND 3/3] i2c/ibm-iic: drop NO_IRQ
On Tue, 2010-04-27 at 09:12 +0200, Wolfram Sang wrote: Oops... forgot those. Applied, will show up in -next soon. Ah, thanks. I also asked Ben Dooks to pick them up, but better twice than never ;) Ok, Ben, are you taking them or do you want me to ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] booke_wdt: Fix build (unconstify watchdog_info)
On Tue, 2010-04-27 at 09:42 +0200, Wim Van Sebroeck wrote: Hi Ben, commit 42747d712de56cf2087b702d2ad90af114c53138 ([WATCHDOG] watchdog_info constify) introduced the following build failure: CC booke_wdt.o booke_wdt.c: In function 'booke_wdt_init': booke_wdt.c:220: error: assignment of read-only variable 'ident' Fix this by removing 'const' qualifier from watchdog_info struct. Should this go via powerpc.git ? If yes, I'll send to Linus asap. I'm sending watchdog related patches to Linus today. This one will be included. Thanks ! Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] Correct PowerPC Parport interrupt parsing.
Currently the parsing of the device tree in
arch/powerpc/include/asm/parport.h assumes that the interrupt provided in
the parallel port node is a valid virtual irq. The values for the
interrupts provided in the device tree should have meaning in the context
of the driver for the specific interrupt controller to which the interrupt
is connected and irq_of_parse_and_map() should be used to determine the
correct virtual irq.
Signed-off-by: Martyn Welch martyn.we...@ge.com
---
v2: Corrected irq_of_parse_and_map() index.
arch/powerpc/include/asm/parport.h | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/parport.h
b/arch/powerpc/include/asm/parport.h
index 94942d6..1ca1102 100644
--- a/arch/powerpc/include/asm/parport.h
+++ b/arch/powerpc/include/asm/parport.h
@@ -19,6 +19,8 @@ static int __devinit parport_pc_find_nonpci_ports (int
autoirq, int autodma)
u32 io1, io2;
int propsize;
int count = 0;
+ int virq;
+
for (np = NULL; (np = of_find_compatible_node(np,
parallel,
pnpPNP,400)) != NULL;) {
@@ -26,10 +28,13 @@ static int __devinit parport_pc_find_nonpci_ports (int
autoirq, int autodma)
if (!prop || propsize 6*sizeof(u32))
continue;
io1 = prop[1]; io2 = prop[2];
- prop = of_get_property(np, interrupts, NULL);
- if (!prop)
+
+ virq = irq_of_parse_and_map(np, 0);
+ if (virq == NO_IRQ)
continue;
- if (parport_pc_probe_port(io1, io2, prop[0], autodma, NULL, 0)
!= NULL)
+
+ if (parport_pc_probe_port(io1, io2, virq, autodma, NULL, 0)
+ != NULL)
count++;
}
return count;
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748| Barbirolli Square, Manchester,
E martyn.we...@ge.com| M2 3AB VAT:GB 927559189
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RESEND] serial/mpc52xx_uart: Drop outdated comments
Most things mentioned are either obsolete (platform-support) or wrong (device numbering, DCD spport) these days. The remaining rest is obvious. Signed-off-by: Wolfram Sang w.s...@pengutronix.de Cc: Grant Likely grant.lik...@secretlab.ca --- drivers/serial/mpc52xx_uart.c | 33 - 1 files changed, 0 insertions(+), 33 deletions(-) diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c index 3119fdd..a176ab4 100644 --- a/drivers/serial/mpc52xx_uart.c +++ b/drivers/serial/mpc52xx_uart.c @@ -29,39 +29,6 @@ * kind, whether express or implied. */ -/* Platform device Usage : - * - * Since PSCs can have multiple function, the correct driver for each one - * is selected by calling mpc52xx_match_psc_function(...). The function - * handled by this driver is uart. - * - * The driver init all necessary registers to place the PSC in uart mode without - * DCD. However, the pin multiplexing aren't changed and should be set either - * by the bootloader or in the platform init code. - * - * The idx field must be equal to the PSC index (e.g. 0 for PSC1, 1 for PSC2, - * and so on). So the PSC1 is mapped to /dev/ttyPSC0, PSC2 to /dev/ttyPSC1 and - * so on. But be warned, it's an ABSOLUTE REQUIREMENT ! This is needed mainly - * fpr the console code : without this 1:1 mapping, at early boot time, when we - * are parsing the kernel args console=ttyPSC?, we wouldn't know which PSC it - * will be mapped to. - */ - -/* OF Platform device Usage : - * - * This driver is only used for PSCs configured in uart mode. The device - * tree will have a node for each PSC with mpc52xx-psc-uart in the compatible - * list. - * - * By default, PSC devices are enumerated in the order they are found. However - * a particular PSC number can be forces by adding 'device_no = port#' - * to the device node. - * - * The driver init all necessary registers to place the PSC in uart mode without - * DCD. However, the pin multiplexing aren't changed and should be set either - * by the bootloader or in the platform init code. - */ - #undef DEBUG #include linux/device.h -- 1.7.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.34-rc3 : Badness at lib/dma-debug.c:820 during ibmvscsi init
On Tue, 27 Apr 2010 17:05:21 +1000 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2010-04-02 at 15:50 +0900, FUJITA Tomonori wrote: Thanks, here's the patch in the proper format. = From: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp Subject: [PATCH] ibmvscsi: fix DMA API misuse ibmvscsi uses dma_unmap_single() for buffers mapped via dma_map_sg(). It works however it's the API violation. The DMA debug facility complains about it: Hi folks ! Is this going to be merged via the scsi tree ? Already merged (a71fa1fc43a29133f13ae6ada1a389ca298c0934). ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, Apr 27, 2010 at 04:36:08PM +1000, Benjamin Herrenschmidt wrote: Gross. Loses the linkage to device-tree etc... which is useful for audio especially. You should at least make sure the device node follows for the target driver to be able to use it :-) I'd like you to sync with Grant work on that matter if you are going to convert of_devices into platform_devices. So, Liam already sent a message explaining the technical side of this - the audio subsystem needs to glue together two or more components that don't immediately have anything to do with each other from a device tree point of view and may have rather complex interrelationships. I'd just like to add that I *really* want to see you guys come to some sort of firm and documented conclusion about the way to handle situations like this. Some variant of this seems to come up every single time anyone tries to do anything to do with audio on a system using the device tree and it's getting really repetitive. What would be really useful for audio at this point would be if we could get some sort of decision about how to represent this stuff which we can point people at so that work on systems using the device tree can be done without having to deal with the device tree layout discussions that frequently seem to be involved. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, 2010-04-27 at 10:54 +0100, Mark Brown wrote: I'd just like to add that I *really* want to see you guys come to some sort of firm and documented conclusion about the way to handle situations like this. Some variant of this seems to come up every single time anyone tries to do anything to do with audio on a system using the device tree and it's getting really repetitive. What would be really useful for audio at this point would be if we could get some sort of decision about how to represent this stuff which we can point people at so that work on systems using the device tree can be done without having to deal with the device tree layout discussions that frequently seem to be involved. Agreed. Just seeing how Apple fucked it up so many times, it's not a simple problem :-) The device-tree allows to express all of these relationship but we should be able to come up with a reasonably standard way to do so to avoid every SoC or platform doing it it's own way. I think the main deal is to decide who gets to be the master node which contains the various properties doing the linkage. My gut feeling is that it could be the main transport, ie, the i2s or ac97, but people with more experience dealing with that stuff might have other ideas. Keep in mind that it's perfectly kosher to create nodes for virtual devices. IE. We could imagine a node for the sound subsystem that doesn't actually correspond to any physical device but contain the necessary properties that binds everything together. You could even have multiple of these if you have separate set of sound HW that aren't directly dependant. I don't have bandwidth to contribute much in this discussion right now, at least not to lead it, so I'm happy to let others do so, but I'm happy to provide feedback from my own experience as proposals are made. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, Apr 27, 2010 at 08:09:15PM +1000, Benjamin Herrenschmidt wrote: I think the main deal is to decide who gets to be the master node which contains the various properties doing the linkage. My gut feeling is that it could be the main transport, ie, the i2s or ac97, but people with more experience dealing with that stuff might have other ideas. You're not going to find a single master transport node on more complex systems - some systems have multiple audio interfaces to the CPU (to allow use of hardware mixing, for example), and in systems with things like offboard DSPs or basebands it's not always clear that the CPU Linux is running on is in charge of anything. Keep in mind that it's perfectly kosher to create nodes for virtual devices. IE. We could imagine a node for the sound subsystem that doesn't actually correspond to any physical device but contain the necessary properties that binds everything together. You could even have multiple of these if you have separate set of sound HW that aren't directly dependant. In terms of where to shove any data this is sort of the solution I favour, it's pretty much exactly what's implemented on other platforms at the moment and it seems to adequately represent the physical board (it's not a million miles away from what Timur has here). The main problem is that trying to define a language which can represent the needs of modern mobile audio subsystems just doesn't seem worth the effort. The clocking arrangements for modern mobile audio subsystems aren't trivial, are normally highly device and system specific, and when you add on more exotic things like sharing the bit and frame clocks between multiple audio interfaces it gets even more involved. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
Hello Benjamin, Benjamin Herrenschmidt wrote: Hi Linus ! PowerPC has been a bit quiet this time around :-) That is until Kumar woke me up with a few fixes and defconfig updates for the freescale embedded platforms. I got no comments for the following patch: http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-March/081303.html Can this go in? Thanks bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Tue, 2010-04-27 at 12:48 +0200, Heiko Schocher wrote: Hello Benjamin, Benjamin Herrenschmidt wrote: Hi Linus ! PowerPC has been a bit quiet this time around :-) That is until Kumar woke me up with a few fixes and defconfig updates for the freescale embedded platforms. I got no comments for the following patch: http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-March/081303.html Can this go in? This is Kumar's call. However, it's definitely not something that can go in -rc5, we only take grave bugs / regression fixes at this stage. More like a candidate for -next. My -next branch is open, so it's up to Kumar to pick that up and send me something to pull from. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] genirq: reliably replay pending edge-triggered irq
On Thu, 22 Apr 2010, Guillaume Knispel wrote: When the critical section in handle_edge_irq() is executed after IRQ_DISABLED has been set in the one in disable_irq(), the interrupt is in the one ? -ENOPARSE acked and masked at controller level and IRQ_PENDING is set. --- arch/arm/Kconfig |4 arch/arm/configs/acs5k_defconfig |1 - arch/arm/configs/acs5k_tiny_defconfig |1 - Changing the defconfigs should be a separate patch and I'm not going to push such a thing through the genirq tree. The stale entries do not hurt. diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index 127b871..9bec343 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -1423,7 +1423,7 @@ int setup_ioapic_entry(int apic_id, int irq, entry-polarity = polarity; /* Mask level triggered irqs. - * Use IRQ_DELAYED_DISABLE for edge triggered irqs. + * Edge triggered irqs can be resent by software. That change is unrelated and should be done in a seperate patch. Thanks, tglx ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/4xx: Add optional reset_type property to control reboot via dts
Hi Josh,
On Monday 26 April 2010 20:28:29 Josh Boyer wrote:
On Mon, Apr 26, 2010 at 03:39:01PM +0200, Stefan Roese wrote:
By setting reset_type to one of the following values, the default
software reset mechanism may be overidden. Here the possible values of
reset_type:
NEAT! A 4xx patch! I haven't gotten enough of these lately, so forgive my
nit picking ;)
Sure. Comments welcome, as always.
1 - PPC4xx core reset
2 - PPC4xx chip reset
3 - PPC4xx system reset (default)
We should probably put a brief description of this in the dts bindings
under Documentation (or whereever we're storing them these days. I saw
something about a wiki?).
Right. I thought about this as well (too late). I'll include a short
documentation in my next patch version.
Also, while it's not a large issue, I wonder if there will be confusion on
whether 'reset-type' is the type of reset to use or the type of reset
that was just done. There are some products that actually care about the
latter for various RAS issues. I don't, however, have a great alternative
property name that comes to mind though.
I'll stick with this name for now then.
This will be used by a new PPC440SPe board port, which needs a chip
reset instead of the default system reset to be asserted.
I'm curious why that is?
Hmmm. Frankly, I can't remember the background here. You might what to check
this for yourself. Katmai has the same issue. And I just copied this reboot
code from Katmai for this new 440SPe board.
BTW: Once this patch is finished/accepted, I'll cook up a short katmai patch
to fix this reboot issue here too.
Signed-off-by: Stefan Roese s...@denx.de
Cc: Josh Boyer jwbo...@linux.vnet.ibm.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/sysdev/ppc4xx_soc.c | 17 +++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_soc.c
b/arch/powerpc/sysdev/ppc4xx_soc.c index 5c01435..fe54216 100644
--- a/arch/powerpc/sysdev/ppc4xx_soc.c
+++ b/arch/powerpc/sysdev/ppc4xx_soc.c
@@ -191,11 +191,24 @@ static int __init ppc4xx_l2c_probe(void)
arch_initcall(ppc4xx_l2c_probe);
/*
- * At present, this routine just applies a system reset.
+ * Apply a system reset. Alternatively a board specific value may be
+ * provided via the reset-type property in the cpu node.
*/
void ppc4xx_reset_system(char *cmd)
{
-mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) | DBCR0_RST_SYSTEM);
+struct device_node *np;
+u32 reset_type = DBCR0_RST_SYSTEM;
+const u32 *prop;
+
+np = of_find_node_by_type(NULL, cpu);
+if (np) {
+prop = of_get_property(np, reset-type, NULL);
+if (prop)
+reset_type = prop[0] 28;
+}
While I don't think it's a big issue, I wonder if we should sanity check
the resulting value here. I could see someone being dumb and doing:
reset-type = system;
or something like that. If that is done, what would the resulting shift on
it turn into?
Good idea. I'll add a check in the next version.
Thanks.
Cheers,
Stefan
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
Liam Girdwood wrote: I think one of the difficulties encountered here is that the device tree root for sound in this case is the SSI (Digital Audio Interface) controller and not the sound card as in ASoC. So maybe the problem is how do we represent an ASoC sound card in the device tree ? Yes, that is a topic of concern. If you look at the 8610 DTS, you'll see that the SSI (i2s) is effectively the master. In reality, I just modeled the board in the DTS. The SSI node, for example, lists the two DMA channels it needs. It also points to the codec that it's connected to. And the clock-frequency property is in the codec node because the oscillator is connected to the codec on the board. In theory, would could probably get rid of the DMA node pointers if I can update the standard DMA driver to allow me to reserve two DMA channels. That's not an easy fix, though. The sound card within ASoC is a compound device that is made up of the SSI, Codec and audio DMA engine components. The SSI/Codec/DMA components do not have to be the sound cards child devices wrt the driver model but do register with the ASoC core and are 'joined' with each other and the sound card driver to form a working audio device. Yes, today I just walk the device tree looking for these connections implicitly. The code may be ugly, but the device tree is more streamlined. Now I don't know the mechanics of adding an ASoC sound card to the device tree, but the device tree should be able to define an ASoC sound card and also represent the relationships between the sound card and the SSI/Codec/DMA components. The components should also be represented in the device tree. Parsing the device tree should probe() all the ASoC components and sound card. The ASoC core would then instantiated them as a sound device. Another problem is that ASoC won't let me probe the DMA channels independently. That is, I cannot tell ASoC that I have a playback DMA and a capture DMA. ASoC does not recognize two DMA devices for a single SSI. If you can fix that, then I can turn the DMA driver into an OF driver. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, 2010-04-27 at 09:52 -0500, Timur Tabi wrote: Liam Girdwood wrote: Now I don't know the mechanics of adding an ASoC sound card to the device tree, but the device tree should be able to define an ASoC sound card and also represent the relationships between the sound card and the SSI/Codec/DMA components. The components should also be represented in the device tree. Parsing the device tree should probe() all the ASoC components and sound card. The ASoC core would then instantiated them as a sound device. Another problem is that ASoC won't let me probe the DMA channels independently. That is, I cannot tell ASoC that I have a playback DMA and a capture DMA. ASoC does not recognize two DMA devices for a single SSI. If you can fix that, then I can turn the DMA driver into an OF driver. Iirc, the SSI and DMA controllers on your SoC mean that each DMA device can only do one direction (either Playback or Capture). So I'm thinking we create two DAI link entries for your sound card (one for playback and the other for capture) and they both use the same SSI device but each would have it's own DMA device. This would result in two separate pcm devices being exported to userspace i.e one for playback only and the other for capture only. I think this is also a more accurate representation of your hardware too (since we have different DMA devices for each pcm stream direction). Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
Liam Girdwood wrote: Iirc, the SSI and DMA controllers on your SoC mean that each DMA device can only do one direction (either Playback or Capture). So I'm thinking we create two DAI link entries for your sound card (one for playback and the other for capture) and they both use the same SSI device but each would have it's own DMA device. Do you mean here: machine_data-card.probe = mpc8610_hpcd_machine_probe; machine_data-card.remove = mpc8610_hpcd_machine_remove; machine_data-card.name = MPC8610 HPCD; machine_data-card.num_links = 1; machine_data-card.dai_link = machine_data-dai; So that num_links would be 2 instead of 1? I would need some way for fsl_dma_open() to get a pointer to private, DMA-specific data. I'm not sure how I can do that. This would result in two separate pcm devices being exported to userspace i.e one for playback only and the other for capture only. I think this is also a more accurate representation of your hardware too (since we have different DMA devices for each pcm stream direction). I can say for certain whether that will actually work. My gut tells me that I might run into problems trying to implement that. The only way to know for sure is to start hacking. Unfortunately, my window of opportunity to work on this just closed, and it may not open for a while. I know my current patch is less-than-ideal, but it does restore functionality to the 8610, and without needing any U-Boot or device-tree changes. So unless there are any real objections, I'd like it to be merged. Otherwise, 8610 audio will be broken in the next release. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, Apr 27, 2010 at 10:28 AM, Timur Tabi ti...@freescale.com wrote: I can say for certain whether that will actually work. Ugh, I meant to write, I can't say for certain. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/4] Add USB Host and OTG support for MPC5121 SoC
Anatolij Gustschin (4): powerpc/fsl_soc.c: prepare for addition of mpc5121 USB code powerpc/mpc5121: add USB host support USB: add USB OTG support for MPC5121 SoC powerpc/mpc5121: select options for USB OTG support Documentation/powerpc/dts-bindings/fsl/usb.txt | 22 + arch/powerpc/include/asm/fsl_usb_io.h | 106 +++ arch/powerpc/platforms/512x/Kconfig| 11 + arch/powerpc/platforms/512x/Makefile |2 +- arch/powerpc/platforms/512x/mpc5121_usb.c | 131 +++ arch/powerpc/platforms/512x/mpc512x.h |1 + arch/powerpc/platforms/512x/mpc512x_shared.c |1 + arch/powerpc/sysdev/fsl_soc.c | 249 +++--- arch/powerpc/sysdev/fsl_soc.h |9 + drivers/usb/gadget/fsl_udc_core.c | 357 ++-- drivers/usb/gadget/fsl_usb2_udc.h | 14 + drivers/usb/host/ehci-fsl.c| 372 ++-- drivers/usb/host/ehci-fsl.h| 22 +- drivers/usb/host/ehci-hub.c| 39 + drivers/usb/host/ehci-mem.c|2 +- drivers/usb/host/ehci.h|5 + drivers/usb/otg/Kconfig|8 + drivers/usb/otg/Makefile |2 + drivers/usb/otg/fsl_otg.c | 1199 drivers/usb/otg/fsl_otg.h | 418 + drivers/usb/otg/otg.c | 17 + drivers/usb/otg/otg_fsm.c | 368 drivers/usb/otg/otg_fsm.h | 154 +++ include/linux/fsl_devices.h| 28 + 24 files changed, 3285 insertions(+), 252 deletions(-) create mode 100644 arch/powerpc/include/asm/fsl_usb_io.h create mode 100644 arch/powerpc/platforms/512x/mpc5121_usb.c create mode 100644 drivers/usb/otg/fsl_otg.c create mode 100644 drivers/usb/otg/fsl_otg.h create mode 100644 drivers/usb/otg/otg_fsm.c create mode 100644 drivers/usb/otg/otg_fsm.h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/4] powerpc/mpc5121: add USB host support
Platform specific code for MPC5121 USB Host support.
The patch also contains changes to FSL EHCI platform driver
needed to support MPC5121 USB controllers. MPC5121 Rev 2.0
silicon EHCI registers are in big endian format. The
appropriate flags are set using the information in the
platform data structure. 83xx system interface registers
are not available on 512x, so the access to these registers
is isolated for 512x. Furthermore the USB controller clock
must be enabled before 512x register access which is done
by providing platform specific init callback.
The 512x internal USB PHY doesn't provide supply voltage.
For boards using different power switches allow specifying
DRVVBUS and PWR_FAULT signal polarity of the MPC5121 internal
PHY using fsl,invert-drvvbus and fsl,invert-pwr-fault
properties in the device tree USB node.
Signed-off-by: Bruce Schmid d...@freescale.com
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: David Brownell dbrown...@users.sourceforge.net
Cc: Greg Kroah-Hartman gre...@suse.de
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: devicetree-disc...@lists.ozlabs.org
---
Documentation/powerpc/dts-bindings/fsl/usb.txt | 22
arch/powerpc/platforms/512x/Kconfig|3 +
arch/powerpc/platforms/512x/Makefile |2 +-
arch/powerpc/platforms/512x/mpc5121_usb.c | 131
arch/powerpc/platforms/512x/mpc512x.h |1 +
arch/powerpc/platforms/512x/mpc512x_shared.c |1 +
arch/powerpc/sysdev/fsl_soc.c | 20
arch/powerpc/sysdev/fsl_soc.h |9 ++
drivers/usb/host/ehci-fsl.c| 111 +++--
drivers/usb/host/ehci-fsl.h| 19 -
drivers/usb/host/ehci-mem.c|2 +-
include/linux/fsl_devices.h| 13 +++
12 files changed, 301 insertions(+), 33 deletions(-)
create mode 100644 arch/powerpc/platforms/512x/mpc5121_usb.c
diff --git a/Documentation/powerpc/dts-bindings/fsl/usb.txt
b/Documentation/powerpc/dts-bindings/fsl/usb.txt
index b001524..bd5723f 100644
--- a/Documentation/powerpc/dts-bindings/fsl/usb.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/usb.txt
@@ -8,6 +8,7 @@ and additions :
Required properties :
- compatible : Should be fsl-usb2-mph for multi port host USB
controllers, or fsl-usb2-dr for dual role USB controllers
+ or fsl,mpc5121-usb2-dr for dual role USB controllers of MPC5121
- phy_type : For multi port host USB controllers, should be one of
ulpi, or serial. For dual role USB controllers, should be
one of ulpi, utmi, utmi_wide, or serial.
@@ -33,6 +34,12 @@ Recommended properties :
- interrupt-parent : the phandle for the interrupt controller that
services interrupts for this device.
+Optional properties :
+ - fsl,invert-drvvbus : boolean; for MPC5121 USB0 only. Indicates the
+ port power polarity of internal PHY signal DRVVBUS is inverted.
+ - fsl,invert-pwr-fault : boolean; for MPC5121 USB0 only. Indicates
+ the PWR_FAULT signal polarity is inverted.
+
Example multi port host USB controller device node :
u...@22000 {
compatible = fsl-usb2-mph;
@@ -57,3 +64,18 @@ Example dual role USB controller device node :
dr_mode = otg;
phy = ulpi;
};
+
+Example dual role USB controller device node for MPC5121ADS:
+
+ u...@4000 {
+ compatible = fsl,mpc5121-usb2-dr;
+ reg = 0x4000 0x1000;
+ #address-cells = 1;
+ #size-cells = 0;
+ interrupt-parent = ipic ;
+ interrupts = 44 0x8;
+ dr_mode = otg;
+ phy_type = utmi_wide;
+ fsl,invert-drvvbus;
+ fsl,invert-pwr-fault;
+ };
diff --git a/arch/powerpc/platforms/512x/Kconfig
b/arch/powerpc/platforms/512x/Kconfig
index 4dac9b0..fed7b5d 100644
--- a/arch/powerpc/platforms/512x/Kconfig
+++ b/arch/powerpc/platforms/512x/Kconfig
@@ -9,6 +9,9 @@ config PPC_MPC512x
config PPC_MPC5121
bool
select PPC_MPC512x
+ select USB_ARCH_HAS_EHCI
+ select USB_EHCI_BIG_ENDIAN_DESC
+ select USB_EHCI_BIG_ENDIAN_MMIO
config MPC5121_ADS
bool Freescale MPC5121E ADS
diff --git a/arch/powerpc/platforms/512x/Makefile
b/arch/powerpc/platforms/512x/Makefile
index 90be2f5..49adabc 100644
--- a/arch/powerpc/platforms/512x/Makefile
+++ b/arch/powerpc/platforms/512x/Makefile
@@ -1,6 +1,6 @@
#
# Makefile for the Freescale PowerPC 512x linux kernel.
#
-obj-y += clock.o mpc512x_shared.o
+obj-y += clock.o mpc512x_shared.o mpc5121_usb.o
obj-$(CONFIG_MPC5121_ADS) += mpc5121_ads.o mpc5121_ads_cpld.o
obj-$(CONFIG_MPC5121_GENERIC) += mpc5121_generic.o
diff --git a/arch/powerpc/platforms/512x/mpc5121_usb.c
b/arch/powerpc/platforms/512x/mpc5121_usb.c
new file mode 100644
index 000..33ac812
[PATCH 1/4] powerpc/fsl_soc.c: prepare for addition of mpc5121 USB code
Factor out common code for registering a FSL EHCI platform
device into new fsl_usb2_register_device() function. This
is done to avoid code duplication while adding code for
instantiating of MPC5121 dual role USB platform devices.
Then, the subsequent patch can use
for_each_compatible_node(np, NULL, fsl,mpc5121-usb2-dr) {
...
fsl_usb2_register_device();
}
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: Grant Likely grant.lik...@secretlab.ca
---
arch/powerpc/sysdev/fsl_soc.c | 231 +++-
1 files changed, 110 insertions(+), 121 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index b91f7ac..976218c 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -209,6 +209,49 @@ static int __init of_add_fixed_phys(void)
arch_initcall(of_add_fixed_phys);
#endif /* CONFIG_FIXED_PHY */
+struct fsl_usb2_dev_data {
+ char *dr_mode; /* controller mode */
+ char *drivers[3]; /* drivers to instantiate for this mode */
+ enum fsl_usb2_operating_modes op_mode; /* operating mode */
+};
+
+struct fsl_usb2_dev_data dr_data[] __initdata = {
+ {
+ host,
+ { fsl-ehci, NULL, NULL, },
+ FSL_USB2_DR_HOST,
+ },
+ {
+ otg,
+ { fsl-ehci, fsl-usb2-udc, fsl-usb2-otg, },
+ FSL_USB2_DR_OTG,
+ },
+ {
+ periferal,
+ { fsl-usb2-udc, NULL, NULL, },
+ FSL_USB2_DR_DEVICE,
+ },
+};
+
+struct fsl_usb2_dev_data mph_data[] __initdata = {
+ { NULL, { fsl-ehci, NULL, }, FSL_USB2_MPH_HOST, },
+};
+
+struct fsl_usb2_dev_data * __init get_dr_data(struct device_node *np)
+{
+ const unsigned char *prop;
+ int i;
+
+ prop = of_get_property(np, dr_mode, NULL);
+ if (prop) {
+ for (i = 0; i ARRAY_SIZE(dr_data); i++) {
+ if (!strcmp(prop, dr_data[i].dr_mode))
+ return dr_data[i];
+ }
+ }
+ return dr_data[0]; /* mode not specified, use host */
+}
+
static enum fsl_usb2_phy_modes determine_usb_phy(const char *phy_type)
{
if (!phy_type)
@@ -225,151 +268,97 @@ static enum fsl_usb2_phy_modes determine_usb_phy(const
char *phy_type)
return FSL_USB2_PHY_NONE;
}
-static int __init fsl_usb_of_init(void)
+int __init fsl_usb2_register_device(struct device_node *np,
+ struct fsl_usb2_dev_data *dev_data,
+ struct fsl_usb2_platform_data *pdata,
+ unsigned int idx)
{
- struct device_node *np;
- unsigned int i = 0;
- struct platform_device *usb_dev_mph = NULL, *usb_dev_dr_host = NULL,
- *usb_dev_dr_client = NULL;
+ struct platform_device *usb_dev;
+ const unsigned char *prop;
+ struct resource r[2];
+ int registered = 0;
int ret;
+ int i;
+
+ if (!(dev_data pdata))
+ return -EINVAL;
+
+ memset(r, 0, sizeof(r));
+ ret = of_address_to_resource(np, 0, r[0]);
+ if (ret)
+ return -ENODEV;
+
+ ret = of_irq_to_resource(np, 0, r[1]);
+ if (ret == NO_IRQ)
+ return -ENODEV;
+
+ pdata-operating_mode = dev_data-op_mode;
+
+ prop = of_get_property(np, phy_type, NULL);
+ pdata-phy_mode = determine_usb_phy(prop);
+ ret = 0;
+ for (i = 0; i ARRAY_SIZE(dev_data-drivers); i++) {
+ if (!dev_data-drivers[i])
+ break;
+ usb_dev = platform_device_register_simple(
+ dev_data-drivers[i], idx, r, 2);
+ if (IS_ERR(usb_dev)) {
+ ret = PTR_ERR(usb_dev);
+ goto out;
+ }
- for_each_compatible_node(np, NULL, fsl-usb2-mph) {
- struct resource r[2];
- struct fsl_usb2_platform_data usb_data;
- const unsigned char *prop = NULL;
-
- memset(r, 0, sizeof(r));
- memset(usb_data, 0, sizeof(usb_data));
-
- ret = of_address_to_resource(np, 0, r[0]);
+ usb_dev-dev.coherent_dma_mask = 0xUL;
+ usb_dev-dev.dma_mask = usb_dev-dev.coherent_dma_mask;
+ ret = platform_device_add_data(usb_dev, pdata,
+ sizeof(struct fsl_usb2_platform_data));
if (ret)
- goto err;
-
- of_irq_to_resource(np, 0, r[1]);
-
- usb_dev_mph =
- platform_device_register_simple(fsl-ehci, i, r, 2);
- if (IS_ERR(usb_dev_mph)) {
- ret = PTR_ERR(usb_dev_mph);
- goto err;
- }
+
[PATCH 4/4] powerpc/mpc5121: select options for USB OTG support
USB Device Controller driver and OTG driver allow configuration of controller register accessors. Enable default big-endian register accessors for Rev.2 SoC. Signed-off-by: Anatolij Gustschin ag...@denx.de Cc: Grant Likely grant.lik...@secretlab.ca --- arch/powerpc/platforms/512x/Kconfig |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/platforms/512x/Kconfig b/arch/powerpc/platforms/512x/Kconfig index fed7b5d..0c42537 100644 --- a/arch/powerpc/platforms/512x/Kconfig +++ b/arch/powerpc/platforms/512x/Kconfig @@ -12,6 +12,14 @@ config PPC_MPC5121 select USB_ARCH_HAS_EHCI select USB_EHCI_BIG_ENDIAN_DESC select USB_EHCI_BIG_ENDIAN_MMIO + select USB_FSL_BIG_ENDIAN_DESC + select USB_FSL_BIG_ENDIAN_MMIO + +config USB_FSL_BIG_ENDIAN_MMIO + bool + +config USB_FSL_BIG_ENDIAN_DESC + bool config MPC5121_ADS bool Freescale MPC5121E ADS -- 1.6.3.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [RFC] Xilinx MPMC SDMA subsystem
On Tuesday 20 April 2010 20:29:55 Steven J. Magnani wrote: Hi Sergey, I've only just started using this in earnest, sorry for not getting back to you sooner. It's a nice encapsulation of the MPMC/SDMA functionality, thanks for posting it. In order to integrate this into my system, I refactored the bus attachment code and added hooks for platform bus. I also removed some dead code, reformatted some things to satisfy checkpatch, tweaked #includes to fix Microblaze compilation, and fixed a potential bug where sdma_set_coalesce() could return without releasing a spinlock. I also optimized the sdma_desc_* functions by moving any byte swapping from runtime to compile-time. Well, it looks good. Some more controversial changes / items for discussion: 1. I dropped setting the tail descriptor in the sdma_[rt]x_init() functions since that would start DMA, which is not what I think we want. Needs some testing, I think. Back in 2008, AFAIR, I've had some problems with this approach, but I don't remember exactly if it was the cause. 2. I made RX and TX interrupts optional. There are use cases (DMAing while atomic) in which interrupts are not necessary. The DMA engine only needs RX interrupts. There is an (obscure) mode in which it might also want TX interrupts, and in that case it's only interested in error interrupts - normal done interrupts are of no interest whatsoever. Rather than try to adapt the sdma driver to fit that case, I think I will drop that mode from the DMA engine driver. Looks good too. 2A. I will need, but haven't added yet, methods to know if a SDMA channel has RX and TX IRQ resources. I'm assuming that a simple inline accessor is preferred over snooping struct sdma directly. I would suggest sdma_has_[r|t]x(). 3. I changed the user[4] field of struct sdma_desc to individually-named fields app1 - app4, to match the MPMC datasheet. I found user[0] confusing and already had to fix a bug where I had coded user[0] thinking it was app0, when I really should have specified stat_ctl. It doesn't really matter as these fields have different meaning in different applications and one has to decode it appropriately. If it helps to write more understandable code, so be it. 4. Why have sdma_[rt]x_submit() return a value if it is always zero? I don't remember exactly why I've coded this, but now I think that return value isn't needed for these functions too. 5. I would like to see the 'virt' and 'flags' fields removed from struct sdma_desc and SDMA_ALIGNMENT reduced from 0x40 to 0x20. Neither field is used in the sdma driver itself. I understand why 'virt' is there, but having it in the struct will make the DMA engine driver less efficient. Because the DMA engine operates on 'loopback' SDMA channels it always allocates descriptors in pairs. Also the DMA engine framework already provides storage for the 'virt' pointer. Having a larger-than-necessary structure would force the DMA engine to do larger allocations from its DMA pool - instead of 64 bytes per dual descriptor, it would have to allocate 128. The 'virt' and 'flags' fields are there specially for users. The 'virt' is intended for the pointer to the structure associated with the buffer (maybe, 'virt' should be called 'priv' instead), and 'flags' is there to determine which data type 'virt' is pointing to. 6. I'm concerned that there is no concept of allocating a channel, something like a sdma_device_get() / sdma_device_put() pair that would prevent concurrent access to a SDMA device by removing the device from consideration by sdma_find_device(). 7. In that same vein, I'm curious about the need for a list of sdma_clients. Is there a use case for this in your systems? I've added the list of clients rather recently to support several of my drivers which implement the separate descriptor rings and char devices for RX and TX (there are some custom IP cores for DSP developed by our company which need this functionality). 8. It would probably make sense to have sdma_init() fail with -EEXIST if a SDMA device with the specified phandle already exists (-1 being an exception). Maybe this check is needed but 'linux,phandle' is an automatic property added by the device tree compiler and I doubt that the FDT code with invalid phandles will even compile. 9. I didn't resolve the issue of what to name the files / API, assuming 'sdma' is a little too generic for things that are now publicly visible. If we have to change it, some suggestions are 'mpmcsdma' (long, but precise), 'xildma', 'xsdma', or 'xdma' (also perhaps too generic). Maybe, 'xllsdma' would be good. As time permits, I'll work on refactoring the DMA engine driver to use the sdma driver - I'll post change requests for anything else I need rather than modifying the sdma code directly. Feel free to contact me directly or through the mailing list. Regards,
[RFC Patch 0/1] [hw-bkpt BookE] hw-breakpoint interfaces for BookE - ver I
Hi All, Please find a patch that implements hardware-breakpoint interfaces for BookE processors. The patches are under continuous development and are sent to receive early comments. For the moment, they are (only) compile tested (with ppc64e_defconfig), further testing will accompany the ongoing development. A few notes about the patchset, as below: - The patch is designed with reference to BookIII-E type processors specification (having two DAC/DVC registers). - Instruction breakpoint requests are not implemented through the generic breakpoint interfaces. Such requests are still possible for user-space through ptrace. - Breakpoint exceptions are designed to 'trigger-after-execute', although the processors raise the exception before instruction execution. To achieve this, the causative insruction is single-stepped over and the breakpoint handler is invoked in the ICMP exception handler. - The patches are dependant on the recent submissions (not yet integrated into mainline) that bring support for hw-breakpoint weight (patchset from Frederic Weisbecker LKML ref:1271999639-23605-1-git-send-regression-fweis...@gmail.com) and PPC64 hw-breakpoint support (linuxppc-dev ref:20100414034340.ga6...@in.ibm.com). Here are a few items identified to work upon in the successive versions. TO DO -- - Modify ptrace requests to use the generic hw-breakpoint interfaces (PTRACE_GETSET_DEBUGREG, PTRACE_SETHWDEBUG) - Explore intergration of BookE and BookS code intergration (hw_breakpoint.c and hw_breakpoint_booke.c) - Code clean-up and reduction. Kindly let me know about comments/suggestions, if any. Thank You, K.Prasad ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC Patch 1/1] Implement hw-breakpoint interfaces for BookE processors
Implement hardware breakpoint interfaces for PowerPC BookE processors
Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com
---
arch/powerpc/Kconfig |2
arch/powerpc/include/asm/cputable.h|4
arch/powerpc/include/asm/hw_breakpoint_booke.h | 42 +++
arch/powerpc/kernel/Makefile |4
arch/powerpc/kernel/hw_breakpoint_booke.c | 326 +
arch/powerpc/kernel/ptrace.c |8
arch/powerpc/kernel/traps.c| 11
include/linux/perf_event.h |4
8 files changed, 398 insertions(+), 3 deletions(-)
Index: linux-2.6.bookE/arch/powerpc/include/asm/hw_breakpoint_booke.h
===
--- /dev/null
+++ linux-2.6.bookE/arch/powerpc/include/asm/hw_breakpoint_booke.h
@@ -0,0 +1,42 @@
+#ifndef_I386_HW_BREAKPOINT_H
+#define_I386_HW_BREAKPOINT_H
+
+#ifdef __KERNEL__
+#define__ARCH_HW_BREAKPOINT_H
+
+struct arch_hw_breakpoint {
+ u8 len;
+ unsigned long address;
+ unsigned long type;
+};
+
+#include linux/kdebug.h
+#include linux/percpu.h
+#include linux/list.h
+
+/* Breakpoint length beyond which we should use 'range' breakpoints */
+#define DAC_LEN 8
+
+static inline int hw_breakpoint_slots(int type)
+{
+ return HBP_NUM;
+}
+
+struct perf_event;
+struct pmu;
+
+extern int arch_check_bp_in_kernelspace(struct perf_event *bp);
+extern int arch_validate_hwbkpt_settings(struct perf_event *bp);
+extern int hw_breakpoint_exceptions_notify(struct notifier_block *unused,
+ unsigned long val, void *data);
+extern void hw_breakpoint_handler(struct pt_regs *regs,
+ unsigned long debug_status);
+int arch_install_hw_breakpoint(struct perf_event *bp);
+void arch_uninstall_hw_breakpoint(struct perf_event *bp);
+void hw_breakpoint_pmu_read(struct perf_event *bp);
+
+extern struct pmu perf_ops_bp;
+
+#endif /* __KERNEL__ */
+#endif /* _I386_HW_BREAKPOINT_H */
+
Index: linux-2.6.bookE/arch/powerpc/kernel/hw_breakpoint_booke.c
===
--- /dev/null
+++ linux-2.6.bookE/arch/powerpc/kernel/hw_breakpoint_booke.c
@@ -0,0 +1,326 @@
+#include linux/perf_event.h
+#include linux/hw_breakpoint.h
+#include linux/notifier.h
+#include linux/percpu.h
+#include linux/kprobes.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/sched.h
+#include linux/init.h
+#include linux/smp.h
+
+#include asm/hw_breakpoint_booke.h
+#include asm/reg_booke.h
+#include asm/reg.h
+
+/*
+ * Store the 'bp' that caused the hw-breakpoint exception just before we
+ * single-step. Use it to distinguish a single-step exception (due to a
+ * previous hw-breakpoint exception) from a normal one
+ */
+static DEFINE_PER_CPU(struct perf_event *, last_hit_bp);
+
+/*
+ * Save the debug registers to restore them after single-stepping the
+ * instruction that caused the debug exception
+ */
+static DEFINE_PER_CPU(unsigned long, last_hit_dac[2]);
+static DEFINE_PER_CPU(unsigned long, last_hit_dbcr0);
+
+/*
+ * Stores the breakpoints currently in use on each breakpoint address
+ * register for each cpus
+ */
+static DEFINE_PER_CPU(struct perf_event *, bp_per_reg[HBP_NUM]);
+
+int hw_breakpoint_weight(struct perf_event *bp)
+{
+ return (bp-attr.bp_len DAC_LEN) ? 2 : 1;
+}
+
+/*
+ * Install a perf counter breakpoint.
+ *
+ * We seek a free debug address register and use it for this
+ * breakpoint. Eventually we enable it in the debug control register.
+ *
+ * Atomic: we hold the counter-ctx-lock and we only handle variables
+ * and registers local to this cpu.
+ */
+int arch_install_hw_breakpoint(struct perf_event *bp)
+{
+ bool range_bp;
+ int i;
+ struct arch_hw_breakpoint *info = counter_arch_bp(bp);
+ unsigned long dbcr0 = mfspr(SPRN_DBCR0);
+
+ range_bp = (info-len DAC_LEN) ? true : false;
+ for (i = 0; i HBP_NUM; i++) {
+ struct perf_event **slot = __get_cpu_var(bp_per_reg[i]);
+
+ if (*slot)
+ continue;
+ *slot = bp;
+ mtspr(SPRN_DAC1, info-address);
+ /* Clean the 'type' fields to erase past values */
+ dbcr0 = ~(DBCR0_DAC2W | DBCR0_DAC2R);
+
+ mtspr(SPRN_DBCR0, dbcr0 |
+ (info-type (HBP_NUM - i)) | DBCR0_IDM);
+ /*
+* Use DAC2 register in 'range' mode if the length of the
+* breakpoint request is 'large'
+*/
+ if (unlikely(range_bp)) {
+ if (i (HBP_NUM - hw_breakpoint_weight(bp))) {
+ *slot = NULL;
+ mtspr(SPRN_DBCR0, dbcr0);
+ return -EBUSY;
+ }
+
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, 2010-04-27 at 10:28 -0500, Timur Tabi wrote: Liam Girdwood wrote: Iirc, the SSI and DMA controllers on your SoC mean that each DMA device can only do one direction (either Playback or Capture). So I'm thinking we create two DAI link entries for your sound card (one for playback and the other for capture) and they both use the same SSI device but each would have it's own DMA device. Do you mean here: machine_data-card.probe = mpc8610_hpcd_machine_probe; machine_data-card.remove = mpc8610_hpcd_machine_remove; machine_data-card.name = MPC8610 HPCD; machine_data-card.num_links = 1; machine_data-card.dai_link = machine_data-dai; So that num_links would be 2 instead of 1? Yes. I would need some way for fsl_dma_open() to get a pointer to private, DMA-specific data. I'm not sure how I can do that. In multi-component we now have platform_data and device private data (from the regular driver model). We also have stream snd_soc_dai_set_dma_data() for runtime DMA config. So it depends on who is setting your DMA data. If it's DTS then it would be the of_ platform equivalent, if it's your DMA probe() then dev data otherwise you can use the snd_soc_dai_set_dma_data(). This would result in two separate pcm devices being exported to userspace i.e one for playback only and the other for capture only. I think this is also a more accurate representation of your hardware too (since we have different DMA devices for each pcm stream direction). I can say for certain whether that will actually work. My gut tells me that I might run into problems trying to implement that. The only way to know for sure is to start hacking. Unfortunately, my window of opportunity to work on this just closed, and it may not open for a while. I know my current patch is less-than-ideal, but it does restore functionality to the 8610, and without needing any U-Boot or device-tree changes. So unless there are any real objections, I'd like it to be merged. Otherwise, 8610 audio will be broken in the next release. Ok, I can live with this providing we can mark it as a TODO: and have a PPC Ack. It may be easier to fix in the future too as the ASoC card registration clean-up should be complete/in-progress (i.e. card platform_data and private_data will be available for passing in anything you like). Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] powerpc/fsl_soc.c: prepare for addition of mpc5121 USB code
On Tue, Apr 27, 2010 at 10:11 AM, Anatolij Gustschin ag...@denx.de wrote:
Factor out common code for registering a FSL EHCI platform
device into new fsl_usb2_register_device() function. This
is done to avoid code duplication while adding code for
instantiating of MPC5121 dual role USB platform devices.
Then, the subsequent patch can use
for_each_compatible_node(np, NULL, fsl,mpc5121-usb2-dr) {
...
fsl_usb2_register_device();
}
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: Grant Likely grant.lik...@secretlab.ca
---
arch/powerpc/sysdev/fsl_soc.c | 231 +++-
Hi Anatolij,
Thanks for this work. However, I've got concerns.
Forgive me for ragging on code that you didn't write, but this
fsl_soc.c code for registering the USB device really doesn't belong
here anymore. It should be part of the drivers/usb/host/ehci-fsl.c
and the driver should do of-style binding (Which should be a lot
easier if I manage to get the merge of platform bus and of_platform
bus into 2.6.35).
This patch series makes the fsl_soc.c code even more complicated, and
scatters what is essentially driver code over even more places in the
arch/powerpc tree. I'm really not keen on it being merged in this
form.
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] USB: add USB OTG support for MPC5121 SoC
Hi Anatolij,
I haven't looked deeply, but I've written a couple of minor comments below.
g.
On Tue, Apr 27, 2010 at 10:11 AM, Anatolij Gustschin ag...@denx.de wrote:
Adds Freescale USB OTG driver and extends Freescale
USB SoC Device Controller driver and FSL EHCI driver
to support OTG operation on MPC5121.
Signed-off-by: Li Yang le...@freescale.com
Signed-off-by: Bruce Schmid d...@freescale.com
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: Greg Kroah-Hartman gre...@suse.de
Cc: David Brownell dbrown...@users.sourceforge.net
Cc: Grant Likely grant.lik...@secretlab.ca
---
arch/powerpc/include/asm/fsl_usb_io.h | 106 +++
drivers/usb/gadget/fsl_udc_core.c | 357 --
drivers/usb/gadget/fsl_usb2_udc.h | 14 +
drivers/usb/host/ehci-fsl.c | 261 +++-
drivers/usb/host/ehci-fsl.h | 3 +
drivers/usb/host/ehci-hub.c | 39 ++
drivers/usb/host/ehci.h | 5 +
drivers/usb/otg/Kconfig | 8 +
drivers/usb/otg/Makefile | 2 +
drivers/usb/otg/fsl_otg.c | 1199
+
drivers/usb/otg/fsl_otg.h | 418
drivers/usb/otg/otg.c | 17 +
drivers/usb/otg/otg_fsm.c | 368 ++
drivers/usb/otg/otg_fsm.h | 154 +
include/linux/fsl_devices.h | 15 +
15 files changed, 2867 insertions(+), 99 deletions(-)
create mode 100644 arch/powerpc/include/asm/fsl_usb_io.h
create mode 100644 drivers/usb/otg/fsl_otg.c
create mode 100644 drivers/usb/otg/fsl_otg.h
create mode 100644 drivers/usb/otg/otg_fsm.c
create mode 100644 drivers/usb/otg/otg_fsm.h
diff --git a/arch/powerpc/include/asm/fsl_usb_io.h
b/arch/powerpc/include/asm/fsl_usb_io.h
new file mode 100644
index 000..20c42ef
--- /dev/null
+++ b/arch/powerpc/include/asm/fsl_usb_io.h
@@ -0,0 +1,106 @@
+/* Copyright (c) 2008 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#ifndef _FSL_USB_IO_H
+#define _FSL_USB_IO_H
+
+/*
+ * On some SoCs, the USB controller registers can be big or little endian,
+ * depending on the version of the chip. For these SoCs, the kernel
+ * should be configured with CONFIG_USB_FSL_BIG_ENDIAN_MMIO enabled.
+ *
+ * Platform code for SoCs that have BE USB registers should set
+ * pdata-big_endian_mmio flag.
+ *
+ * In order to be able to run the same kernel binary on 2 different
+ * versions of an SoC, the BE/LE decision must be made at run time.
+ * _fsl_readl and fsl_writel are pointers to the BE or LE readl()
+ * and writel() functions, and fsl_readl() and fsl_writel() call through
+ * those pointers.
+ *
+ * For SoCs with the usual LE USB registers, don't enable
+ * CONFIG_USB_FSL_BIG_ENDIAN_MMIO, and then fsl_readl() and fsl_writel()
+ * are just macro wrappers for in_le32() and out_le32().
+ *
+ * In either (LE or mixed) case, the function fsl_set_usb_accessors()
+ * should be called at probe time, to either set up the readl/writel
+ * function pointers (mixed case), or do nothing (LE case).
+ *
+ * The host USB drivers already have a mechanism to handle BE/LE
+ * registers. The functionality here is intended to be used by the
+ * gadget and OTG transceiver drivers.
+ *
+ * This file also contains controller-to-cpu accessors for the
+ * USB descriptors, since their endianess is also SoC dependant.
+ * The kernel option CONFIG_USB_FSL_BIG_ENDIAN_DESC configures
+ * which way to go.
+ */
+
+#ifdef CONFIG_USB_FSL_BIG_ENDIAN_MMIO
+static u32 __maybe_unused _fsl_readl_be(const unsigned __iomem *p)
+{
+ return in_be32(p);
+}
+static u32 __maybe_unused _fsl_readl_le(const unsigned __iomem *p)
+{
+ return in_le32(p);
+}
+
+static void __maybe_unused _fsl_writel_be(u32 v, unsigned __iomem *p)
+{
+ out_be32(p, v);
+}
+static void __maybe_unused _fsl_writel_le(u32 v, unsigned __iomem *p)
+{
+ out_le32(p, v);
+}
+
+static u32 (*_fsl_readl)(const unsigned __iomem *p);
+static void (*_fsl_writel)(u32 v, unsigned __iomem *p);
statics defined in a header file? That doesn't look right. These
dynamic accessors probably need to be defined in a .c file and linked
to the rest of the driver code.
It is
Re: [PATCH 2/4] powerpc/mpc5121: add USB host support
On Tue, Apr 27, 2010 at 10:11 AM, Anatolij Gustschin ag...@denx.de wrote:
Platform specific code for MPC5121 USB Host support.
The patch also contains changes to FSL EHCI platform driver
needed to support MPC5121 USB controllers. MPC5121 Rev 2.0
silicon EHCI registers are in big endian format. The
appropriate flags are set using the information in the
platform data structure. 83xx system interface registers
are not available on 512x, so the access to these registers
is isolated for 512x. Furthermore the USB controller clock
must be enabled before 512x register access which is done
by providing platform specific init callback.
The 512x internal USB PHY doesn't provide supply voltage.
For boards using different power switches allow specifying
DRVVBUS and PWR_FAULT signal polarity of the MPC5121 internal
PHY using fsl,invert-drvvbus and fsl,invert-pwr-fault
properties in the device tree USB node.
Signed-off-by: Bruce Schmid d...@freescale.com
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: David Brownell dbrown...@users.sourceforge.net
Cc: Greg Kroah-Hartman gre...@suse.de
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: devicetree-disc...@lists.ozlabs.org
---
Documentation/powerpc/dts-bindings/fsl/usb.txt | 22
arch/powerpc/platforms/512x/Kconfig | 3 +
arch/powerpc/platforms/512x/Makefile | 2 +-
arch/powerpc/platforms/512x/mpc5121_usb.c | 131
arch/powerpc/platforms/512x/mpc512x.h | 1 +
arch/powerpc/platforms/512x/mpc512x_shared.c | 1 +
arch/powerpc/sysdev/fsl_soc.c | 20
arch/powerpc/sysdev/fsl_soc.h | 9 ++
drivers/usb/host/ehci-fsl.c | 111 +++--
drivers/usb/host/ehci-fsl.h | 19 -
drivers/usb/host/ehci-mem.c | 2 +-
include/linux/fsl_devices.h | 13 +++
12 files changed, 301 insertions(+), 33 deletions(-)
create mode 100644 arch/powerpc/platforms/512x/mpc5121_usb.c
diff --git a/Documentation/powerpc/dts-bindings/fsl/usb.txt
b/Documentation/powerpc/dts-bindings/fsl/usb.txt
index b001524..bd5723f 100644
--- a/Documentation/powerpc/dts-bindings/fsl/usb.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/usb.txt
@@ -8,6 +8,7 @@ and additions :
Required properties :
- compatible : Should be fsl-usb2-mph for multi port host USB
controllers, or fsl-usb2-dr for dual role USB controllers
+ or fsl,mpc5121-usb2-dr for dual role USB controllers of MPC5121
- phy_type : For multi port host USB controllers, should be one of
ulpi, or serial. For dual role USB controllers, should be
one of ulpi, utmi, utmi_wide, or serial.
@@ -33,6 +34,12 @@ Recommended properties :
- interrupt-parent : the phandle for the interrupt controller that
services interrupts for this device.
+Optional properties :
+ - fsl,invert-drvvbus : boolean; for MPC5121 USB0 only. Indicates the
+ port power polarity of internal PHY signal DRVVBUS is inverted.
+ - fsl,invert-pwr-fault : boolean; for MPC5121 USB0 only. Indicates
+ the PWR_FAULT signal polarity is inverted.
+
Example multi port host USB controller device node :
...@22000 {
compatible = fsl-usb2-mph;
@@ -57,3 +64,18 @@ Example dual role USB controller device node :
dr_mode = otg;
phy = ulpi;
};
+
+Example dual role USB controller device node for MPC5121ADS:
+
+ u...@4000 {
+ compatible = fsl,mpc5121-usb2-dr;
+ reg = 0x4000 0x1000;
+ #address-cells = 1;
+ #size-cells = 0;
+ interrupt-parent = ipic ;
+ interrupts = 44 0x8;
+ dr_mode = otg;
+ phy_type = utmi_wide;
+ fsl,invert-drvvbus;
+ fsl,invert-pwr-fault;
+ };
This modification to the device binding looks fine to me.
Cheers,
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
Liam Girdwood wrote: I would need some way for fsl_dma_open() to get a pointer to private, DMA-specific data. I'm not sure how I can do that. In multi-component we now have platform_data and device private data (from the regular driver model). In that case, I still have the same problem with how to generate an 'id' based on a device tree node. We have the idea of a 'phandle', which is a unique integer for a node, but there's no way to create phandles from within Linux. They have to exist in the DTS first, and I'm loathe to modify the DTS. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, Apr 27, 2010 at 12:32 PM, Timur Tabi ti...@freescale.com wrote: Liam Girdwood wrote: I would need some way for fsl_dma_open() to get a pointer to private, DMA-specific data. I'm not sure how I can do that. In multi-component we now have platform_data and device private data (from the regular driver model). In that case, I still have the same problem with how to generate an 'id' based on a device tree node. We have the idea of a 'phandle', which is a unique integer for a node, but there's no way to create phandles from within Linux. They have to exist in the DTS first, and I'm loathe to modify the DTS. Can you not dynamically assign an id? If alsa soc needs a unique id number, then just create a lookup function. Something like of_asoc_phandle_to_codec_id() that will either return a previously assigned id, or will assign a new id. You shouldn't ever need to add data to the tree at runtime. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Mon, Apr 26, 2010 at 2:49 PM, Timur Tabi ti...@freescale.com wrote: An upcoming change in the architecture of ALSA SoC (ASoC) will require the MPC8610 HPCD's ASoC fabric driver to register as a standard platform driver. Therefore, we need to call platform_device_register_simple() from the board's platform code. Signed-off-by: Timur Tabi ti...@freescale.com --- Kumar, the ASoC mainters are willing to pick up this patch, but they want an ACK from you first. Or, you could pick it up, since by itself it's harmless. arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c index 5abe137..66afff3 100644 --- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c +++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c @@ -98,6 +98,9 @@ static int __init mpc8610_declare_of_platform_devices(void) /* Without this call, the SSI device driver won't get probed. */ of_platform_bus_probe(NULL, mpc8610_ids, NULL); + /* Register the platform device for the ASoC fabric driver */ + platform_device_register_simple(snd-soc-mpc8610-hpcd, 0, NULL, 0); + Since this is a temporary measure, this device registration is probably best put into the .probe() hook of the i2s driver. That will keep everything contained in the same place until we can hammer out a reasonable binding. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
gianfar driver with realtime patch does not work
I'm trying to get 834x/TSEC gianfar.c working with 2.6.33/RT. when PREEMPT is disabled gianfar driver worked well. if PREEMPT is enabled, especially when PREEMPT_RT is enabled, network(gianfar) will be disconnected in about 2-3 minutes under iperf. In an older version (2.6.18-rt) where NAPI is disabled, gianfar performed well under PREEMPT_RT, in the new version of gianfar, NAPI is enforced(the code is there by default and it's hard to disable NAPI in the code now), also TX COALESCE is enabled while RX COALESCE is disabled. It seems to me NAPI is now by default for Rx and COALESCE is by default for Tx. Both NAPI/COALESCE may have negative effects for real time systems, where latency is more important than throughput. Unfortunately it's hard to disable either of them now after some experiments. Is there anyone here using gianfar with PREEMPT_RT? Do I have to port an older version gianfar to get rid of NAPI at least? Thanks, Xianghua ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
Grant Likely wrote: Can you not dynamically assign an id? If alsa soc needs a unique id number, then just create a lookup function. What I need is something like a hashing function that can convert a struct device_node * into an int. I'm going to have two functions that independently parse the device tree and locate a specific node. Both functions will register the node with asoc, but they'll use an integer ID to uniquely identify the node. At least, that's the way ASoC likes to operate. AsoC takes a fixed string plus a unique integer. I could technically create a unique string for each DMA device, and have the integer always be 0. Something like of_asoc_phandle_to_codec_id() that will either return a previously assigned id, or will assign a new id. You shouldn't ever need to add data to the tree at runtime. I know. It just would have been nice if my nodes already had phandles in them. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
Grant Likely wrote: + /* Register the platform device for the ASoC fabric driver */ + platform_device_register_simple(snd-soc-mpc8610-hpcd, 0, NULL, 0); + Since this is a temporary measure, this device registration is probably best put into the .probe() hook of the i2s driver. That will keep everything contained in the same place until we can hammer out a reasonable binding. This part is not temporary, I think. The fabric driver will always be a standard platform driver, not an OF driver, because there are no DT nodes that it can probe against. BenH is suggestion that maybe we can create one, but I'm not sure that's really the best approach. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, Apr 27, 2010 at 2:07 AM, Liam Girdwood l...@slimlogic.co.uk wrote:
On Tue, 2010-04-27 at 16:36 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2010-04-26 at 15:49 -0500, Timur Tabi wrote:
An upcoming change in the architecture of ALSA SoC (ASoC) will require the
MPC8610 HPCD's ASoC fabric driver to register as a standard platform
driver.
Therefore, we need to call platform_device_register_simple() from the
board's
platform code.
Signed-off-by: Timur Tabi ti...@freescale.com
---
Gross. Loses the linkage to device-tree etc... which is useful for audio
especially. You should at least make sure the device node follows for
the target driver to be able to use it :-) I'd like you to sync with
Grant work on that matter if you are going to convert of_devices into
platform_devices.
Timur, please correct my device tree understanding form our IRC
conversation if I'm wrong here.
I think one of the difficulties encountered here is that the device tree
root for sound in this case is the SSI (Digital Audio Interface)
controller and not the sound card as in ASoC. So maybe the problem is
how do we represent an ASoC sound card in the device tree ?
Most likely this is currently a problem, yes. *however* the device
tree is just data. It is convenient and useful to have a common
representation between similar kinds of devices, but it isn't
mandatory. The device tree structure does *not* need to have a 1:1
correspondence to the ASoC device registrations.
So, the current 86xx device tree binding assumes a simple layout with
a node describing an DAI controller, and another node describing the
codec with a single phandle (pointer) from the DAI to the codec. In
this configuration, it is completely reasonable for the DAI node to
trigger both the instantiation of the ASoC DAI controller device and
the sound card device. Linux can treat them as separate even though
the current device tree has a simplistic representation.
The sound card within ASoC is a compound device that is made up of the
SSI, Codec and audio DMA engine components. The SSI/Codec/DMA components
do not have to be the sound cards child devices wrt the driver model but
do register with the ASoC core and are 'joined' with each other and the
sound card driver to form a working audio device.
Right. This makes sense to me.
Now I don't know the mechanics of adding an ASoC sound card to the
device tree, but the device tree should be able to define an ASoC sound
card and also represent the relationships between the sound card and the
SSI/Codec/DMA components. The components should also be represented in
the device tree. Parsing the device tree should probe() all the ASoC
components and sound card. The ASoC core would then instantiated them as
a sound device.
I've tried very hard to maintain a distinction between device tree
binding (representation) and Linux kernel internal implementation
details. The real question is whether or not the binding provides
sufficient detail for the operating system to figure out what to do.
In the extreme minimalist case, the audio driver could decide how to
configure itself solely on the board name property of the root node.
There is nothing wrong with that, but it also means that no data is
available to dynamically select common modules or modify connections;
it all has to be hard coded.
The 8610 device tree looks something like this right now:
[...]
cs4270:co...@4f {
compatible = cirrus,cs4270;
reg = 0x4f;
/* MCLK source is a stand-alone oscillator */
clock-frequency = 12288000;
};
[...]
s...@16000 {
compatible = fsl,mpc8610-ssi;
[...]
fsl,mode = i2s-slave;
codec-handle = cs4270;
fsl,playback-dma = dma00;
fsl,capture-dma = dma01;
fsl,fifo-depth = 8;
sleep = pmc 0 0x0800;
};
[...]
(I've omitted the DMA nodes and some irrelevant details) This is
enough information for a simplistic driver registration that probably
makes a lot of assumptions. Such as the ssi represents a single
logical sound device. It won't handle complex representations, but in
a lot of cases that may be just fine.
However, as you and Mark rightly point out, it completely fails to
represent complex sound devices with weird clocking and strange
routes. Something like this is probably more appropriate:
[...]
codec1 :co...@4f {
compatible = cirrus,cs4270;
reg = 0x4f;
/* MCLK source is a stand-alone oscillator */
clock-frequency = 12288000;
};
[...]
ssi1: s...@16000 {
compatible = fsl,mpc8610-ssi;
[...]
fsl,mode =
Re: [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, Apr 27, 2010 at 4:09 AM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Tue, 2010-04-27 at 10:54 +0100, Mark Brown wrote: I'd just like to add that I *really* want to see you guys come to some sort of firm and documented conclusion about the way to handle situations like this. Some variant of this seems to come up every single time anyone tries to do anything to do with audio on a system using the device tree and it's getting really repetitive. What would be really useful for audio at this point would be if we could get some sort of decision about how to represent this stuff which we can point people at so that work on systems using the device tree can be done without having to deal with the device tree layout discussions that frequently seem to be involved. Yes, you're right. I completely agree. [...] Keep in mind that it's perfectly kosher to create nodes for virtual devices. IE. We could imagine a node for the sound subsystem that doesn't actually correspond to any physical device but contain the necessary properties that binds everything together. You could even have multiple of these if you have separate set of sound HW that aren't directly dependant. I don't have bandwidth to contribute much in this discussion right now, at least not to lead it, so I'm happy to let others do so, but I'm happy to provide feedback from my own experience as proposals are made. Unfortunately, I'm in the same boat. :-( However, I'll be at UDS in 2 weeks time, and I know audio is a big concern for the Ubuntu folks. A bunch of the ARM vendors will be there too. I'll schedule a session to talk about audio bindings and hopefully that way make some headway on defining a binding that makes sense and is actually useful. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, Apr 27, 2010 at 03:04:33PM -0500, Timur Tabi wrote: [Reflowed into 80 columns] At least, that's the way ASoC likes to operate. AsoC takes a fixed string plus a unique integer. I could technically create a unique string for each DMA device, and have the integer always be 0. This seems like the most direct approach to your problem - as with other subsystems the .id is there mostly to provide deduping when the string is always the same, if you can easily come up with sensible names you can just use those. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
Grant Likely wrote:
So, the current 86xx device tree binding assumes a simple layout with
a node describing an DAI controller, and another node describing the
codec with a single phandle (pointer) from the DAI to the codec. In
this configuration, it is completely reasonable for the DAI node to
trigger both the instantiation of the ASoC DAI controller device and
the sound card device. Linux can treat them as separate even though
the current device tree has a simplistic representation.
The only problem with this is that there is board-specific programming that
needs to be done (look at mpc8610_hpcd_machine_probe), so we still need to have
a fabric driver that is independent of the SSI, codec, or DMA drivers. The
P1022 also has an SSI, and I'm hoping that all I need to do is create a new
fabric driver, not hack up the SSI driver to support board programming.
So if the fabric driver still needs to exist, then it still needs a struct
device, and it still needs to register with asoc. I don't see how I can
register the sound card itself in the SSI driver, because it won't know
anything about the board-specific code in the fabric driver.
I've tried very hard to maintain a distinction between device tree
binding (representation) and Linux kernel internal implementation
details. The real question is whether or not the binding provides
sufficient detail for the operating system to figure out what to do.
I think it does, because it's working today.
In the extreme minimalist case, the audio driver could decide how to
configure itself solely on the board name property of the root node.
There is nothing wrong with that, but it also means that no data is
available to dynamically select common modules or modify connections;
it all has to be hard coded.
Well, asoc already has several hard-coded requirements:
machine_data-dai.cpu_dai_drv = fsl_ssi_dai;
machine_data-dai.codec_dai_drv = cs4270_dai;
machine_data-dai.codec_drv = soc_codec_device_cs4270;
machine_data-dai.ops = mpc8610_hpcd_ops;
machine_data-dai.platform_drv = fsl_soc_platform;
So even though I probe for each device separately and register them separately,
the fabric driver still needs to have hard-coded addresses
Maybe the asoc guys can tell me why I need to register the cpu_dai_drv
structure via platform_device_add(), when it's already being registered via
snd_soc_register_dai().
(I've omitted the DMA nodes and some irrelevant details) This is
enough information for a simplistic driver registration that probably
makes a lot of assumptions. Such as the ssi represents a single
logical sound device. It won't handle complex representations, but in
a lot of cases that may be just fine.
Why would I ever represent the SSI as anything but a single logical sound
device? Let ALSA handle synchronizing multiple streams together if it wants to.
sound {
compatible = fsl,mpc8610-hpcd-sound;
/* maybe something like (totally off the top of my head) */
dai-links = ssi1 0 codec 0
ssi1 1 codec 1;
[...]
};
I don't know when I would ever do this. The two SSI devices are completely
independent. Why would I bind them together into one device?
Where the 'sound' node is now the starting point for representing a
logical sound device instead of the ssi node. This binding probably
makes more sense (but I'm not committing to anything like this until I
see a real proposal for a real device).
The only issue I have with this is all it does is turn the fabric driver from a
platform driver that scans the OF tree, into an OF driver that still needs to
query the device tree to get all the data it needs. For example, the fabric
driver still needs to know the clock frequency and direction of the codec node,
so that it can call snd_soc_dai_set_fmt() and snd_soc_dai_set_sysclk()
properly. To eliminate that, we could have the fabric driver never call these
functions, and expect the SSI and codec drivers to gather this information
itself. But the codec driver is not an OF driver, so it has no expectation of
being able to query the codec node.
I would solve the problem this way: In the ssi driver, if the
codec-node property is present, then call a function to instantiate a
simple or platform specific sound card instance that makes the
assumptions listed above. If not, then just register the ssi and
exit, which leaves the ssi available for a separate driver to pick it
up. I wouldn't do this for new platforms, but it gracefully makes use
of the data provided in the current 8610 device tree.
Eh, I'll have to think about that. The absence of a codec pointer in the SSI
node means that the SSI is not connected to a codec, so it should just be
ignored altogether. An SSI is useless if it's not connected to a codec.
BTW Timur, there is nothing wrong with registering multiple
Re: [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, Apr 27, 2010 at 02:27:42PM -0600, Grant Likely wrote: On Tue, Apr 27, 2010 at 4:09 AM, Benjamin Herrenschmidt I don't have bandwidth to contribute much in this discussion right now, at least not to lead it, so I'm happy to let others do so, but I'm happy to provide feedback from my own experience as proposals are made. Unfortunately, I'm in the same boat. :-( However, I'll be at UDS in 2 weeks time, and I know audio is a big concern for the Ubuntu folks. A bunch of the ARM vendors will be there too. I'll schedule a session to talk about audio bindings and hopefully that way make some headway on defining a binding that makes sense and is actually useful. Hrm, the only issue that's been raised upstream is multi-CODEC (there are one or two other things that boil down to multi-CODEC, but nothing else I'm aware of). If you schedule something please announce it here, I believe that UDS generally has arrangements for remote participation. Note that most of the complexity explosion you'll see here is visible in things like phones more than the sort of devices you'd run Ubuntu on currently and much of it isn't really visible to a lot of the CPU vendors at all since it's generally all handled off the CPU. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
Mark Brown wrote:
Hrm, the only issue that's been raised upstream is multi-CODEC (there
are one or two other things that boil down to multi-CODEC, but nothing
else I'm aware of). If you schedule something please announce it here,
I believe that UDS generally has arrangements for remote participation.
Keep in mind that the phandle-type properties can accept multiple phandles. So
for instance, if I had two codecs attached to an SSI, the SSI node would look
like this:
s...@16000 {
compatible = fsl,mpc8610-ssi;
...
codec-handle = cs4270_1 cs4270_2;
};
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, Apr 27, 2010 at 03:46:04PM -0500, Timur Tabi wrote: [Reflowed into 80 columns; please fix your mail client.] (I've omitted the DMA nodes and some irrelevant details) This is enough information for a simplistic driver registration that probably makes a lot of assumptions. Such as the ssi represents a single logical sound device. It won't handle complex representations, but in Why would I ever represent the SSI as anything but a single logical sound device? Let ALSA handle synchronizing multiple streams together if it wants to. ... dai-links = ssi1 0 codec 0 ssi1 1 codec 1; [...] I don't know when I would ever do this. The two SSI devices are completely independent. Why would I bind them together into one device? It's entirely possible that if the board designer intended the verious SSIs to be used in concert they've done something like cross wire the clocks which creates a board-specific interrelationship that needs to be dealt with. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
Mark Brown wrote: It's entirely possible that if the board designer intended the verious SSIs to be used in concert they've done something like cross wire the clocks which creates a board-specific interrelationship that needs to be dealt with. Fine, but I don't see how that can be handled with the current code. Each SSI is independent, and audio is streamed to it via DMA. The current SSI driver would need to be completely rewritten in order to initiate both DMA operations simultaneously. The clocking is the least of my problems. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, Apr 27, 2010 at 04:03:27PM -0500, Timur Tabi wrote: [Reflowing the text into 80 columns again] Mark Brown wrote: It's entirely possible that if the board designer intended the verious SSIs to be used in concert they've done something like cross wire the clocks which creates a board-specific interrelationship that needs to be dealt with. Fine, but I don't see how that can be handled with the current code. Each SSI is independent, and audio is streamed to it via DMA. The current SSI driver would need to be completely rewritten in order to initiate both DMA operations simultaneously. The clocking is the least of my problems. I believe the usual technique is to start the DMA then clock the bus - data doesn't flow over the bus until the clock appears and that appears everywhere simultaneously. Obviously some hardware really doesn't like having the DMA blocked like that, but not all. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[patch 1/1] powerpc: add rcu_read_lock() to gup_fast() implementation
From: Peter Zijlstra a.p.zijls...@chello.nl The powerpc page table freeing relies on the fact that IRQs hold off an RCU grace period, this is currently true for all existing RCU implementations but is not an assumption Paul wants to support. Therefore, also take the RCU read lock along with disabling IRQs to ensure the RCU grace period does at least cover these lookups. Signed-off-by: Peter Zijlstra a.p.zijls...@chello.nl Requested-by: Paul E. McKenney paul...@linux.vnet.ibm.com Cc: Nick Piggin npig...@suse.de Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Reviewed-by: Rik van Riel r...@redhat.com Signed-off-by: Andrew Morton a...@linux-foundation.org --- arch/powerpc/mm/gup.c |3 +++ 1 file changed, 3 insertions(+) diff -puN arch/powerpc/mm/gup.c~powerpc-add-rcu_read_lock-to-gup_fast-implementation arch/powerpc/mm/gup.c --- a/arch/powerpc/mm/gup.c~powerpc-add-rcu_read_lock-to-gup_fast-implementation +++ a/arch/powerpc/mm/gup.c @@ -142,6 +142,7 @@ int get_user_pages_fast(unsigned long st * So long as we atomically load page table pointers versus teardown, * we can follow the address down to the the page and take a ref on it. */ + rcu_read_lock(); local_irq_disable(); pgdp = pgd_offset(mm, addr); @@ -162,6 +163,7 @@ int get_user_pages_fast(unsigned long st } while (pgdp++, addr = next, addr != end); local_irq_enable(); + rcu_read_unlock(); VM_BUG_ON(nr != (end - start) PAGE_SHIFT); return nr; @@ -171,6 +173,7 @@ int get_user_pages_fast(unsigned long st slow: local_irq_enable(); + rcu_read_unlock(); slow_irqon: pr_devel( slow path ! nr = %d\n, nr); _ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] add icswx support
On Sat, 2010-04-24 at 10:55 +1000, Benjamin Herrenschmidt wrote:
On Fri, 2010-04-23 at 17:04 -0500, Tseng-Hui (Frank) Lin wrote:
Add Power7 icswx co-processor instruction support.
Please provide a -much- more detailed explanation of what it is, what it
does and why it requires hooking into the MMU context switch code. _I_
know these things but nobody else on the list does which limits the
ability of people to review your patch.
icswx is a PowerPC co-processor instruction to send data to a
co-processor. On Book-S processors the LPAR_ID and process ID (PID) of
the owning process are registered in the window context of the
co-processor at initial time. When the icswx instruction is executed,
the L2 generates a cop-reg transaction on PowerBus. The transaction has
no address and the processor does not perform an MMU access to
authenticate the transaction. The coprocessor compares the LPAR_ID and
the PID included in the transaction and the LPAR_ID and PID held in the
window context to determine if the process is authorized to generate the
transaction.
Signed-off-by: Sonny Rao sonny...@linux.vnet.ibm.com
Signed-off-by: Tseng-Hui (Frank) Lin th...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/mmu-hash64.h |3 +
arch/powerpc/include/asm/mmu_context.h |4 ++
arch/powerpc/include/asm/reg.h |3 +
arch/powerpc/mm/mmu_context_hash64.c | 79
4 files changed, 89 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu-hash64.h
b/arch/powerpc/include/asm/mmu-hash64.h
index 2102b21..ba5727d 100644
--- a/arch/powerpc/include/asm/mmu-hash64.h
+++ b/arch/powerpc/include/asm/mmu-hash64.h
@@ -421,6 +421,9 @@ typedef struct {
#ifdef CONFIG_PPC_SUBPAGE_PROT
struct subpage_prot_table spt;
#endif /* CONFIG_PPC_SUBPAGE_PROT */
+ unsigned long acop;
+#define HASH64_MAX_PID (0x)
+ unsigned int pid;
Please add a comment as to what those two fields are about, something
like acop; /* mask of enabled coprocessor types */ and pid /* pid
value used with coprocessors */ or something like that.
} mm_context_t;
diff --git a/arch/powerpc/include/asm/mmu_context.h
b/arch/powerpc/include/asm/mmu_context.h
index 26383e0..d6c8841 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -78,6 +78,10 @@ static inline void switch_mm(struct mm_struct *prev,
struct mm_struct *next,
#define deactivate_mm(tsk,mm) do { } while (0)
+extern void switch_cop(struct mm_struct *next);
+extern int use_cop(unsigned long acop, struct task_struct *task);
^ remove that space
+extern void disuse_cop(unsigned long acop, struct mm_struct *mm);
I'd prefer drop or forget :-)
+
/*
* After we have set current-mm to a new value, this activates
* the context for the new mm so we see the new mappings.
diff --git a/arch/powerpc/include/asm/reg.h
b/arch/powerpc/include/asm/reg.h
index 5572e86..30503f8 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -516,6 +516,9 @@
#define SPRN_SIAR 780
#define SPRN_SDAR 781
+#define SPRN_ACOP 31
+#define SPRN_PID48
+
Remove the definition of SPRN_PID from reg_booke.h to avoid a double
definition then.
#define SPRN_PA6T_MMCR0 795
#define PA6T_MMCR0_EN0 0x0001UL
#define PA6T_MMCR0_EN1 0x0002UL
diff --git a/arch/powerpc/mm/mmu_context_hash64.c
b/arch/powerpc/mm/mmu_context_hash64.c
index 2535828..d0a79f6 100644
--- a/arch/powerpc/mm/mmu_context_hash64.c
+++ b/arch/powerpc/mm/mmu_context_hash64.c
@@ -18,6 +18,7 @@
#include linux/mm.h
#include linux/spinlock.h
#include linux/idr.h
+#include linux/percpu.h
#include linux/module.h
#include linux/gfp.h
@@ -25,6 +26,82 @@
static DEFINE_SPINLOCK(mmu_context_lock);
static DEFINE_IDA(mmu_context_ida);
+static DEFINE_IDA(cop_ida);
+
+/* Lazy switch the ACOP register */
+static DEFINE_PER_CPU(unsigned long, acop_reg);
+
+void switch_cop(struct mm_struct *next)
+{
+ mtspr(SPRN_PID, next-context.pid);
+ if (next-context.pid
+ __get_cpu_var(acop_reg) != next-context.acop) {
+ mtspr(SPRN_ACOP, next-context.acop);
+ __get_cpu_var(acop_reg) = next-context.acop;
+ }
+}
The above doesn't appear to be called anywhere ?
+int use_cop(unsigned long acop, struct task_struct *task)
+{
+ int pid;
+ int err;
+ struct mm_struct *mm = get_task_mm(task);
+
+ if (!mm)
+ return -EINVAL;
+
+ if (!mm-context.pid) {
+ if (!ida_pre_get(cop_ida, GFP_KERNEL))
+ return -ENOMEM;
+again:
+ spin_lock(mmu_context_lock);
+ err = ida_get_new_above(cop_ida, 1, pid);
+ spin_unlock(mmu_context_lock);
+
+ if (err ==
Re: [PATCH] add icswx support
On Tue, 2010-04-27 at 16:56 -0500, Tseng-Hui (Frank) Lin wrote: icswx is a PowerPC co-processor instruction to send data to a co-processor. On Book-S processors the LPAR_ID and process ID (PID) of the owning process are registered in the window context of the co-processor at initial time. When the icswx instruction is executed, the L2 generates a cop-reg transaction on PowerBus. The transaction has no address and the processor does not perform an MMU access to authenticate the transaction. The coprocessor compares the LPAR_ID and the PID included in the transaction and the LPAR_ID and PID held in the window context to determine if the process is authorized to generate the transaction. Ok, good, then stick that in the cset comment of your next patch submission after you've addresses all my other comments :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCHv2] [RFC] Xilinx MPMC SDMA subsystem
This is the 2nd version of Xilinx MPMC LocalLink SDMA subsystem
Changelog v2:
* Changed the functions and struct definition prefix from sdma_ to xllsdma_
* Platform bus bindings and various changes by Steven J. Magnani.
* Moved source files from arch/powerpc/sysdev to global locations and added
CONFIG_XLLSDMA option.
Regards, Sergey Temerkhanov,
Cifronic ZAO
diff -r baced9e29ab5 drivers/dma/Kconfig
--- a/drivers/dma/Kconfig Tue Apr 27 20:48:50 2010 +0400
+++ b/drivers/dma/Kconfig Wed Apr 28 02:00:51 2010 +0400
@@ -97,6 +97,14 @@
Support the TXx9 SoC internal DMA controller. This can be
integrated in chips such as the Toshiba TX4927/38/39.
+config XLLSDMA
+ bool Xilinx MPMC DMA support
+ depends on XILINX_VIRTEX || MICROBLAZE
+ select DMA_ENGINE
+ help
+ Support fot Xilinx MPMC LocalLink SDMA. Virtex FPGA family
+ has it integrated or fabric-based.
+
config DMA_ENGINE
bool
@@ -133,3 +141,5 @@
DMA Device driver.
endif
+
+
diff -r baced9e29ab5 drivers/dma/Makefile
--- a/drivers/dma/Makefile Tue Apr 27 20:48:50 2010 +0400
+++ b/drivers/dma/Makefile Wed Apr 28 02:00:51 2010 +0400
@@ -10,3 +10,4 @@
obj-$(CONFIG_AT_HDMAC) += at_hdmac.o
obj-$(CONFIG_MX3_IPU) += ipu/
obj-$(CONFIG_TXX9_DMAC) += txx9dmac.o
+obj-$(CONFIG_XLLSDMA) += xllsdma.o
diff -r baced9e29ab5 drivers/dma/xllsdma.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/drivers/dma/xllsdma.c Wed Apr 28 02:00:51 2010 +0400
@@ -0,0 +1,887 @@
+/*
+ * SDMA subsystem support for Xilinx MPMC.
+ *
+ * Author: Sergey Temerkhanov
+ * Platform Bus by Steven J. Magnani
+ *
+ * Copyright (c) 2008-2010 Cifronic ZAO
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include linux/delay.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/module.h
+#include linux/init.h
+#include linux/errno.h
+#include linux/interrupt.h
+#include linux/mutex.h
+#include linux/wait.h
+#include linux/list.h
+#include linux/io.h
+#include linux/xllsdma.h
+
+#include linux/of_device.h
+#include linux/of_platform.h
+
+#define DRV_VERSION 0.1.0
+#define DRV_NAME sdma
+
+MODULE_AUTHOR(Sergey Temerkhanov temerkha...@cifronik.ru);
+MODULE_DESCRIPTION(Xilinx SDMA driver);
+MODULE_LICENSE(GPL);
+MODULE_VERSION(DRV_VERSION);
+
+LIST_HEAD(mpmc_devs);
+DEFINE_MUTEX(mpmc_devs_lock);
+
+enum {
+ XLLSDMA_TX_REGS = 0x00, /* TX channel registers beginning */
+ XLLSDMA_RX_REGS = 0x20, /* RX channel registers beginning */
+ XLLSDMA_DMACR = 0x40, /* DMA control register */
+
+ XLLSDMA_NDESCR = 0x00, /* Next descriptor address */
+ XLLSDMA_BUFA = 0x04, /* Current buffer address */
+ XLLSDMA_BUFL = 0x08, /* Current buffer length */
+ XLLSDMA_CDESCR = 0x0C, /* Current descriptor address */
+ XLLSDMA_TDESCR = 0x10, /* Tail descriptor address */
+ XLLSDMA_CR = 0x14, /* Channel control */
+ XLLSDMA_IRQ = 0x18, /* Interrupt register */
+ XLLSDMA_SR = 0x1C, /* Status */
+};
+
+enum {
+ XLLSDMA_CR_IRQ_TIMEOUT_MSK = (0xFF 24), /* Interrupt coalesce timeout */
+ XLLSDMA_CR_IRQ_THRESHOLD_MSK = (0xFF 16), /* Interrupt coalesce count */
+ XLLSDMA_CR_MSB_ADDR_MSK = (0xF 12), /* MSB for 36 bit addressing */
+ XLLSDMA_CR_APP_EN = (1 11), /* Application data mask enable */
+ XLLSDMA_CR_1_BIT_CNT = (1 10), /* All interrupt counters are 1-bit */
+ XLLSDMA_CR_INT_ON_END = (1 9), /* Interrupt-on-end */
+ XLLSDMA_CR_LD_IRQ_CNT = (1 8), /* Load IRQ_COUNT */
+ XLLSDMA_CR_IRQ_EN = (1 7), /* Master interrupt enable */
+ XLLSDMA_CR_IRQ_ERROR = (1 2), /* Error interrupt enable */
+ XLLSDMA_CR_IRQ_TIMEOUT = (1 1), /* Coalesce timeout interrupt enable */
+ XLLSDMA_CR_IRQ_THRESHOLD = (1 0), /* Coalesce threshold interrupt enable */
+
+ XLLSDMA_CR_IRQ_ALL = XLLSDMA_CR_IRQ_EN | XLLSDMA_CR_IRQ_ERROR |
+ XLLSDMA_CR_IRQ_TIMEOUT | XLLSDMA_CR_IRQ_THRESHOLD,
+
+ XLLSDMA_CR_IRQ_TIMEOUT_SH = 24,
+ XLLSDMA_CR_IRQ_THRESHOLD_SH = 16,
+ XLLSDMA_CR_MSB_ADDR_SH = 12,
+
+ XLLSDMA_IRQ_WRQ_EMPTY = (1 14), /* Write Command Queue Empty (rx) */
+ XLLSDMA_IRQ_PLB_RD_ERROR = (1 4), /* PLB Read Error IRQ */
+ XLLSDMA_IRQ_PLB_WR_ERROR = (1 3), /* PLB Write Error IRQ */
+ XLLSDMA_IRQ_ERROR = (1 2), /* Error IRQ */
+ XLLSDMA_IRQ_TIMEOUT = (1 1), /* Coalesce timeout IRQ */
+ XLLSDMA_IRQ_THRESHOLD = (1 0), /* Coalesce threshold IRQ */
+
+ XLLSDMA_IRQ_ALL_ERR = 0x1C, /* All error interrupt */
+ XLLSDMA_IRQ_ALL = 0x1F, /* All interrupt bits */
+ XLLSDMA_IRQ_ALL_DONE = 0x3, /* All work complete interrupt bits */
+
+
+#define XLLSDMA_IRQ_COALESCE_COUNT(x) ((x 10) 0xF)
+#define XLLSDMA_IRQ_DELAY_COUNT(x) ((x 8) 0x3)
+
+ XLLSDMA_SR_ERR_TDESCR = (1 21), /* Tail descriptor pointer is invalid */
+ XLLSDMA_SR_ERR_CMPL = (1 20), /* Complete bit is set */
+ XLLSDMA_SR_ERR_BUFA = (1 19), /* Buffer address is invalid */
+
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, Apr 27, 2010 at 02:24:34PM -0600, Grant Likely wrote:
However, as you and Mark rightly point out, it completely fails to
represent complex sound devices with weird clocking and strange
routes. Something like this is probably more appropriate:
[...]
codec1 :co...@4f {
compatible = cirrus,cs4270;
reg = 0x4f;
/* MCLK source is a stand-alone oscillator */
clock-frequency = 12288000;
};
You also want to be representing unused pins here.
[...]
ssi1: s...@16000 {
compatible = fsl,mpc8610-ssi;
[...]
fsl,mode = i2s-slave;
I'd not include the master/slave decision; it's either implied by the
fact that the CODEC has a standalone clock, a property of the link/card,
or a policy decision that the running software can change on a whim.
sound {
compatible = fsl,mpc8610-hpcd-sound;
/* maybe something like (totally off the top of my head) */
dai-links = ssi1 0 codec 0
ssi1 1 codec 1;
I'm having a hard time loving this. I'd be looking for a lot more
semantics on the links (things like information about separate clocks
for the two directions, for example) which makes me think that that
simple list format is far too simple and you want a list of more complex
objects.
There's also analogue interconnects to deal with, and jacks (including
detection and accessories). Jacks can be particularly entertaining
here.
Or, in other words, the device tree should *not* be used to describe
every possible detail and permutation. It is best used to describe
the permutations that are common so that they don't need to be hard
coded for each and every board.
I think the ideal is something that's purely descriptive of the hardware
and doesn't include any policy decisions. Policy decisions covers an
awful lot of the interesting issues, though - but they're the sort of
things that can easily be changed with a new software load and therefore
don't belong in the device tree.
On the other hand from a pragmatic point of view it's just much less
hassle to just only provide the mechanism for instantiating a machine
with custom code and use that for everything.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [patch 03/15] powerpc: cpumask: Convert smp_cpus_done to new cpumask API
Hi Anton, On Tue, 27 Apr 2010 11:32:34 +1000 Anton Blanchard an...@samba.org wrote: - old_mask = current-cpus_allowed; - set_cpus_allowed(current, cpumask_of_cpu(boot_cpuid)); - + alloc_cpumask_var(old_mask, GFP_NOWAIT); You should probably put an explicit include of linux/gfp.h in this file for this. (Maybe linux/cpumask.h should include it - but it doesn't.) -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpoyS0dRQp0y.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, Apr 27, 2010 at 4:29 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Tue, Apr 27, 2010 at 02:24:34PM -0600, Grant Likely wrote:
However, as you and Mark rightly point out, it completely fails to
represent complex sound devices with weird clocking and strange
routes. Something like this is probably more appropriate:
[...]
codec1 :co...@4f {
compatible = cirrus,cs4270;
reg = 0x4f;
/* MCLK source is a stand-alone oscillator */
clock-frequency = 12288000;
};
You also want to be representing unused pins here.
[...]
ssi1: s...@16000 {
compatible = fsl,mpc8610-ssi;
[...]
fsl,mode = i2s-slave;
I'd not include the master/slave decision; it's either implied by the
fact that the CODEC has a standalone clock, a property of the link/card,
or a policy decision that the running software can change on a whim.
sound {
compatible = fsl,mpc8610-hpcd-sound;
/* maybe something like (totally off the top of my head) */
dai-links = ssi1 0 codec 0
ssi1 1 codec 1;
I'm having a hard time loving this. I'd be looking for a lot more
semantics on the links (things like information about separate clocks
for the two directions, for example) which makes me think that that
simple list format is far too simple and you want a list of more complex
objects.
Oh, absolutely. This example is no where near complete. Mostly I
just wanted to give a concrete example of a 'virtual' device like Ben
was talking about. I'm not going to even attempt to draft a complete
binding until I've got time to properly go over the issues involved
and discuss them with you and Liam.
There's also analogue interconnects to deal with, and jacks (including
detection and accessories). Jacks can be particularly entertaining
here.
Or, in other words, the device tree should *not* be used to describe
every possible detail and permutation. It is best used to describe
the permutations that are common so that they don't need to be hard
coded for each and every board.
I think the ideal is something that's purely descriptive of the hardware
and doesn't include any policy decisions. Policy decisions covers an
awful lot of the interesting issues, though - but they're the sort of
things that can easily be changed with a new software load and therefore
don't belong in the device tree.
Agreed.
On the other hand from a pragmatic point of view it's just much less
hassle to just only provide the mechanism for instantiating a machine
with custom code and use that for everything.
Also true, but this approach carries with it an incremental cost that
distributions feel the pain of. Ultimately I think we'll find a sweet
spot somewhere in between.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [microblaze-uclinux] [PATCHv2] [RFC] Xilinx MPMC SDMA subsystem
On Wed, 2010-04-28 at 02:06 +0400, Sergey Temerkhanov wrote:
This is the 2nd version of Xilinx MPMC LocalLink SDMA subsystem
Changelog v2:
* Changed the functions and struct definition prefix from sdma_ to xllsdma_
* Platform bus bindings and various changes by Steven J. Magnani.
* Moved source files from arch/powerpc/sysdev to global locations and added
CONFIG_XLLSDMA option.
Regards, Sergey Temerkhanov,
Cifronic ZAO
diff -r baced9e29ab5 drivers/dma/Kconfig
--- a/drivers/dma/Kconfig Tue Apr 27 20:48:50 2010 +0400
+++ b/drivers/dma/Kconfig Wed Apr 28 02:00:51 2010 +0400
@@ -97,6 +97,14 @@
Support the TXx9 SoC internal DMA controller. This can be
integrated in chips such as the Toshiba TX4927/38/39.
+config XLLSDMA
+ bool Xilinx MPMC DMA support
+ depends on XILINX_VIRTEX || MICROBLAZE
+ select DMA_ENGINE
+ help
+ Support fot Xilinx MPMC LocalLink SDMA. Virtex FPGA family
+ has it integrated or fabric-based.
+
fot -- for
Since the xllsdma driver provides services to other drivers - not to userland -
I think this would be better as a silent option, selected automatically when
something like ll_temac or the forthcoming Xilinx DMA engine is selected.
If we do it that way, note that XLLSDMA is independent of DMA_ENGINE so
drivers/Makefile will need to be patched so that the dma subdirectory is
always y.
config DMA_ENGINE
bool
@@ -133,3 +141,5 @@
DMA Device driver.
endif
+
+
Some extra white space crept in at the end of the file.
diff -r baced9e29ab5 drivers/dma/Makefile
--- a/drivers/dma/MakefileTue Apr 27 20:48:50 2010 +0400
+++ b/drivers/dma/MakefileWed Apr 28 02:00:51 2010 +0400
@@ -10,3 +10,4 @@
obj-$(CONFIG_AT_HDMAC) += at_hdmac.o
obj-$(CONFIG_MX3_IPU) += ipu/
obj-$(CONFIG_TXX9_DMAC) += txx9dmac.o
+obj-$(CONFIG_XLLSDMA) += xllsdma.o
diff -r baced9e29ab5 drivers/dma/xllsdma.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/drivers/dma/xllsdma.c Wed Apr 28 02:00:51 2010 +0400
@@ -0,0 +1,887 @@
+/*
+ * SDMA subsystem support for Xilinx MPMC.
+ *
+ * Author: Sergey Temerkhanov
+ * Platform Bus by Steven J. Magnani
+ *
+ * Copyright (c) 2008-2010 Cifronic ZAO
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include linux/delay.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/module.h
+#include linux/init.h
+#include linux/errno.h
+#include linux/interrupt.h
+#include linux/mutex.h
+#include linux/wait.h
+#include linux/list.h
+#include linux/io.h
+#include linux/xllsdma.h
+
+#include linux/of_device.h
+#include linux/of_platform.h
+
+#define DRV_VERSION 0.1.0
+#define DRV_NAME sdma
+
+MODULE_AUTHOR(Sergey Temerkhanov temerkha...@cifronik.ru);
+MODULE_DESCRIPTION(Xilinx SDMA driver);
+MODULE_LICENSE(GPL);
+MODULE_VERSION(DRV_VERSION);
+
+LIST_HEAD(mpmc_devs);
+DEFINE_MUTEX(mpmc_devs_lock);
+
+enum {
+ XLLSDMA_TX_REGS = 0x00, /* TX channel registers beginning */
+ XLLSDMA_RX_REGS = 0x20, /* RX channel registers beginning */
+ XLLSDMA_DMACR = 0x40, /* DMA control register */
+
+ XLLSDMA_NDESCR = 0x00, /* Next descriptor address */
+ XLLSDMA_BUFA= 0x04, /* Current buffer address */
+ XLLSDMA_BUFL= 0x08, /* Current buffer length */
+ XLLSDMA_CDESCR = 0x0C, /* Current descriptor address */
+ XLLSDMA_TDESCR = 0x10, /* Tail descriptor address */
+ XLLSDMA_CR = 0x14, /* Channel control */
+ XLLSDMA_IRQ = 0x18, /* Interrupt register */
+ XLLSDMA_SR = 0x1C, /* Status */
+};
+
+enum {
+ XLLSDMA_CR_IRQ_TIMEOUT_MSK = (0xFF 24),/* Interrupt coalesce
timeout */
+ XLLSDMA_CR_IRQ_THRESHOLD_MSK = (0xFF 16),/* Interrupt coalesce
count */
+ XLLSDMA_CR_MSB_ADDR_MSK = (0xF 12), /* MSB for 36 bit
addressing */
+ XLLSDMA_CR_APP_EN = (1 11), /* Application data mask enable
*/
+ XLLSDMA_CR_1_BIT_CNT = (1 10), /* All interrupt counters are
1-bit */
+ XLLSDMA_CR_INT_ON_END = (1 9), /* Interrupt-on-end */
+ XLLSDMA_CR_LD_IRQ_CNT = (1 8), /* Load IRQ_COUNT */
+ XLLSDMA_CR_IRQ_EN = (1 7), /* Master interrupt enable */
+ XLLSDMA_CR_IRQ_ERROR = (1 2), /* Error interrupt enable */
+ XLLSDMA_CR_IRQ_TIMEOUT= (1 1), /* Coalesce timeout interrupt
enable */
+ XLLSDMA_CR_IRQ_THRESHOLD = (1 0), /* Coalesce threshold interrupt
enable */
+
+ XLLSDMA_CR_IRQ_ALL= XLLSDMA_CR_IRQ_EN | XLLSDMA_CR_IRQ_ERROR |
+ XLLSDMA_CR_IRQ_TIMEOUT |
XLLSDMA_CR_IRQ_THRESHOLD,
+
+ XLLSDMA_CR_IRQ_TIMEOUT_SH = 24,
+ XLLSDMA_CR_IRQ_THRESHOLD_SH =
Re: [patch 1/1] powerpc: add rcu_read_lock() to gup_fast() implementation
On Tue, Apr 27, 2010 at 02:10:47PM -0700, Andrew Morton wrote: From: Peter Zijlstra a.p.zijls...@chello.nl The powerpc page table freeing relies on the fact that IRQs hold off an RCU grace period, this is currently true for all existing RCU implementations but is not an assumption Paul wants to support. Therefore, also take the RCU read lock along with disabling IRQs to ensure the RCU grace period does at least cover these lookups. Signed-off-by: Peter Zijlstra a.p.zijls...@chello.nl Requested-by: Paul E. McKenney paul...@linux.vnet.ibm.com Cc: Nick Piggin npig...@suse.de Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Reviewed-by: Rik van Riel r...@redhat.com Signed-off-by: Andrew Morton a...@linux-foundation.org I think I nacked this because the rest of the powerpc code also assumes irq disables provide an rcu critical section. The plan was to convert powerpc pagetable code to use call_rcu_sched. --- arch/powerpc/mm/gup.c |3 +++ 1 file changed, 3 insertions(+) diff -puN arch/powerpc/mm/gup.c~powerpc-add-rcu_read_lock-to-gup_fast-implementation arch/powerpc/mm/gup.c --- a/arch/powerpc/mm/gup.c~powerpc-add-rcu_read_lock-to-gup_fast-implementation +++ a/arch/powerpc/mm/gup.c @@ -142,6 +142,7 @@ int get_user_pages_fast(unsigned long st * So long as we atomically load page table pointers versus teardown, * we can follow the address down to the the page and take a ref on it. */ + rcu_read_lock(); local_irq_disable(); pgdp = pgd_offset(mm, addr); @@ -162,6 +163,7 @@ int get_user_pages_fast(unsigned long st } while (pgdp++, addr = next, addr != end); local_irq_enable(); + rcu_read_unlock(); VM_BUG_ON(nr != (end - start) PAGE_SHIFT); return nr; @@ -171,6 +173,7 @@ int get_user_pages_fast(unsigned long st slow: local_irq_enable(); + rcu_read_unlock(); slow_irqon: pr_devel( slow path ! nr = %d\n, nr); _ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, 2010-04-27 at 23:29 +0100, Mark Brown wrote: On the other hand from a pragmatic point of view it's just much less hassle to just only provide the mechanism for instantiating a machine with custom code and use that for everything. Right, that's the balance to find. A too descriptive device-tree becomes a mess, and attempting to deal with any kind of representation in SW is horrible. There is a fine balance to be found between how much goes into the device-tree and how much is eventually just a plain C file that puts things together. For example, one could imagine a /sound node with simply a compatible property that matches what we call in AOA terminology a fabric driver. IE. The one thing specific to the board that puts bits and pieces together. Now, the device-tree is still obviously useful to provide things like the actual i2c IDs of codecs, GPIOs used for various actions, link to from various components to their clock source devices, etc.. All these things simplify the code, avoids horrid board specific code in the actual drivers (codecs, busses, etc...) and overall help keeping the code more maintainable. This is not an issue specific to audio. The same problem to some extent shows up at the arch level, which is why I was never too much in favor of doing a generic platform on powerpc, but still want to have a per board (or at least board family) platform .c file which has the upper hand, even if it ends up mostly using device-tree based helpers to put things together. The device-tree helps keep the platform .c file simple and devoid of too horrible hacks, it allows to easily pass various configuration data to leaf drivers such as i2c thingies, PHY devices etc... without gross hooks between these and the platform, but the platform code still has the upper hand for doing ad-hoc bits and pieces (or overwriting the device-tree based behaviour) if necessary. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [patch 1/1] powerpc: add rcu_read_lock() to gup_fast() implementation
On Wed, 2010-04-28 at 13:29 +1000, Nick Piggin wrote: I think I nacked this because the rest of the powerpc code also assumes irq disables provide an rcu critical section. The plan was to convert powerpc pagetable code to use call_rcu_sched. Right, on my todo list. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, 2010-04-27 at 13:15 -0600, Grant Likely wrote: Can you not dynamically assign an id? If alsa soc needs a unique id number, then just create a lookup function. Something like of_asoc_phandle_to_codec_id() that will either return a previously assigned id, or will assign a new id. You shouldn't ever need to add data to the tree at runtime. Numerical magic IDs are evil... why not a name ? Or it's existing alsa breakage ? :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, 2010-04-27 at 15:04 -0500, Timur Tabi wrote: What I need is something like a hashing function that can convert a struct device_node * into an int. I'm going to have two functions that independently parse the device tree and locate a specific node. Both functions will register the node with asoc, but they'll use an integer ID to uniquely identify the node. At least, that's the way ASoC likes to operate. AsoC takes a fixed string plus a unique integer. I could technically create a unique string for each DMA device, and have the integer always be 0. That's just plain gross and horrible. You could use phandles you know :-) Or you could use path in your strings, or something like that. Note that any time you have a struct device, you have a free device_node pointer as well. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, 2010-04-27 at 21:59 +0100, Mark Brown wrote: It's entirely possible that if the board designer intended the verious SSIs to be used in concert they've done something like cross wire the clocks which creates a board-specific interrelationship that needs to be dealt with. In which case, have that in some board specific code :-) Really, as I said earlier, I think there's no point to aim toward a uber-representation that can describe everything along with code that can cope with anything the tree can describe :-) That's just insane. I'd stay stick to the basics and move incrementally up until it stops making sense: - First, the basics: nodes for actual physical devices. i2c codecs on their i2c busses, DMA controllers, etc... - From there, see what simple properties are better off being put in those respective nodes because they represent common enough variants of functionality or simply because they are specific attributes of a given device that aren't too concerned by the way things are interconnected. - Provide at least one identifier (either in a sound virtual device, or just use the board's own compatible property) to have a .c file to put everything together. From there, you may decide that 90% of the simple cases can be very easily represented by a couple of properties in the said sound node, and henceforth, create a simple.c board file that matches against a list of boards known to fit within that simple model, and that pretty much exclusively use the device-tree to put things together. But you don't have to. The whole thing is a matter of common sense and a bit of taste :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [patch 1/1] powerpc: add rcu_read_lock() to gup_fast() implementation
On Tue, 2010-04-27 at 14:10 -0700, a...@linux-foundation.org wrote: From: Peter Zijlstra a.p.zijls...@chello.nl The powerpc page table freeing relies on the fact that IRQs hold off an RCU grace period, this is currently true for all existing RCU implementations but is not an assumption Paul wants to support. Therefore, also take the RCU read lock along with disabling IRQs to ensure the RCU grace period does at least cover these lookups. Nah, that's not right. The right fix is to use call_rcu_sched() from the powerpc page table freeing code. Please drop. Cheers, Ben. Signed-off-by: Peter Zijlstra a.p.zijls...@chello.nl Requested-by: Paul E. McKenney paul...@linux.vnet.ibm.com Cc: Nick Piggin npig...@suse.de Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Reviewed-by: Rik van Riel r...@redhat.com Signed-off-by: Andrew Morton a...@linux-foundation.org --- arch/powerpc/mm/gup.c |3 +++ 1 file changed, 3 insertions(+) diff -puN arch/powerpc/mm/gup.c~powerpc-add-rcu_read_lock-to-gup_fast-implementation arch/powerpc/mm/gup.c --- a/arch/powerpc/mm/gup.c~powerpc-add-rcu_read_lock-to-gup_fast-implementation +++ a/arch/powerpc/mm/gup.c @@ -142,6 +142,7 @@ int get_user_pages_fast(unsigned long st * So long as we atomically load page table pointers versus teardown, * we can follow the address down to the the page and take a ref on it. */ + rcu_read_lock(); local_irq_disable(); pgdp = pgd_offset(mm, addr); @@ -162,6 +163,7 @@ int get_user_pages_fast(unsigned long st } while (pgdp++, addr = next, addr != end); local_irq_enable(); + rcu_read_unlock(); VM_BUG_ON(nr != (end - start) PAGE_SHIFT); return nr; @@ -171,6 +173,7 @@ int get_user_pages_fast(unsigned long st slow: local_irq_enable(); + rcu_read_unlock(); slow_irqon: pr_devel( slow path ! nr = %d\n, nr); _ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [microblaze-uclinux] [PATCHv2] [RFC] Xilinx MPMC SDMA subsystem
Hi Sergey and Steven,
On Tue, Apr 27, 2010 at 8:29 PM, Steven J. Magnani
st...@digidescorp.com wrote:
On Wed, 2010-04-28 at 02:06 +0400, Sergey Temerkhanov wrote:
This is the 2nd version of Xilinx MPMC LocalLink SDMA subsystem
Changelog v2:
* Changed the functions and struct definition prefix from sdma_ to xllsdma_
* Platform bus bindings and various changes by Steven J. Magnani.
* Moved source files from arch/powerpc/sysdev to global locations and added
CONFIG_XLLSDMA option.
Regards, Sergey Temerkhanov,
Cifronic ZAO
diff -r baced9e29ab5 drivers/dma/Kconfig
--- a/drivers/dma/Kconfig Tue Apr 27 20:48:50 2010 +0400
+++ b/drivers/dma/Kconfig Wed Apr 28 02:00:51 2010 +0400
@@ -97,6 +97,14 @@
Support the TXx9 SoC internal DMA controller. This can be
integrated in chips such as the Toshiba TX4927/38/39.
+config XLLSDMA
I'd prefer XILINX_LLSDMA. XLLSDMA could be ambiguous in the global
namespace (for a human reader), particularly as it is something that
few people will actually see.
+ bool Xilinx MPMC DMA support
+ depends on XILINX_VIRTEX || MICROBLAZE
+ select DMA_ENGINE
+ help
+ Support fot Xilinx MPMC LocalLink SDMA. Virtex FPGA family
+ has it integrated or fabric-based.
+
fot -- for
Since the xllsdma driver provides services to other drivers - not to userland
-
I think this would be better as a silent option, selected automatically when
something like ll_temac or the forthcoming Xilinx DMA engine is selected.
If we do it that way, note that XLLSDMA is independent of DMA_ENGINE so
drivers/Makefile will need to be patched so that the dma subdirectory is
always y.
Agreed. However, looking at this code, I don't see anything that
actually uses DMA_ENGINE here. Am I missing something?
diff -r baced9e29ab5 drivers/dma/Makefile
--- a/drivers/dma/Makefile Tue Apr 27 20:48:50 2010 +0400
+++ b/drivers/dma/Makefile Wed Apr 28 02:00:51 2010 +0400
@@ -10,3 +10,4 @@
obj-$(CONFIG_AT_HDMAC) += at_hdmac.o
obj-$(CONFIG_MX3_IPU) += ipu/
obj-$(CONFIG_TXX9_DMAC) += txx9dmac.o
+obj-$(CONFIG_XLLSDMA) += xllsdma.o
diff -r baced9e29ab5 drivers/dma/xllsdma.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/drivers/dma/xllsdma.c Wed Apr 28 02:00:51 2010 +0400
@@ -0,0 +1,887 @@
+/*
+ * SDMA subsystem support for Xilinx MPMC.
+ *
+ * Author: Sergey Temerkhanov
+ * Platform Bus by Steven J. Magnani
+ *
+ * Copyright (c) 2008-2010 Cifronic ZAO
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include linux/delay.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/module.h
+#include linux/init.h
+#include linux/errno.h
+#include linux/interrupt.h
+#include linux/mutex.h
+#include linux/wait.h
+#include linux/list.h
+#include linux/io.h
+#include linux/xllsdma.h
+
+#include linux/of_device.h
+#include linux/of_platform.h
+
+#define DRV_VERSION 0.1.0
Irrelevant, can be dropped
+#define DRV_NAME sdma
Used only once, drop.
+
+MODULE_AUTHOR(Sergey Temerkhanov temerkha...@cifronik.ru);
+MODULE_DESCRIPTION(Xilinx SDMA driver);
+MODULE_LICENSE(GPL);
+MODULE_VERSION(DRV_VERSION);
+
+LIST_HEAD(mpmc_devs);
+DEFINE_MUTEX(mpmc_devs_lock);
+
+void xllsdma_tx_irq_enable(struct xllsdma_device *sdma)
+{
+ u32 tx_cr;
+ unsigned long flags;
+
+ BUG_ON(sdma-tx_irq == NO_IRQ);
+
+ spin_lock_irqsave(sdma-lock, flags);
+ tx_cr = xllsdma_tx_in32(sdma, XLLSDMA_CR);
+ xllsdma_tx_out32(sdma, XLLSDMA_CR, tx_cr | XLLSDMA_CR_IRQ_EN);
+ spin_unlock_irqrestore(sdma-lock, flags);
This pattern is used a lot. Might be worth while to implement
xllsdma_tx_* variants of setbits32, clrbits32 and clrsetbits32.
Also, there are a lot of these little functions; really trivial and
small. Would it be better to have them as static inlines in the
header file instead of exported globals?
+}
+EXPORT_SYMBOL_GPL(xllsdma_tx_irq_enable);
+
+void xllsdma_rx_irq_enable(struct xllsdma_device *sdma)
+{
+ u32 rx_cr;
+ unsigned long flags;
+
+ BUG_ON(sdma-rx_irq == NO_IRQ);
+
+ spin_lock_irqsave(sdma-lock, flags);
+ rx_cr = xllsdma_rx_in32(sdma, XLLSDMA_CR);
+ xllsdma_rx_out32(sdma, XLLSDMA_CR, rx_cr | XLLSDMA_CR_IRQ_EN);
+ spin_unlock_irqrestore(sdma-lock, flags);
+}
+EXPORT_SYMBOL_GPL(xllsdma_rx_irq_enable);
+
+void xllsdma_tx_irq_disable(struct xllsdma_device *sdma)
+{
+ u32 tx_cr;
+ unsigned long flags;
+
+ spin_lock_irqsave(sdma-lock, flags);
+ tx_cr = xllsdma_tx_in32(sdma, XLLSDMA_CR);
+ xllsdma_tx_out32(sdma, XLLSDMA_CR, tx_cr ~XLLSDMA_CR_IRQ_EN);
+ spin_unlock_irqrestore(sdma-lock, flags);
+}
+EXPORT_SYMBOL_GPL(xllsdma_tx_irq_disable);
+
+void
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, Apr 27, 2010 at 2:46 PM, Timur Tabi ti...@freescale.com wrote:
Grant Likely wrote:
So, the current 86xx device tree binding assumes a simple layout with
a node describing an DAI controller, and another node describing the
codec with a single phandle (pointer) from the DAI to the codec. In
this configuration, it is completely reasonable for the DAI node to
trigger both the instantiation of the ASoC DAI controller device and
the sound card device. Linux can treat them as separate even though
the current device tree has a simplistic representation.
The only problem with this is that there is board-specific programming that
needs to be done (look at mpc8610_hpcd_machine_probe), so we still need to
have a fabric driver that is independent of the SSI, codec, or DMA drivers.
The P1022 also has an SSI, and I'm hoping that all I need to do is create a
new fabric driver, not hack up the SSI driver to support board programming.
So if the fabric driver still needs to exist, then it still needs a struct
device, and it still needs to register with asoc. I don't see how I can
register the sound card itself in the SSI driver, because it won't know
anything about the board-specific code in the fabric driver.
Why not? Just have the ssi driver probe routine register the fabric
device based on the existence of the codec-handle property. It is the
best way to go about things with the data that you've got available,
and it is no big deal. The relevant fabric driver can then bind
against that. You should probably also stuff the ssi device node
pointer into the fabric device of_node pointer.
I've tried very hard to maintain a distinction between device tree
binding (representation) and Linux kernel internal implementation
details. The real question is whether or not the binding provides
sufficient detail for the operating system to figure out what to do.
I think it does, because it's working today.
In the extreme minimalist case, the audio driver could decide how to
configure itself solely on the board name property of the root node.
There is nothing wrong with that, but it also means that no data is
available to dynamically select common modules or modify connections;
it all has to be hard coded.
Well, asoc already has several hard-coded requirements:
machine_data-dai.cpu_dai_drv = fsl_ssi_dai;
machine_data-dai.codec_dai_drv = cs4270_dai;
machine_data-dai.codec_drv = soc_codec_device_cs4270;
machine_data-dai.ops = mpc8610_hpcd_ops;
machine_data-dai.platform_drv = fsl_soc_platform;
So even though I probe for each device separately and register them
separately, the fabric driver still needs to have hard-coded addresses
Maybe the asoc guys can tell me why I need to register the cpu_dai_drv
structure via platform_device_add(), when it's already being registered via
snd_soc_register_dai().
(I've omitted the DMA nodes and some irrelevant details) This is
enough information for a simplistic driver registration that probably
makes a lot of assumptions. Such as the ssi represents a single
logical sound device. It won't handle complex representations, but in
a lot of cases that may be just fine.
Why would I ever represent the SSI as anything but a single logical sound
device? Let ALSA handle synchronizing multiple streams together if it wants
to.
sound {
compatible = fsl,mpc8610-hpcd-sound;
/* maybe something like (totally off the top of my head) */
dai-links = ssi1 0 codec 0
ssi1 1 codec 1;
[...]
};
I don't know when I would ever do this. The two SSI devices are completely
independent. Why would I bind them together into one device?
If there is no use case for binding them together, then you're right.
The current binding is probably just fine. I cannot comment on
whether or not it will be used that way by platform designers.
Where the 'sound' node is now the starting point for representing a
logical sound device instead of the ssi node. This binding probably
makes more sense (but I'm not committing to anything like this until I
see a real proposal for a real device).
The only issue I have with this is all it does is turn the fabric driver from
a platform driver that scans the OF tree, into an OF driver that still needs
to query the device tree to get all the data it needs. For example, the
fabric driver still needs to know the clock frequency and direction of the
codec node, so that it can call snd_soc_dai_set_fmt() and
snd_soc_dai_set_sysclk() properly. To eliminate that, we could have the
fabric driver never call these functions, and expect the SSI and codec
drivers to gather this information itself. But the codec driver is not an OF
driver, so it has no expectation of being able to query the codec node.
I would solve the problem this way: In the ssi driver, if the
