Re: [PATCH V2 1/2] mcx: very basic support for HTKW mcx board

2012-01-11 Thread Ilya Yanok
Hi Tony,

as you probably seen we've got an ACK from Grant Likely for the
mt_ventoux DT-only support patch (which is really the same as this one,
only board name/vendor changed). Probably you can now merge support for
both boards?

Regards, Ilya.

On 17.12.2011 05:37, Tony Lindgren wrote:
> * Ilya Yanok  [111214 16:21]:
>> Very basic support for HTKW mcx board. Able to boot via board-generic
>> and ramdisk/initramfs, however most of peripherals is unsupported.
>> Produces tons of twl4030 related errors as this board doesn't have
>> twl4030 installed.
> 
> Please resend with linux-arm-kernel and devicetree-discuss
> lists in Cc. We need an ack from the devicetree people for this.
> 
> Tony

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2] OMAP3: hwmod_data: register dss hwmods after dss_core

2012-01-11 Thread Ilya Yanok
Hi Archit.

On 30.12.2011 14:02, Archit Taneja wrote:
> This looks fine, but it should be needed for other OMAP2 and OMAP4 also.
> If you could extend the patch we could test it out for the other OMAPs.

OMAP2 and OMAP4 don't need this as they have single hwmod list, so
correct ordering can be handled just by ordering list items.

Regards, Ilya.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] mt_ventoux: support for TeeJet Mt.Ventoux board

2012-01-11 Thread Ilya Yanok
Hi Igor,

On 03.01.2012 13:48, Igor Grinberg wrote:
>> I will forward this info to hardware guys and ask about wiring. For now
>> I will leave it as is. Thanks for this information it turned to be some
>> kind of mystery. It would be great if you could give some pointer to the
>> datasheet regarding VDDSHV and DSS.
> 
> Well, there is no direct pointer to that information, but
> I've found these facts:
> 1) the "Ball Characteristics" tables state that the DSS related pins
>(and also many others) are powered by the VDDSHV.
> 2) the estimated power consumption of VDDSHV is the largest after the
>VDD_CORE, which is typical for DSS, but it is also one of the largest
>power domains, so I guess this cannot be a valid argument ;-)
> 3) On the "Voltage domains" diagram, only the VDD_CORE is exposed and
>DSS is not listed in it, but there are other domains which are not
>exposed... (this only can exclude the DSS from VDD_CORE, but not
>absolutely, as datasheets can have mistakes or just not give that piece
>of information).
> 
> Still, it is a guess and not verified information.

Yes, I understand. Thanks for sharing you thoughts!

Regards, Ilya.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] OMAP3: don't init PM on AM35{05,17}

2012-01-11 Thread Ilya Yanok
Hi Kevin,

On 04.01.2012 03:37, Kevin Hilman wrote:
>> Current OMAP3 PM code seems to be incompatible with AM35{05,17} and
>> leads to system hang during boot.
>> Disable PM init on AM35{05,17} until working implementation will be
>> merged.
> 
> Were you able to find out where exactly things got hung up?

Well, actually there were two manifestations of this problem:
 1. Output on the serial console is slow. I'm working with the board
remotely so it really looked like slow internet connection but I've
verified it and found that the problem is certainly on the board side. I
can't say if it's the whole system running so slow or only serial
console cause I haven't managed to boot it.
 2. At some point cpu_idle() is called, execution goes to SRAM and never
comes back...

Regards, Ilya.

> We're trying hard to avoid adding more cpu_is_* checks so would like to
> better understand the problem before merging such a fix.
> 
> Thanks,
> 
> Kevin
> 
>> Signed-off-by: Ilya Yanok 
>> ---
>> This patch solves the problem for me but I'm curious why simple
>> CONFIG_PM disabling doesn't work? I'm getting
>> Unhandled fault: external abort on non-linefetch
>> while trying to access absolutely valid register from omapdss/venc
>> driver. I've tried to disable VENC but then I got the same error
>> from omap_wdt driver. Is it supposed to be so? Are !CONFIG_PM
>> configurations supported? How comes that disabling CONFIG_PM
>> makes some registers inaccessible?
>>
>> Regards, Ilya.
>>
>>  arch/arm/mach-omap2/pm34xx.c |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
>> index fc69875..0f30742 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -790,7 +790,7 @@ static int __init omap3_pm_init(void)
>>  struct clockdomain *neon_clkdm, *per_clkdm, *mpu_clkdm, *core_clkdm;
>>  int ret;
>>  
>> -if (!cpu_is_omap34xx())
>> +if (!cpu_is_omap34xx() || cpu_is_omap3505() || cpu_is_omap3517())
>>  return -ENODEV;
>>  
>>  if (!omap3_has_io_chain_ctrl())

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH V2] OMAP3: hwmod_data: register dss hwmods after dss_core

2011-12-28 Thread Ilya Yanok
dss_core has to be initialized before any other DSS hwmod. Currently
this is broken as dss_core is listed in chip/revision specific hwmod
lists while other DSS hwmods are listed in common list which is
registered first.

This patch moves DSS hwmods (except for dss_core) to the separate list
which is registered last to ensure that dss_core is already registered.

This solves the problem with BUG() in L3 interrupt handler on boards
with DSS enabled in bootloader.

CC: Tomi Valkeinen 
CC: Archit Taneja 
CC: Paul Walmsley 
Signed-off-by: Ilya Yanok 
---

Changes from V1:
 - Added extended comment

 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   28 ++--
 1 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 5324e8d..f263d3c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3523,12 +3523,6 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = 
{
&omap3xxx_uart2_hwmod,
&omap3xxx_uart3_hwmod,
 
-   /* dss class */
-   &omap3xxx_dss_dispc_hwmod,
-   &omap3xxx_dss_dsi1_hwmod,
-   &omap3xxx_dss_rfbi_hwmod,
-   &omap3xxx_dss_venc_hwmod,
-
/* i2c class */
&omap3xxx_i2c1_hwmod,
&omap3xxx_i2c2_hwmod,
@@ -3635,6 +3629,15 @@ static __initdata struct omap_hwmod *am35xx_hwmods[] = {
NULL
 };
 
+static __initdata struct omap_hwmod *omap3xxx_dss_hwmods[] = {
+   /* dss class */
+   &omap3xxx_dss_dispc_hwmod,
+   &omap3xxx_dss_dsi1_hwmod,
+   &omap3xxx_dss_rfbi_hwmod,
+   &omap3xxx_dss_venc_hwmod,
+   NULL
+};
+
 int __init omap3xxx_hwmod_init(void)
 {
int r;
@@ -3708,6 +3711,19 @@ int __init omap3xxx_hwmod_init(void)
 
if (h)
r = omap_hwmod_register(h);
+   if (r < 0)
+   return r;
+
+   /*
+* DSS code presumes that dss_core hwmod is handled first,
+* _before_ any other DSS related hwmods so register common
+* DSS hwmods last to ensure that dss_core is already registered.
+* Otherwise some change things may happen, for ex. if dispc
+* is handled before dss_core and DSS is enabled in bootloader
+* DIPSC will be reset with outputs enabled which sometimes leads
+* to unrecoverable L3 error.
+*/
+   r = omap_hwmod_register(omap3xxx_dss_hwmods);
 
return r;
 }
-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH V2] mt_ventoux: support for TeeJet Mt.Ventoux board

2011-12-27 Thread Ilya Yanok
This patch adds support for TeeJet Mt.Ventoux board based on TAM3517
SOM. Supported devices:
 - Serial
 - Ethernet
 - NAND
 - USB host
 - LCD
 - Touchscreen
 - CAN controller
 - ADC128S converter

Signed-off-by: Ilya Yanok 
---

Changes from V1:

 - Fixed indentation (use tabs not spaces)
 - Fixed over 80 characters lines
 - Added #if defined(CONFIG_SENSORS_ADCXX_MODULE) to allow adcxx to be a
   module.
 - Fixes for compilation with CONFIG_TOUCHSCREEN_ADS7846!=y
  - Added defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE)
  - Moved call to omap_ads7846_init to separate small function
  - Register fixed regulator used for touchscreen only if the driver is
enabled
 - Changed board name (MT_VENTOUX -> Mt.Ventoux)

 arch/arm/mach-omap2/Kconfig   |6 +
 arch/arm/mach-omap2/Makefile  |1 +
 arch/arm/mach-omap2/board-am3517_mt_ventoux.c |  724 +
 arch/arm/plat-omap/include/plat/uncompress.h  |1 +
 4 files changed, 732 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-am3517_mt_ventoux.c

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index fd9b8c0..45f5dcb 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -237,6 +237,12 @@ config MACH_MCX
select OMAP_PACKAGE_CBB
select REGULATOR_FIXED_VOLTAGE
 
+config MACH_AM3517_MT_VENTOUX
+   bool "TeeJet MT_VENTOUX (TAM3517 based) board"
+   depends on ARCH_OMAP3
+   select OMAP_PACKAGE_CBB
+   select REGULATOR_FIXED_VOLTAGE
+
 config MACH_NOKIA_N800
bool
 
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 9405dfc..cbc3a36 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -239,6 +239,7 @@ obj-$(CONFIG_MACH_SBC3530)  += board-omap3stalker.o
 obj-$(CONFIG_MACH_TI8168EVM)   += board-ti8168evm.o
 obj-$(CONFIG_MACH_TI8148EVM)   += board-ti8168evm.o
 obj-$(CONFIG_MACH_MCX) += board-mcx.o
+obj-$(CONFIG_MACH_AM3517_MT_VENTOUX)   += board-am3517_mt_ventoux.o
 
 # Platform specific device init code
 
