* Re: [PATCH] i2c: adds support for i2c bus on 8xx
From: Jean Delvare @ 2007-07-11 15:50 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20070511101231.241e3a30@hyperion.delvare>
Hi Vitaly,
What's the status of this patch? I didn't see any update since my
review on May 10th. It's too late for 2.6.23 already.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH 1/3] powerpc clk.h interface for platforms
From: David Brownell @ 2007-07-11 15:56 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, Domen Puncer, Russell King, linux-mips
In-Reply-To: <20070711103640.GB15536@lst.de>
On Wednesday 11 July 2007, Christoph Hellwig wrote:
> On Wed, Jul 11, 2007 at 11:32:20AM +0200, Domen Puncer wrote:
> > clk interface for arch/powerpc, platforms should fill
> > clk_functions.
>
> Umm, this is about the fifth almost identical implementation of
> the clk_ functions. Please, please put it into common code.
>
> And talk to the mips folks which just got a similar comment from me.
You mean like a lib/clock.c core, rather than an opsvector?
ISTR that allowing custom platform-specific implementations
was intended to be a feature. But it's also true that some
folks see lack of shared implementation code as a drawback;
so I've CC'd Russell King (who originated the interface for
ARM platforms).
- Dave
^ permalink raw reply
* Re: [PATCH 1/3] powerpc clk.h interface for platforms
From: Christoph Hellwig @ 2007-07-11 16:16 UTC (permalink / raw)
To: David Brownell
Cc: linux-mips, linuxppc-dev, Domen Puncer, Christoph Hellwig,
Russell King
In-Reply-To: <200707110856.58463.david-b@pacbell.net>
On Wed, Jul 11, 2007 at 08:56:58AM -0700, David Brownell wrote:
> > Umm, this is about the fifth almost identical implementation of
> > the clk_ functions. Please, please put it into common code.
> >
> > And talk to the mips folks which just got a similar comment from me.
>
> You mean like a lib/clock.c core, rather than an opsvector?
I mean an ops vector and surrounding wrappers. Every architecture
is reimplementing their own dispatch table which is rather annoying.
What would a lib/clock.c do?
^ permalink raw reply
* Re: PageFault when I write in the Serial registers, MMU ?
From: Bhupender Saharan @ 2007-07-11 16:32 UTC (permalink / raw)
To: Nicolas Mederle; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <4694F9BD.4090406@yahoo.fr>
[-- Attachment #1: Type: text/plain, Size: 1896 bytes --]
Hi,
You could call *io_block_mapping* function from your setup.c file that will
add the entry into MMU.
regards
Bhupi
On 7/11/07, Nicolas Mederle <mederle_nicolas@yahoo.fr> wrote:
>
> Hi,
>
> I am porting linux on a custom board equipped with a PPC750, and I
> will like to have some advices on the MMU. I used the powerpc arch, and
> I built my device tree.
> I will like to know in which files we can configure the
> authorizations access for the I/O registers. When I use the function
> md_ppc.progress, I have a data access fault. I modified the head. S
> files, for add the BAT config. But I think that it is not correct, and
> that it is possible to do it elsewhere (platform_init?). Moreover the
> kernel modify the MMU config, it removes the BATs, and configures the
> Registers Segments. So, must I remake the configuration? Or is it
> possible to indicate, at the beginning, which space is reserved for I/O?
> I studied several patch (sandpoint, PrPMC2800) but none configures
> really the MMU for I/O registers. In the same way, I read several books,
> but I am not able to have information that I seek, therefore I am really
> blocked. I warmly thank you for the assistance which you will be able to
> bring to me.
>
> Mapping : 0x0000 0000 -> 0x0FFF FFFF : RAM
> 0x2000 0000 -> 0x201F FFFF : ASIC (
> UART, DMA, GPIO, PIC...)
> 0x8000 0000 -> 0x8FFF FFFF : PCI
> 0xF000 0000 -> 0xFFFF FFFF : Flash
> The kernel is load at 0x0, an the system is a Run In Memory.
> Currently, I don't use the flash.
>
>
> Best regards,
> Nicolas MEDERLE
>
> --
> Cordialement,
>
> Nicolas MEDERLE.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 3091 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] Add DMA engine driver for Freescale MPC8xxx processors.
From: Scott Wood @ 2007-07-11 16:34 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, paulus
In-Reply-To: <11840607262279-git-send-email-wei.zhang@freescale.com>
On Tue, Jul 10, 2007 at 05:45:26PM +0800, Zhang Wei wrote:
> +config FSL_DMA
> + bool "Freescale MPC8xxx DMA support"
> + depends on DMA_ENGINE && (PPC_86xx || PPC_85xx)
Remove the dependency on specific PPC chips... let the device tree say
whether the hardware is present.
> +static inline int fsl_dma_idle(struct fsl_dma_chan *fsl_chan)
> +{
> + return (((in_be32(&fsl_chan->reg_base->sr) & FSL_DMA_SR_CB) == 0) &&
> + ((in_be32(&fsl_chan->reg_base->mr) & FSL_DMA_MR_CC) == 0));
> +}
I'm still not convinced that there's any reason to check MR_CC, even if
the driver *did* set it.
> + /* We need the descriptor to be aligned to 32bytes
> + * for meeting FSL DMA specification requirement.
> + */
> + fsl_chan->desc_pool = dma_pool_create("fsl_dma_engine_desc_pool",
> + fsl_chan->device->dev, sizeof(struct fsl_desc_sw),
> + 32, 0);
> + if (unlikely(!fsl_chan->desc_pool)) {
> + dev_err(fsl_chan->device->dev, "No memory for channel %d "
> + "descriptor dma pool.\n", fsl_chan->id);
> + return 0;
> + }
> +
> + /* Allocate list ring, and form the static list ring */
> + for (i = 0; i < FSLDMA_LD_INIT_RING_SIZE; i++) {
> + desc = fsl_dma_alloc_descriptor(fsl_chan->desc_pool,
> + GFP_KERNEL);
It'd be much simpler to allocate the entire ring at once. No need for
linked lists, DMA pools, etc. Just a single dma_alloc_coherent.
In general, this driver seems far more complex than it needs to be.
> + switch (fsl_chan->mode) {
> + case FSL_DMA_EXTENDED:
What benefit do we get out of using extended mode? If the driver can do
everything it needs to with basic, with no performance penalty, why not
always use basic?
> +static dma_cookie_t do_fsl_dma_memcpy(struct fsl_dma_chan *fsl_chan,
> + dma_addr_t dest,
> + dma_addr_t src, size_t len,
> + dma_xfer_callback cb, void *data)
> +{
> + struct fsl_desc_sw *first = NULL, *prev = NULL, *list, *new;
> + size_t copy;
> + dma_cookie_t cookie;
> + unsigned long flags;
> + struct fsl_dma_device *fdev = fsl_chan->device;
> + int err = 0;
> + LIST_HEAD(link_chain);
> +
> + if (unlikely(!fsl_chan || !dest || !src))
> + return -EFAULT;
-EINVAL for fsl_chan, if you bother checking at all (I wouldn't; it
doesn't come from untrusted code. Better to show a nasty-looking oops to
bring attention to the problem).
Don't check dest and src against NULL; zero is a potentially valid DMA
address.
> + /* Stop the DMA */
> + fsl_dma_halt(fsl_chan);
> + /* Insert the ld descriptor to the LD ring */
> + list_add(&ld->node, fsl_chan->enque);
> + switch (fsl_chan->mode) {
> + case FSL_DMA_EXTENDED:
> + INSERT_LD_RING(fsl_chan, ld, list, next_ls_addr);
> + break;
> + case FSL_DMA_BASIC:
> + INSERT_LD_RING(fsl_chan, ld, link, next_ln_addr);
> + break;
> + }
> + spin_unlock_irqrestore(&fsl_chan->desc_lock, flags);
It'd be nice if we didn't have to stop the DMA in order to insert new
descriptors.
> + /* cookie incr and addition to used_list must be atomic */
> + cookie = fsl_chan->common.cookie;
> + cookie++;
> + if (cookie < 0)
> + cookie = 1;
Why not just use the index into the ring as the cookie?
> + stat = in_be32(&fsl_chan->reg_base->sr);
> + dev_dbg(fsl_chan->device->dev, "event: channel %d, stat = 0x%x\n",
> + fsl_chan->id, stat);
> + if (!stat)
> + return IRQ_NONE;
> + busy = stat & (FSL_DMA_SR_CB);
> + stat &= ~(FSL_DMA_SR_CB | FSL_DMA_SR_CH);
This masking must happen *before* the IRQ_NONE check.
-Scott
^ permalink raw reply
* Re: [PATCH 3/4] Extend the DMA-engine API.
From: Dan Williams @ 2007-07-11 16:56 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: shannon.nelson, linux-kernel, linuxppc-dev, paulus, akpm
In-Reply-To: <46B96294322F7D458F9648B60E15112C6F3CED@zch01exm26.fsl.freescale.net>
On 7/11/07, Zhang Wei-r63237 <Wei.Zhang@freescale.com> wrote:
> Hi, Dan,
>
> Do you mention here: http://marc.info/?l=linux-raid&m=118290909614463&w=2 ?
> I see the async_tx is located at crypto/ of the above page, but my patch is for DMA engine in drivers/dma and for DMA engine driver.
>
> Thanks!
> Wei.
Hi Wei,
I was referring to:
http://marc.info/?l=linux-raid&m=118290909528910&w=2
async_tx is an api that exploits the raw capabilities of the new
dmaengine interface. For your case when the existing api calls do not
provide the proper interface you can open code something like the
following:
tx = dev->device_prep_dma_<operation>(chan, len, int_flag)
tx->tx_set_src(dma_addr_t, tx, index /* for multi-source ops */)
tx->tx_set_dest(dma_addr_t, tx, index)
tx->tx_submit(tx)
The expectation is that the most common usages of dmaengines will use
async_tx calls, or the 'dma_async_memcpy_foo_to_bar' helper routines.
--
Dan
^ permalink raw reply
* Re: [PATCH 1/3] powerpc clk.h interface for platforms
From: David Brownell @ 2007-07-11 17:02 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, Domen Puncer, Russell King, linux-mips
In-Reply-To: <20070711161633.GA4846@lst.de>
On Wednesday 11 July 2007, Christoph Hellwig wrote:
> On Wed, Jul 11, 2007 at 08:56:58AM -0700, David Brownell wrote:
> > > Umm, this is about the fifth almost identical implementation of
> > > the clk_ functions. Please, please put it into common code.
> > >
> > > And talk to the mips folks which just got a similar comment from me.
> >
> > You mean like a lib/clock.c core, rather than an opsvector?
>
> I mean an ops vector and surrounding wrappers. Every architecture
> is reimplementing their own dispatch table which is rather annoying.
ARM doesn't. :)
But then, nobody expects one kernel to support more than one
vendor's ARM chips; or usually, more than one generation of
that vendor's chips. So any dispatch table is specific to
a given platform, and tuned to its quirks. Not much to share
between OMAP and AT91, for example, except in some cases maybe
an arm926ejs block.
> What would a lib/clock.c do?
Some folk have suggested defining a core "struct clk {...}" with
some of the basics -- refcount, parent, maybe enough to support
the clk_get() lookup or even more -- so that the more obvious
stuff doesn't need constant re-implementation, and so that new
implementations become easier. Platforms would wrap that with
whatever extensions they need.
I've not seen a solid proposal for such a thing, and it's not
clear to me how that would play with with older code (e.g. any
of the ARM implementations).
And I'm sure there are other suggestions ... I was mostly just
wondering just what you were suggesting.
- Dave
^ permalink raw reply
* [PATCH] powerpc: Marvell mv64x60 EDAC platform device setup
From: Dave Jiang @ 2007-07-11 17:43 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, bluesmoke-devel
Creating platform devices (memory controller, sram error registers, cpu error
registers, PCI error registers) for Error Detection and Correction (EDAC)
driver.
The platform devices allow the mv64x60 EDAC driver to detect errors from the
memory controller (ECC erorrs), SRAM controller, CPU data path error registers,
and PCI error registers. The errors are reported to syslog. Software ECC
scrubbing is provided. These replace the mv64x60 error handlers in the ppc
branch. They are being moved to EDAC subsystem in order to centralize error
reporting.
The error reporting can be triggered via interrupts from the mv64x60 bridge chip
or via polling mechanism provided by the EDAC core code.
Signed-off-by: Dave Jiang <djiang@mvista.com>
Acked-by: Dale Farnsworth <dale@farnsworth.org>
---
The patch has been reworked per Paul's comments.
The mv64x60 EDAC driver can be found at:
http://bluesmoke.sourceforge.net/
It's in development to be pushed into the kernel. Still waiting on some core
EDAC code going into the mainline.
arch/powerpc/sysdev/mv64x60_dev.c | 115 +++++++++++++++++++++++++++++++++----
1 files changed, 103 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/sysdev/mv64x60_dev.c b/arch/powerpc/sysdev/mv64x60_dev.c
index b618fa6..bc8cd5a 100644
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -17,6 +17,7 @@
#include <linux/platform_device.h>
#include <asm/prom.h>
+#include <asm/io.h>
/*
* These functions provide the necessary setup for the mv64x60 drivers.
@@ -390,30 +391,120 @@ error:
return err;
}
+static int __init mv64x60_edac_pdev_init(struct device_node *np,
+ int id,
+ int num_addr,
+ char *pdev_name)
+{
+ struct resource *r;
+ struct platform_device *pdev;
+ int i, ret;
+
+ r = kzalloc(num_addr * sizeof(*r) + sizeof(*r), GFP_KERNEL);
+ if (!r)
+ return -ENOMEM;
+
+ for (i = 0; i < num_addr; i++) {
+ ret = of_address_to_resource(np, i, &r[i]);
+ if (ret) {
+ kfree(r);
+ return ret;
+ }
+ }
+
+ of_irq_to_resource(np, 0, &r[i]);
+
+ pdev = platform_device_register_simple(pdev_name, id, r, num_addr + 1);
+
+ kfree(r);
+
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+
+ return 0;
+}
+
+#ifdef CONFIG_PCI
+/*
+ * Bit 0 of MV64x60_PCIx_ERR_MASK does not exist on the 64360 and because of
+ * errata FEr-#11 and FEr-##16 for the 64460, it should be 0 on that chip as
+ * well. IOW, don't set bit 0.
+ */
+#define MV64X60_PCIx_ERR_MASK_VAL 0x00a50c24
+
+/* Erratum FEr PCI-#16: clear bit 0 of PCI SERRn Mask reg. */
+static int __init mv64x60_pci_fixup(struct device_node *np)
+{
+ struct resource res;
+ void __iomem *pci_serr;
+ int ret;
+
+ ret = of_address_to_resource(np, 1, &res);
+ if (ret)
+ return ret;
+
+ pci_serr = ioremap(res.start, res.end - res.start + 1);
+ if (!pci_serr)
+ return -ENOMEM;
+
+ out_le32(pci_serr, in_le32(pci_serr) & ~0x1);
+ iounmap(pci_serr);
+
+ return 0;
+}
+#endif /* CONFIG_PCI */
+
static int __init mv64x60_device_setup(void)
{
struct device_node *np = NULL;
int id;
int err;
- for (id = 0;
- (np = of_find_compatible_node(np, "serial", "marvell,mpsc")); id++)
- if ((err = mv64x60_mpsc_device_setup(np, id)))
+ id = 0;
+ for_each_compatible_node(np, "serial", "marvell,mpsc")
+ if ((err = mv64x60_mpsc_device_setup(np, id++)))
+ goto error;
+
+ id = 0;
+ for_each_compatible_node(np, "network", "marvell,mv64x60-eth")
+ if ((err = mv64x60_eth_device_setup(np, id++)))
goto error;
- for (id = 0;
- (np = of_find_compatible_node(np, "network",
- "marvell,mv64x60-eth"));
- id++)
- if ((err = mv64x60_eth_device_setup(np, id)))
+ id = 0;
+ for_each_compatible_node(np, "i2c", "marvell,mv64x60-i2c")
+ if ((err = mv64x60_i2c_device_setup(np, id++)))
goto error;
- for (id = 0;
- (np = of_find_compatible_node(np, "i2c", "marvell,mv64x60-i2c"));
- id++)
- if ((err = mv64x60_i2c_device_setup(np, id)))
+ id = 0;
+ for_each_compatible_node(np, NULL, "marvell,mv64x60-mem-ctrl")
+ if ((err = mv64x60_edac_pdev_init(np, id++, 1,
+ "mv64x60_mc_err")))
goto error;
+ id = 0;
+ for_each_compatible_node(np, NULL, "marvell,mv64x60-cpu-error")
+ if ((err = mv64x60_edac_pdev_init(np, id++, 2,
+ "mv64x60_cpu_err")))
+ goto error;
+
+ id = 0;
+ for_each_compatible_node(np, NULL, "marvell,mv64x60-sram-ctrl")
+ if ((err = mv64x60_edac_pdev_init(np, id++, 1,
+ "mv64x60_sram_err")))
+ goto error;
+
+#ifdef CONFIG_PCI
+ id = 0;
+ for_each_compatible_node(np, NULL, "marvell,mv64x60-pci-error") {
+ if ((err = mv64x60_pci_fixup(np)))
+ goto error;
+
+ if ((err = mv64x60_edac_pdev_init(np, id++, 1,
+ "mv64x60_pci_err")))
+ goto error;
+ }
+#endif
+
return 0;
error:
^ permalink raw reply related
* Re: [RFC][PATCH 6/8] Walnut DTS
From: Segher Boessenkool @ 2007-07-11 17:49 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1184162389.32199.65.camel@weaponx.rchland.ibm.com>
> + UIC0: interrupt-controller0 {
Why not just "interrupt-controller"?
> + #address-cells = <0>;
> + #size-cells = <0>;
No need for these.
>
> + plb {
> + ranges;
Please make the valid address ranges explicit here.
> + SDRAM0: memory-controller {
> + compatible = "ibm,sdram-405gp", "ibm,sdram-440gp";
It's a bit weird to mention 440 here, since 405 is older.
Not a real problem, but if you still can change all relevant
OS code and device trees, I'd swap it around (make 440 trees
include the 405 "compatible" value). Can you still do that
or is there a too big installed base already?
> + POB0: opb {
> + ranges;
Similar question as for PLB here.
> + UART0: serial@ef600300 {
> + current-speed = <2580>;
Write this in decimal?
Quite a nice tree btw :-)
Segher
^ permalink raw reply
* Re: PageFault when I write in the Serial registers, MMU ?
From: Josh Boyer @ 2007-07-11 17:51 UTC (permalink / raw)
To: Bhupender Saharan; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <720399a30707110932n5a4ddb33u552f5b01921f34b5@mail.gmail.com>
On Wed, 2007-07-11 at 09:32 -0700, Bhupender Saharan wrote:
> Hi,
>
> You could call io_block_mapping function from your setup.c file that
> will add the entry into MMU.
io_block_mapping doesn't exist in the arch/powerpc tree.
josh
^ permalink raw reply
* Re: [PATCH] Fix mpc7448hpc2 tsi108 device_type bug
From: Segher Boessenkool @ 2007-07-11 17:51 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras, David Gibson
In-Reply-To: <1184165950.24563.11.camel@localhost.localdomain>
>>> Fix mpc7448hpc2 tsi108 device_type bug.
>>> Wrong device type will break the board startup.
>>
>>> - device_type = "tsi108-bridge";
>>> + device_type = "tsi-bridge";
>>
>> The OS code shouldn't use "device_type" at all for this,
>> but "compatible" instead. You might want to fix that.
> I can understand you. Should we separate it into two steps:
> (1) Fix the bug in old style to ensure the board work. I can see
> other
> code in kernel tree will be affected by removing "device_type".
> (2) Using compatible instead of device_type for all associated boards
> and code.
Yes, good plan.
>> This patch is fine until you do of course.
> That is fine.
This is your step (1) :-)
Segher
^ permalink raw reply
* Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.
From: Segher Boessenkool @ 2007-07-11 17:53 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus, Zhang Wei-r63237
In-Reply-To: <4694F608.2090503@freescale.com>
>>> I'd rather just treat the different DMA channels as independent
>>> devices,
>>> rather than children of a dma "bus", and change the compatible
>>> name if
>>> they're not general purpose. There's only one register that's
>>> shared
>>> among the channels, and it's a superfluous status summary register.
>>>
>> Your and my ideas are both sides of a coin. :-)
>
> I think there's a substantive difference between them. Making each
> channel an independent device makes it easier for other drivers to
> use them.
True. If the DMA channels are independent enough, putting them
in nodes of their own isn't too cumbersome, either.
Segher
^ permalink raw reply
* Re: [RFC][PATCH 6/8] Walnut DTS
From: Josh Boyer @ 2007-07-11 17:55 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <4EAC985A-2F04-465D-AB69-C67807310D7B@kernel.crashing.org>
On Wed, 2007-07-11 at 19:49 +0200, Segher Boessenkool wrote:
> > + UIC0: interrupt-controller0 {
>
> Why not just "interrupt-controller"?
Copy/paste error from Ebony DTS, which has multiple UICs. Will fix.
>
> > + #address-cells = <0>;
> > + #size-cells = <0>;
>
> No need for these.
Ok.
> >
> > + plb {
> > + ranges;
>
> Please make the valid address ranges explicit here.
Meaning what exactly? I thought just specifying "ranges;" simply said
"the addresses from this node don't have any translation from the parent
node" (or something like that).
>
> > + SDRAM0: memory-controller {
> > + compatible = "ibm,sdram-405gp", "ibm,sdram-440gp";
>
> It's a bit weird to mention 440 here, since 405 is older.
> Not a real problem, but if you still can change all relevant
> OS code and device trees, I'd swap it around (make 440 trees
> include the 405 "compatible" value). Can you still do that
> or is there a too big installed base already?
The installed base for 440 exists of exactly 1 completely non-functional
board ;). I can change it.
>
> > + POB0: opb {
> > + ranges;
>
> Similar question as for PLB here.
>
> > + UART0: serial@ef600300 {
> > + current-speed = <2580>;
>
> Write this in decimal?
In a comment? Or?
> Quite a nice tree btw :-)
Thanks! Easy to do when there's nothing in it ;)
josh
^ permalink raw reply
* Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.
From: Segher Boessenkool @ 2007-07-11 18:01 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <4694F7A2.6040403@freescale.com>
>>> Some hardware has DMA channels hardwired to certain peripherals,
>>> such as
>>> an audio codec. This keeps them from being used as general
>>> purpose DMA
>>> channels.
>> I think you need this knowledge in the kernel drivers anyway,
>> or at the very least, the device node for for example that
>> audio codec needs to refer to the DMA channel in the device
>> tree, so this "reserved" property is unnecessary.
>
> The generic DMA driver needs to know not to touch the reserved
> channels.
The generic DMA driver can look at the device tree, too. It's
more convenient to only have to look at the dma-controller node,
true. But with the proposed tree you have to look at all the
channel nodes already.
>>> I'd rather just treat the different DMA channels as independent
>>> devices,
>>> rather than children of a dma "bus", and change the compatible
>>> name if
>>> they're not general purpose. There's only one register that's
>>> shared
>>> among the channels, and it's a superfluous status summary register.
>> If you make separate nodes for the channels, they need to have
>> a parent. I don't think it makes sense to have the channel
>> nodes and the "master" node as siblings -- maybe it all should
>> be just one node with a "#channels" property or such?
>
> I don't see the need for a master node -- there are no shared
> registers (other than a redundant read-only status summary
> register) to synchronize access to. Each channel would be an
> independent device under the SoC bus.
The "master" node is needed to describe its register block. It
doesn't matter whether you want to use those registers currently
or not.
> The benefit is that if a channel needs to be driven by (for
> example) a sound driver, it can have a different compatible that
> will be matched by the sound driver,
Nah, the sound node should just point to the channel node, or
point to the DMA controller and describe the channel # some
other way. There is no need to make a special "sound DMA
channel" device name.
> and the generic DMA driver will never see it unless the sound
> driver explicitly chooses to make use of the generic DMA code --
> and most of the time I think it'd be simpler for the special-
> purpose driver to manage the descriptors itself.
Sure. But you yourself already say "most of the time" -- and
the device tree doesn't describe how the kernel uses the hardware,
it simply describes the hardware itself. The sound DMA channel
is part of the DMA controller, it is only _connected_ to the
sound controller, it shouldn't be described as being more closely
connected to the sound stuff than it actually is.
Segher
^ permalink raw reply
* Tickless Hz/hrtimers/etc. on PowerPC
From: Matt Sealey @ 2007-07-11 18:06 UTC (permalink / raw)
To: ppc-dev
Does anyone have the definitive patchset to enable the tickless hz,
some kind of hrtimer and the other related improvements in the
PowerPC tree?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [RFC][PATCH 6/8] Walnut DTS
From: Segher Boessenkool @ 2007-07-11 18:07 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1184176531.32199.81.camel@weaponx.rchland.ibm.com>
>>> + plb {
>>> + ranges;
>>
>> Please make the valid address ranges explicit here.
>
> Meaning what exactly? I thought just specifying "ranges;" simply said
> "the addresses from this node don't have any translation from the
> parent
> node" (or something like that).
Just list the actual ranges that sit on the PLB bus. It is
good to be more explicit with these things (for example, the
kernel will have more information to work from when deciding
whether to apply a certain workaround for broken device trees
or not).
>>> + SDRAM0: memory-controller {
>>> + compatible = "ibm,sdram-405gp", "ibm,sdram-440gp";
>>
>> It's a bit weird to mention 440 here, since 405 is older.
>> Not a real problem, but if you still can change all relevant
>> OS code and device trees, I'd swap it around (make 440 trees
>> include the 405 "compatible" value). Can you still do that
>> or is there a too big installed base already?
>
> The installed base for 440 exists of exactly 1 completely non-
> functional
> board ;). I can change it.
Yes exactly, let's do that while we still can.
>>> + UART0: serial@ef600300 {
>>> + current-speed = <2580>;
>>
>> Write this in decimal?
>
> In a comment? Or?
Just in the code. The syntax is <d#9600> I believe?
>> Quite a nice tree btw :-)
>
> Thanks! Easy to do when there's nothing in it ;)
Well I didn't want to put it like that, but since you bring it
up yourself... :-)
Segher
^ permalink raw reply
* Re: Tickless Hz/hrtimers/etc. on PowerPC
From: Sergei Shtylyov @ 2007-07-11 18:17 UTC (permalink / raw)
To: Matt Sealey; +Cc: ppc-dev
In-Reply-To: <46951C1A.4080001@genesi-usa.com>
Hello.
Matt Sealey wrote:
> Does anyone have the definitive patchset to enable the tickless hz,
> some kind of hrtimer and the other related improvements in the
> PowerPC tree?
Look into the -rt patch which has the all this (minus TOD vsyscalls).
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.
From: Scott Wood @ 2007-07-11 18:18 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus
In-Reply-To: <01035B4E-01EB-479A-9AA7-BCFBF6C60904@kernel.crashing.org>
Segher Boessenkool wrote:
> The generic DMA driver can look at the device tree, too. It's more
> convenient to only have to look at the dma-controller node, true.
> But with the proposed tree you have to look at all the channel nodes
> already.
But if the only way to tell is a phandle from the sound device, it has
to look at the sound node as well, and somehow figure out where in the
sound node the phandle is stored.
>> I don't see the need for a master node -- there are no shared
>> registers (other than a redundant read-only status summary
>> register) to synchronize access to. Each channel would be an
>> independent device under the SoC bus.
>
>
> The "master" node is needed to describe its register block. It
> doesn't matter whether you want to use those registers currently or
> not.
It doesn't have a register block, as such. There's one fairly useless
read-only register, that if we really wanted to we could describe as a
second reg resource in each channel, combined with a channel-ID property.
I'm not inclined to bother, though -- not because we don't currently use
it, but because I have a hard time seeing anyone needing to use it.
There is no information in that register that is not the individual
channels' registers. I'd just lump it in with all of the other assorted
SoC registers that we don't describe in the device tree.
>> The benefit is that if a channel needs to be driven by (for
>> example) a sound driver, it can have a different compatible that
>> will be matched by the sound driver,
>
>
> Nah, the sound node should just point to the channel node, or point
> to the DMA controller and describe the channel # some other way.
> There is no need to make a special "sound DMA channel" device name.
It's by far the simplest way to tell the generic DMA driver "do not
touch". "fsl,mpc8548-dma" says "this is a generic, mem-to-mem DMA
channel". "fsl,mpc8548-audio-dma" says "this is a non-generic DMA
channel, hooked up to an audio codec".
Would you prefer something like "fsl,mpc8548-dma-special-purpose"?
Though there's also the possibility that there might be no other node to
indicate the function, and that the only way to program the device is to
start DMA.
> Sure. But you yourself already say "most of the time" -- and the
> device tree doesn't describe how the kernel uses the hardware, it
> simply describes the hardware itself.
Precisely. If the fsl,whatever-audio-dma driver wants to call the
generic DMA code, it can do so without the device tree's help. I see no
reason to give the mem-to-mem DMA driver special status compared to
other users of the DMA channels.
> The sound DMA channel is part of the DMA controller, it is only
> _connected_ to the sound controller, it shouldn't be described as
> being more closely connected to the sound stuff than it actually is.
It's not as if I'm suggesting making it a child of the sound node --
just that each channel be a separate SoC-level device, and only
mem-to-mem channels match the mem-to-mem driver.
-Scott
^ permalink raw reply
* DEFINE_IDR() and the layer cache
From: Joachim Fenkes @ 2007-07-11 18:27 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev, jim.houston; +Cc: Stefan Roscher, Christoph Raisch
Hi all,
while the idr discussion is still hot, there's another thing that caught my
eye recently:
As to my reading of idr.h, I have two choices of initializing a global idr:
a) static struct idr foo; /* ... */ idr_init(&foo);
b) static DEFINE_IDR(foo);
idr_init(), when called for the first time, sets up the layer
cache. idr_get_new() and friends expect the cache to exist. Now, what happens
if the first call to idr_get_new() targets an idr initialized using
DEFINE_IDR() before idr_init() has been called at least once? Could this
happen?
My $0.02,
Joachim
^ permalink raw reply
* Re: Tickless Hz/hrtimers/etc. on PowerPC
From: Michael Neuling @ 2007-07-11 18:33 UTC (permalink / raw)
To: Matt Sealey; +Cc: ppc-dev
In-Reply-To: <46951C1A.4080001@genesi-usa.com>
> Does anyone have the definitive patchset to enable the tickless hz,
> some kind of hrtimer and the other related improvements in the PowerPC
> tree?
Tony Breeds has been looking at this. I think he wanted to clean his
patch set up before he posted it.
Mikey
^ permalink raw reply
* Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.
From: Segher Boessenkool @ 2007-07-11 18:43 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <46951EE0.6040603@freescale.com>
>> The generic DMA driver can look at the device tree, too. It's more
>> convenient to only have to look at the dma-controller node, true.
>> But with the proposed tree you have to look at all the channel nodes
>> already.
>
> But if the only way to tell is a phandle from the sound device, it has
> to look at the sound node as well, and somehow figure out where in the
> sound node the phandle is stored.
Yes, like I said, not very convenient. I don't find a property
per channel to be all that convenient either, but hey that's
just me I suppose. Either way, the "reserved" property isn't
*needed*. It's misnamed too btw; the hardware doesn't reserve
anything (how could it?); maybe the channel is unusable for
general purpose stuff though, dunno.
>>> I don't see the need for a master node -- there are no shared
>>> registers (other than a redundant read-only status summary
>>> register) to synchronize access to. Each channel would be an
>>> independent device under the SoC bus.
>> The "master" node is needed to describe its register block. It
>> doesn't matter whether you want to use those registers currently or
>> not.
>
> It doesn't have a register block, as such. There's one fairly useless
> read-only register,
There's your register block. 21000..210ff or what was it.
> that if we really wanted to we could describe as a
> second reg resource in each channel, combined with a channel-ID
> property.
You cannot describe one register in two different nodes.
> I'm not inclined to bother, though -- not because we don't
> currently use
> it, but because I have a hard time seeing anyone needing to use it.
Unless you're sure no one ever wants to use it, it should be in
the device tree.
> There is no information in that register that is not the individual
> channels' registers.
People use it to get the status of all registers at once. I/O reads
aren't cheap...
> I'd just lump it in with all of the other assorted
> SoC registers that we don't describe in the device tree.
>
>>> The benefit is that if a channel needs to be driven by (for
>>> example) a sound driver, it can have a different compatible that
>>> will be matched by the sound driver,
>> Nah, the sound node should just point to the channel node, or point
>> to the DMA controller and describe the channel # some other way.
>> There is no need to make a special "sound DMA channel" device name.
>
> It's by far the simplest way to tell the generic DMA driver "do not
> touch". "fsl,mpc8548-dma" says "this is a generic, mem-to-mem DMA
> channel".
I would expect it to mean "this is the 8548 DMA controller".
> "fsl,mpc8548-audio-dma" says "this is a non-generic DMA channel,
> hooked up to an audio codec".
So this DMA channel cannot be used for general purpose stuff
at all?
> Would you prefer something like "fsl,mpc8548-dma-special-purpose"?
Just don't overload the "compatible" property with extra semantics.
Just add some extra property (I'm not happy about "reserved", but
_some_ new property is the way to go).
> Though there's also the possibility that there might be no other
> node to indicate the function, and that the only way to program the
> device is to start DMA.
>
>> Sure. But you yourself already say "most of the time" -- and the
>> device tree doesn't describe how the kernel uses the hardware, it
>> simply describes the hardware itself.
>
> Precisely. If the fsl,whatever-audio-dma driver wants to call the
> generic DMA code, it can do so without the device tree's help. I
> see no reason to give the mem-to-mem DMA driver special status
> compared to other users of the DMA channels.
Sure, we agree on this. It is prudent to describe in the sound
node which DMA channel is associated with the sound thing though,
even if this is a SoC and all that. It is just describing the
hardware; if your sound driver wants to hardcode the DMA stuff,
that's fine with me, but that's no reason to not describe the
relation in the device tree.
>> The sound DMA channel is part of the DMA controller, it is only
>> _connected_ to the sound controller, it shouldn't be described as
>> being more closely connected to the sound stuff than it actually is.
>
> It's not as if I'm suggesting making it a child of the sound node
> -- just that each channel be a separate SoC-level device, and only
> mem-to-mem channels match the mem-to-mem driver.
I see no reason to pretend the non-mem-to-mem channels are somehow
different from the mem-to-mem channels.
Segher
^ permalink raw reply
* Re: [patch 5/6] Update the 83xx/85xx/86xx boards device tree
From: Segher Boessenkool @ 2007-07-11 18:49 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1184122420.22066.35.camel@localhost.localdomain>
>>> Indentify pci, pcie host by compatible property
>>> "fsl,mpc83xx-pci","83xx"
>>> "fsl,mpc85xx-pci","85xx"
>>> "fsl,mpc86xx-pci","86xx"
>>> and
>>> "fsl, mpc85xx-pciex","85xx"
>>> "fsl, mpc86xx-pciex","86xx"
>>
>> This can't ever work --
> It works!
How can any driver match for "85xx" if two completely different
devices use it as device name?
>> if you see "compatible" = "85xx",
>> what is it?
> That's why I remove the original compatible "85xx".
All entries in "compatible" are independent of each other. So
there still is a "85xx" in there.
>> PCI or PCIe? Or something else perhaps, maybe
>> a CPU or an I2C controller or who-knows-what?
> I just think the compatible field
> "fsl,mpc83xx-pci","83xx"
> has some redundant information.
> Kumar don't want to break anything using the old
> information.
Yes, you can keep the existing "compatible" for, ahem,
compatibility reasons -- but that doesn't mean you should
add "85xx" to new (incompatible!) nodes.
> We can remove it in the future:-).
I hope so :-)
Segher
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] mmio ide support for mpc8349-itx target
From: Sergei Shtylyov @ 2007-07-11 19:02 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20070710145256.6ac64e11@localhost.localdomain>
Hello.
Vitaly Bordug wrote:
>>>+
>>>+#ifdef CONFIG_MPC834x_ITX
>> Erm, isn't this stuff misplaced? Is this really SoC device? I
>>remember seeng this in the arch/ppc/ platform code before (in the
>>internal tree)...
> The point is to declare methods bsp, as mmio access may effectively vary (having bugs or intentionally) from platform to platform. All-in-one driver approach is nice but might be an issue to handle/maintain.
You misunderstood. Why this was placed in fsl_soc.c and not in the proper
platform code (as it was in the internal tree even)?
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.
From: Scott Wood @ 2007-07-11 19:03 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus
In-Reply-To: <12728378-7DC8-41D9-BCF4-5F883F651E40@kernel.crashing.org>
Segher Boessenkool wrote:
>> that if we really wanted to we could describe as a
>> second reg resource in each channel, combined with a channel-ID
>> property.
>
>
> You cannot describe one register in two different nodes.
Why not? It's read-only.
>> I'm not inclined to bother, though -- not because we don't currently use
>> it, but because I have a hard time seeing anyone needing to use it.
>
>
> Unless you're sure no one ever wants to use it, it should be in
> the device tree.
There are lots of registers that are used that aren't in the device
tree. This one's pretty low on the priority list to get added, IMHO.
>> There is no information in that register that is not the individual
>> channels' registers.
>
> People use it to get the status of all registers at once. I/O reads
> aren't cheap...
On-chip I/O reads shouldn't be all that slow...
>> It's by far the simplest way to tell the generic DMA driver "do not
>> touch". "fsl,mpc8548-dma" says "this is a generic, mem-to-mem DMA
>> channel".
>
>
> I would expect it to mean "this is the 8548 DMA controller".
What if the mem-to-mem channels were explicitly labelled
fsl,mpc8548-dma-mem-to-mem?
>> "fsl,mpc8548-audio-dma" says "this is a non-generic DMA channel,
>> hooked up to an audio codec".
>
> So this DMA channel cannot be used for general purpose stuff
> at all?
I don't know if it *can* or not, though it'd be a pretty unusual way of
using it. In any case, the device tree should be able to handle the
case where it can't.
> Sure, we agree on this. It is prudent to describe in the sound
> node which DMA channel is associated with the sound thing though,
> even if this is a SoC and all that. It is just describing the
> hardware; if your sound driver wants to hardcode the DMA stuff,
> that's fine with me, but that's no reason to not describe the
> relation in the device tree.
Sure, I was never saying that there shouldn't be phandle linkage from
the sound node to the dma channel node. I just don't want the
mem-to-mem driver to have to go to great lengths to figure out whether
it owns the channel.
Phandle linkage the other way could work, though; if the channel has a
phandle set in an attached-device property, then the mem-to-mem driver
leaves it alone.
> I see no reason to pretend the non-mem-to-mem channels are somehow
> different from the mem-to-mem channels.
But they are different, just like an SCC UART is different from an SCC
ethernet, even though they both go through the SCC.
-Scott
^ permalink raw reply
* ML410 PCI support
From: khollan @ 2007-07-11 19:15 UTC (permalink / raw)
To: linuxppc-embedded
I have two questions:
1) Has anyone wrote linux 2.6 PCI drviers for the xilinx development boards.
I want to get the PCI slots working on my board.
2)How do I set the HwAddr for the TEMAC driver? Im using Grants latest git
tree. My board boots and the HwAddr is set to 00:00:00:00:00:00
Thanks for your help
Kevin
--
View this message in context: http://www.nabble.com/ML410-PCI-support-tf4064052.html#a11547023
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox