[PATCH v5] Frame Buffer driver for TI DA8xx/OMAP-L1xx
Adds LCD controller (LCDC) driver for TI's DA8xx/OMAP-L1xx architecture. LCDC specifications can be found at http://www.ti.com/litv/pdf/sprufm0a. LCDC on DA8xx consists of two independent controllers, the Raster Controller and the LCD Interface Display Driver (LIDD) controller. LIDD further supports character and graphic displays. This patch adds support for the graphic display (Sharp LQ035Q3DG01) found on the DA830 based EVM. The EVM details can be found at: http://support.spectrumdigital.com/boards/dskda830/revc/. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com Signed-off-by: Pavel Kiryukhin pkiryuk...@ru.mvista.com Signed-off-by: Steve Chen sc...@mvista.com --- This patch applies to Linus's Kernel tree. Since the previous version, fb_setcolreg function has been modified for 8 bit mode. drivers/video/Kconfig| 11 + drivers/video/Makefile |1 + drivers/video/da8xx-fb.c | 900 ++ include/video/da8xx-fb.h | 106 ++ 4 files changed, 1018 insertions(+), 0 deletions(-) create mode 100644 drivers/video/da8xx-fb.c create mode 100644 include/video/da8xx-fb.h diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 8afcf08..d048b7e 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -2038,6 +2038,17 @@ config FB_SH7760 and 8, 15 or 16 bpp color; 90 degrees clockwise display rotation for panels = 320 pixel horizontal resolution. +config FB_DA8XX +tristate DA8xx/OMAP-L1xx Framebuffer support +depends on FB ARCH_DAVINCI_DA830 + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + ---help--- + This is the frame buffer device driver for the TI LCD controller + found on DA8xx/OMAP-L1xx SoCs. + If unsure, say N. + config FB_VIRTUAL tristate Virtual Frame Buffer support (ONLY FOR TESTING!) depends on FB diff --git a/drivers/video/Makefile b/drivers/video/Makefile index 01a819f..288d9b0 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -136,6 +136,7 @@ obj-$(CONFIG_FB_OF) += offb.o obj-$(CONFIG_FB_BF54X_LQ043) += bf54x-lq043fb.o obj-$(CONFIG_FB_BFIN_T350MCQB) += bfin-t350mcqb-fb.o obj-$(CONFIG_FB_MX3) += mx3fb.o +obj-$(CONFIG_FB_DA8XX) += da8xx-fb.o # the test framebuffer is last obj-$(CONFIG_FB_VIRTUAL) += vfb.o diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c new file mode 100644 index 000..4b9d80b --- /dev/null +++ b/drivers/video/da8xx-fb.c @@ -0,0 +1,900 @@ +/* + * Copyright (C) 2008-2009 MontaVista Software Inc. + * Copyright (C) 2008-2009 Texas Instruments Inc + * + * Based on the LCD driver for TI Avalanche processors written by + * Ajay Singh and Shalom Hai. + * + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#include linux/module.h +#include linux/kernel.h +#include linux/fb.h +#include linux/dma-mapping.h +#include linux/device.h +#include linux/platform_device.h +#include linux/uaccess.h +#include linux/device.h +#include linux/interrupt.h +#include linux/clk.h +#include video/da8xx-fb.h + +#define DRIVER_NAME da8xx_lcdc + +/* LCD Status Register */ +#define LCD_END_OF_FRAME0 BIT(8) +#define LCD_FIFO_UNDERFLOW BIT(5) +#define LCD_SYNC_LOST BIT(2) + +/* LCD DMA Control Register */ +#define LCD_DMA_BURST_SIZE(x) ((x) 4) +#define LCD_DMA_BURST_10x0 +#define LCD_DMA_BURST_20x1 +#define LCD_DMA_BURST_40x2 +#define LCD_DMA_BURST_80x3 +#define LCD_DMA_BURST_16 0x4 +#define LCD_END_OF_FRAME_INT_ENA BIT(2) +#define LCD_DUAL_FRAME_BUFFER_ENABLE BIT(0) + +/* LCD Control Register */ +#define LCD_CLK_DIVISOR(x) ((x) 8) +#define LCD_RASTER_MODE0x01 + +/* LCD Raster Control Register */ +#define LCD_PALETTE_LOAD_MODE(x) ((x) 20) +#define PALETTE_AND_DATA 0x00 +#define PALETTE_ONLY 0x01 + +#define LCD_MONO_8BIT_MODE BIT(9) +#define LCD_RASTER_ORDER BIT(8) +#define LCD_TFT_MODE BIT(7) +#define LCD_UNDERFLOW_INT_ENA BIT(6) +#define
DM6443 Cursor Window practical use case
Hi, From the VPBE user's guide I understand that the Cursor window can display only a rectangular cursor which is transparent within. I cannot display a Bitmap cursor. Is this understanding of mine correct? Can some one explain me what can be a practical use case for the rectangular cursor being displayed in in the Cursor window? I read the example in VPBE user's guide, still in that case also whats the practical use case for a Bitmap cursor displayed on OSD and surrounded with rectangular cursor boundary? Thanks and regards -Nitin Get your new Email address! Grab the Email name you#39;ve always wanted before someone else does! http://mail.promotions.yahoo.com/newdomains/aa/ ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
anyone knows about the networked encode and decode demo?
Hi, Does anyone knows abouth the networked encode and decode demo? That is the infomation about it: http://wiki.davincidsp.com/index.php?title=Networked_encode_and_decode_demos#Changes_in_control_thread_.28_optional.29 : Could some one give me some helps about that? or share your source code about the project? Thank you~~ -- Best Regards! zhangshaofeng @Xi'an JiaoTong University ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
spi master and slave device and driver
my dm6446 has a spi interface, I use it as the spi master device. In my board, there is also a chip --mcp2510, which has also a spi interface. I use the mcp2510's spi as the slave device. In my project, I want to use the spidev, which is available since linux 2.6.18 kernel, to talk to the spi slave device in user space. I make this spidev device to list in the spi_board_info struct with field chip_select = 0. when the spidev driver is registered, the spidev device is also added to the spi_bus. But when I want to register the mcp2510's spi driver, I find that this driver can not find the proper spi device to attach(The spi device registered in spi_bus is attached to the spidev drivers). How can I solve the problem? I think that whether I can also join the mcp_2510's spi into the spi_board_info struct array, so it can also be register as a device in spi_bus with the function spi_register_board_info(). But when I do like it, how can I set the field chip_select of spi_board_info struct? My dm6446's spi interface is connected to mcp2510's spi by the chip_select signal--EN0. I think that spi_master can't use EN0 to control two slave spi devices. How can i do it? 2009-07-06 邹卫军 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Booting via NOR FLash- DM6467
Hi , I am using custom board consisting of DM6467 Davinci processor. I am trying to boot the processor from an on-board NOR flash, by burning ubl and u-boot to the NOR flash. AFter burning the NOR flash with u-boot, I get the following series of messages sfh_Dm646x.exe -norflash -v ubl_DM646x_nor.bin u-boot.bin - TI Serial Flasher Host Program for DM646x (C) 2009, Texas Instruments, Inc. Ver. 1.50 - Platform is Windows. Flashing NOR with ubl_DM646x_nor.bin and u-boot.bin. Attempting to connect to device COM1... Press any key to end this program at any time. Waiting for the DM646x... Target: BOOTME BOOTME commmand received. Returning ACK and header... ACK command sent. Waiting for BEGIN command... Target: BEGIN BEGIN commmand received. Sending CRC table... 100% [ ] CRC table sent Waiting for DONE... Target:DONE DONE received. Sending the UBL... 100% [ ] UBL sent Target:DONE DONE received. UBL was accepted. UBL transmitted successfully. Waiting for SFT on the DM646x... Target: Starting UART Boot... Target: BOOTUBL BOOTUBL commmand received. Returning CMD and command... CMD value sent. Waiting for DONE... Target:DONE DONE received. Command was accepted. Sending the UBL image Waiting for SENDIMG sequence... Target: CFI Query...passed. Target: NOR Initialization: Target: Command Set: AMD Target: Manufacturer: AMD Target: Size: 0x0010 MB Target: SENDIMG SENDIMG received. Returning ACK and header for image data... ACK command sent. Waiting for BEGIN command... Target: BEGIN BEGIN commmand received. 100% [ ] Image data sent... Waiting for DONE... Target:DONE DONE received. All bytes of image data received... Target: Erasing the NOR Flash Target: Erased through 0x4202 Target: Erase Completed Target: Writing UBL to NOR flash Target: Writing the NOR Flash Target: NOR Write OK through 0x42002C08. Target:DONE Sending the Application image Waiting for SENDIMG sequence... Target: SENDIMG SENDIMG received. Returning ACK and header for image data... ACK command sent. Waiting for BEGIN command... Target: BEGIN BEGIN commmand received. 100% [ ] Image data sent... Waiting for DONE... Target:DONE DONE received. All bytes of image data received... Target: Erasing the NOR Flash Target: Erased through 0x4204 Target: Erase Completed Target: Writing APP to NOR flash Target: Writing the NOR Flash Target: NOR Write OK through 0x42020010. Target: Writing the NOR Flash Target: NOR Write OK through 0x42028000. Target: NOR Write OK through 0x4203. Target: NOR Write OK through 0x42038000. Target: NOR Write OK through 0x420383F0. Target:DONE Target:DONE Operation completed successfully. AFter shifting to NOR Boot mode, however, I get BOOTME message continuously on Hyperterminal as if no u-boot has been loaded. Can someone point out whether I am missing something? I am using u-boot 1.2.0 version and ubl present in DM646x_FlashAndBootUtils version 1.50. I am using sfh_DM646x.exe utitilty present in the same, to burn my flash. My Flash no. is S29GL128P90TFIR2 from SPANSION. Thanks and Regards, Sidharth ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2] davinci_emac: fix kernel oops when changing MAC address while interface is down
Check that network interface is running before changing its MAC address.
Otherwise, rxch is accessed when it's NULL - causing a kernel oops.
Moreover, check that the new MAC address is valid.
Signed-off-by: Pablo Bitton pablo.bit...@gmail.com
Signed-off-by: Chaithrika U S chaithr...@ti.com
Tested-by: Chaithrika U S chaithr...@ti.com
[tested on DM6467 EVM]
---
drivers/net/davinci_emac.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index cf689a0..dddb2b9 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -1821,11 +1821,19 @@ static int emac_dev_setmac_addr(struct net_device
*ndev, void *addr)
struct sockaddr *sa = addr;
DECLARE_MAC_BUF(mac);
+ if (!is_valid_ether_addr(sa-sa_data))
+ return -EINVAL;
+
/* Store mac addr in priv and rx channel and set it in EMAC hw */
memcpy(priv-mac_addr, sa-sa_data, ndev-addr_len);
- memcpy(rxch-mac_addr, sa-sa_data, ndev-addr_len);
memcpy(ndev-dev_addr, sa-sa_data, ndev-addr_len);
- emac_setmac(priv, EMAC_DEF_RX_CH, rxch-mac_addr);
+
+ /* If the interface is down - rxch is NULL. */
+ /* MAC address is configured only after the interface is enabled. */
+ if (netif_running(ndev)) {
+ memcpy(rxch-mac_addr, sa-sa_data, ndev-addr_len);
+ emac_setmac(priv, EMAC_DEF_RX_CH, rxch-mac_addr);
+ }
if (netif_msg_drv(priv))
dev_notice(emac_dev, DaVinci EMAC: emac_dev_setmac_addr %s\n,
--
1.5.4.3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Reg. two out buffers in encoding of DM6446
Hi,
I want to read the motion vector in another buffer which i pass from
application.
Already i am allocating the memory using Memory_ContigAlloc()
XDAS_Int32 inBufSizeArray[1];
XDAS_Int8 OutPutBuffers[2];
OutPutBuffers[0] = outBuf;
OutPutBuffers[1] = MotionVecData;
XDAS_Int32 outBufSizeArray[2];
XDAS_Int32 status;
XDM_BufDesc inBufDesc;
XDM_BufDesc outBufDesc;
VIDENC_InArgs inArgs;
VIDENC_OutArgs outArgs;
inBufSizeArray[0] = inBufSize;
outBufSizeArray[0] = outBufMaxSize; //Encoded data
outBufSizeArray[1] = MotionVecSize; //Motion vector
inBufDesc.numBufs = 1;
inBufDesc.bufSizes = inBufSizeArray;
inBufDesc.bufs = (XDAS_Int8 **) inBuf;
outBufDesc.numBufs = 2;
outBufDesc.bufSizes = outBufSizeArray;
outBufDesc.bufs = OutPutBuffers;
inArgs.size = sizeof(VIDENC_InArgs);
outArgs.size= sizeof(VIDENC_OutArgs);
/* Encode video buffer */
status = VIDENC_process(hEncode,inBufDesc,outBufDesc,inArgs,
outArgs);
if (status != VIDENC_EOK)
{
ERR(VIDENC_process() failed with a fatal error (%ld ext:
%#lx)\n,status, outArgs.extendedError);
return FAILURE;
}
*outBufSize = outArgs.bytesGenerated;
EncodedFrameType = outArgs.encodedFrameType;
return SUCCESS;
In the codec i am copying the data in two output buffers.
outBufs-bufs[0] -encoded data
outBufs-bufs[1] -Motion vec data.
When ever i call the encode_process()
I am getting the following error
Memory Allocated for Motion Vector
crop.c.left=0
crop.c.top=0
crop.c.width=640
Capturing 640x480 video (cropped to 640x480)
CMEMK Error: GETPHYS: Failed to convert virtual 0x0 to physical.
CMEMK Error: GETPHYS: Failed to convert virtual 0xa8bff to physical.
Jpeg Encode Error: VIDENC_process() failed with a fatal error (-2 ext: 0
Struck some where.
Suggest me.
___
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 V1 08/11] ASoc: DaVinci: i2s, Improve underrun, support mono
On Sat, 2009-07-04 at 19:29 -0700, Troy Kisky wrote:
This patch will reduce the number of underruns by
shifting out 32 bit values instead of 16 bit. It also
adds mono support.
Doesn't ALSA already automatically handle mono-stero conversions? I
don't think we need to provide the same functionality in the driver.
Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
---
sound/soc/davinci/davinci-i2s.c | 124
+++
sound/soc/davinci/davinci-pcm.c | 31 +++---
sound/soc/davinci/davinci-pcm.h |3 +-
3 files changed, 110 insertions(+), 48 deletions(-)
diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c
index 6fa1b6a..a2ad53e 100644
--- a/sound/soc/davinci/davinci-i2s.c
+++ b/sound/soc/davinci/davinci-i2s.c
@@ -356,26 +356,29 @@ static int davinci_i2s_hw_params(struct
snd_pcm_substream *substream,
struct davinci_mcbsp_dev *dev = rtd-dai-cpu_dai-private_data;
struct snd_interval *i = NULL;
int mcbsp_word_length;
+ int bits_per_sample;
+ int bits_per_frame;
unsigned int rcr, xcr, srgr;
+ int channels;
+ int format;
+ int element_cnt = 1;
u32 spcr;
- /* general line settings */
- spcr = davinci_mcbsp_read_reg(dev, DAVINCI_MCBSP_SPCR_REG);
- if (substream-stream == SNDRV_PCM_STREAM_CAPTURE) {
- spcr |= DAVINCI_MCBSP_SPCR_RINTM(3) | DAVINCI_MCBSP_SPCR_FREE;
- davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_SPCR_REG, spcr);
- } else {
- spcr |= DAVINCI_MCBSP_SPCR_XINTM(3) | DAVINCI_MCBSP_SPCR_FREE;
- davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_SPCR_REG, spcr);
- }
-
i = hw_param_interval(params, SNDRV_PCM_HW_PARAM_SAMPLE_BITS);
- srgr = DAVINCI_MCBSP_SRGR_FSGM;
- srgr |= DAVINCI_MCBSP_SRGR_FWID(snd_interval_value(i) - 1);
+ bits_per_sample = snd_interval_value(i);
+ /* always 2 samples/frame, mono will convert to stereo */
+ bits_per_frame = bits_per_sample 1;
+ srgr = DAVINCI_MCBSP_SRGR_FSGM |
+ DAVINCI_MCBSP_SRGR_FPER(bits_per_frame - 1) |
+ DAVINCI_MCBSP_SRGR_FWID(bits_per_sample - 1);
- i = hw_param_interval(params, SNDRV_PCM_HW_PARAM_FRAME_BITS);
- srgr |= DAVINCI_MCBSP_SRGR_FPER(snd_interval_value(i) - 1);
- davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_SRGR_REG, srgr);
+ /* general line settings */
+ spcr = davinci_mcbsp_read_reg(dev, DAVINCI_MCBSP_SPCR_REG);
+ spcr |= DAVINCI_MCBSP_SPCR_FREE;
+ spcr |= (substream-stream == SNDRV_PCM_STREAM_PLAYBACK) ?
+ DAVINCI_MCBSP_SPCR_XINTM(3) :
+ DAVINCI_MCBSP_SPCR_RINTM(3);
+ davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_SPCR_REG, spcr);
rcr = DAVINCI_MCBSP_RCR_RFIG;
xcr = DAVINCI_MCBSP_XCR_XFIG;
@@ -386,33 +389,80 @@ static int davinci_i2s_hw_params(struct
snd_pcm_substream *substream,
rcr |= DAVINCI_MCBSP_RCR_RDATDLY(1);
xcr |= DAVINCI_MCBSP_XCR_XDATDLY(1);
}
+ channels = params_channels(params);
+ format = params_format(params);
/* Determine xfer data type */
- switch (params_format(params)) {
- case SNDRV_PCM_FORMAT_S8:
- dma_params-data_type = 1;
- mcbsp_word_length = DAVINCI_MCBSP_WORD_8;
- break;
- case SNDRV_PCM_FORMAT_S16_LE:
- dma_params-data_type = 2;
- mcbsp_word_length = DAVINCI_MCBSP_WORD_16;
- break;
- case SNDRV_PCM_FORMAT_S32_LE:
- dma_params-data_type = 4;
- mcbsp_word_length = DAVINCI_MCBSP_WORD_32;
- break;
- default:
- printk(KERN_WARNING davinci-i2s: unsupported PCM format\n);
- return -EINVAL;
+ if (channels == 2) {
+ /* Combining both channels into 1 element can allow x10 the
+ * amount of time between servicing the dma channel, increase
+ * effiency, and reduce the chance of overrun/underrun. But,
+ * it will result in the left right channels being swapped.
+ * So, you may want to let the codec know to swap them back.
+ *
+ * It may be x10 instead of x2 because the clock from the codec
+ * may run at mclk speed (ie. tlvaic23b), independent of the
+ * sample rate. So, having an entire frame at once means it can
+ * be serviced at the sample rate instead of the mclk speed.
+ *
+ * In the now very unlikely case that an underrun still
+ * occurs, both the left and right samples will be repeated
+ * so that no pops are heard, and the left and right channels
+ * won't end up being swapped because of the underrun.
+ */
+ dma_params-convert_mono_stereo = 0;
+ switch (format) {
+
error library:member ' ' has incompatible byte ordering when building servers
hello there,
I am currently working on building my own algorithm by modifying viddec_copy in
your examples.
When building codec engine, I have added below lines in package.bld file.
Pkg.addLibrary(name, target, {
/* any other exeAttrs */
copts: -mem_model:data=far
}
);And able to create library successfully. Without using
-mem_model:data=far, I get relocation error message when building server. So
I have used this option for now,even though it hinders performance.
When I build servers for the same , I get this error message below.
I understand that this might be due to different compiler options, Since I am
not using CCS v3.3 IDE I am not familiar how to do this in dvsdk_1_30_xx on
linux platform.
error: library
'/home/sandeep/work/examples/ti/sdo/ce/examples/codecs/viddec_copy/lib/viddec_copy.a64P',
member 'viddec_copy.o64P' has incompatible byte ordering
error: library
'/home/sandeep/work/examples/ti/sdo/ce/examples/codecs/viddec_copy/lib/viddec_copy.a64P',
member 'ldecod.o64P' has incompatible byte ordering
-
-
-
like this I get many.
--
Please suggest where to set the same compile options
I also found that, if I add -mem_model:data=far in makefile in
servers/viddec_copy/evmDM6446/
# [CE] Augment the standard $(CFLAGS) variable, adding the
# Configuro-generated compiler file.
CFLAGS = -@ $(COMPILER_FILE) -mem_model:data=far //Added by me.
I get different error for libraries which are being shared (not built by me). I
dont get error for libraries built by me.
error: library
'/home/sandeep/dvsdk_1_30_01_41/codec_engine_2_00_01/packages/ti/sdo/ce/lib/ce.a64P',
member 'Engine.o64P' has incompatible byte ordering
error: library
'/home/sandeep/dvsdk_1_30_01_41/codec_engine_2_00_01/packages/ti/sdo/ce/lib/ce.a64P',
member 'visa.o64P' has incompatible byte ordering
-
-
-
Like this many more...
---
Many Thanks,
Sandeep.Yedire
Yahoo! recommends that you upgrade to the new and safer Internet Explorer
8. http://downloads.yahoo.com/in/internetexplorer/___
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 V1 08/11] ASoc: DaVinci: i2s, Improve underrun, support mono
On Mon, 2009-07-06 at 12:54 +0100, Mark Brown wrote: On Mon, Jul 06, 2009 at 06:09:16AM -0500, Steve Chen wrote: On Sat, 2009-07-04 at 19:29 -0700, Troy Kisky wrote: This patch will reduce the number of underruns by shifting out 32 bit values instead of 16 bit. It also adds mono support. Doesn't ALSA already automatically handle mono-stero conversions? I don't think we need to provide the same functionality in the driver. If the hardware can natively play mono then that's less work for the CPU to do which will improve efficiency. I see. In this case, DaVinci hardware does not support mono, but the patch does some DMA index magic to convert between mono and stereo. It works just as well then... ___ 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] davinci: DA850/OMAP-L138: add cpufreq support
add basic cpufreq support for DA850/OMAP-L138
Currently, frequency scaling only on PLL0 is supported. No scaling of PLL1
or voltage levels as yet.
This patch also moves Async3 clock source to PLL1 so that frequency scaling
on PLL0 does not affect those peripherals. Without this the console on UART2
goes for a toss the moment CPUFreq kicks in.
The OPP defintions assume clock input of 24MHz to the SoC. This is inline
with hardcoding of input frequency in the soc.c files. At some point
this will need to move into board dependent code as boards appear with
different input clock.
Tested with ondemand governer and a shell script to vary processor load.
Signed-off-by: Sekhar Nori nsek...@ti.com
---
arch/arm/mach-davinci/da850.c | 152 -
1 files changed, 149 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 274f004..7a3a376 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -15,6 +15,7 @@
#include linux/init.h
#include linux/clk.h
#include linux/platform_device.h
+#include linux/cpufreq.h
#include asm/mach/map.h
@@ -32,14 +33,20 @@
#define DA850_PSC0_BASE0x01c1
#define DA850_PLL0_BASE0x01c11000
-#define DA850_JTAG_ID_REG 0x01c14018
#define DA850_TIMER64P0_BASE 0x01c2
#define DA850_TIMER64P1_BASE 0x01c21000
#define DA850_GPIO_BASE0x01e26000
#define DA850_PSC1_BASE0x01e27000
#define DA850_PLL1_BASE0x01e1a000
+#define DA850_SYSCFG_BASE 0x01c14000
+#define DA850_CFGCHIP0_REG (DA850_SYSCFG_BASE + 0x17c)
+#define DA850_CFGCHIP3_REG (DA850_SYSCFG_BASE + 0x188)
+#define DA850_JTAG_ID_REG (DA850_SYSCFG_BASE + 0x18)
+
#define DA850_REF_FREQ 2400
+static int da850_set_armrate(struct clk *clk, unsigned long rate);
+static int da850_round_armrate(struct clk *clk, unsigned long rate);
static struct pll_data pll0_data = {
.num= 1,
@@ -235,14 +242,14 @@ static struct clk uart0_clk = {
static struct clk uart1_clk = {
.name = uart1,
- .parent = pll0_sysclk2,
+ .parent = pll1_sysclk2,
.lpsc = DA8XX_LPSC1_UART1,
.psc_ctlr = 1,
};
static struct clk uart2_clk = {
.name = uart2,
- .parent = pll0_sysclk2,
+ .parent = pll1_sysclk2,
.lpsc = DA8XX_LPSC1_UART2,
.psc_ctlr = 1,
};
@@ -281,6 +288,8 @@ static struct clk arm_clk = {
.parent = pll0_sysclk6,
.lpsc = DA8XX_LPSC0_ARM,
.flags = ALWAYS_ENABLED,
+ .set_rate = da850_set_armrate,
+ .round_rate = da850_round_armrate,
};
static struct clk rmii_clk = {
@@ -600,6 +609,65 @@ static struct davinci_timer_info da850_timer_info = {
.clocksource_id = T0_TOP,
};
+#define MAX_NUM_OPP3
+
+/*
+ * Notes:
+ * According to the TRM, minimum PLLM results in max power savings.
+ * The OPP definitions below should keep the PLLM as low as possible.
+ *
+ * The output of the PLLM must be between 400 to 600 MHz.
+ * This rules out prediv of anything but divide-by-one for 24Mhz OSC input.
+ */
+struct da850_opp {
+ unsigned intfreq; /* in KHz */
+ unsigned intprediv;
+ unsigned intmult;
+ unsigned intpostdiv;
+};
+
+static const struct da850_opp da850_opp_300 = {
+ .freq = 30,
+ .prediv = 1,
+ .mult = 25,
+ .postdiv= 2,
+};
+
+static const struct da850_opp da850_opp_200 = {
+ .freq = 20,
+ .prediv = 1,
+ .mult = 25,
+ .postdiv= 3,
+};
+
+static const struct da850_opp da850_opp_96 = {
+ .freq = 96000,
+ .prediv = 1,
+ .mult = 20,
+ .postdiv= 5,
+};
+
+#define OPP(freq) \
+ { \
+ .index = (unsigned int) da850_opp_##freq, \
+ .frequency = freq * 1000, \
+ }
+
+static struct cpufreq_frequency_table da850_freq_table[MAX_NUM_OPP+1] = {
+ OPP(300),
+ OPP(200),
+ OPP(96),
+ {
+ .index = 0,
+ .frequency = CPUFREQ_TABLE_END,
+ },
+};
+
+void da850_init_cpufreq_table(struct cpufreq_frequency_table **table)
+{
+ *table = da850_freq_table[0];
+}
+
static struct davinci_soc_info davinci_soc_info_da850 = {
.io_desc= da850_io_desc,
.io_desc_num= ARRAY_SIZE(da850_io_desc),
@@ -622,9 +690,87 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
.gpio_irq = IRQ_DA8XX_GPIO0,
.serial_dev = da8xx_serial_device,
.emac_pdata = da8xx_emac_pdata,
+ .init_cpufreq_table =
LSP 2.10 Previewer hung on preview task
Hi Do someone have tested davinci_previewer from LSP 2.10 on DVEVM DM6446. I have made one test with one frame and all was ok. But when use previewer for stream from MT9P031 board. It hung on IOCTL - PREV_PREVIEW. I have put some printk() in driver. All is ok till: wait_for_completion_interruptible((device-wfc)); It hung. All other threads are runnig, but I am not able to end whole applicatio, because of this one thread. Please suggest what could be problem. Ondrej Pindroch SoftHard Technology ltd. ___ 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 2/2] davinci: DA850/OMAP-L138: add cpufreq support
Hello. Sekhar Nori wrote: add basic cpufreq support for DA850/OMAP-L138 Currently, frequency scaling only on PLL0 is supported. No scaling of PLL1 or voltage levels as yet. This patch also moves Async3 clock source to PLL1 so that frequency scaling on PLL0 does not affect those peripherals. Without this the console on UART2 goes for a toss the moment CPUFreq kicks in. The OPP defintions assume clock input of 24MHz to the SoC. This is inline with hardcoding of input frequency in the soc.c files. At some point this will need to move into board dependent code as boards appear with different input clock. Tested with ondemand governer and a shell script to vary processor load. Signed-off-by: Sekhar Nori nsek...@ti.com diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c index 274f004..7a3a376 100644 --- a/arch/arm/mach-davinci/da850.c +++ b/arch/arm/mach-davinci/da850.c @@ -15,6 +15,7 @@ #include linux/init.h #include linux/clk.h #include linux/platform_device.h +#include linux/cpufreq.h #include asm/mach/map.h @@ -32,14 +33,20 @@ #define DA850_PSC0_BASE 0x01c1 #define DA850_PLL0_BASE0x01c11000 -#define DA850_JTAG_ID_REG 0x01c14018 #define DA850_TIMER64P0_BASE 0x01c2 #define DA850_TIMER64P1_BASE 0x01c21000 #define DA850_GPIO_BASE0x01e26000 #define DA850_PSC1_BASE0x01e27000 #define DA850_PLL1_BASE0x01e1a000 Please don't duplicate these #define's which are not specific to DA850 and are the same for DA830. Could you move them into soime header file instead -- probably mach/hardware.h? +#define DA850_SYSCFG_BASE 0x01c14000 +#define DA850_CFGCHIP0_REG (DA850_SYSCFG_BASE + 0x17c) +#define DA850_CFGCHIP3_REG (DA850_SYSCFG_BASE + 0x188) +#define DA850_JTAG_ID_REG (DA850_SYSCFG_BASE + 0x18) These registers are the same b/w DA830 and DA850. Place them into some header file instead. Note that I'll also need CHIPCFG2 #define for the USB platfrom code. WBR, Sergei ___ 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 2/2] davinci: DA850/OMAP-L138: add cpufreq support
Hello, I wrote: add basic cpufreq support for DA850/OMAP-L138 Currently, frequency scaling only on PLL0 is supported. No scaling of PLL1 or voltage levels as yet. This patch also moves Async3 clock source to PLL1 so that frequency scaling on PLL0 does not affect those peripherals. Without this the console on UART2 goes for a toss the moment CPUFreq kicks in. The OPP defintions assume clock input of 24MHz to the SoC. This is inline with hardcoding of input frequency in the soc.c files. At some point this will need to move into board dependent code as boards appear with different input clock. Tested with ondemand governer and a shell script to vary processor load. Signed-off-by: Sekhar Nori nsek...@ti.com diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c index 274f004..7a3a376 100644 --- a/arch/arm/mach-davinci/da850.c +++ b/arch/arm/mach-davinci/da850.c @@ -15,6 +15,7 @@ #include linux/init.h #include linux/clk.h #include linux/platform_device.h +#include linux/cpufreq.h #include asm/mach/map.h @@ -32,14 +33,20 @@ #define DA850_PSC0_BASE0x01c1 #define DA850_PLL0_BASE0x01c11000 -#define DA850_JTAG_ID_REG0x01c14018 #define DA850_TIMER64P0_BASE0x01c2 #define DA850_TIMER64P1_BASE0x01c21000 #define DA850_GPIO_BASE0x01e26000 #define DA850_PSC1_BASE0x01e27000 #define DA850_PLL1_BASE0x01e1a000 Please don't duplicate these #define's which are not specific to DA850 and are the same for DA830. Could you move them into soime header file instead -- probably mach/hardware.h? No, actually there's mach/da8xx.h for exactly that purpose. +#define DA850_SYSCFG_BASE0x01c14000 +#define DA850_CFGCHIP0_REG(DA850_SYSCFG_BASE + 0x17c) +#define DA850_CFGCHIP3_REG(DA850_SYSCFG_BASE + 0x188) +#define DA850_JTAG_ID_REG(DA850_SYSCFG_BASE + 0x18) These registers are the same b/w DA830 and DA850. Place them into some header file instead. Note that I'll also need CHIPCFG2 #define for the USB platfrom code. WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: trouble in OSD land (DM355, DM365)
Jean-Philippe, Most likely the OSD0 is hiding the video window. Could you issue the following:- fbset -fb /dev/fb/0 -xres 0 This basically disable osd0. I am not sure how you are disabling OSD0. If you are already doing this, ignore this. The v4l2 display works with FBDev driving the OSD layers. We had tested this use case in LSP 2.10 for DM365. Let me know if you need further help on this. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 Phone : 301-515-3736 email: m-kariche...@ti.com -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Jean-Philippe François Sent: Friday, July 03, 2009 3:26 AM To: davinci-linux-open-source Subject: Re: trouble in OSD land (DM355, DM365) Jean-Philippe François a écrit : Hi, When the framebuffer driver is enabled, Video can't be displayed through V4L2. Here is the setup : V4L2 display and framebuffer driver are enabled. Kernel command line contains video=davincifb:vid0=off,vid1=off The V4L2 application runs fine, but nothing on the output, wether OSD window 0 is enabled or not. OSD application works and produce output. What did I miss ? Additional info : V4L2 display alone works fine V4L2 + OSD : OSD works fine, not V4L2. I guess I could use the fb driver to display video, but the V4L2 API is more suited to video display. Anyone did use this succesfully on dm355 ? Jean-Philippe François ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: why the image corruption occured in ipipe?
First for the IPIPE cannot process 2592 pixels per line. I believe it is something like 1360 pixels. I am curious why you can’t do 1280x720? Could you provide more details on what you are doing? LSP release you are using, single shot/continuous, MMAP/Userptr etc will be helpful to narrow down the issue. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Pavel Han Sent: Friday, July 03, 2009 11:34 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: why the image corruption occured in ipipe? hello EveryBody! I use a MT9P031 Sensor to capture 2592x1944 resolution picture on DM355,but now I face a strange image corruption problem in the ipipe,the picture sometimes is corrupted by blocks of image on another position.I find this problem even in the 1280x...@30fpsmailto:1280x...@30fps resolution,so I think this is a very common problem. Is there anybody also face this problem and get it solved. Any help or tips is appreciated! Pavel Han windla...@gmail.com 2009-07-04 ___ 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 2/2] davinci: Add support for DA850/OMAP-L138 EVM board
Rajashekhara, Sudhakar sudhakar@ti.com writes:
On Wed, Jul 01, 2009 at 23:24:21, Kevin Hilman wrote:
Rajashekhara, Sudhakar sudhakar@ti.com writes:
This patch also fixes broken CONFIG_DEBUG_LL support on
DA830/OMAP-L137 EVM caused by my previous patch.
hmm...
diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h
b/arch/arm/mach-davinci/include/mach/uncompress.h
index 0f1f12b..28ea1f5 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h
@@ -21,7 +21,8 @@ static u32 *uart;
static u32 *get_uart_base(void)
{
- if (__machine_arch_type == MACH_TYPE_DAVINCI_DA8XX_EVM)
+ if (__machine_arch_type == MACH_TYPE_DAVINCI_DA8XX_EVM ||
+ __machine_arch_type == MACH_TYPE_DAVINCI_DA850_EVM)
return (u32 *)DA8XX_UART2_BASE;
else
return (u32 *)DAVINCI_UART0_BASE;
this looks still broken for da830 since ..._DA8XX_EVM machine doesn't exist.
No, it's not broken. DA830 EVM has been registered as DAVINCI_DA8XX_EVM.
Please refer to arch/arm/tools/mach-types.
Then the machine type was registered incorrectly as that is clearly a
wrong (and confusing) name for that board.
Please fix the machine-name registration and send a mach-types patch
along with an updated version of this patch.
Kevin
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: spi master and slave device and driver
On Monday 06 July 2009, 邹卫军 wrote: But when I want to register the mcp2510's spi driver, I find that this driver can not find the proper spi device to attach(The spi device registered in spi_bus is attached to the spidev drivers). One device, one driver. *EITHER* use spidev from userspace, or some kernel driver from inside the kernel. ___ 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 1/2] davinci: Add cpufreq support
On Monday 06 July 2009, Sekhar Nori wrote: The patch implements cpufreq driver, support to change PLL output rate and recalculation of the rates of PLL derived clocks It seems to me this is missing some sanity checks. First, that the DRAM isn't being clocked through this PLL... since changing the PLL would imply recalculating all of its timings, and might require running the re-clock from SRAM. Second, similar issues crop up with every clock derived from that same PLL. If you change the clock going into the MMC controller, that can require recalculating the dividers used to clock the MMC/SD card it's talking to. Now, those are issues the clock framework handles poorly. So I don't think there are likely to be easy fixes for those PLL recalc problems ... unless I missed something. It might be simpler to just restrict a first pass of this to changing dividers for the ARM's clock. Also, this patch is doing two separate things. One is adding clk_set_rate() support for PLLs. The other is matching $SUBJECT. Better to split those two. (And notice how your patch [2/2] hit that second issue already, with the UART2 clock getting goofed ...) - Dave ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 03/26] davinci: EDMA: interface changes visible to EDMA clients
From: Sudhakar Rajashekhara sudhakar@ti.com
Introduce macros to build IDs from controller and channel number, and to
extract them. Modify the edma_alloc_slot function to take an extra argument
for the controller.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Reviewed-by: David Brownell dbrown...@users.sourceforge.net
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-davinci/devices.c |8 +-
arch/arm/mach-davinci/dma.c | 530 +++--
arch/arm/mach-davinci/include/mach/edma.h |6 +-
3 files changed, 356 insertions(+), 188 deletions(-)
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index de16f34..7a2f8ae 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -82,10 +82,10 @@ static struct resource mmcsd0_resources[] = {
},
/* DMA channels: RX, then TX */
{
- .start = DAVINCI_DMA_MMCRXEVT,
+ .start = EDMA_CTLR_CHAN(0, DAVINCI_DMA_MMCRXEVT),
.flags = IORESOURCE_DMA,
}, {
- .start = DAVINCI_DMA_MMCTXEVT,
+ .start = EDMA_CTLR_CHAN(0, DAVINCI_DMA_MMCTXEVT),
.flags = IORESOURCE_DMA,
},
};
@@ -119,10 +119,10 @@ static struct resource mmcsd1_resources[] = {
},
/* DMA channels: RX, then TX */
{
- .start = 30,/* rx */
+ .start = EDMA_CTLR_CHAN(0, 30), /* rx */
.flags = IORESOURCE_DMA,
}, {
- .start = 31,/* tx */
+ .start = EDMA_CTLR_CHAN(0, 31), /* tx */
.flags = IORESOURCE_DMA,
},
};
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
index 9afd55f..0a021ff 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/mach-davinci/dma.c
@@ -114,95 +114,105 @@
static void __iomem *edmacc_regs_base[EDMA_MAX_CC];
-static inline unsigned int edma_read(int offset)
+static inline unsigned int edma_read(unsigned ctlr, int offset)
{
- return (unsigned int)__raw_readl(edmacc_regs_base + offset);
+ return (unsigned int)__raw_readl(edmacc_regs_base[ctlr] + offset);
}
-static inline void edma_write(int offset, int val)
+static inline void edma_write(unsigned ctlr, int offset, int val)
{
- __raw_writel(val, edmacc_regs_base + offset);
+ __raw_writel(val, edmacc_regs_base[ctlr] + offset);
}
-static inline void edma_modify(int offset, unsigned and, unsigned or)
+static inline void edma_modify(unsigned ctlr, int offset, unsigned and,
+ unsigned or)
{
- unsigned val = edma_read(offset);
+ unsigned val = edma_read(ctlr, offset);
val = and;
val |= or;
- edma_write(offset, val);
+ edma_write(ctlr, offset, val);
}
-static inline void edma_and(int offset, unsigned and)
+static inline void edma_and(unsigned ctlr, int offset, unsigned and)
{
- unsigned val = edma_read(offset);
+ unsigned val = edma_read(ctlr, offset);
val = and;
- edma_write(offset, val);
+ edma_write(ctlr, offset, val);
}
-static inline void edma_or(int offset, unsigned or)
+static inline void edma_or(unsigned ctlr, int offset, unsigned or)
{
- unsigned val = edma_read(offset);
+ unsigned val = edma_read(ctlr, offset);
val |= or;
- edma_write(offset, val);
+ edma_write(ctlr, offset, val);
}
-static inline unsigned int edma_read_array(int offset, int i)
+static inline unsigned int edma_read_array(unsigned ctlr, int offset, int i)
{
- return edma_read(offset + (i 2));
+ return edma_read(ctlr, offset + (i 2));
}
-static inline void edma_write_array(int offset, int i, unsigned val)
+static inline void edma_write_array(unsigned ctlr, int offset, int i,
+ unsigned val)
{
- edma_write(offset + (i 2), val);
+ edma_write(ctlr, offset + (i 2), val);
}
-static inline void edma_modify_array(int offset, int i,
+static inline void edma_modify_array(unsigned ctlr, int offset, int i,
unsigned and, unsigned or)
{
- edma_modify(offset + (i 2), and, or);
+ edma_modify(ctlr, offset + (i 2), and, or);
}
-static inline void edma_or_array(int offset, int i, unsigned or)
+static inline void edma_or_array(unsigned ctlr, int offset, int i, unsigned or)
{
- edma_or(offset + (i 2), or);
+ edma_or(ctlr, offset + (i 2), or);
}
-static inline void edma_or_array2(int offset, int i, int j, unsigned or)
+static inline void edma_or_array2(unsigned ctlr, int offset, int i, int j,
+ unsigned or)
{
- edma_or(offset + ((i*2 + j) 2), or);
+ edma_or(ctlr, offset + ((i*2 + j) 2), or);
}
-static inline void edma_write_array2(int offset, int i, int j, unsigned val)
+static inline void edma_write_array2(unsigned ctlr, int offset, int i, int j,
+ unsigned val)
{
- edma_write(offset +
[PATCH 00/26] davinci: updates for next merge window
This series is the queue of DaVinci platform changes proposed for the next merge window. This series based at v2.6.31-rc2 and is available as the 'davinci-next' branch of DaVinci git w git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git davinci-next Upon review, I will push these to my 'for-next' branch which is included as part of linux-next. Chaithrika U S (1): davinci: dm646x: Adds McASP clock David Brownell (4): davinci: EDMA minor cleanup davinci: sram warning fix davinci: dm365 evm cpld support: leds, card detect, other setup davinci: dm365 gpio irq support David Griego (1): davinci: Fix watchdog reset code Kevin Hilman (3): MAINTAINERS: add entry for TI DaVinci machine support davinci: Kconfig: enable EVMs by default when SoCs are enabled davinci: remove watchdog from soc_info Mark A. Greer (2): davinci: da8xx: Add base DA830/OMAP-L137 SoC support davinci: da8xx: Add support for DA830/OMAP-L137 EVM board Rajashekhara, Sudhakar (1): davinci: dm644x: Support for dm644x silicon revision 2.1 Sandeep Paulraj (10): davinci: Adding DM365 SOC Support davinci: Adding DM365 EVM board support davinci: Adding DM365 entries to Makefile/Kconfig/defconfig davinci: dm365: add mux entries for EDMA, RTC, EMAC, keypad. davinci: dm365: EMAC support for SoC and dm365 EVM davinci: dm365: add EDMA support davinci: dm365: add MMC/SD support davinci: MMC/SD Support for dm365 EVM davinci: dm365: add NAND support to EVM board davinci: DM365 Updating PINMUX Entries Sudhakar Rajashekhara (4): davinci: EDMA: restructure to support multiple channel controllers davinci: EDMA: interface changes visible to EDMA clients davinci: EDMA: Move queue related mappings to dmsoc.c davinci: EDMA: add support for dm646x MAINTAINERS |6 + arch/arm/configs/da830_omapl137_defconfig| 1254 ++ arch/arm/configs/davinci_all_defconfig |2 + arch/arm/mach-davinci/Kconfig| 39 +- arch/arm/mach-davinci/Makefile | 12 +- arch/arm/mach-davinci/Makefile.boot | 10 + arch/arm/mach-davinci/board-da830-evm.c | 127 +++ arch/arm/mach-davinci/board-dm365-evm.c | 492 + arch/arm/mach-davinci/clock.c|5 +- arch/arm/mach-davinci/da830.c| 1247 + arch/arm/mach-davinci/devices-da8xx.c| 283 + arch/arm/mach-davinci/devices.c | 60 +- arch/arm/mach-davinci/dm355.c| 34 +- arch/arm/mach-davinci/dm365.c| 905 arch/arm/mach-davinci/dm644x.c | 41 +- arch/arm/mach-davinci/dm646x.c | 93 ++- arch/arm/mach-davinci/dma.c | 681 arch/arm/mach-davinci/gpio.c | 105 ++- arch/arm/mach-davinci/include/mach/common.h |2 +- arch/arm/mach-davinci/include/mach/cputype.h | 16 + arch/arm/mach-davinci/include/mach/da8xx.h | 69 ++ arch/arm/mach-davinci/include/mach/debug-macro.S |7 + arch/arm/mach-davinci/include/mach/dm365.h | 29 + arch/arm/mach-davinci/include/mach/edma.h| 57 +- arch/arm/mach-davinci/include/mach/gpio.h|8 +- arch/arm/mach-davinci/include/mach/irqs.h| 145 +++- arch/arm/mach-davinci/include/mach/memory.h |9 +- arch/arm/mach-davinci/include/mach/mux.h | 548 ++ arch/arm/mach-davinci/include/mach/psc.h | 59 + arch/arm/mach-davinci/include/mach/serial.h |4 + arch/arm/mach-davinci/include/mach/uncompress.h |6 +- arch/arm/mach-davinci/sram.c |2 +- arch/arm/mach-davinci/time.c | 16 +- 33 files changed, 6053 insertions(+), 320 deletions(-) create mode 100644 arch/arm/configs/da830_omapl137_defconfig create mode 100644 arch/arm/mach-davinci/board-da830-evm.c create mode 100644 arch/arm/mach-davinci/board-dm365-evm.c create mode 100644 arch/arm/mach-davinci/da830.c create mode 100644 arch/arm/mach-davinci/devices-da8xx.c create mode 100644 arch/arm/mach-davinci/dm365.c create mode 100644 arch/arm/mach-davinci/include/mach/da8xx.h create mode 100644 arch/arm/mach-davinci/include/mach/dm365.h ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 06/26] davinci: EDMA minor cleanup
From: David Brownell dbrown...@users.sourceforge.net Minor EDMA cleanup: remove unused SoC-specific #define; and when requesting the channel controller region, use the device's name (to be more useful on chips with multiple such controllers). Signed-off-by: David Brownell dbrown...@users.sourceforge.net Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-davinci/dma.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c index 1c60de6..c9c1a93 100644 --- a/arch/arm/mach-davinci/dma.c +++ b/arch/arm/mach-davinci/dma.c @@ -100,8 +100,6 @@ #define EDMA_SHADOW0 0x2000 /* 4 regions shadowing global channels */ #define EDMA_PARM 0x4000 /* 128 param entries */ -#define DAVINCI_DMA_3PCC_BASE 0x01C0 - #define PARM_OFFSET(param_no) (EDMA_PARM + ((param_no) 5)) #define EDMA_DCHMAP0x0100 /* 64 registers */ @@ -1215,7 +1213,7 @@ static int __init edma_probe(struct platform_device *pdev) len = r-end - r-start + 1; - r = request_mem_region(r-start, len, r-name); + r = request_mem_region(r-start, len, dev_name(pdev-dev)); if (!r) return -EBUSY; -- 1.6.3.3 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 04/26] davinci: EDMA: Move queue related mappings to dmsoc.c
From: Sudhakar Rajashekhara sudhakar@ti.com
EDMA in DM355 and DM644x has two transfer controllers while DM646x has four
transfer controllers. Moving the queue to tc mapping and queue priority
mapping to dmsoc.c will be helpful to probe these mappings from platform
device so that the machine_is_* testing will be avoided.
Signed-off-by: Naresh Medisetty nar...@ti.com
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-davinci/dm355.c | 30 ++
arch/arm/mach-davinci/dm644x.c| 30 ++
arch/arm/mach-davinci/dm646x.c| 38 +++-
arch/arm/mach-davinci/dma.c | 22 -
arch/arm/mach-davinci/include/mach/edma.h |2 +
5 files changed, 86 insertions(+), 36 deletions(-)
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index beda643..9baeed3 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -558,13 +558,31 @@ static const s8 dma_chan_dm355_no_event[] = {
-1
};
+static const s8
+queue_tc_mapping[][2] = {
+ /* {event queue no, TC no} */
+ {0, 0},
+ {1, 1},
+ {-1, -1},
+};
+
+static const s8
+queue_priority_mapping[][2] = {
+ /* {event queue no, Priority} */
+ {0, 3},
+ {1, 7},
+ {-1, -1},
+};
+
static struct edma_soc_info dm355_edma_info = {
- .n_channel = 64,
- .n_region = 4,
- .n_slot = 128,
- .n_tc = 2,
- .n_cc = 1,
- .noevent= dma_chan_dm355_no_event,
+ .n_channel = 64,
+ .n_region = 4,
+ .n_slot = 128,
+ .n_tc = 2,
+ .n_cc = 1,
+ .noevent= dma_chan_dm355_no_event,
+ .queue_tc_mapping = queue_tc_mapping,
+ .queue_priority_mapping = queue_priority_mapping,
};
static struct resource edma_resources[] = {
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index ddc1d4f..a2f83af 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -484,13 +484,31 @@ static const s8 dma_chan_dm644x_no_event[] = {
-1
};
+static const s8
+queue_tc_mapping[][2] = {
+ /* {event queue no, TC no} */
+ {0, 0},
+ {1, 1},
+ {-1, -1},
+};
+
+static const s8
+queue_priority_mapping[][2] = {
+ /* {event queue no, Priority} */
+ {0, 3},
+ {1, 7},
+ {-1, -1},
+};
+
static struct edma_soc_info dm644x_edma_info = {
- .n_channel = 64,
- .n_region = 4,
- .n_slot = 128,
- .n_tc = 2,
- .n_cc = 1,
- .noevent= dma_chan_dm644x_no_event,
+ .n_channel = 64,
+ .n_region = 4,
+ .n_slot = 128,
+ .n_tc = 2,
+ .n_cc = 1,
+ .noevent= dma_chan_dm644x_no_event,
+ .queue_tc_mapping = queue_tc_mapping,
+ .queue_priority_mapping = queue_priority_mapping,
};
static struct resource edma_resources[] = {
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 334f071..d32d2b8 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -451,17 +451,41 @@ static const s8 dma_chan_dm646x_no_event[] = {
-1
};
+/* Four Transfer Controllers on DM646x */
+static const s8
+dm646x_queue_tc_mapping[][2] = {
+ /* {event queue no, TC no} */
+ {0, 0},
+ {1, 1},
+ {2, 2},
+ {3, 3},
+ {-1, -1},
+};
+
+static const s8
+dm646x_queue_priority_mapping[][2] = {
+ /* {event queue no, Priority} */
+ {0, 4},
+ {1, 0},
+ {2, 5},
+ {3, 1},
+ {-1, -1},
+};
+
static struct edma_soc_info dm646x_edma_info = {
- .n_channel = 64,
- .n_region = 6,/* 0-1, 4-7 */
- .n_slot = 512,
- .n_tc = 4,
- .noevent= dma_chan_dm646x_no_event,
+ .n_channel = 64,
+ .n_region = 6,/* 0-1, 4-7 */
+ .n_slot = 512,
+ .n_tc = 4,
+ .n_cc = 1,
+ .noevent= dma_chan_dm646x_no_event,
+ .queue_tc_mapping = dm646x_queue_tc_mapping,
+ .queue_priority_mapping = dm646x_queue_priority_mapping,
};
static struct resource edma_resources[] = {
{
- .name = edma_cc,
+ .name = edma_cc0,
.start = 0x01c0,
.end= 0x01c0 + SZ_64K - 1,
.flags = IORESOURCE_MEM,
@@ -503,7 +527,7 @@ static struct resource edma_resources[] = {
static struct platform_device dm646x_edma_device = {
[PATCH 05/26] davinci: EDMA: add support for dm646x
From: Sudhakar Rajashekhara sudhakar@ti.com
Enables module clock for DM646x EDMA channel controller and transfer controller.
Channel mapping logic is introduced in dm646x EDMA. This implies that there is
no fixed association for a channel number to a parameter entry number. In other
words, using the DMA channel mapping registers (DCHMAPn), a PaRAM entry can be
mapped to any channel. While in the case of dm644x and dm355 there is a fixed
mapping between the EDMA channel and Param entry number.
Signed-off-by: Naresh Medisetty nar...@ti.com
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-davinci/dm646x.c | 40
arch/arm/mach-davinci/dma.c| 25 +
2 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index d32d2b8..5326edf 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -162,6 +162,41 @@ static struct clk arm_clk = {
.flags = ALWAYS_ENABLED,
};
+static struct clk edma_cc_clk = {
+ .name = edma_cc,
+ .parent = pll1_sysclk2,
+ .lpsc = DM646X_LPSC_TPCC,
+ .flags = ALWAYS_ENABLED,
+};
+
+static struct clk edma_tc0_clk = {
+ .name = edma_tc0,
+ .parent = pll1_sysclk2,
+ .lpsc = DM646X_LPSC_TPTC0,
+ .flags = ALWAYS_ENABLED,
+};
+
+static struct clk edma_tc1_clk = {
+ .name = edma_tc1,
+ .parent = pll1_sysclk2,
+ .lpsc = DM646X_LPSC_TPTC1,
+ .flags = ALWAYS_ENABLED,
+};
+
+static struct clk edma_tc2_clk = {
+ .name = edma_tc2,
+ .parent = pll1_sysclk2,
+ .lpsc = DM646X_LPSC_TPTC2,
+ .flags = ALWAYS_ENABLED,
+};
+
+static struct clk edma_tc3_clk = {
+ .name = edma_tc3,
+ .parent = pll1_sysclk2,
+ .lpsc = DM646X_LPSC_TPTC3,
+ .flags = ALWAYS_ENABLED,
+};
+
static struct clk uart0_clk = {
.name = uart0,
.parent = aux_clkin,
@@ -269,6 +304,11 @@ struct davinci_clk dm646x_clks[] = {
CLK(NULL, pll2_sysclk1, pll2_sysclk1),
CLK(NULL, dsp, dsp_clk),
CLK(NULL, arm, arm_clk),
+ CLK(NULL, edma_cc, edma_cc_clk),
+ CLK(NULL, edma_tc0, edma_tc0_clk),
+ CLK(NULL, edma_tc1, edma_tc1_clk),
+ CLK(NULL, edma_tc2, edma_tc2_clk),
+ CLK(NULL, edma_tc3, edma_tc3_clk),
CLK(NULL, uart0, uart0_clk),
CLK(NULL, uart1, uart1_clk),
CLK(NULL, uart2, uart2_clk),
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
index 50ac74f..1c60de6 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/mach-davinci/dma.c
@@ -104,6 +104,9 @@
#define PARM_OFFSET(param_no) (EDMA_PARM + ((param_no) 5))
+#define EDMA_DCHMAP0x0100 /* 64 registers */
+#define CHMAP_EXISTBIT(24)
+
#define EDMA_MAX_DMACH 64
#define EDMA_MAX_PARAMENTRY 512
#define EDMA_MAX_CC 2
@@ -287,6 +290,24 @@ static void __init assign_priority_to_queue(unsigned ctlr,
int queue_no,
((priority 0x7) bit));
}
+/**
+ * map_dmach_param - Maps channel number to param entry number
+ *
+ * This maps the dma channel number to param entry numberter. In
+ * other words using the DMA channel mapping registers a param entry
+ * can be mapped to any channel
+ *
+ * Callers are responsible for ensuring the channel mapping logic is
+ * included in that particular EDMA variant (Eg : dm646x)
+ *
+ */
+static void __init map_dmach_param(unsigned ctlr)
+{
+ int i;
+ for (i = 0; i EDMA_MAX_DMACH; i++)
+ edma_write_array(ctlr, EDMA_DCHMAP , i , (i 5));
+}
+
static inline void
setup_dma_interrupt(unsigned lch,
void (*callback)(unsigned channel, u16 ch_status, void *data),
@@ -1287,6 +1308,10 @@ static int __init edma_probe(struct platform_device
*pdev)
assign_priority_to_queue(pdev-id, queue_priority_mapping[i][0],
queue_priority_mapping[i][1]);
+ /* Map the channel to param entry if channel mapping logic exist */
+ if (edma_read(pdev-id, EDMA_CCCFG) CHMAP_EXIST)
+ map_dmach_param(pdev-id);
+
for (i = 0; i info-n_region; i++) {
edma_write_array2(pdev-id, EDMA_DRAE, i, 0, 0x0);
edma_write_array2(pdev-id, EDMA_DRAE, i, 1, 0x0);
--
1.6.3.3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 11/26] davinci: sram warning fix
From: David Brownell davi...@pacbell.net
CC arch/arm/mach-davinci/sram.o
arch/arm/mach-davinci/sram.c: In function 'sram_init':
arch/arm/mach-davinci/sram.c:63: warning: comparison of distinct pointer types
lacks a cast
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-davinci/sram.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
index db54b2a..4f1fc9b 100644
--- a/arch/arm/mach-davinci/sram.c
+++ b/arch/arm/mach-davinci/sram.c
@@ -60,7 +60,7 @@ static int __init sram_init(void)
int status = 0;
if (len) {
- len = min(len, SRAM_SIZE);
+ len = min_t(unsigned, len, SRAM_SIZE);
sram_pool = gen_pool_create(ilog2(SRAM_GRANULARITY), -1);
if (!sram_pool)
status = -ENOMEM;
--
1.6.3.3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 07/26] davinci: dm646x: Adds McASP clock
From: Chaithrika U S chaithr...@ti.com
Adds McASP clock support for the two instances of mcasp (mcasp0,mcasp1). This
patch is part of the audio support for dm646x series.
Signed-off-by: Naresh Medisetty nar...@ti.com
Signed-off-by: Chaithrika U S chaithr...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-davinci/dm646x.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 5326edf..e4d7d0f 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -227,6 +227,18 @@ static struct clk gpio_clk = {
.lpsc = DM646X_LPSC_GPIO,
};
+static struct clk mcasp0_clk = {
+ .name = mcasp0,
+ .parent = pll1_sysclk3,
+ .lpsc = DM646X_LPSC_McASP0,
+};
+
+static struct clk mcasp1_clk = {
+ .name = mcasp1,
+ .parent = pll1_sysclk3,
+ .lpsc = DM646X_LPSC_McASP1,
+};
+
static struct clk aemif_clk = {
.name = aemif,
.parent = pll1_sysclk3,
@@ -314,6 +326,8 @@ struct davinci_clk dm646x_clks[] = {
CLK(NULL, uart2, uart2_clk),
CLK(i2c_davinci.1, NULL, i2c_clk),
CLK(NULL, gpio, gpio_clk),
+ CLK(NULL, mcasp0, mcasp0_clk),
+ CLK(NULL, mcasp1, mcasp1_clk),
CLK(NULL, aemif, aemif_clk),
CLK(davinci_emac.1, NULL, emac_clk),
CLK(NULL, pwm0, pwm0_clk),
--
1.6.3.3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 08/26] davinci: Fix watchdog reset code
From: David Griego dgri...@mvista.com The davinci reset routine, davinci_watchdog_reset(), sets the TCR register instead of the TGCR register as it should to put the WDT into its Initial State. It also writes the WDTCR register without the proper WDKEY which is pointless since the register will be write-protected. Signed-off-by: David Griego dgri...@mvista.com Signed-off-by: Mark A. Greer mgr...@mvista.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-davinci/time.c | 10 +++--- 1 files changed, 3 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c index 0884ca5..ca85d18 100644 --- a/arch/arm/mach-davinci/time.c +++ b/arch/arm/mach-davinci/time.c @@ -420,11 +420,11 @@ void davinci_watchdog_reset(void) /* reset timer, set mode to 64-bit watchdog, and unreset */ tgcr = 0; - __raw_writel(tgcr, base + TCR); + __raw_writel(tgcr, base + TGCR); tgcr = TGCR_TIMMODE_64BIT_WDOG TGCR_TIMMODE_SHIFT; tgcr |= (TGCR_UNRESET TGCR_TIM12RS_SHIFT) | (TGCR_UNRESET TGCR_TIM34RS_SHIFT); - __raw_writel(tgcr, base + TCR); + __raw_writel(tgcr, base + TGCR); /* clear counter and period regs */ __raw_writel(0, base + TIM12); @@ -432,12 +432,8 @@ void davinci_watchdog_reset(void) __raw_writel(0, base + PRD12); __raw_writel(0, base + PRD34); - /* enable */ - wdtcr = __raw_readl(base + WDTCR); - wdtcr |= WDTCR_WDEN_ENABLE WDTCR_WDEN_SHIFT; - __raw_writel(wdtcr, base + WDTCR); - /* put watchdog in pre-active state */ + wdtcr = __raw_readl(base + WDTCR); wdtcr = (WDTCR_WDKEY_SEQ0 WDTCR_WDKEY_SHIFT) | (WDTCR_WDEN_ENABLE WDTCR_WDEN_SHIFT); __raw_writel(wdtcr, base + WDTCR); -- 1.6.3.3 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 09/26] davinci: dm644x: Support for dm644x silicon revision 2.1
From: Rajashekhara, Sudhakar sudhakar@ti.com
JTAG ID for DM644x silicon revision 2.1 has changed. An entry for the new
silicon revision needs to be added to the davinci_id structure. Without
this addition, EVMs with new silicon revision fail to boot the kernel.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-davinci/dm644x.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index a2f83af..1b3aec8 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -576,6 +576,13 @@ static struct davinci_id dm644x_ids[] = {
.cpu_id = DAVINCI_CPU_ID_DM6446,
.name = dm6446,
},
+ {
+ .variant= 0x1,
+ .part_no= 0xb700,
+ .manufacturer = 0x017,
+ .cpu_id = DAVINCI_CPU_ID_DM6446,
+ .name = dm6446a,
+ },
};
static void __iomem *dm644x_psc_bases[] = {
--
1.6.3.3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 15/26] davinci: Adding DM365 entries to Makefile/Kconfig/defconfig
From: Sandeep Paulraj s-paul...@ti.com This patch does the following 1) Adds entries to davinci_all_defconfig for DM365 2) Adds entries to the Makefile for DM365 3) Adds entries for DM365 in the Kconfig Signed-off-by: Sandeep Paulraj s-paul...@ti.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/configs/davinci_all_defconfig |2 ++ arch/arm/mach-davinci/Kconfig | 13 + arch/arm/mach-davinci/Makefile |2 ++ 3 files changed, 17 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig index ac18662..6eb6d9d 100644 --- a/arch/arm/configs/davinci_all_defconfig +++ b/arch/arm/configs/davinci_all_defconfig @@ -191,6 +191,7 @@ CONFIG_AINTC=y CONFIG_ARCH_DAVINCI_DM644x=y CONFIG_ARCH_DAVINCI_DM355=y CONFIG_ARCH_DAVINCI_DM646x=y +CONFIG_ARCH_DAVINCI_DM365=y # # DaVinci Board Type @@ -200,6 +201,7 @@ CONFIG_MACH_SFFSDR=y CONFIG_MACH_DAVINCI_DM355_EVM=y CONFIG_MACH_DM355_LEOPARD=y CONFIG_MACH_DAVINCI_DM6467_EVM=y +CONFIG_MACH_DAVINCI_DM365_EVM=y CONFIG_DAVINCI_MUX=y CONFIG_DAVINCI_MUX_DEBUG=y CONFIG_DAVINCI_MUX_WARNINGS=y diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig index c330a5a..5ead4ae 100644 --- a/arch/arm/mach-davinci/Kconfig +++ b/arch/arm/mach-davinci/Kconfig @@ -22,6 +22,11 @@ config ARCH_DAVINCI_DM646x bool DaVinci 646x based system select AINTC +config ARCH_DAVINCI_DM365 + bool DaVinci 365 based system + select AINTC + select ARCH_DAVINCI_DMx + comment DaVinci Board Type config MACH_DAVINCI_EVM @@ -64,6 +69,14 @@ config MACH_DAVINCI_DM6467_EVM Configure this option to specify the whether the board used for development is a DM6467 EVM +config MACH_DAVINCI_DM365_EVM + bool TI DM365 EVM + default ARCH_DAVINCI_DM365 + depends on ARCH_DAVINCI_DM365 + help + Configure this option to specify whether the board used + for development is a DM365 EVM + config DAVINCI_MUX bool DAVINCI multiplexing support diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile index 059ab78..bea7ba6 100644 --- a/arch/arm/mach-davinci/Makefile +++ b/arch/arm/mach-davinci/Makefile @@ -13,6 +13,7 @@ obj-$(CONFIG_DAVINCI_MUX) += mux.o obj-$(CONFIG_ARCH_DAVINCI_DM644x) += dm644x.o obj-$(CONFIG_ARCH_DAVINCI_DM355)+= dm355.o obj-$(CONFIG_ARCH_DAVINCI_DM646x) += dm646x.o +obj-$(CONFIG_ARCH_DAVINCI_DM365) += dm365.o obj-$(CONFIG_AINTC)+= irq.o obj-$(CONFIG_CP_INTC) += cp_intc.o @@ -23,3 +24,4 @@ obj-$(CONFIG_MACH_SFFSDR) += board-sffsdr.o obj-$(CONFIG_MACH_DAVINCI_DM355_EVM) += board-dm355-evm.o obj-$(CONFIG_MACH_DM355_LEOPARD) += board-dm355-leopard.o obj-$(CONFIG_MACH_DAVINCI_DM6467_EVM) += board-dm646x-evm.o +obj-$(CONFIG_MACH_DAVINCI_DM365_EVM) += board-dm365-evm.o -- 1.6.3.3 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 12/26] davinci: remove watchdog from soc_info
watchdog info is not needed in soc_info, platform_device can
be used directly in core code.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-davinci/devices.c |7 ++-
arch/arm/mach-davinci/dm355.c |1 -
arch/arm/mach-davinci/dm644x.c |1 -
arch/arm/mach-davinci/dm646x.c |1 -
arch/arm/mach-davinci/include/mach/common.h |1 -
arch/arm/mach-davinci/time.c|6 +++---
6 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index 7a2f8ae..385e833 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -216,6 +216,8 @@ void __init davinci_setup_mmc(int module, struct
davinci_mmc_config *config)
static struct resource wdt_resources[] = {
{
+ .start = DAVINCI_WDOG_BASE,
+ .end= DAVINCI_WDOG_BASE + SZ_1K - 1,
.flags = IORESOURCE_MEM,
},
};
@@ -229,11 +231,6 @@ struct platform_device davinci_wdt_device = {
static void davinci_init_wdt(void)
{
- struct davinci_soc_info *soc_info = davinci_soc_info;
-
- wdt_resources[0].start = (resource_size_t)soc_info-wdt_base;
- wdt_resources[0].end = (resource_size_t)soc_info-wdt_base + SZ_1K - 1;
-
platform_device_register(davinci_wdt_device);
}
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 9baeed3..f0b10b4 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -723,7 +723,6 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
.intc_irq_prios = dm355_default_priorities,
.intc_irq_num = DAVINCI_N_AINTC_IRQ,
.timer_info = dm355_timer_info,
- .wdt_base = IO_ADDRESS(DAVINCI_WDOG_BASE),
.gpio_base = IO_ADDRESS(DAVINCI_GPIO_BASE),
.gpio_num = 104,
.gpio_irq = IRQ_DM355_GPIOBNK0,
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 1b3aec8..dd58f08 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -656,7 +656,6 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
.intc_irq_prios = dm644x_default_priorities,
.intc_irq_num = DAVINCI_N_AINTC_IRQ,
.timer_info = dm644x_timer_info,
- .wdt_base = IO_ADDRESS(DAVINCI_WDOG_BASE),
.gpio_base = IO_ADDRESS(DAVINCI_GPIO_BASE),
.gpio_num = 71,
.gpio_irq = IRQ_GPIOBNK0,
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index e4d7d0f..64a291f 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -687,7 +687,6 @@ static struct davinci_soc_info davinci_soc_info_dm646x = {
.intc_irq_prios = dm646x_default_priorities,
.intc_irq_num = DAVINCI_N_AINTC_IRQ,
.timer_info = dm646x_timer_info,
- .wdt_base = IO_ADDRESS(DAVINCI_WDOG_BASE),
.gpio_base = IO_ADDRESS(DAVINCI_GPIO_BASE),
.gpio_num = 43, /* Only 33 usable */
.gpio_irq = IRQ_DM646X_GPIOBNK0,
diff --git a/arch/arm/mach-davinci/include/mach/common.h
b/arch/arm/mach-davinci/include/mach/common.h
index a1f03b6..b21393b 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -60,7 +60,6 @@ struct davinci_soc_info {
u8 *intc_irq_prios;
unsigned long intc_irq_num;
struct davinci_timer_info *timer_info;
- void __iomem*wdt_base;
void __iomem*gpio_base;
unsignedgpio_num;
unsignedgpio_irq;
diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c
index ca85d18..0d1b6d4 100644
--- a/arch/arm/mach-davinci/time.c
+++ b/arch/arm/mach-davinci/time.c
@@ -406,11 +406,11 @@ struct sys_timer davinci_timer = {
void davinci_watchdog_reset(void)
{
u32 tgcr, wdtcr;
- struct davinci_soc_info *soc_info = davinci_soc_info;
- void __iomem *base = soc_info-wdt_base;
+ struct platform_device *pdev = davinci_wdt_device;
+ void __iomem *base = IO_ADDRESS(pdev-resource[0].start);
struct clk *wd_clk;
- wd_clk = clk_get(davinci_wdt_device.dev, NULL);
+ wd_clk = clk_get(pdev-dev, NULL);
if (WARN_ON(IS_ERR(wd_clk)))
return;
clk_enable(wd_clk);
--
1.6.3.3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 21/26] davinci: dm365: add NAND support to EVM board
From: Sandeep Paulraj s-paul...@ti.com
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-davinci/board-dm365-evm.c | 84 +++
1 files changed, 84 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index e62d1ab..3675e84 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -20,6 +20,9 @@
#include linux/io.h
#include linux/clk.h
#include linux/i2c/at24.h
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
#include asm/setup.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -34,10 +37,84 @@
#include mach/serial.h
#include mach/common.h
#include mach/mmc.h
+#include mach/nand.h
+
+#define DM365_ASYNC_EMIF_CONTROL_BASE 0x01d1
+#define DM365_ASYNC_EMIF_DATA_CE0_BASE 0x0200
#define DM365_EVM_PHY_MASK (0x2)
#define DM365_EVM_MDIO_FREQUENCY (220) /* PHY bus frequency */
+/* NOTE: this is geared for the standard config, with a socketed
+ * 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors. If you
+ * swap chips with a different block size, partitioning will
+ * need to be changed. This NAND chip MT29F16G08FAA is the default
+ * NAND shipped with the Spectrum Digital DM365 EVM
+ */
+#define NAND_BLOCK_SIZESZ_128K
+
+static struct mtd_partition davinci_nand_partitions[] = {
+ {
+ /* UBL (a few copies) plus U-Boot */
+ .name = bootloader,
+ .offset = 0,
+ .size = 28 * NAND_BLOCK_SIZE,
+ .mask_flags = MTD_WRITEABLE, /* force read-only */
+ }, {
+ /* U-Boot environment */
+ .name = params,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 2 * NAND_BLOCK_SIZE,
+ .mask_flags = 0,
+ }, {
+ .name = kernel,
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_4M,
+ .mask_flags = 0,
+ }, {
+ .name = filesystem1,
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_512M,
+ .mask_flags = 0,
+ }, {
+ .name = filesystem2,
+ .offset = MTDPART_OFS_APPEND,
+ .size = MTDPART_SIZ_FULL,
+ .mask_flags = 0,
+ }
+ /* two blocks with bad block table (and mirror) at the end */
+};
+
+static struct davinci_nand_pdata davinci_nand_data = {
+ .mask_chipsel = BIT(14),
+ .parts = davinci_nand_partitions,
+ .nr_parts = ARRAY_SIZE(davinci_nand_partitions),
+ .ecc_mode = NAND_ECC_HW,
+ .options= NAND_USE_FLASH_BBT,
+};
+
+static struct resource davinci_nand_resources[] = {
+ {
+ .start = DM365_ASYNC_EMIF_DATA_CE0_BASE,
+ .end= DM365_ASYNC_EMIF_DATA_CE0_BASE + SZ_32M - 1,
+ .flags = IORESOURCE_MEM,
+ }, {
+ .start = DM365_ASYNC_EMIF_CONTROL_BASE,
+ .end= DM365_ASYNC_EMIF_CONTROL_BASE + SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device davinci_nand_device = {
+ .name = davinci_nand,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(davinci_nand_resources),
+ .resource = davinci_nand_resources,
+ .dev= {
+ .platform_data = davinci_nand_data,
+ },
+};
+
static struct at24_platform_data eeprom_info = {
.byte_len = (256*1024) / 8,
.page_size = 64,
@@ -122,6 +199,10 @@ static void __init evm_init_i2c(void)
i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));
}
+static struct platform_device *dm365_evm_devices[] __initdata = {
+ davinci_nand_device,
+};
+
static struct davinci_uart_config uart_config __initdata = {
.enabled_uarts = (1 0),
};
@@ -135,6 +216,9 @@ static __init void dm365_evm_init(void)
{
struct davinci_soc_info *soc_info = davinci_soc_info;
+ platform_add_devices(dm365_evm_devices,
+ ARRAY_SIZE(dm365_evm_devices));
+
evm_init_i2c();
davinci_serial_init(uart_config);
--
1.6.3.3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 17/26] davinci: dm365: EMAC support for SoC and dm365 EVM
From: Sandeep Paulraj s-paul...@ti.com
The patch adds Support for EMAC in the DM365 SOC and
the DM365 EVM board.
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-davinci/board-dm365-evm.c | 66 ++-
arch/arm/mach-davinci/dm365.c | 58 +++
2 files changed, 122 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index 08c2f12..9dda399 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -19,12 +19,12 @@
#include linux/i2c.h
#include linux/io.h
#include linux/clk.h
-
+#include linux/i2c/at24.h
#include asm/setup.h
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
-
+#include mach/mux.h
#include mach/hardware.h
#include mach/dm365.h
#include mach/psc.h
@@ -34,14 +34,69 @@
#include mach/serial.h
#include mach/common.h
+#define DM365_EVM_PHY_MASK (0x2)
+#define DM365_EVM_MDIO_FREQUENCY (220) /* PHY bus frequency */
+
+static struct at24_platform_data eeprom_info = {
+ .byte_len = (256*1024) / 8,
+ .page_size = 64,
+ .flags = AT24_FLAG_ADDR16,
+ .setup = davinci_get_mac_addr,
+ .context= (void *)0x7f00,
+};
+
+static struct i2c_board_info i2c_info[] = {
+ {
+ I2C_BOARD_INFO(24c256, 0x50),
+ .platform_data = eeprom_info,
+ },
+};
+
static struct davinci_i2c_platform_data i2c_pdata = {
.bus_freq = 400 /* kHz */,
.bus_delay = 0 /* usec */,
};
+static void dm365evm_emac_configure(void)
+{
+ /*
+* EMAC pins are multiplexed with GPIO and UART
+* Further details are available at the DM365 ARM
+* Subsystem Users Guide(sprufg5.pdf) pages 125 - 127
+*/
+ davinci_cfg_reg(DM365_EMAC_TX_EN);
+ davinci_cfg_reg(DM365_EMAC_TX_CLK);
+ davinci_cfg_reg(DM365_EMAC_COL);
+ davinci_cfg_reg(DM365_EMAC_TXD3);
+ davinci_cfg_reg(DM365_EMAC_TXD2);
+ davinci_cfg_reg(DM365_EMAC_TXD1);
+ davinci_cfg_reg(DM365_EMAC_TXD0);
+ davinci_cfg_reg(DM365_EMAC_RXD3);
+ davinci_cfg_reg(DM365_EMAC_RXD2);
+ davinci_cfg_reg(DM365_EMAC_RXD1);
+ davinci_cfg_reg(DM365_EMAC_RXD0);
+ davinci_cfg_reg(DM365_EMAC_RX_CLK);
+ davinci_cfg_reg(DM365_EMAC_RX_DV);
+ davinci_cfg_reg(DM365_EMAC_RX_ER);
+ davinci_cfg_reg(DM365_EMAC_CRS);
+ davinci_cfg_reg(DM365_EMAC_MDIO);
+ davinci_cfg_reg(DM365_EMAC_MDCLK);
+
+ /*
+* EMAC interrupts are multiplexed with GPIO interrupts
+* Details are available at the DM365 ARM
+* Subsystem Users Guide(sprufg5.pdf) pages 133 - 134
+*/
+ davinci_cfg_reg(DM365_INT_EMAC_RXTHRESH);
+ davinci_cfg_reg(DM365_INT_EMAC_RXPULSE);
+ davinci_cfg_reg(DM365_INT_EMAC_TXPULSE);
+ davinci_cfg_reg(DM365_INT_EMAC_MISCPULSE);
+}
+
static void __init evm_init_i2c(void)
{
davinci_init_i2c(i2c_pdata);
+ i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));
}
static struct davinci_uart_config uart_config __initdata = {
@@ -55,8 +110,15 @@ static void __init dm365_evm_map_io(void)
static __init void dm365_evm_init(void)
{
+ struct davinci_soc_info *soc_info = davinci_soc_info;
+
evm_init_i2c();
davinci_serial_init(uart_config);
+
+ dm365evm_emac_configure();
+
+ soc_info-emac_pdata-phy_mask = DM365_EVM_PHY_MASK;
+ soc_info-emac_pdata-mdio_max_freq = DM365_EVM_MDIO_FREQUENCY;
}
static __init void dm365_evm_irq_init(void)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index c9ae97a..9d615db 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -546,6 +546,52 @@ INT_CFG(DM365, INT_EMAC_MISCPULSE, 17,1,1,
false)
#endif
};
+static struct emac_platform_data dm365_emac_pdata = {
+ .ctrl_reg_offset= DM365_EMAC_CNTRL_OFFSET,
+ .ctrl_mod_reg_offset= DM365_EMAC_CNTRL_MOD_OFFSET,
+ .ctrl_ram_offset= DM365_EMAC_CNTRL_RAM_OFFSET,
+ .mdio_reg_offset= DM365_EMAC_MDIO_OFFSET,
+ .ctrl_ram_size = DM365_EMAC_CNTRL_RAM_SIZE,
+ .version= EMAC_VERSION_2,
+};
+
+static struct resource dm365_emac_resources[] = {
+ {
+ .start = DM365_EMAC_BASE,
+ .end= DM365_EMAC_BASE + 0x47ff,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = IRQ_DM365_EMAC_RXTHRESH,
+ .end= IRQ_DM365_EMAC_RXTHRESH,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = IRQ_DM365_EMAC_RXPULSE,
+ .end= IRQ_DM365_EMAC_RXPULSE,
+ .flags = IORESOURCE_IRQ,
+ },
+
[PATCH 19/26] davinci: dm365: add MMC/SD support
From: Sandeep Paulraj s-paul...@ti.com
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-davinci/devices.c | 45 ++
1 files changed, 31 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index 385e833..a55b650 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -31,6 +31,8 @@
#define DAVINCI_MMCSD0_BASE 0x01E1
#define DM355_MMCSD0_BASE 0x01E11000
#define DM355_MMCSD1_BASE 0x01E0
+#define DM365_MMCSD0_BASE 0x01D11000
+#define DM365_MMCSD1_BASE 0x01D0
static struct resource i2c_resources[] = {
{
@@ -154,19 +156,31 @@ void __init davinci_setup_mmc(int module, struct
davinci_mmc_config *config)
*/
switch (module) {
case 1:
- if (!cpu_is_davinci_dm355())
+ if (cpu_is_davinci_dm355()) {
+ /* REVISIT we may not need all these pins if e.g. this
+* is a hard-wired SDIO device...
+*/
+ davinci_cfg_reg(DM355_SD1_CMD);
+ davinci_cfg_reg(DM355_SD1_CLK);
+ davinci_cfg_reg(DM355_SD1_DATA0);
+ davinci_cfg_reg(DM355_SD1_DATA1);
+ davinci_cfg_reg(DM355_SD1_DATA2);
+ davinci_cfg_reg(DM355_SD1_DATA3);
+ } else if (cpu_is_davinci_dm365()) {
+ void __iomem *pupdctl1 =
+ IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE + 0x7c);
+
+ /* Configure pull down control */
+ __raw_writel((__raw_readl(pupdctl1) ~0x400),
+ pupdctl1);
+
+ mmcsd1_resources[0].start = DM365_MMCSD1_BASE;
+ mmcsd1_resources[0].end = DM365_MMCSD1_BASE +
+ SZ_4K - 1;
+ mmcsd0_resources[2].start = IRQ_DM365_SDIOINT1;
+ } else
break;
- /* REVISIT we may not need all these pins if e.g. this
-* is a hard-wired SDIO device...
-*/
- davinci_cfg_reg(DM355_SD1_CMD);
- davinci_cfg_reg(DM355_SD1_CLK);
- davinci_cfg_reg(DM355_SD1_DATA0);
- davinci_cfg_reg(DM355_SD1_DATA1);
- davinci_cfg_reg(DM355_SD1_DATA2);
- davinci_cfg_reg(DM355_SD1_DATA3);
-
pdev = davinci_mmcsd1_device;
break;
case 0:
@@ -180,9 +194,12 @@ void __init davinci_setup_mmc(int module, struct
davinci_mmc_config *config)
/* enable RX EDMA */
davinci_cfg_reg(DM355_EVT26_MMC0_RX);
- }
-
- else if (cpu_is_davinci_dm644x()) {
+ } else if (cpu_is_davinci_dm365()) {
+ mmcsd0_resources[0].start = DM365_MMCSD0_BASE;
+ mmcsd0_resources[0].end = DM365_MMCSD0_BASE +
+ SZ_4K - 1;
+ mmcsd0_resources[2].start = IRQ_DM365_SDIOINT0;
+ } else if (cpu_is_davinci_dm644x()) {
/* REVISIT: should this be in board-init code? */
void __iomem *base =
IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
--
1.6.3.3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 20/26] davinci: MMC/SD Support for dm365 EVM
From: Sandeep Paulraj s-paul...@ti.com
Patch adds support for MMC/SD in the DM365 EVM.
Pinmux for MMC/SD slot 1 on the DM365 EVM is also
configured.
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-davinci/board-dm365-evm.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index 9dda399..e62d1ab 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -33,6 +33,7 @@
#include linux/i2c.h
#include mach/serial.h
#include mach/common.h
+#include mach/mmc.h
#define DM365_EVM_PHY_MASK (0x2)
#define DM365_EVM_MDIO_FREQUENCY (220) /* PHY bus frequency */
@@ -57,6 +58,13 @@ static struct davinci_i2c_platform_data i2c_pdata = {
.bus_delay = 0 /* usec */,
};
+static struct davinci_mmc_config dm365evm_mmc_config = {
+ .wires = 4,
+ .max_freq = 5000,
+ .caps = MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
+ .version= MMC_CTLR_VERSION_2,
+};
+
static void dm365evm_emac_configure(void)
{
/*
@@ -93,6 +101,21 @@ static void dm365evm_emac_configure(void)
davinci_cfg_reg(DM365_INT_EMAC_MISCPULSE);
}
+static void dm365evm_mmc_configure(void)
+{
+ /*
+* MMC/SD pins are multiplexed with GPIO and EMIF
+* Further details are available at the DM365 ARM
+* Subsystem Users Guide(sprufg5.pdf) pages 118, 128 - 131
+*/
+ davinci_cfg_reg(DM365_SD1_CLK);
+ davinci_cfg_reg(DM365_SD1_CMD);
+ davinci_cfg_reg(DM365_SD1_DATA3);
+ davinci_cfg_reg(DM365_SD1_DATA2);
+ davinci_cfg_reg(DM365_SD1_DATA1);
+ davinci_cfg_reg(DM365_SD1_DATA0);
+}
+
static void __init evm_init_i2c(void)
{
davinci_init_i2c(i2c_pdata);
@@ -116,6 +139,10 @@ static __init void dm365_evm_init(void)
davinci_serial_init(uart_config);
dm365evm_emac_configure();
+ dm365evm_mmc_configure();
+
+ davinci_setup_mmc(0, dm365evm_mmc_config);
+ davinci_setup_mmc(1, dm365evm_mmc_config);
soc_info-emac_pdata-phy_mask = DM365_EVM_PHY_MASK;
soc_info-emac_pdata-mdio_max_freq = DM365_EVM_MDIO_FREQUENCY;
--
1.6.3.3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 22/26] davinci: dm365 evm cpld support: leds, card detect, other setup
From: David Brownell dbrown...@users.sourceforge.net
Add basic support for the CPLD on the DM365 EVM board:
- Read SW5 to set up NAND and keypad vs (someday) OneNAND
- Export MMC/SD card detect and writeprotect signals
- LED support (same layout as on DM355 EVM)
- Static config for video input:
* external HD imager precludes MMC1, Ethernet, audio
* else either tvp5146 (SD/default) or tvp7002 (HD)
The video input could actually be switched around dynamically;
change that if/when that's needed (and after those other video
inputs have driver support).
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-davinci/board-dm365-evm.c | 263 +--
1 files changed, 253 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index 3675e84..a1d5e7d 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -20,6 +20,7 @@
#include linux/io.h
#include linux/clk.h
#include linux/i2c/at24.h
+#include linux/leds.h
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
#include linux/mtd/nand.h
@@ -33,18 +34,71 @@
#include mach/psc.h
#include mach/common.h
#include mach/i2c.h
-#include linux/i2c.h
#include mach/serial.h
#include mach/common.h
#include mach/mmc.h
#include mach/nand.h
+
+static inline int have_imager(void)
+{
+ /* REVISIT when it's supported, trigger via Kconfig */
+ return 0;
+}
+
+static inline int have_tvp7002(void)
+{
+ /* REVISIT when it's supported, trigger via Kconfig */
+ return 0;
+}
+
+
#define DM365_ASYNC_EMIF_CONTROL_BASE 0x01d1
#define DM365_ASYNC_EMIF_DATA_CE0_BASE 0x0200
+#define DM365_ASYNC_EMIF_DATA_CE1_BASE 0x0400
#define DM365_EVM_PHY_MASK (0x2)
#define DM365_EVM_MDIO_FREQUENCY (220) /* PHY bus frequency */
+/*
+ * A MAX-II CPLD is used for various board control functions.
+ */
+#define CPLD_OFFSET(a13a8,a2a1)(((a13a8) 10) + ((a2a1)
3))
+
+#define CPLD_VERSION CPLD_OFFSET(0,0)/* r/o */
+#define CPLD_TEST CPLD_OFFSET(0,1)
+#define CPLD_LEDS CPLD_OFFSET(0,2)
+#define CPLD_MUX CPLD_OFFSET(0,3)
+#define CPLD_SWITCHCPLD_OFFSET(1,0)/* r/o */
+#define CPLD_POWER CPLD_OFFSET(1,1)
+#define CPLD_VIDEO CPLD_OFFSET(1,2)
+#define CPLD_CARDSTAT CPLD_OFFSET(1,3)/* r/o */
+
+#define CPLD_DILC_OUT CPLD_OFFSET(2,0)
+#define CPLD_DILC_IN CPLD_OFFSET(2,1)/* r/o */
+
+#define CPLD_IMG_DIR0 CPLD_OFFSET(2,2)
+#define CPLD_IMG_MUX0 CPLD_OFFSET(2,3)
+#define CPLD_IMG_MUX1 CPLD_OFFSET(3,0)
+#define CPLD_IMG_DIR1 CPLD_OFFSET(3,1)
+#define CPLD_IMG_MUX2 CPLD_OFFSET(3,2)
+#define CPLD_IMG_MUX3 CPLD_OFFSET(3,3)
+#define CPLD_IMG_DIR2 CPLD_OFFSET(4,0)
+#define CPLD_IMG_MUX4 CPLD_OFFSET(4,1)
+#define CPLD_IMG_MUX5 CPLD_OFFSET(4,2)
+
+#define CPLD_RESETSCPLD_OFFSET(4,3)
+
+#define CPLD_CCD_DIR1 CPLD_OFFSET(0x3e,0)
+#define CPLD_CCD_IO1 CPLD_OFFSET(0x3e,1)
+#define CPLD_CCD_DIR2 CPLD_OFFSET(0x3e,2)
+#define CPLD_CCD_IO2 CPLD_OFFSET(0x3e,3)
+#define CPLD_CCD_DIR3 CPLD_OFFSET(0x3f,0)
+#define CPLD_CCD_IO3 CPLD_OFFSET(0x3f,1)
+
+static void __iomem *cpld;
+
+
/* NOTE: this is geared for the standard config, with a socketed
* 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors. If you
* swap chips with a different block size, partitioning will
@@ -135,7 +189,27 @@ static struct davinci_i2c_platform_data i2c_pdata = {
.bus_delay = 0 /* usec */,
};
+static int cpld_mmc_get_cd(int module)
+{
+ if (!cpld)
+ return -ENXIO;
+
+ /* low == card present */
+ return !(__raw_readb(cpld + CPLD_CARDSTAT) BIT(module ? 4 : 0));
+}
+
+static int cpld_mmc_get_ro(int module)
+{
+ if (!cpld)
+ return -ENXIO;
+
+ /* high == card's write protect switch active */
+ return !!(__raw_readb(cpld + CPLD_CARDSTAT) BIT(module ? 5 : 1));
+}
+
static struct davinci_mmc_config dm365evm_mmc_config = {
+ .get_cd = cpld_mmc_get_cd,
+ .get_ro = cpld_mmc_get_ro,
.wires = 4,
.max_freq = 5000,
.caps = MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
@@ -199,10 +273,185 @@ static void __init evm_init_i2c(void)
i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));
}
-static struct platform_device *dm365_evm_devices[] __initdata = {
+static struct platform_device *dm365_evm_nand_devices[] __initdata = {
davinci_nand_device,
};
+static inline int have_leds(void)
+{
+#ifdef CONFIG_LEDS_CLASS
+ return 1;
+#else
+ return 0;
+#endif
+}
+
+struct cpld_led {
+ struct led_classdev cdev;
+ u8 mask;
+};
+
+static const struct {
+ const char *name;
+ const char *trigger;
+} cpld_leds[] = {
+
[PATCH 24/26] davinci: da8xx: Add support for DA830/OMAP-L137 EVM board
From: Mark A. Greer mgr...@mvista.com Add support for the DA830/OMAP-L137 Evaluation Module (EVM) from TI. The EVM has User Interface (UI) and Audio cards that can be connected which contain various devices. Support for those devices and ones on the EVM will be added in subsequent patches. Additional generalizations for future SoCs in da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen sc...@mvista.com Signed-off-by: Mark A. Greer mgr...@mvista.com Cc: Sudhakar Rajashekhara sudhakar@ti.com Cc: Sekhar Nori nsek...@ti.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/configs/da830_omapl137_defconfig| 1254 ++ arch/arm/mach-davinci/Kconfig|6 + arch/arm/mach-davinci/Makefile |1 + arch/arm/mach-davinci/board-da830-evm.c | 127 +++ arch/arm/mach-davinci/include/mach/debug-macro.S |7 + arch/arm/mach-davinci/include/mach/uncompress.h |6 +- 6 files changed, 1399 insertions(+), 2 deletions(-) create mode 100644 arch/arm/configs/da830_omapl137_defconfig create mode 100644 arch/arm/mach-davinci/board-da830-evm.c diff --git a/arch/arm/configs/da830_omapl137_defconfig b/arch/arm/configs/da830_omapl137_defconfig new file mode 100644 index 000..7c8e38f --- /dev/null +++ b/arch/arm/configs/da830_omapl137_defconfig @@ -0,0 +1,1254 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.30-rc2-davinci1 +# Wed May 13 15:33:29 2009 +# +CONFIG_ARM=y +CONFIG_SYS_SUPPORTS_APM_EMULATION=y +CONFIG_GENERIC_GPIO=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_MMU=y +# CONFIG_NO_IOPORT is not set +CONFIG_GENERIC_HARDIRQS=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_HAVE_LATENCYTOP_SUPPORT=y +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_TRACE_IRQFLAGS_SUPPORT=y +CONFIG_HARDIRQS_SW_RESEND=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_RWSEM_GENERIC_SPINLOCK=y +# CONFIG_ARCH_HAS_ILOG2_U32 is not set +# CONFIG_ARCH_HAS_ILOG2_U64 is not set +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_ZONE_DMA=y +CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y +CONFIG_VECTORS_BASE=0x +CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_LOCK_KERNEL=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION= +CONFIG_LOCALVERSION_AUTO=y +# CONFIG_SWAP is not set +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +CONFIG_POSIX_MQUEUE=y +CONFIG_POSIX_MQUEUE_SYSCTL=y +# CONFIG_BSD_PROCESS_ACCT is not set +# CONFIG_TASKSTATS is not set +# CONFIG_AUDIT is not set + +# +# RCU Subsystem +# +CONFIG_CLASSIC_RCU=y +# CONFIG_TREE_RCU is not set +# CONFIG_PREEMPT_RCU is not set +# CONFIG_TREE_RCU_TRACE is not set +# CONFIG_PREEMPT_RCU_TRACE is not set +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_GROUP_SCHED=y +CONFIG_FAIR_GROUP_SCHED=y +# CONFIG_RT_GROUP_SCHED is not set +CONFIG_USER_SCHED=y +# CONFIG_CGROUP_SCHED is not set +# CONFIG_CGROUPS is not set +CONFIG_SYSFS_DEPRECATED=y +CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_RELAY is not set +# CONFIG_NAMESPACES is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE= +CONFIG_RD_GZIP=y +# CONFIG_RD_BZIP2 is not set +# CONFIG_RD_LZMA is not set +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL=y +CONFIG_ANON_INODES=y +CONFIG_EMBEDDED=y +CONFIG_UID16=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +# CONFIG_KALLSYMS_EXTRA_PASS is not set +# CONFIG_STRIP_ASM_SYMS is not set +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_TIMERFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_AIO=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_SLUB_DEBUG=y +CONFIG_COMPAT_BRK=y +# CONFIG_SLAB is not set +CONFIG_SLUB=y +# CONFIG_SLOB is not set +# CONFIG_PROFILING is not set +# CONFIG_MARKERS is not set +CONFIG_HAVE_OPROFILE=y +# CONFIG_KPROBES is not set +CONFIG_HAVE_KPROBES=y +CONFIG_HAVE_KRETPROBES=y +CONFIG_HAVE_CLK=y +# CONFIG_SLOW_WORK is not set +CONFIG_HAVE_GENERIC_DMA_COHERENT=y +CONFIG_SLABINFO=y +CONFIG_RT_MUTEXES=y +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +# CONFIG_MODULE_FORCE_LOAD is not set +CONFIG_MODULE_UNLOAD=y +CONFIG_MODULE_FORCE_UNLOAD=y +CONFIG_MODVERSIONS=y +# CONFIG_MODULE_SRCVERSION_ALL is not set +CONFIG_BLOCK=y +# CONFIG_LBD is not set +# CONFIG_BLK_DEV_BSG is not set +# CONFIG_BLK_DEV_INTEGRITY is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +# CONFIG_IOSCHED_DEADLINE is not set +# CONFIG_IOSCHED_CFQ is not set +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED=anticipatory +# CONFIG_FREEZER is not set + +# +# System Type +# +# CONFIG_ARCH_AAEC2000 is not set +# CONFIG_ARCH_INTEGRATOR is not set +# CONFIG_ARCH_REALVIEW is not set +# CONFIG_ARCH_VERSATILE is not set +#
[PATCH 26/26] davinci: dm365 gpio irq support
From: David Brownell dbrown...@users.sourceforge.net
Support DM365 GPIOs ... primarily by handling non-banked GPIO IRQs:
- Flag DM365 chips as using non-banked GPIO interrupts, using a
new soc_info field.
- Replace the gpio_to_irq() mapping logic. This now uses some
runtime infrastructure, keyed off that new soc_info field,
which doesn't handle irq_to_gpio().
- Provide a new irq_chip ... GPIO IRQs handled directly by AINTC
still need edge triggering managed by the GPIO controller.
DM365 chips no longer falsely report 104 GPIO IRQs as they boot.
Intelligence about IRQ muxing is missing, so for the moment this
only exposes the first eight DM365 GPIOs, which are never muxed.
The next eight are muxed, half with Ethernet (which uses most of
those pins anyway).
Tested on DM355 (10 unbanked IRQs _or_ 104 banked ones) and also
on DM365 (16 unbanked ones, only 8 made available).
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-davinci/dm365.c |3 +-
arch/arm/mach-davinci/gpio.c| 105 +--
arch/arm/mach-davinci/include/mach/common.h |1 +
arch/arm/mach-davinci/include/mach/gpio.h |8 +--
4 files changed, 105 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 0789de0..e5fb9e4 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -878,7 +878,8 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
.timer_info = dm365_timer_info,
.gpio_base = IO_ADDRESS(DAVINCI_GPIO_BASE),
.gpio_num = 104,
- .gpio_irq = 44,
+ .gpio_irq = IRQ_DM365_GPIO0,
+ .gpio_unbanked = 8,/* really 16 ... skip muxed GPIOs */
.serial_dev = dm365_serial_device,
.emac_pdata = dm365_emac_pdata,
.sram_dma = 0x0001,
diff --git a/arch/arm/mach-davinci/gpio.c b/arch/arm/mach-davinci/gpio.c
index 1b65321..f6ea9db 100644
--- a/arch/arm/mach-davinci/gpio.c
+++ b/arch/arm/mach-davinci/gpio.c
@@ -34,6 +34,7 @@ static DEFINE_SPINLOCK(gpio_lock);
struct davinci_gpio {
struct gpio_chipchip;
struct gpio_controller *__iomem regs;
+ int irq_base;
};
static struct davinci_gpio chips[DIV_ROUND_UP(DAVINCI_N_GPIO, 32)];
@@ -161,8 +162,7 @@ pure_initcall(davinci_gpio_setup);
* used as output pins ... which is convenient for testing.
*
* NOTE: The first few GPIOs also have direct INTC hookups in addition
- * to their GPIOBNK0 irq, with a bit less overhead but less flexibility
- * on triggering (e.g. no edge options). We don't try to use those.
+ * to their GPIOBNK0 irq, with a bit less overhead.
*
* All those INTC hookups (direct, plus several IRQ banks) can also
* serve as EDMA event triggers.
@@ -171,7 +171,7 @@ pure_initcall(davinci_gpio_setup);
static void gpio_irq_disable(unsigned irq)
{
struct gpio_controller *__iomem g = get_irq_chip_data(irq);
- u32 mask = __gpio_mask(irq_to_gpio(irq));
+ u32 mask = (u32) get_irq_data(irq);
__raw_writel(mask, g-clr_falling);
__raw_writel(mask, g-clr_rising);
@@ -180,7 +180,7 @@ static void gpio_irq_disable(unsigned irq)
static void gpio_irq_enable(unsigned irq)
{
struct gpio_controller *__iomem g = get_irq_chip_data(irq);
- u32 mask = __gpio_mask(irq_to_gpio(irq));
+ u32 mask = (u32) get_irq_data(irq);
unsigned status = irq_desc[irq].status;
status = IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING;
@@ -196,7 +196,7 @@ static void gpio_irq_enable(unsigned irq)
static int gpio_irq_type(unsigned irq, unsigned trigger)
{
struct gpio_controller *__iomem g = get_irq_chip_data(irq);
- u32 mask = __gpio_mask(irq_to_gpio(irq));
+ u32 mask = (u32) get_irq_data(irq);
if (trigger ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
return -EINVAL;
@@ -260,6 +260,45 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)
/* now it may re-trigger */
}
+static int gpio_to_irq_banked(struct gpio_chip *chip, unsigned offset)
+{
+ struct davinci_gpio *d = container_of(chip, struct davinci_gpio, chip);
+
+ if (d-irq_base = 0)
+ return d-irq_base + offset;
+ else
+ return -ENODEV;
+}
+
+static int gpio_to_irq_unbanked(struct gpio_chip *chip, unsigned offset)
+{
+ struct davinci_soc_info *soc_info = davinci_soc_info;
+
+ /* NOTE: we assume for now that only irqs in the first gpio_chip
+* can provide direct-mapped IRQs to AINTC (up to 32 GPIOs).
+*/
+ if (offset soc_info-gpio_unbanked)
+ return soc_info-gpio_irq + offset;
+ else
+ return -ENODEV;
+}
+
+static int
Re: [alsa-devel] davinci-i2c,pcm updates
Mark Brown broo...@opensource.wolfsonmicro.com writes: Could you give a pointer to the SRAM allocator patch, please? SRAM allocater changes are in mainline as of 2.6.31. See arch/arm/mach-davinci/sram.c. Kevin ___ 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 07/26] davinci: dm646x: Adds McASP clock
Mark Brown broo...@sirena.org.uk writes: On Mon, Jul 06, 2009 at 02:14:41PM -0700, Kevin Hilman wrote: From: Chaithrika U S chaithr...@ti.com Adds McASP clock support for the two instances of mcasp (mcasp0,mcasp1). This patch is part of the audio support for dm646x series. Signed-off-by: Naresh Medisetty nar...@ti.com Signed-off-by: Chaithrika U S chaithr...@ti.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com I guess it's safe for me to go ahead and merge the ASoC changes that were waiting for this now, then? Yes, go ahead. IIRC it's runtime dependencies only so there should be no merge issues. There shouldn't be any merge issues, but there will be some compile issues. The DaVinci core had some EDMA changes which are now part of my 'davinci-next' queue in DaVinci git[1]. Also, in the same tree, I have a 'davinci-next-drivers' branch which includes a commit for the ASoC changes needed on top of the EDMA API changes, as well as another unrelated change for default volume. I'll send those to alsa-devel shortly. Kevin [1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git ___ 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] ASoC: davinci: update after EDMA interface changes
From: Sudhakar Rajashekhara sudhakar@ti.com
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Reviewed-by: David Brownell dbrown...@users.sourceforge.net
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
sound/soc/davinci/davinci-evm.c |8
sound/soc/davinci/davinci-pcm.c |6 +++---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index 58fd1cb..832d5db 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -175,8 +175,8 @@ static struct resource evm_snd_resources[] = {
};
static struct evm_snd_platform_data evm_snd_data = {
- .tx_dma_ch = DAVINCI_DMA_ASP0_TX,
- .rx_dma_ch = DAVINCI_DMA_ASP0_RX,
+ .tx_dma_ch = EDMA_CTLR_CHAN(0, DAVINCI_DMA_ASP0_TX),
+ .rx_dma_ch = EDMA_CTLR_CHAN(0, DAVINCI_DMA_ASP0_RX),
};
/* DM335 EVM uses ASP1; line-out is a stereo mini-jack */
@@ -189,8 +189,8 @@ static struct resource dm335evm_snd_resources[] = {
};
static struct evm_snd_platform_data dm335evm_snd_data = {
- .tx_dma_ch = DAVINCI_DMA_ASP1_TX,
- .rx_dma_ch = DAVINCI_DMA_ASP1_RX,
+ .tx_dma_ch = EDMA_CTLR_CHAN(0, DAVINCI_DMA_ASP1_TX),
+ .rx_dma_ch = EDMA_CTLR_CHAN(0, DAVINCI_DMA_ASP1_RX),
};
static struct platform_device *evm_snd_device;
diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c
index a059965..3ee38b6 100644
--- a/sound/soc/davinci/davinci-pcm.c
+++ b/sound/soc/davinci/davinci-pcm.c
@@ -143,7 +143,7 @@ static int davinci_pcm_dma_request(struct snd_pcm_substream
*substream)
prtd-master_lch = ret;
/* Request parameter RAM reload slot */
- ret = edma_alloc_slot(EDMA_SLOT_ANY);
+ ret = edma_alloc_slot(EDMA_CTLR(prtd-master_lch), EDMA_SLOT_ANY);
if (ret 0) {
edma_free_channel(prtd-master_lch);
return ret;
@@ -160,8 +160,8 @@ static int davinci_pcm_dma_request(struct snd_pcm_substream
*substream)
* so davinci_pcm_enqueue_dma() takes less time in IRQ.
*/
edma_read_slot(prtd-slave_lch, p_ram);
- p_ram.opt |= TCINTEN | EDMA_TCC(prtd-master_lch);
- p_ram.link_bcntrld = prtd-slave_lch 5;
+ p_ram.opt |= TCINTEN | EDMA_TCC(EDMA_CHAN_SLOT(prtd-master_lch));
+ p_ram.link_bcntrld = EDMA_CHAN_SLOT(prtd-slave_lch) 5;
edma_write_slot(prtd-slave_lch, p_ram);
return 0;
--
1.6.3.3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [alsa-devel] [PATCH V1 10/11] ASoC: DaVinci: i2s don't limit rates
Mark Brown wrote: On Sat, Jul 04, 2009 at 07:30:00PM -0700, Troy Kisky wrote: If the codec is master, we support anything that the codec supports. Hrm, tricky - the rate configuration doesn't depend on what is master so this could cause confusion if the codec is slave. -#define DAVINCI_I2S_RATES SNDRV_PCM_RATE_8000_96000 +#define DAVINCI_I2S_RATES (SNDRV_PCM_RATE_8000_96000 |\ +SNDRV_PCM_RATE_5512 | SNDRV_PCM_RATE_KNOT | SNDRV_PCM_RATE_CONTINUOUS) Note that the ASoC core doesn't support _KNOT or _CONTINUOUS (at least not properly) so the only thing you should get from this is 5512. Is that really worth worrying about the master/slave problem? Ok. I'll drop this. I just needed it when I was testing all rates my codec supports. Now that I've tested it, I don't think I'll ever use the other rates. But even if the cpu is the clock/frame master, the sample rate generator has an 8 bit divider field, which seems to be always 0 in the current code. And I don't see any reference to params_rate in the davinci-i2s.c file. Has anyone tried the cpu as master??? Troy ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 0/2] davinci ASoC interface changes
This series updates the DaVinci ASoC support after various DaVinci core interface changes. These core changes are part of the DaVinci core changes submitted for 2.6.32. This compiles on top of the v2.6.31-rc2 based 'davinci-next' branch of the DaVinci git repo here: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git Naresh Medisetty (1): ASoC: DaVinci: Change default output volume Sudhakar Rajashekhara (1): ASoC: davinci: update after EDMA interface changes sound/soc/codecs/tlv320aic3x.h |2 +- sound/soc/davinci/davinci-evm.c |8 sound/soc/davinci/davinci-pcm.c |6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] IDE: palm_bk3710: convert clock usage after clkdev conversion
DaVinci core code has converted to the new clkdev API so
clock name strings are not needed. Instead, just the a
'struct device' pointer is needed.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
Fix needed for 2.6.31
drivers/ide/palm_bk3710.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/ide/palm_bk3710.c b/drivers/ide/palm_bk3710.c
index 3c1dc01..f8eddf0 100644
--- a/drivers/ide/palm_bk3710.c
+++ b/drivers/ide/palm_bk3710.c
@@ -318,7 +318,7 @@ static int __init palm_bk3710_probe(struct platform_device
*pdev)
int i, rc;
struct ide_hw hw, *hws[] = { hw };
- clk = clk_get(pdev-dev, IDECLK);
+ clk = clk_get(pdev-dev, NULL);
if (IS_ERR(clk))
return -ENODEV;
--
1.6.3.3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [alsa-devel] [PATCH V1 10/11] ASoC: DaVinci: i2s don't limit rates
Mark Brown wrote: On Mon, Jul 06, 2009 at 03:01:54PM -0700, Troy Kisky wrote: But even if the cpu is the clock/frame master, the sample rate generator has an 8 bit divider field, which seems to be always 0 in the current code. And I don't see any reference to params_rate in the davinci-i2s.c file. Has anyone tried the cpu as master??? It does appear that way, doesn't it? But looking at the code davinci-sffsdr runs with the CPU as frame master so I'd have expected that it would have shown any problems here. But in this case the clock to divide would come from the CLKR pin, so a divide by (0+1) would be correct. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [alsa-devel] [PATCH 1/2] ASoC: davinci: update after EDMA interface changes
Mark Brown broo...@opensource.wolfsonmicro.com writes: On Mon, Jul 06, 2009 at 03:19:01PM -0700, Kevin Hilman wrote: So should I queue this up along with my changes, or do you want to merge this into asoc? It needs to go along with your changes at least to preserve bisect (it should really be in the same commit that changes the API from that point of view). OK, it was originally part of the same patch, but I separated it out thinking that the sound/* part would go upstream separately. I'll merge it back into the original commit and update davinci-next. But see my reply to Troy's post - he's got some further ASoC changes which depend on the new API and complicate matters a little. OK, will reply there. Kevin ___ 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 10/26] davinci: Kconfig: enable EVMs by default when SoCs are enabled
Russell King - ARM Linux li...@arm.linux.org.uk writes: On Mon, Jul 06, 2009 at 02:14:44PM -0700, Kevin Hilman wrote: @@ -34,6 +34,7 @@ config MACH_DAVINCI_EVM config MACH_SFFSDR bool Lyrtech SFFSDR +default n There's absolutely no need for this (or the other one below). @@ -48,6 +50,7 @@ config MACH_DAVINCI_DM355_EVM config MACH_DM355_LEOPARD bool DM355 Leopard board +default n OK, removed the 2 instances o'default n' from this patch. Kevin ___ 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] i2c-davinci: behave with i2cdetect
From: David Brownell dbrown...@users.sourceforge.net Make i2c-davinci cope properly with i2cdetect: don't spew syslog spam on perfectly normal behaviors, or respond to any address other than the one reserved for the SMBus host. Signed-off-by: David Brownell dbrown...@users.sourceforge.net Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- drivers/i2c/busses/i2c-davinci.c | 18 ++ 1 files changed, 14 insertions(+), 4 deletions(-) diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c index ee3fbb8..1f3d89c 100644 --- a/drivers/i2c/busses/i2c-davinci.c +++ b/drivers/i2c/busses/i2c-davinci.c @@ -187,6 +187,11 @@ static int i2c_davinci_init(struct davinci_i2c_dev *dev) davinci_i2c_write_reg(dev, DAVINCI_I2C_CLKH_REG, clkh); davinci_i2c_write_reg(dev, DAVINCI_I2C_CLKL_REG, clkl); + /* Respond at reserved SMBus Host slave address (and zero); +* we seem to have no option to not respond... +*/ + davinci_i2c_write_reg(dev, DAVINCI_I2C_OAR_REG, 0x08); + dev_dbg(dev-dev, input_clock = %d, CLK = %d\n, input_clock, clk); dev_dbg(dev-dev, PSC = %d\n, davinci_i2c_read_reg(dev, DAVINCI_I2C_PSC_REG)); @@ -387,7 +392,7 @@ static void terminate_write(struct davinci_i2c_dev *dev) davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, w); if (!dev-terminate) - dev_err(dev-dev, TDR IRQ while no data to send\n); + dev_dbg(dev-dev, TDR IRQ while no data to send\n); } /* @@ -473,9 +478,14 @@ static irqreturn_t i2c_davinci_isr(int this_irq, void *dev_id) break; case DAVINCI_I2C_IVR_AAS: - dev_warn(dev-dev, Address as slave interrupt\n); - }/* switch */ - }/* while */ + dev_dbg(dev-dev, Address as slave interrupt\n); + break; + + default: + dev_warn(dev-dev, Unrecognized irq stat %d\n, stat); + break; + } + } return count ? IRQ_HANDLED : IRQ_NONE; } -- 1.6.3.3 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 0/2] davinci i2c fixes for 2.6.31
Here are a couple fixes for the i2c driver on the TI DaVinci family of SoCs. These have been tested for awhile in the DaVinci git repo are needed for 2.6.31. These apply on v2.6.31-rc2. David Brownell (1): i2c-davinci: behave with i2cdetect Kevin Hilman (1): i2c-davinci: convert clock usage after clkdev conversion drivers/i2c/busses/i2c-davinci.c | 20 +++- 1 files changed, 15 insertions(+), 5 deletions(-) ___ 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] i2c-davinci: convert clock usage after clkdev conversion
DaVinci core code has converted to the new clkdev API so
clock name strings are not needed. Instead, just the a
'struct device' pointer is needed.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
drivers/i2c/busses/i2c-davinci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 3fae3a9..ee3fbb8 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -523,7 +523,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
dev-irq = irq-start;
platform_set_drvdata(pdev, dev);
- dev-clk = clk_get(pdev-dev, I2CCLK);
+ dev-clk = clk_get(pdev-dev, NULL);
if (IS_ERR(dev-clk)) {
r = -ENODEV;
goto err_free_mem;
--
1.6.3.3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [alsa-devel] davinci-i2c,pcm updates
Mark Brown broo...@opensource.wolfsonmicro.com writes: On Mon, Jul 06, 2009 at 02:30:21PM -0700, Troy Kisky wrote: ARM: DaVinci: Interface changes visible to EDMA clients But the last patch in series needs rebased on to this. Unfortunately, this patch is not yet in your for-2.6.32 branch. So, unless this patch is going to merge first, I show remove the need for this patch??? Unless you can make your changes such that the above patch will merge in cleanly there's no point - we'll need to deal with the cross tree merge issues somehow. That'll require coordination with Kevin; probably the best approach is to make a small branch which can be merged into both trees but that may be too involved. For now, how about making anything that has arch/arm dependencies apply to the 'davinci-next' branch of DaVinci git. Kevin ___ 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] DaVinci: MMC: MMC/SD controller driver for DaVinci family.
Pierre,
Vipin Bhandari vipin.bhand...@ti.com writes:
This patch adds support for MMC/SD controller driver for all DaVinci family
SoC. This patch supports davinci family SoC's DM6446, DM355, DM365 and
DA830/OMAPL137.
The patch has been tested on DM355 EVM.
The MMCSD controller specifications for DM355 can be found at
http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=spruee2c
Signed-off-by: Vipin Bhandari vipin.bhand...@ti.com
Signed-off-by: Purshotam Kumar purusho...@ti.com
Acked-by: David Brownell dbrown...@users.sourceforge.net
I don't yet see this driver upstream (at least not in linux-next.)
Do you have this queued someplace?
There is one other DaVinci MMC update needed after this patch due to
some EDMA API changes in the DaVinci core which are queued for 2.6.32,
so if this is queued for .31 it can go as is. If it is queued for .32,
the patch below should be folded in.
Thanks,
Kevin
From: Rajashekhara, Sudhakar sudhakar@ti.com
Subject: [PATCH] davinci: Fix MMCSD compilation issue
To: davinci-linux-open-source@linux.davincidsp.com
Date: Wed, 24 Jun 2009 07:57:48 -0400
Passes channel controller number as the first argument to
edma_alloc_slot() API. Without this patch, kernel compilation
fails with too few arguments to function 'edma_alloc_slot'
error.
This patch has been tested on DM6446 EVM.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
---
drivers/mmc/host/davinci_mmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index 170a0a0..e1095f3 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -589,7 +589,7 @@ static int __init davinci_acquire_dma_channels(struct
mmc_davinci_host *host)
* channel as needed to handle a scatterlist.
*/
for (i = 0; i ARRAY_SIZE(host-links); i++) {
- r = edma_alloc_slot(EDMA_SLOT_ANY);
+ r = edma_alloc_slot(EDMA_CTLR(host-txdma), EDMA_SLOT_ANY);
if (r 0) {
dev_dbg(mmc_dev(host-mmc), dma PaRAM alloc -- %d\n,
r);
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
DaVinci git updated to v2.6.31-rc2
FYI... DaVinci git has been updatd to v2.6.31-rc2 and includes a sync/merge with the various branches I've been pushing upstream. Boot tested davinci_all_defconfig on dm6446 EVM, dm355 EVM and dm6467 EVM. I also created a 'davinci-2.6.30' branch for those who wish to keep working on a 2.6.30 base. Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [alsa-devel] [PATCH V1 11/11] ASoC: DaVinci: pcm, fix underruns by using sram
Mark Brown wrote:
On Sat, Jul 04, 2009 at 07:30:01PM -0700, Troy Kisky wrote:
If you mean that it should start and
stop the clocks
Yes.
that causes issues in situations like TDM since there
can be transfers going on independantly of the CPU which may need the
clocks running. Not everything will be able to gate the clocks, too.
What is TDM? time division multiplexing? You mean the frame carries
more than just audio data? I think I'm misunderstanding something.
Can you elaborate please.
In any case, this looks like a separate patch that should be split out
of this one.
+if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK) {
+/* reading ram before asp should be safe
+ * as long as the asp transfers less than a ping size
+ * of bytes between the 2 reads
+ */
+edma_get_position(prtd-ram_master_lch,
+ram_src, ram_dst);
+edma_get_position(prtd-asp_master_lch,
+asp_src, asp_dst);
+count_asp = asp_src - prtd-asp_params.src;
+count_ram = ram_src - prtd-ram_params.src;
+mod_ram = count_ram % period_size;
+mod_ram -= count_asp;
Is it perhaps saner to just look at the current position as being the
position of the transfer to SRAM? This does mean more variation from
the point at which data is audibly playing but on the other hand as far
as the CPU is concerned once the audio gets to SRAM it can't work with
it any longer so it's potentially misleading to report the SRAM
position. Not all hardware will be able to report the position at all
so userspace ought to be able to cope.
Hmm. Good point. I just wanted as accurate lip-sync as possible.
+iram_virt = sram_alloc(iram_size, iram_phys);
+if (!iram_virt)
+goto exit2;
Should this perhaps be configured via platform data? You've currently
picked 7 * 512 bytes but there appears to be no urgent reason for that
particular number and presumably SRAM is a limited resource which people
may want to prioritise differently. That may mean having bigger buffers
for audio as well as less - things like MP3 players can get better
battery life by setting up very big DMAs. On a similar vein is it worth
considering making this feature entirely optional and/or falling back to
non-SRAM if SRAM allocation fails?
Yes Chris Ring also asked for that, and it is fairly easy to allocate another
SDRAM buffer to use for the SRAM. But I'd rather another patch after this
if I need to use plaform data. Maybe audio_sram_buffer_size = 0 in platform
data to mean use SDRAM?
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
DM6446: LSP1.30 NAND Driver Bug
We are working with Monta Vista Linux with TI-Davinci platform. Previously we were using TI LSP release of 1.20 and now we have migrated to LSP 1.30. After migration to 1.30 we are facing issue of NAND bad block erase. From logs we can see almost all blocks are getting marked as bad blocks. Then I tried to trace code to figure out the issue. I found following changes… 1. Board-evm.c :- a. some members are added to nand data-structure and masks of cle and ale initialized here b. Cle mask changed to 0x08 from 0x0a which was macro in nand-davinci.c previous version(suspect of problem tried change of 0x0a but not working) c. Ecc mode changed to NAND_ECC_HW3_512 (but previous one also using 1-bit ecc only so may not be the problem) d. Instead of 1 there are 2 NAND resources (verified and may not be a problem) 2. Nand_davinci.c, nand_base.c :- a. Virtual address related access methods changed(may not be a problem). b. Code contains multiple chips support. (but it has been verified that correct base addresses are getting used) c. ECC modes added and hence num of ecc bytes getting changed. Considering above cases I tried to trace behavior of code and found that execution of this one is almost similar to previous one. But still call to following method in Create_bbt [nand_bbt.c] gives wrong buffer data. ret = mtd-read_oob(mtd, from + j * mtd-oobblock, mtd-oobsize, retlen, buf); Thus check_short_pattern (buf, bd) method fails to check it against 0xff and I get Bad Erase blocks error. Code function trace (as per our initialization of structures )is as follows… Nand_davinci_probe - nand_scan - nand_default_bbt - nand_scan_bbt(largepage_memorybased) - nand_memory_bbt - create_bbt If I boot through previous version on same board everything related to NAND works fine. So anybody here to have faced this problem... Omkar Yahoo! recommends that you upgrade to the new and safer Internet Explorer 8. http://downloads.yahoo.com/in/internetexplorer/___ 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 2/2] davinci: Add support for DA850/OMAP-L138 EVM board
On Tue, Jul 07, 2009 at 00:02:00, Kevin Hilman wrote:
Rajashekhara, Sudhakar sudhakar@ti.com writes:
On Wed, Jul 01, 2009 at 23:24:21, Kevin Hilman wrote:
Rajashekhara, Sudhakar sudhakar@ti.com writes:
This patch also fixes broken CONFIG_DEBUG_LL support on
DA830/OMAP-L137 EVM caused by my previous patch.
hmm...
diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h
b/arch/arm/mach-davinci/include/mach/uncompress.h
index 0f1f12b..28ea1f5 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h
@@ -21,7 +21,8 @@ static u32 *uart;
static u32 *get_uart_base(void)
{
-if (__machine_arch_type == MACH_TYPE_DAVINCI_DA8XX_EVM)
+if (__machine_arch_type == MACH_TYPE_DAVINCI_DA8XX_EVM ||
+__machine_arch_type == MACH_TYPE_DAVINCI_DA850_EVM)
return (u32 *)DA8XX_UART2_BASE;
else
return (u32 *)DAVINCI_UART0_BASE;
this looks still broken for da830 since ..._DA8XX_EVM machine doesn't
exist.
No, it's not broken. DA830 EVM has been registered as DAVINCI_DA8XX_EVM.
Please refer to arch/arm/tools/mach-types.
Then the machine type was registered incorrectly as that is clearly a
wrong (and confusing) name for that board.
Please fix the machine-name registration and send a mach-types patch
along with an updated version of this patch.
FYI, I did not register DA830 board. Now if I register the DA830 again,
u-boot will break because.
Can I submit a patch against mach-types file to Russell King, which
changes the the EVM name to ..._DA830_EVM from ..._DA8XX_EVM?
Regards, Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