diff --git a/arch/arm/mach-omap2/board-am3517_mt_ventoux.c 
b/arch/arm/mach-omap2/board-am3517_mt_ventoux.c
new file mode 100644
index 000..4b6bd33
--- /dev/null
+++ b/arch/arm/mach-omap2/board-am3517_mt_ventoux.c
@@ -0,0 +1,724 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, Emcraft Systems
+ *
+ * Modified from mach-omap2/board-mcx.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "am35xx-emac.h"
+#include "mux.h"
+#include "control.h"
+#include "hsmmc.h"
+#include "common-board-devices.h"
+#include "common.h"
+
+/* FPGA */
+static struct platdata_mtd_ram mt_ventoux_fpga_data = {
+   .bankwidth = 2,
+};
+
+#define FPGA_BASE_ADDR 0x2000
+static struct resource mt_ventoux_fpga_resource = {
+   .start = FPGA_BASE_ADDR,
+   .end   = FPGA_BASE_ADDR + SZ_128M - 1,
+   .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device mt_ventoux_fpga_device = {
+   .name = "mtd-ram",
+   .id = 0,
+   .dev = {
+   .platform_data = &mt_ventoux_fpga_data,
+   },
+   .num_resources = 1,
+   .resource = &mt_ventoux_fpga_resource,
+};
+
+#define MCX_MDIO_FREQUENCY (100)
+
+static struct mtd_partition mt_ventoux_nand_partitions[] = {
+   /* All the partition sizes are listed in terms of NAND block size */
+   {
+   .name   = "X-Loader",
+   .offset = 0,
+   .size   = 4 * NAND_BLOCK_SIZE,
+   .mask_flags = MTD_WRITEABLE,/* force read-only */
+   },
+   {
+   .name   = "U-Boot",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x8 */
+   .size   = 15 * NAND_BLOCK_SIZE,
+   .mask_flags = MTD_WRITEABLE,/* force read-only */
+   },
+   {
+   .name   = "U-Boot Env",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x26 */
+   .size   = 1 * NAND_BLOCK_SIZE,
+   },
+   {
+   .name   = "Kernel",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x28 */
+   .size   = 32 * NAND_BLOCK_SIZE,
+   },
+   {
+   .name   = "File System",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x68 */
+   

Re: [PATCH 2/2] mt_ventoux: support for TeeJet Mt.Ventoux board

2011-12-27 Thread Ilya Yanok
Hi Igor,

thanks for your comments.

On 27.12.2011 11:56, Igor Grinberg wrote:
>> +/*
>> + * use fake regulator for vdds_dsi as we can't find this pin inside
>> + * AM3517 datasheet.
>> + */
>> +static struct regulator_consumer_supply mt_ventoux_vdds_dsi_supply[] = {
>> +REGULATOR_SUPPLY("vdds_dsi", "omapdss"),
>> +REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"),
>> +};
> 
> Although the TRM states that there is a vdds_dsi signal,
> it looks, from the datasheet, that VDDSHV is used to power the DSS.
> Either way, it can't be switched off, I think...
> Therefore, depending on your board wiring, you can leave it as fixed
> regulator or bind to a supply on TPS65023.

I will forward this info to hardware guys and ask about wiring. For now
I will leave it as is. Thanks for this information it turned to be some
kind of mystery. It would be great if you could give some pointer to the
datasheet regarding VDDSHV and DSS.

>> +static struct i2c_board_info __initdata mt_ventoux_i2c1_devices[] = {
>> +{
>> +I2C_BOARD_INFO("tps65023", 0x48),
>> +.flags = I2C_CLIENT_WAKE,
>> +.platform_data = &mt_ventoux_regulator_data[0],
>> +},
>> +{
>> +I2C_BOARD_INFO("24c02", 0x50),
>> +},
>> +};
> 
> Here (and may be in some other places) you have spaces for
> indentation. Can it be tabs instead for uniformity (and file size)?

Argh.. Surely. I should have noticed this myself.

>> +#if defined(CONFIG_TOUCHSCREEN_ADS7846)
> 
> Can't the ADS7846 be module?

Surely. Fixed.

>> +static struct ads7846_platform_data tsc2046_config __initdata = {
>> +.x_max  = 0x0fff,
>> +.y_max  = 0x0fff,
>> +.x_plate_ohms   = 180,
>> +.pressure_max   = 255,
>> +.debounce_max   = 30,
>> +.debounce_tol   = 10,
>> +.debounce_rep   = 1,
>> +.keep_vref_on   = 1,
>> +.settle_delay_usecs = 100,
>> +};
>> +#endif
> 
> [...]
> 
>> +static void __init mt_ventoux_init(void)
>> +{
>> +omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
>> +mt_ventoux_i2c_init();
>> +platform_add_devices(mt_ventoux_devices, 
>> ARRAY_SIZE(mt_ventoux_devices));
>> +mt_ventoux_serial_init();
>> +omap_sdrc_init(NULL, NULL);
>> +
>> +mt_ventoux_display_init();
>> +
>> +/* Configure EHCI ports */
>> +omap_mux_init_gpio(USB_PHY1_RESET, OMAP_PIN_OUTPUT);
>> +usbhs_init(&usbhs_bdata);
>> +
>> +/* NAND */
>> +omap_nand_flash_init(NAND_BUSWIDTH_16, mt_ventoux_nand_partitions,
>> + ARRAY_SIZE(mt_ventoux_nand_partitions));
>> +
>> +/* touchscreen */
>> +omap_mux_init_gpio(TS_IRQ_PIN, OMAP_PIN_INPUT);
>> +omap_ads7846_init(1, TS_IRQ_PIN, 310, &tsc2046_config);
> 
> Here you call omap_ads7846_init() irregardless to
> CONFIG_TOUCHSCREEN_ADS7846, but the tsc2046_config is defined only
> if it is enabled...
> I think, either remove the #ifdef CONFIG_TOUCHSCREEN_ADS7846
> or move the above to a separate function like
> mt_ventoux_touch_init() and provide a static inline version of it
> in case the CONFIG_TOUCHSCREEN_ADS7846 is not enabled (just like you
> did for adc128s_init()).
> Otherwise, various rand_configs will fail...

Agreed. Fixed.

>> +/* Ethernet */
>> +am35xx_ethernet_init(MCX_MDIO_FREQUENCY, 1);
>> +
>> +/* MMC init */
>> +omap_mux_init_gpio(SD_CARD_CD, OMAP_PIN_INPUT);
>> +omap2_hsmmc_init(mmc);
>> +
>> +/* ADC128S022 init */
>> +adc128s_init();
> 
> I think you are missing the __init annotation in the adc128s_init()
> function definition (just noticed after snipping).

Well, it's declared as inline so I think there is no much use for the
__init annotation...

Regards, Ilya.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/2] mt_ventoux: support for TeeJet Mt.Ventoux board

2011-12-26 Thread Ilya Yanok
This patch adds support for TeeJet Mt.Ventoux board based on TAM3517
SOM. Supported devices:
 - Serial
 - Ethernet
 - NAND
 - USB host
 - LCD
 - Touchscreen
 - CAN controller
 - ADC128S converter

Signed-off-by: Ilya Yanok 
---
Requires updated machine-type file, recently posted AM35xx-EMAC patch
and "Disable PM init on AM35{05,17} patch.

 arch/arm/mach-omap2/Kconfig   |6 +
 arch/arm/mach-omap2/Makefile  |1 +
 arch/arm/mach-omap2/board-am3517_mt_ventoux.c |  708 +
 arch/arm/plat-omap/include/plat/uncompress.h  |1 +
 4 files changed, 716 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-am3517_mt_ventoux.c

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index fd9b8c0..45f5dcb 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -237,6 +237,12 @@ config MACH_MCX
select OMAP_PACKAGE_CBB
select REGULATOR_FIXED_VOLTAGE
 
+config MACH_AM3517_MT_VENTOUX
+   bool "TeeJet MT_VENTOUX (TAM3517 based) board"
+   depends on ARCH_OMAP3
+   select OMAP_PACKAGE_CBB
+   select REGULATOR_FIXED_VOLTAGE
+
 config MACH_NOKIA_N800
bool
 
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 9405dfc..cbc3a36 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -239,6 +239,7 @@ obj-$(CONFIG_MACH_SBC3530)  += board-omap3stalker.o
 obj-$(CONFIG_MACH_TI8168EVM)   += board-ti8168evm.o
 obj-$(CONFIG_MACH_TI8148EVM)   += board-ti8168evm.o
 obj-$(CONFIG_MACH_MCX) += board-mcx.o
+obj-$(CONFIG_MACH_AM3517_MT_VENTOUX)   += board-am3517_mt_ventoux.o
 
 # Platform specific device init code
 
diff --git a/arch/arm/mach-omap2/board-am3517_mt_ventoux.c 
b/arch/arm/mach-omap2/board-am3517_mt_ventoux.c
new file mode 100644
index 000..d4501d9
--- /dev/null
+++ b/arch/arm/mach-omap2/board-am3517_mt_ventoux.c
@@ -0,0 +1,708 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, Emcraft Systems
+ *
+ * Modified from mach-omap2/board-mcx.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "am35xx-emac.h"
+#include "mux.h"
+#include "control.h"
+#include "hsmmc.h"
+#include "common-board-devices.h"
+#include "common.h"
+
+/* FPGA */
+static struct platdata_mtd_ram mt_ventoux_fpga_data = {
+   .bankwidth = 2,
+};
+
+#define FPGA_BASE_ADDR 0x2000
+static struct resource mt_ventoux_fpga_resource = {
+   .start = FPGA_BASE_ADDR,
+   .end   = FPGA_BASE_ADDR + SZ_128M - 1,
+   .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device mt_ventoux_fpga_device = {
+   .name = "mtd-ram",
+   .id = 0,
+   .dev = {
+   .platform_data = &mt_ventoux_fpga_data,
+   },
+   .num_resources = 1,
+   .resource = &mt_ventoux_fpga_resource,
+};
+
+#define MCX_MDIO_FREQUENCY (100)
+
+static struct mtd_partition mt_ventoux_nand_partitions[] = {
+   /* All the partition sizes are listed in terms of NAND block size */
+   {
+   .name   = "X-Loader",
+   .offset = 0,
+   .size   = 4 * NAND_BLOCK_SIZE,
+   .mask_flags = MTD_WRITEABLE,/* force read-only */
+   },
+   {
+   .name   = "U-Boot",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x8 */
+   .size   = 15 * NAND_BLOCK_SIZE,
+   .mask_flags = MTD_WRITEABLE,/* force read-only */
+   },
+   {
+   .name   = "U-Boot Env",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x26 */
+   .size   = 1 * NAND_BLOCK_SIZE,
+   },
+   {
+   .name   = "Kernel",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x28 */
+   .size   = 32 * NAND_BLOCK_SIZE,
+   },
+   {
+   .name   = "File System",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x68 */
+   .size   = MTDPART_SIZ_FULL,
+   },
+};
+
+#define PANEL_PWR_PIN  138
+#define LCD_PANEL_PON_PIN  139
+#define DVI_PON_PIN24
+
+static int lcd_enabled;
+static int dvi_enabled;
+
+static int mt_ventoux_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+   if (dvi_enabled) {
+   pr_err("cannot enable LCD, D

[PATCH 0/2] Support for TeeJet Mt.Ventoux

2011-12-26 Thread Ilya Yanok
Split into two parts:
 1. Device tree only to be used with board-generic (only serial works)
 2. Full board support via custom machine file for board-testing

Ilya Yanok (2):
  mt_ventoux: very basic support for TeeJet Mt.Ventoux board
  mt_ventoux: support for TeeJet Mt.Ventoux board

 arch/arm/boot/dts/am3517_mt_ventoux.dts   |   27 +
 arch/arm/mach-omap2/Kconfig   |6 +
 arch/arm/mach-omap2/Makefile  |1 +
 arch/arm/mach-omap2/board-am3517_mt_ventoux.c |  708 +
 arch/arm/plat-omap/include/plat/uncompress.h  |1 +
 5 files changed, 743 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/am3517_mt_ventoux.dts
 create mode 100644 arch/arm/mach-omap2/board-am3517_mt_ventoux.c

-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/2] mt_ventoux: very basic support for TeeJet Mt.Ventoux board

2011-12-26 Thread Ilya Yanok
Very basic support for TeeJet Mt.Ventoux board. Able to boot via
board-generic and ramdisk/initramfs, however most of peripherals are
not supported. Produces tons of twl4030 related errors as this board
doesn't have twl4030 installed.

Signed-off-by: Ilya Yanok 
---
 arch/arm/boot/dts/am3517_mt_ventoux.dts |   27 +++
 1 files changed, 27 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/am3517_mt_ventoux.dts

diff --git a/arch/arm/boot/dts/am3517_mt_ventoux.dts 
b/arch/arm/boot/dts/am3517_mt_ventoux.dts
new file mode 100644
index 000..5eb26d7
--- /dev/null
+++ b/arch/arm/boot/dts/am3517_mt_ventoux.dts
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, EmCraft Systems
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ "omap3.dtsi"
+
+/ {
+   model = "TeeJet Mt.Ventoux";
+   compatible = "teejet,mt_ventoux", "ti,omap3";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x1000>; /* 256 MB */
+   };
+
+   /* AM35xx doesn't have IVA */
+   soc {
+   iva {
+   status = "disabled";
+   };
+   };
+};
-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] OMAPDSS: add OrtusTech COM43H4M10XTC display support

2011-12-26 Thread Ilya Yanok
dd data for the OrtusTech COM43H4M10XTC display to the
generic_dpi_panel driver.

CC: Tomi Valkeinen 
Signed-off-by: Ilya Yanok 
---
 drivers/video/omap2/displays/panel-generic-dpi.c |   20 
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c 
b/drivers/video/omap2/displays/panel-generic-dpi.c
index 593f831..99669ae 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -317,6 +317,26 @@ static struct panel_config generic_dpi_panels[] = {
  OMAP_DSS_LCD_IHS,
.name   = "focaltech_etm070003dh6",
},
+   /* OrtusTech COM43H4M10XTC */
+   {
+   {
+   .x_res  = 480,
+   .y_res  = 272,
+
+   .pixel_clock= 8000,
+
+   .hsw= 41,
+   .hfp= 8,
+   .hbp= 4,
+
+   .vsw= 10,
+   .vfp= 4,
+   .vbp= 2,
+   },
+   .config = OMAP_DSS_LCD_TFT,
+
+   .name   = "ortustech_com43h4m10xtc",
+   },
 };
 
 struct panel_drv_data {
-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] OMAP3: hwmod_data: register dss hwmods after dss_core

2011-12-22 Thread Ilya Yanok
dss_core has to be initialized before any other DSS hwmod. Currently
this is broken as dss_core is listed in chip/revision specific hwmod
lists while other DSS hwmods are listed in common list which is
registered first.

This patch moves DSS hwmods (except for dss_core) to the separate list
which is registered last to ensure that dss_core is already registered.

CC: Tomi Valkeinen 
CC: Archit Taneja 
CC: Paul Walmsley 
Signed-off-by: Ilya Yanok 
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   20 ++--
 1 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 5324e8d..85536ff 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3523,12 +3523,6 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = 
{
&omap3xxx_uart2_hwmod,
&omap3xxx_uart3_hwmod,
 
-   /* dss class */
-   &omap3xxx_dss_dispc_hwmod,
-   &omap3xxx_dss_dsi1_hwmod,
-   &omap3xxx_dss_rfbi_hwmod,
-   &omap3xxx_dss_venc_hwmod,
-
/* i2c class */
&omap3xxx_i2c1_hwmod,
&omap3xxx_i2c2_hwmod,
@@ -3635,6 +3629,15 @@ static __initdata struct omap_hwmod *am35xx_hwmods[] = {
NULL
 };
 
+static __initdata struct omap_hwmod *omap3xxx_dss_hwmods[] = {
+   /* dss class */
+   &omap3xxx_dss_dispc_hwmod,
+   &omap3xxx_dss_dsi1_hwmod,
+   &omap3xxx_dss_rfbi_hwmod,
+   &omap3xxx_dss_venc_hwmod,
+   NULL
+};
+
 int __init omap3xxx_hwmod_init(void)
 {
int r;
@@ -3708,6 +3711,11 @@ int __init omap3xxx_hwmod_init(void)
 
if (h)
r = omap_hwmod_register(h);
+   if (r < 0)
+   return r;
+
+   /* Register common DSS hwmods later than dss_core */
+   r = omap_hwmod_register(omap3xxx_dss_hwmods);
 
return r;
 }
-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH V2] OMAP2+: ads7846_init: put gpio_pendown into pdata if it's provided

2011-12-22 Thread Ilya Yanok
If platform data is provided by the caller gpio_pendown is put into
unused static ads7846_config structure and effectively has no effect.
Of course caller can set gpio_pendown field in platform data himself
but it seems natural to do this in ads7846_init to remove duplication.

Signed-off-by: Igor Grinberg 
Signed-off-by: Ilya Yanok 

---
Changes from V1:

 - existing if clause reused

 arch/arm/mach-omap2/common-board-devices.c |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/common-board-devices.c 
b/arch/arm/mach-omap2/common-board-devices.c
index 2d1d775..9498b0f 100644
--- a/arch/arm/mach-omap2/common-board-devices.c
+++ b/arch/arm/mach-omap2/common-board-devices.c
@@ -75,13 +75,15 @@ void __init omap_ads7846_init(int bus_num, int 
gpio_pendown, int gpio_debounce,
gpio_set_debounce(gpio_pendown, gpio_debounce);
}
 
-   ads7846_config.gpio_pendown = gpio_pendown;
-
spi_bi->bus_num = bus_num;
spi_bi->irq = OMAP_GPIO_IRQ(gpio_pendown);
 
-   if (board_pdata)
+   if (board_pdata) {
+   board_pdata->gpio_pendown = gpio_pendown;
spi_bi->platform_data = board_pdata;
+   } else {
+   ads7846_config.gpio_pendown = gpio_pendown;
+   }
 
spi_register_board_info(&ads7846_spi_board_info, 1);
 }
-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] OMAP3: hwmod_data: add HWMOD_INIT_NO_RESET flag for dss_dispc

2011-12-22 Thread Ilya Yanok
Hi Tomi,

On 22.12.2011 14:13, Tomi Valkeinen wrote:
> On Thu, 2011-12-22 at 02:00 +0100, Ilya Yanok wrote:
>> Resetting DISPC when a DISPC output is enabled causes the DSS to go into
>> an inconsistent state.
>>
>> commit b923d40dd4211c4ef7d4efa2bd81b7ca1d8744c1
>> Author: Archit Taneja 
>> Date:   Thu Oct 6 18:04:08 2011 -0600
>>
>> ARM: OMAP2PLUS: DSS: Ensure DSS works correctly if display is
>> enabled in bootloader
>>
>> tries to deal with this problem by checking if display is enabled and
>> disabling it before doing reset.
>>
>> But in my setup dss_dispc is resetted from omap_hwmod_setup_all function
>> _before_ calling omap_dss_reset. So when dispc_disable_outputs is
>> executed dispc is already reset and nothing happens.
> 
> Hmm, why is that? You don't have the dss hwmod before dispc in the list
> of hwmods? The code presumes that dss hwmod is handled first.

Looking at the arch/arm/mach-omap2/omap_hwmod_3xxx_data.c I can see that
dss_dispc is in the list of generic hwmods which is registered first
while dss_core hwmod is in revision-specific lists which are registered
later. I think this is the real root of the problem, thanks for pointing
this out!

> 
>> This patch and HWMOD_INIT_NO_RESET flags to dss_dispc hwmod thus leaving
>> DISPC untouched so that omap_dss_reset can take care of it.
> 
> omap_dss_reset() doesn't reset dispc, so this will leave dispc
> un-reseted.
> 
> The idea of the current code is to do the reset similarly on all OMAPs.
> The sequence should be:
> 
> - omap_dss_reset(), which disables dispc outputs and manually resets dss
> registers.
> - then the rest of the dss modules reset themselves normally, using the
> softreset bit.

But currently omap_dss_reset() is called the last.

