Re: [PATCH V4 0/4] DRIVERS: IRQCHIP: Add support for crossbar IP
On Thu, Nov 14, 2013 at 1:18 PM, Sricharan R r.sricha...@ti.com wrote: The minimal crossbar driver to track and allocate free GIC lines and configure the crossbar is added here, along with the DT bindings. V4: Addressed a couple of comments and split the DTS file updates in to a separate series. I'm pretty happy with the work and effort put into this now it's looking real elegant. FWIW: Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- 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] pinctrl: single: call pcs_soc-rearm() whenever IRQ mask is changed
On Thu, Nov 14, 2013 at 7:24 PM, Tony Lindgren t...@atomide.com wrote: * Tony Lindgren t...@atomide.com [131112 11:57]: The fix from Roger is still missing. You can go ahead and queue it, or if you prefer me to do it I can add it to my fixes. Actually Linus, I'll queue this with your ack as the interrupts-extended property is now merged in and I can also enable some minimal wake-up events for omap3. OK thanks for the heads-up, go ahead. Yours, Linus Walleij -- 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 01/23] gpio/omap: raw read and write endian fix
On Sat, Nov 16, 2013 at 1:01 AM, Taras Kondratiuk taras.kondrat...@linaro.org wrote: From: Victor Kamensky victor.kamen...@linaro.org All OMAP IP blocks expect LE data, but CPU may operate in BE mode. Need to use endian neutral functions to read/write h/w registers. I.e instead of __raw_read[lw] and __raw_write[lw] functions code need to use read[lw]_relaxed and write[lw]_relaxed functions. If the first simply reads/writes register, the second will byteswap it if host operates in BE mode. Changes are trivial sed like replacement of __raw_xxx functions with xxx_relaxed variant. Signed-off-by: Victor Kamensky victor.kamen...@linaro.org Signed-off-by: Taras Kondratiuk taras.kondrat...@linaro.org Since I generally just dislike __raw accessors I went and applied this. If it collides with any of Tony's fixup work I might need to take the patch out again, no big deal. Some ACKs would be nice, but unless there are major objections this stays merged. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] Add support for charging battery in Nokia RX-51
This patch series finally bringing support for charging battery on Nokia N900 (RX-51) without any proprietary Nokia bits in userspace. I removed hook function from bq2415x_charger driver and replaced it by Jenny TC power_supply notifier code. This simplify usage of bq2415x driver and also allow adding DT support in future because driver does not need board specific function anymore (only static data). I tested this series with linux 3.12-rc5 on Nokia N900. Pali Rohár (3): power_supply: Add power_supply notifier bq2415x_charger: Use power_supply notifier for automode RX-51: Add platform data for bq24150a charger arch/arm/mach-omap2/board-rx51-peripherals.c | 17 +- drivers/power/bq2415x_charger.c | 77 -- drivers/power/power_supply_core.c| 17 ++ include/linux/power/bq2415x_charger.h| 48 ++-- include/linux/power_supply.h | 10 5 files changed, 108 insertions(+), 61 deletions(-) -- 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
[PATCH v2 1/3] power_supply: Add power_supply notifier
This patch adds a notifier chain to the power_supply.
This notifier helps drivers in other subsystem to listen to
changes in power supply subsystem. This would help to take some
actions in those drivers on changing the power supply properties.
One such scenario is to increase/decrease system performance based
on the battery capacity/voltage. Another scenario is to adjust the
h/w peak current detection voltage/current thresholds based on battery
voltage/capacity. The notifier helps drivers to listen to changes
in power_suppy susbystem without polling the power_supply properties
Signed-off-by: Jenny TC jenny...@intel.com
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
drivers/power/power_supply_core.c | 17 +
include/linux/power_supply.h | 10 ++
2 files changed, 27 insertions(+)
diff --git a/drivers/power/power_supply_core.c
b/drivers/power/power_supply_core.c
index 00e6672..08bce22 100644
--- a/drivers/power/power_supply_core.c
+++ b/drivers/power/power_supply_core.c
@@ -24,6 +24,9 @@
struct class *power_supply_class;
EXPORT_SYMBOL_GPL(power_supply_class);
+ATOMIC_NOTIFIER_HEAD(power_supply_notifier);
+EXPORT_SYMBOL_GPL(power_supply_notifier);
+
static struct device_type power_supply_dev_type;
static bool __power_supply_is_supplied_by(struct power_supply *supplier,
@@ -80,6 +83,8 @@ static void power_supply_changed_work(struct work_struct
*work)
class_for_each_device(power_supply_class, NULL, psy,
__power_supply_changed_work);
power_supply_update_leds(psy);
+ atomic_notifier_call_chain(power_supply_notifier,
+ PSY_EVENT_PROP_CHANGED, psy);
kobject_uevent(psy-dev-kobj, KOBJ_CHANGE);
spin_lock_irqsave(psy-changed_lock, flags);
}
@@ -347,6 +352,18 @@ static void power_supply_dev_release(struct device *dev)
kfree(dev);
}
+int power_supply_reg_notifier(struct notifier_block *nb)
+{
+ return atomic_notifier_chain_register(power_supply_notifier, nb);
+}
+EXPORT_SYMBOL_GPL(power_supply_reg_notifier);
+
+void power_supply_unreg_notifier(struct notifier_block *nb)
+{
+ atomic_notifier_chain_unregister(power_supply_notifier, nb);
+}
+EXPORT_SYMBOL_GPL(power_supply_unreg_notifier);
+
#ifdef CONFIG_THERMAL
static int power_supply_read_temp(struct thermal_zone_device *tzd,
unsigned long *temp)
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 5c26006..c6f52c0 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -158,6 +158,13 @@ enum power_supply_type {
POWER_SUPPLY_TYPE_USB_ACA, /* Accessory Charger Adapters */
};
+enum power_supply_notifier_events {
+ PSY_EVENT_NONE,
+ PSY_EVENT_PROP_CHANGED,
+ PSY_EVENT_BATTERY,
+ PSY_EVENT_CABLE,
+};
+
union power_supply_propval {
int intval;
const char *strval;
@@ -235,6 +242,9 @@ struct power_supply_info {
int use_for_apm;
};
+extern struct atomic_notifier_headpower_supply_notifier;
+extern int power_supply_reg_notifier(struct notifier_block *nb);
+extern void power_supply_unreg_notifier(struct notifier_block *nb);
extern struct power_supply *power_supply_get_by_name(const char *name);
extern void power_supply_changed(struct power_supply *psy);
extern int power_supply_am_i_supplied(struct power_supply *psy);
--
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
[PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode
This patch removing set_mode_hook function from board data and replacing it with
new string variable of notifier power supply device. After this change it is
possible to add DT support because driver does not need specific board function
anymore. Only static data and name of power supply device is required.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
drivers/power/bq2415x_charger.c | 77 +
include/linux/power/bq2415x_charger.h | 48 +++-
2 files changed, 65 insertions(+), 60 deletions(-)
diff --git a/drivers/power/bq2415x_charger.c b/drivers/power/bq2415x_charger.c
index 0727f92..d89583d 100644
--- a/drivers/power/bq2415x_charger.c
+++ b/drivers/power/bq2415x_charger.c
@@ -1,7 +1,7 @@
/*
* bq2415x charger driver
*
- * Copyright (C) 2011-2012 Pali Rohár pali.ro...@gmail.com
+ * Copyright (C) 2011-2013 Pali Rohár pali.ro...@gmail.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
@@ -170,6 +170,7 @@ struct bq2415x_device {
struct bq2415x_platform_data init_data;
struct power_supply charger;
struct delayed_work work;
+ struct notifier_block nb;
enum bq2415x_mode reported_mode;/* mode reported by hook function */
enum bq2415x_mode mode; /* current configured mode */
enum bq2415x_chip chip;
@@ -791,24 +792,53 @@ static int bq2415x_set_mode(struct bq2415x_device *bq,
enum bq2415x_mode mode)
}
-/* hook function called by other driver which set reported mode */
-static void bq2415x_hook_function(enum bq2415x_mode mode, void *data)
+static int bq2415x_notifier_call(struct notifier_block *nb,
+ unsigned long val, void *v)
{
- struct bq2415x_device *bq = data;
+ struct bq2415x_device *bq =
+ container_of(nb, struct bq2415x_device, nb);
+ struct power_supply *psy = v;
+ enum bq2415x_mode mode;
+ union power_supply_propval prop;
+ int ret;
+ int mA;
- if (!bq)
- return;
+ if (val != PSY_EVENT_PROP_CHANGED)
+ return NOTIFY_OK;
+
+ if (strcmp(psy-name, bq-init_data.notify_device) != 0)
+ return NOTIFY_OK;
+
+ dev_dbg(bq-dev, notifier call was called\n);
+
+ ret = psy-get_property(psy, POWER_SUPPLY_PROP_CURRENT_MAX, prop);
+ if (ret != 0)
+ return NOTIFY_OK;
+
+ mA = prop.intval;
+
+ if (mA == 0)
+ mode = BQ2415X_MODE_OFF;
+ else if (mA 500)
+ mode = BQ2415X_MODE_NONE;
+ else if (mA 1800)
+ mode = BQ2415X_MODE_HOST_CHARGER;
+ else
+ mode = BQ2415X_MODE_DEDICATED_CHARGER;
+
+ if (bq-reported_mode == mode)
+ return NOTIFY_OK;
- dev_dbg(bq-dev, hook function was called\n);
bq-reported_mode = mode;
/* if automode is not enabled do not tell about reported_mode */
if (bq-automode 1)
- return;
+ return NOTIFY_OK;
sysfs_notify(bq-charger.dev-kobj, NULL, reported_mode);
bq2415x_set_mode(bq, bq-reported_mode);
+ return NOTIFY_OK;
}
/ timer functions /
@@ -1508,6 +1538,7 @@ static int bq2415x_probe(struct i2c_client *client,
int num;
char *name;
struct bq2415x_device *bq;
+ struct power_supply *psy;
if (!client-dev.platform_data) {
dev_err(client-dev, platform data not set\n);
@@ -1569,16 +1600,27 @@ static int bq2415x_probe(struct i2c_client *client,
goto error_4;
}
- if (bq-init_data.set_mode_hook) {
- if (bq-init_data.set_mode_hook(
- bq2415x_hook_function, bq)) {
- bq-automode = 1;
+ if (bq-init_data.notify_device) {
+ bq-nb.notifier_call = bq2415x_notifier_call;
+ ret = power_supply_reg_notifier(bq-nb);
+ if (ret) {
+ dev_err(bq-dev, failed to reg notifier: %d\n, ret);
+ goto error_5;
+ }
+ psy = power_supply_get_by_name(bq-init_data.notify_device);
+ if (psy) {
+ /* Query for initial reported_mode and set it */
+ bq2415x_notifier_call(bq-nb,
+ PSY_EVENT_PROP_CHANGED, psy);
bq2415x_set_mode(bq, bq-reported_mode);
- dev_info(bq-dev, automode enabled\n);
} else {
- bq-automode = -1;
- dev_info(bq-dev, automode failed\n);
+ dev_info(bq-dev, notifier power supply device (%s)
+ for automode is not registred yet...
+ automode will not work without that device\n,
+
[PATCH v2 3/3] RX-51: Add platform data for bq24150a charger
This patch will register bq24150a charger in RX-51 board data.
So finally charging battery on Nokia N900 (RX-51) working
automatically without any proprietary Nokia bits in userspace.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 70fcaff..95e6638 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -25,6 +25,7 @@
#include linux/gpio_keys.h
#include linux/mmc/host.h
#include linux/power/isp1704_charger.h
+#include linux/power/bq2415x_charger.h
#include linux/platform_data/spi-omap2-mcspi.h
#include linux/platform_data/mtd-onenand-omap2.h
#include linux/hsi/hsi.h
@@ -1275,6 +1276,16 @@ static struct aic3x_pdata rx51_aic3x_data2 = {
.gpio_reset = 60,
};
+static struct bq2415x_platform_data rx51_bq24150a_platform_data = {
+ .current_limit = 100, /* mA */
+ .weak_battery_voltage = 3400, /* mV */
+ .battery_regulation_voltage = 4200, /* mV */
+ .charge_current = 650, /* mA */
+ .termination_current = 100, /* mA */
+ .resistor_sense = 68, /* m ohm */
+ .notify_device = isp1704,
+};
+
static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[] = {
{
I2C_BOARD_INFO(tlv320aic3x, 0x18),
@@ -1302,7 +1313,11 @@ static struct i2c_board_info __initdata
rx51_peripherals_i2c_board_info_2[] = {
{
I2C_BOARD_INFO(tpa6130a2, 0x60),
.platform_data = rx51_tpa6130a2_data,
- }
+ },
+ {
+ I2C_BOARD_INFO(bq24150a, 0x6b),
+ .platform_data = rx51_bq24150a_platform_data,
+ },
};
static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_3[] = {
--
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 V3] ARM: OMAP2+: omap_device: maintain sane runtime pm status around suspend/resume
On 15 November 2013 23:03, Kevin Hilman khil...@linaro.org wrote: Tony Lindgren t...@atomide.com writes: * Nishanth Menon n...@ti.com [131115 05:30]: On 11/15/2013 02:07 AM, Paul Walmsley wrote: On Thu, 14 Nov 2013, Nishanth Menon wrote: OMAP device hooks around suspend|resume_noirq ensures that hwmod devices are forced to idle using omap_device_idle/enable as part of the last stage of suspend activity. For a device such as i2c who uses autosuspend, it is possible to enter the suspend path with dev-power.runtime_status = RPM_ACTIVE. As part of the suspend flow, the generic runtime logic would increment it's dev-power.disable_depth to 1. This should prevent further pm_runtime_get_sync from succeeding once the runtime_status has been set to RPM_SUSPENDED. Now, as part of the suspend_noirq handler in omap_device, we force the following: if the device status is !suspended, we force the device to idle using omap_device_idle (clocks are cut etc..). This ensures that from a hardware perspective, the device is suspended. However, runtime_status is left to be active. *if* an operation is attempted after this point to pm_runtime_get_sync, runtime framework depends on runtime_status to indicate accurately the device status, and since it sees it to be ACTIVE, it assumes the module is functional and returns a non-error value. As a result the user will see pm_runtime_get succeed, however a register access will crash due to the lack of clocks. To prevent this from happening, we should ensure that runtime_status exactly indicates the device status. As a result of this change any further calls to pm_runtime_get* would return -EACCES (since disable_depth is 1). On resume, we restore the clocks and runtime status exactly as we suspended with. These operations are not expected to fail as we update the states after the core runtime framework has suspended itself and restore before the core runtime framework has resumed. Reported-by: J Keerthy j-keer...@ti.com Signed-off-by: Nishanth Menon n...@ti.com Acked-by: Rajendra Nayak rna...@ti.com Acked-by: Kevin Hilman khil...@linaro.org Hi Kevin, I am wondering if OMAP would benefit from letting the PM core allow runtime suspends during system suspend, which is not the case as of now. My impression is that it could simplify OMAP drivers and the power domain, but it would be interesting to hear your opinion in this. It somewhat touches this patch. I guess. The reason for bringing this up here, is that I wanted to highlight that we are at the moment discussing the following RFC on the linux-pm mailing list: [RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend. Kind regards Ulf Hansson Looks reasonable to me. Looks like this should be considered for -stable - Nishanth, what do you think? Every product kernel since 3.4 needed to be hacked (we have hacked in different ways so far) to work around this (since we never spend time digging deeper :( ), So, I do agree with your view that a -stable tag will be most beneficial. Tony or Kevin, do you want to take this one, or want me to? I can take it unless you have other fixes pending right now. This version looks good to me. Reviewed-by: Kevin Hilman khil...@linaro.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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 RFC 0/9] Beaglebone-Black HDMI audio
This set of patches implements PCM HDMI audio driver for Beaglebone-Black HDMI output. The patches have been rebased on top of: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound topic/davinci There is couple of earlier RFC versions of the clk patch floating around, but the one here is the latest version. I'll send the associated dts changes shortly as a separate patch. Best regards, Jyri Jyri Sarha (9): clk: add gpio controlled clock ASoC: davinci-evm: Add named clock reference to DT bindings ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus ASoC: hdmi-codec: Add devicetree binding with documentation ASoC: hdmi-codec: Add SNDRV_PCM_FMTBIT_32_LE playback format ASoC: davinci: HDMI audio build for AM33XX and TDA998x drm/tilcdc: Add I2C HDMI audio config for tda998x ARM: OMAP2+: omap2plus_defconfig: Enable tilcdc and TDA998X HDMI support ARM: OMAP2+: omap2plus_defconfig: Enable BeagleBone Black HDMI audio support .../devicetree/bindings/clock/gpio-clock.txt | 21 ++ .../bindings/sound/davinci-evm-audio.txt | 12 +- Documentation/devicetree/bindings/sound/hdmi.txt | 17 ++ arch/arm/configs/omap2plus_defconfig |5 + drivers/clk/Makefile |1 + drivers/clk/clk-gpio.c | 209 ++ drivers/gpu/drm/tilcdc/tilcdc_slave.c | 24 ++- include/linux/clk-provider.h | 25 +++ sound/soc/codecs/hdmi.c| 12 +- sound/soc/davinci/Kconfig | 12 ++ sound/soc/davinci/Makefile |1 + sound/soc/davinci/davinci-evm.c| 227 +++- 12 files changed, 558 insertions(+), 8 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/gpio-clock.txt create mode 100644 Documentation/devicetree/bindings/sound/hdmi.txt create mode 100644 drivers/clk/clk-gpio.c -- 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
[PATCH RFC 6/9] ASoC: davinci: HDMI audio build for AM33XX and TDA998x
Adds configuration option for HDMI audio support for AM33XX based boards with NXP TDA998x HDMI transmitter. The audio is connected to NXP TDA998x trough McASP running in i2s mode. Signed-off-by: Jyri Sarha jsa...@ti.com --- sound/soc/davinci/Kconfig | 12 sound/soc/davinci/Makefile |1 + 2 files changed, 13 insertions(+) diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig index a8ec1fc..40dd5d1 100644 --- a/sound/soc/davinci/Kconfig +++ b/sound/soc/davinci/Kconfig @@ -26,6 +26,18 @@ config SND_AM33XX_SOC_EVM AM335X-EVMSK, and BeagelBone with AudioCape boards have this setup. +config SND_AM335X_SOC_NXPTDA_EVM + tristate HDMI Audio for the AM33XX chip based boards with TDA998x + depends on SND_DAVINCI_SOC SOC_AM33XX + depends on DRM_TILCDC DRM_I2C_NXP_TDA998X + select SND_SOC_HDMI_CODEC + select SND_DAVINCI_SOC_MCASP + help + Say Y or M if you want to add support for HDMI SoC audio on + AM33XX boards with NXP TDA998x HDMI transmitter. For example + BeagleBoneBack. The audio is connected to NXP TDA998x trough + McASP running in i2s mode. + config SND_DAVINCI_SOC_EVM tristate SoC Audio support for DaVinci DM6446, DM355 or DM365 EVM depends on SND_DAVINCI_SOC diff --git a/sound/soc/davinci/Makefile b/sound/soc/davinci/Makefile index 744d4d9..7587a70 100644 --- a/sound/soc/davinci/Makefile +++ b/sound/soc/davinci/Makefile @@ -13,3 +13,4 @@ obj-$(CONFIG_SND_DAVINCI_SOC_VCIF) += snd-soc-davinci-vcif.o snd-soc-evm-objs := davinci-evm.o obj-$(CONFIG_SND_DAVINCI_SOC_GENERIC_EVM) += snd-soc-evm.o +obj-$(CONFIG_SND_AM335X_SOC_NXPTDA_EVM) += snd-soc-evm.o -- 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
[PATCH RFC 3/9] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
Add machine driver support for BeagleBone-Black and other boards with
tilcdc support and NXP TDA998X HDMI transmitter connected to McASP
port in I2S mode. The 44100 Hz sample-rate and it's multiples can not
be supported on Beaglebone-Black because of limited clock-rate
support. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE.
The 8 least significant bits are ignored.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
.../bindings/sound/davinci-evm-audio.txt |3 +-
sound/soc/davinci/davinci-evm.c| 167 +++-
2 files changed, 167 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
index 4aa00f6..2abc4c2 100644
--- a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
@@ -1,7 +1,8 @@
* Texas Instruments SoC audio setups with TLV320AIC3X Codec
Required properties:
-- compatible : ti,da830-evm-audio : forDM365/DA8xx/OMAPL1x/AM33xx
+- compatible : ti,da830-evm-audio : for DM365/DA8xx/OMAPL1x/AM33xx
+ ti,am33xx-beaglebone-black : for Beaglebone-black HDMI audio
- ti,model : The user-visible name of this sound complex.
- ti,audio-codec : The phandle of the TLV320AIC3x audio codec
- ti,mcasp-controller : The phandle of the McASP controller
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index b28c9fd..71496b6 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -21,6 +21,7 @@
#include sound/core.h
#include sound/pcm.h
#include sound/soc.h
+#include sound/pcm_params.h
#include asm/dma.h
#include asm/mach-types.h
@@ -33,8 +34,13 @@
struct snd_soc_card_drvdata_davinci {
struct clk *mclk;
unsigned sysclk;
+ struct snd_pcm_hw_constraint_list *rate_constraint;
};
+/* If changing sample format the tda998x configuration (REG_CTS_N) needs
+ to be changed. */
+#define TDA998X_SAMPLE_FORMAT SNDRV_PCM_FORMAT_S32_LE
+
static int evm_startup(struct snd_pcm_substream *substream)
{
struct snd_soc_pcm_runtime *rtd = substream-private_data;
@@ -80,12 +86,80 @@ static int evm_hw_params(struct snd_pcm_substream
*substream,
return 0;
}
+static int evm_tda998x_startup(struct snd_pcm_substream *substream)
+{
+ struct snd_pcm_runtime *runtime = substream-runtime;
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_card *soc_card = rtd-codec-card;
+ struct snd_soc_card_drvdata_davinci *drvdata =
+ (struct snd_soc_card_drvdata_davinci *)
+ snd_soc_card_get_drvdata(soc_card);
+ struct snd_mask *fmt = constrs_mask(runtime-hw_constraints,
+ SNDRV_PCM_HW_PARAM_FORMAT);
+ snd_mask_none(fmt);
+ snd_mask_set(fmt, TDA998X_SAMPLE_FORMAT);
+
+ runtime-hw.rate_min = drvdata-rate_constraint-list[0];
+ runtime-hw.rate_max = drvdata-rate_constraint-list[
+ drvdata-rate_constraint-count - 1];
+ runtime-hw.rates = SNDRV_PCM_RATE_KNOT;
+
+ snd_pcm_hw_constraint_list(runtime, 0, SNDRV_PCM_HW_PARAM_RATE,
+ drvdata-rate_constraint);
+ snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_CHANNELS,
+2, 2);
+
+ return evm_startup(substream);
+}
+
+static unsigned int evm_get_bclk(struct snd_pcm_hw_params *params)
+{
+ int sample_size = snd_pcm_format_width(params_format(params));
+ int rate = params_rate(params);
+ int channels = params_channels(params);
+
+ return sample_size * channels * rate;
+}
+
+static int evm_tda998x_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_dai *cpu_dai = rtd-cpu_dai;
+ struct snd_soc_codec *codec = rtd-codec;
+ struct snd_soc_card *soc_card = codec-card;
+ struct platform_device *pdev = to_platform_device(soc_card-dev);
+ unsigned int bclk_freq = evm_get_bclk(params);
+ unsigned sysclk = ((struct snd_soc_card_drvdata_davinci *)
+ snd_soc_card_get_drvdata(soc_card))-sysclk;
+ int ret;
+
+ ret = snd_soc_dai_set_clkdiv(cpu_dai, 1, sysclk / bclk_freq);
+ if (ret 0) {
+ dev_err(pdev-dev, can't set CPU DAI clock divider %d\n,
+ ret);
+ return ret;
+ }
+
+ ret = snd_soc_dai_set_sysclk(cpu_dai, 0, sysclk, SND_SOC_CLOCK_IN);
+ if (ret 0)
+ return ret;
+
+ return ret;
+}
+
static struct snd_soc_ops evm_ops = {
.startup = evm_startup,
.shutdown = evm_shutdown,
.hw_params = evm_hw_params,
};
+static struct snd_soc_ops evm_tda998x_ops
[PATCH RFC 9/9] ARM: OMAP2+: omap2plus_defconfig: Enable BeagleBone Black HDMI audio support
Select following: CONFIG_SND_DAVINCI_SOC=m CONFIG_SND_AM335X_SOC_NXPTDA_EVM=m Signed-off-by: Jyri Sarha jsa...@ti.com cc: t...@atomide.com --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 52b0d92..c1a9730 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -216,6 +216,8 @@ CONFIG_SND_OMAP_SOC=m CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040=m CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m +CONFIG_SND_DAVINCI_SOC=m +CONFIG_SND_AM335X_SOC_NXPTDA_EVM=m CONFIG_USB=y CONFIG_USB_DEBUG=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y -- 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
[PATCH RFC 7/9] drm/tilcdc: Add I2C HDMI audio config for tda998x
The configuration is needed for HDMI audio. The swap and mirr
parameters have to be correctly set in the configuration in order to
have proper colors in the HDMI picture.
Signed-off-by: Jyri Sarha jsa...@ti.com
cc: airl...@linux.ie
---
drivers/gpu/drm/tilcdc/tilcdc_slave.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
index 595068b..e43240a 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
@@ -19,6 +19,7 @@
#include linux/pinctrl/pinmux.h
#include linux/pinctrl/consumer.h
#include drm/drm_encoder_slave.h
+#include drm/i2c/tda998x.h
#include tilcdc_drv.h
@@ -111,8 +112,29 @@ static const struct drm_encoder_helper_funcs
slave_encoder_helper_funcs = {
.restore= drm_i2c_encoder_restore,
};
+static struct tda998x_encoder_params tda998x_pdata = {
+ .swap_b = 0x3,
+ .mirr_b = 0x0,
+ .swap_a = 0x2,
+ .mirr_a = 0x0,
+ .swap_d = 0x1,
+ .mirr_d = 0x0,
+ .swap_c = 0x0,
+ .mirr_c = 0x0,
+ .swap_f = 0x5,
+ .mirr_f = 0x0,
+ .swap_e = 0x4,
+ .mirr_e = 0x0,
+ .audio_cfg = 0x3, /* I2S mode */
+ .audio_clk_cfg = 1, /* select clock pin */
+ .audio_frame[1] = 1,/* channels - 1 */
+ .audio_format = AFMT_I2S,
+ .audio_sample_rate = 48000,
+};
+
static const struct i2c_board_info info = {
- I2C_BOARD_INFO(tda998x, 0x70)
+ I2C_BOARD_INFO(tda998x, 0x70),
+ .platform_data = tda998x_pdata,
};
static struct drm_encoder *slave_encoder_create(struct drm_device *dev,
--
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
[PATCH RFC 2/9] ASoC: davinci-evm: Add named clock reference to DT bindings
The referenced clock is used to get codec clock rate and the clock is
disabled and enabled in startup and shutdown snd_soc_ops call
backs. The change is also documented in DT bindigs document.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
.../bindings/sound/davinci-evm-audio.txt |9 ++-
sound/soc/davinci/davinci-evm.c| 60 +++-
2 files changed, 66 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
index 865178d..4aa00f6 100644
--- a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
@@ -5,12 +5,19 @@ Required properties:
- ti,model : The user-visible name of this sound complex.
- ti,audio-codec : The phandle of the TLV320AIC3x audio codec
- ti,mcasp-controller : The phandle of the McASP controller
-- ti,codec-clock-rate : The Codec Clock rate (in Hz) applied to the Codec
- ti,audio-routing : A list of the connections between audio components.
Each entry is a pair of strings, the first being the connection's sink,
the second being the connection's source. Valid names for sources and
sinks are the codec's pins, and the jacks on the board:
+Optional properties:
+- ti,codec-clock-rate : The Codec Clock rate (in Hz) applied to the Codec.
+- clocks : Reference to the clock used as codec clock
+- clock-names : The codec clock should be named ti,codec-clock
+- Either codec-clock-rate or the codec-clock reference has to be defined. If
+ the both are defined the driver attempts to set referenced clock to the
+ defined rate and takes the rate from the clock reference.
+
Board connectors:
* Headphone Jack
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index 70ff377..b28c9fd 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -17,6 +17,7 @@
#include linux/platform_data/edma.h
#include linux/i2c.h
#include linux/of_platform.h
+#include linux/clk.h
#include sound/core.h
#include sound/pcm.h
#include sound/soc.h
@@ -30,9 +31,30 @@
#include davinci-i2s.h
struct snd_soc_card_drvdata_davinci {
+ struct clk *mclk;
unsigned sysclk;
};
+static int evm_startup(struct snd_pcm_substream *substream)
+{
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_card *soc_card = rtd-codec-card;
+ struct clk *mclk = ((struct snd_soc_card_drvdata_davinci *)
+ snd_soc_card_get_drvdata(soc_card))-mclk;
+
+ return clk_prepare_enable(mclk);
+}
+
+static void evm_shutdown(struct snd_pcm_substream *substream)
+{
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_card *soc_card = rtd-codec-card;
+ struct clk *mclk = ((struct snd_soc_card_drvdata_davinci *)
+ snd_soc_card_get_drvdata(soc_card))-mclk;
+
+ clk_disable_unprepare(mclk);
+}
+
static int evm_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
{
@@ -59,6 +81,8 @@ static int evm_hw_params(struct snd_pcm_substream *substream,
}
static struct snd_soc_ops evm_ops = {
+ .startup = evm_startup,
+ .shutdown = evm_shutdown,
.hw_params = evm_hw_params,
};
@@ -348,6 +372,7 @@ static int davinci_evm_probe(struct platform_device *pdev)
of_match_device(of_match_ptr(davinci_evm_dt_ids), pdev-dev);
struct snd_soc_dai_link *dai = (struct snd_soc_dai_link *) match-data;
struct snd_soc_card_drvdata_davinci *drvdata = NULL;
+ struct clk *mclk;
int ret = 0;
evm_soc_card.dai_link = dai;
@@ -367,13 +392,38 @@ static int davinci_evm_probe(struct platform_device *pdev)
if (ret)
return ret;
+ mclk = of_clk_get_by_name(np, ti,codec-clock);
+ if (PTR_ERR(mclk) == -EPROBE_DEFER) {
+ return -EPROBE_DEFER;
+ } else if (IS_ERR(mclk)) {
+ dev_dbg(pdev-dev, Codec clock not found.\n);
+ mclk = NULL;
+ }
+
drvdata = devm_kzalloc(pdev-dev, sizeof(*drvdata), GFP_KERNEL);
if (!drvdata)
return -ENOMEM;
+ drvdata-mclk = mclk;
+
ret = of_property_read_u32(np, ti,codec-clock-rate, drvdata-sysclk);
- if (ret 0)
- return -EINVAL;
+
+ if (ret 0) {
+ if (!drvdata-mclk) {
+ dev_err(pdev-dev,
+ No clock or clock rate defined.\n);
+ return -EINVAL;
+ }
+ drvdata-sysclk = clk_get_rate(drvdata-mclk);
+ } else if (drvdata-mclk) {
+ unsigned int requestd_rate = drvdata-sysclk;
+ clk_set_rate(drvdata-mclk, drvdata-sysclk);
+ drvdata-sysclk = clk_get_rate(drvdata-mclk);
+
[PATCH RFC 1/9] clk: add gpio controlled clock
The added clk-gpio is a basic clock that can be enabled and disabled
trough a gpio output. The DT binding document for the clock is also
added. For EPROBE_DEFER handling the registering of the clock has to
be delayed until of_clk_get() call time.
Signed-off-by: Jyri Sarha jsa...@ti.com
cc: mturque...@linaro.org
---
.../devicetree/bindings/clock/gpio-clock.txt | 21 ++
drivers/clk/Makefile |1 +
drivers/clk/clk-gpio.c | 209
include/linux/clk-provider.h | 25 +++
4 files changed, 256 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/gpio-clock.txt
create mode 100644 drivers/clk/clk-gpio.c
diff --git a/Documentation/devicetree/bindings/clock/gpio-clock.txt
b/Documentation/devicetree/bindings/clock/gpio-clock.txt
new file mode 100644
index 000..54fea39
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/gpio-clock.txt
@@ -0,0 +1,21 @@
+Binding for simple gpio controlled clock.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be gpio-clock.
+- #clock-cells : from common clock binding; shall be set to 0.
+- enable-gpios : GPIO reference for enabling and disabling the clock.
+
+Optional properties:
+- clocks: Maximum of one parent clock is supported.
+
+Example:
+ clock {
+ compatible = gpio-clock;
+ clocks = parentclk;
+ #clock-cells = 0;
+ enable-gpios = gpio 1 GPIO_ACTIVE_HIGH;
+ };
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 7b11106..568b7be 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_COMMON_CLK)+= clk-fixed-rate.o
obj-$(CONFIG_COMMON_CLK) += clk-gate.o
obj-$(CONFIG_COMMON_CLK) += clk-mux.o
obj-$(CONFIG_COMMON_CLK) += clk-composite.o
+obj-$(CONFIG_COMMON_CLK) += clk-gpio.o
# SoCs specific
obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
new file mode 100644
index 000..992d13f
--- /dev/null
+++ b/drivers/clk/clk-gpio.c
@@ -0,0 +1,209 @@
+/*
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Jyri Sarha jsa...@ti.com
+ *
+ * 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.
+ *
+ * Gpio controlled clock implementation
+ */
+
+#include linux/clk-provider.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/gpio.h
+#include linux/of_gpio.h
+#include linux/err.h
+#include linux/device.h
+
+/**
+ * DOC: basic gpio controlled clock which can be enabled and disabled
+ * with gpio output
+ * Traits of this clock:
+ * prepare - clk_(un)prepare only ensures parent is (un)prepared
+ * enable - clk_enable and clk_disable are functional control gpio
+ * rate - inherits rate from parent. No clk_set_rate support
+ * parent - fixed parent. No clk_set_parent support
+ */
+
+#define to_clk_gpio(_hw) container_of(_hw, struct clk_gpio, hw)
+
+static int clk_gpio_enable(struct clk_hw *hw)
+{
+ struct clk_gpio *gpio = to_clk_gpio(hw);
+ int value = gpio-active_low ? 0 : 1;
+
+ gpio_set_value(gpio-gpio, value);
+
+ return 0;
+}
+
+static void clk_gpio_disable(struct clk_hw *hw)
+{
+ struct clk_gpio *gpio = to_clk_gpio(hw);
+ int value = gpio-active_low ? 1 : 0;
+
+ gpio_set_value(gpio-gpio, value);
+}
+
+static int clk_gpio_is_enabled(struct clk_hw *hw)
+{
+ struct clk_gpio *gpio = to_clk_gpio(hw);
+ int value = gpio_get_value(gpio-gpio);
+
+ return gpio-active_low ? !value : value;
+}
+
+const struct clk_ops clk_gpio_ops = {
+ .enable = clk_gpio_enable,
+ .disable = clk_gpio_disable,
+ .is_enabled = clk_gpio_is_enabled,
+};
+EXPORT_SYMBOL_GPL(clk_gpio_ops);
+
+/**
+ * clk_register_gpio - register a gpip clock with the clock framework
+ * @dev: device that is registering this clock
+ * @name: name of this clock
+ * @parent_name: name of this clock's parent
+ * @flags: framework-specific flags for this clock
+ * @gpio: gpio to control this clock
+ * @active_low: gpio polarity
+ */
+struct clk *clk_register_gpio(struct device *dev, const char *name,
+ const char *parent_name, unsigned long flags,
+ unsigned int gpio, bool active_low)
+{
+ struct clk_gpio *clk_gpio;
+ struct clk *clk = ERR_PTR(-EINVAL);
+ struct clk_init_data init = { NULL };
+ unsigned long gpio_flags;
+ int err;
+
+ if (active_low)
+ gpio_flags = GPIOF_OUT_INIT_LOW;
+ else
+ gpio_flags = GPIOF_OUT_INIT_HIGH;
+
+ err = gpio_request_one(gpio, gpio_flags, name);
+
+ if (err) {
+ pr_err(%s: %s: Error requesting clock
[PATCH RFC 4/9] ASoC: hdmi-codec: Add devicetree binding with documentation
Signed-off-by: Jyri Sarha jsa...@ti.com
---
Documentation/devicetree/bindings/sound/hdmi.txt | 17 +
sound/soc/codecs/hdmi.c | 10 ++
2 files changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/hdmi.txt
diff --git a/Documentation/devicetree/bindings/sound/hdmi.txt
b/Documentation/devicetree/bindings/sound/hdmi.txt
new file mode 100644
index 000..31af7bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/hdmi.txt
@@ -0,0 +1,17 @@
+Device-Tree bindings for dummy HDMI codec
+
+Required properties:
+ - compatible: should be linux,hdmi-audio.
+
+CODEC output pins:
+ * TX
+
+CODEC input pins:
+ * RX
+
+Example node:
+
+ hdmi_audio: hdmi_audio@0 {
+ compatible = linux,hdmi-audio;
+ status = okay;
+ };
diff --git a/sound/soc/codecs/hdmi.c b/sound/soc/codecs/hdmi.c
index 68342b1..6d2fcf1 100644
--- a/sound/soc/codecs/hdmi.c
+++ b/sound/soc/codecs/hdmi.c
@@ -20,6 +20,7 @@
*/
#include linux/module.h
#include sound/soc.h
+#include linux/of_device.h
#define DRV_NAME hdmi-audio-codec
@@ -60,6 +61,14 @@ static struct snd_soc_dai_driver hdmi_codec_dai = {
};
+#ifdef CONFIG_OF
+static const struct of_device_id hdmi_audio_codec_ids[] = {
+ { .compatible = linux,hdmi-audio, },
+ { }
+};
+MODULE_DEVICE_TABLE(of, hdmi_audio_codec_ids);
+#endif
+
static struct snd_soc_codec_driver hdmi_codec = {
.dapm_widgets = hdmi_widgets,
.num_dapm_widgets = ARRAY_SIZE(hdmi_widgets),
@@ -83,6 +92,7 @@ static struct platform_driver hdmi_codec_driver = {
.driver = {
.name = DRV_NAME,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(hdmi_audio_codec_ids),
},
.probe = hdmi_codec_probe,
--
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
[PATCH RFC 5/9] ASoC: hdmi-codec: Add SNDRV_PCM_FMTBIT_32_LE playback format
The new playback format is needed for tda998x HDMI audio support. At
the moment the only other user of this codec is omap-hdmi-audio. This
change should not break anything because omap-hdmi-audio-dai, the
cpu-dai of omap-hdmi-audio, enforces sufficient constraints to
available sample formats.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
sound/soc/codecs/hdmi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/hdmi.c b/sound/soc/codecs/hdmi.c
index 6d2fcf1..9cb1c7d 100644
--- a/sound/soc/codecs/hdmi.c
+++ b/sound/soc/codecs/hdmi.c
@@ -45,7 +45,7 @@ static struct snd_soc_dai_driver hdmi_codec_dai = {
SNDRV_PCM_RATE_88200 | SNDRV_PCM_RATE_96000 |
SNDRV_PCM_RATE_176400 | SNDRV_PCM_RATE_192000,
.formats = SNDRV_PCM_FMTBIT_S16_LE |
- SNDRV_PCM_FMTBIT_S24_LE,
+ SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE,
},
.capture = {
.stream_name = Capture,
--
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
[PATCH RFC 8/9] ARM: OMAP2+: omap2plus_defconfig: Enable tilcdc and TDA998X HDMI support
This enables HDMI video support on Beaglebone-Black. Signed-off-by: Jyri Sarha jsa...@ti.com cc: t...@atomide.com --- arch/arm/configs/omap2plus_defconfig |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 254cf05..52b0d92 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -176,6 +176,9 @@ CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y CONFIG_REGULATOR_TPS65217=y CONFIG_REGULATOR_TPS65910=y +CONFIG_DRM=m +CONFIG_DRM_I2C_NXP_TDA998X=m +CONFIG_DRM_TILCDC=m CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y -- 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
[PATCH RFC] DTS Changes for Beaglebone-Black HDMI audio
The associated code changes can be found here: http://mailman.alsa-project.org/pipermail/alsa-devel/2013-November/068920.html Jyri Sarha (1): ARM/dts: am335x-boneblack: Add HDMI audio support arch/arm/boot/dts/am335x-boneblack.dts | 52 1 file changed, 52 insertions(+) -- 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
[PATCH RFC] ARM/dts: am335x-boneblack: Add HDMI audio support
Adds mcasp0_pins, clk_mcasp0_fixed, clk_mcasp0, mcasp0, hdmi_audio,
and sound nodes.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
arch/arm/boot/dts/am335x-boneblack.dts | 52
1 file changed, 52 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 6b71ad9..b5a2404 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -60,12 +60,35 @@
0x1b0 0x03 /* xdma_event_intr0, OMAP_MUX_MODE3 |
AM33XX_PIN_OUTPUT */
;
};
+
+ mcasp0_pins: mcasp0_pins {
+ pinctrl-single,pins =
+ 0x1ac (PIN_INPUT_PULLUP | MUX_MODE0) /*
mcasp0_ahclkx.mcasp0_ahclkx */
+ 0x19c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mcasp0_ahclkr.mcasp0_axr2 */
+ 0x194 (PIN_OUTPUT_PULLUP | MUX_MODE0) /*
mcasp0_fsx.mcasp0_fsx */
+ 0x190 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mcasp0_aclkx.mcasp0_aclkx */
+ 0x06c (PIN_OUTPUT_PULLUP | MUX_MODE7) /*
gpmc_a11.gpio1_27 */
+ ;
+ };
};
lcdc {
status = okay;
};
+mcasp0{
+ pinctrl-names = default;
+ pinctrl-0 = mcasp0_pins;
+ status = okay;
+ op-mode = 0; /* MCASP_IIS_MODE */
+ tdm-slots = 2;
+ serial-dir = /* 0: INACTIVE, 1: TX, 2: RX */
+ 0 0 1 0
+ ;
+ tx-num-evt = 1;
+ rx-num-evt = 1;
+};
+
/ {
hdmi {
compatible = ti,tilcdc,slave;
@@ -75,4 +98,33 @@
pinctrl-1 = nxp_hdmi_bonelt_off_pins;
status = okay;
};
+
+ clk_mcasp0_fixed: clk_mcasp0_fixed {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 24576000;
+ };
+
+ clk_mcasp0: clk_mcasp0 {
+ #clock-cells = 0;
+ compatible = gpio-clock;
+ clocks = clk_mcasp0_fixed;
+ enable-gpios = gpio1 27 GPIO_ACTIVE_HIGH; /* BeagleBone
Black Clk enable on GPIO1_27 */
+ };
+
+ hdmi_audio: hdmi_audio@0 {
+ compatible = linux,hdmi-audio;
+ status = okay;
+ };
+
+ sound {
+ compatible = ti,am33xx-beaglebone-black;
+ ti,model = TI BeagleBone Black;
+ ti,audio-codec = hdmi_audio;
+ ti,mcasp-controller = mcasp0;
+ ti,audio-routing =
+ HDMI Out, TX;
+ clocks = clk_mcasp0;
+ clock-names = ti,codec-clock;
+ };
};
--
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 RFC] ARM/dts: am335x-boneblack: Add HDMI audio support
Hi Jyri,
A side question related to audio cape support on BBB. In the official
3.8.13 CircuitCo version the HDMI audio support was breaking the
audio-cape support due to some bad hacks in the mcasp driver.
Is this still the case with you series?
Thanks,
Benoit
On 19/11/2013 13:21, Jyri Sarha wrote:
Adds mcasp0_pins, clk_mcasp0_fixed, clk_mcasp0, mcasp0, hdmi_audio,
and sound nodes.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
arch/arm/boot/dts/am335x-boneblack.dts | 52
1 file changed, 52 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 6b71ad9..b5a2404 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -60,12 +60,35 @@
0x1b0 0x03 /* xdma_event_intr0, OMAP_MUX_MODE3 |
AM33XX_PIN_OUTPUT */
;
};
+
+ mcasp0_pins: mcasp0_pins {
+ pinctrl-single,pins =
+ 0x1ac (PIN_INPUT_PULLUP | MUX_MODE0) /*
mcasp0_ahclkx.mcasp0_ahclkx */
+ 0x19c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mcasp0_ahclkr.mcasp0_axr2 */
+ 0x194 (PIN_OUTPUT_PULLUP | MUX_MODE0) /*
mcasp0_fsx.mcasp0_fsx */
+ 0x190 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mcasp0_aclkx.mcasp0_aclkx */
+ 0x06c (PIN_OUTPUT_PULLUP | MUX_MODE7) /*
gpmc_a11.gpio1_27 */
+ ;
+ };
};
lcdc {
status = okay;
};
+mcasp0{
+ pinctrl-names = default;
+ pinctrl-0 = mcasp0_pins;
+ status = okay;
+ op-mode = 0;/* MCASP_IIS_MODE */
+ tdm-slots = 2;
+ serial-dir =/* 0: INACTIVE, 1: TX, 2: RX */
+ 0 0 1 0
+ ;
+ tx-num-evt = 1;
+ rx-num-evt = 1;
+};
+
/ {
hdmi {
compatible = ti,tilcdc,slave;
@@ -75,4 +98,33 @@
pinctrl-1 = nxp_hdmi_bonelt_off_pins;
status = okay;
};
+
+ clk_mcasp0_fixed: clk_mcasp0_fixed {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 24576000;
+ };
+
+ clk_mcasp0: clk_mcasp0 {
+ #clock-cells = 0;
+ compatible = gpio-clock;
+ clocks = clk_mcasp0_fixed;
+ enable-gpios = gpio1 27 GPIO_ACTIVE_HIGH; /* BeagleBone
Black Clk enable on GPIO1_27 */
+ };
+
+ hdmi_audio: hdmi_audio@0 {
+ compatible = linux,hdmi-audio;
+ status = okay;
+ };
+
+ sound {
+ compatible = ti,am33xx-beaglebone-black;
+ ti,model = TI BeagleBone Black;
+ ti,audio-codec = hdmi_audio;
+ ti,mcasp-controller = mcasp0;
+ ti,audio-routing =
+ HDMI Out, TX;
+ clocks = clk_mcasp0;
+ clock-names = ti,codec-clock;
+ };
};
--
Benoît Cousson
BayLibre
Embedded Linux Technology Lab
www.baylibre.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
Re: [PATCH v2 1/3] power_supply: Add power_supply notifier
On Tue 2013-11-19 11:18:03, Pali Rohár wrote: This patch adds a notifier chain to the power_supply. This notifier helps drivers in other subsystem to listen to changes in power supply subsystem. This would help to take some actions in those drivers on changing the power supply properties. One such scenario is to increase/decrease system performance based on the battery capacity/voltage. Another scenario is to adjust the h/w peak current detection voltage/current thresholds based on battery voltage/capacity. The notifier helps drivers to listen to changes in power_suppy susbystem without polling the power_supply properties Signed-off-by: Jenny TC jenny...@intel.com Signed-off-by: Pali Rohár pali.ro...@gmail.com Reviewed-by: Pavel Machek pa...@ucw.cz +extern struct atomic_notifier_headpower_supply_notifier; You may want to delete some spaces here. 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 v3 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.
On 18 November 2013 08:53, Andreas Fenkart afenk...@gmail.com wrote:
The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, the GPIO will only wake
the module from suspend, SDIO irq detection will still happen through the
IP block.
Idea of remuxing the pins by Tony Lindgren as well as the implementation
of omap_hsmmc_pin_init.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 1136e6b..146f3ad 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -21,8 +21,11 @@ ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
ti,needs-special-hs-handling: HSMMC IP needs special setting for handling
High Speed
ti,quirk-swakup-missing: SOC missing the swakeup line, will not detect
-SDIO irq while in suspend. Fallback to polling. Affected chips are
-am335x,
+SDIO irq while in suspend. The workaround is to reconfigure the dat1 line as
a
+GPIO upon suspend. Beyond this option and the GPIO config, you also need to
set
+named pinctrl states default, active and idle , see example below. The
+MMC driver will then then toggle between default and idle during the runtime
+Affected chips are am335x,
--
| PRCM |
@@ -49,3 +52,24 @@ Example:
vmmc-supply = vmmc; /* phandle to regulator node */
ti,non-removable;
};
+
+[am335x with with gpio for sdio irq]
+
+ mmc1_cirq_pin: pinmux_cirq_pin {
+ pinctrl-single,pins =
+ 0x0f8 0x3f /* MMC0_DAT1 as GPIO2_28 */
+ ;
+ };
+
+ mmc1: mmc@4806 {
+ ti,non-removable;
+ bus-width = 4;
+ vmmc-supply = ldo2_reg;
+ vmmc_aux-supply = vmmc;
+ ti,quirk-swakeup-missing;
+ pinctrl-names = default, active, idle;
+ pinctrl-0 = mmc1_pins;
+ pinctrl-1 = mmc1_pins;
+ pinctrl-2 = mmc1_cirq_pin;
+ ti,cirq-gpio = gpio3 28 0;
+ };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 6b0ec55..b94ab08 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -36,6 +36,7 @@
#include linux/mmc/core.h
#include linux/mmc/mmc.h
#include linux/io.h
+#include linux/irq.h
#include linux/gpio.h
#include linux/regulator/consumer.h
#include linux/pinctrl/consumer.h
@@ -213,11 +214,32 @@ struct omap_hsmmc_host {
int req_in_progress;
int flags;
#define HSMMC_SDIO_IRQ_ENABLED (1 0)/* SDIO irq enabled */
+#define HSMMC_SWAKEUP_QUIRK(1 1)
+#define HSMMC_CIRQ_GPIO_ENABLED (1 2)
struct omap_hsmmc_next next_data;
+ struct pinctrl *pinctrl;
+ struct pinctrl_state*fixed, *active, *idle;
struct omap_mmc_platform_data *pdata;
};
+static irqreturn_t omap_hsmmc_cirq(int irq, void *dev_id)
+{
+ struct omap_hsmmc_host *host = dev_id;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ if (host-flags HSMMC_CIRQ_GPIO_ENABLED) {
+ disable_irq_nosync(mmc_slot(host).sdio_irq);
+ host-flags = ~HSMMC_CIRQ_GPIO_ENABLED;
+ }
+ spin_unlock_irqrestore(host-irq_lock, flags);
+
+ pm_request_resume(host-dev); /* no use counter */
In the case were you are not waking up from system suspend, but from
runtime suspend, you likely want to signal the SDIO irq as soon as
possible. Then you should use mmc_signal_sdio_irq instead.
In the other case, when waking up from system suspend, you should be
able to completely rely on that the mmc_sdio_resume from the core
layer, will handle the IRQ.
Kind regards
Ulf Hansson
+
+ return IRQ_HANDLED;
+}
+
static int omap_hsmmc_card_detect(struct device *dev, int slot)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
@@ -452,10 +474,25 @@ static int omap_hsmmc_gpio_init(struct
omap_mmc_platform_data *pdata)
} else
pdata-slots[0].gpio_wp = -EINVAL;
+ if (gpio_is_valid(pdata-slots[0].gpio_cirq)) {
+ pdata-slots[0].sdio_irq =
+ gpio_to_irq(pdata-slots[0].gpio_cirq);
+ ret = gpio_request_one(pdata-slots[0].gpio_cirq,
GPIOF_DIR_IN,
+ sdio_cirq);
+ if (ret)
+ goto err_free_ro;
+
+ } else {
+ pdata-slots[0].gpio_cirq = -EINVAL;
+ }
+
+
Re: [PATCH v2 1/3] power_supply: Add power_supply notifier
On Tuesday 19 November 2013 14:10:06 Pavel Machek wrote: On Tue 2013-11-19 11:18:03, Pali Rohár wrote: This patch adds a notifier chain to the power_supply. This notifier helps drivers in other subsystem to listen to changes in power supply subsystem. This would help to take some actions in those drivers on changing the power supply properties. One such scenario is to increase/decrease system performance based on the battery capacity/voltage. Another scenario is to adjust the h/w peak current detection voltage/current thresholds based on battery voltage/capacity. The notifier helps drivers to listen to changes in power_suppy susbystem without polling the power_supply properties Signed-off-by: Jenny TC jenny...@intel.com Signed-off-by: Pali Rohár pali.ro...@gmail.com Reviewed-by: Pavel Machek pa...@ucw.cz +extern struct atomic_notifier_head power_supply_notifier; You may want to delete some spaces here. Thanks, Pavel Ok, note that this patch I copied from: https://lkml.org/lkml/2013/9/23/181 -- Pali Rohár pali.ro...@gmail.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
Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode
On Tue 2013-11-19 11:18:04, Pali Rohár wrote: This patch removing set_mode_hook function from board data and replacing it with new string variable of notifier power supply device. After this change it is possible to add DT support because driver does not need specific board function anymore. Only static data and name of power supply device is required. Signed-off-by: Pali Rohár pali.ro...@gmail.com Reviewed-by: Pavel Machek pa...@ucw.cz 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] ARM/dts: am335x-boneblack: Add HDMI audio support
On 11/19/2013 03:02 PM, Benoit Cousson wrote: A side question related to audio cape support on BBB. In the official 3.8.13 CircuitCo version the HDMI audio support was breaking the audio-cape support due to some bad hacks in the mcasp driver. Is this still the case with you series? My patches do not touch davinci-mcasp at all and the davinci-evm changes should be backwards compatible. So if the audio-cape was working before my patches should not break it. Best regards, Jyri -- 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/3] RX-51: Add platform data for bq24150a charger
On Tue 2013-11-19 11:18:05, Pali Rohár wrote:
This patch will register bq24150a charger in RX-51 board data.
So finally charging battery on Nokia N900 (RX-51) working
automatically without any proprietary Nokia bits in userspace.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
Reviewed-by: Pavel Machek pa...@ucw.cz
Pavel
BTW, current code says:
That seems to limit charging voltage to 3.9V, with comment saying
4.11V... which means battery will not be charged fully. does it make
sense to raise limit to 4.11V here?
Aha, and actually will not 4.2V requested by
rx51_bq24150a_platform_data trigger -EINVAL?
/* set battery regulation voltage in mV */
static int bq2415x_set_battery_regulation_voltage(struct
bq2415x_device *bq,
int mV)
{
int val = (mV/10 - 350) / 2;
if (val 0)
val = 0;
else if (val 94) /* FIXME: Max is 94 or 122 ? Set max value
? */
return -EINVAL;
return bq2415x_i2c_write_mask(bq, BQ2415X_REG_VOLTAGE, val,
BQ2415X_MASK_VO, BQ2415X_SHIFT_VO);
}
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -1275,6 +1276,16 @@ static struct aic3x_pdata rx51_aic3x_data2 = {
.gpio_reset = 60,
};
+static struct bq2415x_platform_data rx51_bq24150a_platform_data = {
+ .current_limit = 100, /* mA */
+ .weak_battery_voltage = 3400, /* mV */
+ .battery_regulation_voltage = 4200, /* mV */
+ .charge_current = 650, /* mA */
+ .termination_current = 100, /* mA */
+ .resistor_sense = 68, /* m ohm */
+ .notify_device = isp1704,
+};
+
static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[]
= {
{
I2C_BOARD_INFO(tlv320aic3x, 0x18),
--
(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 v3 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.
Hi Ulf,
2013/11/19 Ulf Hansson ulf.hans...@linaro.org:
On 18 November 2013 08:53, Andreas Fenkart afenk...@gmail.com wrote:
+static irqreturn_t omap_hsmmc_cirq(int irq, void *dev_id)
+{
+ struct omap_hsmmc_host *host = dev_id;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ if (host-flags HSMMC_CIRQ_GPIO_ENABLED) {
+ disable_irq_nosync(mmc_slot(host).sdio_irq);
+ host-flags = ~HSMMC_CIRQ_GPIO_ENABLED;
+ }
+ spin_unlock_irqrestore(host-irq_lock, flags);
+
+ pm_request_resume(host-dev); /* no use counter */
In the case were you are not waking up from system suspend, but from
runtime suspend, you likely want to signal the SDIO irq as soon as
possible. Then you should use mmc_signal_sdio_irq instead.
That was my intention first as well, and previous patches worked that way.
SDIO IRQ while in pm_suspend is a rare event, compard to SDIO irq
while in pm_active state.
cat /proc/interrupts
CPU0
80: 68349 INTC 64 mmc0
236: 4352 GPIO 28 mmc0
Here the Wifi module is just connected, not being pinged or iperf
running. So the benefit will not be as big as you imagine.
On the other side the optimisations is not without problems, while in
pm_suspend the functional clock is off and you must not access the
registers of the module.
But this is exactly whapt happens when you call mmc_signal_sdio_irq,
it will call back into the drivers omap_hsmmc_enable_sdio_irq trying to
disable the SDIO irq. So you must add special state machines there.
After all it's doable but error prone, and I consider not worth the troubles
for no noticeable speedup.
Also have a look here, Balaji T K had a similar remark to yours
http://www.spinics.net/lists/linux-omap/msg99832.html
In the other case, when waking up from system suspend, you should be
able to completely rely on that the mmc_sdio_resume from the core
layer, will handle the IRQ.
Kind regards
Ulf Hansson
--
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: [BUG] PandaBoard hangs before starting init while booting v3.12
Lokesh Vutla lokeshvu...@ti.com writes: Hi Ben, On Monday 18 November 2013 08:44 PM, Ben Gamari wrote: I'm having difficulty getting a PandaBoard ES rev. B1 to boot v3.12 and linux-next (30121118). I'm booting with a brand new u-boot (c2e5e802ecb7ab668ce9911b210ed68c804b349f). In both cases the device appears to hang shortly before one would expect init to start as seen in the boot output below. I'm booting with the omap4-panda-es devicetree. As far as I can tell, the machine is completely dead and will not respond to even sysrq. I have a PandaBoard A4 which apparently has no trouble with the same kernel image. Which defconfig are you using ? I derived the config from RobertCNelson's Debian Wheezy image. It did require some modification, however. Can you see if CPU_IDLE is enabled in your defconfig? Yes, CPU_IDLE is enabled. I saw a similar failure on my panda es when CPU_IDLE is enabled. If this is the case for you please apply this[1] patch and give a try. Indeed that did the trick. Thanks for the reference! I do however now see periodic messages of the form, [ 42.143005] gic_timer_retrigger: lost localtimer interrupt Any idea what this might be due to? Cheers, - Ben pgpubspGDYvbs.pgp Description: PGP signature
Re: [PATCH v2 0/3] Add support for charging battery in Nokia RX-51
Hi Pali, On Tue, Nov 19, 2013 at 11:18:02AM +0100, Pali Rohár wrote: This patch series finally bringing support for charging battery on Nokia N900 (RX-51) without any proprietary Nokia bits in userspace. YAY! :) I removed hook function from bq2415x_charger driver and replaced it by Jenny TC power_supply notifier code. This simplify usage of bq2415x driver and also allow adding DT support in future because driver does not need board specific function anymore (only static data). I tested this series with linux 3.12-rc5 on Nokia N900. cool :) Do you want me to take this up and add DT support? -- Sebastian signature.asc Description: Digital signature
cpufreq on PandaBoard
Booting a PandaBoard with a recent kernel and devicetree appears to be a rather messy process. There are dozens of devicetree-related warnings spewed on boot (many pertaining to missing regulators). At the moment, however, I'm most interested in this, cpufreq-cpu0 cpufreq-cpu0.0: no of_node; not parsing pinctrl DT cpu cpu0: dummy supplies not allowed cpufreq_cpu0: failed to get cpu0 regulator: -19 cpufreq_cpu0: failed to get cpu0 clock: -2 cpufreq-cpu0: probe of cpufreq-cpu0.0 failed with error -2 What is the status of cpufreq on the PandaBoard? Is this expected to work? More generally, if one wants a fairly recent kernel supporting the PandaBoard's hardware what kernel tree should be used? Is mainline not yet appropriate? Is linux-next preferred? Perhaps a ti-maintained tree? Cheers, - Ben pgp9fQiwRN8sy.pgp Description: PGP signature
Re: cpufreq on PandaBoard
On 11/19/2013 08:59 AM, Ben Gamari wrote: Booting a PandaBoard with a recent kernel and devicetree appears to be a rather messy process. There are dozens of devicetree-related warnings spewed on boot (many pertaining to missing regulators). At the moment, however, I'm most interested in this, cpufreq-cpu0 cpufreq-cpu0.0: no of_node; not parsing pinctrl DT cpu cpu0: dummy supplies not allowed cpufreq_cpu0: failed to get cpu0 regulator: -19 cpufreq_cpu0: failed to get cpu0 clock: -2 cpufreq-cpu0: probe of cpufreq-cpu0.0 failed with error -2 What is the status of cpufreq on the PandaBoard? Is this expected to work? More generally, if one wants a fairly recent kernel supporting the PandaBoard's hardware what kernel tree should be used? Is mainline not yet appropriate? Is linux-next preferred? Perhaps a ti-maintained tree? for upstream: Wait for the clock nodes to get merged.. we are at v9 of discussion thread here[1]. for ti-maintained tree, you need to talk to TI support folks for appropriate kernel for your product line. [1] http://marc.info/?t=13827167252r=1w=2 -- 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 v3 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.
On 19 November 2013 14:37, Andreas Fenkart afenk...@gmail.com wrote:
Hi Ulf,
2013/11/19 Ulf Hansson ulf.hans...@linaro.org:
On 18 November 2013 08:53, Andreas Fenkart afenk...@gmail.com wrote:
+static irqreturn_t omap_hsmmc_cirq(int irq, void *dev_id)
+{
+ struct omap_hsmmc_host *host = dev_id;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ if (host-flags HSMMC_CIRQ_GPIO_ENABLED) {
+ disable_irq_nosync(mmc_slot(host).sdio_irq);
+ host-flags = ~HSMMC_CIRQ_GPIO_ENABLED;
+ }
+ spin_unlock_irqrestore(host-irq_lock, flags);
+
+ pm_request_resume(host-dev); /* no use counter */
In the case were you are not waking up from system suspend, but from
runtime suspend, you likely want to signal the SDIO irq as soon as
possible. Then you should use mmc_signal_sdio_irq instead.
That was my intention first as well, and previous patches worked that way.
SDIO IRQ while in pm_suspend is a rare event, compard to SDIO irq
while in pm_active state.
cat /proc/interrupts
CPU0
80: 68349 INTC 64 mmc0
236: 4352 GPIO 28 mmc0
Here the Wifi module is just connected, not being pinged or iperf
running. So the benefit will not be as big as you imagine.
You are right.
On the other side the optimisations is not without problems, while in
pm_suspend the functional clock is off and you must not access the
registers of the module.
But this is exactly whapt happens when you call mmc_signal_sdio_irq,
it will call back into the drivers omap_hsmmc_enable_sdio_irq trying to
disable the SDIO irq. So you must add special state machines there.
Yes, it will be somewhat complicated - I guess.
After all it's doable but error prone, and I consider not worth the troubles
for no noticeable speedup.
Also have a look here, Balaji T K had a similar remark to yours
http://www.spinics.net/lists/linux-omap/msg99832.html
Thanks, I should have looked that first. :-)
Kind regards
Ulf Hansson
In the other case, when waking up from system suspend, you should be
able to completely rely on that the mmc_sdio_resume from the core
layer, will handle the IRQ.
Kind regards
Ulf Hansson
--
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 3/9] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
Dear Jyri Sarha, On Tue, 19 Nov 2013 14:12:23 +0200, Jyri Sarha wrote: -- compatible : ti,da830-evm-audio : forDM365/DA8xx/OMAPL1x/AM33xx +- compatible : ti,da830-evm-audio : for DM365/DA8xx/OMAPL1x/AM33xx + ti,am33xx-beaglebone-black : for Beaglebone-black HDMI audio The compatible string namespace is a global namespace, and in the compatible string you've chosen, there's nothing that makes it specific to audio. ti,am33xx-beaglebone-black could be used for any other device, or even for the board as a whole, no? Maybe you need to suffix it with -audio, like the existing compatible string for audio in this driver. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.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
Re: [PATCH v2 0/3] Add support for charging battery in Nokia RX-51
* Sebastian Reichel s...@debian.org [131119 06:45]: Hi Pali, On Tue, Nov 19, 2013 at 11:18:02AM +0100, Pali Rohár wrote: This patch series finally bringing support for charging battery on Nokia N900 (RX-51) without any proprietary Nokia bits in userspace. YAY! :) I removed hook function from bq2415x_charger driver and replaced it by Jenny TC power_supply notifier code. This simplify usage of bq2415x driver and also allow adding DT support in future because driver does not need board specific function anymore (only static data). I tested this series with linux 3.12-rc5 on Nokia N900. cool :) Do you want me to take this up and add DT support? Great news, yeah let's add this with DT support instead as we're planning to switch over to DT only booting anyways. The values can be probably set directly in the charger driver based on the compatible flag. Note that we can also still add the I2C devices as needed from the pdata-quirks.c, but in this case there should not be any need for it :) Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 01/23] gpio/omap: raw read and write endian fix
* Linus Walleij linus.wall...@linaro.org [131119 01:29]: On Sat, Nov 16, 2013 at 1:01 AM, Taras Kondratiuk taras.kondrat...@linaro.org wrote: From: Victor Kamensky victor.kamen...@linaro.org All OMAP IP blocks expect LE data, but CPU may operate in BE mode. Need to use endian neutral functions to read/write h/w registers. I.e instead of __raw_read[lw] and __raw_write[lw] functions code need to use read[lw]_relaxed and write[lw]_relaxed functions. If the first simply reads/writes register, the second will byteswap it if host operates in BE mode. Changes are trivial sed like replacement of __raw_xxx functions with xxx_relaxed variant. Signed-off-by: Victor Kamensky victor.kamen...@linaro.org Signed-off-by: Taras Kondratiuk taras.kondrat...@linaro.org Since I generally just dislike __raw accessors I went and applied this. If it collides with any of Tony's fixup work I might need to take the patch out again, no big deal. Thanks, this should not conflict with what I have. I just had few fixes for the twl4030-gpio for older omaps and I doubt that I have further driver dependencies beyond that for my clean-up work. Some ACKs would be nice, but unless there are major objections this stays merged. Acked-by: Tony Lindgren t...@atomide.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
Re: [PATCH v3 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.
* Balaji T K balaj...@ti.com [131118 08:23]:
On Monday 18 November 2013 05:45 PM, Andreas Fenkart wrote:
2013/11/18 Michael Trimarchi mich...@amarulasolutions.com:
On Mon, Nov 18, 2013 at 8:53 AM, Andreas Fenkart afenk...@gmail.com wrote:
static int omap_hsmmc_card_detect(struct device *dev, int slot)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
@@ -452,10 +474,25 @@ static int omap_hsmmc_gpio_init(struct
omap_mmc_platform_data *pdata)
} else
pdata-slots[0].gpio_wp = -EINVAL;
+ if (gpio_is_valid(pdata-slots[0].gpio_cirq)) {
+ pdata-slots[0].sdio_irq =
+ gpio_to_irq(pdata-slots[0].gpio_cirq);
What is this? re-assign the platform data?
Seems like, I didn't pay attention to this.
Simply kept in line how the write protection/read only pins are managed.
I'd rather not change this part, or not changing it as part of adding
sdio IRQ support it.
Maybe somebody else on the list can explain why the platform data
contains elements
that are modified during runtime.
- set_power / get_ro function callbacks
- ocr_mask.
Hi,
few params were passed via platform data in non-DT case and never cached
in internal data structure, with non-dt support going away soon, I am
planning to cleanup pdata usage in the driver when it gets to DT only support.
The issue of pdata tinkering needs to be fixed first as it will cause nasty
issues when the module is reprobed.
Note that it's still possible to pass platform data in the device tree case
as auxdata. And we probably need to do that for the pbias register handling
until we have a driver for that.
Talking of the pbias driver, any news on it?
To recap, we basically we need a minimal separate driver that exposes the
control module pbias register as a regulator to the hsmmc driver. I don't see
that we can remove the platform data from the driver before that's done.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.
On Tuesday 19 November 2013 09:19 PM, Tony Lindgren wrote:
* Balaji T K balaj...@ti.com [131118 08:23]:
On Monday 18 November 2013 05:45 PM, Andreas Fenkart wrote:
2013/11/18 Michael Trimarchi mich...@amarulasolutions.com:
On Mon, Nov 18, 2013 at 8:53 AM, Andreas Fenkart afenk...@gmail.com wrote:
static int omap_hsmmc_card_detect(struct device *dev, int slot)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
@@ -452,10 +474,25 @@ static int omap_hsmmc_gpio_init(struct
omap_mmc_platform_data *pdata)
} else
pdata-slots[0].gpio_wp = -EINVAL;
+ if (gpio_is_valid(pdata-slots[0].gpio_cirq)) {
+ pdata-slots[0].sdio_irq =
+ gpio_to_irq(pdata-slots[0].gpio_cirq);
What is this? re-assign the platform data?
Seems like, I didn't pay attention to this.
Simply kept in line how the write protection/read only pins are managed.
I'd rather not change this part, or not changing it as part of adding
sdio IRQ support it.
Maybe somebody else on the list can explain why the platform data
contains elements
that are modified during runtime.
- set_power / get_ro function callbacks
- ocr_mask.
Hi,
few params were passed via platform data in non-DT case and never cached
in internal data structure, with non-dt support going away soon, I am
planning to cleanup pdata usage in the driver when it gets to DT only support.
The issue of pdata tinkering needs to be fixed first as it will cause nasty
issues when the module is reprobed.
Agree that pdata usage needs to be fixed, but currently module
reprobe is working fine.
Note that it's still possible to pass platform data in the device tree case
as auxdata. And we probably need to do that for the pbias register handling
until we have a driver for that.
Talking of the pbias driver, any news on it?
Almost there, will post the patches soon.
Do you have a branch with updated board files, for me to base pbias patches on
else I can base the patches on rc1 too.
To recap, we basically we need a minimal separate driver that exposes the
control module pbias register as a regulator to the hsmmc driver. I don't see
that we can remove the platform data from the driver before that's done.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.
* Balaji T K balaj...@ti.com [131119 08:00]: On Tuesday 19 November 2013 09:19 PM, Tony Lindgren wrote: * Balaji T K balaj...@ti.com [131118 08:23]: few params were passed via platform data in non-DT case and never cached in internal data structure, with non-dt support going away soon, I am planning to cleanup pdata usage in the driver when it gets to DT only support. The issue of pdata tinkering needs to be fixed first as it will cause nasty issues when the module is reprobed. Agree that pdata usage needs to be fixed, but currently module reprobe is working fine. OK. The sdio_irq should be just set in struct omap_hsmmc_host instead. Note that it's still possible to pass platform data in the device tree case as auxdata. And we probably need to do that for the pbias register handling until we have a driver for that. Talking of the pbias driver, any news on it? Almost there, will post the patches soon. Do you have a branch with updated board files, for me to base pbias patches on else I can base the patches on rc1 too. Great. How about make the pbias driver DT only? Let's not touch the board-*.c files any longer as those will be going away for v3.14. We can probably keep the old callback support in place also, and then remove it for v3.15. And after that it would certainly make sense to rip out the platform data fomr hsmmc driver just to get rid of the legacy support for multiplexing slots that's not needed in this driver. That would allow replacing all mmc-slots[0] accesses with something more standard. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP2+: Remove legacy mux code for display.c
This is all omap4 specific, which is device tree based
nowadays and should use pinctrl-single instead.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/display.c | 78 ---
1 file changed, 78 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index a4e536b..58347bb 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -32,7 +32,6 @@
#include soc.h
#include iomap.h
-#include mux.h
#include control.h
#include display.h
#include prm.h
@@ -102,90 +101,13 @@ static const struct omap_dss_hwmod_data
omap4_dss_hwmod_data[] __initconst = {
{ dss_hdmi, omapdss_hdmi, -1 },
};
-static void __init omap4_tpd12s015_mux_pads(void)
-{
- omap_mux_init_signal(hdmi_cec,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_ddc_scl,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_ddc_sda,
- OMAP_PIN_INPUT_PULLUP);
-}
-
-static void __init omap4_hdmi_mux_pads(enum omap_hdmi_flags flags)
-{
- u32 reg;
- u16 control_i2c_1;
-
- /*
-* CONTROL_I2C_1: HDMI_DDC_SDA_PULLUPRESX (bit 28) and
-* HDMI_DDC_SCL_PULLUPRESX (bit 24) are set to disable
-* internal pull up resistor.
-*/
- if (flags OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP) {
- control_i2c_1 = OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_I2C_1;
- reg = omap4_ctrl_pad_readl(control_i2c_1);
- reg |= (OMAP4_HDMI_DDC_SDA_PULLUPRESX_MASK |
- OMAP4_HDMI_DDC_SCL_PULLUPRESX_MASK);
- omap4_ctrl_pad_writel(reg, control_i2c_1);
- }
-}
-
-static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
-{
- u32 enable_mask, enable_shift;
- u32 pipd_mask, pipd_shift;
- u32 reg;
-
- if (dsi_id == 0) {
- enable_mask = OMAP4_DSI1_LANEENABLE_MASK;
- enable_shift = OMAP4_DSI1_LANEENABLE_SHIFT;
- pipd_mask = OMAP4_DSI1_PIPD_MASK;
- pipd_shift = OMAP4_DSI1_PIPD_SHIFT;
- } else if (dsi_id == 1) {
- enable_mask = OMAP4_DSI2_LANEENABLE_MASK;
- enable_shift = OMAP4_DSI2_LANEENABLE_SHIFT;
- pipd_mask = OMAP4_DSI2_PIPD_MASK;
- pipd_shift = OMAP4_DSI2_PIPD_SHIFT;
- } else {
- return -ENODEV;
- }
-
- reg = omap4_ctrl_pad_readl(OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_DSIPHY);
-
- reg = ~enable_mask;
- reg = ~pipd_mask;
-
- reg |= (lanes enable_shift) enable_mask;
- reg |= (lanes pipd_shift) pipd_mask;
-
- omap4_ctrl_pad_writel(reg, OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_DSIPHY);
-
- return 0;
-}
-
-int __init omap_hdmi_init(enum omap_hdmi_flags flags)
-{
- if (cpu_is_omap44xx()) {
- omap4_hdmi_mux_pads(flags);
- omap4_tpd12s015_mux_pads();
- }
-
- return 0;
-}
-
static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
{
- if (cpu_is_omap44xx())
- return omap4_dsi_mux_pads(dsi_id, lane_mask);
-
return 0;
}
static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
{
- if (cpu_is_omap44xx())
- omap4_dsi_mux_pads(dsi_id, 0);
}
static int omap_dss_set_min_bus_tput(struct device *dev, unsigned long tput)
--
1.8.1.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
[PATCH 2/2] ARM: OMAP2+: Remove legacy omap4_twl6030_hsmmc_init
This is no longer used, omap4 is device tree based now.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/common.h | 1 -
arch/arm/mach-omap2/omap4-common.c | 57 --
2 files changed, 58 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index f7644fe..e30ef67 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -299,7 +299,6 @@ struct omap_sdrc_params;
extern void omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1);
struct omap2_hsmmc_info;
-extern int omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers);
extern void omap_reserve(void);
struct omap_hwmod;
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index 5791143..b39efd4 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -35,7 +35,6 @@
#include iomap.h
#include common.h
#include mmc.h
-#include hsmmc.h
#include prminst44xx.h
#include prcm_mpu44xx.h
#include omap4-sar-layout.h
@@ -284,59 +283,3 @@ skip_errata_init:
omap_wakeupgen_init();
irqchip_init();
}
-
-#if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
-static int omap4_twl6030_hsmmc_late_init(struct device *dev)
-{
- int irq = 0;
- struct platform_device *pdev = container_of(dev,
- struct platform_device, dev);
- struct omap_mmc_platform_data *pdata = dev-platform_data;
-
- /* Setting MMC1 Card detect Irq */
- if (pdev-id == 0) {
- irq = twl6030_mmc_card_detect_config();
- if (irq 0) {
- dev_err(dev, %s: Error card detect config(%d)\n,
- __func__, irq);
- return irq;
- }
- pdata-slots[0].card_detect_irq = irq;
- pdata-slots[0].card_detect = twl6030_mmc_card_detect;
- }
- return 0;
-}
-
-static __init void omap4_twl6030_hsmmc_set_late_init(struct device *dev)
-{
- struct omap_mmc_platform_data *pdata;
-
- /* dev can be null if CONFIG_MMC_OMAP_HS is not set */
- if (!dev) {
- pr_err(Failed %s\n, __func__);
- return;
- }
- pdata = dev-platform_data;
- pdata-init = omap4_twl6030_hsmmc_late_init;
-}
-
-int __init omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers)
-{
- struct omap2_hsmmc_info *c;
-
- omap_hsmmc_init(controllers);
- for (c = controllers; c-mmc; c++) {
- /* pdev can be null if CONFIG_MMC_OMAP_HS is not set */
- if (!c-pdev)
- continue;
- omap4_twl6030_hsmmc_set_late_init(c-pdev-dev);
- }
-
- return 0;
-}
-#else
-int __init omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers)
-{
- return 0;
-}
-#endif
--
1.8.1.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
[PATCH 0/2] Remove some dead code for omaps
Hi all, I noticed we have some dead code left over after we made omap4 to boot in device tree only mode, so let's just remove it. Regards, Tony Tony Lindgren (2): ARM: OMAP2+: Remove legacy mux code for display.c ARM: OMAP2+: Remove legacy omap4_twl6030_hsmmc_init arch/arm/mach-omap2/common.h | 1 - arch/arm/mach-omap2/display.c | 78 -- arch/arm/mach-omap2/omap4-common.c | 57 3 files changed, 136 deletions(-) -- 1.8.1.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: [RFC 01/23] gpio/omap: raw read and write endian fix
On 11/19/2013 10:29 AM, Linus Walleij wrote: On Sat, Nov 16, 2013 at 1:01 AM, Taras Kondratiuk taras.kondrat...@linaro.org wrote: From: Victor Kamensky victor.kamen...@linaro.org All OMAP IP blocks expect LE data, but CPU may operate in BE mode. Need to use endian neutral functions to read/write h/w registers. I.e instead of __raw_read[lw] and __raw_write[lw] functions code need to use read[lw]_relaxed and write[lw]_relaxed functions. If the first simply reads/writes register, the second will byteswap it if host operates in BE mode. Changes are trivial sed like replacement of __raw_xxx functions with xxx_relaxed variant. Signed-off-by: Victor Kamensky victor.kamen...@linaro.org Signed-off-by: Taras Kondratiuk taras.kondrat...@linaro.org Since I generally just dislike __raw accessors I went and applied this. If it collides with any of Tony's fixup work I might need to take the patch out again, no big deal. Some ACKs would be nice, but unless there are major objections this stays merged. Looks good to me and also I've tested this patch on a TI DM3730 (Cortex A-8) board in LE mode and found no regressions on devices using a GPIO. Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Yours, Linus Walleij Thanks a lot and best regards, Javier -- 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: cpufreq on PandaBoard
Nishanth Menon n...@ti.com writes: On 11/19/2013 08:59 AM, Ben Gamari wrote: Booting a PandaBoard with a recent kernel and devicetree appears to be a rather messy process. There are dozens of devicetree-related warnings spewed on boot (many pertaining to missing regulators). At the moment, however, I'm most interested in this, cpufreq-cpu0 cpufreq-cpu0.0: no of_node; not parsing pinctrl DT cpu cpu0: dummy supplies not allowed cpufreq_cpu0: failed to get cpu0 regulator: -19 cpufreq_cpu0: failed to get cpu0 clock: -2 cpufreq-cpu0: probe of cpufreq-cpu0.0 failed with error -2 What is the status of cpufreq on the PandaBoard? Is this expected to work? More generally, if one wants a fairly recent kernel supporting the PandaBoard's hardware what kernel tree should be used? Is mainline not yet appropriate? Is linux-next preferred? Perhaps a ti-maintained tree? for upstream: Wait for the clock nodes to get merged.. we are at v9 of discussion thread here[1]. I take it that the clock node work does not itself fix cpufreq? I've built the 3.12-dt-clks-v10-dev branch. On the bright side, it boots and appears to run just fine. Unfortunately, there isn't even a mention of cpufreq in the boot log. I've seen your Google+ post[1] from May enumerating the steps to having working DVFS. It would be useful to post an update showing what has been merged, what is waiting for merge, and what is still in progress. for ti-maintained tree, you need to talk to TI support folks for appropriate kernel for your product line. I wasn't asking for official support, just wondering where work is currently happening. Thanks for your help. Cheers, - Ben [1] https://plus.google.com/112464029509057661457/posts/gvyZQcNieoq pgptSEyrcT6dw.pgp Description: PGP signature
Re: cpufreq on PandaBoard
On 11/19/2013 11:18 AM, Ben Gamari wrote: Nishanth Menon n...@ti.com writes: On 11/19/2013 08:59 AM, Ben Gamari wrote: Booting a PandaBoard with a recent kernel and devicetree appears to be a rather messy process. There are dozens of devicetree-related warnings spewed on boot (many pertaining to missing regulators). At the moment, however, I'm most interested in this, cpufreq-cpu0 cpufreq-cpu0.0: no of_node; not parsing pinctrl DT cpu cpu0: dummy supplies not allowed cpufreq_cpu0: failed to get cpu0 regulator: -19 cpufreq_cpu0: failed to get cpu0 clock: -2 cpufreq-cpu0: probe of cpufreq-cpu0.0 failed with error -2 What is the status of cpufreq on the PandaBoard? Is this expected to work? More generally, if one wants a fairly recent kernel supporting the PandaBoard's hardware what kernel tree should be used? Is mainline not yet appropriate? Is linux-next preferred? Perhaps a ti-maintained tree? for upstream: Wait for the clock nodes to get merged.. we are at v9 of discussion thread here[1]. I take it that the clock node work does not itself fix cpufreq? I've built the 3.12-dt-clks-v10-dev branch. On the bright side, it boots and appears to run just fine. Unfortunately, there isn't even a mention of cpufreq in the boot log. You are probably picking up a branch that is yet to be posted :)... and I assume you know the risk of in-development patches ;) - the branch looks to introduce purely clock nodes which patch [2] adds on to and makes cpufreq work as a start.. I've seen your Google+ post[1] from May enumerating the steps to having working DVFS. It would be useful to post an update showing what has been merged, what is waiting for merge, and what is still in progress. We are still at step 1 - get clock nodes :(... and no, situation has not improved since May 2013 when I originally posted that G+ comment (and not because we have not been trying..). for ti-maintained tree, you need to talk to TI support folks for appropriate kernel for your product line. I wasn't asking for official support, just wondering where work is currently happening. they are happening here in linux-omap mailing list.. just that the changes are pretty fundamental and a lot of discussions have been taking place Thanks for your help. Cheers, - Ben [1] https://plus.google.com/112464029509057661457/posts/gvyZQcNieoq [2] http://marc.info/?l=linux-omapm=138193821608515w=2 -- 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 RFC 4/9] ASoC: hdmi-codec: Add devicetree binding with documentation
On Tue, Nov 19, 2013 at 02:12:24PM +0200, Jyri Sarha wrote: Signed-off-by: Jyri Sarha jsa...@ti.com --- Documentation/devicetree/bindings/sound/hdmi.txt | 17 + sound/soc/codecs/hdmi.c | 10 ++ Device tree bindings need to be sent to the DT folks for review as well. This looks OK but it should still go there. signature.asc Description: Digital signature
Re: cpufreq on PandaBoard
Nishanth Menon n...@ti.com writes: On 11/19/2013 11:18 AM, Ben Gamari wrote: I take it that the clock node work does not itself fix cpufreq? I've built the 3.12-dt-clks-v10-dev branch. On the bright side, it boots and appears to run just fine. Unfortunately, there isn't even a mention of cpufreq in the boot log. You are probably picking up a branch that is yet to be posted :)... and I assume you know the risk of in-development patches ;) The house hasn't burned down yet... ;) - the branch looks to introduce purely clock nodes which patch [2] adds on to and makes cpufreq work as a start.. Thanks! I've seen your Google+ post[1] from May enumerating the steps to having working DVFS. It would be useful to post an update showing what has been merged, what is waiting for merge, and what is still in progress. We are still at step 1 - get clock nodes :(... and no, situation has not improved since May 2013 when I originally posted that G+ comment (and not because we have not been trying..). Ouch. Good luck! I wasn't asking for official support, just wondering where work is currently happening. they are happening here in linux-omap mailing list.. just that the changes are pretty fundamental and a lot of discussions have been taking place Thanks! Cheers, - Ben pgp2zx9Gmb5bu.pgp Description: PGP signature
Re: [RFC 01/23] gpio/omap: raw read and write endian fix
Linus Walleij linus.wall...@linaro.org writes: On Sat, Nov 16, 2013 at 1:01 AM, Taras Kondratiuk taras.kondrat...@linaro.org wrote: From: Victor Kamensky victor.kamen...@linaro.org All OMAP IP blocks expect LE data, but CPU may operate in BE mode. Need to use endian neutral functions to read/write h/w registers. I.e instead of __raw_read[lw] and __raw_write[lw] functions code need to use read[lw]_relaxed and write[lw]_relaxed functions. If the first simply reads/writes register, the second will byteswap it if host operates in BE mode. Changes are trivial sed like replacement of __raw_xxx functions with xxx_relaxed variant. Signed-off-by: Victor Kamensky victor.kamen...@linaro.org Signed-off-by: Taras Kondratiuk taras.kondrat...@linaro.org Since I generally just dislike __raw accessors I went and applied this. If it collides with any of Tony's fixup work I might need to take the patch out again, no big deal. Some ACKs would be nice, but unless there are major objections this stays merged. Acked-by: Kevin Hilman khil...@linaro.org -- 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 2/9] ASoC: davinci-evm: Add named clock reference to DT bindings
On Tue, Nov 19, 2013 at 02:12:22PM +0200, Jyri Sarha wrote: .../bindings/sound/davinci-evm-audio.txt |9 ++- sound/soc/davinci/davinci-evm.c| 60 +++- Again this looks sensible but ought to go to the DT folks. signature.asc Description: Digital signature
Re: [PATCH RFC 5/9] ASoC: hdmi-codec: Add SNDRV_PCM_FMTBIT_32_LE playback format
On Tue, Nov 19, 2013 at 02:12:25PM +0200, Jyri Sarha wrote: The new playback format is needed for tda998x HDMI audio support. At the moment the only other user of this codec is omap-hdmi-audio. This change should not break anything because omap-hdmi-audio-dai, the cpu-dai of omap-hdmi-audio, enforces sufficient constraints to available sample formats. Applied, thanks. signature.asc Description: Digital signature
Re: [RFC 01/23] gpio/omap: raw read and write endian fix
On Friday 15 November 2013 07:01 PM, Taras Kondratiuk wrote: From: Victor Kamensky victor.kamen...@linaro.org All OMAP IP blocks expect LE data, but CPU may operate in BE mode. Need to use endian neutral functions to read/write h/w registers. I.e instead of __raw_read[lw] and __raw_write[lw] functions code need to use read[lw]_relaxed and write[lw]_relaxed functions. If the first simply reads/writes register, the second will byteswap it if host operates in BE mode. Changes are trivial sed like replacement of __raw_xxx functions with xxx_relaxed variant. Signed-off-by: Victor Kamensky victor.kamen...@linaro.org Signed-off-by: Taras Kondratiuk taras.kondrat...@linaro.org --- Acked-by: Santosh Shilimkar santosh.shilim...@ti.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
[GIT PULL] few more omap fixes for v3.13 merge window
The following changes since commit 26273e02a0cf18eb72416559310d3294390a9024: ARM: OMAP2+: Fix build for dra7xx without omap4 and 5 (2013-11-15 08:27:29 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.13/more-fixes-for-merge-window-take2 for you to fetch changes up to b2ff4790612bbfa3433cc92e56445c2a40098e2c: ARM: OMAP2+: Remove legacy omap4_twl6030_hsmmc_init (2013-11-18 16:24:58 -0800) Few more fixes for issues found booting older omaps using device tree. Also few randconfig build fixes and removal of some dead code for omap4 as it no longer has legacy platform data based booting support. Tony Lindgren (9): i2c: omap: Fix missing device tree flags for omap2 ARM: OMAP2+: Fix GPMC and simplify bootloader timings for 8250 and smc91x ARM: dts: Fix omap2 specific dtsi files by adding the missing entries ARM: OMAP2+: More randconfig fixes for reconfigure_io_chain gpio: twl4030: Fix regression for twl gpio output gpio: twl4030: Fix passing of pdata in the device tree case ARM: OMAP2+: Fix undefined reference to set_cntfreq ARM: OMAP2+: Remove legacy mux code for display.c ARM: OMAP2+: Remove legacy omap4_twl6030_hsmmc_init Documentation/devicetree/bindings/i2c/i2c-omap.txt | 3 +- arch/arm/boot/dts/omap-zoom-common.dtsi| 2 +- arch/arm/boot/dts/omap2.dtsi | 96 ++ arch/arm/boot/dts/omap2420.dtsi| 23 ++ arch/arm/boot/dts/omap2430.dtsi| 49 +++ arch/arm/mach-omap2/Makefile | 6 +- arch/arm/mach-omap2/common.h | 1 - arch/arm/mach-omap2/display.c | 78 -- arch/arm/mach-omap2/gpmc.c | 58 + arch/arm/mach-omap2/omap-secure.h | 7 ++ arch/arm/mach-omap2/omap4-common.c | 57 - arch/arm/mach-omap2/prm44xx_54xx.h | 2 +- drivers/gpio/gpio-twl4030.c| 13 ++- drivers/i2c/busses/i2c-omap.c | 22 + 14 files changed, 232 insertions(+), 185 deletions(-) -- 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: [GIT PULL] few more omap fixes for v3.13 merge window
On Tue, Nov 19, 2013 at 11:48 AM, Tony Lindgren t...@atomide.com wrote: The following changes since commit 26273e02a0cf18eb72416559310d3294390a9024: ARM: OMAP2+: Fix build for dra7xx without omap4 and 5 (2013-11-15 08:27:29 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.13/more-fixes-for-merge-window-take2 Pulled, thanks. -Olof -- 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 v3 09/10] ARM: dts: omap3-beagle-xm: Add USB Host support
On 09/24/2013 03:53 AM, Roger Quadros wrote:
Provide RESET GPIO and Power regulator for the USB PHY,
the USB Host port mode and the PHY device for the controller.
Also provide pin multiplexer information for USB host pins.
We also relocate omap3_pmx_core pin definations so that they
are close to omap3_pmx_wkup pin definations.
Signed-off-by: Roger Quadros rog...@ti.com
---
just using this thread, but a question -
I am kernel * master dec8e46 Merge
tag 'arc-v3.13-rc1-part2' of
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc
and I see that VAUX2 which supplies USB_1V8[1] is not enabled - I did
a quick patch and it did seem to work (Usb keyboard, networking, mouse
etc on my ehci ports seems to come up good) - any suggestions how we'd
like to handle this?
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -169,6 +169,14 @@
bus-width = 8;
};
+vaux2 {
+ regulator-name = HubPower;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+};
+
+
[1]
https://github.com/CircuitCo/BeagleBoard-xM-RevC/blob/master/BeagleBoard-xM_revC_SCH.pdf?raw=true
arch/arm/boot/dts/omap3-beagle-xm.dts | 65
-
1 files changed, 56 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index afdb164..b081f5a 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -69,6 +69,23 @@
};
};
+
+ /* HS USB Port 2 Power */
+ hsusb2_power: hsusb2_power_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb2_vbus;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = twl_gpio 18 0;/* GPIO LEDA */
+ startup-delay-us = 7;
+ };
+
+ /* HS USB Host PHY on PORT 2 */
+ hsusb2_phy: hsusb2_phy {
+ compatible = usb-nop-xceiv;
+ reset-gpios = gpio5 19 GPIO_ACTIVE_LOW; /* gpio_147 */
+ vcc-supply = hsusb2_power;
+ };
};
omap3_pmx_wkup {
@@ -79,6 +96,37 @@
};
};
+omap3_pmx_core {
+ pinctrl-names = default;
+ pinctrl-0 =
+ hsusbb2_pins
+ ;
+
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins =
+ 0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /*
uart3_rx_irrx.uart3_rx_irrx */
+ 0x170 (PIN_OUTPUT | MUX_MODE0) /*
uart3_tx_irtx.uart3_tx_irtx OUTPUT | MODE0 */
+ ;
+ };
+
+ hsusbb2_pins: pinmux_hsusbb2_pins {
+ pinctrl-single,pins =
+ 0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
+ 0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
+ 0x5c4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d12.hsusb2_dir */
+ 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d13.hsusb2_nxt */
+ 0x5c8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d14.hsusb2_data0 */
+ 0x5cA (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d15.hsusb2_data1 */
+ 0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi1_cs3.hsusb2_data2 */
+ 0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_clk.hsusb2_data7 */
+ 0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_simo.hsusb2_data4 */
+ 0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_somi.hsusb2_data5 */
+ 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs0.hsusb2_data6 */
+ 0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs1.hsusb2_data3 */
+ ;
+ };
+};
+
i2c1 {
clock-frequency = 260;
@@ -148,15 +196,6 @@
power = 50;
};
-omap3_pmx_core {
- uart3_pins: pinmux_uart3_pins {
- pinctrl-single,pins =
- 0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /*
uart3_rx_irrx.uart3_rx_irrx */
- 0x170 (PIN_OUTPUT | MUX_MODE0) /*
uart3_tx_irtx.uart3_tx_irtx OUTPUT | MODE0 */
- ;
- };
-};
-
uart3 {
pinctrl-names = default;
pinctrl-0 = uart3_pins;
@@ -166,3 +205,11 @@
pinctrl-names = default;
pinctrl-0 = gpio1_pins;
};
+
+usbhshost {
+ port2-mode = ehci-phy;
+};
+
+usbhsehci {
+ phys = 0 hsusb2_phy;
+};
--
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 v2 0/3] Add support for charging battery in Nokia RX-51
On Tuesday 19 November 2013 15:44:09 Sebastian Reichel wrote: Hi Pali, On Tue, Nov 19, 2013 at 11:18:02AM +0100, Pali Rohár wrote: This patch series finally bringing support for charging battery on Nokia N900 (RX-51) without any proprietary Nokia bits in userspace. YAY! :) I removed hook function from bq2415x_charger driver and replaced it by Jenny TC power_supply notifier code. This simplify usage of bq2415x driver and also allow adding DT support in future because driver does not need board specific function anymore (only static data). I tested this series with linux 3.12-rc5 on Nokia N900. cool :) Do you want me to take this up and add DT support? -- Sebastian Hello, if you have time, can you add DT support code? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
[PATCH v2 00/11]: add remaining support for IGEP boards
In order to make mach-omap2 Device Tree only, the board file for IGEP boards was removed even when support for wifi and display was still not supported by its DTS. This is a second version of a patch-set that adds support for these remaining peripherals and also adds support for USB, HDMI and user LED for the am33xx SoC based IGEP Aquila board. The patch-set is composed of the following patches: Enric Balletbo i Serra (7): ARM: dts: omap3-igep: Fix bus-width for mmc1. ARM: dts: omap3-igep: Add support for LBEE1USJYC WiFi connected to SDIO. ARM: dts: omap3-igep: Update to use the TI AM/DM37x processor. ARM: dts: AM33XX BASE0033: add pinmux and hdmi node to enable display ARM: dts: AM33XX BASE0033: add pinmux and user led support. ARM: dts: AM33XX BASE0033: add 32KBit EEPROM support. ARM: dts: AM33XX IGEP0033: add USB support. Javier Martinez Canillas (4): ARM: dts: omap3-igep0020: Add pinmux setup for i2c devices ARM: dts: omap3-igep0020: Add pinmuxing for DVI output ARM: OMAP: dss-common: change IGEP's DVI DDC i2c bus ARM: dts: omap3-igep0020: name twl4030 VPLL2 regulator as vdds_dsi Changes since v1: Don't add a workaround in drivers/video/omap2/dss/dpi.c to use the VPLL2 regulator from twl4030 if VDDS_DSI regulator is not linked to the DPI device since the used regulator is a per board configuration. Instead add a regulator-name = vdds_dsi property to the regulator in the IGEPv2 DTS file as suggested by Tony Lindgren. Tony, Most of these patches are just DTS changes so they have to be picked by Benoit besides the following patch that has to go through your tree [PATCH 10/11] ARM: OMAP: dss-common: change IGEP's DVI DDC i2c bus Since we have removed the board file for IGEP boards I think these can be considered as regression fixes for 3.13 although I don't mind if you prefer to wait for 3.14. Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 01/11] ARM: dts: omap3-igep: Fix bus-width for mmc1.
From: Enric Balletbo i Serra eballe...@gmail.com
Both, IGEPv2 and IGEP COM MODULE have a bus-width of 4 not 8, so fix this and
do not mux data pins from mmc1_data4 to mmc1_data7.
Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com
---
arch/arm/boot/dts/omap3-igep.dtsi | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index ba1e58b..d4fecce 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -65,10 +65,6 @@
0x11a (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat1.sdmmc1_dat1 */
0x11c (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat2.sdmmc1_dat2 */
0x11e (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat3.sdmmc1_dat3 */
- 0x120 (PIN_INPUT | MUX_MODE0) /*
sdmmc1_dat4.sdmmc1_dat4 */
- 0x122 (PIN_INPUT | MUX_MODE0) /*
sdmmc1_dat5.sdmmc1_dat5 */
- 0x124 (PIN_INPUT | MUX_MODE0) /*
sdmmc1_dat6.sdmmc1_dat6 */
- 0x126 (PIN_INPUT | MUX_MODE0) /*
sdmmc1_dat7.sdmmc1_dat7 */
;
};
@@ -114,7 +110,7 @@
pinctrl-0 = mmc1_pins;
vmmc-supply = vmmc1;
vmmc_aux-supply = vsim;
- bus-width = 8;
+ bus-width = 4;
};
mmc2 {
--
1.8.4.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 v2 09/11] ARM: dts: AM33XX IGEP0033: add USB support.
From: Enric Balletbo i Serra eballe...@iseebcn.com
Add node to support the USB Host and the USB OTG on the IGEP AQUILA
Processor Board.
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
arch/arm/boot/dts/am335x-igep0033.dtsi | 29 +
1 file changed, 29 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi
b/arch/arm/boot/dts/am335x-igep0033.dtsi
index 6196244..7063311 100644
--- a/arch/arm/boot/dts/am335x-igep0033.dtsi
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -199,6 +199,35 @@
pinctrl-0 = uart0_pins;
};
+usb {
+ status = okay;
+
+ control@44e1 {
+ status = okay;
+ };
+
+ usb-phy@47401300 {
+ status = okay;
+ };
+
+ usb-phy@47401b00 {
+ status = okay;
+ };
+
+ usb@47401000 {
+ status = okay;
+ };
+
+ usb@47401800 {
+ status = okay;
+ dr_mode = host;
+ };
+
+ dma-controller@07402000 {
+ status = okay;
+ };
+};
+
#include tps65910.dtsi
tps {
--
1.8.4.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 v2 10/11] ARM: OMAP: dss-common: change IGEP's DVI DDC i2c bus
IGEP's DVI connector's DDC pins are connected to OMAP's third i2c bus.
When booting with Device Trees the requested bus number is set to -1
which means that the bus number should be dynamically assigned. So the
third i2c bus has 2 has a bus number.
Since now only DT booting is supported for IGEP boards after commit
06ff74fd (ARM: OMAP2+: remove legacy support for IGEP boards), the
i2c bus number has to be changed.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/mach-omap2/dss-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 365bfd3..dadccc9 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -223,7 +223,7 @@ void __init omap_4430sdp_display_init_of(void)
static struct connector_dvi_platform_data omap3_igep2_dvi_connector_pdata = {
.name = dvi,
.source = tfp410.0,
- .i2c_bus_num= 3,
+ .i2c_bus_num= 2,
};
static struct platform_device omap3_igep2_dvi_connector_device = {
--
1.8.4.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 v2 02/11] ARM: dts: omap3-igep: Add support for LBEE1USJYC WiFi connected to SDIO.
From: Enric Balletbo i Serra eballe...@gmail.com
The LBEE1USJYC is a WiFi/BT combo module used on OMAP3-based IGEP boards. In
both cases, IGEPv2 Rev. C and IGEP COM MODULE, the module is connected using
the same MMC interface and uses the same GPIOs.
Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com
---
arch/arm/boot/dts/omap3-igep.dtsi | 45 ++-
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index d4fecce..b3517b2 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -24,6 +24,25 @@
ti,mcbsp = mcbsp2;
ti,codec = twl_audio;
};
+
+ vdd33: regulator-vdd33 {
+ compatible = regulator-fixed;
+ regulator-name = vdd33;
+ regulator-always-on;
+ };
+
+ lbee1usjyc_vmmc: lbee1usjyc_vmmc {
+ pinctrl-names = default;
+ pinctrl-0 = lbee1usjyc_pins;
+ compatible = regulator-fixed;
+ regulator-name = regulator-lbee1usjyc;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio5 10 GPIO_ACTIVE_HIGH;/* gpio_138 WIFI_PDN */
+ startup-delay-us = 1;
+ enable-active-high;
+ vin-supply = vdd33;
+ };
};
omap3_pmx_core {
@@ -48,6 +67,15 @@
;
};
+ /* WiFi/BT combo */
+ lbee1usjyc_pins: pinmux_lbee1usjyc_pins {
+ pinctrl-single,pins =
+ 0x136 (PIN_OUTPUT | MUX_MODE4) /* sdmmc2_dat5.gpio_137
*/
+ 0x138 (PIN_OUTPUT | MUX_MODE4) /* sdmmc2_dat6.gpio_138
*/
+ 0x13a (PIN_OUTPUT | MUX_MODE4) /* sdmmc2_dat7.gpio_139
*/
+ ;
+ };
+
mcbsp2_pins: pinmux_mcbsp2_pins {
pinctrl-single,pins =
0x10c (PIN_INPUT | MUX_MODE0) /*
mcbsp2_fsx.mcbsp2_fsx */
@@ -68,6 +96,17 @@
;
};
+ mmc2_pins: pinmux_mmc2_pins {
+ pinctrl-single,pins =
+ 0x128 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_clk.sdmmc2_clk */
+ 0x12a (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_cmd.sdmmc2_cmd */
+ 0x12c (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_dat0.sdmmc2_dat0 */
+ 0x12e (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_dat1.sdmmc2_dat1 */
+ 0x130 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_dat2.sdmmc2_dat2 */
+ 0x132 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_dat3.sdmmc2_dat3 */
+ ;
+ };
+
smsc911x_pins: pinmux_smsc911x_pins {
pinctrl-single,pins =
0x1a2 (PIN_INPUT | MUX_MODE4) /*
mcspi1_cs2.gpio_176 */
@@ -114,7 +153,11 @@
};
mmc2 {
- status = disabled;
+ pinctrl-names = default;
+ pinctrl-0 = mmc2_pins;
+ vmmc-supply = lbee1usjyc_vmmc;
+ bus-width = 4;
+ non-removable;
};
mmc3 {
--
1.8.4.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 v2 06/11] ARM: dts: AM33XX BASE0033: add pinmux and hdmi node to enable display
From: Enric Balletbo i Serra eballe...@gmail.com
Enable the hdmi output and the LCD Controller on IGEP AQUILA. Also
configure the correct pinmux for output of video data from the SoC
to the HDMI encoder.
Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com
---
arch/arm/boot/dts/am335x-base0033.dts | 47 +++
1 file changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-base0033.dts
b/arch/arm/boot/dts/am335x-base0033.dts
index b4f95c2..3a97613 100644
--- a/arch/arm/boot/dts/am335x-base0033.dts
+++ b/arch/arm/boot/dts/am335x-base0033.dts
@@ -13,4 +13,51 @@
/ {
model = IGEP COM AM335x on AQUILA Expansion;
compatible = isee,am335x-base0033, isee,am335x-igep0033,
ti,am33xx;
+
+ hdmi {
+ compatible = ti,tilcdc,slave;
+ i2c = i2c0;
+ pinctrl-names = default, off;
+ pinctrl-0 = nxp_hdmi_pins;
+ pinctrl-1 = nxp_hdmi_off_pins;
+ status = okay;
+ };
+};
+
+am33xx_pinmux {
+ nxp_hdmi_pins: pinmux_nxp_hdmi_pins {
+ pinctrl-single,pins =
+ 0x1b0 (PIN_OUTPUT | MUX_MODE3) /*
xdma_event_intr0.clkout1 */
+ 0xa0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data0 */
+ 0xa4 (PIN_OUTPUT | MUX_MODE0) /* lcd_data1 */
+ 0xa8 (PIN_OUTPUT | MUX_MODE0) /* lcd_data2 */
+ 0xac (PIN_OUTPUT | MUX_MODE0) /* lcd_data3 */
+ 0xb0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data4 */
+ 0xb4 (PIN_OUTPUT | MUX_MODE0) /* lcd_data5 */
+ 0xb8 (PIN_OUTPUT | MUX_MODE0) /* lcd_data6 */
+ 0xbc (PIN_OUTPUT | MUX_MODE0) /* lcd_data7 */
+ 0xc0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data8 */
+ 0xc4 (PIN_OUTPUT | MUX_MODE0) /* lcd_data9 */
+ 0xc8 (PIN_OUTPUT | MUX_MODE0) /* lcd_data10 */
+ 0xcc (PIN_OUTPUT | MUX_MODE0) /* lcd_data11 */
+ 0xd0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data12 */
+ 0xd4 (PIN_OUTPUT | MUX_MODE0) /* lcd_data13 */
+ 0xd8 (PIN_OUTPUT | MUX_MODE0) /* lcd_data14 */
+ 0xdc (PIN_OUTPUT | MUX_MODE0) /* lcd_data15 */
+ 0xe0 (PIN_OUTPUT | MUX_MODE0) /* lcd_vsync */
+ 0xe4 (PIN_OUTPUT | MUX_MODE0) /* lcd_hsync */
+ 0xe8 (PIN_OUTPUT | MUX_MODE0) /* lcd_pclk */
+ 0xec (PIN_OUTPUT | MUX_MODE0) /* lcd_ac_bias_en */
+ ;
+ };
+ nxp_hdmi_off_pins: pinmux_nxp_hdmi_off_pins {
+ pinctrl-single,pins =
+ 0x1b0 (PIN_OUTPUT | MUX_MODE3) /*
xdma_event_intr0.clkout1 */
+ ;
+ };
};
+
+lcdc {
+ status = okay;
+};
+
--
1.8.4.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 v2 07/11] ARM: dts: AM33XX BASE0033: add pinmux and user led support.
From: Enric Balletbo i Serra eballe...@iseebcn.com
Enable the user leds on the IGEP AQUILA EXPANSION. The has two leds,
one green and one red, that are controllable by software.
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
arch/arm/boot/dts/am335x-base0033.dts | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-base0033.dts
b/arch/arm/boot/dts/am335x-base0033.dts
index 3a97613..2878024 100644
--- a/arch/arm/boot/dts/am335x-base0033.dts
+++ b/arch/arm/boot/dts/am335x-base0033.dts
@@ -22,6 +22,25 @@
pinctrl-1 = nxp_hdmi_off_pins;
status = okay;
};
+
+ leds_base {
+ pinctrl-names = default;
+ pinctrl-0 = leds_base_pins;
+
+ compatible = gpio-leds;
+
+ led@0 {
+ label = base:red:user;
+ gpios = gpio1 21 GPIO_ACTIVE_HIGH; /* gpio1_21 */
+ default-state = off;
+ };
+
+ led@1 {
+ label = base:green:user;
+ gpios = gpio2 0 GPIO_ACTIVE_HIGH;/* gpio2_0 */
+ default-state = off;
+ };
+ };
};
am33xx_pinmux {
@@ -55,6 +74,13 @@
0x1b0 (PIN_OUTPUT | MUX_MODE3) /*
xdma_event_intr0.clkout1 */
;
};
+
+ leds_base_pins: pinmux_leds_base_pins {
+ pinctrl-single,pins =
+ 0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a5.gpio1_21 */
+ 0x88 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_csn3.gpio2_0 */
+ ;
+ };
};
lcdc {
--
1.8.4.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 v2 03/11] ARM: dts: omap3-igep: Update to use the TI AM/DM37x processor.
From: Enric Balletbo i Serra eballe...@gmail.com
Most of the boards are using the TI AM/DM37x processor, there is only a small
quantity of IGEP Processor Boards based on TI OMAP3530. So it's better use the
omap36xx.dtsi include instead of omap34xx.dtsi include.
To avoid confusion we have added to the model the (TI AM/DM37x) comment.
Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com
---
arch/arm/boot/dts/omap3-igep.dtsi| 4 ++--
arch/arm/boot/dts/omap3-igep0020.dts | 4 ++--
arch/arm/boot/dts/omap3-igep0030.dts | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index b3517b2..e4c8769 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -1,5 +1,5 @@
/*
- * Device Tree Source for IGEP Technology devices
+ * Common device tree for IGEP boards based on AM/DM37x
*
* Copyright (C) 2012 Javier Martinez Canillas jav...@collabora.co.uk
* Copyright (C) 2012 Enric Balletbo i Serra eballe...@gmail.com
@@ -10,7 +10,7 @@
*/
/dts-v1/;
-#include omap34xx.dtsi
+#include omap36xx.dtsi
/ {
memory {
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index d5cc792..33ce123 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -1,5 +1,5 @@
/*
- * Device Tree Source for IGEPv2 board
+ * Device Tree Source for IGEPv2 Rev. (TI OMAP AM/DM37x)
*
* Copyright (C) 2012 Javier Martinez Canillas jav...@collabora.co.uk
* Copyright (C) 2012 Enric Balletbo i Serra eballe...@gmail.com
@@ -13,7 +13,7 @@
#include omap-gpmc-smsc911x.dtsi
/ {
- model = IGEPv2;
+ model = IGEPv2 (TI OMAP AM/DM37x);
compatible = isee,omap3-igep0020, ti,omap3;
leds {
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts
b/arch/arm/boot/dts/omap3-igep0030.dts
index 525e6d9..02a23f8 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -1,5 +1,5 @@
/*
- * Device Tree Source for IGEP COM Module
+ * Device Tree Source for IGEP COM MODULE (TI OMAP AM/DM37x)
*
* Copyright (C) 2012 Javier Martinez Canillas jav...@collabora.co.uk
* Copyright (C) 2012 Enric Balletbo i Serra eballe...@gmail.com
@@ -12,7 +12,7 @@
#include omap3-igep.dtsi
/ {
- model = IGEP COM Module;
+ model = IGEP COM MODULE (TI OMAP AM/DM37x);
compatible = isee,omap3-igep0030, ti,omap3;
leds {
--
1.8.4.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 v2 08/11] ARM: dts: AM33XX BASE0033: add 32KBit EEPROM support.
From: Enric Balletbo i Serra eballe...@iseebcn.com
The IGEP AQUILA EXPANSION has a 32KBit EEPROM for user data storage.
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
arch/arm/boot/dts/am335x-base0033.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-base0033.dts
b/arch/arm/boot/dts/am335x-base0033.dts
index 2878024..a76ea11 100644
--- a/arch/arm/boot/dts/am335x-base0033.dts
+++ b/arch/arm/boot/dts/am335x-base0033.dts
@@ -87,3 +87,10 @@
status = okay;
};
+i2c0 {
+ eeprom: eeprom@50 {
+ compatible = at,24c256;
+ reg = 0x50;
+ };
+};
+
--
1.8.4.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 v2 05/11] ARM: dts: omap3-igep0020: Add pinmuxing for DVI output
The IGEPv2 has a TFP410 DPI-to-DVI encoder attached to OMAP's
Display SubSystem (DSS).
Add mux setup for DSS pins and also for the GPIO 170 pin that
is used to ensure that the DVI-D is powered down on power up.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep0020.dts | 41
1 file changed, 41 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index 33ce123..b9a9e17 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -67,6 +67,8 @@
pinctrl-names = default;
pinctrl-0 =
hsusbb1_pins
+ tfp410_pins
+ dss_pins
;
hsusbb1_pins: pinmux_hsusbb1_pins {
@@ -85,6 +87,45 @@
0x5ba (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d7.hsusb1_data3 */
;
};
+
+ tfp410_pins: tfp410_dvi_pins {
+ pinctrl-single,pins =
+ 0x196 (PIN_OUTPUT | MUX_MODE4) /* hdq_sio.gpio_170 */
+ ;
+ };
+
+ dss_pins: pinmux_dss_dvi_pins {
+ pinctrl-single,pins =
+ 0x0a4 (PIN_OUTPUT | MUX_MODE0) /* dss_pclk.dss_pclk */
+ 0x0a6 (PIN_OUTPUT | MUX_MODE0) /* dss_hsync.dss_hsync
*/
+ 0x0a8 (PIN_OUTPUT | MUX_MODE0) /* dss_vsync.dss_vsync
*/
+ 0x0aa (PIN_OUTPUT | MUX_MODE0) /*
dss_acbias.dss_acbias */
+ 0x0ac (PIN_OUTPUT | MUX_MODE0) /* dss_data0.dss_data0
*/
+ 0x0ae (PIN_OUTPUT | MUX_MODE0) /* dss_data1.dss_data1
*/
+ 0x0b0 (PIN_OUTPUT | MUX_MODE0) /* dss_data2.dss_data2
*/
+ 0x0b2 (PIN_OUTPUT | MUX_MODE0) /* dss_data3.dss_data3
*/
+ 0x0b4 (PIN_OUTPUT | MUX_MODE0) /* dss_data4.dss_data4
*/
+ 0x0b6 (PIN_OUTPUT | MUX_MODE0) /* dss_data5.dss_data5
*/
+ 0x0b8 (PIN_OUTPUT | MUX_MODE0) /* dss_data6.dss_data6
*/
+ 0x0ba (PIN_OUTPUT | MUX_MODE0) /* dss_data7.dss_data7
*/
+ 0x0bc (PIN_OUTPUT | MUX_MODE0) /* dss_data8.dss_data8
*/
+ 0x0be (PIN_OUTPUT | MUX_MODE0) /* dss_data9.dss_data9
*/
+ 0x0c0 (PIN_OUTPUT | MUX_MODE0) /*
dss_data10.dss_data10 */
+ 0x0c2 (PIN_OUTPUT | MUX_MODE0) /*
dss_data11.dss_data11 */
+ 0x0c4 (PIN_OUTPUT | MUX_MODE0) /*
dss_data12.dss_data12 */
+ 0x0c6 (PIN_OUTPUT | MUX_MODE0) /*
dss_data13.dss_data13 */
+ 0x0c8 (PIN_OUTPUT | MUX_MODE0) /*
dss_data14.dss_data14 */
+ 0x0ca (PIN_OUTPUT | MUX_MODE0) /*
dss_data15.dss_data15 */
+ 0x0cc (PIN_OUTPUT | MUX_MODE0) /*
dss_data16.dss_data16 */
+ 0x0ce (PIN_OUTPUT | MUX_MODE0) /*
dss_data17.dss_data17 */
+ 0x0d0 (PIN_OUTPUT | MUX_MODE0) /*
dss_data18.dss_data18 */
+ 0x0d2 (PIN_OUTPUT | MUX_MODE0) /*
dss_data19.dss_data19 */
+ 0x0d4 (PIN_OUTPUT | MUX_MODE0) /*
dss_data20.dss_data20 */
+ 0x0d6 (PIN_OUTPUT | MUX_MODE0) /*
dss_data21.dss_data21 */
+ 0x0d8 (PIN_OUTPUT | MUX_MODE0) /*
dss_data22.dss_data22 */
+ 0x0da (PIN_OUTPUT | MUX_MODE0) /*
dss_data23.dss_data23 */
+ ;
+ };
};
leds_pins {
--
1.8.4.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 v2 11/11] ARM: dts: omap3-igep0020: name twl4030 VPLL2 regulator as vdds_dsi
On Device Tree boot the VDDS_DSI regulator is not linked to
the DPI device so omapfb driver probing fails with:
[3.186035] OMAPFB: omapfb_probe
[3.190704] omapdss DPI error: can't get VDDS_DSI regulator
[3.196594] omapfb omapfb: failed to connect default display
[3.202667] omapfb omapfb: failed to init overlay connections
[3.208892] OMAPFB: free_resources
[3.212493] OMAPFB: free all fbmem
[3.216735] omapfb omapfb: failed to setup omapfb
As a workaround name the VPLL2 regulator from twl4030 as vdds_dsi
so getting the VDDS_DSI regulator will succeed on dpi_init_regulator().
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep0020.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index b9a9e17..1c7e74d 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -215,3 +215,8 @@
usbhsehci {
phys = hsusb1_phy;
};
+
+vpll2 {
+/* Needed for DSS */
+regulator-name = vdds_dsi;
+};
--
1.8.4.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 v2 04/11] ARM: dts: omap3-igep0020: Add pinmux setup for i2c devices
Add pin muxing support for IGEP boards i2c controllers.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep.dtsi | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index e4c8769..165aaf7 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -113,10 +113,33 @@
;
};
+ i2c1_pins: pinmux_i2c1_pins {
+ pinctrl-single,pins =
+ 0x18a (PIN_INPUT | MUX_MODE0) /* i2c1_scl.i2c1_scl */
+ 0x18c (PIN_INPUT | MUX_MODE0) /* i2c1_sda.i2c1_sda */
+ ;
+ };
+
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins =
+ 0x18e (PIN_INPUT | MUX_MODE0) /* i2c2_scl.i2c2_scl */
+ 0x190 (PIN_INPUT | MUX_MODE0) /* i2c2_sda.i2c2_sda */
+ ;
+ };
+
+ i2c3_pins: pinmux_i2c3_pins {
+ pinctrl-single,pins =
+ 0x192 (PIN_INPUT | MUX_MODE0) /* i2c3_scl.i2c3_scl */
+ 0x194 (PIN_INPUT | MUX_MODE0) /* i2c3_sda.i2c3_sda */
+ ;
+ };
+
leds_pins: pinmux_leds_pins { };
};
i2c1 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c1_pins;
clock-frequency = 260;
twl: twl@48 {
@@ -136,9 +159,16 @@
#include twl4030_omap3.dtsi
i2c2 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c2_pins;
clock-frequency = 40;
};
+i2c3 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c3_pins;
+};
+
mcbsp2 {
pinctrl-names = default;
pinctrl-0 = mcbsp2_pins;
--
1.8.4.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: [BUG] PandaBoard hangs before starting init while booting v3.12
Hi, I also try to boot v3.12 on my pandaboard rev A2, but it hangs at starting kernel. My SD card is originally loaded with a linaro 12.04 ubuntu-developer image. I have tried with v3.7 and v3.8 uImage and both of them work normally, but v3.12 hangs. Is there any trick I missed? Do I need to use the new u-boot as used by Ben? And here is a separate problem with building u-boot. I cloned the upstream u-boot repository. The latest commit is c2e5e802ecb7ab668ce9911b210ed68c804b349f. Then I did: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- omap4_panda_config make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- -j8 cp MLO u-boot.img /media/boot/ But when turn on my pandaboard, there is NO output from the serial console. I didn't change the other file in the boot partition. They are from linaro 12.04 ubuntu-developer image. Any help would be much appreciated! On Mon, Nov 18, 2013 at 9:14 AM, Ben Gamari bgamari.f...@gmail.com wrote: I'm having difficulty getting a PandaBoard ES rev. B1 to boot v3.12 and linux-next (30121118). I'm booting with a brand new u-boot (c2e5e802ecb7ab668ce9911b210ed68c804b349f). In both cases the device appears to hang shortly before one would expect init to start as seen in the boot output below. I'm booting with the omap4-panda-es devicetree. As far as I can tell, the machine is completely dead and will not respond to even sysrq. I have a PandaBoard A4 which apparently has no trouble with the same kernel image. The only issues I can see in the output are, * pinctrl issues pertaining to wl12xx[1], these shouldn't cause the machine not to boot * Various missing vmmc regulators * hw-breakpoint issues: * Failed to enable monitor mode on CPU 0 * CPU 0 failed to disable vector catch These sound serious and occur near the hang. Perhaps this is the culprit? Any help would be greatly appreciated. Cheers, - Ben [1] http://www.spinics.net/lists/devicetree/msg07983.html reading uEnv-new.txt 1147 bytes read in 5 ms (223.6 KiB/s) Importing environment from mmc0 ... Running uenvcmd ... reading zImage-new 3738608 bytes read in 172 ms (20.7 MiB/s) reading uInitrd-new.img 3241151 bytes read in 157 ms (19.7 MiB/s) reading /dtbs-new/omap4-panda-es.dtb 20188 bytes read in 10 ms (1.9 MiB/s) Kernel image @ 0x8030 [ 0x00 - 0x390bf0 ] ## Loading init Ramdisk from Legacy Image at 8160 ... Image Name: Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size:3241087 Bytes = 3.1 MiB Load Address: 8160 Entry Point: 8160 Verifying Checksum ... OK ## Flattened Device Tree blob at 815f Booting using the fdt blob at 0x815f Loading Ramdisk to 8fce8000, end 847f ... OK Using Device Tree in place at 815f, end 815f7edb Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.12.0-next-20131118 (ben@ben-server) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) ) #11 SMP Mon Nov 18 02:24:43 EST 2013 [0.00] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine model: TI OMAP4 PandaBoard [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: Data cache writealloc [0.00] OMAP4460 ES1.1 [0.00] PERCPU: Embedded 9 pages/cpu @c13c8000 s13568 r8192 d15104 u36864 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260368 [0.00] Kernel command line: console=ttyO2,115200n8 earlyprintk initcall_debug vram=16M omapfb.mode=: omapdss.def_disp= root=/dev/mmcblk0p5 ro rootfstype=ext4 fixrtc [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] allocated 2097152 bytes of page_cgroup [0.00] please try 'cgroup_disable=memory' option if you don't want memory cgroups [0.00] Memory: 1021188K/1047552K available (7108K kernel code, 620K rwdata, 2940K rodata, 457K init, 833K bss, 26364K reserved, 269312K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xf000 - 0xff00 ( 240 MB) [0.00] lowmem : 0xc000 - 0xef80 ( 760 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc09d845c (10050 kB) [0.00] .init : 0xc09d9000 - 0xc0a4b500
[PATCH] ARM: OMAP2+: Fix populating the hwmod data from device tree
We have some device tree properties where the ti,hwmod has multiple
values:
am33xx.dtsi:ti,hwmods = tpcc, tptc0, tptc1, tptc2;
am4372.dtsi:ti,hwmods = tpcc, tptc0, tptc1, tptc2;
dra7.dtsi: ti,hwmods = l3_main_1, l3_main_2;
omap3.dtsi: ti,hwmods = mcbsp2, mcbsp2_sidetone;
omap3.dtsi: ti,hwmods = mcbsp3, mcbsp3_sidetone;
omap4.dtsi: ti,hwmods = l3_main_1, l3_main_2, l3_main_3;
omap5.dtsi: ti,hwmods = l3_main_1, l3_main_2, l3_main_3;
So we need to handle the whole string array instead of just the
first string to find the related hwmod entry.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2228,11 +2228,23 @@ static struct device_node *of_dev_hwmod_lookup(struct
device_node *np,
struct omap_hwmod *oh)
{
struct device_node *np0 = NULL, *np1 = NULL;
- const char *p;
for_each_child_of_node(np, np0) {
- if (of_find_property(np0, ti,hwmods, NULL)) {
- p = of_get_property(np0, ti,hwmods, NULL);
+ int count, i;
+
+ count = of_property_count_strings(np0, ti,hwmods);
+ if (count 1)
+ continue;
+
+ for (i = 0; i count; i++) {
+ const char *p;
+ int res;
+
+ res = of_property_read_string_index(np0, ti,hwmods,
+ i, p);
+ if (res)
+ continue;
+
if (!strcmp(p, oh-name))
return np0;
np1 = of_dev_hwmod_lookup(np0, oh);
--
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: [BUG] PandaBoard hangs before starting init while booting v3.12
Chao Xu caesarxuc...@gmail.com writes: Hi, I also try to boot v3.12 on my pandaboard rev A2, but it hangs at starting kernel. My SD card is originally loaded with a linaro 12.04 ubuntu-developer image. I have tried with v3.7 and v3.8 uImage and both of them work normally, but v3.12 hangs. Is there any trick I missed? Do I need to use the new u-boot as used by Ben? I've written up some of my experiences bringing up 3.12 on the PandaBoard here[1]. You may find it helpful. Regardless, I would definitely try upgrading u-boot. And here is a separate problem with building u-boot. I cloned the upstream u-boot repository. The latest commit is c2e5e802ecb7ab668ce9911b210ed68c804b349f. Then I did: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- omap4_panda_config make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- -j8 cp MLO u-boot.img /media/boot/ But when turn on my pandaboard, there is NO output from the serial console. I didn't change the other file in the boot partition. They are from linaro 12.04 ubuntu-developer image. I would check that you have earlyprintk enabled (both in the kernel configuration as well as on the kernel command line). Moreover, ensure that the correct serial devices is selected for low-level debug output (in the kernel configuration). Cheers, - Ben [1] http://bgamari.github.io/posts/2013-11-17-running-modern-kernel-on-pandaboard.html pgpXEq97V9CLv.pgp Description: PGP signature
