date:20110325

On Thu, Mar 24, 2011 at 1:00 AM, Kevin Hilman khil...@ti.com wrote:
 This series is the begining of a voltage layer cleanup and restruture
 with the primary goal of splitting up voltage domain, voltage
 processor (VP) and voltage controller (VC) code.
It would be nice to give a bit more detail on what are the VD, VP 
VC. This would help to understand the split/restructure.


 The RFC part is for the last 3 patches in the series, and for
 discussion of how/if to split out the SoC specifics.  As an example, I
 started on the VC and split out some functionality (setting slave i2c
 addr, setting PMIC register addresses) into hooks that can be
 implemented in SoC specific code.  I'd appreciate any input on this
 approach as well as the types of functions/APIs that should exist at
 this level.

 Boot tested on 2420/n810, 3630/zoom3 and 4430/panda.

 This series applies to my current pm-core branch.

 Also, there are known checkpatch/whitespace problems in this series,
 and that's OK for now.  That will all eventually be cleaned up as
 well.
A few typos also...

Jean


 Kevin



 Benoit Cousson (1):
  OMAP4: powerdomain data: add voltage domains

 Kevin Hilman (18):
  OMAP2+: hwmod: remove unused voltagedomain pointer
  OMAP2+: voltage: move PRCM mod offets into VC/VP structures
  OMAP2+: voltage: move prm_irqst_reg from VP into voltage domain
  OMAP2+: voltage: start towards a new voltagedomain layer
  OMAP3: voltage: rename mpu voltagedomain to mpu_iva
  OMAP3: voltagedomain data: add wakeup domain
  OMAP3: voltage: add scalable flag to voltagedomain
  OMAP2+: powerdomain: add voltagedomain to struct powerdomain
  OMAP2: add voltage domains and connect to powerdomains
  OMAP3: powerdomain data: add voltage domains
  OMAP2+: powerdomain: add voltage domain lookup during register
  OMAP2+: voltage: keep track of powerdomains in each voltagedomain
  OMAP2+: voltage: split voltage controller (VC) code into dedicated
    layer
  OMAP2+: voltage: move VC into struct voltagedomain, misc. renames
  OMAP2+: voltage: split out voltage processor (VP) code into new layer
  OMAP2+: voltage: VC: begin spliting out SoC specifics; start with i2c
    slave addr
  OMAP2+: VC: support PMICs with separate voltage and command registers
  OMAP2+: VC: add SoC-specific op for PMIC register addresses

  arch/arm/mach-omap2/Makefile                     |   10 +-
  arch/arm/mach-omap2/io.c                         |    5 +
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c       |    4 +-
  arch/arm/mach-omap2/omap_twl.c                   |   20 +-
  arch/arm/mach-omap2/pm.c                         |    4 +-
  arch/arm/mach-omap2/powerdomain.c                |   23 +
  arch/arm/mach-omap2/powerdomain.h                |   10 +
  arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c |    2 +
  arch/arm/mach-omap2/powerdomains2xxx_data.c      |    4 +
  arch/arm/mach-omap2/powerdomains3xxx_data.c      |   16 +
  arch/arm/mach-omap2/powerdomains44xx_data.c      |   18 +-
  arch/arm/mach-omap2/sr_device.c                  |    2 +-
  arch/arm/mach-omap2/vc.c                         |  265 +++
  arch/arm/mach-omap2/vc.h                         |   67 ++-
  arch/arm/mach-omap2/vc3xxx.c                     |   73 ++
  arch/arm/mach-omap2/vc3xxx_data.c                |   21 +-
  arch/arm/mach-omap2/vc44xx.c                     |   73 ++
  arch/arm/mach-omap2/vc44xx_data.c                |   30 +-
  arch/arm/mach-omap2/voltage.c                    |  856 
 +-
  arch/arm/mach-omap2/voltage.h                    |   60 +-
  arch/arm/mach-omap2/voltagedomains2xxx_data.c    |   33 +
  arch/arm/mach-omap2/voltagedomains3xxx_data.c    |   51 +-
  arch/arm/mach-omap2/voltagedomains44xx_data.c    |   58 +-
  arch/arm/mach-omap2/vp.c                         |  374 ++
  arch/arm/mach-omap2/vp.h                         |   14 +-
  arch/arm/mach-omap2/vp3xxx_data.c                |    3 +-
  arch/arm/mach-omap2/vp44xx_data.c                |    4 +-
  arch/arm/plat-omap/include/plat/omap_hwmod.h     |    1 -
  28 files changed, 1280 insertions(+), 821 deletions(-)
  create mode 100644 arch/arm/mach-omap2/vc.c
  create mode 100644 arch/arm/mach-omap2/vc3xxx.c
  create mode 100644 arch/arm/mach-omap2/vc44xx.c
  create mode 100644 arch/arm/mach-omap2/voltagedomains2xxx_data.c
  create mode 100644 arch/arm/mach-omap2/vp.c

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

--
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/RFC 01/19] OMAP2+: hwmod: remove unused voltagedomain pointer

On Thu, Mar 24, 2011 at 1:00 AM, Kevin Hilman khil...@ti.com wrote:
 The voltage domain pointer currently in struct omap_hwmod is not used
 and does not belong here.  Instead, voltage domains will be associated
Extra space

 with powerdomains in forthcoming patches.

 Acked-by: Paul Walmsley p...@pwsan.com
 Signed-off-by: Kevin Hilman khil...@ti.com
 ---
  arch/arm/plat-omap/include/plat/omap_hwmod.h |    1 -
  1 files changed, 0 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h 
 b/arch/arm/plat-omap/include/plat/omap_hwmod.h
 index 1adea9c..a5fa7c1 100644
 --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
 +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
 @@ -520,7 +520,6 @@ struct omap_hwmod {
        struct clk                      *_clk;
        struct omap_hwmod_opt_clk       *opt_clks;
        char                            *vdd_name;
 -       struct voltagedomain            *voltdm;
        struct omap_hwmod_ocp_if        **masters; /* connect to *_IA */
        struct omap_hwmod_ocp_if        **slaves;  /* connect to *_TA */
        void                            *dev_attr;
 --
 1.7.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

--
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/RFC 04/19] OMAP2+: voltage: start towards a new voltagedomain layer

On Thu, Mar 24, 2011 at 1:00 AM, Kevin Hilman khil...@ti.com wrote:
 Start cleaning up the voltage layer to have a voltage domain layer
 that resembles thae structure of the existing clock and power domain
s/thae/the

 layers.  To that end:
Extra space


 - move the 'struct voltagedomain' out of 'struct omap_vdd_info' to
  become the primary data structure.

 - convert any functions taking a pointer to struct omap_vdd_info into
  functions taking a struct voltagedomain pointer.

 - convert the register  initialize of voltage domains to look like
  that of powerdomains

 - convert omap_voltage_domain_lookup() to voltdm_lookup(), modeled
  after the current powerdomain and clockdomain lookup functions.

 - omap_voltage_late_init(): only configure VDD info when
  the vdd_info struct is non-NULL

 Signed-off-by: Kevin Hilman khil...@ti.com
 ---
  arch/arm/mach-omap2/io.c                      |    3 +
  arch/arm/mach-omap2/omap_twl.c                |   10 +-
  arch/arm/mach-omap2/pm.c                      |    2 +-
  arch/arm/mach-omap2/sr_device.c               |    2 +-
  arch/arm/mach-omap2/voltage.c                 |  257 
 ++---
  arch/arm/mach-omap2/voltage.h                 |   27 ++--
  arch/arm/mach-omap2/voltagedomains3xxx_data.c |   34 ++--
  arch/arm/mach-omap2/voltagedomains44xx_data.c |   44 ++--
  8 files changed, 207 insertions(+), 172 deletions(-)

 diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
 index 441e79d..44c2c3e 100644
 --- a/arch/arm/mach-omap2/io.c
 +++ b/arch/arm/mach-omap2/io.c
 @@ -38,6 +38,7 @@
  #include io.h

  #include plat/omap-pm.h
 +#include voltage.h
  #include powerdomain.h

  #include clockdomain.h
 @@ -363,10 +364,12 @@ void __init omap2_init_common_infrastructure(void)
                omap2xxx_clockdomains_init();
                omap2430_hwmod_init();
        } else if (cpu_is_omap34xx()) {
 +               omap3xxx_voltagedomains_init();
                omap3xxx_powerdomains_init();
                omap3xxx_clockdomains_init();
                omap3xxx_hwmod_init();
        } else if (cpu_is_omap44xx()) {
 +               omap44xx_voltagedomains_init();
                omap44xx_powerdomains_init();
                omap44xx_clockdomains_init();
                omap44xx_hwmod_init();
 diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
 index 0a8e74e..287aef2 100644
 --- a/arch/arm/mach-omap2/omap_twl.c
 +++ b/arch/arm/mach-omap2/omap_twl.c
 @@ -250,13 +250,13 @@ int __init omap4_twl_init(void)
        if (!cpu_is_omap44xx())
                return -ENODEV;

 -       voltdm = omap_voltage_domain_lookup(mpu);
 +       voltdm = voltdm_lookup(mpu);
        omap_voltage_register_pmic(voltdm, omap4_mpu_volt_info);

 -       voltdm = omap_voltage_domain_lookup(iva);
 +       voltdm = voltdm_lookup(iva);
        omap_voltage_register_pmic(voltdm, omap4_iva_volt_info);

 -       voltdm = omap_voltage_domain_lookup(core);
 +       voltdm = voltdm_lookup(core);
        omap_voltage_register_pmic(voltdm, omap4_core_volt_info);

        return 0;
 @@ -288,10 +288,10 @@ int __init omap3_twl_init(void)
        if (!twl_sr_enable_autoinit)
                omap3_twl_set_sr_bit(true);

 -       voltdm = omap_voltage_domain_lookup(mpu);
 +       voltdm = voltdm_lookup(mpu);
        omap_voltage_register_pmic(voltdm, omap3_mpu_volt_info);

 -       voltdm = omap_voltage_domain_lookup(core);
 +       voltdm = voltdm_lookup(core);
        omap_voltage_register_pmic(voltdm, omap3_core_volt_info);

        return 0;
 diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
 index 49486f5..917e1e3 100644
 --- a/arch/arm/mach-omap2/pm.c
 +++ b/arch/arm/mach-omap2/pm.c
 @@ -181,7 +181,7 @@ static int __init omap2_set_init_voltage(char *vdd_name, 
 char *clk_name,
                goto exit;
        }

 -       voltdm = omap_voltage_domain_lookup(vdd_name);
 +       voltdm = voltdm_lookup(vdd_name);
        if (IS_ERR(voltdm)) {
                printk(KERN_ERR %s: Unable to get vdd pointer for vdd_%s\n,
                        __func__, vdd_name);
 diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
 index 10d3c5e..2782d3f 100644
 --- a/arch/arm/mach-omap2/sr_device.c
 +++ b/arch/arm/mach-omap2/sr_device.c
 @@ -102,7 +102,7 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user)
        sr_data-senn_mod = 0x1;
        sr_data-senp_mod = 0x1;

 -       sr_data-voltdm = omap_voltage_domain_lookup(oh-vdd_name);
 +       sr_data-voltdm = voltdm_lookup(oh-vdd_name);
        if (IS_ERR(sr_data-voltdm)) {
                pr_err(%s: Unable to get voltage domain pointer for VDD %s\n,
                        __func__, oh-vdd_name);
 diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
 index 15a9cb8..f995003 100644
 --- a/arch/arm/mach-omap2/voltage.c
 +++ b/arch/arm/mach-omap2/voltage.c
 @@ -40,20 +40,13 @@
  #include vc.h
  #include vp.h

 -#define VOLTAGE_DIR_SIZE       16
 -
 -

Re: [PATCH/RFC 10/19] OMAP3: powerdomain data: add voltage domains

On Thu, Mar 24, 2011 at 1:00 AM, Kevin Hilman khil...@ti.com wrote:
 Add voltage domain name to indicate which voltagedomain each
 powerdomain is in.  A missing voltage domain name means that that
 powerdomain is not in one of the currently scalable voltage domains.
Is that the role of the 'scalable' flag? Why not fill in all
powerdomain structs and set the flag on scalable VDs only?


 Signed-off-by: Kevin Hilman khil...@ti.com
 ---
  arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c |    2 ++
  arch/arm/mach-omap2/powerdomains3xxx_data.c      |   16 
  2 files changed, 18 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c 
 b/arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c
 index 4210c33..45aa4b7 100644
 --- a/arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c
 +++ b/arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c
 @@ -70,6 +70,7 @@ struct powerdomain gfx_omap2_pwrdm = {
        .pwrsts_mem_on    = {
                [0] = PWRSTS_ON,  /* MEMONSTATE */
        },
 +       .voltdm           = { .name = core },
  };

  struct powerdomain wkup_omap2_pwrdm = {
 @@ -77,4 +78,5 @@ struct powerdomain wkup_omap2_pwrdm = {
        .prcm_offs      = WKUP_MOD,
        .omap_chip      = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX | CHIP_IS_OMAP3430),
        .pwrsts         = PWRSTS_ON,
 +       .voltdm         = { .name = wkup },
  };
 diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c 
 b/arch/arm/mach-omap2/powerdomains3xxx_data.c
 index 9c9c113..09bdfcf 100644
 --- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
 +++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
 @@ -52,6 +52,7 @@ static struct powerdomain iva2_pwrdm = {
                [2] = PWRSTS_OFF_ON,
                [3] = PWRSTS_ON,
        },
 +       .voltdm           = { .name = mpu_iva },
  };

  static struct powerdomain mpu_3xxx_pwrdm = {
 @@ -68,6 +69,7 @@ static struct powerdomain mpu_3xxx_pwrdm = {
        .pwrsts_mem_on    = {
                [0] = PWRSTS_OFF_ON,
        },
 +       .voltdm           = { .name = mpu_iva },
  };

  /*
 @@ -98,6 +100,7 @@ static struct powerdomain core_3xxx_pre_es3_1_pwrdm = {
                [0] = PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */
                [1] = PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */
        },
 +       .voltdm           = { .name = core },
  };

  static struct powerdomain core_3xxx_es3_1_pwrdm = {
 @@ -121,6 +124,7 @@ static struct powerdomain core_3xxx_es3_1_pwrdm = {
                [0] = PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */
                [1] = PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */
        },
 +       .voltdm           = { .name = core },
  };

  static struct powerdomain dss_pwrdm = {
 @@ -136,6 +140,7 @@ static struct powerdomain dss_pwrdm = {
        .pwrsts_mem_on    = {
                [0] = PWRSTS_ON,  /* MEMONSTATE */
        },
 +       .voltdm           = { .name = core },
  };

  /*
 @@ -157,6 +162,7 @@ static struct powerdomain sgx_pwrdm = {
        .pwrsts_mem_on    = {
                [0] = PWRSTS_ON,  /* MEMONSTATE */
        },
 +       .voltdm           = { .name = core },
  };

  static struct powerdomain cam_pwrdm = {
 @@ -172,6 +178,7 @@ static struct powerdomain cam_pwrdm = {
        .pwrsts_mem_on    = {
                [0] = PWRSTS_ON,  /* MEMONSTATE */
        },
 +       .voltdm           = { .name = core },
  };

  static struct powerdomain per_pwrdm = {
 @@ -187,12 +194,14 @@ static struct powerdomain per_pwrdm = {
        .pwrsts_mem_on    = {
                [0] = PWRSTS_ON,  /* MEMONSTATE */
        },
 +       .voltdm           = { .name = core },
  };

  static struct powerdomain emu_pwrdm = {
        .name           = emu_pwrdm,
        .prcm_offs      = OMAP3430_EMU_MOD,
        .omap_chip      = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
 +       .voltdm           = { .name = core },
  };

  static struct powerdomain neon_pwrdm = {
 @@ -201,6 +210,7 @@ static struct powerdomain neon_pwrdm = {
        .omap_chip        = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
        .pwrsts           = PWRSTS_OFF_RET_ON,
        .pwrsts_logic_ret = PWRSTS_RET,
 +       .voltdm           = { .name = mpu_iva },
  };

  static struct powerdomain usbhost_pwrdm = {
 @@ -223,36 +233,42 @@ static struct powerdomain usbhost_pwrdm = {
        .pwrsts_mem_on    = {
                [0] = PWRSTS_ON,  /* MEMONSTATE */
        },
 +       .voltdm           = { .name = core },
  };

  static struct powerdomain dpll1_pwrdm = {
        .name           = dpll1_pwrdm,
        .prcm_offs      = MPU_MOD,
        .omap_chip      = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
 +       .voltdm           = { .name = mpu_iva },
  };

  static struct powerdomain dpll2_pwrdm = {
        .name           = dpll2_pwrdm,
        .prcm_offs      = OMAP3430_IVA2_MOD,
        .omap_chip      = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
 +       .voltdm           = { .name = mpu_iva },
  };

  static struct powerdomain dpll3_pwrdm = {
        .name           = dpll3_pwrdm,
        .prcm_offs      =

Re: [PATCH/RFC 12/19] OMAP2+: powerdomain: add voltage domain lookup during register

On Thu, Mar 24, 2011 at 1:00 AM, Kevin Hilman khil...@ti.com wrote:
 When a powerdomain is registered, lookup the voltage domain by name
 and keep a pointer to the containing voltagedomain in the powerdomain
 structure.

 Modeled after similar method between powerdomain and clockdomain layers.

 Signed-off-by: Kevin Hilman khil...@ti.com
 ---
  arch/arm/mach-omap2/powerdomain.c |   21 +
  arch/arm/mach-omap2/powerdomain.h |    1 +
  arch/arm/mach-omap2/voltage.h     |    1 +
  3 files changed, 23 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/powerdomain.c 
 b/arch/arm/mach-omap2/powerdomain.c
 index 49c6513..8fccd4b 100644
 --- a/arch/arm/mach-omap2/powerdomain.c
 +++ b/arch/arm/mach-omap2/powerdomain.c
 @@ -77,6 +77,7 @@ static struct powerdomain *_pwrdm_lookup(const char *name)
  static int _pwrdm_register(struct powerdomain *pwrdm)
  {
        int i;
 +       struct voltagedomain *voltdm;

        if (!pwrdm || !pwrdm-name)
                return -EINVAL;
 @@ -94,6 +95,14 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
        if (_pwrdm_lookup(pwrdm-name))
                return -EEXIST;

 +       voltdm = voltdm_lookup(pwrdm-voltdm.name);
 +       if (!voltdm) {
 +               pr_err(powerdomain: %s: voltagedomain %s does not exist\n,
 +                      pwrdm-name, pwrdm-voltdm.name);
 +               return -EINVAL;
Per patch 10/19 some power domains do not have an associated voltage
domain struct filled in. This will result in failure of the power
domain registration. I think this is not expected.

 +       }
 +       pwrdm-voltdm.ptr = voltdm;
 +
        list_add(pwrdm-node, pwrdm_list);

        /* Initialize the powerdomain's state counter */
 @@ -383,6 +392,18 @@ int pwrdm_for_each_clkdm(struct powerdomain *pwrdm,
  }

  /**
 + * pwrdm_get_voltdm - return a ptr to the voltdm that this pwrdm resides in
 + * @pwrdm: struct powerdomain *
 + *
 + * Return a pointer to the struct voltageomain that the specified powerdomain
 + * @pwrdm exists in.
 + */
 +struct voltagedomain *pwrdm_get_voltdm(struct powerdomain *pwrdm)
 +{
 +       return pwrdm-voltdm.ptr;
 +}
 +
 +/**
  * pwrdm_get_mem_bank_count - get number of memory banks in this powerdomain
  * @pwrdm: struct powerdomain *
  *
 diff --git a/arch/arm/mach-omap2/powerdomain.h 
 b/arch/arm/mach-omap2/powerdomain.h
 index cc03a0d..3a1ec37 100644
 --- a/arch/arm/mach-omap2/powerdomain.h
 +++ b/arch/arm/mach-omap2/powerdomain.h
 @@ -183,6 +183,7 @@ int pwrdm_del_clkdm(struct powerdomain *pwrdm, struct 
 clockdomain *clkdm);
  int pwrdm_for_each_clkdm(struct powerdomain *pwrdm,
                         int (*fn)(struct powerdomain *pwrdm,
                                   struct clockdomain *clkdm));
 +struct voltagedomain *pwrdm_get_voltdm(struct powerdomain *pwrdm);

  int pwrdm_get_mem_bank_count(struct powerdomain *pwrdm);

 diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
 index cacd76e..966aa88 100644
 --- a/arch/arm/mach-omap2/voltage.h
 +++ b/arch/arm/mach-omap2/voltage.h
 @@ -186,4 +186,5 @@ extern void omap44xx_voltagedomains_init(void);

  struct voltagedomain *voltdm_lookup(const char *name);
  void voltdm_init(struct voltagedomain **voltdm_list);
 +int voltdm_add_pwrdm(struct voltagedomain *voltdm, struct powerdomain 
 *pwrdm);
  #endif
 --
 1.7.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

--
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/RFC 13/19] OMAP2+: voltage: keep track of powerdomains in each voltagedomain

On Thu, Mar 24, 2011 at 1:00 AM, Kevin Hilman khil...@ti.com wrote:
 When a powerdomain is registered and it has an associated voltage domain,
 add the powerdomain to the voltagedomain using voltdm_add_pwrdm().

 Also add voltagedomain iterator helper functions to iterate over all
 registered voltagedomains and all powerdomains associated with a
 voltagedomain.

 Modeled after a similar relationship between clockdomains and powerdomains.

 Signed-off-by: Kevin Hilman khil...@ti.com
 ---
  arch/arm/mach-omap2/powerdomain.c |    2 +
  arch/arm/mach-omap2/powerdomain.h |    2 +
  arch/arm/mach-omap2/voltage.c     |   80 
 +
  arch/arm/mach-omap2/voltage.h     |   15 +++
  4 files changed, 99 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/powerdomain.c 
 b/arch/arm/mach-omap2/powerdomain.c
 index 8fccd4b..224272e 100644
 --- a/arch/arm/mach-omap2/powerdomain.c
 +++ b/arch/arm/mach-omap2/powerdomain.c
 @@ -102,6 +102,8 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
                return -EINVAL;
        }
        pwrdm-voltdm.ptr = voltdm;
 +       INIT_LIST_HEAD(pwrdm-voltdm_node);
 +       voltdm_add_pwrdm(voltdm, pwrdm);

        list_add(pwrdm-node, pwrdm_list);

 diff --git a/arch/arm/mach-omap2/powerdomain.h 
 b/arch/arm/mach-omap2/powerdomain.h
 index 3a1ec37..6a4f71a 100644
 --- a/arch/arm/mach-omap2/powerdomain.h
 +++ b/arch/arm/mach-omap2/powerdomain.h
 @@ -92,6 +92,7 @@ struct powerdomain;
  * @pwrsts_mem_on: Possible memory bank pwrstates when pwrdm in ON
  * @pwrdm_clkdms: Clockdomains in this powerdomain
  * @node: list_head linking all powerdomains
 + * @voltdm_node: list_head linking all powerdomains in a voltagedomain
  * @state:
  * @state_counter:
  * @timer:
 @@ -116,6 +117,7 @@ struct powerdomain {
        const u8 prcm_partition;
        struct clockdomain *pwrdm_clkdms[PWRDM_MAX_CLKDMS];
        struct list_head node;
 +       struct list_head voltdm_node;
        int state;
        unsigned state_counter[PWRDM_MAX_PWRSTS];
        unsigned ret_logic_off_counter;
 diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
 index bc944ff..b1b5e38 100644
 --- a/arch/arm/mach-omap2/voltage.c
 +++ b/arch/arm/mach-omap2/voltage.c
 @@ -36,6 +36,7 @@
  #include control.h

  #include voltage.h
 +#include powerdomain.h

  #include vc.h
  #include vp.h
 @@ -1085,11 +1086,90 @@ static struct voltagedomain *_voltdm_lookup(const 
 char *name)
        return voltdm;
  }

 +/**
 + * voltdm_add_pwrdm - add a powerdomain to a voltagedomain
 + * @voltdm: struct voltagedomain * to add the powerdomain to
 + * @pwrdm: struct powerdomain * to associate with a voltagedomain
 + *
 + * Associate the powerdomain @pwrdm with a voltagedomain @voltdm.  This
 + * enables the use of voltdm_for_each_pwrdm().  Returns -EINVAL if
 + * presented with invalid pointers; -ENOMEM if memory could not be allocated;
 + * or 0 upon success.
 + */
 +int voltdm_add_pwrdm(struct voltagedomain *voltdm, struct powerdomain *pwrdm)
 +{
 +       if (!voltdm || !pwrdm)
 +               return -EINVAL;
 +
 +       pr_debug(voltagedomain: associating powerdomain %s with 
 voltagedomain 
 +                %s\n, pwrdm-name, voltdm-name);
 +
 +       list_add(pwrdm-voltdm_node, voltdm-pwrdm_list);
 +
 +       return 0;
 +}
 +
 +/**
 + * voltdm_for_each_pwrdm - call function for each pwrdm in a voltdm
 + * @voltdm: struct voltagedomain * to iterate over
 + * @fn: callback function *
 + *
 + * Call the supplied function @fn for each powerdomain in the
 + * voltagedomain @voltdm.  Returns -EINVAL if presented with invalid
 + * pointers; or passes along the last return value of the callback
 + * function, which should be 0 for success or anything else to
 + * indicate failure.
 + */
 +int voltdm_for_each_pwrdm(struct voltagedomain *voltdm,
 +                         int (*fn)(struct voltagedomain *voltdm,
 +                                   struct powerdomain *pwrdm))
 +{
 +       struct powerdomain *pwrdm;
 +       int ret = 0;
 +
 +       if (!fn)
 +               return -EINVAL;
 +
 +       list_for_each_entry(pwrdm, voltdm-pwrdm_list, voltdm_node)
 +               ret = (*fn)(voltdm, pwrdm);
 +
 +       return ret;
 +}
 +
 +/**
 + * voltdm_for_each - call function on each registered voltagedomain
 + * @fn: callback function *
 + *
 + * Call the supplied function @fn for each registered voltagedomain.
 + * The callback function @fn can return anything but 0 to bail out
 + * early from the iterator.  Returns the last return value of the
 + * callback function, which should be 0 for success or anything else
 + * to indicate failure; or -EINVAL if the function pointer is null.
The function description does not match the prototype.

 + */
 +int voltdm_for_each(int (*fn)(struct voltagedomain *voltdm, void *user),
 +                   void *user)
 +{
 +       struct voltagedomain *temp_voltdm;
 +       int ret = 0;
 +
 +       if (!fn)
 +               return

Re: [PATCH/RFC 14/19] OMAP2+: voltage: split voltage controller (VC) code into dedicated layer

On Thu, Mar 24, 2011 at 1:00 AM, Kevin Hilman khil...@ti.com wrote:
 As part of the voltage layer cleanup, split out VC specific code into
 a dedicated VC layer.  This patch primarily just moves VC code from
 voltage.c into vc.c, and adds prototypes to vc.h.

 No functional changes.

 For readability, cach function was given a local 'vc' pointer:
s/cach/each


    struct omap_vc_instance_data *vc = voltdm-vdd-vc_data;

 and a global replace of s/vdd-vc_data/vc/ was done.

 Signed-off-by: Kevin Hilman khil...@ti.com
 ---
  arch/arm/mach-omap2/Makefile  |    2 +-
  arch/arm/mach-omap2/vc.c      |  276 
 +
  arch/arm/mach-omap2/vc.h      |   12 ++
  arch/arm/mach-omap2/voltage.c |  262 +--
  4 files changed, 292 insertions(+), 260 deletions(-)
  create mode 100644 arch/arm/mach-omap2/vc.c

 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
 index ce2105c..a0d8f61 100644
 --- a/arch/arm/mach-omap2/Makefile
 +++ b/arch/arm/mach-omap2/Makefile
 @@ -90,7 +90,7 @@ obj-$(CONFIG_ARCH_OMAP4)              += prcm.o 
 cm2xxx_3xxx.o cminst44xx.o \

  # OMAP voltage domains
  ifeq ($(CONFIG_PM),y)
 -voltagedomain-common                   := voltage.o
 +voltagedomain-common                   := voltage.o vc.o
  obj-$(CONFIG_ARCH_OMAP2)               += $(voltagedomain-common) \
                                           voltagedomains2xxx_data.o
  obj-$(CONFIG_ARCH_OMAP3)               += $(voltagedomain-common) \
 diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
 new file mode 100644
 index 000..4e65fdc
 --- /dev/null
 +++ b/arch/arm/mach-omap2/vc.c
 @@ -0,0 +1,276 @@
 +#include linux/kernel.h
 +#include linux/delay.h
 +#include linux/init.h
 +
 +#include plat/cpu.h
 +
 +#include voltage.h
 +#include vc.h
 +#include prm-regbits-34xx.h
 +#include prm-regbits-44xx.h
 +#include prm44xx.h
 +
 +/* Voltage scale and accessory APIs */
 +int omap_vc_pre_scale(struct voltagedomain *voltdm,
 +                     unsigned long target_volt,
 +                     u8 *target_vsel, u8 *current_vsel)
 +{
 +       struct omap_vc_instance_data *vc = voltdm-vdd-vc_data;
 +       struct omap_vdd_info *vdd = voltdm-vdd;
 +       struct omap_volt_data *volt_data;
 +       const struct omap_vc_common_data *vc_common;
 +       const struct omap_vp_common_data *vp_common;
 +       u32 vc_cmdval, vp_errgain_val;
 +
 +       vc_common = vc-vc_common;
 +       vp_common = vdd-vp_data-vp_common;
 +
 +       /* Check if suffiecient pmic info is available for this vdd */
Typo

 +       if (!vdd-pmic_info) {
 +               pr_err(%s: Insufficient pmic info to scale the vdd_%s\n,
 +                       __func__, voltdm-name);
 +               return -EINVAL;
 +       }
 +
 +       if (!vdd-pmic_info-uv_to_vsel) {
 +               pr_err(%s: PMIC function to convert voltage in uV to
 +                       vsel not registered. Hence unable to scale voltage
 +                       for vdd_%s\n, __func__, voltdm-name);
 +               return -ENODATA;
 +       }
 +
 +       if (!vdd-read_reg || !vdd-write_reg) {
 +               pr_err(%s: No read/write API for accessing vdd_%s regs\n,
 +                       __func__, voltdm-name);
 +               return -EINVAL;
 +       }
 +
 +       /* Get volt_data corresponding to target_volt */
 +       volt_data = omap_voltage_get_voltdata(voltdm, target_volt);
 +       if (IS_ERR(volt_data))
 +               volt_data = NULL;
 +
 +       *target_vsel = vdd-pmic_info-uv_to_vsel(target_volt);
 +       *current_vsel = vdd-read_reg(vdd-vp_data-vp_common-prm_mod, 
 vdd-vp_data-voltage);
 +
 +       /* Setting the ON voltage to the new target voltage */
 +       vc_cmdval = vdd-read_reg(vc-vc_common-prm_mod, vc-cmdval_reg);
 +       vc_cmdval = ~vc_common-cmd_on_mask;
 +       vc_cmdval |= (*target_vsel  vc_common-cmd_on_shift);
 +       vdd-write_reg(vc_cmdval, vc-vc_common-prm_mod, vc-cmdval_reg);
 +
 +       /* Setting vp errorgain based on the voltage */
 +       if (volt_data) {
 +               vp_errgain_val = 
 vdd-read_reg(vdd-vp_data-vp_common-prm_mod,
 +                                              vdd-vp_data-vpconfig);
 +               vdd-vp_rt_data.vpconfig_errorgain = volt_data-vp_errgain;
 +               vp_errgain_val = ~vp_common-vpconfig_errorgain_mask;
 +               vp_errgain_val |= vdd-vp_rt_data.vpconfig_errorgain 
 +                       vp_common-vpconfig_errorgain_shift;
 +               vdd-write_reg(vp_errgain_val, 
 vdd-vp_data-vp_common-prm_mod,
 +                              vdd-vp_data-vpconfig);
 +       }
 +
 +       return 0;
 +}
 +
 +void omap_vc_post_scale(struct voltagedomain *voltdm,
 +                       unsigned long target_volt,
 +                       u8 target_vsel, u8 current_vsel)
 +{
 +       struct omap_vdd_info *vdd = voltdm-vdd;
 +       u32 smps_steps = 0, smps_delay = 0;
 +
 +       smps_steps = abs(target_vsel - current_vsel);

RE: [PATCH] OMAP2+: VC: add SoC-specific op for PMIC register addresses

2011-03-25 Thread Vishwanath Sripathy

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Kevin Hilman
 Sent: Friday, March 25, 2011 5:40 AM
 To: linux-omap@vger.kernel.org
 Cc: Paul Walmsely; Benoit Cousson
 Subject: [PATCH] OMAP2+: VC: add SoC-specific op for PMIC register
 addresses

 Add a new SoC-specific operation for setting PMIC register addresses
 in the VC for the voltage configuration register and command
 configuration register.

 Some PMICs use a single register for voltage configuration and
 on/retention/off commands, others use separate registers.  This patch
 adds a VC operation for setting these registers.  The voltage
 configuration register is required, and the command register may
 optionally be zero, meaning it is not used.  The command register
 address is only written to the VC if it is non-zero.

What about PRM_VC_VAL_BYPASS register? If a PMIC is connected via only
sr-i2c, then PMIC can be configured only via this register. Shouldn't it
be abstracted as part of this patch or patch series?

Vishwa

 Signed-off-by: Kevin Hilman khil...@ti.com
 ---
  arch/arm/mach-omap2/prm.h  |1 +
  arch/arm/mach-omap2/prm2xxx_3xxx.c |   38
 +++
  arch/arm/mach-omap2/prm44xx.c  |   43
 
  arch/arm/mach-omap2/vc.c   |9 +--
  arch/arm/mach-omap2/vc.h   |6 -
  arch/arm/mach-omap2/vc3xxx_data.c  |5 
  arch/arm/mach-omap2/vc44xx_data.c  |7 --
  7 files changed, 84 insertions(+), 25 deletions(-)

 diff --git a/arch/arm/mach-omap2/prm.h b/arch/arm/mach-
 omap2/prm.h
 index 4daee4a..49f9e78 100644
 --- a/arch/arm/mach-omap2/prm.h
 +++ b/arch/arm/mach-omap2/prm.h
 @@ -32,6 +32,7 @@
   */
  struct omap_prm_vc_ops {
   int (*set_i2c_slave_addr)(u8 vc_id, u8 addr);
 + int (*set_pmic_reg_addrs)(u8 vc_id, u8 volt_addr, u8 cmd_addr);
  };

  extern struct omap_prm_vc_ops omap3_prm_vc_ops;
 diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c b/arch/arm/mach-
 omap2/prm2xxx_3xxx.c
 index b0cc855..4d7fe1a 100644
 --- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
 +++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
 @@ -162,14 +162,20 @@ int omap2_prm_deassert_hardreset(s16
 prm_mod, u8 rst_shift, u8 st_shift)
   */
  struct omap3_prm_vc {
   u32 smps_sa_mask;
 + u32 smps_vol_ra_mask;
 + u32 smps_cmd_ra_mask;
  };

  static struct omap3_prm_vc vc_channels[] = {
   [OMAP3_PRM_VC_VDD_MPU_ID] = {
   .smps_sa_mask =
 OMAP3430_PRM_VC_SMPS_SA_SA0_MASK,
 + .smps_vol_ra_mask = OMAP3430_VOLRA0_MASK,
 + .smps_cmd_ra_mask = OMAP3430_CMDRA0_MASK,
   },
   [OMAP3_PRM_VC_VDD_CORE_ID] = {
   .smps_sa_mask =
 OMAP3430_PRM_VC_SMPS_SA_SA1_MASK,
 + .smps_vol_ra_mask = OMAP3430_VOLRA1_MASK,
 + .smps_cmd_ra_mask = OMAP3430_CMDRA1_MASK,
   },
  };

 @@ -190,6 +196,38 @@ int omap3_prm_vc_set_i2c_slave_addr(u8
 vc_id, u8 slave_addr)
   return 0;
  }

 +/**
 + * omap3_prm_vc_set_pmic_reg_addrs - set PMIC register addresses
 used by VC
 + * @vc: pointer to VC channel
 + * @volt_addr: voltage configuration register address
 + * @cmd_addr: on/retention/off command configuration register
 address
 + *
 + * Programs @volt_addr to the voltage register address (VOL_RA)
 + * register for the VDD channnel @vc_id.  If @cmd_addr is
 + * non-zero (for PMICs that use different registers for voltage and
 + * command), write that value to the command configuration register
 + * address (CMD_RA) register.
 + */
 +static int omap3_prm_vc_set_pmic_reg_addrs(u8 vc_id, u8 volt_addr,
 u8 cmd_addr)
 +{
 + struct omap3_prm_vc *vc = vc_channels[vc_id];
 +
 + omap2_prm_rmw_mod_reg_bits(vc-smps_vol_ra_mask,
 +volt_addr  ffs(vc-smps_vol_ra_mask),
 +OMAP3430_GR_MOD,
 +
 OMAP3_PRM_VC_SMPS_VOL_RA_OFFSET);
 +
 + if (cmd_addr)
 + omap2_prm_rmw_mod_reg_bits(vc-
 smps_cmd_ra_mask,
 + cmd_addr  ffs(vc-
 smps_cmd_ra_mask),
 + OMAP3430_GR_MOD,
 +
   OMAP3_PRM_VC_SMPS_CMD_RA_OFFSET);
 +
 + return 0;
 +}
 +
 +
  struct omap_prm_vc_ops omap3_prm_vc_ops = {
   .set_i2c_slave_addr = omap3_prm_vc_set_i2c_slave_addr,
 + .set_pmic_reg_addrs = omap3_prm_vc_set_pmic_reg_addrs,
  };
 diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-
 omap2/prm44xx.c
 index 2e4bdf5..2758b75 100644
 --- a/arch/arm/mach-omap2/prm44xx.c
 +++ b/arch/arm/mach-omap2/prm44xx.c
 @@ -202,17 +202,25 @@ void
 omap4_prm_global_warm_sw_reset(void)
   */
  struct omap4_prm_vc {
   u32 smps_sa_mask;
 + u32 smps_vol_ra_mask;
 + u32 smps_cmd_ra_mask;
  };

  static struct omap4_prm_vc vc_channels[] = {
   [OMAP4_PRM_VC_VDD_MPU_ID] = {
   .smps_sa_mask =
 OMAP4430_SA_VDD_MPU_L_PRM_VC_SMPS_SA_MASK,
 + .smps_vol_ra_mask =
 OMAP4430_VOLRA_VDD_MPU_L_MASK,
 +

Re: 2.6.38 not booting on sbc8100 (aka devkit8000)

2011-03-25 Thread Belisko Marek

On Fri, Mar 25, 2011 at 9:27 AM, Jarkko Nikula jhnik...@gmail.com wrote:
 On Fri, 25 Mar 2011 08:57:04 +0100
 Belisko Marek marek.beli...@gmail.com wrote:

   Can you enable DEBUG_LL and EARLY_PRINTK in your .config
   and add earlyprintk to your cmdline? Then you should see
   what goes wrong.
  
  Forgot to mention. I already test this options but result is same like I
  report in
  first email.
 
  Maybe add some printk statements to start_kernel function in
  init/main.c and see if you get any output?
 Add some printk to function you propose bu no output.

 Do you get any output if you don't compile support for your board but
 for something else like for Beagle only so that machine id from
 bootloader and machine(s) supported by the kernel doesn't match?
u-boot pass  mach-type 2002 (in 2.6.38 kernel is MACH_SPARK) so any of
omap2 machines should fit and I should get some warning from kernel
(not supported mach-type or something like that). But no still hang on
Starting kernel...
So this is obvious more problematic.

 --
 Jarkko


marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
icq: 290551086
web: http://open-nandra.com
--
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

OMAP 3430 Camera/ISP out of memory error

2011-03-25 Thread Patrick Radius

Hi,

i'm trying to get camera support working on a relatively new Android
port to an OMAP 3430 based phone (Samsung GT-i8320 a.k.a. Samsung H1).
However calls to VIDIOC_REQBUFS fail with a -12 (OUT OF MEMORY).
As far as I can see this return error isn't even supposed to exist,
according to the V4L2 spec.
I'm using the code from Android on the Zoom2.
The sensor is a Fujitsu M-4MO.

Any ideas on what could be wrong with the out of memory result?
Thanks!

--
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: OMAP 3430 Camera/ISP out of memory error

2011-03-25 Thread Patrick Radius

Ok, thanks!
However, I'm also quite curious about peoples thoughts about it from
here.
Since I think what's happing is quite OMAP specific.
For example, I was wondering where omap34xxcam.c gets it's memory it
should allocate from.
Is it the 'main' memory? Or does it share memory with a framebuffer
(overlay)? Or memory from the (M-4MO) sensor?
Is it possible I should allocate memory for it as boot argument? similar
like vmem=16M omapfb.vram=0:8M

I can't find much information about this all...

On vr, 2011-03-25 at 13:24 +0200, Sakari Ailus wrote:
 Patrick Radius wrote:
  Hi,
 
 Hi Patrick,
 
 I think this question will get better answered in the linux-media list.
 Cc it.
 
  i'm trying to get camera support working on a relatively new Android
  port to an OMAP 3430 based phone (Samsung GT-i8320 a.k.a. Samsung H1).
  However calls to VIDIOC_REQBUFS fail with a -12 (OUT OF MEMORY).
  As far as I can see this return error isn't even supposed to exist,
  according to the V4L2 spec.
  I'm using the code from Android on the Zoom2.
  The sensor is a Fujitsu M-4MO.
  
  Any ideas on what could be wrong with the out of memory result?
 
 First of all, which version of the driver are you using, i.e. is it the
 current one going to upstream?
 


--
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: [RFC PATCH 2/2] OMAP2+: PANDA: Fix up random or missing MAC addresses for eth0 and wlan0

On Thursday 24 March 2011, Andy Green wrote:
 This patch registers a network device notifier callback to set the mac
 addresses for the onboard network assets of Panda correctly, despite the
 drivers involved have used a random or all-zeros MAC address.
 
 The technique was suggested by Alan Cox on lkml.
 
 It works by device path so it corrects the MAC addresses even if the
 drivers are in modules loaded in an order that changes their interface
 name from usual (eg, the onboard module might be wlan1 if there is a
 USB wireless stick plugged in and its module is inserted first.)
 
 Cc: Alan Cox a...@lxorguk.ukuu.org.uk
 Signed-off-by: Andy Green andy.gr...@linaro.org

It looks like this is the best solution so far.

Acked-by: Arnd Bergmann a...@arndb.de
--
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: [RFC PATCH 1/2] OMAP2+: add cpu id register to MAC address helper

On Thursday 24 March 2011, Andy Green wrote:
 Introduce a generic helper function that can set a MAC address using
 data from the OMAP unique CPU ID register.
 
 For comparison purposes this produces a MAC address of
 
   2e:40:70:f0:12:06
 
 for the ethernet device on my Panda.
 
 
 Note that this patch requires the fix patch for CPU ID register
 indexes previously posted to linux-omap, otherwise the CPU ID is
 misread on Panda by the existing function to do it.  This patch
 is already on linux-omap.
 
 OMAP2+:Common CPU DIE ID reading code reads wrong registers for OMAP4430
 http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=b235e007831dbf57710e59cd4a120e2f374eecb9
 
 Signed-off-by: Andy Green andy.gr...@linaro.org

Acked-by: Arnd Bergmann a...@arndb.de

TI folks: While this is a working solution, I still think it would
be good to get an officially sanctioned method that allows the creation
of a IEEE 802 MAC address in a range assigned to TI instead of using
an address from the locally administered range.

Is that something that can be done?

Arnd
--
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: [RFC PATCH 1/2] OMAP2+: add cpu id register to MAC address helper

On 03/25/2011 11:49 AM, Somebody in the thread at some point said:

On Thursday 24 March 2011, Andy Green wrote:

Introduce a generic helper function that can set a MAC address using
data from the OMAP unique CPU ID register.

For comparison purposes this produces a MAC address of

2e:40:70:f0:12:06

for the ethernet device on my Panda.

Note that this patch requires the fix patch for CPU ID register
indexes previously posted to linux-omap, otherwise the CPU ID is
misread on Panda by the existing function to do it. This patch
is already on linux-omap.

OMAP2+:Common CPU DIE ID reading code reads wrong registers for OMAP4430
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=b235e007831dbf57710e59cd4a120e2f374eecb9

Signed-off-by: Andy Greenandy.gr...@linaro.org

Acked-by: Arnd Bergmanna...@arndb.de

Thanks.

TI folks: While this is a working solution, I still think it would
be good to get an officially sanctioned method that allows the creation
of a IEEE 802 MAC address in a range assigned to TI instead of using
an address from the locally administered range.

Is that something that can be done?

Having a proper MAC from IEEE assigned for each interface is of course
ideal.

But even if that happened today though, on Panda there is no board
identity storage to put the reserved MAC addresses in to bind it to the
physical board. If you try to manage them on SD Card, you have the
problem of dealing with correct MAC addresses needing putting there
again every time it is nuked. So it doesn't in itself help in the Panda
case.

David Anders mentioned yesterday that for next OMAP board, he probably
puts a general board identity EEPROM where one could stash MACs. This
kind of API can be extended to query the EEPROM at device-register-time
and fetch the MAC instead of compute it. So I think we go in a
reasonable direction even when it is possible to get assigned MACs.

-Andy
--
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: [RFC PATCH 1/2] OMAP2+: add cpu id register to MAC address helper

On Friday 25 March 2011, Andy Green wrote:
 Having a proper MAC from IEEE assigned for each interface is of course 
 ideal.
 
 But even if that happened today though, on Panda there is no board 
 identity storage to put the reserved MAC addresses in to bind it to the 
 physical board.  If you try to manage them on SD Card, you have the 
 problem of dealing with correct MAC addresses needing putting there 
 again every time it is nuked.  So it doesn't in itself help in the Panda 
 case.

What I meant is computing an official MAC address from the same input
data as you already do. Unfortunately that would mean having at most 24
bits available instead of the 44 or so bits you currently use, because
the upper half of the address then becomes fixed.

Also it would require
1. defining an new algorithm that computes the lower 24 bits from the
   die ID in a way that minimises the chances of collision
2. Getting an official identifier for the upper half of the address
   assigned to the OMAP3/OMAP4 CPUs
3. Documenting this method in the OMAP data sheets.

Arnd
--
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: [RFC PATCH 1/2] OMAP2+: add cpu id register to MAC address helper


On 03/25/2011 01:24 PM, Somebody in the thread at some point said:

On Friday 25 March 2011, Andy Green wrote:

Having a proper MAC from IEEE assigned for each interface is of course
ideal.

But even if that happened today though, on Panda there is no board
identity storage to put the reserved MAC addresses in to bind it to the
physical board.  If you try to manage them on SD Card, you have the
problem of dealing with correct MAC addresses needing putting there
again every time it is nuked.  So it doesn't in itself help in the Panda
case.


What I meant is computing an official MAC address from the same input
data as you already do. Unfortunately that would mean having at most 24
bits available instead of the 44 or so bits you currently use, because
the upper half of the address then becomes fixed.

Also it would require
1. defining an new algorithm that computes the lower 24 bits from the
die ID in a way that minimises the chances of collision
2. Getting an official identifier for the upper half of the address
assigned to the OMAP3/OMAP4 CPUs
3. Documenting this method in the OMAP data sheets.


I see.  It would work OK then.  They probably wouldn't want to blow 
their $1750 just on Panda though, so maybe they set 4 bits or whatever 
and let 20 be computed.


However, the only practical advantage is that it would show up as a TI 
MAC in an OUI database.  The locally administered address as used at 
the moment is otherwise legal in every respect AFAIK.


-Andy
--
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: [RFC PATCH] HDMI:Support for EDID parsing in kernel.

2011-03-25 Thread K, Mythri P

Hi Gunnedi,

snip
  Dave's point is that we can't ditch the existing code without
  introducing a lot of risk; it would be better to start a library-ized
  EDID codebase from the most complete one we have already, i.e. the DRM
  EDID code.

 Does the DRM EDID-parser also process blocks beyond the first one and
 also parses SVD entries similar to what I've recently added to fbdev? Yes,
 we definitely need a common EDID parses, and maybe we'll have to collect
 various pieces from different implementations.

As far as I know , it does not parse SVD ,But it should not be that
difficult to add.
We could take the SVD parsing from your code . In the RFC i have
posted I parse for detailed timing and other VSDB blocks.
Also the parsing should be based on the extension type for  multiple
128 byte blocks.

Thanks and regards,
Mythri.

 Thanks
 Guennadi

--
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+: VC: add SoC-specific op for PMIC register addresses

Vishwanath Sripathy vishwanath...@ti.com writes:

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Kevin Hilman
 Sent: Friday, March 25, 2011 5:40 AM
 To: linux-omap@vger.kernel.org
 Cc: Paul Walmsely; Benoit Cousson
 Subject: [PATCH] OMAP2+: VC: add SoC-specific op for PMIC register
 addresses

 Add a new SoC-specific operation for setting PMIC register addresses
 in the VC for the voltage configuration register and command
 configuration register.

 Some PMICs use a single register for voltage configuration and
 on/retention/off commands, others use separate registers.  This patch
 adds a VC operation for setting these registers.  The voltage
 configuration register is required, and the command register may
 optionally be zero, meaning it is not used.  The command register
 address is only written to the VC if it is non-zero.

 What about PRM_VC_VAL_BYPASS register? If a PMIC is connected via only
 sr-i2c, then PMIC can be configured only via this register. Shouldn't it
 be abstracted as part of this patch or patch series?

Yes.

So far this series just splits out the setting of the slave address and
the PMIC register addresses.  Once we are happy with this approach
(hence the RFC patches) I will continue splitting out the other
functionality in a similar way.

Kevin

--
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/RFC 01/19] OMAP2+: hwmod: remove unused voltagedomain pointer

Jean Pihet jean.pi...@newoldbits.com writes:

 On Thu, Mar 24, 2011 at 1:00 AM, Kevin Hilman khil...@ti.com wrote:
 The voltage domain pointer currently in struct omap_hwmod is not used
 and does not belong here.  Instead, voltage domains will be associated

 Extra space


heh.  My english teachers always taught me to put two spaces after a
period. ;)

Kevin
--
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: OMAP 3430 Camera/ISP out of memory error

2011-03-25 Thread David Cohen

Hi,

On Fri, Mar 25, 2011 at 1:34 PM, Patrick Radius i...@notoyota.nl wrote:
 Ok, thanks!
 However, I'm also quite curious about peoples thoughts about it from
 here.
 Since I think what's happing is quite OMAP specific.
 For example, I was wondering where omap34xxcam.c gets it's memory it
 should allocate from.
 Is it the 'main' memory? Or does it share memory with a framebuffer
 (overlay)? Or memory from the (M-4MO) sensor?
 Is it possible I should allocate memory for it as boot argument? similar
 like vmem=16M omapfb.vram=0:8M

 I can't find much information about this all...

You're using an old version of the driver. Please, use the newer one
available in mainline.

Regards,

David Cohen


 On vr, 2011-03-25 at 13:24 +0200, Sakari Ailus wrote:
 Patrick Radius wrote:
  Hi,

 Hi Patrick,

 I think this question will get better answered in the linux-media list.
 Cc it.

  i'm trying to get camera support working on a relatively new Android
  port to an OMAP 3430 based phone (Samsung GT-i8320 a.k.a. Samsung H1).
  However calls to VIDIOC_REQBUFS fail with a -12 (OUT OF MEMORY).
  As far as I can see this return error isn't even supposed to exist,
  according to the V4L2 spec.
  I'm using the code from Android on the Zoom2.
  The sensor is a Fujitsu M-4MO.
 
  Any ideas on what could be wrong with the out of memory result?

 First of all, which version of the driver are you using, i.e. is it the
 current one going to upstream?



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

--
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/RFC 00/19] OMAP: voltage layer cleanup and restructure

2011-03-25 Thread Cousson, Benoit


On 3/25/2011 1:02 AM, Hilman, Kevin wrote:

Kevin Hilmankhil...@ti.com  writes:


This series is the begining of a voltage layer cleanup and restruture
with the primary goal of splitting up voltage domain, voltage
processor (VP) and voltage controller (VC) code.

The RFC part is for the last 3 patches in the series, and for
discussion of how/if to split out the SoC specifics.  As an example, I
started on the VC and split out some functionality (setting slave i2c
addr, setting PMIC register addresses) into hooks that can be
implemented in SoC specific code.  I'd appreciate any input on this
approach as well as the types of functions/APIs that should exist at
this level.


Based on some more discussions with Paul, I decided on a slightly
different approach based on a suggestion from Paul.

Rather than create the vc3xxx.c/vc4xxx.c files, instead I create the SoC
specific functions for the VC in the existing SoC specific PRM code
(prm2xxx_3xxx.c and prm4xxx.c.)


FWIW, I prefer your original approach :-)

I really think we'd better split the PRCM code by functions instead or 
trying to map the HW partitioning which is purely arbitrary most of the 
time.


This is for that reason that I didn't wanted to split CM to CM1  CM2. 
These 2 partitions are doing exactly the same stuff than what CM used to do.


In this case, the PRM just contain a bunch a various stuff that are not
necessarily related. VP and VC are both standalone IPs, that are just 
located in the PRM because if was convenient for the HW folks.


So having dedicated file for each functions inside the PRCM is for my 
point of view a much better approach for the long term.


Otherwise, we might end up with one big file that will just mimic the 
mess we have inside the HW.



That being said, as soon as we have defined the functions, moving them 
here and there should not be a big deal.


Benoit
--
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: hwmod: add syss reset done flags to omap2, omap3 hwmods

2011-03-25 Thread Cousson, Benoit


Hi Paul,

On 3/25/2011 6:38 AM, Paul Walmsley wrote:

Hi Avinash,


On Thu, 24 Feb 2011, Avinash.H.M wrote:


Some of the omap2, omap3 peripherals support software reset. This
can be done through the softreset bit in sysconfig register.
The reset status can be checked through resetdone bit of
sysstatus register. syss_has_reset_status is added to the hwmod
database of peripherals which have resetdone bit in sysstatus register.

Cc: Rajendra Nayakrna...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
Cc: Benoit Coussonb-cous...@ti.com
Cc: Kevin Hilmankhil...@ti.com
Reviewed-by: Govindraj.Rgovindraj.r...@ti.com
Signed-off-by: Avinash.H.Mavinas...@ti.com


This patch is causing I2C softreset timeouts in the hwmod layer on OMAP2
and 3.  Could you please take a look at this and figure out what is going
on?


I think this is probably due to the nasty I2C softreset bug with 
discussed last year with Paul Brady.


AFAIR, the I2C cannot be reset by just writing to the SYSCONFIG 
softreset bit. You need to play with other registers too.


Avinash,
You should try to look at 3430 or 3630 errata. You will probably find 
the bug I'm referring to.



Benoit

--
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: [RFC PATCH 1/2] OMAP2+: add cpu id register to MAC address helper

On Friday 25 March 2011, Andy Green wrote:
 I see.  It would work OK then.  They probably wouldn't want to blow 
 their $1750 just on Panda though, so maybe they set 4 bits or whatever 
 and let 20 be computed.

Well, if the algorithm is defined well, it could be used for any device
based on OMAP. The marketing department could turn this into a win by
declaring does not require external EEPROM for ethernet mac address ;-)
 
 However, the only practical advantage is that it would show up as a TI 
 MAC in an OUI database.  The locally administered address as used at 
 the moment is otherwise legal in every respect AFAIK.

It should work almost always, except in very special corner cases:

* If you have a netboot setup, you want the boot loader to use the
same mac address for requesting the kernel image that you use later,
otherwise the switch might consider it a MAC spoofing attach and disable
the port. The obvious workaround is to put your code into the boot loader
as well.

* Some environments might be configured to disallow locally administered
MAC addresses for security reasons. A bit bogus, but not unheard of.

* Some places try to keep a database of all used machines and their MAC
addresses to monitor who connects to the network. This requires the address
to be stable. It also prevents the use of virtualization, so it's becoming
less common.

Arnd
--
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/6] arm: mach-omap2: smartreflex: fix sr_late_init() error path in probe

Nishanth Menon n...@ti.com writes:

 Kevin Hilman wrote, on 03/24/2011 10:48 PM:
 Also, I renamed the subject/shortlog to use 'OMAP2+: smartreflex: ...
 instead of 'arm: mach-omap2'.

 might be better to be OMAP3+ we dont have SR on OMAP2 :)


Good point.  Will use OMAP3+.

Thanks,

Kevin

P.S. Nishanth, as you are one of the primary developers on SR, any
 acks, reviewed-bys from you are most welcome on SR patches.
 Thanks.

--
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: [RFC PATCH 1/2] OMAP2+: add cpu id register to MAC address helper


On 03/25/2011 02:50 PM, Somebody in the thread at some point said:

On Friday 25 March 2011, Andy Green wrote:

I see.  It would work OK then.  They probably wouldn't want to blow
their $1750 just on Panda though, so maybe they set 4 bits or whatever
and let 20 be computed.


Well, if the algorithm is defined well, it could be used for any device
based on OMAP. The marketing department could turn this into a win by
declaring does not require external EEPROM for ethernet mac address ;-)


Okay, can't argue with it ^^


* Some places try to keep a database of all used machines and their MAC
addresses to monitor who connects to the network. This requires the address
to be stable. It also prevents the use of virtualization, so it's becoming
less common.


They will probably just be happy the crazy noise they have been seeing 
from current Panda MACs changing every session will go away, it doesn't 
seem to add anything it's an OUI namespace MAC.  In the patch case the 
locally administered mac will be stable.


Anyway since I understood it, I can see your idea is a cool approach, 
it's up to TI what they will do about it but I guess it's OK with or 
without it.


-Andy
--
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] iommu: Prevent oops in iommu_get() and while arch_iommu is in use

Hi,

This patchset is aimed to fix a problem in arch_iommu implementation
references. When an actual arch_iommu implementation is not loaded while
iommu_get() is being called results to a kernel oops, as well as
removing an arch_iommu implementation which is in use.

This patchset fixes both issues.

The patchset assumes the arch_iommu is uninstalled at module unload
time. Is this an acceptable requirement?

Serialisation of the access to arch_iommu is done using mutex called
arch_iommu_mutex.

module_put() doesn't need to have the arch_iommu_mutex since when this
gets called there won't be any users on the arch_iommu anyway.

Comments are welcome. :-)

Cheers,

-- 
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
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] iommu: Prevent oops in iommu_get() and while arch_iommu is in use

Hi,

[Resend: the patches were accidentally sent to linux-media instead.
Apologies.]

This patchset is aimed to fix a problem in arch_iommu implementation
references. When an actual arch_iommu implementation is not loaded while
iommu_get() is being called results to a kernel oops, as well as
removing an arch_iommu implementation which is in use.

This patchset fixes both issues.

The patchset assumes the arch_iommu is uninstalled at module unload
time. Is this an acceptable requirement?

Serialisation of the access to arch_iommu is done using mutex called
arch_iommu_mutex.

module_put() doesn't need to have the arch_iommu_mutex since when this
gets called there won't be any users on the arch_iommu anyway.