Regards, Ilya.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Interesting L3 driver panic on v3.2-rc5 on 3530

2011-12-21 Thread Ilya Yanok
Hi Archit, Paul,

On 20.12.2011 16:23, Archit Taneja wrote:
> There was a patch which got into the kernel in 3.2-rc4:
> 
> b923d40dd4211c4ef7d4efa2bd81b7ca1d8744c1
> ARM: OMAP2PLUS: DSS: Ensure DSS works correctly if display is enabled in
> bootloader
> 
> This tries to disable any display outputs if enabled in bootloader. If
> this issue didn't happen before, we might want to look into this code.
> 
> Could you share what debug prints you get from the function
> omap_dss_reset() (its in arch/arm/mach-omap2/display.c)

In my case the bottom part of dispc_disable_outputs() is never executed
as dss_dispc is reset but omap_hwmod_setup_all function and when
dispc_disable_outputs is executed it sees that the display is disabled
already.

I've just posted a patch to fix this.

Regards, Ilya.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] OMAP3: hwmod_data: add HWMOD_INIT_NO_RESET flag for dss_dispc

2011-12-21 Thread Ilya Yanok
Resetting DISPC when a DISPC output is enabled causes the DSS to go into
an inconsistent state.

commit b923d40dd4211c4ef7d4efa2bd81b7ca1d8744c1
Author: Archit Taneja 
Date:   Thu Oct 6 18:04:08 2011 -0600

ARM: OMAP2PLUS: DSS: Ensure DSS works correctly if display is
enabled in bootloader

tries to deal with this problem by checking if display is enabled and
disabling it before doing reset.

But in my setup dss_dispc is resetted from omap_hwmod_setup_all function
_before_ calling omap_dss_reset. So when dispc_disable_outputs is
executed dispc is already reset and nothing happens.

This patch and HWMOD_INIT_NO_RESET flags to dss_dispc hwmod thus leaving
DISPC untouched so that omap_dss_reset can take care of it.

This solves the l3_app_irq BUG problem on my AM3517 based board.

CC: Archit Taneja 
CC: Paul Walmsley 
Signed-off-by: Ilya Yanok 
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 5324e8d..226b365 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1515,7 +1515,7 @@ static struct omap_hwmod omap3xxx_dss_dispc_hwmod = {
},
.slaves = omap3xxx_dss_dispc_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_dss_dispc_slaves),
-   .flags  = HWMOD_NO_IDLEST,
+   .flags  = HWMOD_NO_IDLEST | HWMOD_INIT_NO_RESET,
.dev_attr   = &omap2_3_dss_dispc_dev_attr
 };
 
-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] OMAP2+: ads7846_init: put gpio_pendown into pdata if it's provided

2011-12-21 Thread Ilya Yanok
Hi Igor,

On 21.12.2011 21:22, Igor Grinberg wrote:
> Please, Cc the linux-arm-ker...@lists.infradead.org for patches,
> so Tony, or whoever will not need to resend them...

Uh.. Actually I thought that linux-omap ML is a good place for really
OMAP-specific patches like this one and there is no much sense posting
such patches into the main ARM list...

Ok, I will Cc linux-arm-kernel in future.

>> If platform data is provided by the caller gpio_pendown is put into
>> unused static ads7846_config structure and effectively has no effect.
>> Of course caller can set gpio_pendown field in platform data himself
>> but it seems natural to do this in ads7846_init to remove duplication.
>>
>> Signed-off-by: Ilya Yanok 
>> ---
>>  arch/arm/mach-omap2/common-board-devices.c |5 -
>>  1 files changed, 4 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/common-board-devices.c 
>> b/arch/arm/mach-omap2/common-board-devices.c
>> index 2d1d775..eb408dd 100644
>> --- a/arch/arm/mach-omap2/common-board-devices.c
>> +++ b/arch/arm/mach-omap2/common-board-devices.c
>> @@ -75,7 +75,10 @@ void __init omap_ads7846_init(int bus_num, int 
>> gpio_pendown, int gpio_debounce,
>>  gpio_set_debounce(gpio_pendown, gpio_debounce);
>>  }
>>  
>> -ads7846_config.gpio_pendown = gpio_pendown;
>> +if (!board_pdata)
>> +ads7846_config.gpio_pendown = gpio_pendown;
>> +else
>> +board_pdata->gpio_pendown = gpio_pendown;
>>  
>>  spi_bi->bus_num = bus_num;
>>  spi_bi->irq = OMAP_GPIO_IRQ(gpio_pendown);
> 
> The fact that the ads7846_config has no effect in case
> the board_pdata is provided does not really meter...
> How about reusing the existing "if" instead of adding another one?
> Like in the attached patch?

Yes, I think your version is a bit clearer. Probably it makes to add
"else" clause and move ads7846_config.gpio_pendown assignment under it.

Regards, Ilya.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] OMAP2+: ads7846_init: put gpio_pendown into pdata if it's provided

2011-12-21 Thread Ilya Yanok
If platform data is provided by the caller gpio_pendown is put into
unused static ads7846_config structure and effectively has no effect.
Of course caller can set gpio_pendown field in platform data himself
but it seems natural to do this in ads7846_init to remove duplication.

Signed-off-by: Ilya Yanok 
---
 arch/arm/mach-omap2/common-board-devices.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/common-board-devices.c 
b/arch/arm/mach-omap2/common-board-devices.c
index 2d1d775..eb408dd 100644
--- a/arch/arm/mach-omap2/common-board-devices.c
+++ b/arch/arm/mach-omap2/common-board-devices.c
@@ -75,7 +75,10 @@ void __init omap_ads7846_init(int bus_num, int gpio_pendown, 
int gpio_debounce,
gpio_set_debounce(gpio_pendown, gpio_debounce);
}
 
-   ads7846_config.gpio_pendown = gpio_pendown;
+   if (!board_pdata)
+   ads7846_config.gpio_pendown = gpio_pendown;
+   else
+   board_pdata->gpio_pendown = gpio_pendown;
 
spi_bi->bus_num = bus_num;
spi_bi->irq = OMAP_GPIO_IRQ(gpio_pendown);
-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH V3 1/2] mcx: very basic support for HTKW mcx board

2011-12-21 Thread Ilya Yanok
Very basic support for HTKW mcx board. Able to boot via board-generic
and ramdisk/initramfs, however most of peripherals is unsupported.
Produces tons of twl4030 related errors as this board doesn't have
twl4030 installed.

Signed-off-by: Ilya Yanok 

---
Changes from V2:

 - None

Changes from V1:

 - device tree move to the separate patch
 - iva node is disabled instead of using custom includes
 - removed bootargs entry

 arch/arm/boot/dts/mcx.dts |   27 +++
 1 files changed, 27 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/mcx.dts

diff --git a/arch/arm/boot/dts/mcx.dts b/arch/arm/boot/dts/mcx.dts
new file mode 100644
index 000..66b81bd
--- /dev/null
+++ b/arch/arm/boot/dts/mcx.dts
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, EmCraft Systems
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ "omap3.dtsi"
+
+/ {
+   model = "HTKW mcx";
+   compatible = "htkw,mcx", "ti,omap3";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x1000>; /* 256 MB */
+   };
+
+   /* AM35xx doesn't have IVA */
+   soc {
+   iva {
+   status = "disabled";
+   };
+   };
+};
-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH V3 2/2] mcx: support for HTKW mcx board

2011-12-21 Thread Ilya Yanok
Support for the HTKW mcx board (TI AM3517 based) including serial,
Ethernet, I2C, USB host, HSMMC, DSS and RTC.

Signed-off-by: Ilya Yanok 

---
Requires updated machine-type file, recently posted AM35xx-EMAC patch
and "Disable PM init on AM35{05,17} patch.

Changes from V2:
 - Rebased onto the current linux-omap/master
  - Added "common.h" include
  - Added .handle_irq field to machine description
  - Added omap_sdrc_init() call
 - Removed unneeded pullup from output pins
 - Moved pin muxing before GPIO accesses
 - Removed .ocr_mask field (it's overwritten anyway)
 - Moved touchscreen init out of I2C init
 - some readability improvements (empty lines, comments)

Changes from V1:
 - Kconfig option name fixed
 - Makefile entry sanitized
 - Unneeded headers removed
 - EMAC initialization moved to separate file/patch
 - Use gpio_{request,free}_{array,one} where possible
 - don't use platform data for touchscreen, we only need to pass
   irq number, do it via client.irq
 - check mcx_ts_init return value
 - Moved DEBUG_LL_OMAP3 entry to be in aplhabetical order
 - check return value of gpio_request for USB pwr pin
 - use pr_err instead of printk for error printing
 - added a fixed regulator for vdds_dsi
 - added SDcard card-detect pin

 arch/arm/mach-omap2/Kconfig  |6 +
 arch/arm/mach-omap2/Makefile |1 +
 arch/arm/mach-omap2/board-mcx.c  |  500 ++
 arch/arm/plat-omap/include/plat/uncompress.h |1 +
 4 files changed, 508 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-mcx.c

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 0eb27b2..fd9b8c0 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -231,6 +231,12 @@ config MACH_OMAP_3430SDP
default y
select OMAP_PACKAGE_CBB
 
+config MACH_MCX
+   bool "HTKW mcx (AM3517 based) board"
+   depends on ARCH_OMAP3
+   select OMAP_PACKAGE_CBB
+   select REGULATOR_FIXED_VOLTAGE
+
 config MACH_NOKIA_N800
bool
 
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 5d75cb5..9405dfc 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -238,6 +238,7 @@ obj-$(CONFIG_MACH_CRANEBOARD)   += 
board-am3517crane.o
 obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o
 obj-$(CONFIG_MACH_TI8168EVM)   += board-ti8168evm.o
 obj-$(CONFIG_MACH_TI8148EVM)   += board-ti8168evm.o
+obj-$(CONFIG_MACH_MCX) += board-mcx.o
 
 # Platform specific device init code
 
diff --git a/arch/arm/mach-omap2/board-mcx.c b/arch/arm/mach-omap2/board-mcx.c
new file mode 100644
index 000..70c4339
--- /dev/null
+++ b/arch/arm/mach-omap2/board-mcx.c
@@ -0,0 +1,500 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, Emcraft Systems
+ *
+ * Modified from mach-omap2/board-omap3beagle.c
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "am35xx-emac.h"
+#include "mux.h"
+#include "control.h"
+#include "hsmmc.h"
+#include "common-board-devices.h"
+#include "common.h"
+
+#define MCX_MDIO_FREQUENCY (100)
+
+static struct mtd_partition mcx_nand_partitions[] = {
+   /* All the partition sizes are listed in terms of NAND block size */
+   {
+   .name   = "X-Loader",
+   .offset = 0,
+   .size   = 4 * NAND_BLOCK_SIZE,
+   .mask_flags = MTD_WRITEABLE,/* force read-only */
+   },
+   {
+   .name   = "U-Boot",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x8 */
+   .size   = 15 * NAND_BLOCK_SIZE,
+   .mask_flags = MTD_WRITEABLE,/* force read-only */
+   },
+   {
+   .name   = "U-Boot Env",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x26 */
+   .size   = 1 * NAND_BLOCK_SIZE,
+   },
+   {
+   .name   = "Kernel",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x28 */
+   .size   = 32 * NAND_BLOCK_SIZE,
+   },
+   {
+   .name   = "File System",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x68 */
+   .size   = MTDPART_SIZ_FULL,
+   },
+};
+
+#define LCD_PWR_ENn131
+#define HDMI_TRCVR_PDn 133
+#define LCD_BKLIGHT_EN 55

[PATCH V3 0/2] Support for HTKW mcx

2011-12-21 Thread Ilya Yanok
Split into two parts:
 1. Device tree only to be used with board-generic (only serial works)
 2. Full board support via custom machine file for board-testing

Sorry for double-posting: I've put wrong linux-arm-kernel address in
the first post.

Ilya Yanok (2):
  mcx: very basic support for HTKW mcx board
  mcx: support for HTKW mcx board

 arch/arm/boot/dts/mcx.dts|   27 ++
 arch/arm/mach-omap2/Kconfig  |6 +
 arch/arm/mach-omap2/Makefile |1 +
 arch/arm/mach-omap2/board-mcx.c  |  500 ++
 arch/arm/plat-omap/include/plat/uncompress.h |1 +
 5 files changed, 535 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/mcx.dts
 create mode 100644 arch/arm/mach-omap2/board-mcx.c

-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH V3 2/2] mcx: support for HTKW mcx board

2011-12-21 Thread Ilya Yanok
Support for the HTKW mcx board (TI AM3517 based) including serial,
Ethernet, I2C, USB host, HSMMC, DSS and RTC.

Signed-off-by: Ilya Yanok 

---
Requires updated machine-type file, recently posted AM35xx-EMAC patch
and "Disable PM init on AM35{05,17} patch.

