Re: [PATCH v2 0/3] dmaengine: add per channel capabilities api
On Thu, Jan 10, 2013 at 02:07:03PM -0500, Matt Porter wrote: The call is implemented as follows: struct dmaengine_chan_caps *dma_get_channel_caps(struct dma_chan *chan, enum dma_transfer_direction dir); The dma transfer direction parameter may appear a bit out of place but it is necessary since the direction field in struct dma_slave_config was deprecated. In some cases, EDMA for one, it is necessary for the dmaengine driver to have the burst and address width slave configuration parameters available in order to compute the maximum segment size that can be handle. Due to this requirement, the calling order of this api is as follows: Well you are passing direction as argument so even in EDMA it doesn't seem to help you as you seem to need burst and width!. So why do you even need the direction to compute the capablities -- ~Vinod ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 1/3] dmaengine: add dma_get_channel_caps()
On Thu, Jan 10, 2013 at 02:07:04PM -0500, Matt Porter wrote:
+/* struct dmaengine_chan_caps - expose capability of a channel
+ * Note: each channel can have same or different capabilities
+ *
+ * This primarily classifies capabilities into
+ * a) APIs/ops supported
+ * b) channel physical capabilities
+ *
+ * @cap_mask: api/ops capability (DMA_INTERRUPT and DMA_PRIVATE
+ * are invalid api/ops and will never be set)
+ * @seg_nr: maximum number of SG segments supported on a SG/SLAVE
+ * channel (0 for no maximum or not a SG/SLAVE channel)
+ * @seg_len: maximum length of SG segments supported on a SG/SLAVE
+ *channel (0 for no maximum or not a SG/SLAVE channel)
+ */
+struct dmaengine_chan_caps {
+ dma_cap_mask_t cap_mask;
+ int seg_nr;
+ int seg_len;
+};
Now am really unclear why we would need direction as argument.
Also, I would add the channel physical capablities like direction, widths,
lengths etc supported.
+/**
+ * dma_get_channel_caps - flush pending transactions to HW
flush pending... ???
+ * driver does not implement per channel capbilities then
+ * NULL is returned.
+ */
+static inline struct dmaengine_chan_caps
+*dma_get_channel_caps(struct dma_chan *chan, enum dma_transfer_direction dir)
you need to add this for when CONFIG_DMA_ENGINE is not defined as well.
+{
+ if (chan-device-device_channel_caps)
+ return chan-device-device_channel_caps(chan, dir);
+ return NULL;
+}
+
enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie);
#ifdef CONFIG_DMA_ENGINE
enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx);
--
~Vinod
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 2/3] dma: edma: add device_channel_caps() support
On Thu, Jan 10, 2013 at 02:07:05PM -0500, Matt Porter wrote:
Implement device_channel_caps().
EDMA has a finite set of PaRAM slots available for linking
a multi-segment SG transfer. In order to prevent any one
channel from consuming all PaRAM slots to fulfill a large SG
transfer, the driver reports a static per-channel max number
of SG segments it will handle.
The maximum size of SG segment is limited by the slave config
maxburst and addr_width for the channel in question. These values
are used from the current channel config to calculate and return
the max segment length cap.
Signed-off-by: Matt Porter mpor...@ti.com
---
drivers/dma/edma.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 82c8672..fc4b9db 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -70,6 +70,7 @@ struct edma_chan {
boolalloced;
int slot[EDMA_MAX_SLOTS];
struct dma_slave_config cfg;
+ struct dmaengine_chan_caps caps;
};
struct edma_cc {
@@ -462,6 +463,28 @@ static void edma_issue_pending(struct dma_chan *chan)
spin_unlock_irqrestore(echan-vchan.lock, flags);
}
+static struct dmaengine_chan_caps
+*edma_get_channel_caps(struct dma_chan *chan, enum dma_transfer_direction
dir)
+{
+ struct edma_chan *echan;
+ enum dma_slave_buswidth width = 0;
+ u32 burst = 0;
+
+ if (chan) {
I think this check is redundant.
+ echan = to_edma_chan(chan);
+ if (dir == DMA_MEM_TO_DEV) {
+ width = echan-cfg.dst_addr_width;
+ burst = echan-cfg.dst_maxburst;
Per you API example burst and width is not set yet, so this doesn't make sense
+ } else if (dir == DMA_DEV_TO_MEM) {
+ width = echan-cfg.src_addr_width;
+ burst = echan-cfg.src_maxburst;
+ }
+ echan-caps.seg_len = (SZ_64K - 1) * width * burst;
Also the defination of API is max, above computation doesn't make sense to me!
--
~Vinod
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 0/3] dmaengine: add per channel capabilities api
On Sun, Jan 20, 2013 at 12:37:34PM +, Vinod Koul wrote: On Thu, Jan 10, 2013 at 02:07:03PM -0500, Matt Porter wrote: The call is implemented as follows: struct dmaengine_chan_caps *dma_get_channel_caps(struct dma_chan *chan, enum dma_transfer_direction dir); The dma transfer direction parameter may appear a bit out of place but it is necessary since the direction field in struct dma_slave_config was deprecated. In some cases, EDMA for one, it is necessary for the dmaengine driver to have the burst and address width slave configuration parameters available in order to compute the maximum segment size that can be handle. Due to this requirement, the calling order of this api is as follows: Well you are passing direction as argument so even in EDMA it doesn't seem to help you as you seem to need burst and width!. So why do you even need the direction to compute the capablities Yes, I need burst and width, but they are dependent on direction (dst vs src, as stored in the slave channel config). Ok, so I think I know where this is leading...the problem is probably that I made an implicit dependency on burst and width here. The expectation in this implementation is that dmaengine_slave_config() has already been called and as a result, the dmaengine driver has either src_* or dst_* attributes populated depending on the direction of the channel. Given that, the call to dma_get_channel_caps() needs to provide the direction in order for the driver to know which of src_*/dst_* attributes are valid in order to do the max segment size calculation. An alternative, since the slave driver is the one that provided the info in the first place is: struct dmaengine_chan_caps *dma_get_channel_caps(struct dma_chan *chan, enum dma_slave_buswidth addr_width, u32 maxburst); where the attributes required by the edma driver to find the max segment size are now explicitly provided. This approach also removes the ordering requirement of calling dmaengine_slave_config() first. Is this what you had in mind? -Matt ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 1/3] dmaengine: add dma_get_channel_caps()
On Sun, Jan 20, 2013 at 12:52:43PM +, Vinod Koul wrote:
On Thu, Jan 10, 2013 at 02:07:04PM -0500, Matt Porter wrote:
+/* struct dmaengine_chan_caps - expose capability of a channel
+ * Note: each channel can have same or different capabilities
+ *
+ * This primarily classifies capabilities into
+ * a) APIs/ops supported
+ * b) channel physical capabilities
+ *
+ * @cap_mask: api/ops capability (DMA_INTERRUPT and DMA_PRIVATE
+ *are invalid api/ops and will never be set)
+ * @seg_nr: maximum number of SG segments supported on a SG/SLAVE
+ * channel (0 for no maximum or not a SG/SLAVE channel)
+ * @seg_len: maximum length of SG segments supported on a SG/SLAVE
+ * channel (0 for no maximum or not a SG/SLAVE channel)
+ */
+struct dmaengine_chan_caps {
+ dma_cap_mask_t cap_mask;
+ int seg_nr;
+ int seg_len;
+};
Now am really unclear why we would need direction as argument.
Best explanation is my reply to your comments on 0/3. In summary, the
direction allows the edma driver to select the src vs dst addr_width and
maxburst fields to be used to calculate the max segment size that can
be handled.
Also, I would add the channel physical capablities like direction, widths,
lengths etc supported.
Ok, I can take a stab at this...I didn't bother initially as I don't
have user for that info at this point. Though, I suppose we don't have
an immediate user for the cap_mask either.
+/**
+ * dma_get_channel_caps - flush pending transactions to HW
flush pending... ???
ugh, cp fail...will fix.
+ * driver does not implement per channel capbilities then
+ * NULL is returned.
+ */
+static inline struct dmaengine_chan_caps
+*dma_get_channel_caps(struct dma_chan *chan, enum dma_transfer_direction
dir)
you need to add this for when CONFIG_DMA_ENGINE is not defined as well.
ok, will fix.
+{
+ if (chan-device-device_channel_caps)
+ return chan-device-device_channel_caps(chan, dir);
+ return NULL;
+}
+
enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie);
#ifdef CONFIG_DMA_ENGINE
enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx);
--
~Vinod
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 2/3] dma: edma: add device_channel_caps() support
On Sun, Jan 20, 2013 at 01:03:21PM +, Vinod Koul wrote:
On Thu, Jan 10, 2013 at 02:07:05PM -0500, Matt Porter wrote:
Implement device_channel_caps().
EDMA has a finite set of PaRAM slots available for linking
a multi-segment SG transfer. In order to prevent any one
channel from consuming all PaRAM slots to fulfill a large SG
transfer, the driver reports a static per-channel max number
of SG segments it will handle.
The maximum size of SG segment is limited by the slave config
maxburst and addr_width for the channel in question. These values
are used from the current channel config to calculate and return
the max segment length cap.
Signed-off-by: Matt Porter mpor...@ti.com
---
drivers/dma/edma.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 82c8672..fc4b9db 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -70,6 +70,7 @@ struct edma_chan {
boolalloced;
int slot[EDMA_MAX_SLOTS];
struct dma_slave_config cfg;
+ struct dmaengine_chan_caps caps;
};
struct edma_cc {
@@ -462,6 +463,28 @@ static void edma_issue_pending(struct dma_chan *chan)
spin_unlock_irqrestore(echan-vchan.lock, flags);
}
+static struct dmaengine_chan_caps
+*edma_get_channel_caps(struct dma_chan *chan, enum dma_transfer_direction
dir)
+{
+ struct edma_chan *echan;
+ enum dma_slave_buswidth width = 0;
+ u32 burst = 0;
+
+ if (chan) {
I think this check is redundant.
Yes, will remove.
+ echan = to_edma_chan(chan);
+ if (dir == DMA_MEM_TO_DEV) {
+ width = echan-cfg.dst_addr_width;
+ burst = echan-cfg.dst_maxburst;
Per you API example burst and width is not set yet, so this doesn't make sense
The explanation in the cover letter mentions that dmaengine_slave_config() is
required to be called prior to dmaengine_get_channel_caps(). If we
switch to the alternative API, then that would go away including the
dependency on direction.
+ } else if (dir == DMA_DEV_TO_MEM) {
+ width = echan-cfg.src_addr_width;
+ burst = echan-cfg.src_maxburst;
+ }
+ echan-caps.seg_len = (SZ_64K - 1) * width * burst;
Also the defination of API is max, above computation doesn't make sense to me!
Ok, so in this case, the slave driver has informed the dmaengine driver
that the max burst for the channel is foo. That's in units of
addr_width. On the EDMA DMAC, we program burst transfers by setting ACNT
to our per-transfer width (FIFO width in the slave SG case we are
covering here) then BCNT gets the maxburst setting. We then have a CCNT
field for EDMA that has a limit of SZ_64K-1 transfers. Thus, if a slave
driver tells us the maxburst for the channel is foo and our width is
bar, the maximum size of an SG segment in that configuration is:
(SZ_64K - 1) * bar * foo.
-Matt
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 0/3] dmaengine: add per channel capabilities api
On Sun, Jan 20, 2013 at 11:37:35AM -0500, Matt Porter wrote: On Sun, Jan 20, 2013 at 12:37:34PM +, Vinod Koul wrote: On Thu, Jan 10, 2013 at 02:07:03PM -0500, Matt Porter wrote: The call is implemented as follows: struct dmaengine_chan_caps *dma_get_channel_caps(struct dma_chan *chan, enum dma_transfer_direction dir); The dma transfer direction parameter may appear a bit out of place but it is necessary since the direction field in struct dma_slave_config was deprecated. In some cases, EDMA for one, it is necessary for the dmaengine driver to have the burst and address width slave configuration parameters available in order to compute the maximum segment size that can be handle. Due to this requirement, the calling order of this api is as follows: Well you are passing direction as argument so even in EDMA it doesn't seem to help you as you seem to need burst and width!. So why do you even need the direction to compute the capablities Yes, I need burst and width, but they are dependent on direction (dst vs src, as stored in the slave channel config). Ok, so I think I know where this is leading...the problem is probably that I made an implicit dependency on burst and width here. The expectation in this And also due to wrong documentation. This is what you have put up the flow as: Due to this requirement, the calling order of this api is as follows: 1. Allocate a DMA slave channel 1a. [Optionally] Get channel capabilities 2. Set slave and controller specific parameters 3. Get a descriptor for transaction 4. Submit the transaction 5. Issue pending requests and wait for callback notification Now when we query capablities, slave parameters _are_not_set_. So seems like you have thought something and written something else! Which brings me to the point on what are we trying to query: a) API capability, dont need slave parameters for that b) Sg segment length and numbers: Well these are capabilities, so it tells you what is the maximum I can do. IMO it doesn't make sense to tie it down to burst, width etc. For that configuration you are checking maximum. What this needs to return is what is the maximum length it supports and maximum number of sg list the h/w can use. Also if you return your burst and width capablity, then any client can easily find out what is the length byte value it can hold. If you feel this computaion if client specific, though looking at doesnt make me think so, you can add a callback for this computaion given the parameters. -- ~Vinod ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 2/3] dma: edma: add device_channel_caps() support
On Sun, Jan 20, 2013 at 11:51:08AM -0500, Matt Porter wrote: The explanation in the cover letter mentions that dmaengine_slave_config() is required to be called prior to dmaengine_get_channel_caps(). If we switch to the alternative API, then that would go away including the dependency on direction. Nope you got that wrong! -- ~Vinod ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP
On 1/11/2013 5:53 AM, Robert Tivy wrote:
Adding a remoteproc driver implementation for OMAP-L138 DSP
Signed-off-by: Robert Tivy rt...@ti.com
---
drivers/remoteproc/Kconfig | 23 ++
drivers/remoteproc/Makefile|1 +
drivers/remoteproc/davinci_remoteproc.c| 307
include/linux/platform_data/da8xx-remoteproc.h | 33 +++
naming the driver davinci_remoteproc.c and platform data as
da8xx-remoteproc.h is odd. The driver looks really specific to omap-l138
so may be call the driver da8xx-remoteproc.c?
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 96ce101..7d3a5e0 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -41,4 +41,27 @@ config STE_MODEM_RPROC
This can be either built-in or a loadable module.
If unsure say N.
+config DAVINCI_REMOTEPROC
+ tristate DaVinci DA850/OMAPL138 remoteproc support (EXPERIMENTAL)
+ depends on ARCH_DAVINCI_DA850
+ select REMOTEPROC
+ select RPMSG
+ select FW_LOADER
+ select CMA
+ default n
+ help
+ Say y here to support DaVinci DA850/OMAPL138 remote processors
+ via the remote processor framework.
+
+ You want to say y here in order to enable AMP
+ use-cases to run on your platform (multimedia codecs are
+ offloaded to remote DSP processors using this framework).
+
+ It's safe to say n here if you're not interested in multimedia
+ offloading or just want a bare minimum kernel.
+ This feature is considered EXPERIMENTAL, due to it not having
+ any previous exposure to the general public and therefore
+ limited developer-based testing.
This is probably true in general for remoteproc (I am being warned a lot
by the framework when using it) so may be you can drop this specific
reference.
diff --git a/drivers/remoteproc/davinci_remoteproc.c
b/drivers/remoteproc/davinci_remoteproc.c
new file mode 100644
index 000..fc6fd72
--- /dev/null
+++ b/drivers/remoteproc/davinci_remoteproc.c
@@ -0,0 +1,307 @@
+/*
+ * Remote processor machine-specific module for Davinci
+ *
+ * Copyright (C) 2011-2012 Texas Instruments, Inc.
2013?
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#define pr_fmt(fmt)%s: fmt, __func__
You dont seem to be using this anywhere.
+
+#include linux/kernel.h
+#include linux/err.h
+#include linux/printk.h
+#include linux/bitops.h
+#include linux/platform_device.h
+#include linux/remoteproc.h
+#include linux/platform_data/da8xx-remoteproc.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/irq.h
It will be nice to keep this sorted. It avoids duplicate includes later.
+static char *fw_name;
+module_param(fw_name, charp, S_IRUGO);
+MODULE_PARM_DESC(fw_name, \n\t\tName of DSP firmware file in
/lib/firmware);
+
+/*
+ * OMAP-L138 Technical References:
+ * http://www.ti.com/product/omap-l138
+ */
+#define SYSCFG_CHIPSIG_OFFSET 0x174
+#define SYSCFG_CHIPSIG_CLR_OFFSET 0x178
+#define SYSCFG_CHIPINT0 (1 0)
+#define SYSCFG_CHIPINT1 (1 1)
+#define SYSCFG_CHIPINT2 (1 2)
+#define SYSCFG_CHIPINT3 (1 3)
You can use BIT(x) here.
+
+/**
+ * struct davinci_rproc - davinci remote processor state
+ * @rproc: rproc handle
+ */
+struct davinci_rproc {
+ struct rproc *rproc;
+ struct clk *dsp_clk;
+};
+
+static void __iomem *syscfg0_base;
+static struct platform_device *remoteprocdev;
+static struct irq_data *irq_data;
+static void (*ack_fxn)(struct irq_data *data);
+static int irq;
+
+/**
+ * handle_event() - inbound virtqueue message workqueue function
+ *
+ * This funciton is registered as a kernel thread and is scheduled by the
+ * kernel handler.
+ */
+static irqreturn_t handle_event(int irq, void *p)
+{
+ struct rproc *rproc = platform_get_drvdata(remoteprocdev);
+
+ /* Process incoming buffers on our vring */
+ while (IRQ_HANDLED == rproc_vq_interrupt(rproc, 0))
+ ;
+
+ /* Must allow wakeup of potenitally blocking senders: */
+ rproc_vq_interrupt(rproc, 1);
+
+ return IRQ_HANDLED;
+}
+
+/**
+ * davinci_rproc_callback() - inbound virtqueue message handler
+ *
+ * This handler is invoked directly by the kernel whenever the remote
+ * core (DSP) has modified the state of a virtqueue. There is no
+ * payload message indicating the virtqueue index as is the case with
+ * mailbox-based implementations on OMAP4. As such, this handler polls
+ * each known virtqueue index for every invocation.
+ */
+static irqreturn_t davinci_rproc_callback(int irq, void *p)
+{
+ if (readl(syscfg0_base + SYSCFG_CHIPSIG_OFFSET) SYSCFG_CHIPINT0) {
personally I
[PATCH 0/2] ARM: davinci: da850: add ethernet driver DT support
From: Lad, Prabhakar prabhakar@ti.com This patch set enables Ethernet support through device tree model. Patches are available on [1] for testing. [1] http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git/shortlog/refs/heads/da850_dt Lad, Prabhakar (2): ARM: davinci: da850: add DT node for eth0. ARM: davinci: da850: add OF_DEV_AUXDATA entry for eth0. arch/arm/boot/dts/da850-evm.dts |3 +++ arch/arm/boot/dts/da850.dtsi | 15 +++ arch/arm/mach-davinci/da8xx-dt.c |9 - 3 files changed, 26 insertions(+), 1 deletions(-) -- 1.7.4.1 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 2/2] ARM: davinci: da850: add OF_DEV_AUXDATA entry for eth0.
From: Lad, Prabhakar prabhakar@ti.com
Add OF_DEV_AUXDATA for eth0 driver in da850 board dt
file to use emac clock.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: davinci-linux-open-source@linux.davincidsp.com
Cc: net...@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: Sekhar Nori nsek...@ti.com
Cc: Heiko Schocher h...@denx.de
---
arch/arm/mach-davinci/da8xx-dt.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 37c27af..d548a38 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -37,11 +37,18 @@ static void __init da8xx_init_irq(void)
of_irq_init(da8xx_irq_match);
}
+struct of_dev_auxdata da850_evm_auxdata_lookup[] __initdata = {
+ OF_DEV_AUXDATA(ti,davinci-dm6467-emac, 0x01e2, davinci_emac.1,
+ NULL),
+ {}
+};
+
#ifdef CONFIG_ARCH_DAVINCI_DA850
static void __init da850_init_machine(void)
{
- of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+ of_platform_populate(NULL, of_default_bus_match_table,
+da850_evm_auxdata_lookup, NULL);
da8xx_uart_clk_enable();
}
--
1.7.4.1
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 1/2] ARM: davinci: da850: add DT node for eth0.
From: Lad, Prabhakar prabhakar@ti.com
Add eth0 device tree node information to da850 by
providing interrupt details and local mac address of eth0.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: davinci-linux-open-source@linux.davincidsp.com
Cc: net...@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: Sekhar Nori nsek...@ti.com
Cc: Heiko Schocher h...@denx.de
---
arch/arm/boot/dts/da850-evm.dts |3 +++
arch/arm/boot/dts/da850.dtsi| 15 +++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 37dc5a3..a1d6e3e 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -24,5 +24,8 @@
serial2: serial@1d0d000 {
status = okay;
};
+ eth0: emac@1e2 {
+ status = okay;
+ };
};
};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 640ab75..309cc99 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -56,5 +56,20 @@
interrupt-parent = intc;
status = disabled;
};
+ eth0: emac@1e2 {
+ compatible = ti,davinci-dm6467-emac;
+ reg = 0x22 0x4000;
+ ti,davinci-ctrl-reg-offset = 0x3000;
+ ti,davinci-ctrl-mod-reg-offset = 0x2000;
+ ti,davinci-ctrl-ram-offset = 0;
+ ti,davinci-ctrl-ram-size = 0x2000;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = 33
+ 34
+ 35
+ 36
+ ;
+ interrupt-parent = intc;
+ };
};
};
--
1.7.4.1
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