Comments are welcome. :-)

Cheers,

-- 
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
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 3/4] omap2 iommu: Set module information in omap2_iommu_ops

Set omap2_iommu_ops.module to point to THIS_MODULE.

Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
 arch/arm/mach-omap2/iommu2.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 14ee686..cf0c32a 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -342,6 +342,8 @@ static const struct iommu_functions omap2_iommu_ops = {
.save_ctx   = omap2_iommu_save_ctx,
.restore_ctx= omap2_iommu_restore_ctx,
.dump_ctx   = omap2_iommu_dump_ctx,
+
+   .module = THIS_MODULE,
 };
 
 static int __init omap2_iommu_init(void)
-- 
1.7.2.3

--
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 4/4] omap iommu: Prevent iommu implementations from being unloaded while in use

Prevent module implementing arch_iommu from being unloaded while the
arch_iommu is in use, essentially while the iommu has been acquired using
iommu_get() by increasing module use count.

This assumes that the arch_iommu has to be uninstalled at module unload
time.

Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
 arch/arm/plat-omap/iommu.c |   31 +--
 1 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index f0fea0b..430ed94 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -35,6 +35,7 @@ static const struct iommu_functions *arch_iommu;
 
 static struct platform_driver omap_iommu_driver;
 static struct kmem_cache *iopte_cachep;
+static struct mutex arch_iommu_mutex;
 
 /**
  * install_iommu_arch - Install archtecure specific iommu functions
@@ -45,10 +46,17 @@ static struct kmem_cache *iopte_cachep;
  **/
 int install_iommu_arch(const struct iommu_functions *ops)
 {
-   if (arch_iommu)
+   mutex_lock(arch_iommu_mutex);
+
+   if (arch_iommu) {
+   mutex_unlock(arch_iommu_mutex);
return -EBUSY;
+   }
 
arch_iommu = ops;
+
+   mutex_unlock(arch_iommu_mutex);
+
return 0;
 }
 EXPORT_SYMBOL_GPL(install_iommu_arch);
@@ -58,13 +66,22 @@ EXPORT_SYMBOL_GPL(install_iommu_arch);
  * @ops:   a pointer to architecture specific iommu functions
  *
  * This interface uninstalls the iommu algorighm installed previously.
+ *
+ * Note: This function may only be called at module_exit() function of
+ * a module which implements arch_iommu. Otherwise another mechanism
+ * from the module use count only to ensure the arch_iommu stays there
+ * has to be implemented.
  **/
 void uninstall_iommu_arch(const struct iommu_functions *ops)
 {
+   mutex_lock(arch_iommu_mutex);
+
if (arch_iommu != ops)
pr_err(%s: not your arch\n, __func__);
 
arch_iommu = NULL;
+
+   mutex_unlock(arch_iommu_mutex);
 }
 EXPORT_SYMBOL_GPL(uninstall_iommu_arch);
 
@@ -104,14 +121,20 @@ static int iommu_enable(struct iommu *obj)
if (!obj)
return -EINVAL;
 
-   if (!arch_iommu)
+   mutex_lock(arch_iommu_mutex);
+   if (!arch_iommu || !try_module_get(arch_iommu-module)) {
+   mutex_unlock(arch_iommu_mutex);
return -ENOENT;
+   }
 
clk_enable(obj-clk);
 
err = arch_iommu-enable(obj);
 
clk_disable(obj-clk);
+
+   mutex_unlock(arch_iommu_mutex);
+
return err;
 }
 
@@ -125,6 +148,8 @@ static void iommu_disable(struct iommu *obj)
arch_iommu-disable(obj);
 
clk_disable(obj-clk);
+
+   module_put(arch_iommu-module);
 }
 
 /*
@@ -1058,6 +1083,8 @@ static int __init omap_iommu_init(void)
return -ENOMEM;
iopte_cachep = p;
 
+   mutex_init(arch_iommu_mutex);
+
return platform_driver_register(omap_iommu_driver);
 }
 module_init(omap_iommu_init);
-- 
1.7.2.3

--
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 iommu: Add module information to struct iommu_functions

Whichever module that implements the struct, may not be unloaded while it's
in use.  Prepare to this by adding module reference to the structure.

Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
 arch/arm/plat-omap/include/plat/iommu.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/iommu.h 
b/arch/arm/plat-omap/include/plat/iommu.h
index 69230d6..26fefb4 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -79,6 +79,7 @@ struct iotlb_lock {
 /* architecture specific functions */
 struct iommu_functions {
unsigned long   version;
+   struct module *module;
 
int (*enable)(struct iommu *obj);
void (*disable)(struct iommu *obj);
-- 
1.7.2.3

--
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] omap iommu: Check existence of arch_iommu

Check that the arch_iommu has been installed before trying to use it. This
will lead to kernel oops if the arch_iommu isn't there.

Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
 arch/arm/plat-omap/iommu.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index b1107c0..f0fea0b 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -104,6 +104,9 @@ static int iommu_enable(struct iommu *obj)
if (!obj)
return -EINVAL;
 
+   if (!arch_iommu)
+   return -ENOENT;
+
clk_enable(obj-clk);
 
err = arch_iommu-enable(obj);
-- 
1.7.2.3

--
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: [RFC PATCH] HDMI:Support for EDID parsing in kernel.

2011-03-25 Thread K, Mythri P

Hi Florian,