Changes from V2:
 - Rebased onto the current linux-omap/master
  - Added "common.h" include
  - Added .handle_irq field to machine description
  - Added omap_sdrc_init() call
 - Removed unneeded pullup from output pins
 - Moved pin muxing before GPIO accesses
 - Removed .ocr_mask field (it's overwritten anyway)
 - Moved touchscreen init out of I2C init
 - some readability improvements (empty lines, comments)

Changes from V1:
 - Kconfig option name fixed
 - Makefile entry sanitized
 - Unneeded headers removed
 - EMAC initialization moved to separate file/patch
 - Use gpio_{request,free}_{array,one} where possible
 - don't use platform data for touchscreen, we only need to pass
   irq number, do it via client.irq
 - check mcx_ts_init return value
 - Moved DEBUG_LL_OMAP3 entry to be in aplhabetical order
 - check return value of gpio_request for USB pwr pin
 - use pr_err instead of printk for error printing
 - added a fixed regulator for vdds_dsi
 - added SDcard card-detect pin

 arch/arm/mach-omap2/Kconfig  |6 +
 arch/arm/mach-omap2/Makefile |1 +
 arch/arm/mach-omap2/board-mcx.c  |  500 ++
 arch/arm/plat-omap/include/plat/uncompress.h |1 +
 4 files changed, 508 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-mcx.c

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 0eb27b2..fd9b8c0 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -231,6 +231,12 @@ config MACH_OMAP_3430SDP
default y
select OMAP_PACKAGE_CBB
 
+config MACH_MCX
+   bool "HTKW mcx (AM3517 based) board"
+   depends on ARCH_OMAP3
+   select OMAP_PACKAGE_CBB
+   select REGULATOR_FIXED_VOLTAGE
+
 config MACH_NOKIA_N800
bool
 
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 5d75cb5..9405dfc 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -238,6 +238,7 @@ obj-$(CONFIG_MACH_CRANEBOARD)   += 
board-am3517crane.o
 obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o
 obj-$(CONFIG_MACH_TI8168EVM)   += board-ti8168evm.o
 obj-$(CONFIG_MACH_TI8148EVM)   += board-ti8168evm.o
+obj-$(CONFIG_MACH_MCX) += board-mcx.o
 
 # Platform specific device init code
 
diff --git a/arch/arm/mach-omap2/board-mcx.c b/arch/arm/mach-omap2/board-mcx.c
new file mode 100644
index 000..70c4339
--- /dev/null
+++ b/arch/arm/mach-omap2/board-mcx.c
@@ -0,0 +1,500 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, Emcraft Systems
+ *
+ * Modified from mach-omap2/board-omap3beagle.c
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "am35xx-emac.h"
+#include "mux.h"
+#include "control.h"
+#include "hsmmc.h"
+#include "common-board-devices.h"
+#include "common.h"
+
+#define MCX_MDIO_FREQUENCY (100)
+
+static struct mtd_partition mcx_nand_partitions[] = {
+   /* All the partition sizes are listed in terms of NAND block size */
+   {
+   .name   = "X-Loader",
+   .offset = 0,
+   .size   = 4 * NAND_BLOCK_SIZE,
+   .mask_flags = MTD_WRITEABLE,/* force read-only */
+   },
+   {
+   .name   = "U-Boot",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x8 */
+   .size   = 15 * NAND_BLOCK_SIZE,
+   .mask_flags = MTD_WRITEABLE,/* force read-only */
+   },
+   {
+   .name   = "U-Boot Env",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x26 */
+   .size   = 1 * NAND_BLOCK_SIZE,
+   },
+   {
+   .name   = "Kernel",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x28 */
+   .size   = 32 * NAND_BLOCK_SIZE,
+   },
+   {
+   .name   = "File System",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x68 */
+   .size   = MTDPART_SIZ_FULL,
+   },
+};
+
+#define LCD_PWR_ENn131
+#define HDMI_TRCVR_PDn 133
+#define LCD_BKLIGHT_EN 55

[PATCH V3 1/2] mcx: very basic support for HTKW mcx board

2011-12-21 Thread Ilya Yanok
Very basic support for HTKW mcx board. Able to boot via board-generic
and ramdisk/initramfs, however most of peripherals is unsupported.
Produces tons of twl4030 related errors as this board doesn't have
twl4030 installed.

Signed-off-by: Ilya Yanok 

---
Changes from V2:

 - None

Changes from V1:

 - device tree move to the separate patch
 - iva node is disabled instead of using custom includes
 - removed bootargs entry

 arch/arm/boot/dts/mcx.dts |   27 +++
 1 files changed, 27 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/mcx.dts

diff --git a/arch/arm/boot/dts/mcx.dts b/arch/arm/boot/dts/mcx.dts
new file mode 100644
index 000..66b81bd
--- /dev/null
+++ b/arch/arm/boot/dts/mcx.dts
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, EmCraft Systems
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ "omap3.dtsi"
+
+/ {
+   model = "HTKW mcx";
+   compatible = "htkw,mcx", "ti,omap3";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x1000>; /* 256 MB */
+   };
+
+   /* AM35xx doesn't have IVA */
+   soc {
+   iva {
+   status = "disabled";
+   };
+   };
+};
-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH V3 0/2] Support for HTKW mcx

2011-12-21 Thread Ilya Yanok
plit into two parts:
 1. Device tree only to be used with board-generic (only serial works)
 2. Full board support via custom machine file for board-testing

Ilya Yanok (2):
  mcx: very basic support for HTKW mcx board
  mcx: support for HTKW mcx board

 arch/arm/boot/dts/mcx.dts|   27 ++
 arch/arm/mach-omap2/Kconfig  |6 +
 arch/arm/mach-omap2/Makefile |1 +
 arch/arm/mach-omap2/board-mcx.c  |  500 ++
 arch/arm/plat-omap/include/plat/uncompress.h |1 +
 5 files changed, 535 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/mcx.dts
 create mode 100644 arch/arm/mach-omap2/board-mcx.c

-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2] am35xx-emac: move generic EMAC init to separate file

2011-12-21 Thread Ilya Yanok
Hi,

On 21.12.2011 10:07, Hiremath, Vaibhav wrote:
>> +static struct resource am35xx_mdio_resources[] = {
>> +{
>> +.start  = AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET,
>> +.end= AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET +
>> +  SZ_4K - 1,
>> +.flags  = IORESOURCE_MEM,
>> +},
>> +};
> This will not be board independent, using AM35xx everywhere.

Why? It will work for any AM35XX based board. Probably we can try and
make it work with EMACs on other AM3XXXs but I don't have these devices.

> To make it completely board independent, you should get all this platform 
> specific data from board file. Probably have emac_init() function here and 
> pass the data.

Hm.. This data is SoC-dependent not board-dependent, what's the reason
to move it to the board file?

> Do you know any other platform or device using this IP?

Yes, I have a couple of AM3517 based boards that use this IP.

Regards, Ilya.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] OMAP3: clock3xxx_data: change EMAC clocks aliases

2011-12-20 Thread Ilya Yanok
Rename EMAC clocks to match driver expectations: both davinci_emac and
davinci_mdio drivers call clk_get(dev, NULL) so we have to provide
("davinci_emac", NULL) and ("davinci_mdio.0", NULL) clocks instead of
("davinci_emac", "emac_clk") and ("davinci_emac", "phy_clk") resp.

CC: Paul Walmsley 
Signed-off-by: Ilya Yanok 
---
 arch/arm/mach-omap2/clock3xxx_data.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/clock3xxx_data.c 
b/arch/arm/mach-omap2/clock3xxx_data.c
index d75e5f6..1a60661 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3465,8 +3465,8 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL,   "ipss_ick", &ipss_ick,  CK_AM35XX),
CLK(NULL,   "rmii_ck",  &rmii_ck,   CK_AM35XX),
CLK(NULL,   "pclk_ck",  &pclk_ck,   CK_AM35XX),
-   CLK("davinci_emac", "emac_clk", &emac_ick,  CK_AM35XX),
-   CLK("davinci_emac", "phy_clk",  &emac_fck,  CK_AM35XX),
+   CLK("davinci_emac", NULL,   &emac_ick,  CK_AM35XX),
+   CLK("davinci_mdio.0",   NULL,   &emac_fck,  CK_AM35XX),
CLK("vpfe-capture", "master",   &vpfe_ick,  CK_AM35XX),
CLK("vpfe-capture", "slave",&vpfe_fck,  CK_AM35XX),
CLK("musb-am35x",   "ick",  &hsotgusb_ick_am35xx,   
CK_AM35XX),
-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH V2] am35xx-emac: move generic EMAC init to separate file

2011-12-20 Thread Ilya Yanok
AM35xx SoCs include DaVinci EMAC IP. Initialization code in
board-am3517evm.c is pretty board independent and will work for any
AM35xx based board so move this code to it's own file to be reused by
other boards.

Signed-off-by: Ilya Yanok 

---
Changes from V1:

 - removed clock aliases

 arch/arm/mach-omap2/Makefile  |3 +
 arch/arm/mach-omap2/am35xx-emac.c |  131 +
 arch/arm/mach-omap2/am35xx-emac.h |   16 
 arch/arm/mach-omap2/board-am3517evm.c |  114 +
 4 files changed, 152 insertions(+), 112 deletions(-)
 create mode 100644 arch/arm/mach-omap2/am35xx-emac.c
 create mode 100644 arch/arm/mach-omap2/am35xx-emac.h

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fc9b238..5d75cb5 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -270,4 +270,7 @@ smsc911x-$(CONFIG_SMSC911X) := gpmc-smsc911x.o
 obj-y  += $(smsc911x-m) $(smsc911x-y)
 obj-$(CONFIG_ARCH_OMAP4)   += hwspinlock.o
 
+emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
+obj-y  += $(emac-m) $(emac-y)
+
 obj-y  += common-board-devices.o twl-common.o
