Re: [PATCH v10 0/7] mmc: omap_hsmmc: pbias dt and cleanup
On Monday 13 January 2014 09:06 PM, Balaji T K wrote: Few cleanups to reduce code indent, Add pbias_regulator support and adapt omap_hsmmc to use pbias regulator to configure required voltage on mmc1 pad(SD card) i/o rails on OMAP SoCs. Hi Tony, Considering the dependencies with regulator, defconfig, mmc and device tree, Is it possible for you to pick this series. Thanks and Regards, Balaji T K Balaji T K (7): mmc: omap_hsmmc: use devm_regulator API mmc: omap_hsmmc: handle vcc and vcc_aux independently regulator: add pbias regulator support mmc: omap_hsmmc: adapt hsmmc to use pbias regulator ARM: dts: add pbias dt node ARM: OMAP: enable SYSCON and REGULATOR_PBIAS in omap2plus_defconfig mmc: omap_hsmmc: remove pbias workaround .../bindings/regulator/pbias-regulator.txt | 27 ++ arch/arm/boot/dts/dra7.dtsi| 17 ++ arch/arm/boot/dts/omap2430.dtsi| 17 ++ arch/arm/boot/dts/omap3.dtsi | 17 ++ arch/arm/boot/dts/omap4.dtsi | 17 ++ arch/arm/boot/dts/omap5.dtsi | 17 ++ arch/arm/configs/omap2plus_defconfig |2 + drivers/mmc/host/omap_hsmmc.c | 111 + drivers/regulator/Kconfig |9 + drivers/regulator/Makefile |1 + drivers/regulator/pbias-regulator.c| 255 11 files changed, 441 insertions(+), 49 deletions(-) create mode 100644 Documentation/devicetree/bindings/regulator/pbias-regulator.txt create mode 100644 drivers/regulator/pbias-regulator.c -- 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 v1 0/2] mtd: nand: omap: booting from NAND using u-boot
Hi Brian, From: Gupta, Pekon I'm preparing a 3.14 pull request soon, and since you seem committed to fixing and properly testing a known regression here, I'd like to see this go in. But given the late timing and the unanswered questions, I think it's unlikely to go in -rc1. Perhaps I can send a later pull request if we can get it together properly. Yes, if the above details are sufficient, then I'll: (1) re-word [PATCH 1/2] commit log title to mention that it's a clean-up (2) Add above description and details of regression into commit log of [PATCH 2/2] (3) Include your other comments on individual patches. So I'd like to first of all get a few answers to my questions, and then I think we might want to refresh this patch series with a little better commit messages and perhaps a separate documentation file (not necessarily in the same patch series, as the fix is more urgent). Do my previous responses look complete to you for re-submission ? with regards, pekon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] power_supply: bq24261 charger driver
Hi!
+#define DEV_MANUFACTURER TI
+#define DEV_MANUFACTURER_NAME_SIZE 4
This is unneccessarily complicated for no reason. You copy TI to
struct, just so that ou can return pointer to the field on
get_property.
What about simply returning TI from get_property, without defines
and copying?
+#define BQ24261_MIN_CV 3500
+#define BQ24261_MAX_CV 4440
Other defines use uV as an unit :-(.
+static void lookup_regval(u16 tbl[][2], size_t size, u16 in_val, u8 *out_val)
+{
+ int i;
+
+ for (i = 1; i size; ++i)
+ if (in_val tbl[i][0])
+ break;
+
+ *out_val = (u8) tbl[i - 1][1];
+}
Umm. Could we simply return the value?
+static void bq24261_cc_to_reg(int cc, u8 *reg_val)
+{
+
+ cc = cc BQ24261_MAX_CC ? cc : BQ24261_MAX_CC;
+ cc = cc - BQ24261_MIN_CC;
clamp_t?
+ *reg_val = cc 0 ? ((cc/100) 3) 0xFF : 0;
+}
Just return the value?
+static void bq24261_cv_to_reg(int cv, u8 *reg_val)
+{
+ int val;
+
+ val = clamp_t(int, cv, BQ24261_MIN_CV, BQ24261_MAX_CV);
+ *reg_val =
+ (((val - BQ24261_MIN_CV) / BQ24261_CV_DIV)
+ BQ24261_CV_BIT_POS);
+}
Not sure if the defines really make it more readable. It should be
consistent with the above/below functions...
+static inline void bq24261_iterm_to_reg(int iterm, u8 *regval)
+{
+ iterm = iterm BQ24261_MAX_ITERM ? iterm : BQ24261_MAX_ITERM;
+ iterm = iterm - BQ24261_MIN_ITERM;
clamp_t?
+ *regval = iterm 0 ? (iterm/50) 0xFF : 0;
+}
Just return the value.
+static inline void bq24261_sfty_tmr_to_reg(int tmr, u8 *regval)
+{
+ return lookup_regval(bq24261_sfty_tmr, ARRAY_SIZE(bq24261_sfty_tmr),
+ tmr, regval);
+}
Just return the value... returning void values with explicit return is
interesting.
+ /* If status is fault, wait for READY before enabling the charging */
+
+ if (!is_ready) {
+ ret = wait_event_timeout(chip-wait_ready,
+ (chip-chrgr_stat != BQ24261_CHRGR_STAT_READY),
+ HZ);
+ dev_info(chip-client-dev,
+ chrgr_stat=%x\n, chip-chrgr_stat);
+ if (ret == 0) {
+ dev_err(chip-client-dev,
+ Waiting for Charger Ready Failed.Enabling
charging anyway\n);
+ }
+ }
So charger has a problem, and we force it on, anyway? Also put space
after ..
+static inline int bq24261_set_cv(struct bq24261_charger *chip, int cv)
+{
+ int bat_volt;
+ int ret;
+ u8 reg_val;
+ u8 vindpm_val = 0x0;
+
+ /*
+ * Setting VINDPM value as per the battery voltage
+ * VBatt Vindpm Register Setting
+ * 3.7v 4.2v 0x0 (default)
+ * 3.71v - 3.96v4.36v 0x2
+ * 3.96v 4.6v 0x5
+ */
+ ret = get_battery_voltage(bat_volt);
+ if (ret) {
+ dev_err(chip-client-dev,
+ Error getting battery voltage!!\n);
+ } else {
You forget the error value and continue anyway.
+static inline void resume_charging(struct bq24261_charger *chip)
+{
+
+ if (chip-is_charger_enabled)
+ bq24261_enable_charger(chip, true);
+ if (chip-inlmt)
+ bq24261_set_inlmt(chip, chip-inlmt);
+ if (chip-cc)
+ bq24261_set_cc(chip, chip-cc);
+ if (chip-cv)
+ bq24261_set_cv(chip, chip-cv);
+ if (chip-is_charging_enabled)
+ bq24261_enable_charging(chip, true);
What about some error checking?
Is it wise to enable charging when setting voltage failed?
+static inline bool is_bq24261_enabled(struct bq24261_charger *chip)
+{
+ if (chip-cable_type == PSY_CHARGER_CABLE_TYPE_NONE)
+ return false;
+ else if (!chip-is_charger_enabled)
+ return false;
Kill the else.
+static inline int get_battery_voltage(int *volt)
+{
+ struct power_supply *psy;
+ union power_supply_propval val;
+ int ret;
+
+ psy = get_psy_battery();
+ if (!psy)
+ return -EINVAL;
Hmm. Does this assume just one battery in the system?
Is it good idea? Older machines contain main and memory backup
batteries. Newer machines contain keyboard and display battery
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 2/4] power_supply: Introduce generic psy charging driver
Hi!
+Throttling configuration example:
+
+struct psy_throttle_state my_throttle_states[] = {
+
+ /* Level 0: Limit charge current to 1500mA. Normal Level */
+ {
+ .throttle_action = PSY_THROTTLE_CC_LIMIT,
+ .throttle_val = 1500,
+ },
+
+ /* Level 1: Limit charge current to 500mA */
+ {
+ .throttle_action = PSY_THROTTLE_CC_LIMIT,
+ .throttle_val = 500,
+ },
+
+ /*
+ * Level 2: Disable charging: Stop charging, charger supply power to
+ * platform.
+ */
+ {
+ .throttle_action = PSY_THROTTLE_DISABLE_CHARGING,
+ },
+
+ /* Level 3: Disable charger: Battery start discharging */
+ {
+ .throttle_action = PSY_THROTTLE_DISABLE_CHARGER,
+ },
+
+};
Does it make sense to have throttling description as a data, as
opposed to normal C code?
+struct psy_charger_context {
+ bool is_usb_cable_evt_reg;
+ int psyc_cnt;
+ int batt_status;
+ /*cache battery and charger properties */
Comment coding style. Please run you patches through checkpatch.
+ struct list_head evt_queue;
+ struct mutex evt_lock;
+ struct list_head event_queue;
+ struct psy_batt_chrg_prof batt_property;
Again, please use full words in variable names. How am I supposed to
know what evt_queue is? Especially when you have event_queue, also?!
And please do it globally.
+static void __power_supply_trigger_charging_handler(struct power_supply *psy)
+{
+ int i;
+ struct power_supply *psb = NULL;
+
+
+ if (is_trigger_charging_algo(psy)) {
+ if (psy_is_battery(psy)) {
+ if (trigger_algo(psy))
+ enable_supplied_by_charging(psy, false);
+ else
+ enable_supplied_by_charging(psy, true);
+ } else if (psy_is_charger(psy)) {
+ for (i = 0; i psy-num_supplicants; i++) {
+ psb =
+ power_supply_get_by_name(psy-
+ supplied_to[i]);
+
+ if (psb psy_is_battery(psb)
+ psy_is_present(psb)) {
+ if (trigger_algo(psb)) {
+ psy_disable_charging(psy);
+ break;
+ } else if
+ (psy_is_charging_can_be_enabled
+ (psy)) {
+ psy_enable_charging(psy);
+ wait_for_charging_enabled(psy);
+ }
+ }
+ }
+ }
+ update_sysfs(psy);
+ power_supply_changed(psy);
+ }
+}
See coding style about excessive nesting. Please fix it globally.
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 3/4] power_supply: Introduce PSE compliant algorithm
Hi!
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -22,6 +22,19 @@ config POWER_SUPPLY_CHARGER
drivers to keep the charging logic outside and the charger driver
just need to abstract the charger hardware.
+config POWER_SUPPLY_CHARGING_ALGO_PSE
+ bool PSE compliant charging algorithm
+ help
+ Say Y here to select Product Safety Engineering (PSE) compliant
+ charging algorithm. As per PSE standard the battery characteristics
+ and thereby the charging rates can vary on different temperature
+ zones. This config will enable PSE compliant charging algorithm with
+ maintenance charging support. At runtime the algorithm will be
+ selected by the psy charger driver based on the type of the battery
+ charging profile.
Information where to expect PSE compliant chargers would be nice.
+static inline bool __is_battery_full
+ (long volt, long cur, long iterm, unsigned long cv)
+{
codingstyle.
+ pr_devel(%s:current=%ld pse_mod_bprof-chrg_term_mA =%ld
voltage_now=%ld full_cond=%ld,
+ __func__, cur, iterm, volt * 100, (FULL_CV_MIN * cv));
+
+ return (cur 0) (cur = iterm)
+ ((volt * 100) = (FULL_CV_MIN * cv));
Codingstyle. Just run checkpatch.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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] dmaengine: omap-dma: split header file
On Friday 24 January 2014 10:21 PM, Balaji T K wrote:
To Resolve build failure seen with sh-allmodconfig:
include/linux/omap-dma.h:171:8: error: expected identifier before numeric
constant
make[4]: *** [drivers/mmc/host/omap_hsmmc.o] Error 1
due to CCR redefinition, move dmaengine consumer specific function to
omap-dmaengine.h
Tested-by: Geert Uytterhoeven ge...@linux-m68k.org
Signed-off-by: Balaji T K balaj...@ti.com
Hi Russell,
Ping,
If this patch looks OK, I can drop RFC and post as Patch, let me know.
Thanks and Regards,
Balaji T K
---
drivers/mmc/host/omap_hsmmc.c |2 +-
include/linux/omap-dma.h | 19 +--
include/linux/omap-dmaengine.h | 21 +
3 files changed, 23 insertions(+), 19 deletions(-)
create mode 100644 include/linux/omap-dmaengine.h
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index dbd32ad..2f57e36 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -31,7 +31,7 @@
#include linux/of.h
#include linux/of_gpio.h
#include linux/of_device.h
-#include linux/omap-dma.h
+#include linux/omap-dmaengine.h
#include linux/mmc/host.h
#include linux/mmc/core.h
#include linux/mmc/mmc.h
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 7af25a9..6aa97e5 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -1,23 +1,6 @@
-/*
- * OMAP DMA Engine support
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
#ifndef __LINUX_OMAP_DMA_H
#define __LINUX_OMAP_DMA_H
-
-struct dma_chan;
-
-#if defined(CONFIG_DMA_OMAP) || defined(CONFIG_DMA_OMAP_MODULE)
-bool omap_dma_filter_fn(struct dma_chan *, void *);
-#else
-static inline bool omap_dma_filter_fn(struct dma_chan *c, void *d)
-{
- return false;
-}
-#endif
+#include linux/omap-dmaengine.h
/*
* Legacy OMAP DMA handling defines and functions
diff --git a/include/linux/omap-dmaengine.h b/include/linux/omap-dmaengine.h
new file mode 100644
index 000..2b0b6aa
--- /dev/null
+++ b/include/linux/omap-dmaengine.h
@@ -0,0 +1,21 @@
+/*
+ * OMAP DMA Engine support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __LINUX_OMAP_DMAENGINE_H
+#define __LINUX_OMAP_DMAENGINE_H
+
+struct dma_chan;
+
+#if defined(CONFIG_DMA_OMAP) || defined(CONFIG_DMA_OMAP_MODULE)
+bool omap_dma_filter_fn(struct dma_chan *, void *);
+#else
+static inline bool omap_dma_filter_fn(struct dma_chan *c, void *d)
+{
+ return false;
+}
+#endif
+#endif /* __LINUX_OMAP_DMAENGINE_H */
--
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] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot
On Tuesday 21 January 2014 04:59 AM, Nishanth Menon wrote: When device is booted using devicetree, platforms impacted by Erratum 2.1.1.128 is not detected easily in the mmc driver. This erratum indicates that the module cannot do multi-block transfers. Handle this by providing a boolean flag to indicate to driver that it is working on a hardware with mentioned limitation. Signed-off-by: Nishanth Menon n...@ti.com --- This explains the logs I see: OMAP3430 LDP (ES2.2): uImage only boot: http://slexy.org/raw/s2YrbMAi7c uImage+dtb concatenated boot: http://slexy.org/raw/s20qVg17T0 With the following flag set, device is now able to consistently boot with device tree supported uImage+dtb concat boot. .../devicetree/bindings/mmc/ti-omap-hsmmc.txt |2 ++ drivers/mmc/host/omap_hsmmc.c |3 +++ 2 files changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index 8c8908a..ab36f8b 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -26,6 +26,8 @@ specifier is required. dma-names: List of DMA request names. These strings correspond 1:1 with the DMA specifiers listed in dmas. The string naming is to be rx and tx for RX and TX DMA requests, respectively. +ti,erratum-2.1.1.128: boolean, for OMAP3430/OMAP35xx platforms with broken +multiblock reads Rather than ti,errata.. specific property, something like caps no/disable multiblock read is more readable in my opinion, Otherwise Acked-by: Balaji T K balaj...@ti.com Examples: diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 014bfe5..f2d5940 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1730,6 +1730,9 @@ static struct omap_mmc_platform_data *of_get_hsmmc_pdata(struct device *dev) if (of_find_property(np, ti,dual-volt, NULL)) pdata-controller_flags |= OMAP_HSMMC_SUPPORTS_DUAL_VOLT; + if (of_find_property(np, ti,erratum-2.1.1.128, NULL)) + pdata-controller_flags |= OMAP_HSMMC_BROKEN_MULTIBLOCK_READ; + /* This driver only supports 1 slot */ pdata-nr_slots = 1; pdata-slots[0].switch_pin = cd_gpio; -- 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] ARM: dts: omap3-ldp: fix mmc configuration
On Tuesday 21 January 2014 05:04 AM, Nishanth Menon wrote:
MMC1 is the only MMC interface available on the platform. Further,
since the platform is based on older revision of SoC which is not
capable of doing multi-block writes, mark it so and add pinmux
s/writes/read
Thanks and Regards,
Balaji T K
to ensure that all relevant pins are configured for non-MMC boot
mode.
Signed-off-by: Nishanth Menon n...@ti.com
---
ti,erratum-2.1.1.128 introduced in https://patchwork.kernel.org/patch/3514851/
hence depends on the same.
arch/arm/boot/dts/omap3-ldp.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
index ddce0d8..bc0cc66 100644
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -176,6 +176,17 @@
mmc1 {
vmmc-supply = vmmc1;
bus-width = 4;
+ ti,erratum-2.1.1.128;
+ pinctrl-names = default;
+ pinctrl-0 = mmc1_pins;
+};
+
+mmc2 {
+ status=disabled;
+};
+
+mmc3 {
+ status=disabled;
};
omap3_pmx_core {
@@ -209,6 +220,17 @@
0x174 (PIN_OUTPUT | MUX_MODE0) /*
hsusb0_stp.hsusb0_stp */
;
};
+
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x2144, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_clk.mmc1_clk */
+ OMAP3_CORE1_IOPAD(0x2146, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_cmd.mmc1_cmd */
+ OMAP3_CORE1_IOPAD(0x2148, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_dat0.mmc1_dat0 */
+ OMAP3_CORE1_IOPAD(0x214A, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_dat1.mmc1_dat1 */
+ OMAP3_CORE1_IOPAD(0x214C, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_dat2.mmc1_dat2 */
+ OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_dat3.mmc1_dat3 */
+ ;
+ };
};
usb_otg_hs {
--
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 3/5] char: ti-usim: Add driver for USIM module on AM43xx
Hi Satish, On 01/20/2014 06:33 AM, Satish Patel wrote: TI-USIM driver is a platform driver that provides a character driver interface to user applications. It allows user applications to call IOCTL's to perform smart card operations. Driver currently supports - ATR - T=0 T=1 protocol - clock stop mode - smart card clock configuration - Tx/Rx application data units (APDU) to smart card - Interface to PHY using DT phy interface Validation is done with ACOS3 smart cards Signed-off-by: Satish Patel satish.pa...@ti.com --- .../devicetree/bindings/ti-usim/ti-usim.txt| 31 + drivers/char/Kconfig |7 + drivers/char/Makefile |1 + drivers/char/ti-usim-hw.h | 863 + drivers/char/ti-usim.c | 1859 ti-usim.c is a very large driver that does everything but looks like limited to TI hardware. How about splitting it into generic stuff and hw specific glue logic so that most of the generic stuff could be used by different hardware types. include/linux/ti-usim.h| 98 + 6 files changed, 2859 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/ti-usim/ti-usim.txt create mode 100644 drivers/char/ti-usim-hw.h create mode 100644 drivers/char/ti-usim.c create mode 100644 include/linux/ti-usim.h cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usb: musb: host: Fix SuperSpeed hub enumeration
From: Ajay Kumar Gupta ajay.gu...@ti.com Disables PING on status phase of control transfer. PING token is not mandatory in status phase of control transfer and so some high speed USB devices don't support it. If such devices are connected to MUSB then they would not respond to PING token causing delayed or failed enumeration. [Roger Q] Fixes enumeration issues with some Super-Speed USB hubs e.g. Dlink DUB-1340 Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Signed-off-by: Roger Quadros rog...@ti.com Acked-by: Felipe Balbi ba...@ti.com --- drivers/usb/musb/musb_host.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c index ed45572..abb38c3 100644 --- a/drivers/usb/musb/musb_host.c +++ b/drivers/usb/musb/musb_host.c @@ -1183,6 +1183,9 @@ irqreturn_t musb_h_ep0_irq(struct musb *musb) csr = MUSB_CSR0_H_STATUSPKT | MUSB_CSR0_TXPKTRDY; + /* disable ping token in status phase */ + csr |= MUSB_CSR0_H_DIS_PING; + /* flag status stage */ musb-ep0_stage = MUSB_EP0_STATUS; -- 1.8.3.2 -- 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/2] usb: musb: host: fixes for 3.14-rc
Hi Greg, Patch 1 fixes SuperSpeed hub enumeration on beaglebone. Patch 2 fixes remote-wakeup resume on beaglebone. Felipe has Acked the 1st patch but still needs to Ack the 2nd one. Patches are based on 3.14-rc1 cheers, -roger Ajay Kumar Gupta (1): usb: musb: host: Fix SuperSpeed hub enumeration Roger Quadros (1): usb: musb: core: Fix remote-wakeup resume drivers/usb/musb/musb_core.c | 10 +- drivers/usb/musb/musb_host.c | 3 +++ 2 files changed, 12 insertions(+), 1 deletion(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb: musb: core: Fix remote-wakeup resume
During resume don't touch SUSPENDM/RESUME bits of POWER register while restoring controller context. These bits might be changed by the controller during resume operation and so will be different than what they were during suspend. e.g. SUSPENDM bit is set by software during USB global suspend but automatically cleared by the controller during remote wakeup or during resume. Setting this bit back while restoring context causes undesired behaviour. i.e. Babble interrupt is generated and USB is broken. Signed-off-by: Roger Quadros rog...@ti.com --- drivers/usb/musb/musb_core.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index fc192ad..a501542 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -2157,11 +2157,19 @@ static void musb_restore_context(struct musb *musb) void __iomem *musb_base = musb-mregs; void __iomem *ep_target_regs; void __iomem *epio; + u8 power; musb_writew(musb_base, MUSB_FRAME, musb-context.frame); musb_writeb(musb_base, MUSB_TESTMODE, musb-context.testmode); musb_write_ulpi_buscontrol(musb-mregs, musb-context.busctl); - musb_writeb(musb_base, MUSB_POWER, musb-context.power); + + /* Don't affect SUSPENDM/RESUME bits in POWER reg */ + power = musb_readb(musb_base, MUSB_POWER); + power = MUSB_POWER_SUSPENDM | MUSB_POWER_RESUME; + musb-context.power = ~(MUSB_POWER_SUSPENDM | MUSB_POWER_RESUME); + power |= musb-context.power; + musb_writeb(musb_base, MUSB_POWER, power); + musb_writew(musb_base, MUSB_INTRTXE, musb-intrtxe); musb_writew(musb_base, MUSB_INTRRXE, musb-intrrxe); musb_writeb(musb_base, MUSB_INTRUSBE, musb-context.intrusbe); -- 1.8.3.2 -- 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] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot
On 02/04/2014 06:44 AM, Balaji T K wrote: On Tuesday 21 January 2014 04:59 AM, Nishanth Menon wrote: When device is booted using devicetree, platforms impacted by Erratum 2.1.1.128 is not detected easily in the mmc driver. This erratum indicates that the module cannot do multi-block transfers. Handle this by providing a boolean flag to indicate to driver that it is working on a hardware with mentioned limitation. Signed-off-by: Nishanth Menon n...@ti.com --- This explains the logs I see: OMAP3430 LDP (ES2.2): uImage only boot: http://slexy.org/raw/s2YrbMAi7c uImage+dtb concatenated boot: http://slexy.org/raw/s20qVg17T0 With the following flag set, device is now able to consistently boot with device tree supported uImage+dtb concat boot. .../devicetree/bindings/mmc/ti-omap-hsmmc.txt |2 ++ drivers/mmc/host/omap_hsmmc.c |3 +++ 2 files changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index 8c8908a..ab36f8b 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -26,6 +26,8 @@ specifier is required. dma-names: List of DMA request names. These strings correspond 1:1 with the DMA specifiers listed in dmas. The string naming is to be rx and tx for RX and TX DMA requests, respectively. +ti,erratum-2.1.1.128: boolean, for OMAP3430/OMAP35xx platforms with broken +multiblock reads Rather than ti,errata.. specific property, something like caps no/disable multiblock read is more readable in my opinion, Otherwise Is'nt the better definition to state i have quirk X and allow the driver to do the necessary thing/things needed to handle quirk X? in this case, there is just one thing to do: broken multi_block_read, in the case of other quirks, there might be more than 1 thing to do.. let driver figure that out, dts just states the h/w capabilty or in this case, the quirk capability. Acked-by: Balaji T K balaj...@ti.com Examples: diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 014bfe5..f2d5940 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1730,6 +1730,9 @@ static struct omap_mmc_platform_data *of_get_hsmmc_pdata(struct device *dev) if (of_find_property(np, ti,dual-volt, NULL)) pdata-controller_flags |= OMAP_HSMMC_SUPPORTS_DUAL_VOLT; +if (of_find_property(np, ti,erratum-2.1.1.128, NULL)) +pdata-controller_flags |= OMAP_HSMMC_BROKEN_MULTIBLOCK_READ; + /* This driver only supports 1 slot */ pdata-nr_slots = 1; pdata-slots[0].switch_pin = cd_gpio; -- Regards, Nishanth Menon -- 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] ARM: dts: omap3-ldp: fix mmc configuration
On 02/04/2014 06:46 AM, Balaji T K wrote:
On Tuesday 21 January 2014 05:04 AM, Nishanth Menon wrote:
MMC1 is the only MMC interface available on the platform. Further,
since the platform is based on older revision of SoC which is not
capable of doing multi-block writes, mark it so and add pinmux
s/writes/read
arrgh.. yes.
Thanks and Regards,
Balaji T K
to ensure that all relevant pins are configured for non-MMC boot
mode.
Signed-off-by: Nishanth Menon n...@ti.com
---
ti,erratum-2.1.1.128 introduced in
https://patchwork.kernel.org/patch/3514851/
hence depends on the same.
arch/arm/boot/dts/omap3-ldp.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-ldp.dts
b/arch/arm/boot/dts/omap3-ldp.dts
index ddce0d8..bc0cc66 100644
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -176,6 +176,17 @@
mmc1 {
vmmc-supply = vmmc1;
bus-width = 4;
+ti,erratum-2.1.1.128;
+pinctrl-names = default;
+pinctrl-0 = mmc1_pins;
+};
+
+mmc2 {
+status=disabled;
+};
+
+mmc3 {
+status=disabled;
};
omap3_pmx_core {
@@ -209,6 +220,17 @@
0x174 (PIN_OUTPUT | MUX_MODE0) /*
hsusb0_stp.hsusb0_stp */
;
};
+
+mmc1_pins: pinmux_mmc1_pins {
+pinctrl-single,pins =
+OMAP3_CORE1_IOPAD(0x2144, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_clk.mmc1_clk */
+OMAP3_CORE1_IOPAD(0x2146, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_cmd.mmc1_cmd */
+OMAP3_CORE1_IOPAD(0x2148, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_dat0.mmc1_dat0 */
+OMAP3_CORE1_IOPAD(0x214A, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_dat1.mmc1_dat1 */
+OMAP3_CORE1_IOPAD(0x214C, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_dat2.mmc1_dat2 */
+OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_dat3.mmc1_dat3 */
+;
+};
};
usb_otg_hs {
--
Regards,
Nishanth Menon
--
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/2] usb: musb: host: fixes for 3.14-rc
On 02/04/2014 05:27 PM, Greg KH wrote: On Tue, Feb 04, 2014 at 03:25:47PM +0200, Roger Quadros wrote: Hi Greg, Patch 1 fixes SuperSpeed hub enumeration on beaglebone. Patch 2 fixes remote-wakeup resume on beaglebone. Felipe has Acked the 1st patch but still needs to Ack the 2nd one. Patches are based on 3.14-rc1 Why wouldn't these come into my tree from Felipe like normal? Why should I take them? confused, I should have mentioned it earlier. Felipe told me to send it to you as he's out on vacations. But never-mind, I can wait till he picks it up. cheers, -roger -- 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/2] usb: musb: host: fixes for 3.14-rc
On Tue, Feb 04, 2014 at 03:25:47PM +0200, Roger Quadros wrote: Hi Greg, Patch 1 fixes SuperSpeed hub enumeration on beaglebone. Patch 2 fixes remote-wakeup resume on beaglebone. Felipe has Acked the 1st patch but still needs to Ack the 2nd one. Patches are based on 3.14-rc1 Why wouldn't these come into my tree from Felipe like normal? Why should I take them? confused, greg k-h -- 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: clock DT conversion issues with omap36xx
On 01/29/2014 01:21 PM, Christoph Fritz wrote:
On Tue, 2014-01-28 at 18:02 +0100, Christoph Fritz wrote:
On Tue, 2014-01-28 at 15:40 +0200, Tero Kristo wrote:
Due to a regression since next-20140122 the following errors are present:
- pin sys_clkout2, which gets configured to 24 Mhz by the fourth patch
in this set, erroneously outputs only 12 Mhz.
Just out of curiosity, configuring it to 48 Mhz puts out desired 24 Mhz.
- omap_dss, which gets configured by the third patch in this set, fails
to do 'dss_set_fck_rate(fck);' in
drivers/video/omap2/dss/dss.c:dss_setup_default_clock() which leads to:
| omapdss_dss: probe of omapdss_dss failed with error -22
| omapdss CORE error: Failed to initialize DSS platform driver
| panel-dpi panel-dpi.0: failed to find video source 'dpi.0
Both regressions seem to have something to do with the clock framework.
Could this be related to the DT clock conversion patches?
Yea its definitely possible, as the clock DT conversion touches pretty
much everything. Have you tried whether this works properly with legacy
boot? Personally I don't have access to any omap3 devices that would
have display and have no possibility to check this out myself. Anyway,
my initial guess is that some clock divider setup might be wrong with
omap3, or we are missing some ti,set-rate-parent flag for some clock
node which prevents escalating clk_set_rate properly. However, it should
be easy to debug this by looking at the clock node in question, and its
parent nodes to see if there are any problems.
Currently I only analyzed sys_clkout2 (see attachments for full
clk_summary files):
clk_summary__next-20140115__works_as_expected:
dpll4_m2_ck1 19600
dpll4_m2x2_ck 1 19600
omap_192m_alwon_fck 1 19600
omap_96m_alwon_fck 1 29600
per_96m_fck 0 69600
mcbsp4_fck 0 19600
mcbsp3_fck 0 29600
mcbsp2_fck 0 29600
cm_96m_fck 2 39600
clkout2_src_ck 1 19600
sys_clkout2 1 12400
For real, on pin sys_clkout2 are correctly 24 Mhz measured.
clk_summary__next-20140124__sysclkout2_dss_fails:
dpll4_m2_ck1 19600
dpll4_m2x2_mul_ck 1 119200
dpll4_m2x2_ck 1 119200
omap_192m_alwon_fck 0 019200
omap_96m_alwon_fck 1 219200
per_96m_fck 0 619200
mcbsp4_fck 0 119200
mcbsp3_fck 0 219200
mcbsp2_fck 0 219200
cm_96m_fck 2 319200
clkout2_src_ck 1 119200
sys_clkout2 1 12400
For real, on pin sys_clkout2 are only ~12 Mhz measured.
Hey Christoph,
I had a chance to look at this in more detail, and it looks like your
patch above was almost the correct one (except that I think you modified
wrong property and also modified the clock node for all omap3 variants.)
Can you give this one a shot? Can you also send me the clk-summary dump
with this patch (with the relevant nodes)?
From: Tero Kristo t-kri...@ti.com
Date: Tue, 4 Feb 2014 17:37:37 +0200
Subject: [PATCH] ARM: dts: omap36xx: fix omap96m_alwon_fck
OMAP36xx has different hardware implementation for the omap96m_alwon_fck
compared to other OMAP3 variants. Reflect this properly in the dts file.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/boot/dts/omap36xx-clocks.dtsi |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/omap36xx-clocks.dtsi
b/arch/arm/boot/dts/omap36xx-clocks.dtsi
index 2fcf253..24869cb 100644
--- a/arch/arm/boot/dts/omap36xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap36xx-clocks.dtsi
@@ -70,6 +70,10 @@
};
};
+omap_96m_alwon_fck {
+ clock-div = 2;
+};
+
cm_clockdomains {
dpll4_clkdm: dpll4_clkdm {
compatible = ti,clockdomain;
--
1.7.9.5
--
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 V5 2/4] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
On Mon, 3 Feb 2014, Sricharan R wrote: I already have your reviewed-by tag for the first patch in this series. Kevin was pointing out that irqchip maintainer tag is needed for this patch as well to be merged. We are planning to take this series through arm-soc tree. Can i please have your tag for this patch as well ? Acked-by-me -- 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: omapfb segfaults
* Grant emailgr...@gmail.com [140203 20:44]: omapfb segfaults on my Pandaboard ES across several different kernel versions including 3.13.1. I've tried everything I can think of. Any ideas? - Grant This was fixed with the patches here: https://github.com/archlinuxarm/PKGBUILDs/tree/master/alarm/xf86-video-omapfb OK good to hear. 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: Issues with GPIO and wake from sleep
I have been looking more into the issue I am having and it looks like the
system isnt even entering a fully suspended state;
Tracing through the suspend sequence it looks like it is having trouble with
void omap_sram_idle(void)
The return from pwrm_read_next is 3 (PWRDM_POWER_ON) surely the next power
state should be 0 (PWRDM_POWER_OFF)
mpu_next_state = pwrdm_read_next_pwrst(mpu_pwrdm);
All the remaining checks are then invalid as it thinks the power domain needs
to be on for all;
/* NEON control */
if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
/* Enable IO-PAD and IO-CHAIN wakeups */
per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
pwrdm_pre_transition(NULL);
/* PER */
if (per_next_state PWRDM_POWER_ON) {
per_going_off = (per_next_state == PWRDM_POWER_OFF) ? 1 : 0;
omap2_gpio_prepare_for_idle(per_going_off);
}
/* CORE */
if (core_next_state PWRDM_POWER_ON) {
if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_cm_save_context();
}
}
omap3_intc_prepare_idle();
Is there anywhere I can find out what omap3_pm_suspend() is supposed to be
doing when it traverses through the list of power domains ?
static int omap3_pm_suspend(void)
{
struct power_state *pwrst;
int state, ret = 0;
/* Read current next_pwrsts */
list_for_each_entry(pwrst, pwrst_list, node)
pwrst-saved_state = pwrdm_read_next_pwrst(pwrst-pwrdm);
/* Set ones wanted by suspend */
list_for_each_entry(pwrst, pwrst_list, node) {
if (omap_set_pwrdm_state(pwrst-pwrdm, pwrst-next_state))
goto restore;
if (pwrdm_clear_all_prev_pwrst(pwrst-pwrdm))
goto restore;
}
omap3_intc_suspend();
omap_sram_idle();
I think the problem lies in the system thinking it is going from an ON state to
an ON state maybe ??
Kind Regards
Marc
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Marc Murphy
Sent: 23 January 2014 09:45
To: Tony Lindgren
Cc: linux-omap@vger.kernel.org
Subject: RE: Issues with GPIO and wake from sleep
I have tried all sorts of configurations now and still cannot get the system to
wake from GPIO.
The confusing thing is that if I use the power managements tests via debugfs I
can make the system sleep and wakeup using the timer, so the suspend and wake
is configured and working.
Using either method of configuring the GPIO to be an interrupt and wakeup
source OR a GPIO key with wakeup capability results in the system just sitting
there in the suspended state.
I know the GPIO and IRQ is working as I see the count increment in
/proc/interrupts
I have tried debugging with JTAG but not having any luck because the core
enters a power down state so therefore disconnects the JTAG and the debug
session hangs.
I have also removed all devices going back to a very basic system thinking
drivers are causing the suspend resume issue but still it stays in the sleep
state.
All the references I can find online do not assist in getting a solution for me.
Is there anyone out there that has managed to successfully get the wake from
suspend to memory working via a GPIO on a 3.x kernel ?
i am getting close to running out of options to make this system work.
Help appreciated and may help others out there with a similar issue.
Kind Regards
Marc
From: Tony Lindgren [t...@atomide.com]
Sent: 17 January 2014 17:39
To: Marc Murphy
Cc: linux-omap@vger.kernel.org
Subject: Re: Issues with GPIO and wake from sleep
* Marc Murphy marcm...@marcm.co.uk [140117 04:32]:
I have resisted contacting the list with regards to an issue I am having
trying to get what should be a simple part of my system working but I cannot
find any documentation or other posts to help.
I am using 3.6 kernel but have tried 3.12 to see if the issue has been
addressed in that but its exactly the same.
I am attempting to get a GPIO to wake my AM3517 system up from a
suspend to memory. I have tried with a few different options for GPIO's I
have available GPIO-10, GPIO-28 and GPIO-30.
I started by using GPIO-28 and that would configure nicely and I set
up the interrupt handler and could see my debug when triggering the
input (brilliant) but for some reason I cannot use it to wake the
system as it is not in the correct group for wakeup. There is a note
in the Tech Ref Man -
Only gpio_1, gpio_9, gpio_10, gpio_11, gpio_30, and gpio_31 can be used to
generate a direct wake-up event.
So have to use