snip

 So why should this be a common library? Most kernel code doesn't need
 it. Or is there a serious need for video input to parse EDIDs?

 It's true that most kernel code does not need it as it is only useful for
 display output systems (and only the ones that can be connected to something
 sending EDID data) but it would be good anyway.
 Because sharing code that should fulfill the same purpose is always a good
 idea. But of course only if the scope is clearly limited as we don't want to
 end up with a mess that nobody dares touching again as it became to complex.
 So I totally agree that we should share the common stuff we all need and
 adding the extras one needs in the subsystem/driver.
 This is good because it looks like we'll have 3 display subsystems within
 the kernel for a long future and with a common library the same patch would
 not need to be done 3 times but only once. Or even more often if drivers
 have there private EDID implementation which I just throw out of mine to
 replace it later with a common one.


Precisely my point . Also if there are some bad TV models which
doesn't adhere to standard EDID, It would help to add quirks.
Anyone out there want to help me split the DRM code ? As i don't want
DRMer's to fret over changed code :).

Thanks and regards,
Mythri.
 Regards,

 Florian Tobias Schandinat

--
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 00/19] OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Hi  Santosh,

Santosh Shilimkar santosh.shilim...@ti.com writes:

[...]

 Can you rebase and repost your v3 series, I'd like to get this
 queued up early in the 2.6.40 dev cycle.

 You can base on my current pm-core branch, which also has Russell's
 devel-stable branch merged in.

 I pulled your latest pm-core branch
 --
 commit 61cbb3172176b84c106bf0f4c32317c472932ab5
 Merge: d0cf394... da19719...
 Author: Kevin Hilman khil...@ti.com
 Date:   Wed Mar 23 16:33:01 2011 -0700

 Merge branch 'for_2.6.40/pm-misc' into pm-reset
 -
 Looks like Russell's devel branch isn't merged in pm-core.
 I didn't find the relevant patches.

hmm, you're right.  I'm actually pulling Russell's devel-stable branch
not his devel branch.  I assumed they were in devel-stable as well.

 By the way the relevant ARM patches are already in mainline.  So if
 the pm-core is rebased against latest mainline, we can get those
 changes as well.

Before I rebase, I'll wait at least until -rc1 and/or Tony rebases to
mainline.

In the mean time, can you create two branches?  One with the
dependencies and another with the OMAP4 PM series.  After some final
review and testing, I'll merge the latter series and by then we'll
probably have an -rc1 baseline.

Kevin



--
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 00/19] OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

2011-03-25 Thread Santosh Shilimkar

 -Original Message-
 From: Kevin Hilman [mailto:khil...@ti.com]
 Sent: Friday, March 25, 2011 8:54 PM
 To: Santosh Shilimkar
 Cc: linux-omap@vger.kernel.org; Rajendra Nayak; linux-arm-
 ker...@lists.infradead.org
 Subject: Re: [PATCH v2 00/19] OMAP4: PM: Suspend, CPU-hotplug and
 CPUilde support.

 Hi  Santosh,

 Santosh Shilimkar santosh.shilim...@ti.com writes:

[]
  I pulled your latest pm-core branch
  --
  commit 61cbb3172176b84c106bf0f4c32317c472932ab5
  Merge: d0cf394... da19719...
  Author: Kevin Hilman khil...@ti.com
  Date:   Wed Mar 23 16:33:01 2011 -0700

  Merge branch 'for_2.6.40/pm-misc' into pm-reset
  -
  Looks like Russell's devel branch isn't merged in pm-core.
  I didn't find the relevant patches.

 hmm, you're right.  I'm actually pulling Russell's devel-stable
 branch
 not his devel branch.  I assumed they were in devel-stable as well.

Ok.

  By the way the relevant ARM patches are already in mainline.
  So if the pm-core is rebased against latest mainline, we can get
  those changes as well.

 Before I rebase, I'll wait at least until -rc1 and/or Tony rebases
 to mainline.

Ok.

 In the mean time, can you create two branches?  One with the
 dependencies and another with the OMAP4 PM series.  After some final
 review and testing, I'll merge the latter series and by then we'll
 probably have an -rc1 baseline.

Will do.

Regards,
Santosh
--
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 0/4] iommu: Prevent oops in iommu_get() and while arch_iommu is in use

2011-03-25 Thread David Cohen

On Fri, Mar 25, 2011 at 5:17 PM, Sakari Ailus
sakari.ai...@maxwell.research.nokia.com wrote:
 Hi,

Hi Sakari,


 [Resend: the patches were accidentally sent to linux-media instead.
 Apologies.]

 This patchset is aimed to fix a problem in arch_iommu implementation
 references. When an actual arch_iommu implementation is not loaded while
 iommu_get() is being called results to a kernel oops, as well as
 removing an arch_iommu implementation which is in use.

 This patchset fixes both issues.

Sounds nice.


 The patchset assumes the arch_iommu is uninstalled at module unload
 time. Is this an acceptable requirement?

I can't see a reason why this assumption could be wrong. In my point
of view it's acceptable. Let's see Hiroshi's.

Regards,

David Cohen


 Serialisation of the access to arch_iommu is done using mutex called
 arch_iommu_mutex.

 module_put() doesn't need to have the arch_iommu_mutex since when this
 gets called there won't be any users on the arch_iommu anyway.

 Comments are welcome. :-)

 Cheers,

 --
 Sakari Ailus
 sakari.ai...@maxwell.research.nokia.com
 --
 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

--
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/RFC 04/19] OMAP2+: voltage: start towards a new voltagedomain layer

Hi Jean,

Jean Pihet jean.pi...@newoldbits.com writes:

 On Thu, Mar 24, 2011 at 1:00 AM, Kevin Hilman khil...@ti.com wrote:
 Start cleaning up the voltage layer to have a voltage domain layer
 that resembles thae structure of the existing clock and power domain
 s/thae/the

 layers.  To that end:
 Extra space


Thanks for the review of this series.

When commenting on a patch (especially large ones) it helps if you
remove context that is not relevant to the patch.

For example, your two comments above are the only ones on this patch,
yet below you still have the entire patch context, which requires the
author to look through the whole patch again to see if there are other
comments. 

It is a great help to the author (and other reviewers) if the reply only
keeps the relevant context so it's obvious what the reply is to.

Thanks,

Kevin

--
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/RFC 08/19] OMAP2+: powerdomain: add voltagedomain to struct powerdomain

Jean Pihet jean.pi...@newoldbits.com writes:

 On Thu, Mar 24, 2011 at 1:00 AM, Kevin Hilman khil...@ti.com wrote:
 Each powerdomain is associated with a powerdomain.  Add an entry to

 Do you mean '... with a voltage domain'?


yup, thanks.

Kevin

--
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/RFC 10/19] OMAP3: powerdomain data: add voltage domains

Jean Pihet jean.pi...@newoldbits.com writes:

 On Thu, Mar 24, 2011 at 1:00 AM, Kevin Hilman khil...@ti.com wrote:
 Add voltage domain name to indicate which voltagedomain each
 powerdomain is in.  A missing voltage domain name means that that
 powerdomain is not in one of the currently scalable voltage domains.

 Is that the role of the 'scalable' flag? Why not fill in all
 powerdomain structs and set the flag on scalable VDs only?


Yes.

This changelog was written before I added the scalable flag.  Will fix
up the changelog.

Thanks,

Kevin
--
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/RFC 12/19] OMAP2+: powerdomain: add voltage domain lookup during register

Jean Pihet jean.pi...@newoldbits.com writes:

[...]

 @@ -94,6 +95,14 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
        if (_pwrdm_lookup(pwrdm-name))
                return -EEXIST;

 +       voltdm = voltdm_lookup(pwrdm-voltdm.name);
 +       if (!voltdm) {
 +               pr_err(powerdomain: %s: voltagedomain %s does not exist\n,
 +                      pwrdm-name, pwrdm-voltdm.name);
 +               return -EINVAL;

 Per patch 10/19 some power domains do not have an associated voltage
 domain struct filled in. This will result in failure of the power
 domain registration. I think this is not expected.


Right.  I'll fix up the changelog in patch 10.  Now, all powerdomains
are required to have a voltage domain.

Kevin
--
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 v12 4/9] OMAP2+: dmtimer: convert to platform devices

2011-03-25 Thread Tony Lindgren

* DebBarma, Tarun Kanti tarun.ka...@ti.com [110324 23:53]:
 Hi Tony,
 [...]
  Well the dmtimer code can then become just a regular platform_device
  based driver, except for clockevent and clocksource on omap2  3.
 Should I re-post the patch series with removal of duplicate initialization
 Which Kevin pointed out + other relevant comments?
 Or, wait for your patch series!

Just wait few days please, I should have something available that mostly
deals with timer-gp.c, so it should not cause too many issues with your
patches.

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

Re: [PATCH/RFC 13/19] OMAP2+: voltage: keep track of powerdomains in each voltagedomain

Jean Pihet jean.pi...@newoldbits.com writes:

[...]

 +
 +/**
 + * voltdm_for_each - call function on each registered voltagedomain
 + * @fn: callback function *
 + *
 + * Call the supplied function @fn for each registered voltagedomain.
 + * The callback function @fn can return anything but 0 to bail out
 + * early from the iterator.  Returns the last return value of the
 + * callback function, which should be 0 for success or anything else
 + * to indicate failure; or -EINVAL if the function pointer is null.

 The function description does not match the prototype.


in what way?

the description is wrong in how it describes the bail out but I don't
see what you mean for the prototype.

[...]


 +struct powerdomain;
 +
 +/*
 + * Maximum number of powerdomains that can be associated with a 
 voltagedomain.
 + */
 +#define VOLTDM_MAX_PWRDMS             10
 This is not used in the patch. Is it needed?


Nope.  Will drop.

Thanks,

Kevin
--
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] TI816X: prcm: Add module and register offsets

This patch adds PRCM register offsets for TI816X device as required for the
clock data.

Signed-off-by: Hemant Pedanekar hema...@ti.com
---
 arch/arm/mach-omap2/cm816x.h   |  228 
 arch/arm/mach-omap2/prm2xxx_3xxx.h |   17 +++
 2 files changed, 245 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/cm816x.h

diff --git a/arch/arm/mach-omap2/cm816x.h b/arch/arm/mach-omap2/cm816x.h
new file mode 100644
index 000..b1dbd3d
--- /dev/null
+++ b/arch/arm/mach-omap2/cm816x.h
@@ -0,0 +1,228 @@
+/*
+ * TI816X CM register access macros. Also contains CM module offsets.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc. - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * 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.
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_CM816X_H
+#define __ARCH_ARM_MACH_OMAP2_CM816X_H
+
+#include prcm-common.h
+
+#define TI816X_CM_REGADDR(module, reg) \
+   OMAP2_L4_IO_ADDRESS(TI816X_PRCM_BASE + (module) + (reg))
+
+/*
+ * TI816X CM module offsets
+ */
+
+#define TI816X_CM_DEVICE_MOD   0x0100  /* 256B */
+#define TI816X_CM_DPLL_MOD 0x0300  /* 256B */
+#define TI816X_CM_ACTIVE_MOD   0x0400  /* 256B */
+#define TI816X_CM_DEFAULT_MOD  0x0500  /* 256B */
+#define TI816X_CM_IVAHD0_MOD   0x0600  /* 256B */
+#define TI816X_CM_IVAHD1_MOD   0x0700  /* 256B */
+#define TI816X_CM_IVAHD2_MOD   0x0800  /* 256B */
+#define TI816X_CM_SGX_MOD  0x0900  /* 256B */
+#define TI816X_CM_ALWON_MOD0x1400  /* 1KB */
+
+/*
+ * Clock domain register offsets - these are generally CLKSTCTRL registers for
+ * respective modules.
+ */
+
+/* ALWON */
+#define TI816X_CM_ALWON_MPU_CLKDM  0x001C
+#define TI816X_CM_ALWON_L3_SLOW_CLKDM  0x
+#define TI816X_CM_ETHERNET_CLKDM   0x0004
+#define TI816X_CM_MMU_CLKDM0x000C
+#define TI816X_CM_MMUCFG_CLKDM 0x0010
+
+/* ACTIVE */
+#define TI816X_CM_ACTIVE_GEM_CLKDM 0x
+
+/* IVAHD0 */
+#define TI816X_CM_IVAHD0_CLKDM 0x
+
+/* IVAHD1 */
+#define TI816X_CM_IVAHD1_CLKDM 0x
+
+/* IVAHD2 */
+#define TI816X_CM_IVAHD2_CLKDM 0x
+
+/* SGX */
+#define TI816X_CM_SGX_CLKDM0x
+
+/* DEFAULT */
+#define TI816X_CM_DEFAULT_L3_MED_CLKDM 0x0004
+#define TI816X_CM_DEFAULT_DUCATI_CLKDM 0x0018
+#define TI816X_CM_DEFAULT_PCI_CLKDM0x0010
+#define TI816X_CM_DEFAULT_L3_SLOW_CLKDM0x0014
+
+/*
+ * CM register addresses
+ */
+
+/* CM_DPLL */
+#define TI816X_CM_DPLL_SYSCLK1_CLKSEL  
TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x)
+#define TI816X_CM_DPLL_SYSCLK2_CLKSEL  
TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0004)
+#define TI816X_CM_DPLL_SYSCLK3_CLKSEL  
TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0008)
+#define TI816X_CM_DPLL_SYSCLK4_CLKSEL  
TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x000C)
+#define TI816X_CM_DPLL_SYSCLK5_CLKSEL  
TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0010)
+#define TI816X_CM_DPLL_SYSCLK6_CLKSEL  
TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0014)
+#define TI816X_CM_DPLL_SYSCLK7_CLKSEL  
TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0018)
+#define TI816X_CM_DPLL_SYSCLK10_CLKSEL 
TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0024)
+#define TI816X_CM_DPLL_SYSCLK11_CLKSEL 
TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x002C)
+#define TI816X_CM_DPLL_SYSCLK12_CLKSEL 
TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0030)
+#define TI816X_CM_DPLL_SYSCLK13_CLKSEL 
TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0034)
+#define TI816X_CM_DPLL_SYSCLK15_CLKSEL 
TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0038)
+#define TI816X_CM_DPLL_VPB3_CLKSEL 
TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0040)
+#define TI816X_CM_DPLL_VPC1_CLKSEL 
TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0044)
+#define TI816X_CM_DPLL_VPD1_CLKSEL 
TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0048)
+#define TI816X_CM_DPLL_SYSCLK19_CLKSEL 
TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x004C)
+#define TI816X_CM_DPLL_SYSCLK20_CLKSEL 
TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0050)
+#define TI816X_CM_DPLL_SYSCLK21_CLKSEL 
TI816X_CM_REGADDR(TI816X_CM_DPLL_MOD, 0x0054)
+#define

[PATCH 2/4] TI816X: clock: Add clock data

This patch adds data for various clocks present in TI816X.

Note that this data is not automatically generated and not all clocks are
covered currently.

Signed-off-by: Hemant Pedanekar hema...@ti.com
---
 arch/arm/mach-omap2/clock816x.h   |   21 +
 arch/arm/mach-omap2/clock816x_data.c  | 1131 +
 arch/arm/mach-omap2/cm-regbits-816x.h |   44 ++
 3 files changed, 1196 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/clock816x.h
 create mode 100644 arch/arm/mach-omap2/clock816x_data.c
 create mode 100644 arch/arm/mach-omap2/cm-regbits-816x.h