diff --git a/arch/arm/mach-omap2/am35xx-emac.c 
b/arch/arm/mach-omap2/am35xx-emac.c
new file mode 100644
index 000..eb23a09
--- /dev/null
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -0,0 +1,131 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, Emcraft Systems
+ *
+ * Based on mach-omap2/board-am3517evm.c
+ * Copyright (C) 2009 Texas Instruments Incorporated
+ * Author: Ranjith Lohithakshan 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any kind,
+ * whether express or implied; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "control.h"
+
+static struct mdio_platform_data am35xx_mdio_pdata;
+
+static struct resource am35xx_mdio_resources[] = {
+   {
+   .start  = AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET,
+   .end= AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET +
+ SZ_4K - 1,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct platform_device am35xx_mdio_device = {
+   .name   = "davinci_mdio",
+   .id = 0,
+   .num_resources  = ARRAY_SIZE(am35xx_mdio_resources),
+   .resource   = am35xx_mdio_resources,
+   .dev.platform_data = &am35xx_mdio_pdata,
+};
+
+static void am35xx_enable_ethernet_int(void)
+{
+   u32 regval;
+
+   regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+   regval = (regval | AM35XX_CPGMAC_C0_RX_PULSE_CLR |
+   AM35XX_CPGMAC_C0_TX_PULSE_CLR |
+   AM35XX_CPGMAC_C0_MISC_PULSE_CLR |
+   AM35XX_CPGMAC_C0_RX_THRESH_CLR);
+   omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+   regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static void am35xx_disable_ethernet_int(void)
+{
+   u32 regval;
+
+   regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+   regval = (regval | AM35XX_CPGMAC_C0_RX_PULSE_CLR |
+   AM35XX_CPGMAC_C0_TX_PULSE_CLR);
+   omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+   regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static struct emac_platform_data am35xx_emac_pdata = {
+   .ctrl_reg_offset= AM35XX_EMAC_CNTRL_OFFSET,
+   .ctrl_mod_reg_offset= AM35XX_EMAC_CNTRL_MOD_OFFSET,
+   .ctrl_ram_offset= AM35XX_EMAC_CNTRL_RAM_OFFSET,
+   .ctrl_ram_size  = AM35XX_EMAC_CNTRL_RAM_SIZE,
+   .version= EMAC_VERSION_2,
+   .hw_ram_addr= AM35XX_EMAC_HW_RAM_ADDR,
+   .interrupt_enable   = am35xx_enable_ethernet_int,
+   .interrupt_disable  = am35xx_disable_ethernet_int,
+};
+
+static struct resource am35xx_emac_resources[] = {
+   {
+   .start  = AM35XX_IPSS_EMAC_BASE,
+   .end= AM35XX_IPSS_EMAC_BASE + 0x2,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start  = INT_35XX_EMAC_C0_RXTHRESH_IRQ,
+   .end= INT_35XX_EMAC_C0_RXTHRESH_IRQ,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = INT_35XX_EMAC_C0_RX_PULSE_IRQ,
+   .end= INT_35XX_EMAC_C0_RX_PULSE_IRQ,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = INT_35XX_EMAC_C0_TX_PULSE_IRQ,
+   .end= INT_35XX_EMAC_

Re: [PATCH] am35xx-emac: move generic EMAC init to separate file

2011-12-20 Thread Ilya Yanok
Hi Paul,

On 16.12.2011 10:13, Paul Walmsley wrote:
>> Ok, let's wait for Paul's answer and then I'll prepare a separate patch.
> 
> Unfortunately the AM3517 TRM (SPRUGR0) here doesn't really have the same 
> level of clock integration information that the WBU TRMs have, so it's 
> kind of hard to tell what's going on :-(
> 
> Looking at Figure 22-1 "EMAC and MDIO Block Diagram", it appears that what 
> we call "emac_fck" is really just an optional functional clock for the 
> MDIO PHY?

Hm. I have to admit I'm completely lost here.
CONTROL_IPSS_CLK_CTRL register has bit controlling "Func clock of
CPGMAC". But there is no mention of this clock anywhere else in the
manual. I can't find neither where it comes from nor how it's used.
According to the current sources it comes from external 50MHz RMII
clock, do you think this is correct?

EMAC section speaks something about variable frequency peripheral clock
which is used to generate MDIO bus clock signal. But I can't find any
information on that clock in the other parts of the document. It seems
to me the EMAC section was just copied from DaVinci RM without any
editing...

> And it sounds like the AM35xx clock that we call "emac_ick" is actually a 
> combined interface and functional clock for the EMAC and MDIO IP blocks?  
> I guess a combined interface/functional clock would make sense, since the 
> EMAC seems to contain a DMA controller.
>   
> Maybe Ranjith can provide some more information; he's cc'ed.
> 
> In any case, your changes sound reasonable to me, so a patch to the clock 
> file sounds good.  I'd suggest both changing the clkdev aliases and 
> renaming emac_fck - that's a confusing name and I don't think it's in the 
> TRM as such.

Actually it's called Func clock in the manual (see
CONTROL_IPSS_CLK_CTRL). Do you still think we have to rename it?

I have another concern: changing clkdev aliases make things work for me
but now I'm not sure if this change is really correct...

Regards, Ilya.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2] omap-serial: add RS485 mode support

2011-12-20 Thread Ilya Yanok
Hi Wolfram,

On 21.12.2011 01:53, Wolfram Sang wrote:
>> Add support for asserting RTS line while TX is in progress. OMAP
>> hardware doesn't support auto-RS485 mode so we control the line from
>> software. We use TX_EMPTY_CTL_IT bit in SCR register to generate TX
>> empty interrupt.
> 
> Sorry to bring bad news, but software RS485 is not mainlinable [1].
> You can browse linux-serial for RS485 to find more threads about it.

I see. Actually I searched the lists and seen that completely software
solution (using timers) was never merged. This is somewhere in between:
hardware can fire an interrupt exactly after both TX FIFO and shift
register are emptied so it's only the interrupt latency that affects the
timing.

Thanks for your reply anyway. We will have to maintain this patch in our
tree then.

Regards, Ilya.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH V2] omap-serial: add RS485 mode support

2011-12-20 Thread Ilya Yanok
Add support for asserting RTS line while TX is in progress. OMAP
hardware doesn't support auto-RS485 mode so we control the line from
software. We use TX_EMPTY_CTL_IT bit in SCR register to generate TX
empty interrupt.

We use SER_RS485_RTS_ON_SEND flag to control the polarity of RTS signal
(RTS is asserted high during transmition if this flag is set and low
otherwise) though I'm not sure if this is what this flag is for...

Signed-off-by: Ilya Yanok 
---
Changes from V1:

 - rebased onto current linux-omap/master

 arch/arm/plat-omap/include/plat/omap-serial.h |3 +
 drivers/tty/serial/omap-serial.c  |  126 ++---
 include/linux/serial_reg.h|2 +
 3 files changed, 118 insertions(+), 13 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h 
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 9ff..d6f5eee 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -136,6 +136,9 @@ struct uart_omap_port {
u32 latency;
u32 calc_latency;
struct work_struct  qos_work;
+   struct serial_rs485 rs485;
+   unsigned inttx_in_progress:1,
+   tx_wait_end:1;
 };
 
 #endif /* __OMAP_SERIAL_H__ */
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index ca24ab3..1483c43 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -39,12 +39,14 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 
 #define DEFAULT_CLK_SPEED 4800 /* 48Mhz*/
+#define OMAP_RS485_SUPPORTED   (SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND)
 
 static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
 
@@ -126,6 +128,45 @@ static void serial_omap_enable_ms(struct uart_port *port)
pm_runtime_put(&up->pdev->dev);
 }
 
+static inline void serial_omap_enable_ier_thri(struct uart_omap_port *up)
+{
+   if (!(up->ier & UART_IER_THRI)) {
+   up->ier |= UART_IER_THRI;
+   serial_out(up, UART_IER, up->ier);
+   }
+}
+
+static inline void serial_omap_disable_ier_thri(struct uart_omap_port *up)
+{
+   if (up->ier & UART_IER_THRI) {
+   up->ier &= ~UART_IER_THRI;
+   serial_out(up, UART_IER, up->ier);
+   }
+}
+
+static inline void serial_omap_thri_mode(struct uart_omap_port *up)
+{
+   unsigned char scr = serial_in(up, UART_OMAP_SCR);
+
+   if (up->tx_wait_end)
+   scr |= UART_OMAP_SCR_TX_EMPTY_CTL_IT;
+   else
+   scr &= ~UART_OMAP_SCR_TX_EMPTY_CTL_IT;
+   serial_out(up, UART_OMAP_SCR, scr);
+}
+
+static inline void serial_omap_update_rts(struct uart_omap_port *up)
+{
+   unsigned char mcr = up->mcr;
+   int rts_on_send = up->rs485.flags & SER_RS485_RTS_ON_SEND;
+
+   if ((up->rs485.flags & SER_RS485_ENABLED) &&
+   ((up->tx_in_progress && rts_on_send) ||
+!(up->tx_in_progress || rts_on_send)))
+   mcr |= UART_MCR_RTS;
+   serial_out(up, UART_MCR, mcr);
+}
+
 static void serial_omap_stop_tx(struct uart_port *port)
 {
struct uart_omap_port *up = (struct uart_omap_port *)port;
@@ -146,11 +187,13 @@ static void serial_omap_stop_tx(struct uart_port *port)
}
 
pm_runtime_get_sync(&up->pdev->dev);
-   if (up->ier & UART_IER_THRI) {
-   up->ier &= ~UART_IER_THRI;
-   serial_out(up, UART_IER, up->ier);
+   if (!(up->rs485.flags & SER_RS485_ENABLED)) {
+   serial_omap_disable_ier_thri(up);
+   } else {
+   up->tx_wait_end = 1;
+   serial_omap_thri_mode(up);
+   serial_omap_enable_ier_thri(up);
}
-
pm_runtime_mark_last_busy(&up->pdev->dev);
pm_runtime_put_autosuspend(&up->pdev->dev);
 }
@@ -268,14 +311,6 @@ static void transmit_chars(struct uart_omap_port *up)
serial_omap_stop_tx(&up->port);
 }
 
-static inline void serial_omap_enable_ier_thri(struct uart_omap_port *up)
-{
-   if (!(up->ier & UART_IER_THRI)) {
-   up->ier |= UART_IER_THRI;
-   serial_out(up, UART_IER, up->ier);
-   }
-}
-
 static void serial_omap_start_tx(struct uart_port *port)
 {
struct uart_omap_port *up = (struct uart_omap_port *)port;
@@ -283,6 +318,18 @@ static void serial_omap_start_tx(struct uart_port *port)
unsigned int start;
int ret = 0;
 
+   if (up->rs485.flags & SER_RS485_ENABLED) {
+   if (!up->tx_in_progress) {
+   up->tx_in_progress = 1;
+   serial_omap_update_rts(up);
+   }
+   

Re: [PATCH V2 2/2] mcx: support for HTKW mcx board

2011-12-20 Thread Ilya Yanok
Hi Igor,

On 15.12.2011 14:40, Igor Grinberg wrote:
>> +r = gpio_request_array(mcx_dss_gpios, ARRAY_SIZE(mcx_dss_gpios));
>> +if (r) {
>> +pr_err("failed to get DSS control GPIOs\n");
>> +return;
>> +}
>> +
>> +omap_mux_init_gpio(LCD_BKLIGHT_EN, OMAP_PIN_OUTPUT);
>> +omap_mux_init_gpio(LCD_LVL_SFHT_BUF_ENn, OMAP_PIN_OUTPUT);
>> +omap_mux_init_gpio(LCD_PWR_ENn, OMAP_PIN_OUTPUT);
>> +omap_mux_init_gpio(HDMI_TRCVR_PDn, OMAP_PIN_OUTPUT);
> 
> Shouldn't you mux the pins, before you access the GPIO
> (e.g. before the gpio_request_array()).
> Are there any safety problems?

No, there are no problems. I will move mux settings above
gpio_request_array() call.

>> +static struct omap2_hsmmc_info mmc[] = {
>> +{
>> +.mmc= 1,
>> +.caps   = MMC_CAP_4_BIT_DATA,
>> +.gpio_cd= SD_CARD_CD,
>> +.gpio_wp= SD_CARD_WP,
>> +.ocr_mask   = MMC_VDD_32_33 | MMC_VDD_33_34 |
>> +MMC_VDD_165_195,
> 
> The ocr_mask will be overridden, by the following patch:
> -
> commit e89715a7e48d505f42813a4e3ee0f0efb49832ba
> Author: Abhilash K V 
> Date:   Fri Dec 9 12:27:36 2011 -0800
> 
> ARM: OMAP: hsmmc: Support for AM3517 MMC1 voltages
> --
> 
> in Tony's hsmmc branch.
> 
> IMO it should be fixed, by adding a check if the ocr_mask is
> already set...
> I can't send a patch for this right now...

Well, I think I should just drop the .ocr_mask field then. Everything
works fine for me with the above mentioned patch.

>> +#ifdef CONFIG_OMAP_MUX
>> +static struct omap_board_mux board_mux[] __initdata = {
>> +OMAP3_MUX(CHASSIS_DMAREQ3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
>> +OMAP3_MUX(UART1_TX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT |
>> +OMAP_PULL_ENA | OMAP_PULL_UP),
>> +OMAP3_MUX(UART1_RX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
>> +OMAP3_MUX(UART1_RTS, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
>> +OMAP3_MUX(UART1_CTS, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT |
>> +OMAP_PULL_ENA | OMAP_PULL_UP),
> 
> Hmm... pullup for output? Is this needed for kind of safety?

This is a mistake indeed. Will remove the pullups.

>> +static void __init mcx_init(void)
>> +{
>> +int err;
>> +
>> +omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
>> +mcx_i2c_init();
>> +platform_add_devices(mcx_devices, ARRAY_SIZE(mcx_devices));
>> +omap_serial_init();
> 
> Shouldn't this one be before the mcx_i2c_init() call?

Well, I think I've taken this order from some other board init... I
think the idea was to bring up regulator chip earlier. But I can move
serial up with no problem.

>> +mcx_display_init();
>> +
>> +/* Configure EHCI ports */
>> +err = gpio_request_one(USB_HOST_PWR_EN, GPIOF_OUT_INIT_HIGH,
>> +"USB_HOST_PWR_EN");
>> +if (err)
>> +pr_warn("Failed to request USB host power enable GPIO\n");
> 
> empty line here will improve the readability.

Ok.

Regards, Ilya.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Interesting L3 driver panic on v3.2-rc5 on 3530

2011-12-20 Thread Ilya Yanok
Hi Archit,

On 20.12.2011 16:23, Archit Taneja wrote:
>>> [0.238494] Kernel BUG at c0033e34 [verbose debug info unavailable]
>>> [0.245025] Internal error: Oops - undefined instruction: 0 [#1] SMP
>>> [0.262390] PC is at omap3_l3_app_irq+0x108/0x12c
>>
>> I'm getting the same error on one of my AM3517 boards.
>> L3_SI_FLAG_STATUS_0 register has bit 15 set that means Display SS IA
>> burst
>> timeout according to the RM.
>>
>> Regards, Ilya.
> 
> Do the bootloaders on these boards enable display?

Yes, U-Boot on the problematic board enables the display. Disabling
display support in U-Boot makes this problem go away.

> There was a patch which got into the kernel in 3.2-rc4:
> 
> b923d40dd4211c4ef7d4efa2bd81b7ca1d8744c1
> ARM: OMAP2PLUS: DSS: Ensure DSS works correctly if display is enabled in
> bootloader
> 
> This tries to disable any display outputs if enabled in bootloader. If
> this issue didn't happen before, we might want to look into this code.

Hm. I can't say reverting this patch solves the problem completely. It
seems to me that the bug triggers more rarely without this patch but I
can't say for sure: it might be just a coincedence.

> Could you share what debug prints you get from the function
> omap_dss_reset() (its in arch/arm/mach-omap2/display.c)

I can't see much debug output from this function/file. The only line is

dss_core: softreset done

and it's the same regardless of the bug was triggered or not.

Do you wish me to add some debugging output and present the results? It
would be great if you could say what data to dump.

Regards, Ilya.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Interesting L3 driver panic on v3.2-rc5 on 3530

2011-12-19 Thread Ilya Yanok
Hi Paul,

Paul Walmsley  pwsan.com> writes:
> [0.238494] Kernel BUG at c0033e34 [verbose debug info unavailable]
> [0.245025] Internal error: Oops - undefined instruction: 0 [#1] SMP
> [0.262390] PC is at omap3_l3_app_irq+0x108/0x12c

I'm getting the same error on one of my AM3517 boards.
L3_SI_FLAG_STATUS_0 register has bit 15 set that means Display SS IA burst
timeout according to the RM.

Regards, Ilya.


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] OMAP3: don't init PM on AM35{05,17}

2011-12-19 Thread Ilya Yanok
Current OMAP3 PM code seems to be incompatible with AM35{05,17} and
leads to system hang during boot.
Disable PM init on AM35{05,17} until working implementation will be
merged.

Signed-off-by: Ilya Yanok 
---
This patch solves the problem for me but I'm curious why simple
CONFIG_PM disabling doesn't work? I'm getting
Unhandled fault: external abort on non-linefetch
while trying to access absolutely valid register from omapdss/venc
driver. I've tried to disable VENC but then I got the same error
from omap_wdt driver. Is it supposed to be so? Are !CONFIG_PM
configurations supported? How comes that disabling CONFIG_PM
makes some registers inaccessible?

Regards, Ilya.

 arch/arm/mach-omap2/pm34xx.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index fc69875..0f30742 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -790,7 +790,7 @@ static int __init omap3_pm_init(void)
struct clockdomain *neon_clkdm, *per_clkdm, *mpu_clkdm, *core_clkdm;
int ret;
 
-   if (!cpu_is_omap34xx())
+   if (!cpu_is_omap34xx() || cpu_is_omap3505() || cpu_is_omap3517())
return -ENODEV;
 
if (!omap3_has_io_chain_ctrl())
-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Problems booting recent kernels on AM3517

2011-12-18 Thread Ilya Yanok
Hi All,

I've just rebased my patches on the top of current linux-omap tree and
found my AM3517 unbootable: omap3_pm_idle is called and then the system
hangs.

I can see some patches to support pm_idle on AM3517 so I assume that the
current code can't work on my systems properly.

What is the right way to make my systems boot again?

(I've tried to disable PM_RUNTIME but that results in crash somewhere
inside DSS driver.)

Regards, Ilya.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] davinci-cpdma: fix locking issue in cpdma_chan_stop

2011-12-18 Thread Ilya Yanok
Free the channel lock before calling __cpdma_chan_process to prevent
dead lock.

Signed-off-by: Ilya Yanok 
---
 drivers/net/ethernet/ti/davinci_cpdma.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c 
b/drivers/net/ethernet/ti/davinci_cpdma.c
index dca9d33..c97d2f5 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -836,11 +836,13 @@ int cpdma_chan_stop(struct cpdma_chan *chan)
chan_write(chan, cp, CPDMA_TEARDOWN_VALUE);
 
/* handle completed packets */
+   spin_unlock_irqrestore(&chan->lock, flags);
do {
ret = __cpdma_chan_process(chan);
if (ret < 0)
break;
} while ((ret & CPDMA_DESC_TD_COMPLETE) == 0);
+   spin_lock_irqsave(&chan->lock, flags);
 
/* remaining packets haven't been tx/rx'ed, clean them up */
while (chan->head) {
-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2 1/2] mcx: very basic support for HTKW mcx board

2011-12-15 Thread Ilya Yanok
Hi Igor,

On 15.12.2011 13:51, Igor Grinberg wrote:
>> +/* AM35xx doesn't have IVA */
>> +soc {
>> +iva {
>> +status = "disabled";
>> +};
>> +};
> 
> I don't get it...
> Why SoCs that do not have those IP blocks should poke
> their configuration inside the h/w description
> (e.g. disable/enable/workaround/hack)?
> This way, why don't we also disable the PCIe which this SoC does not have?

Well, I'm not really happy about this solution... But when we discussed
it last time (http://thread.gmane.org/gmane.linux.ports.arm.omap/66601 )
you and Benoit didn't come to agreement...
I really like your solution with dts built from brick corresponding to
IPs but I don't have much time to invest into patches that will likely
be rejected...

Regards, Ilya.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] am35xx-emac: move generic EMAC init to separate file

2011-12-15 Thread Ilya Yanok
Hi Tony,

On 15.12.2011 22:43, Tony Lindgren wrote:
 Should this be just called emac-common.c? Or is it so am35xx specific
 that it won't work with others?
>>>
>>> Uh.. I'm not sure but I thought that EMAC is present only on am35xx SoCs...
> 
> OK, maybe just do a quick check on that so we don't end up
> moving the platform init code around again in few months?

Well, according to TI site, EMAC can be also found on AM33x, AM387x and
AM389x... I'm not sure if it's completely compatible but probably though.

> + clk_add_alias(NULL, dev_name(&am35xx_emac_device.dev),
> +   "emac_clk", &am35xx_emac_device.dev);
> + clk_add_alias(NULL, dev_name(&am35xx_mdio_device.dev),
> +   "phy_clk", &am35xx_emac_device.dev);

 Hmm after moving the code and should be a separate patch, don't
 we already have these clock aliases in cloc3xxx_data.c?
>>>
>>> No, we have
>>> CLK("davinci_emac", "emac_clk"...) and
>>> CLK("davinci_emac", "phy_clk"...)
>>> while drivers want ("davinci_emac", NULL) and ("davinci_mdio", NULL).
>>>
>>> Probably we have to fix the clock definitions instead of adding the aliases.
>>>
>>> So, should I post this as a separate patch?
>>
>> If it comes to that question, Cc Paul...
> 
> Yes please do that as a separate patch.

Ok, let's wait for Paul's answer and then I'll prepare a separate patch.

Regards, Ilya.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH V2 2/2] mcx: support for HTKW mcx board

2011-12-14 Thread Ilya Yanok
Support for the HTKW mcx board (TI AM3517 based) including serial,
Ethernet, I2C, USB host, HSMMC, DSS and RTC.

Signed-off-by: Ilya Yanok 

---
Requires updated mach-types file and previously posted AM35xx-EMAC
patch: http://article.gmane.org/gmane.linux.ports.arm.omap/66861

Changes from V1:
 - Kconfig option name fixed
 - Makefile entry sanitized
 - Unneeded headers removed
 - EMAC initialization moved to separate file/patch
 - Use gpio_{request,free}_{array,one} where possible
 - don't use platform data for touchscreen, we only need to pass
   irq number, do it via client.irq
 - check mcx_ts_init return value
 - Moved DEBUG_LL_OMAP3 entry to be in aplhabetical order
 - check return value of gpio_request for USB pwr pin
 - use pr_err instead of printk for error printing
 - added a fixed regulator for vdds_dsi
 - added SDcard card-detect pin

 arch/arm/mach-omap2/Kconfig  |6 +
 arch/arm/mach-omap2/Makefile |1 +
 arch/arm/mach-omap2/board-mcx.c  |  495 ++
 arch/arm/plat-omap/include/plat/uncompress.h |1 +
 4 files changed, 503 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-mcx.c

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 09ea525..535f1a1 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -230,6 +230,12 @@ config MACH_OMAP_3430SDP
default y
select OMAP_PACKAGE_CBB
 
+config MACH_MCX
+   bool "HTKW mcx (AM3517 based) board"
+   depends on ARCH_OMAP3
+   select OMAP_PACKAGE_CBB
+   select REGULATOR_FIXED_VOLTAGE
+
 config MACH_NOKIA_N800
bool
 
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index e88fcfa..4204c97 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -232,6 +232,7 @@ obj-$(CONFIG_MACH_CRANEBOARD)   += 
board-am3517crane.o
 
 obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o
 obj-$(CONFIG_MACH_TI8168EVM)   += board-ti8168evm.o
+obj-$(CONFIG_MACH_MCX) += board-mcx.o
 
 # Platform specific device init code
 
diff --git a/arch/arm/mach-omap2/board-mcx.c b/arch/arm/mach-omap2/board-mcx.c
new file mode 100644
index 000..6375fa1
--- /dev/null
+++ b/arch/arm/mach-omap2/board-mcx.c
@@ -0,0 +1,495 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, Emcraft Systems
+ *
+ * Modified from mach-omap2/board-omap3beagle.c
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "am35xx-emac.h"
+#include "mux.h"
+#include "control.h"
+#include "hsmmc.h"
+#include "common-board-devices.h"
+
+#define MCX_MDIO_FREQUENCY (100)
+
+static struct mtd_partition mcx_nand_partitions[] = {
+   /* All the partition sizes are listed in terms of NAND block size */
+   {
+   .name   = "X-Loader",
+   .offset = 0,
+   .size   = 4 * NAND_BLOCK_SIZE,
+   .mask_flags = MTD_WRITEABLE,/* force read-only */
+   },
+   {
+   .name   = "U-Boot",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x8 */
+   .size   = 15 * NAND_BLOCK_SIZE,
+   .mask_flags = MTD_WRITEABLE,/* force read-only */
+   },
+   {
+   .name   = "U-Boot Env",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x26 */
+   .size   = 1 * NAND_BLOCK_SIZE,
+   },
+   {
+   .name   = "Kernel",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x28 */
+   .size   = 32 * NAND_BLOCK_SIZE,
+   },
+   {
+   .name   = "File System",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x68 */
+   .size   = MTDPART_SIZ_FULL,
+   },
+};
+
+#define LCD_PWR_ENn131
+#define HDMI_TRCVR_PDn 133
+#define LCD_BKLIGHT_EN 55
+#define LCD_LVL_SFHT_BUF_ENn   43
+
+static int lcd_enabled;
+static int dvi_enabled;
+
+static int mcx_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+   if (dvi_enabled) {
+   pr_err("cannot enable LCD, DVI is enabled\n");
+   return -EINVAL;
+   }
+
+   gpio_set_value(LCD_BKLIGHT_EN, 1);
+   lcd_enabled = 1;
+
+   return 0;
+}
+
+static void mcx_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+   gpio_

[PATCH V2 1/2] mcx: very basic support for HTKW mcx board

2011-12-14 Thread Ilya Yanok
Very basic support for HTKW mcx board. Able to boot via board-generic
and ramdisk/initramfs, however most of peripherals is unsupported.
Produces tons of twl4030 related errors as this board doesn't have
twl4030 installed.

Signed-off-by: Ilya Yanok 

---
Changes from V1:

 - device tree moved to the separate patch
 - iva node is disabled instead of using custom includes
 - removed bootargs entry

 arch/arm/boot/dts/mcx.dts |   27 +++
 1 files changed, 27 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/mcx.dts

diff --git a/arch/arm/boot/dts/mcx.dts b/arch/arm/boot/dts/mcx.dts
new file mode 100644
index 000..66b81bd
--- /dev/null
+++ b/arch/arm/boot/dts/mcx.dts
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, EmCraft Systems
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ "omap3.dtsi"
+
+/ {
+   model = "HTKW mcx";
+   compatible = "htkw,mcx", "ti,omap3";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x1000>; /* 256 MB */
+   };
+
+   /* AM35xx doesn't have IVA */
+   soc {
+   iva {
+   status = "disabled";
+   };
+   };
+};
-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH V2 0/2] Support for HTKW mcx

2011-12-14 Thread Ilya Yanok
Split into two parts:
 1. Device tree only to be used with board-generic (only serial works)
 2. Full board support via custom machine file for board-testing

Ilya Yanok (2):
  mcx: very basic support for HTKW mcx board
  mcx: support for HTKW mcx board

 arch/arm/boot/dts/mcx.dts|   27 ++
 arch/arm/mach-omap2/Kconfig  |6 +
 arch/arm/mach-omap2/Makefile |1 +
 arch/arm/mach-omap2/board-mcx.c  |  495 ++
 arch/arm/plat-omap/include/plat/uncompress.h |1 +
 5 files changed, 530 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/mcx.dts
 create mode 100644 arch/arm/mach-omap2/board-mcx.c

-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] am35xx-emac: move generic EMAC init to separate file

2011-12-14 Thread Ilya Yanok
Hi Tony,

On 08.12.2011 04:15, Tony Lindgren wrote:
>> AM35xx SoCs include DaVinci EMAC IP. Initialization code in
>> board-am3517evm.c is pretty board independent and will work for any
>> AM35xx based board so move this code to it's own file to be reused by
>> other boards.
> 
> Should this be just called emac-common.c? Or is it so am35xx specific
> that it won't work with others?

Uh.. I'm not sure but I thought that EMAC is present only on am35xx SoCs...

>> +clk_add_alias(NULL, dev_name(&am35xx_emac_device.dev),
>> +  "emac_clk", &am35xx_emac_device.dev);
>> +clk_add_alias(NULL, dev_name(&am35xx_mdio_device.dev),
>> +  "phy_clk", &am35xx_emac_device.dev);
> 
> Hmm after moving the code and should be a separate patch, don't
> we already have these clock aliases in cloc3xxx_data.c?

No, we have
CLK("davinci_emac", "emac_clk"...) and
CLK("davinci_emac", "phy_clk"...)
while drivers want ("davinci_emac", NULL) and ("davinci_mdio", NULL).

Probably we have to fix the clock definitions instead of adding the aliases.

So, should I post this as a separate patch?

Regards, Ilya.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 4/4] mcx: initial support for HTKW mcx board

2011-11-21 Thread Ilya Yanok
Hi Tony,

On 19.11.2011 04:36, Tony Lindgren wrote:
>> Well, it already boots with DT actually. Did you mean booting with DT
>> and board-generic? I have to admit I don't know how to proceed here:
> 
> Good to hear you're already playing with it. Yes, let's work on making
> all the boards work with DT and board-generic..

Hm, do you think it's absolutely necessary to make everybody work with
board-generic? It will require a lot of additional bindings to get rid
of all machine-specific code. I've just thought that on PowerPC we don't
have such strict rules: if some boards are really similar they share
common machine file but if we need something specific for the new board
we can create it's own machine file.

>> board-generic initialize twl4030 which we don't have on our board...
>> Could you give me some pointer how I'm supposed to handle this?
> 
> .. we should only initialize twl4030/twl6030 if the DT compatible flag
> for it is set. But we're still missing the DT bindings for those :(
> 
> For now, maybe try to fix the twl4030 probe so it won't do anything
> unless the I2C device is found?

That turned to be not such a big problem. Device is not present so we
have tons of error messages but somehow it works.

The bigger problem is that we have different regulator chip attached.
How am I supposed to register supplies/consumers data with it? Does
anybody working on DT bindings for the regulator framework?

Regards, Ilya.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH V2] omap_dss: add FocalTech ETM070003DH6 display support

2011-11-20 Thread Ilya Yanok
Add data for the FocalTech ETM070003DH6 display to the generic_dpi_panel
display driver.

Signed-off-by: Ilya Yanok 
---
Changes from V1:
 - acb, acbi, power_on_delay and power_off_delay fields removed.

 drivers/video/omap2/displays/panel-generic-dpi.c |   20 
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c 
b/drivers/video/omap2/displays/panel-generic-dpi.c
index 519c47d..593f831 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -297,6 +297,26 @@ static struct panel_config generic_dpi_panels[] = {
 
.name   = "apollon",
},
+   /* FocalTech ETM070003DH6 */
+   {
+   {
+   .x_res  = 800,
+   .y_res  = 480,
+
+   .pixel_clock= 28000,
+
+   .hsw= 48,
+   .hfp= 40,
+   .hbp= 40,
+
+   .vsw= 3,
+   .vfp= 13,
+   .vbp= 29,
+   },
+   .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+ OMAP_DSS_LCD_IHS,
+   .name   = "focaltech_etm070003dh6",
+   },
 };
 
 struct panel_drv_data {
-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/4] omap_dss: add FocalTech ETM070003DH6 display support

2011-11-20 Thread Ilya Yanok
Hi Tomi,

On 17.11.2011 14:26, Tomi Valkeinen wrote:
>> +.acbi   = 0x0,
>> +.acb= 0x28,
> 
> You could just remove .acbi and .acb, I don't think they are needed.

You are right.

>> +.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
>> +  OMAP_DSS_LCD_IHS,
>> +.power_on_delay = 50,
>> +.power_off_delay= 100,
> 
> Did you check from the panel spec if any delays are needed? These look
> like just copied from the Sharp panel data.

Actually they were copied from some vendor code, but you are right
again, I can't see anything concerning the delays in the panel spec and
panel works ok with the delays thrown out.

Regards, Ilya.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] am35xx-emac: move generic EMAC init to separate file

2011-11-16 Thread Ilya Yanok
AM35xx SoCs include DaVinci EMAC IP. Initialization code in
board-am3517evm.c is pretty board independent and will work for any
AM35xx based board so move this code to it's own file to be reused by
other boards.

Signed-off-by: Ilya Yanok 
---
 arch/arm/mach-omap2/Makefile  |3 +
 arch/arm/mach-omap2/am35xx-emac.c |  136 +
 arch/arm/mach-omap2/am35xx-emac.h |   17 
 arch/arm/mach-omap2/board-am3517evm.c |  114 +---
 4 files changed, 158 insertions(+), 112 deletions(-)
 create mode 100644 arch/arm/mach-omap2/am35xx-emac.c
 create mode 100644 arch/arm/mach-omap2/am35xx-emac.h

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 69ab1c0..3256301 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -267,4 +267,7 @@ obj-$(CONFIG_ARCH_OMAP4)+= hwspinlock.o
 disp-$(CONFIG_OMAP2_DSS)   := display.o
 obj-y  += $(disp-m) $(disp-y)
 
+emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
+obj-y  += $(emac-m) $(emac-y)
+
 obj-y  += common-board-devices.o twl-common.o
diff --git a/arch/arm/mach-omap2/am35xx-emac.c 
b/arch/arm/mach-omap2/am35xx-emac.c
new file mode 100644
index 000..e5ad303
--- /dev/null
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -0,0 +1,136 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, Emcraft Systems
+ *
+ * Based on mach-omap2/board-am3517evm.c
+ * Copyright (C) 2009 Texas Instruments Incorporated
+ * Author: Ranjith Lohithakshan 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any kind,
+ * whether express or implied; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "control.h"
+
+static struct mdio_platform_data am35xx_mdio_pdata;
+
+static struct resource am35xx_mdio_resources[] = {
+   {
+   .start  = AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET,
+   .end= AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET +
+ SZ_4K - 1,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct platform_device am35xx_mdio_device = {
+   .name   = "davinci_mdio",
+   .id = 0,
+   .num_resources  = ARRAY_SIZE(am35xx_mdio_resources),
+   .resource   = am35xx_mdio_resources,
+   .dev.platform_data = &am35xx_mdio_pdata,
+};
+
+static void am35xx_enable_ethernet_int(void)
+{
+   u32 regval;
+
+   regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+   regval = (regval | AM35XX_CPGMAC_C0_RX_PULSE_CLR |
+   AM35XX_CPGMAC_C0_TX_PULSE_CLR |
+   AM35XX_CPGMAC_C0_MISC_PULSE_CLR |
+   AM35XX_CPGMAC_C0_RX_THRESH_CLR);
+   omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+   regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static void am35xx_disable_ethernet_int(void)
+{
+   u32 regval;
+
+   regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+   regval = (regval | AM35XX_CPGMAC_C0_RX_PULSE_CLR |
+   AM35XX_CPGMAC_C0_TX_PULSE_CLR);
+   omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+   regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static struct emac_platform_data am35xx_emac_pdata = {
+   .ctrl_reg_offset= AM35XX_EMAC_CNTRL_OFFSET,
+   .ctrl_mod_reg_offset= AM35XX_EMAC_CNTRL_MOD_OFFSET,
+   .ctrl_ram_offset= AM35XX_EMAC_CNTRL_RAM_OFFSET,
+   .ctrl_ram_size  = AM35XX_EMAC_CNTRL_RAM_SIZE,
+   .version= EMAC_VERSION_2,
+   .hw_ram_addr= AM35XX_EMAC_HW_RAM_ADDR,
+   .interrupt_enable   = am35xx_enable_ethernet_int,
+   .interrupt_disable  = am35xx_disable_ethernet_int,
+};
+
+static struct resource am35xx_emac_resources[] = {
+   {
+   .start  = AM35XX_IPSS_EMAC_BASE,
+   .end= AM35XX_IPSS_EMAC_BASE + 0x2,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start  = INT_35XX_EMAC_C0_RXTHRESH_IRQ,
+   .end= INT_35XX_EMAC_C0_RXTHRESH_IRQ,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = INT_35XX_EMAC_C0_RX_PULSE_IRQ,
+   .end= INT_35XX_EMAC_C0_RX_PULSE_IRQ,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = INT_35XX_EMAC_C0_TX_PULSE_IRQ,
+   .end= INT_35XX_EMAC_C0_TX_PULSE_IRQ,
+   .flags  = IORESOURCE_IRQ,
+   

Re: [PATCH 2/4] omap_dss: add FocalTech ETM070003DH6 display support

2011-11-16 Thread Ilya Yanok
Hi guys,

what about this patch? Can it be applied? It's pretty independent from
other ones.

Regards, Ilya.

On 09.11.2011 04:12, Ilya Yanok wrote:
> Add data for the FocalTech ETM070003DH6 display to the generic_dpi_panel
> display driver.
> 
> Signed-off-by: Ilya Yanok 
> ---
>  drivers/video/omap2/displays/panel-generic-dpi.c |   24 
> ++
>  1 files changed, 24 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c 
> b/drivers/video/omap2/displays/panel-generic-dpi.c
> index 519c47d..42bfe47 100644
> --- a/drivers/video/omap2/displays/panel-generic-dpi.c
> +++ b/drivers/video/omap2/displays/panel-generic-dpi.c
> @@ -297,6 +297,30 @@ static struct panel_config generic_dpi_panels[] = {
>  
>   .name   = "apollon",
>   },
> + /* FocalTech ETM070003DH6 */
> + {
> + {
> + .x_res  = 800,
> + .y_res  = 480,
> +
> + .pixel_clock= 28000,
> +
> + .hsw= 48,
> + .hfp= 40,
> + .hbp= 40,
> +
> + .vsw= 3,
> + .vfp= 13,
> + .vbp= 29,
> + },
> + .acbi   = 0x0,
> + .acb= 0x28,
> + .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
> +   OMAP_DSS_LCD_IHS,
> + .power_on_delay = 50,
> + .power_off_delay= 100,
> + .name   = "focaltech_etm070003dh6",
> + },
>  };
>  
>  struct panel_drv_data {

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/4] AM35xx: DSS: there is no VDDS_DSI on AM35xx

2011-11-16 Thread Ilya Yanok
Hi Archit,

On 09.11.2011 14:10, Archit Taneja wrote:
>> AM35xx don't have VDDS_DSI regulator.
> 
> AM35xx do have vdds_dsi regulator. Are you saying that your particular
> board doesn't have vdds_dsi connected to a regulator?
> 
> I assumed that vdds_dsi regulator was required for DPI to function
> properly on omap3 devices.

Could you please give me some pointer how to find VDDS_DSI on AM3517?
Looking at the AM3517 datasheet neither I nor board manufactured can't
find any reference of VDDS_DSI so we can't determine how it is powered.

Of course I can register fake fixed regulator from the board code but
I'd like to find the proper solution for this.

Regards, Ilya.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 4/4] mcx: initial support for HTKW mcx board

2011-11-14 Thread Ilya Yanok
Hi Tony,

On 11.11.2011 04:12, Tony Lindgren wrote:
> This looks OK but let's concentrate on getting things working with
> board-generic.c and DT only in mainline kernel.
> 
> I can apply this into testing-board, but let's not cause more churn
> in mainline with the board files that will be disappearing.
> 
> Can you please split it into something minimal for mainline that
> allows booting with DT, and then another patch for testing-board
> branch?

Well, it already boots with DT actually. Did you mean booting with DT
and board-generic? I have to admit I don't know how to proceed here:
board-generic initialize twl4030 which we don't have on our board...
Could you give me some pointer how I'm supposed to handle this?

Regards, Ilya.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/4] AM35xx: DSS: there is no VDDS_DSI on AM35xx

2011-11-09 Thread Ilya Yanok

Hi Archit,

09.11.2011 14:10, Archit Taneja wrote:

AM35xx don't have VDDS_DSI regulator.


AM35xx do have vdds_dsi regulator. Are you saying that your particular
board doesn't have vdds_dsi connected to a regulator?


Yes, you are right. But looking at the manual (and name) I think it's 
needed only for DSI operation. On our board we have LCD connected 
through DPI.



I assumed that vdds_dsi regulator was required for DPI to function
properly on omap3 devices.


Ok, please ignore this patch then. I think I'll create fake regulator 
from the board code to fix this.


Regards, Ilya.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] omap-serial: add RS485 mode support

2011-11-08 Thread Ilya Yanok

Hi guys,

any comments on this? Is anybody interested?

Regards, Ilya.

03.10.2011 0:27, Ilya Yanok wrote:

Add support for asserting RTS line while TX is in progress. OMAP
hardware doesn't support auto-RS485 mode so we control the line from
software. We use TX_EMPTY_CTL_IT bit in SCR register to generate TX
empty interrupt.

We use SER_RS485_RTS_ON_SEND flag to control the polarity of RTS signal
(RTS is asserted high during transmition if this flag is set and low
otherwise) though I'm not sure if this is what this flag is for...

Signed-off-by: Ilya Yanok
---
  arch/arm/plat-omap/include/plat/omap-serial.h |3 +
  drivers/tty/serial/omap-serial.c  |  127 ++---
  include/linux/serial_reg.h|2 +
  3 files changed, 120 insertions(+), 12 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h 
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 2682043..5003400 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -111,6 +111,9 @@ struct uart_omap_port {
unsigned char   msr_saved_flags;
charname[20];
unsigned long   port_activity;
+   struct serial_rs485 rs485;
+   unsigned inttx_in_progress:1,
+   tx_wait_end:1;
  };

  #endif /* __OMAP_SERIAL_H__ */
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 47cadf4..6526171 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -37,11 +37,14 @@
  #include
  #include
  #include
+#include

  #include
  #include
  #include

+#define OMAP_RS485_SUPPORTED   (SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND)
+
  static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];

  /* Forward declaration of functions */
@@ -114,6 +117,45 @@ static void serial_omap_enable_ms(struct uart_port *port)
serial_out(up, UART_IER, up->ier);
  }

+static inline void serial_omap_enable_ier_thri(struct uart_omap_port *up)
+{
+   if (!(up->ier&  UART_IER_THRI)) {
+   up->ier |= UART_IER_THRI;
+   serial_out(up, UART_IER, up->ier);
+   }
+}
+
+static inline void serial_omap_disable_ier_thri(struct uart_omap_port *up)
+{
+   if (up->ier&  UART_IER_THRI) {
+   up->ier&= ~UART_IER_THRI;
+   serial_out(up, UART_IER, up->ier);
+   }
+}
+
+static inline void serial_omap_thri_mode(struct uart_omap_port *up)
+{
+   unsigned char scr = serial_in(up, UART_OMAP_SCR);
+
+   if (up->tx_wait_end)
+   scr |= UART_OMAP_SCR_TX_EMPTY_CTL_IT;
+   else
+   scr&= ~UART_OMAP_SCR_TX_EMPTY_CTL_IT;
+   serial_out(up, UART_OMAP_SCR, scr);
+}
+
+static inline void serial_omap_update_rts(struct uart_omap_port *up)
+{
+   unsigned char mcr = up->mcr;
+   int rts_on_send = up->rs485.flags&  SER_RS485_RTS_ON_SEND;
+
+   if ((up->rs485.flags&  SER_RS485_ENABLED)&&
+   ((up->tx_in_progress&&  rts_on_send) ||
+!(up->tx_in_progress || rts_on_send)))
+   mcr |= UART_MCR_RTS;
+   serial_out(up, UART_MCR, mcr);
+}
+
  static void serial_omap_stop_tx(struct uart_port *port)
  {
struct uart_omap_port *up = (struct uart_omap_port *)port;
@@ -131,10 +173,14 @@ static void serial_omap_stop_tx(struct uart_port *port)
up->uart_dma.tx_dma_channel = OMAP_UART_DMA_CH_FREE;
}

-   if (up->ier&  UART_IER_THRI) {
-   up->ier&= ~UART_IER_THRI;
-   serial_out(up, UART_IER, up->ier);
+   if (!(up->rs485.flags&  SER_RS485_ENABLED)) {
+   serial_omap_disable_ier_thri(up);
+   return;
}
+
+   up->tx_wait_end = 1;
+   serial_omap_thri_mode(up);
+   serial_omap_enable_ier_thri(up);
  }

  static void serial_omap_stop_rx(struct uart_port *port)
@@ -246,14 +292,6 @@ static void transmit_chars(struct uart_omap_port *up)
serial_omap_stop_tx(&up->port);
  }

