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

2011-12-07 Thread Tony Lindgren
* Ilya Yanok ya...@emcraft.com [21 15:46]:
 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.

Well ideally yes we would remove the board files completely eventually.

But that will take a while, so I can carry your board file in testing-board
branch.
 
  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?

Rajendra has posted some regulator DT patches. I believe they have
a dependency to the deferred probe patches in many cases though.

Regards,

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 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


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

2011-11-18 Thread Tony Lindgren
* Ilya Yanok ya...@emcraft.com [14 12:04]:
 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:

Good to hear you're already playing with it. Yes, let's work on making
all the boards work with DT and board-generic..

 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?

Regards,

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 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 4/4] mcx: initial support for HTKW mcx board

2011-11-13 Thread Pankaj Kumar
Hi IIya,

 Support for the HTKW mcx board (TI AM3517 based) including serial,
 Ethernet, I2C, USB host, HSMMC, DSS and RTC.

 Signed-off-by: Ilya Yanok ya...@emcraft.com

 +static struct omap_dss_board_info mcx_dss_data = {
 + .num_devices= ARRAY_SIZE(mcx_dss_devices),
 + .devices= mcx_dss_devices,
 + .default_device = mcx_lcd_device,
 +};
 +
 +static void __init mcx_display_init(void)
 +{
 + int r;
 +
 + /* disable LCD backlight */
 + r = gpio_request(LCD_BKLIGHT_EN, LCD_BKLIGHT_EN);
 + if (r) {
 + printk(KERN_ERR failed to get LCD_BKLIGHT_EN gpio\n);
You should use pr_err macro for error conditions to print, instead of printk.
 + goto err_1;
 + }
 + omap_mux_init_gpio(LCD_BKLIGHT_EN, OMAP_PIN_OUTPUT);
 + gpio_direction_output(LCD_BKLIGHT_EN, 0);
 +
 + /* Enable VIO- 3.3v level shifter */
 + r = gpio_request(LCD_LVL_SFHT_BUF_ENn, LCD_LVL_SFHT_BUF_ENn);
 + if (r) {
 + printk(KERN_ERR failed to get LCD_LVL_SFHT_BUF_ENn gpio\n);

Same here. Deprecate the use of printk for error printing.
 + goto err_2;
 + }
 + omap_mux_init_gpio(LCD_LVL_SFHT_BUF_ENn, OMAP_PIN_OUTPUT);
 + gpio_direction_output(LCD_LVL_SFHT_BUF_ENn, 0);
 +
 + /* Enable LCD panel VCC */
 +
 + r = gpio_request(LCD_PWR_ENn, LCD_PWR_ENn);
 + if (r) {
 + printk(KERN_ERR failed to get LCD_PWR_ENn\n);
Same Here.
 + goto err_3;
 + }
 + omap_mux_init_gpio(LCD_PWR_ENn, OMAP_PIN_OUTPUT);
 +
 + gpio_direction_output(LCD_PWR_ENn, 0);
 +
 + /* Disable HDMI transceiver */
 + r = gpio_request(HDMI_TRCVR_PDn, HDMI_TRCVR_PDn);
 + if (r) {
 + printk(KERN_ERR failed to get HDMI_TRCVR_PDn\n);
Same Here.
 + goto err_4;
 + }
 + omap_mux_init_gpio(HDMI_TRCVR_PDn, OMAP_PIN_OUTPUT);
 + gpio_direction_output(HDMI_TRCVR_PDn, 0);
 +
 + omap_display_init(mcx_dss_data);
 +
 + return;
 +
 +err_4:
 + gpio_free(HDMI_TRCVR_PDn);
 +err_3:
 + gpio_free(LCD_LVL_SFHT_BUF_ENn);
 +err_2:
 + gpio_free(LCD_LVL_SFHT_BUF_ENn);
 +err_1:
 + gpio_free(LCD_BKLIGHT_EN);
 +}
 +
 +/* TPS65023 specific initialization */
 +/* VDCDC1 - VDD_CORE */
 +static struct regulator_consumer_supply am3517_vdcdc1_supplies[] = {
 + {
 + .supply = vdd_core,
 + },
 +};
 +
 +/* VDCDC2 - VDDSHV */
 +static struct regulator_consumer_supply am3517_vdcdc2_supplies[] = {
 + {
 + .supply = vddshv,
 + },
 +};
 +
 +/*
 + * VDCDC2 |- VDDS
 + * |- VDDS_SRAM_CORE_BG
 + * |- VDDS_SRAM_MPU
 + */
 +static struct regulator_consumer_supply am3517_vdcdc3_supplies[] = {
 + {
 + .supply = vdds,
 + },
 + {
 + .supply = vdds_sram_core_bg,
 + },
 + {
 + .supply = vdds_sram_mpu,
 + },
 +};
 +
 +/*
 + * LDO1 |- VDDA1P8V_USBPHY
 + *   |- VDDA_DAC
 + */
 +static struct regulator_consumer_supply am3517_ldo1_supplies[] = {
 + {
 + .supply = vdda1p8v_usbphy,
 + },
 + {
 + .supply = vdda_dac,
 + },
 +};
 +
 +/* LDO2 - VDDA3P3V_USBPHY */
 +static struct regulator_consumer_supply am3517_ldo2_supplies[] = {
 + {
 + .supply = vdda3p3v_usbphy,
 + },
 +};
 +
 +static struct regulator_init_data mcx_regulator_data[] = {
 + /* DCDC1 */
 + {
 + .constraints = {
 + .min_uV = 120,
 + .max_uV = 120,
 + .valid_modes_mask = REGULATOR_MODE_NORMAL,
 + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
 + .always_on = true,
 + .apply_uV = false,
 + },
 + .num_consumer_supplies = ARRAY_SIZE(am3517_vdcdc1_supplies),
 + .consumer_supplies = am3517_vdcdc1_supplies,
 + },
 + /* DCDC2 */
 + {
 + .constraints = {
 + .min_uV = 330,
 + .max_uV = 330,
 + .valid_modes_mask = REGULATOR_MODE_NORMAL,
 + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
 + .always_on = true,
 + .apply_uV = false,
 + },
 + .num_consumer_supplies = ARRAY_SIZE(am3517_vdcdc2_supplies),
 + .consumer_supplies = am3517_vdcdc2_supplies,
 + },
 + /* DCDC3 */
 + {
 + .constraints = {
 + .min_uV = 180,
 + .max_uV = 180,
 + .valid_modes_mask = REGULATOR_MODE_NORMAL,
 + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
 + .always_on = true,
 + .apply_uV = false,
 + },
 + .num_consumer_supplies = ARRAY_SIZE(am3517_vdcdc3_supplies),
 + .consumer_supplies = am3517_vdcdc3_supplies,
 + },
 + /* LDO1 */
 + {
 + .constraints = {
 + 

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

2011-11-10 Thread Igor Grinberg
Hi Ilya,

On 11/09/11 02:12, Ilya Yanok wrote:
 Support for the HTKW mcx board (TI AM3517 based) including serial,
 Ethernet, I2C, USB host, HSMMC, DSS and RTC.
 
 Signed-off-by: Ilya Yanok ya...@emcraft.com
 ---
  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

I have no problem with that, but is this really how you want
the config option to be displayed?

 + 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 \

This one is always compiled in, so you don't need to specify it
(see a couple of lines below in the file)

 +hsmmc.o

This one is compiled in when CONFIG_MMC_OMAP_HS symbol
enabled, so you don't need to specify this one either.

  
  # 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 linux/kernel.h
 +#include linux/init.h
 +#include linux/platform_device.h
 +#include linux/delay.h
 +#include linux/err.h
 +#include linux/clk.h
 +#include linux/io.h
 +#include linux/leds.h
 +#include linux/gpio.h
 +#include linux/input.h
 +#include linux/gpio_keys.h
 +#include linux/opp.h
 +
 +#include linux/mtd/mtd.h
 +#include linux/mtd/partitions.h
 +#include linux/mtd/nand.h
 +#include linux/mmc/host.h
 +
 +#include linux/regulator/machine.h
 +#include linux/davinci_emac.h
 +#include linux/i2c/edt_ts.h
 +
 +#include mach/hardware.h
 +#include mach/am35xx.h
 +#include asm/mach-types.h
 +#include asm/mach/arch.h
 +#include asm/mach/map.h
 +#include asm/mach/flash.h
 +
 +#include plat/board.h
 +#include plat/common.h
 +#include plat/omap_hwmod.h
 +#include video/omapdss.h
 +#include video/omap-panel-generic-dpi.h
 +#include plat/gpmc.h
 +#include plat/nand.h
 +#include plat/usb.h
 +#include plat/omap_device.h
 +
 +#include mux.h
 +#include control.h
 +#include hsmmc.h
 +#include common-board-devices.h

I bet, you don't use and don't need all the includes above...
Can it be reduced to the really needed ones?

 +
 +#define MCX_MDIO_FREQUENCY   (100)
 +
 +static struct mdio_platform_data mcx_mdio_pdata = {
 + .bus_freq   = MCX_MDIO_FREQUENCY,
 +};
 +
 +static struct resource am3517_mdio_resources[] = {
 + {
 + 

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

2011-11-10 Thread Tony Lindgren
* Ilya Yanok ya...@emcraft.com [08 15:38]:
 Support for the HTKW mcx board (TI AM3517 based) including serial,
 Ethernet, I2C, USB host, HSMMC, DSS and RTC.
 
 Signed-off-by: Ilya Yanok ya...@emcraft.com
 ---
  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 
 ++

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?

Thanks,

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