diff --git a/arch/arm/mach-omap2/clock816x.h b/arch/arm/mach-omap2/clock816x.h
new file mode 100644
index 000..89b958b
--- /dev/null
+++ b/arch/arm/mach-omap2/clock816x.h
@@ -0,0 +1,21 @@
+/*
+ * TI816X clock function prototypes and macros.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc. - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * 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.
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_CLOCK816X_H
+#define __ARCH_ARM_MACH_OMAP2_CLOCK816X_H
+
+int ti816x_clk_init(void);
+
+#endif
diff --git a/arch/arm/mach-omap2/clock816x_data.c 
b/arch/arm/mach-omap2/clock816x_data.c
new file mode 100644
index 000..083b0a1
--- /dev/null
+++ b/arch/arm/mach-omap2/clock816x_data.c
@@ -0,0 +1,1131 @@
+/*
+ * Clock data for TI816X.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc. - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * 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 linux/kernel.h
+#include linux/list.h
+#include linux/clk.h
+
+#include plat/clkdev_omap.h
+
+#include control.h
+#include clock.h
+#include clock816x.h
+#include cm.h
+#include cm-regbits-816x.h
+#include prm.h
+
+static struct clk sys_32k_ck = {
+   .name   = sys_32k_ck,
+   .ops= clkops_null,
+   .rate   = 32768,
+   .flags  = RATE_IN_TI816X,
+};
+
+static struct clk tclkin_ck = {
+   .name   = tclkin_ck,
+   .ops= clkops_null,
+   .rate   = 32768,
+   .flags  = RATE_IN_TI816X,
+};
+
+static struct clk osc_sys_ck = {
+   .name   = osc_sys_ck,
+   .ops= clkops_null,
+   .rate   = 2700,
+   .flags  = RATE_IN_TI816X,
+};
+
+static struct clk main_pll_clk1_ck = {
+   .name   = main_pll_clk1_ck,
+   .ops= clkops_null,
+   .rate   = 8,
+   .flags  = RATE_IN_TI816X,
+};
+
+static const struct clksel_rate div8_1to8_rates[] = {
+   { .div = 1, .val = 0, .flags = RATE_IN_TI816X },
+   { .div = 2, .val = 1, .flags = RATE_IN_TI816X },
+   { .div = 3, .val = 2, .flags = RATE_IN_TI816X },
+   { .div = 4, .val = 3, .flags = RATE_IN_TI816X },
+   { .div = 5, .val = 4, .flags = RATE_IN_TI816X },
+   { .div = 6, .val = 5, .flags = RATE_IN_TI816X },
+   { .div = 7, .val = 6, .flags = RATE_IN_TI816X },
+   { .div = 8, .val = 7, .flags = RATE_IN_TI816X },
+   { .div = 0 },
+};
+
+static const struct clksel sysclk1_div[] = {
+   { .parent = main_pll_clk1_ck, .rates = div8_1to8_rates },
+   { .parent = NULL },
+};
+
+static struct clk sysclk1_ck = {
+   .name   = sysclk1_ck,
+   .parent = main_pll_clk1_ck,
+   .clksel = sysclk1_div,
+   .init   = omap2_init_clksel_parent,
+   .ops= clkops_null,
+   .clksel_reg = TI816X_CM_DPLL_SYSCLK1_CLKSEL,
+   .clksel_mask= TI816X_CLKSEL_0_2_MASK,
+   .recalc = omap2_clksel_recalc,
+};
+
+static struct clk dsp_ick = {
+   .name   = dsp_ick,
+   .parent = sysclk1_ck,
+   .ops= clkops_omap2_dflt,
+   .enable_reg = TI816X_CM_ACTIVE_GEM_CLKCTRL,
+   .enable_bit = TI816X_MODULEMODE_SWCTRL,
+   .clkdm_name = active_gem_clkdm,
+   .recalc = followparent_recalc,
+};
+
+static struct clk main_pll_clk2_ck = {
+   .name   = main_pll_clk2_ck,
+   .ops= clkops_null,
+   .rate   = 10,
+   .flags  = RATE_IN_TI816X,
+};
+
+static const struct clksel sysclk2_div[] = {
+

[PATCH 3/4] TI816X: clock: Add clockdomains and powerdomains data

This patch adds data for various clock domains and power domains in TI816X.

Note that at present this is not exhaustive and need to add missing domains.

Signed-off-by: Hemant Pedanekar hema...@ti.com
---
 arch/arm/mach-omap2/clockdomains816x.h |  167 
 arch/arm/mach-omap2/powerdomains816x.h |   74 ++
 2 files changed, 241 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/clockdomains816x.h
 create mode 100644 arch/arm/mach-omap2/powerdomains816x.h

diff --git a/arch/arm/mach-omap2/clockdomains816x.h 
b/arch/arm/mach-omap2/clockdomains816x.h
new file mode 100644
index 000..1938abc
--- /dev/null
+++ b/arch/arm/mach-omap2/clockdomains816x.h
@@ -0,0 +1,167 @@
+/*
+ * TI816X Clock Domain data.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc. - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * 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.
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_CLOCKDOMAINS816X_H
+#define __ARCH_ARM_MACH_OMAP2_CLOCKDOMAINS816X_H
+
+#include cm.h
+#include cm816x.h
+#include cm-regbits-816x.h
+
+#ifdef CONFIG_SOC_OMAPTI816X
+
+static struct clockdomain alwon_mpu_816x_clkdm = {
+   .name   = alwon_mpu_clkdm,
+   .pwrdm  = { .name = alwon_pwrdm },
+   .cm_inst= TI816X_CM_ALWON_MOD,
+   .clkdm_offs = TI816X_CM_ALWON_MPU_CLKDM,
+   .clktrctrl_mask = TI816X_CLKTRCTRL_MASK,
+   .flags  = CLKDM_CAN_HWSUP_SWSUP,
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_TI816X),
+};
+
+static struct clockdomain alwon_l3_slow_816x_clkdm = {
+   .name   = alwon_l3_slow_clkdm,
+   .pwrdm  = { .name = alwon_pwrdm },
+   .cm_inst= TI816X_CM_ALWON_MOD,
+   .clkdm_offs = TI816X_CM_ALWON_L3_SLOW_CLKDM,
+   .clktrctrl_mask = TI816X_CLKTRCTRL_MASK,
+   .flags  = CLKDM_CAN_HWSUP_SWSUP,
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_TI816X),
+};
+
+static struct clockdomain alwon_ethernet_816x_clkdm = {
+   .name   = alwon_ethernet_clkdm,
+   .pwrdm  = { .name = alwon_pwrdm },
+   .cm_inst= TI816X_CM_ALWON_MOD,
+   .clkdm_offs = TI816X_CM_ETHERNET_CLKDM,
+   .clktrctrl_mask = TI816X_CLKTRCTRL_MASK,
+   .flags  = CLKDM_CAN_HWSUP_SWSUP,
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_TI816X),
+};
+
+static struct clockdomain mmu_816x_clkdm = {
+   .name   = mmu_clkdm,
+   .pwrdm  = { .name = alwon_pwrdm },
+   .cm_inst= TI816X_CM_ALWON_MOD,
+   .clkdm_offs = TI816X_CM_MMU_CLKDM,
+   .clktrctrl_mask = TI816X_CLKTRCTRL_MASK,
+   .flags  = CLKDM_CAN_HWSUP_SWSUP,
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_TI816X),
+};
+
+static struct clockdomain mmu_cfg_816x_clkdm = {
+   .name   = mmu_cfg_clkdm,
+   .pwrdm  = { .name = alwon_pwrdm },
+   .cm_inst= TI816X_CM_ALWON_MOD,
+   .clkdm_offs = TI816X_CM_MMUCFG_CLKDM,
+   .clktrctrl_mask = TI816X_CLKTRCTRL_MASK,
+   .flags  = CLKDM_CAN_HWSUP_SWSUP,
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_TI816X),
+};
+
+static struct clockdomain active_gem_816x_clkdm = {
+   .name   = active_gem_clkdm,
+   .pwrdm  = { .name = active_pwrdm },
+   .cm_inst= TI816X_CM_ACTIVE_MOD,
+   .clkdm_offs = TI816X_CM_ACTIVE_GEM_CLKDM,
+   .clktrctrl_mask = TI816X_CLKTRCTRL_MASK,
+   .flags  = CLKDM_CAN_HWSUP_SWSUP,
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_TI816X),
+};
+
+static struct clockdomain hdvicp0_816x_clkdm = {
+   .name   = hdvicp0_clkdm,
+   .pwrdm  = { .name = hdvicp0_pwrdm },
+   .cm_inst= TI816X_CM_IVAHD0_MOD,
+   .clkdm_offs = TI816X_CM_IVAHD0_CLKDM,
+   .clktrctrl_mask = TI816X_CLKTRCTRL_MASK,
+   .flags  = CLKDM_CAN_HWSUP_SWSUP,
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_TI816X),
+};
+
+static struct clockdomain hdvicp1_816x_clkdm = {
+   .name   = hdvicp1_clkdm,
+   .pwrdm  = { .name = hdvicp1_pwrdm },
+   .cm_inst= TI816X_CM_IVAHD1_MOD,
+   .clkdm_offs = TI816X_CM_IVAHD1_CLKDM,
+   .clktrctrl_mask = TI816X_CLKTRCTRL_MASK,
+   .flags  = CLKDM_CAN_HWSUP_SWSUP,
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_TI816X),
+};
+
+static struct clockdomain hdvicp2_816x_clkdm = {
+   .name   = hdvicp2_clkdm,
+   .pwrdm  = { .name = hdvicp2_pwrdm },
+   .cm_inst= TI816X_CM_IVAHD2_MOD,
+   .clkdm_offs = TI816X_CM_IVAHD2_CLKDM,

[PATCH 4/4] clock: Integrate TI816X clock data into OMAP clock framework

This patch hooks clock initialization and clockdomain/powerdomain setup into
OMAP clock framework.

Signed-off-by: Hemant Pedanekar hema...@ti.com
---
 arch/arm/mach-omap2/Makefile |1 +
 arch/arm/mach-omap2/clock3xxx_data.c |5 ++-
 arch/arm/mach-omap2/clock816x_data.c |1 +
 arch/arm/mach-omap2/clockdomain2xxx_3xxx.c   |   18 ++-
 arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c |   20 
 arch/arm/mach-omap2/cm2xxx_3xxx.c|   35 ++
 arch/arm/mach-omap2/cm2xxx_3xxx.h|5 +++
 arch/arm/mach-omap2/powerdomain.h|2 +
 arch/arm/mach-omap2/powerdomain2xxx_3xxx.c   |   27 +++--
 arch/arm/mach-omap2/powerdomains3xxx_data.c  |   18 ++-
 arch/arm/mach-omap2/prm2xxx_3xxx.h   |4 ++
 11 files changed, 127 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 82b2a67..8b88e40 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -137,6 +137,7 @@ obj-$(CONFIG_ARCH_OMAP3)+= $(clock-common) 
clock3xxx.o \
   clock3517.o clock36xx.o \
   dpll3xxx.o clock3xxx_data.o \
   clkt_iclk.o
+obj-$(CONFIG_SOC_OMAPTI816X)   += clock816x_data.o
 obj-$(CONFIG_ARCH_OMAP4)   += $(clock-common) clock44xx_data.o \
   dpll3xxx.o dpll44xx.o
 
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c 
b/arch/arm/mach-omap2/clock3xxx_data.c
index d905ecc..b5fa4e0 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -27,6 +27,7 @@
 #include clock34xx.h
 #include clock36xx.h
 #include clock3517.h
+#include clock816x.h
 
 #include cm2xxx_3xxx.h
 #include cm-regbits-34xx.h
@@ -3471,8 +3472,8 @@ int __init omap3xxx_clk_init(void)
cpu_mask = (RATE_IN_34XX | RATE_IN_36XX);
cpu_clkflg = CK_36XX;
} else if (cpu_is_ti816x()) {
-   cpu_mask = RATE_IN_TI816X;
-   cpu_clkflg = CK_TI816X;
+   ti816x_clk_init();
+   return 0;
} else if (cpu_is_omap34xx()) {
if (omap_rev() == OMAP3430_REV_ES1_0) {
cpu_mask = RATE_IN_3430ES1;
diff --git a/arch/arm/mach-omap2/clock816x_data.c 
b/arch/arm/mach-omap2/clock816x_data.c
index 083b0a1..1670d90 100644
--- a/arch/arm/mach-omap2/clock816x_data.c
+++ b/arch/arm/mach-omap2/clock816x_data.c
@@ -23,6 +23,7 @@
 #include clock.h
 #include clock816x.h
 #include cm.h
+#include cm816x.h
 #include cm-regbits-816x.h
 #include prm.h
 
diff --git a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c 
b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
index 48d0db7..4e31584 100644
--- a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
@@ -151,6 +151,9 @@ static void _enable_hwsup(struct clockdomain *clkdm)
if (cpu_is_omap24xx())
omap2xxx_cm_clkdm_enable_hwsup(clkdm-pwrdm.ptr-prcm_offs,
   clkdm-clktrctrl_mask);
+   else if (cpu_is_ti816x())
+   ti816x_cm_clkdm_enable_hwsup(clkdm-cm_inst, clkdm-clkdm_offs,
+  clkdm-clktrctrl_mask);
else if (cpu_is_omap34xx())
omap3xxx_cm_clkdm_enable_hwsup(clkdm-pwrdm.ptr-prcm_offs,
   clkdm-clktrctrl_mask);
@@ -161,6 +164,9 @@ static void _disable_hwsup(struct clockdomain *clkdm)
if (cpu_is_omap24xx())
omap2xxx_cm_clkdm_disable_hwsup(clkdm-pwrdm.ptr-prcm_offs,
clkdm-clktrctrl_mask);
+   else if (cpu_is_ti816x())
+   ti816x_cm_clkdm_disable_hwsup(clkdm-cm_inst, clkdm-clkdm_offs,
+   clkdm-clktrctrl_mask);
else if (cpu_is_omap34xx())
omap3xxx_cm_clkdm_disable_hwsup(clkdm-pwrdm.ptr-prcm_offs,
clkdm-clktrctrl_mask);
@@ -213,14 +219,22 @@ static int omap2_clkdm_clk_disable(struct clockdomain 
*clkdm)
 
 static int omap3_clkdm_sleep(struct clockdomain *clkdm)
 {
-   omap3xxx_cm_clkdm_force_sleep(clkdm-pwrdm.ptr-prcm_offs,
+   if (cpu_is_ti816x())
+   ti816x_cm_clkdm_force_sleep(clkdm-cm_inst, clkdm-clkdm_offs,
+   clkdm-clktrctrl_mask);
+   else
+   omap3xxx_cm_clkdm_force_sleep(clkdm-pwrdm.ptr-prcm_offs,
clkdm-clktrctrl_mask);
return 0;
 }
 
 static int omap3_clkdm_wakeup(struct clockdomain *clkdm)
 {
-   omap3xxx_cm_clkdm_force_wakeup(clkdm-pwrdm.ptr-prcm_offs,
+   if (cpu_is_ti816x())
+   ti816x_cm_clkdm_force_wakeup(clkdm-cm_inst,

[PATCH] omap: fix compiler warning

2011-03-25 Thread Michael Jones

  CC  arch/arm/plat-omap/gpio.o
arch/arm/plat-omap/gpio.c: In function ‘omap_gpio_chip_init’:
arch/arm/plat-omap/gpio.c:1675: warning: unused variable ‘d’

Signed-off-by: Michael Jones michael.jo...@matrix-vision.de
---
 arch/arm/plat-omap/gpio.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 971d186..a1d4d1b 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1672,7 +1672,9 @@ static void __init omap_gpio_chip_init(struct gpio_bank 
*bank)
 
for (j = bank-virtual_irq_start;
 j  bank-virtual_irq_start + bank_width; j++) {
+#ifdef CONFIG_LOCKDEP
struct irq_desc *d = irq_to_desc(j);
+#endif
 
lockdep_set_class(d-lock, gpio_lock_class);
set_irq_chip_data(j, bank);
-- 
1.7.4.1


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
--
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/RFC 04/19] OMAP2+: voltage: start towards a new voltagedomain layer

On Fri, Mar 25, 2011 at 4:48 PM, Kevin Hilman khil...@ti.com wrote:
 Hi Jean,

 Jean Pihet jean.pi...@newoldbits.com writes:

 On Thu, Mar 24, 2011 at 1:00 AM, Kevin Hilman khil...@ti.com wrote:
 Start cleaning up the voltage layer to have a voltage domain layer
 that resembles thae structure of the existing clock and power domain
 s/thae/the

 layers.  To that end:
 Extra space


 Thanks for the review of this series.

 When commenting on a patch (especially large ones) it helps if you
 remove context that is not relevant to the patch.

 For example, your two comments above are the only ones on this patch,
 yet below you still have the entire patch context, which requires the
 author to look through the whole patch again to see if there are other
 comments.
Ok got the point. In fact my e-mail app (gmail web) does automatically
hide the similar portions of text.


 It is a great help to the author (and other reviewers) if the reply only
 keeps the relevant context so it's obvious what the reply is to.

 Thanks,

 Kevin


Thanks,
Jean



--
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/RFC 10/19] OMAP3: powerdomain data: add voltage domains

On Fri, Mar 25, 2011 at 4:51 PM, Kevin Hilman khil...@ti.com wrote:
 Jean Pihet jean.pi...@newoldbits.com writes:

 On Thu, Mar 24, 2011 at 1:00 AM, Kevin Hilman khil...@ti.com wrote:
 Add voltage domain name to indicate which voltagedomain each
 powerdomain is in.  A missing voltage domain name means that that
 powerdomain is not in one of the currently scalable voltage domains.

 Is that the role of the 'scalable' flag? Why not fill in all
 powerdomain structs and set the flag on scalable VDs only?


 Yes.

 This changelog was written before I added the scalable flag.  Will fix
 up the changelog.
Ok if the code does accordingly (which I suppose it does).


 Thanks,

 Kevin


Jean
--
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/RFC 13/19] OMAP2+: voltage: keep track of powerdomains in each voltagedomain

On Fri, Mar 25, 2011 at 4:56 PM, Kevin Hilman khil...@ti.com wrote:
 Jean Pihet jean.pi...@newoldbits.com writes:

 [...]

 +
 +/**
 + * voltdm_for_each - call function on each registered voltagedomain
 + * @fn: callback function *
 + *
 + * Call the supplied function @fn for each registered voltagedomain.
 + * The callback function @fn can return anything but 0 to bail out
 + * early from the iterator.  Returns the last return value of the
 + * callback function, which should be 0 for success or anything else
 + * to indicate failure; or -EINVAL if the function pointer is null.

 The function description does not match the prototype.


 in what way?

 the description is wrong in how it describes the bail out but I don't
 see what you mean for the prototype.
'user' is not in the list of parmaters, not it is present in the
function description.


 [...]


 +struct powerdomain;
 +
 +/*
 + * Maximum number of powerdomains that can be associated with a 
 voltagedomain.
 + */
 +#define VOLTDM_MAX_PWRDMS             10
 This is not used in the patch. Is it needed?


 Nope.  Will drop.