-static inline void serial_omap_enable_ier_thri(struct uart_omap_port *up)
-{
-   if (!(up->ier&  UART_IER_THRI)) {
-   up->ier |= UART_IER_THRI;
-   serial_out(up, UART_IER, up->ier);
-   }
-}
-
  static void serial_omap_start_tx(struct uart_port *port)
  {
struct uart_omap_port *up = (struct uart_omap_port *)port;
@@ -261,6 +299,18 @@ static void serial_omap_start_tx(struct uart_port *port)
unsigned int start;
int ret = 0;

+   if (up->rs485.flags&  SER_RS485_ENABLED) {
+   if (!up->tx_in_progress) {
+   up->tx_in_progress = 1;
+   serial_omap_update_rts(up);
+   }
+   if (up->tx_wait_end

[PATCH 4/4] mcx: initial support for HTKW mcx board

2011-11-08 Thread Ilya Yanok
Support for the HTKW mcx board (TI AM3517 based) including serial,
Ethernet, I2C, USB host, HSMMC, DSS and RTC.

Signed-off-by: Ilya Yanok 
---
 arch/arm/boot/dts/mcx.dts|   29 ++
 arch/arm/mach-omap2/Kconfig  |5 +
 arch/arm/mach-omap2/Makefile |3 +
 arch/arm/mach-omap2/board-mcx.c  |  618 ++
 arch/arm/plat-omap/include/plat/uncompress.h |1 +
 5 files changed, 656 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/mcx.dts
 create mode 100644 arch/arm/mach-omap2/board-mcx.c

diff --git a/arch/arm/boot/dts/mcx.dts b/arch/arm/boot/dts/mcx.dts
new file mode 100644
index 000..c87df59
--- /dev/null
+++ b/arch/arm/boot/dts/mcx.dts
@@ -0,0 +1,29 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, EmCraft Systems
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ "am35xx.dtsi"
+
+/ {
+   model = "HTKW mcx";
+   compatible = "htkw,mcx";
+
+   /*
+* Since the initial device tree board file does not create any
+* devices (MMC, network...), the only way to boot is to provide a
+* ramdisk.
+*/
+   chosen {
+   bootargs = "root=/dev/ram0 rw console=ttyO2,115200n8 
initrd=0x8160,20M ramdisk_size=20480 no_console_suspend debug earlyprintk";
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x1000>; /* 256 MB */
+   };
+};
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index c3d530b..3be9cc0 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -230,6 +230,11 @@ config MACH_OMAP_3430SDP
default y
select OMAP_PACKAGE_CBB
 
+config MACH_MCX
+   bool "htkw mcx board"
+   depends on ARCH_OMAP3
+   select OMAP_PACKAGE_CBB
+
 config MACH_NOKIA_N800
bool
 
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 69ab1c0..913aa43 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -232,6 +232,9 @@ obj-$(CONFIG_MACH_CRANEBOARD)   += 
board-am3517crane.o
 
 obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o
 obj-$(CONFIG_MACH_TI8168EVM)   += board-ti8168evm.o
+obj-$(CONFIG_MACH_MCX) += board-mcx.o \
+  omap_phy_internal.o \
+  hsmmc.o
 
 # Platform specific device init code
 
diff --git a/arch/arm/mach-omap2/board-mcx.c b/arch/arm/mach-omap2/board-mcx.c
new file mode 100644
index 000..311e1fb
--- /dev/null
+++ b/arch/arm/mach-omap2/board-mcx.c
@@ -0,0 +1,618 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, Emcraft Systems
+ *
+ * Modified from mach-omap2/board-omap3beagle.c
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mux.h"
+#include "control.h"
+#include "hsmmc.h"
+#include "common-board-devices.h"
+
+#define MCX_MDIO_FREQUENCY (100)
+
+static struct mdio_platform_data mcx_mdio_pdata = {
+   .bus_freq   = MCX_MDIO_FREQUENCY,
+};
+
+static struct resource am3517_mdio_resources[] = {
+   {
+   .start  = AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET,
+   .end= AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET +
+ SZ_4K - 1,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct platform_device am3517_mdio_device = {
+   .name   = "davinci_mdio",
+   .id = 0,
+   .num_resources  = ARRAY_SIZE(am3517_mdio_resources),
+   .resource   = am3517_mdio_resources,
+   .dev.platform_data = &mcx_mdio_pdata,
+};
+
+static struct emac_platform_data mcx_emac_pdata = {
+   .rmii_en= 1,
+};
+
+static struct resource am3517_emac_resources[] = {
+   {
+   .start  = AM35XX_IPSS_EMAC_BASE,
+   .end= AM35XX_IPSS_EMAC_BASE + 0x2,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start  = INT_35XX_EMAC_C0_RXTHRESH_IRQ,
+   .end= INT_35XX_EMAC_C0_RXTHRESH_IRQ

[PATCH 3/4] dts/omap3: split omap3.dtsi

2011-11-08 Thread Ilya Yanok
Split omap3.dtsi file into common part, OM3xxx specific part and
AM35xx specific part. For now the only difference is missing IVA node on
AM35xx.

Signed-off-by: Ilya Yanok 
---
 arch/arm/boot/dts/am35xx.dtsi  |   15 +++
 arch/arm/boot/dts/om3xxx.dtsi  |   28 
 arch/arm/boot/dts/omap3-beagle.dts |2 +-
 arch/arm/boot/dts/omap3.dtsi   |9 -
 4 files changed, 44 insertions(+), 10 deletions(-)
 create mode 100644 arch/arm/boot/dts/am35xx.dtsi
 create mode 100644 arch/arm/boot/dts/om3xxx.dtsi

diff --git a/arch/arm/boot/dts/am35xx.dtsi b/arch/arm/boot/dts/am35xx.dtsi
new file mode 100644
index 000..0dbc69d
--- /dev/null
+++ b/arch/arm/boot/dts/am35xx.dtsi
@@ -0,0 +1,15 @@
+/*
+ * Device Tree Source for TI AM35xx SoCs
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "omap3.dtsi"
+
+/ {
+   compatible = "ti,am35xx", "ti,omap3";
+};
diff --git a/arch/arm/boot/dts/om3xxx.dtsi b/arch/arm/boot/dts/om3xxx.dtsi
new file mode 100644
index 000..e8a17dd
--- /dev/null
+++ b/arch/arm/boot/dts/om3xxx.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Source for TI OM3xxx SoCs
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "omap3.dtsi"
+
+/ {
+   /*
+* The soc node represents the soc top level view. It is uses for IPs
+* that are not memory mapped in the MPU view or for the MPU itself.
+*/
+   soc {
+   iva {
+   compatible = "ti,iva2.2";
+   ti,hwmods = "iva";
+
+   dsp {
+   compatible = "ti,omap3-c64";
+   };
+   };
+   };
+};
diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index 9486be6..63e4be1 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -7,7 +7,7 @@
  */
 /dts-v1/;
 
-/include/ "omap3.dtsi"
+/include/ "om3xxx.dtsi"
 
 / {
model = "TI OMAP3 BeagleBoard";
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index d202bb5..2b12b0e 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -29,15 +29,6 @@
compatible = "ti,omap3-mpu";
ti,hwmods = "mpu";
};
-
-   iva {
-   compatible = "ti,iva2.2";
-   ti,hwmods = "iva";
-
-   dsp {
-   compatible = "ti,omap3-c64";
-   };
-   };
};
 
/*
-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/4] AM35xx: DSS: there is no VDDS_DSI on AM35xx

2011-11-08 Thread Ilya Yanok
AM35xx don't have VDDS_DSI regulator.

Signed-off-by: Ilya Yanok 
---
 drivers/video/omap2/dss/dpi.c |9 +
 drivers/video/omap2/dss/dsi.c |   18 --
 2 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 976ac23..929e451 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -191,7 +191,7 @@ int omapdss_dpi_display_enable(struct omap_dss_device 
*dssdev)
goto err_start_dev;
}
 
-   if (cpu_is_omap34xx()) {
+   if (cpu_is_omap34xx() && !cpu_is_omap3505() && !cpu_is_omap3517()) {
r = regulator_enable(dpi.vdds_dsi_reg);
if (r)
goto err_reg_enable;
@@ -238,7 +238,7 @@ err_get_dsi:
 err_get_dispc:
dss_runtime_put();
 err_get_dss:
-   if (cpu_is_omap34xx())
+   if (cpu_is_omap34xx() && !cpu_is_omap3505() && !cpu_is_omap3517())
regulator_disable(dpi.vdds_dsi_reg);
 err_reg_enable:
omap_dss_stop_device(dssdev);
@@ -260,7 +260,7 @@ void omapdss_dpi_display_disable(struct omap_dss_device 
*dssdev)
dispc_runtime_put();
dss_runtime_put();
 
-   if (cpu_is_omap34xx())
+   if (cpu_is_omap34xx() && !cpu_is_omap3505() && !cpu_is_omap3517())
regulator_disable(dpi.vdds_dsi_reg);
 
omap_dss_stop_device(dssdev);
@@ -348,7 +348,8 @@ int dpi_init_display(struct omap_dss_device *dssdev)
 {
DSSDBG("init_display\n");
 
-   if (cpu_is_omap34xx() && dpi.vdds_dsi_reg == NULL) {
+   if (cpu_is_omap34xx() && (dpi.vdds_dsi_reg == NULL) &&
+   !cpu_is_omap3505() && !cpu_is_omap3517()) {
struct regulator *vdds_dsi;
 
vdds_dsi = dss_get_vdds_dsi();
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 5abf8e7..7f38ab6 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1610,7 +1610,8 @@ int dsi_pll_init(struct platform_device *dsidev, bool 
enable_hsclk,
 
DSSDBG("PLL init\n");
 
-   if (dsi->vdds_dsi_reg == NULL) {
+   if ((dsi->vdds_dsi_reg == NULL) &&
+   !cpu_is_omap3517() && !cpu_is_omap3505()) {
struct regulator *vdds_dsi;
 
vdds_dsi = regulator_get(&dsi->pdev->dev, "vdds_dsi");
@@ -1629,7 +1630,8 @@ int dsi_pll_init(struct platform_device *dsidev, bool 
enable_hsclk,
 */
dsi_enable_scp_clk(dsidev);
 
-   if (!dsi->vdds_dsi_enabled) {
+   if (!dsi->vdds_dsi_enabled &&
+   !cpu_is_omap3517() && !cpu_is_omap3505()) {
r = regulator_enable(dsi->vdds_dsi_reg);
if (r)
goto err0;
@@ -1668,7 +1670,8 @@ int dsi_pll_init(struct platform_device *dsidev, bool 
enable_hsclk,
 
return 0;
 err1:
-   if (dsi->vdds_dsi_enabled) {
+   if (dsi->vdds_dsi_enabled &&
+   !cpu_is_omap3517() && !cpu_is_omap3505()) {
regulator_disable(dsi->vdds_dsi_reg);
dsi->vdds_dsi_enabled = false;
}
@@ -1684,7 +1687,8 @@ void dsi_pll_uninit(struct platform_device *dsidev, bool 
disconnect_lanes)
 
dsi->pll_locked = 0;
dsi_pll_power(dsidev, DSI_PLL_POWER_OFF);
-   if (disconnect_lanes) {
+   if (disconnect_lanes &&
+   !cpu_is_omap3517() && !cpu_is_omap3505()) {
WARN_ON(!dsi->vdds_dsi_enabled);
regulator_disable(dsi->vdds_dsi_reg);
dsi->vdds_dsi_enabled = false;
@@ -4530,7 +4534,8 @@ int dsi_init_display(struct omap_dss_device *dssdev)
OMAP_DSS_DISPLAY_CAP_TEAR_ELIM;
}
 
-   if (dsi->vdds_dsi_reg == NULL) {
+   if ((dsi->vdds_dsi_reg == NULL) &&
+   !cpu_is_omap3517() && !cpu_is_omap3505()) {
struct regulator *vdds_dsi;
 
vdds_dsi = regulator_get(&dsi->pdev->dev, "vdds_dsi");
@@ -4799,7 +4804,8 @@ static int omap_dsihw_remove(struct platform_device 
*dsidev)
 
dsi_put_clocks(dsidev);
 
-   if (dsi->vdds_dsi_reg != NULL) {
+   if ((dsi->vdds_dsi_reg != NULL) &&
+   !cpu_is_omap3517() && !cpu_is_omap3505()) {
if (dsi->vdds_dsi_enabled) {
regulator_disable(dsi->vdds_dsi_reg);
dsi->vdds_dsi_enabled = false;
-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/4] omap_dss: add FocalTech ETM070003DH6 display support

2011-11-08 Thread Ilya Yanok
Add data for the FocalTech ETM070003DH6 display to the generic_dpi_panel
display driver.

Signed-off-by: Ilya Yanok 
---
 drivers/video/omap2/displays/panel-generic-dpi.c |   24 ++
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c 
b/drivers/video/omap2/displays/panel-generic-dpi.c
index 519c47d..42bfe47 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -297,6 +297,30 @@ static struct panel_config generic_dpi_panels[] = {
 
.name   = "apollon",
},
+   /* FocalTech ETM070003DH6 */
+   {
+   {
+   .x_res  = 800,
+   .y_res  = 480,
+
+   .pixel_clock= 28000,
+
+   .hsw= 48,
+   .hfp= 40,
+   .hbp= 40,
+
+   .vsw= 3,
+   .vfp= 13,
+   .vbp= 29,
+   },
+   .acbi   = 0x0,
+   .acb= 0x28,
+   .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+ OMAP_DSS_LCD_IHS,
+   .power_on_delay = 50,
+   .power_off_delay= 100,
+   .name   = "focaltech_etm070003dh6",
+   },
 };
 
 struct panel_drv_data {
-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 0/4] Support for the HTKW mcx board

2011-11-08 Thread Ilya Yanok
Hello All,

these patches add support for HTKW mcx board (TI AM3517 based). This
includes fix for the DSS driver to work on 35xx, new panel type support
and some minor cleanup in common dtsi files (not all OMAP3 SoCs have
IVA).

Last patch needs updated mach-types file and relies on EDT touchscreen
driver posted to the linux-input ML:
http://thread.gmane.org/gmane.linux.kernel.input/22356

To boot successfully, these patches have to be applied:
https://lkml.org/lkml/2011/9/30/414
https://lkml.org/lkml/2011/9/30/34

Regards, Ilya.

Signed-off-by: Ilya Yanok 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] AM35xx: disable checking for reserved feature bits

2011-11-08 Thread Ilya Yanok
Bits corresponding to the IVA and ISP features in OMAP_STATUS register
are reserved on AM35xx and checking for them results in wrong results.
So we don't want to check for this features on AM35xx.

Signed-off-by: Ilya Yanok 
---
 arch/arm/mach-omap2/id.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 7f47092..40bab99 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -181,10 +181,8 @@ static void __init omap3_check_features(void)
status = omap_ctrl_readl(OMAP3_CONTROL_OMAP_STATUS);
 
OMAP3_CHECK_FEATURE(status, L2CACHE);
-   OMAP3_CHECK_FEATURE(status, IVA);
OMAP3_CHECK_FEATURE(status, SGX);
OMAP3_CHECK_FEATURE(status, NEON);
-   OMAP3_CHECK_FEATURE(status, ISP);
if (cpu_is_omap3630())
omap_features |= OMAP3_HAS_192MHZ_CLK;
if (cpu_is_omap3430() || cpu_is_omap3630())
@@ -192,6 +190,10 @@ static void __init omap3_check_features(void)
if (cpu_is_omap3630() || omap_rev() == OMAP3430_REV_ES3_1 ||
omap_rev() == OMAP3430_REV_ES3_1_2)
omap_features |= OMAP3_HAS_IO_CHAIN_CTRL;
+   if (!cpu_is_omap3505() && !cpu_is_omap3517()) {
+   OMAP3_CHECK_FEATURE(status, IVA);
+   OMAP3_CHECK_FEATURE(status, ISP);
+   }
 
omap_features |= OMAP3_HAS_SDRC;
 
-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] am35xx: musb: add missing linux/module.h header

2011-11-08 Thread Ilya Yanok
Fix compilation errors by including linux/module.h header.

Signed-off-by: Ilya Yanok 
---
 drivers/usb/musb/am35x.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 08f1d0b6..ea2a258 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] omap-serial: add RS485 mode support

2011-10-02 Thread Ilya Yanok
Add support for asserting RTS line while TX is in progress. OMAP
hardware doesn't support auto-RS485 mode so we control the line from
software. We use TX_EMPTY_CTL_IT bit in SCR register to generate TX
empty interrupt.

We use SER_RS485_RTS_ON_SEND flag to control the polarity of RTS signal
(RTS is asserted high during transmition if this flag is set and low
otherwise) though I'm not sure if this is what this flag is for...

Signed-off-by: Ilya Yanok 
---
 arch/arm/plat-omap/include/plat/omap-serial.h |3 +
 drivers/tty/serial/omap-serial.c  |  127 ++---
 include/linux/serial_reg.h|2 +
 3 files changed, 120 insertions(+), 12 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h 
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 2682043..5003400 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -111,6 +111,9 @@ struct uart_omap_port {
unsigned char   msr_saved_flags;
charname[20];
unsigned long   port_activity;
+   struct serial_rs485 rs485;
+   unsigned inttx_in_progress:1,
+   tx_wait_end:1;
 };
 
 #endif /* __OMAP_SERIAL_H__ */
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 47cadf4..6526171 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -37,11 +37,14 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 
+#define OMAP_RS485_SUPPORTED   (SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND)
+
 static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
 
 /* Forward declaration of functions */
@@ -114,6 +117,45 @@ static void serial_omap_enable_ms(struct uart_port *port)
serial_out(up, UART_IER, up->ier);
 }
 
+static inline void serial_omap_enable_ier_thri(struct uart_omap_port *up)
+{
+   if (!(up->ier & UART_IER_THRI)) {
+   up->ier |= UART_IER_THRI;
+   serial_out(up, UART_IER, up->ier);
+   }
+}
+
+static inline void serial_omap_disable_ier_thri(struct uart_omap_port *up)
+{
+   if (up->ier & UART_IER_THRI) {
+   up->ier &= ~UART_IER_THRI;
+   serial_out(up, UART_IER, up->ier);
+   }
+}
+
+static inline void serial_omap_thri_mode(struct uart_omap_port *up)
+{
+   unsigned char scr = serial_in(up, UART_OMAP_SCR);
+
+   if (up->tx_wait_end)
+   scr |= UART_OMAP_SCR_TX_EMPTY_CTL_IT;
+   else
+   scr &= ~UART_OMAP_SCR_TX_EMPTY_CTL_IT;
+   serial_out(up, UART_OMAP_SCR, scr);
+}
+
+static inline void serial_omap_update_rts(struct uart_omap_port *up)
+{
+   unsigned char mcr = up->mcr;
+   int rts_on_send = up->rs485.flags & SER_RS485_RTS_ON_SEND;
+
+   if ((up->rs485.flags & SER_RS485_ENABLED) &&
+   ((up->tx_in_progress && rts_on_send) ||
+!(up->tx_in_progress || rts_on_send)))
+   mcr |= UART_MCR_RTS;
+   serial_out(up, UART_MCR, mcr);
+}
+
 static void serial_omap_stop_tx(struct uart_port *port)
 {
struct uart_omap_port *up = (struct uart_omap_port *)port;
@@ -131,10 +173,14 @@ static void serial_omap_stop_tx(struct uart_port *port)
up->uart_dma.tx_dma_channel = OMAP_UART_DMA_CH_FREE;
}
 
-   if (up->ier & UART_IER_THRI) {
-   up->ier &= ~UART_IER_THRI;
-   serial_out(up, UART_IER, up->ier);
+   if (!(up->rs485.flags & SER_RS485_ENABLED)) {
+   serial_omap_disable_ier_thri(up);
+   return;
}
+
+   up->tx_wait_end = 1;
+   serial_omap_thri_mode(up);
+   serial_omap_enable_ier_thri(up);
 }
 
 static void serial_omap_stop_rx(struct uart_port *port)
@@ -246,14 +292,6 @@ static void transmit_chars(struct uart_omap_port *up)
serial_omap_stop_tx(&up->port);
 }
 
-static inline void serial_omap_enable_ier_thri(struct uart_omap_port *up)
-{
-   if (!(up->ier & UART_IER_THRI)) {
-   up->ier |= UART_IER_THRI;
-   serial_out(up, UART_IER, up->ier);
-   }
-}
-
 static void serial_omap_start_tx(struct uart_port *port)
 {
struct uart_omap_port *up = (struct uart_omap_port *)port;
@@ -261,6 +299,18 @@ static void serial_omap_start_tx(struct uart_port *port)
unsigned int start;
int ret = 0;
 
+   if (up->rs485.flags & SER_RS485_ENABLED) {
+   if (!up->tx_in_progress) {
+   up->tx_in_progress = 1;
+   serial_omap_update_rts(up);
+   }
+   if (up->tx_wait_end) {
+   up->tx_wait_end = 0;
+   serial_omap_thri_mode(up);
+