Ok


 Thanks,

 Kevin


Thanks,
Jean
--
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: iovmm: fix SW flags passed by user

2011-03-25 Thread Omar Ramirez Luna

Commit d038aee24dcd changes iovmm to receive flags specified by user,
however the upper 16 bits of the flags are wiped by iovmm itself.

This fixes IOVMF_DA_FIXED flags from being lost, and lets the user
map its desired device addresses.

Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
 arch/arm/plat-omap/include/plat/iovmm.h |3 ---
 arch/arm/plat-omap/iovmm.c  |4 
 2 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/iovmm.h 
b/arch/arm/plat-omap/include/plat/iovmm.h
index 32a2f6c..e992b96 100644
--- a/arch/arm/plat-omap/include/plat/iovmm.h
+++ b/arch/arm/plat-omap/include/plat/iovmm.h
@@ -29,9 +29,6 @@ struct iovm_struct {
  * lower 16 bit is used for h/w and upper 16 bit is for s/w.
  */
 #define IOVMF_SW_SHIFT 16
-#define IOVMF_HW_SIZE  (1  IOVMF_SW_SHIFT)
-#define IOVMF_HW_MASK  (IOVMF_HW_SIZE - 1)
-#define IOVMF_SW_MASK  (~IOVMF_HW_MASK)UL
 
 /*
  * iovma: h/w flags derived from cam and ram attribute
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 51ef43e..83a37c5 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -648,7 +648,6 @@ u32 iommu_vmap(struct iommu *obj, u32 da, const struct 
sg_table *sgt,
return PTR_ERR(va);
}
 
-   flags = IOVMF_HW_MASK;
flags |= IOVMF_DISCONT;
flags |= IOVMF_MMIO;
 
@@ -706,7 +705,6 @@ u32 iommu_vmalloc(struct iommu *obj, u32 da, size_t bytes, 
u32 flags)
if (!va)
return -ENOMEM;
 
-   flags = IOVMF_HW_MASK;
flags |= IOVMF_DISCONT;
flags |= IOVMF_ALLOC;
 
@@ -795,7 +793,6 @@ u32 iommu_kmap(struct iommu *obj, u32 da, u32 pa, size_t 
bytes,
if (!va)
return -ENOMEM;
 
-   flags = IOVMF_HW_MASK;
flags |= IOVMF_LINEAR;
flags |= IOVMF_MMIO;
 
@@ -853,7 +850,6 @@ u32 iommu_kmalloc(struct iommu *obj, u32 da, size_t bytes, 
u32 flags)
return -ENOMEM;
pa = virt_to_phys(va);
 
-   flags = IOVMF_HW_MASK;
flags |= IOVMF_LINEAR;
flags |= IOVMF_ALLOC;
 
-- 
1.7.1

--
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: hwmod: add syss reset done flags to omap2, omap3 hwmods

2011-03-25 Thread Paul Walmsley

Hi,

On Fri, 25 Mar 2011, Cousson, Benoit wrote:

 On 3/25/2011 6:38 AM, Paul Walmsley wrote:
On Thu, 24 Feb 2011, Avinash.H.M wrote:
 Some of the omap2, omap3 peripherals support software reset. This
 can be done through the softreset bit in sysconfig register.
 The reset status can be checked through resetdone bit of
 sysstatus register. syss_has_reset_status is added to the hwmod
 database of peripherals which have resetdone bit in sysstatus
 register.
 
 Cc: Rajendra Nayakrna...@ti.com
 Cc: Paul Walmsleyp...@pwsan.com
 Cc: Benoit Coussonb-cous...@ti.com
 Cc: Kevin Hilmankhil...@ti.com
 Reviewed-by: Govindraj.Rgovindraj.r...@ti.com
 Signed-off-by: Avinash.H.Mavinas...@ti.com
  
  This patch is causing I2C softreset timeouts in the hwmod layer on OMAP2
  and 3.  Could you please take a look at this and figure out what is going
  on?
 
 I think this is probably due to the nasty I2C softreset bug with discussed
 last year with Paul Brady.
 
 AFAIR, the I2C cannot be reset by just writing to the SYSCONFIG softreset bit.
 You need to play with other registers too.

Thanks Benoît.

So then, Avinash, you might need to create a custom hwmod class 
reset function for the I2C block (viz., struct omap_hwmod_class.reset)

 Avinash,
 You should try to look at 3430 or 3630 errata. You will probably find the bug
 I'm referring to.


- Paul

Re: [PATCH] omap: hwmod: add syss reset done flags to omap2, omap3 hwmods

2011-03-25 Thread Paul Walmsley

On Fri, 25 Mar 2011, Avinash.H.M. wrote:

 On Fri, Mar 25, 2011 at 11:56:34AM +0530, Avinash.H.M. wrote:
 
 I am able to reproduce the issue. I am seeing the timeout prints for
 i2c, gpio during bootup. I ll check why softreset is failing.
 
 [0.208892] omap_hwmod: i2c1: softreset failed (waited 1 usec)
 [0.223114] omap_hwmod: i2c2: softreset failed (waited 1 usec)
 [0.237335] omap_hwmod: i2c3: softreset failed (waited 1 usec)
 [0.251525] omap_hwmod: gpio2: softreset failed (waited 1 usec)
 [0.265594] omap_hwmod: gpio3: softreset failed (waited 1 usec)
 [0.279693] omap_hwmod: gpio4: softreset failed (waited 1 usec)
 [0.293762] omap_hwmod: gpio5: softreset failed (waited 1 usec)
 [0.307861] omap_hwmod: gpio6: softreset failed (waited 1 usec)

Just FYI, I don't see the gpio softreset failures on my boards here.


- Paul
--
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: iovmm: fix SW flags passed by user

2011-03-25 Thread Sergei Shtylyov


Hello.

Omar Ramirez Luna wrote:


Commit d038aee24dcd changes iovmm to receive flags specified by user,


   Please also specify that commit's summary for the human readers. Bare ID is 
only usable to gitweb...



however the upper 16 bits of the flags are wiped by iovmm itself.



This fixes IOVMF_DA_FIXED flags from being lost, and lets the user
map its desired device addresses.



Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com


WBR, Sergei

--
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: iovmm: fix SW flags passed by user

On Fri, Mar 25, 2011 at 12:30 PM, Sergei Shtylyov sshtyl...@mvista.com wrote:
 Hello.

 Omar Ramirez Luna wrote:

 Commit d038aee24dcd changes iovmm to receive flags specified by user,

   Please also specify that commit's summary for the human readers. Bare ID
 is only usable to gitweb...

Here it is the patch, introducing the change:

https://patchwork.kernel.org/patch/620871/

If accepted by Hiroshi, I can update the description making reference
to this patch instead of commit.

Regards,

Omar
--
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: OMAP 3430 Camera/ISP out of memory error

2011-03-25 Thread Patrick Radius

Thanks,

I'm looking at
http://gitorious.org/linux-omap/mainline/trees/master/drivers/media/video

however, I can't seem to find the drivers I need.
I only see omap24xxcam while I was using the omap34xxcam from Linux
kernel 2.6.32.9.
And I also don't see any M-4MO driver anymore.
I'm probably looking at the wrong spot, but...

As you can tell, I'm fairly new with OMAP programming.

Thanks!

Regards,
Patrick

On vr, 2011-03-25 at 16:34 +0200, David Cohen wrote:
 Hi,
 
 On Fri, Mar 25, 2011 at 1:34 PM, Patrick Radius i...@notoyota.nl wrote:
  Ok, thanks!
  However, I'm also quite curious about peoples thoughts about it from
  here.
  Since I think what's happing is quite OMAP specific.
  For example, I was wondering where omap34xxcam.c gets it's memory it
  should allocate from.
  Is it the 'main' memory? Or does it share memory with a framebuffer
  (overlay)? Or memory from the (M-4MO) sensor?
  Is it possible I should allocate memory for it as boot argument? similar
  like vmem=16M omapfb.vram=0:8M
 
  I can't find much information about this all...
 
 You're using an old version of the driver. Please, use the newer one
 available in mainline.
 
 Regards,
 
 David Cohen
 
 
  On vr, 2011-03-25 at 13:24 +0200, Sakari Ailus wrote:
  Patrick Radius wrote:
   Hi,
 
  Hi Patrick,
 
  I think this question will get better answered in the linux-media list.
  Cc it.
 
   i'm trying to get camera support working on a relatively new Android
   port to an OMAP 3430 based phone (Samsung GT-i8320 a.k.a. Samsung H1).
   However calls to VIDIOC_REQBUFS fail with a -12 (OUT OF MEMORY).
   As far as I can see this return error isn't even supposed to exist,
   according to the V4L2 spec.
   I'm using the code from Android on the Zoom2.
   The sensor is a Fujitsu M-4MO.
  
   Any ideas on what could be wrong with the out of memory result?
 
  First of all, which version of the driver are you using, i.e. is it the
  current one going to upstream?
 
 
 
  --
  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
 


--
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 0/4] iommu: Prevent oops in iommu_get() and while arch_iommu is in use

On Fri, Mar 25, 2011 at 10:13 AM, Sakari Ailus
sakari.ai...@maxwell.research.nokia.com wrote:
 Hi,

 This patchset is aimed to fix a problem in arch_iommu implementation
 references. When an actual arch_iommu implementation is not loaded while
 iommu_get() is being called results to a kernel oops, as well as
 removing an arch_iommu implementation which is in use.

How about fixing the dependency instead? Right now iommu2 depends on
iommu because of the calls to
install_iommu_arch/uninstall_iommu_arch... we should change that
dependency to iommu depend on iommu2. Something like iommu (plat)
querying iommu2 (mach) for devices to install.

This way depmod (if I'm not mistaken) can do its job, you won't be
able to remove iommu2 in the middle of execution nor install iommu
without its mach counterpart being there first, it should also fix
clients depending on this modules, e.g modprobe bridgedriver would
only install iommu and bridgedriver, with this new dependency iommu2
should be installed as well. BTW same happens with omap mailbox.

$ lsmod
iovmm   7225  1 bridgedriver
iommu  11084  2 bridgedriver,iovmm
iommu2  4783  1 iommu

I can send as a patch if the mailer screws the spacing, also just
copy-pasted and played with the pointers, if needed we can give better
naming.

Regards,

Omar

---

diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index adb083e..ab2f9a9 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -341,15 +341,47 @@ static const struct iommu_functions omap2_iommu_ops = {
.dump_ctx   = omap2_iommu_dump_ctx,
 };

+/**
+ * install_iommu_arch - Install archtecure specific iommu functions
+ * @ops:   a pointer to architecture specific iommu functions
+ *
+ * There are several kind of iommu algorithm(tlb, pagetable) among
+ * omap series. This interface installs such an iommu algorighm.
+ **/
+int install_iommu_arch(const struct iommu_functions **ops)
+{
+   if (*ops)
+   return -EBUSY;
+   *ops = omap2_iommu_ops;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(install_iommu_arch);
+
+/**
+ * uninstall_iommu_arch - Uninstall archtecure specific iommu functions
+ * @ops:   a pointer to architecture specific iommu functions
+ *
+ * This interface uninstalls the iommu algorighm installed previously.
+ **/
+void uninstall_iommu_arch(const struct iommu_functions **ops)
+{
+   if (*ops != omap2_iommu_ops)
+   pr_err(%s: not your arch\n, __func__);
+
+   *ops = NULL;
+}
+EXPORT_SYMBOL_GPL(uninstall_iommu_arch);
+
 static int __init omap2_iommu_init(void)
 {
-   return install_iommu_arch(omap2_iommu_ops);
+   return 0;
 }
 module_init(omap2_iommu_init);

 static void __exit omap2_iommu_exit(void)
 {
-   uninstall_iommu_arch(omap2_iommu_ops);
+   /* Do nothing */
 }
 module_exit(omap2_iommu_exit);

diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 174f1b9..1c8e7ee 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -177,9 +177,6 @@ extern int iommu_set_isr(const char *name,
 extern void iommu_save_ctx(struct iommu *obj);
 extern void iommu_restore_ctx(struct iommu *obj);

-extern int install_iommu_arch(const struct iommu_functions *ops);
-extern void uninstall_iommu_arch(const struct iommu_functions *ops);
-
 extern int foreach_iommu_device(void *data,
int (*fn)(struct device *, void *));

diff --git a/arch/arm/plat-omap/include/plat/iommu2.h
b/arch/arm/plat-omap/include/plat/iommu2.h
index 10ad05f..8189f58 100644
--- a/arch/arm/plat-omap/include/plat/iommu2.h
+++ b/arch/arm/plat-omap/include/plat/iommu2.h
@@ -80,6 +80,9 @@
 #define MMU_RAM_MIXED_MASK (1  MMU_RAM_MIXED_SHIFT)
 #define MMU_RAM_MIXED  MMU_RAM_MIXED_MASK

+extern int install_iommu_arch(const struct iommu_functions **ops);
+extern void uninstall_iommu_arch(const struct iommu_functions **ops);
+
 /*
  * register accessors
  */
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index 8a51fd5..f088929 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -37,38 +37,6 @@ static struct platform_driver omap_iommu_driver;
 static struct kmem_cache *iopte_cachep;

 /**
- * install_iommu_arch - Install archtecure specific iommu functions
- * @ops:   a pointer to architecture specific iommu functions
- *
- * There are several kind of iommu algorithm(tlb, pagetable) among
- * omap series. This interface installs such an iommu algorighm.
- **/
-int install_iommu_arch(const struct iommu_functions *ops)
-{
-   if (arch_iommu)
-   return -EBUSY;
-
-   arch_iommu = ops;
-   return 0;
-}
-EXPORT_SYMBOL_GPL(install_iommu_arch);
-
-/**
- * uninstall_iommu_arch - Uninstall archtecure specific iommu functions
- * @ops:   a pointer to architecture specific iommu functions
- *
- * This

Re: [PATCH] OMAP: iovmm: fix SW flags passed by user

2011-03-25 Thread Russell King - ARM Linux

On Fri, Mar 25, 2011 at 12:36:57PM -0500, Ramirez Luna, Omar wrote:
 On Fri, Mar 25, 2011 at 12:30 PM, Sergei Shtylyov sshtyl...@mvista.com 
 wrote:
  Hello.
 
  Omar Ramirez Luna wrote:
 
  Commit d038aee24dcd changes iovmm to receive flags specified by user,
 
    Please also specify that commit's summary for the human readers. Bare ID
  is only usable to gitweb...
 
 Here it is the patch, introducing the change:
 
 https://patchwork.kernel.org/patch/620871/
 
 If accepted by Hiroshi, I can update the description making reference
 to this patch instead of commit.

It is a requirement that all descriptions which refer to a commit shall
contain both the commit ID *and* the summary line for that commit.
Failure to ensure that's the case results in rejection of the patch
until it conforms.
--
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: [RFC PATCH 2/2] OMAP2+: PANDA: Fix up random or missing MAC addresses for eth0 and wlan0

2011-03-25 Thread Jason Kridner

On Fri, Mar 25, 2011 at 3:39 AM, Hema Kalliguddi hem...@ti.com wrote:
 Hi,

 one Minor comment.

-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Andy Green
Sent: Friday, March 25, 2011 2:58 AM
To: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org
Cc: patc...@linaro.org; nicolas.pi...@linaro.org;
a...@arndb.de; x0132...@ti.com; s-...@ti.com;
t...@atomide.com; Alan Cox; Andy Green
Subject: [RFC PATCH 2/2] OMAP2+: PANDA: Fix up random or
missing MAC addresses for eth0 and wlan0

This patch registers a network device notifier callback to set the mac
addresses for the onboard network assets of Panda correctly,
despite the
drivers involved have used a random or all-zeros MAC address.

The technique was suggested by Alan Cox on lkml.

It works by device path so it corrects the MAC addresses even if the
drivers are in modules loaded in an order that changes their interface
name from usual (eg, the onboard module might be wlan1 if there is a
USB wireless stick plugged in and its module is inserted first.)

Cc: Alan Cox a...@lxorguk.ukuu.org.uk
Signed-off-by: Andy Green andy.gr...@linaro.org

I very much like this approach.  I believed the ability to use the die
ID to get a unique code was reasonable approach and that is why I
didn't get an EEPROM put onto the BeagleBoard, though Gerald is
looking at adding one on a future revision because the lack of one
wasn't well received.  Minor questions below.

---

 arch/arm/mach-omap2/board-omap4panda.c |   91

 1 files changed, 91 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 80b8860..0b92873 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -28,9 +28,12 @@
 #include linux/regulator/machine.h
 #include linux/regulator/fixed.h
 #include linux/wl12xx.h
+#include linux/netdevice.h
+#include linux/if_ether.h

 #include mach/hardware.h
 #include mach/omap4-common.h
+#include mach/id.h
 #include asm/mach-types.h
 #include asm/mach/arch.h
 #include asm/mach/map.h
@@ -506,6 +509,92 @@ static inline void board_serial_init(void)
 }
 #endif

+/*
+ * These device paths represent the onboard USB - Ethernet
bridge, and
+ * the WLAN module on Panda, both of which need their random
or all-zeros
+ * mac address replacing with a per-cpu stable generated one
+ */
+
+static const char * const panda_fixup_mac_device_paths[] = {
+      usb1/1-1/1-1.1/1-1.1:1.0,
+      mmc1:0001:2,
+};
+
+static int panda_device_path_need_mac(struct device *dev)
+{
+      const char **try = panda_fixup_mac_device_paths;
+      const char *path;
+      int count = ARRAY_SIZE(panda_fixup_mac_device_paths);
+      const char *p;
+      int len;
+      struct device *devn;
+
+      while (count--) {
+
+              p = *try + strlen(*try);
+              devn = dev;
+
+              while (devn) {
+
+                      path = dev_name(devn);
+                      len = strlen(path);
+
+                      if ((p - *try)  len) {
+                              devn = NULL;
+                              continue;
+                      }
+
+                      p -= len;
+
+                      if (strncmp(path, p, len)) {
+                              devn = NULL;
+                              continue;
+                      }
+
+                      devn = devn-parent;
+                      if (p == *try)
+                              return count;
+
+                      if (devn != NULL  (p - *try)  2)
+                              devn = NULL;
+
+                      p--;
+                      if (devn != NULL  *p != '/')
+                              devn = NULL;
+              }
+
+              try++;
+      }
+
+      return -ENOENT;
+}
+
+static int omap_panda_netdev_event(struct notifier_block *this,
+                                               unsigned long

The use of the OMAP die id below makes this OMAP specific and the list
referenced below of the devices to be referenced makes it Panda
specific.  Is there a way to make the list board specific, but to make
these functions that will be used across many OMAP platforms reusable?
 I believe that this current code will result in a lot of
cut-and-paste.  My preference is that this is accepted and that we
make this more general when we add this to other OMAP platforms, but
it'd be great to capture your suggestions on how to do so before those
cut-and-paste patch sets start coming in.

event, void *ptr)
+{
+      struct net_device *dev = ptr;
+      struct sockaddr sa;
+      int n;
+
+      if (event != NETDEV_REGISTER)
+              return NOTIFY_DONE;
+
+      n = panda_device_path_need_mac(dev-dev.parent);
+      if (n = 0) {
+              sa.sa_family = dev-type;
+              omap2_die_id_to_ethernet_mac(sa.sa_data, n);
+              dev-netdev_ops-ndo_set_mac_address(dev, sa);

[PATCH v2] OMAP: iovmm: fix SW flags passed by user

2011-03-25 Thread Omar Ramirez Luna

Commit d038aee24dcd5a2a0d8547f5396f67ae9698ac8e
omap: iovmm: don't check 'da' to set IOVMF_DA_FIXED flag,
changes iovmm to receive flags specified by user, however
the upper 16 bits of the flags are wiped by iovmm itself.

This fixes IOVMF_DA_FIXED flags from being lost, and lets the user
map its desired device addresses.

Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---

v2:
Include missing reference (commit and name) to patch in
description.

 arch/arm/plat-omap/include/plat/iovmm.h |3 ---
 arch/arm/plat-omap/iovmm.c  |4 
 2 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/iovmm.h 
b/arch/arm/plat-omap/include/plat/iovmm.h
index 32a2f6c..e992b96 100644
--- a/arch/arm/plat-omap/include/plat/iovmm.h
+++ b/arch/arm/plat-omap/include/plat/iovmm.h
@@ -29,9 +29,6 @@ struct iovm_struct {
  * lower 16 bit is used for h/w and upper 16 bit is for s/w.
  */
 #define IOVMF_SW_SHIFT 16
-#define IOVMF_HW_SIZE  (1  IOVMF_SW_SHIFT)
-#define IOVMF_HW_MASK  (IOVMF_HW_SIZE - 1)
-#define IOVMF_SW_MASK  (~IOVMF_HW_MASK)UL
 
 /*
  * iovma: h/w flags derived from cam and ram attribute
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 51ef43e..83a37c5 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -648,7 +648,6 @@ u32 iommu_vmap(struct iommu *obj, u32 da, const struct 
sg_table *sgt,
return PTR_ERR(va);
}
 
-   flags = IOVMF_HW_MASK;
flags |= IOVMF_DISCONT;
flags |= IOVMF_MMIO;
 
@@ -706,7 +705,6 @@ u32 iommu_vmalloc(struct iommu *obj, u32 da, size_t bytes, 
u32 flags)
if (!va)
return -ENOMEM;
 
-   flags = IOVMF_HW_MASK;
flags |= IOVMF_DISCONT;
flags |= IOVMF_ALLOC;
 
@@ -795,7 +793,6 @@ u32 iommu_kmap(struct iommu *obj, u32 da, u32 pa, size_t 
bytes,
if (!va)
return -ENOMEM;
 
-   flags = IOVMF_HW_MASK;
flags |= IOVMF_LINEAR;
flags |= IOVMF_MMIO;
 
@@ -853,7 +850,6 @@ u32 iommu_kmalloc(struct iommu *obj, u32 da, size_t bytes, 
u32 flags)
return -ENOMEM;
pa = virt_to_phys(va);
 
-   flags = IOVMF_HW_MASK;
flags |= IOVMF_LINEAR;
flags |= IOVMF_ALLOC;
 
-- 
1.7.1

--
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: iovmm: fix SW flags passed by user

On Fri, Mar 25, 2011 at 3:05 PM, Russell King - ARM Linux
li...@arm.linux.org.uk
  Commit d038aee24dcd changes iovmm to receive flags specified by user,
 
    Please also specify that commit's summary for the human readers. Bare ID
  is only usable to gitweb...

 Here it is the patch, introducing the change:

 https://patchwork.kernel.org/patch/620871/

 If accepted by Hiroshi, I can update the description making reference
 to this patch instead of commit.

 It is a requirement that all descriptions which refer to a commit shall
 contain both the commit ID *and* the summary line for that commit.
 Failure to ensure that's the case results in rejection of the patch
 until it conforms.

Not a problem then... resending v2.

Regards,

Omar
--
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: [RFC PATCH 2/2] OMAP2+: PANDA: Fix up random or missing MAC addresses for eth0 and wlan0

On Friday 25 March 2011 21:13:05 Jason Kridner wrote:
 The use of the OMAP die id below makes this OMAP specific and the list
 referenced below of the devices to be referenced makes it Panda
 specific.  Is there a way to make the list board specific, but to make
 these functions that will be used across many OMAP platforms reusable?
  I believe that this current code will result in a lot of
 cut-and-paste.  My preference is that this is accepted and that we
 make this more general when we add this to other OMAP platforms, but
 it'd be great to capture your suggestions on how to do so before those
 cut-and-paste patch sets start coming in.
 
Do you know of other existing boards without the EEPROM?
If we need the code to be more general, it will simply have
to move out of the panda specific board file into one file
that can be selected for compilation by other boards.

  static void __init omap4_panda_init(void)
  {
int package = OMAP_PACKAGE_CBS;
 @@ -517,6 +606,8 @@ static void __init omap4_panda_init(void)
if (wl12xx_set_platform_data(omap_panda_wlan_data))
pr_err(error setting wl12xx data\n);
 
 +  register_netdevice_notifier(omap_panda_netdev_notifier);
 +
 
 I just want to make sure I understand how this works.  When a new
 network device is added, if the device name matches one of the above
 listed device paths, then the die id based MAC id is applied.  This
 must be done via a device registration notifier as the registration is
 triggered when the device is detected.

Correct.

Arnd
--
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: [RFC PATCH 2/2] OMAP2+: PANDA: Fix up random or missing MAC addresses for eth0 and wlan0

2011-03-25 Thread Nicolas Pitre

On Fri, 25 Mar 2011, Jason Kridner wrote:

 I very much like this approach.  I believed the ability to use the die
 ID to get a unique code was reasonable approach and that is why I
 didn't get an EEPROM put onto the BeagleBoard, though Gerald is
 looking at adding one on a future revision because the lack of one
 wasn't well received.  Minor questions below.

If this code had been available and/or the procedure well documented 
before then I believe the reception would have been better.

 The use of the OMAP die id below makes this OMAP specific and the list
 referenced below of the devices to be referenced makes it Panda
 specific.  Is there a way to make the list board specific, but to make
 these functions that will be used across many OMAP platforms reusable?
  I believe that this current code will result in a lot of
 cut-and-paste.  My preference is that this is accepted and that we
 make this more general when we add this to other OMAP platforms, but
 it'd be great to capture your suggestions on how to do so before those
 cut-and-paste patch sets start coming in.

It is true that this might get copied.  But as I suggested to Andy, it 
is best to wait and see how often this happens before generalizing the 
approach.  Consolidation is easier when you can see what is actually 
common and what is board specific.  Otherwise it is easy to 
fall into the over-engineering trap.


Nicolas
--
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: [RFC PATCH 2/2] OMAP2+: PANDA: Fix up random or missing MAC addresses for eth0 and wlan0


On 03/25/2011 08:13 PM, Somebody in the thread at some point said:

Hi -


I very much like this approach.  I believed the ability to use the die
ID to get a unique code was reasonable approach and that is why I
didn't get an EEPROM put onto the BeagleBoard, though Gerald is
looking at adding one on a future revision because the lack of one
wasn't well received.  Minor questions below.


Great.  FWIW I think it'd be a lost opportunity to wire the EEPROM 
direct to the network device.  It's more flexible and powerful to regard 
the EEPROM as general board identity storage, a way to bind 
information to the physical board.  Then you can stick any kind of 
information that you need to bind to the board in the same 25c device 
and in-kernel code can take care of discovering that data when needed on 
any subsystem that takes an interest.



The use of the OMAP die id below makes this OMAP specific and the list
referenced below of the devices to be referenced makes it Panda
specific.  Is there a way to make the list board specific, but to make
these functions that will be used across many OMAP platforms reusable?
  I believe that this current code will result in a lot of
cut-and-paste.  My preference is that this is accepted and that we
make this more general when we add this to other OMAP platforms, but
it'd be great to capture your suggestions on how to do so before those
cut-and-paste patch sets start coming in.


Sure, I would be happy to put this stuff at OMAP platform layer for 
example if it makes sense to OMAP guys more generally.



I just want to make sure I understand how this works.  When a new
network device is added, if the device name matches one of the above
listed device paths, then the die id based MAC id is applied.  This
must be done via a device registration notifier as the registration is
triggered when the device is detected.


That's right.  Arguably it would be better if there was a core API to 
register your board-specific uniqueness / entropy, and the drivers were 
able to use that instead of random ethernet address all in network 
layer.   But after wasting two weeks getting pointlessly beaten up on 
lkml largely on the question of how generic this issue is, I would 
rather restart somewhere specific where everyone can see the obvious 
benefit and if it's seen as more useful migrate it.


-Andy
--
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/RFC 00/19] OMAP: voltage layer cleanup and restructure

2011-03-25 Thread Paul Walmsley


Hi Kevin

you might want to consider renaming 

OMAP3_PRM_VC_VDD_MPU_ID

etc. to something like:

OMAP3_VC_VDD_MPU_ID

and to define those in some vc.h header file.

Also, I'd suggest moving the struct omap_prm_vc_ops assignments out of the 
prm*.c code into the vc_data.c files, ideally into some initcall, and 
renaming the struct omap_prm_vc_ops to simply struct omap_vc_ops.

As long as the VC's low-level registers are in the PRM, those reads/writes 
should happen through PRM code, IMHO.


- Paul
--
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/RFC 00/19] OMAP: voltage layer cleanup and restructure

Paul Walmsley p...@pwsan.com writes:

 Hi Kevin

 you might want to consider renaming 

 OMAP3_PRM_VC_VDD_MPU_ID

 etc. to something like:

 OMAP3_VC_VDD_MPU_ID

 and to define those in some vc.h header file.

OK

 Also, I'd suggest moving the struct omap_prm_vc_ops assignments out of the 
 prm*.c code into the vc_data.c files, ideally into some initcall, and 
 renaming the struct omap_prm_vc_ops to simply struct omap_vc_ops.

OK

 As long as the VC's low-level registers are in the PRM, those reads/writes 
 should happen through PRM code, IMHO.

OK, what I will probably do then is at least create some
omapX_prm_vc_read/write/rmw functions in prm.c.  The prototypes for
these will be identical for OMAP3  4, so the read/writes can be called
from SoC independent code (via func ptrs) as needed.

I'll try this approach on Monday.

Kevin
--
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: l3: fix for irq 10: nobody cared message

2011-03-25 Thread Omar Ramirez Luna

If an error occurs in the L3 on any other initiator than MPU,
the interrupt goes unhandled given that the 'base' register
was calculated with the initialized err_base value (which
coincidentally points to MPU) and not with the actual source
of the error.

Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
 arch/arm/mach-omap2/omap_l3_smx.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_l3_smx.c 
b/arch/arm/mach-omap2/omap_l3_smx.c
index 5f2da75..da917c2 100644
--- a/arch/arm/mach-omap2/omap_l3_smx.c
+++ b/arch/arm/mach-omap2/omap_l3_smx.c
@@ -196,11 +196,12 @@ static irqreturn_t omap3_l3_app_irq(int irq, void *_l3)
/* No timeout error for debug sources */
}
 
-   base = ((l3-rt) + (*(omap3_l3_bases[int_type] + err_source)));
-
/* identify the error source */
for (err_source = 0; !(status  (1  err_source)); err_source++)
;
+
+   base = ((l3-rt) + (*(omap3_l3_bases[int_type] + err_source)));
+
error = omap3_l3_readll(base, L3_ERROR_LOG);
 
if (error) {
-- 
1.7.1

--
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: l3: fix for irq 10: nobody cared message