[PATCH 0/3] Changes to cpsw and davinci_emac for getting MAC address
Hi all, Here are a few patches to add common code for cpsw and davinci_emac for getting the MAC address. Looks like we can also now add code to get the MAC address on 3517 but in a slightly different way. Regards, Tony Tony Lindgren (3): net: cpsw: Add a minimal cpsw-common module for shared code net: davinci_emac: Get device dm816x MAC address using the cpsw code net: davinci_emac: Get device MAC on 3517 arch/arm/boot/dts/am3517.dtsi | 1 + drivers/net/ethernet/ti/Makefile | 3 ++ drivers/net/ethernet/ti/cpsw-common.c | 53 drivers/net/ethernet/ti/cpsw.c | 35 ++--- drivers/net/ethernet/ti/cpsw.h | 2 ++ drivers/net/ethernet/ti/davinci_emac.c | 56 +- 6 files changed, 116 insertions(+), 34 deletions(-) create mode 100644 drivers/net/ethernet/ti/cpsw-common.c -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dtc: parser: Add label while overriding nodes
This patch changes the dtc grammar to allow following syntax
i2cexp: i2c2 {
...
};
Current device tree compiler allows to define multiple labels when defining
the device node the first time. Typically device nodes are defined in
DTSI files. Now these nodes can be overwritten for updating some of the
properties. Typically, device nodes are overridden in DTS files.
When working with adapter boards, most of the time adapter board can fit to
multiple base boards. But depending on which base board it is connected to,
the devices on the adapter board would be children of different devices.
e.g. On dra7-evm.dts, i2c2 is exported for expansion connector whereas
on dra72-evm.dts, i2c5 is exported for expansion connector.
This causes a problem when writing a generic device tree file for
the adapter board. Because, you cannot know whether all the devices on
adapter board are present on i2c or i2c5.
The problem can be solved by adding a common label (e.g. i2cexp) in both
of the DTS files when overriding the device nodes for i2c2 or i2c5.
This way, generic adapter board file would override the i2cexp. And
depending on which base board you use the adapter board, all the devices
are automatically added for correct device nodes.
Signed-off-by: Nikhil Devshatwar nikhil...@ti.com
---
dtc-parser.y | 12
1 file changed, 12 insertions(+)
diff --git a/dtc-parser.y b/dtc-parser.y
index ea57e0a..5a897e3 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -140,6 +140,18 @@ devicetree:
{
$$ = merge_nodes($1, $3);
}
+
+ | devicetree DT_LABEL DT_REF nodedef
+ {
+ struct node *target = get_node_by_ref($1, $3);
+
+ add_label(target-labels, $2);
+ if (target)
+ merge_nodes(target, $4);
+ else
+ ERROR(@3, Label or path %s not found, $3);
+ $$ = $1;
+ }
| devicetree DT_REF nodedef
{
struct node *target = get_node_by_ref($1, $2);
--
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 4/4] ARM: dts: Add minimal support for dm8168-evm
* Tony Lindgren t...@atomide.com [150123 08:54]: Should be usable for NFSroot with all the patches I've sent using the ti u-boot and and appended DTB uImage. Sorry not all of it is yet in Linux next though, I'll push a current testing branch at some point today. The mainline u-boot was at least missing the davinci_emac support the last time I tried. Seems to be all in today's Linux next and I just verified that 3.19.0-rc6-next-20150128-06478-g30720bbe is booting on 8168-evm. 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: clk: ti: Add support for FAPLL on dm816x
* Dan Carpenter dan.carpen...@oracle.com [150128 03:08]:
Hello Tony Lindgren,
The patch 163152cbbe32: clk: ti: Add support for FAPLL on dm816x
from Jan 13, 2015, leads to the following static checker warning:
drivers/clk/ti/fapll.c:87 ti_fapll_enable()
warn: double left shift '1 (1 (3))'
drivers/clk/ti/fapll.c
82 static int ti_fapll_enable(struct clk_hw *hw)
83 {
84 struct fapll_data *fd = to_fapll(hw);
85 u32 v = readl_relaxed(fd-base);
86
87 v |= (1 FAPLL_MAIN_PLLEN);
FAPLL_MAIN_PLLEN() is BIT(3). It's possible that this code is correct
as is, but as a complete outsider I think it's more likely that the
code should be:
v |= FAPLL_MAIN_PLLEN;
88 writel_relaxed(v, fd-base);
89
90 return 0;
91 }
92
93 static void ti_fapll_disable(struct clk_hw *hw)
94 {
95 struct fapll_data *fd = to_fapll(hw);
96 u32 v = readl_relaxed(fd-base);
97
98 v = ~(1 FAPLL_MAIN_PLLEN);
^
Same.
99 writel_relaxed(v, fd-base);
100 }
101
102 static int ti_fapll_is_enabled(struct clk_hw *hw)
103 {
104 struct fapll_data *fd = to_fapll(hw);
105 u32 v = readl_relaxed(fd-base);
106
107 return v (1 FAPLL_MAIN_PLLEN);
^^^
Same.
108 }
Thanks for catching that. Yes that's a bug, I've screwed up
while cleaning up and means the parent PLL will not get disabled
even if all the children are disabled.
Will send a fix shortly.
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] ASoC: rx51: do not fail if could not get jack detection gpio
It is quite important to keep qemu working, really. Debugging early boot on hardware is very hard, for example. I understand, but looking at the history of the driver, if it fails now with the jack-detection GPIO, it should have been failing in the past as well. What triggered this sudden qemu does not like jack-detection GPIO? Before the devm_gpiod_get() conversion the driver should have failed in snd_soc_jack_add_gpios() phase. With 3.12 kernel rx51-audio driver loads without any problem. So there is some regression. Here is dmesg log from 3.12 kernel: [1.123779] rx51-audio rx51-audio: tlv320aic3x-hifi - omap- mcbsp.2 mapping ok [1.130737] tlv320aic3x-codec 2-0019: ASoC: mux b Right Line1L Mux has no paths [1.131347] tlv320aic3x-codec 2-0019: ASoC: mux b Left Line1R Mux has no paths [1.133697] tlv320aic3x-codec 2-0018: ASoC: mux Right Line1L Mux has no paths [1.134307] tlv320aic3x-codec 2-0018: ASoC: mux Left Line1R Mux has no paths [1.137451] input: RX-51 AV Jack as /devices/platform/rx51- audio/sound/card0/input2 I will try to investigate where is problem... Ok, problem found and solved. Please drop my patch and sorry for a noise. As is visible in above lines AV Jack is working fine on non DT kernel (3.12) and fails on DT kernel. Reason is because I have another non-mainline driver which is using GPIOs and in non DT kernel is initialized *after* audio. And in DT kernel is initialized *before* audio. Once I changed my non-mainline driver to not request av jack gpio, rx51-audio driver loads fine in qemu. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH v2 1/7] extcon: usb-gpio: Introduce gpio usb extcon driver
Chanwoo,
On 28/01/15 04:19, Chanwoo Choi wrote:
Hi Roger,
On 01/28/2015 12:38 AM, Roger Quadros wrote:
Chanwoo,
On 27/01/15 03:54, Chanwoo Choi wrote:
Hi Roger,
On 01/27/2015 01:27 AM, Roger Quadros wrote:
Hi Chanwoo,
All your comments are valid. Need some clarification on one comment.
On 26/01/15 15:56, Chanwoo Choi wrote:
Hi Roger,
This patch looks good to me. But I add some comment.
If you modify some comment, I'll apply this patch on 3.21 queue.
On Mon, Jan 26, 2015 at 9:15 PM, Roger Quadros rog...@ti.com wrote:
This driver observes the USB ID pin connected over a GPIO and
updates the USB cable extcon states accordingly.
The existing GPIO extcon driver is not suitable for this purpose
as it needs to be taught to understand USB cable states and it
can't handle more than one cable per instance.
For the USB case we need to handle 2 cable states.
1) USB (attach/detach)
2) USB-Host (attach/detach)
This driver can be easily updated in the future to handle VBUS
events in case it happens to be available on GPIO for any platform.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/extcon/extcon-usb-gpio.txt | 20 ++
drivers/extcon/Kconfig | 7 +
drivers/extcon/Makefile| 1 +
drivers/extcon/extcon-usb-gpio.c | 214
+
4 files changed, 242 insertions(+)
create mode 100644
Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
create mode 100644 drivers/extcon/extcon-usb-gpio.c
snip
+
+static int usb_extcon_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct device_node *np = dev-of_node;
+ struct usb_extcon_info *info;
+ int ret;
+
+ if (!np)
+ return -EINVAL;
+
+ info = devm_kzalloc(pdev-dev, sizeof(*info), GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+
+ info-dev = dev;
+ info-id_gpiod = devm_gpiod_get(pdev-dev, id);
+ if (IS_ERR(info-id_gpiod)) {
+ dev_err(dev, failed to get ID GPIO\n);
+ return PTR_ERR(info-id_gpiod);
+ }
+
+ ret = gpiod_set_debounce(info-id_gpiod,
+USB_GPIO_DEBOUNCE_MS * 1000);
+ if (ret 0)
+ info-debounce_jiffies =
msecs_to_jiffies(USB_GPIO_DEBOUNCE_MS);
+
+ INIT_DELAYED_WORK(info-wq_detcable, usb_extcon_detect_cable);
+
+ info-id_irq = gpiod_to_irq(info-id_gpiod);
+ if (info-id_irq 0) {
+ dev_err(dev, failed to get ID IRQ\n);
+ return info-id_irq;
+ }
+
+ ret = devm_request_threaded_irq(dev, info-id_irq, NULL,
+ usb_irq_handler,
+ IRQF_SHARED | IRQF_ONESHOT |
+ IRQF_NO_SUSPEND,
+ pdev-name, info);
use of IRQF_NO_SUSPEND is not recommended to be used together with
IRQF_SHARED so
I'll remove IRQF_SHARED from here if we decide to stick with
IRQF_NO_SUSPEND.
More on this below.
+ if (ret 0) {
+ dev_err(dev, failed to request handler for ID IRQ\n);
+ return ret;
+ }
+
+ info-edev = devm_extcon_dev_allocate(dev, usb_extcon_cable);
+ if (IS_ERR(info-edev)) {
+ dev_err(dev, failed to allocate extcon device\n);
+ return -ENOMEM;
+ }
+
+ ret = devm_extcon_dev_register(dev, info-edev);
+ if (ret 0) {
+ dev_err(dev, failed to register extcon device\n);
+ return ret;
+ }
+
+ platform_set_drvdata(pdev, info);
I prefer to execute the device_init_wakeup() function as following
for suspend/resume function:
device_init_wakeup(pdev-dev, 1);
+
+ /* Perform initial detection */
+ usb_extcon_detect_cable(info-wq_detcable.work);
+
+ return 0;
+}
+
+static int usb_extcon_remove(struct platform_device *pdev)
+{
+ struct usb_extcon_info *info = platform_get_drvdata(pdev);
+
+ cancel_delayed_work_sync(info-wq_detcable);
Need to add blank line.
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int usb_extcon_suspend(struct device *dev)
+{
+ struct usb_extcon_info *info = dev_get_drvdata(dev);
+
+ enable_irq_wake(info-id_irq);
I prefer to use device_may_wakeup() function for whether
executing enable_irq_wake() or not. Also, The disable_irq()
in the suspend function would prevent us from discarding interrupt
before wakeup from suspend completely.
I need more clarification here.
If we are going to use enable_irq_wake() here then what is the point of
IRQF_NO_SUSPEND?
From Documentation/power/suspend-and-interrupts.txt I see that interrupts
marked
as IRQF_NO_SUSPEND should not be configured for system wakeup using
Re: [PATCH v2 1/7] extcon: usb-gpio: Introduce gpio usb extcon driver
* Roger Quadros rog...@ti.com [150128 04:15]: On 28/01/15 04:19, Chanwoo Choi wrote: I still fail to understand that we need to call disable_irq() in .suspend() and enable_irq() in .resume() can you point me to any other drivers doing so? You can refer the suspend function in drivers/mfd/max14577.c or drivers/mfd/max77693.c. The max14577_suspend() includes the detailed comment for why using disable_irq() in suspend function. In max14577 case, max14577_suspend() use disable_irq() function because of i2c dependency. If max14577 device is wake-up from suspend state before completing the resume sequence of i2c, max14577 may fail to read/write i2c communication. Thanks for this information. I will add disable/enable_irq() in suspend/resume(). Are the .dts changes safe for me to apply already? 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 3/3] mmc: omap_hsmmc: switch to 1-bit before turning off clocks if interrupts expected.
On 28 January 2015 at 00:35, NeilBrown ne...@suse.de wrote:
According to section 7.1.2 of
http://www.sandisk.com/media/File/OEM/Manuals/SD_SDIO_specsv1.pdf
In the case where the interrupt mechanism is used to wake the host while
the card is in a low power state (i.e. no clocks), Both the card and the
host shall be placed into the 1-bit SD mode prior to stopping the clock.
This is particularly important for the Marvell libertas wifi chip
in the GTA04. While in 4-bit mode it will only signal an interrupt
when the clock is running (which is why setting CLKEXTFREE is
important).
In 1-bit mode, the interrupt is asynchronous (explained in OMAP3
TRM description of the CIRQ flag to MMCHS_STAT:
In 1-bit mode, interrupt source is asynchronous (can be a source of
asynchronous wakeup).
In 4-bit mode, interrupt source is sampled during the interrupt
cycle.
)
We cannot simply set 1-bit mode in omap_hsmmc_runtime_suspend
as that is called under a spinlock, and setting 1-bit mode requires
a sleeping call to the card.
So:
- use a work_struct to schedule setting of 1-bit mode
- intro a 'force_narrow' state flag which transitions:
0 - NARROW_PENDING - NARROW_FORCED - 0
- have omap_hsmmc_runtime_suspend fail if interrupts are expected
but bus is not in 1-bit mode. When it fails it schedules
the work to change the width. and sets NARROW_PENDING
- when the host is claimed, if NARROW_FORCED is set, restore the
4-bit bus
- When the host is released (disable_fclk), if NARROW_FORCED,
then suspend immediately, no autosuspend. If NARROW_PENDING,
clear that flag as the device has obviously just been used.
I can't give you more detailed comment about this patch(set) yet. Need
to think a bit more first.
Anyway, I have one concern, see comment below.
This all allows a graceful and race-free switch to 1-bit mode
before switching off the clocks, if interrupts are enabled.
With this, I can use my libertas wifi with a 4-bit bus, with
interrupts and runtime power-management enabled, and get around
14Mb/sec throughput (which is the best I've seen).
Signed-off-by: NeilBrown n...@brown.name
---
drivers/mmc/host/omap_hsmmc.c | 55
-
1 file changed, 53 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index f84cfb01716d..91ddebbec8a3 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -214,6 +214,10 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+ int force_narrow;
+#define NARROW_PENDING 1
+#define NARROW_FORCED 2
+ struct work_struct width_work;
unsigned long clk_rate;
unsigned intflags;
#define AUTO_CMD23 (1 0)/* Auto CMD23 support */
@@ -1778,12 +1782,43 @@ static void omap_hsmmc_conf_bus_power(struct
omap_hsmmc_host *host)
set_sd_bus_power(host);
}
+static void omap_hsmmc_width_work(struct work_struct *work)
+{
+ struct omap_hsmmc_host *host = container_of(work,
+ struct omap_hsmmc_host,
+ width_work);
+ atomic_t noblock;
+
+ atomic_set(noblock, 1);
+ if (__mmc_claim_host(host-mmc, noblock)) {
+ /* Device active again */
+ host-force_narrow = 0;
+ return;
+ }
+ if (host-force_narrow != NARROW_PENDING) {
+ /* Someone claimed and released before we got here */
+ mmc_release_host(host-mmc);
+ return;
+ }
+ if (sdio_disable_wide(host-mmc-card) == 0)
+ host-force_narrow = NARROW_FORCED;
+ else
+ host-force_narrow = 0;
+ mmc_release_host(host-mmc);
+}
+
static int omap_hsmmc_enable_fclk(struct mmc_host *mmc)
{
struct omap_hsmmc_host *host = mmc_priv(mmc);
pm_runtime_get_sync(host-dev);
+ if (host-force_narrow == NARROW_FORCED) {
+ if (sdio_enable_4bit_bus(mmc-card) 0)
+ mmc_set_bus_width(mmc, MMC_BUS_WIDTH_4);
+ host-force_narrow = 0;
+ }
+
return 0;
}
@@ -1791,8 +1826,13 @@ static int omap_hsmmc_disable_fclk(struct mmc_host
*mmc)
{
struct omap_hsmmc_host *host = mmc_priv(mmc);
- pm_runtime_mark_last_busy(host-dev);
- pm_runtime_put_autosuspend(host-dev);
+ if (host-force_narrow == NARROW_FORCED) {
+ pm_runtime_put_sync(host-dev);
+ } else {
+ host-force_narrow = 0;
+ pm_runtime_mark_last_busy(host-dev);
+ pm_runtime_put_autosuspend(host-dev);
+ }
return 0;
}
@@
Re: 3.19 on Nokia n900: audio quality awful
On 01/26/2015 03:20 PM, Peter Ujfalusi wrote: On 01/18/2015 02:01 PM, Pavel Machek wrote: In 2.6.28-nokia, it is neccessary to set Input select na digital mic, then it works. Input select being in playback option makes it easy to miss. In 3.18 and 3.19-rc3, all I can record are zeros. Does playback/recording work for you on OMAP 3430-based machines? Same codec (tlv320aic3106) works fine on my am335x and omap-l138 boards. BeagleBoard-xM also fine with twl4030 codec. I don't have my n900 in hacking mode (it is still in use time-to-time) but looking at the dts file: you might want to add ai3x-micbias-vg property to the aic3x nodes to select the correct mic bias voltage. I can't recall what is appropriate for n900, but 2.6.28-nokia sources might give you the answer. No need to go that far. N900 has been supported in mainline since 2.6.39 or so. Part A of AIC34 (which is basically dual AIC33 in a same package) drives 2 V for the digital microphone bias and part B 2.5 V for the headset. Unfortunately I haven't had time recently to try what might have caused that regression after 3.18. -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/7] extcon: usb-gpio: Introduce gpio usb extcon driver
This driver observes the USB ID pin connected over a GPIO and
updates the USB cable extcon states accordingly.
The existing GPIO extcon driver is not suitable for this purpose
as it needs to be taught to understand USB cable states and it
can't handle more than one cable per instance.
For the USB case we need to handle 2 cable states.
1) USB (attach/detach)
2) USB-Host (attach/detach)
This driver can be easily updated in the future to handle VBUS
events in case it happens to be available on GPIO for any platform.
Signed-off-by: Roger Quadros rog...@ti.com
---
v3:
- removed IRQF_NO_SUSPEND flag. Added IRQF_TRIGGER_RISING and
IRQF_TRIGGER_FALLING
- Added disable_irq() to suspend() and enable_irq() to resume()
.../devicetree/bindings/extcon/extcon-usb-gpio.txt | 18 ++
drivers/extcon/Kconfig | 7 +
drivers/extcon/Makefile| 1 +
drivers/extcon/extcon-usb-gpio.c | 233 +
4 files changed, 259 insertions(+)
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
create mode 100644 drivers/extcon/extcon-usb-gpio.c
diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
new file mode 100644
index 000..85fe6b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
@@ -0,0 +1,18 @@
+USB GPIO Extcon device
+
+This is a virtual device used to generate USB cable states from the USB ID pin
+connected to a GPIO pin.
+
+Required properties:
+- compatible: Should be linux,extcon-usb-gpio
+- id-gpio: gpio for USB ID pin. See gpio binding.
+
+Example:
+ extcon_usb1 {
+ compatible = linux,extcon-usb-gpio;
+ id-gpio = gpio6 1 GPIO_ACTIVE_HIGH;
+ }
+
+ omap_dwc3_1 {
+ extcon = extcon_usb1;
+ };
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index 6a1f7de..fd11536 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -93,4 +93,11 @@ config EXTCON_SM5502
Silicon Mitus SM5502. The SM5502 is a USB port accessory
detector and switch.
+config EXTCON_USB_GPIO
+ tristate USB GPIO extcon support
+ select GPIOLIB
+ help
+ Say Y here to enable GPIO based USB cable detection extcon support.
+ Used typically if GPIO is used for USB ID pin detection.
+
endif # MULTISTATE_SWITCH
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 0370b42..6a08a98 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
obj-$(CONFIG_EXTCON_PALMAS)+= extcon-palmas.o
obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
obj-$(CONFIG_EXTCON_SM5502)+= extcon-sm5502.o
+obj-$(CONFIG_EXTCON_USB_GPIO) += extcon-usb-gpio.o
diff --git a/drivers/extcon/extcon-usb-gpio.c b/drivers/extcon/extcon-usb-gpio.c
new file mode 100644
index 000..99a58b2
--- /dev/null
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -0,0 +1,233 @@
+/**
+ * drivers/extcon/extcon-usb-gpio.c - USB GPIO extcon driver
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Roger Quadros rog...@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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/extcon.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_gpio.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/workqueue.h
+
+#define USB_GPIO_DEBOUNCE_MS 20 /* ms */
+
+struct usb_extcon_info {
+ struct device *dev;
+ struct extcon_dev *edev;
+
+ struct gpio_desc *id_gpiod;
+ int id_irq;
+ bool id_irqwake;/* ID wakeup enabled flag */
+
+ unsigned long debounce_jiffies;
+ struct delayed_work wq_detcable;
+};
+
+/* List of detectable cables */
+enum {
+ EXTCON_CABLE_USB = 0,
+ EXTCON_CABLE_USB_HOST,
+
+ EXTCON_CABLE_END,
+};
+
+static const char *usb_extcon_cable[] = {
+ [EXTCON_CABLE_USB] = USB,
+ [EXTCON_CABLE_USB_HOST] = USB-Host,
+ NULL,
+};
+
+static void usb_extcon_detect_cable(struct work_struct *work)
+{
+ int id;
+ struct usb_extcon_info *info = container_of(to_delayed_work(work),
+ struct usb_extcon_info,
+ wq_detcable);
+
+ /* check ID and update cable state */
+ id =
Re: 3.19 on Nokia n900: audio quality awful
On Wed 2015-01-28 20:15:46, Jarkko Nikula wrote:
On 01/26/2015 03:20 PM, Peter Ujfalusi wrote:
On 01/18/2015 02:01 PM, Pavel Machek wrote:
In 2.6.28-nokia, it is neccessary to set Input select na digital
mic, then it works. Input select being in playback option makes it
easy to miss.
In 3.18 and 3.19-rc3, all I can record are zeros.
Does playback/recording work for you on OMAP 3430-based machines?
Same codec (tlv320aic3106) works fine on my am335x and omap-l138 boards.
BeagleBoard-xM also fine with twl4030 codec.
I don't have my n900 in hacking mode (it is still in use time-to-time) but
looking at the dts file: you might want to add ai3x-micbias-vg property to
the
aic3x nodes to select the correct mic bias voltage. I can't recall what is
appropriate for n900, but 2.6.28-nokia sources might give you the answer.
No need to go that far. N900 has been supported in mainline since 2.6.39
or so. Part A of AIC34 (which is basically dual AIC33 in a same package)
drives 2 V for the digital microphone bias and part B 2.5 V for the headset.
Let me try... Umm, no change here :-(
root@n900:/tmp# arecord delme
Recording WAVE 'delme' : Unsigned 8 bit, Rate 8000 Hz, Mono
^CAborted by signal Interrupt...
root@n900:/tmp# hexdump delme
000 4952 4646 987c 4157 4556 6d66 2074
010 0010 0001 0001 1f40 1f40
020 0001 0008 6164 6174 9858 8080 8080
030 8080 8080 8080 8080 8080 8080 8080 8080
*
0009880
root@n900:/tmp# aplay delme
Playing WAVE 'delme' : Unsigned 8 bit, Rate 8000 Hz, Mono
root@n900:/tmp#
I did this:
I'm not sure which one is main microphone and which is headset, but
I guess 2V should be close enough to 2.5V to produce something
different from zeros..?
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 48b0987..f18a5b0 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -491,6 +491,8 @@
DRVDD-supply = vmmc2;
IOVDD-supply = vio;
DVDD-supply = vio;
+
+ ai3x-micbias-vg = 1;
};
tlv320aic3x_aux: tlv320aic3x@19 {
@@ -502,6 +504,8 @@
DRVDD-supply = vmmc2;
IOVDD-supply = vio;
DVDD-supply = vio;
+
+ ai3x-micbias-vg = 1;
};
tsl2563: tsl2563@29 {
Unfortunately I haven't had time recently to try what might have caused
that regression after 3.18.
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
[PATCH] clk: ti: Fix FAPLL parent enable bit handling
Commit 163152cbbe32 (clk: ti: Add support for FAPLL on dm816x) added basic support for the FAPLL on dm818x, but has a bug for the parent PLL enable bit. The FAPLL_MAIN_PLLEN is defined as BIT(3) but the code is doing a shift on it. This means the parent PLL won't get disabled even if all it's child synthesizers are disabled. Reported-by: Dan Carpenter dan.carpen...@oracle.com Cc: Brian Hutchinson b.hutch...@gmail.com Signed-off-by: Tony Lindgren t...@atomide.com --- a/drivers/clk/ti/fapll.c +++ b/drivers/clk/ti/fapll.c @@ -84,7 +84,7 @@ static int ti_fapll_enable(struct clk_hw *hw) struct fapll_data *fd = to_fapll(hw); u32 v = readl_relaxed(fd-base); - v |= (1 FAPLL_MAIN_PLLEN); + v |= FAPLL_MAIN_PLLEN; writel_relaxed(v, fd-base); return 0; @@ -95,7 +95,7 @@ static void ti_fapll_disable(struct clk_hw *hw) struct fapll_data *fd = to_fapll(hw); u32 v = readl_relaxed(fd-base); - v = ~(1 FAPLL_MAIN_PLLEN); + v = ~FAPLL_MAIN_PLLEN; writel_relaxed(v, fd-base); } @@ -104,7 +104,7 @@ static int ti_fapll_is_enabled(struct clk_hw *hw) struct fapll_data *fd = to_fapll(hw); u32 v = readl_relaxed(fd-base); - return v (1 FAPLL_MAIN_PLLEN); + return v FAPLL_MAIN_PLLEN; } static unsigned long ti_fapll_recalc_rate(struct clk_hw *hw, -- 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/3] net: cpsw: Add a minimal cpsw-common module for shared code
Looks like davinci_emac and cpsw can share some code although the
device registers have a different layout.
At least the code for getting the MAC address using syscon can
be shared by passing the register offset. Let's start with that
and set up a minimal shared cpsw-shared.c.
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/net/ethernet/ti/Makefile | 3 ++
drivers/net/ethernet/ti/cpsw-common.c | 53 +++
drivers/net/ethernet/ti/cpsw.c| 35 ++-
drivers/net/ethernet/ti/cpsw.h| 2 ++
4 files changed, 60 insertions(+), 33 deletions(-)
create mode 100644 drivers/net/ethernet/ti/cpsw-common.c
diff --git a/drivers/net/ethernet/ti/Makefile b/drivers/net/ethernet/ti/Makefile
index 465d03d..7fa47f6 100644
--- a/drivers/net/ethernet/ti/Makefile
+++ b/drivers/net/ethernet/ti/Makefile
@@ -2,6 +2,9 @@
# Makefile for the TI network device drivers.
#
+obj-$(CONFIG_TI_CPSW) += cpsw-common.o
+obj-$(CONFIG_TI_DAVINCI_EMAC) += cpsw-common.o
+
obj-$(CONFIG_TLAN) += tlan.o
obj-$(CONFIG_CPMAC) += cpmac.o
obj-$(CONFIG_TI_DAVINCI_EMAC) += davinci_emac.o
diff --git a/drivers/net/ethernet/ti/cpsw-common.c
b/drivers/net/ethernet/ti/cpsw-common.c
new file mode 100644
index 000..763ada1
--- /dev/null
+++ b/drivers/net/ethernet/ti/cpsw-common.c
@@ -0,0 +1,53 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/regmap.h
+#include linux/mfd/syscon.h
+
+#define AM33XX_CTRL_MAC_LO_REG(offset, id) ((offset) + 0x8 * (id))
+#define AM33XX_CTRL_MAC_HI_REG(offset, id) ((offset) + 0x8 * (id) + 0x4)
+
+int cpsw_am33xx_cm_get_macid(struct device *dev, u16 offset, int slave,
+u8 *mac_addr)
+{
+ u32 macid_lo;
+ u32 macid_hi;
+ struct regmap *syscon;
+
+ syscon = syscon_regmap_lookup_by_phandle(dev-of_node, syscon);
+ if (IS_ERR(syscon)) {
+ if (PTR_ERR(syscon) == -ENODEV)
+ return 0;
+ return PTR_ERR(syscon);
+ }
+
+ regmap_read(syscon, AM33XX_CTRL_MAC_LO_REG(offset, slave),
+ macid_lo);
+ regmap_read(syscon, AM33XX_CTRL_MAC_HI_REG(offset, slave),
+ macid_hi);
+
+ mac_addr[5] = (macid_lo 8) 0xff;
+ mac_addr[4] = macid_lo 0xff;
+ mac_addr[3] = (macid_hi 24) 0xff;
+ mac_addr[2] = (macid_hi 16) 0xff;
+ mac_addr[1] = (macid_hi 8) 0xff;
+ mac_addr[0] = macid_hi 0xff;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(cpsw_am33xx_cm_get_macid);
+
+MODULE_LICENSE(GPL);
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 2b9d404..7d8dd0d 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -33,8 +33,6 @@
#include linux/of_net.h
#include linux/of_device.h
#include linux/if_vlan.h
-#include linux/mfd/syscon.h
-#include linux/regmap.h
#include linux/pinctrl/consumer.h
@@ -1936,36 +1934,6 @@ static void cpsw_slave_init(struct cpsw_slave *slave,
struct cpsw_priv *priv,
slave-port_vlan = data-dual_emac_res_vlan;
}
-#define AM33XX_CTRL_MAC_LO_REG(id) (0x630 + 0x8 * id)
-#define AM33XX_CTRL_MAC_HI_REG(id) (0x630 + 0x8 * id + 0x4)
-
-static int cpsw_am33xx_cm_get_macid(struct device *dev, int slave,
- u8 *mac_addr)
-{
- u32 macid_lo;
- u32 macid_hi;
- struct regmap *syscon;
-
- syscon = syscon_regmap_lookup_by_phandle(dev-of_node, syscon);
- if (IS_ERR(syscon)) {
- if (PTR_ERR(syscon) == -ENODEV)
- return 0;
- return PTR_ERR(syscon);
- }
-
- regmap_read(syscon, AM33XX_CTRL_MAC_LO_REG(slave), macid_lo);
- regmap_read(syscon, AM33XX_CTRL_MAC_HI_REG(slave), macid_hi);
-
- mac_addr[5] = (macid_lo 8) 0xff;
- mac_addr[4] = macid_lo 0xff;
- mac_addr[3] = (macid_hi 24) 0xff;
- mac_addr[2] = (macid_hi 16) 0xff;
- mac_addr[1] = (macid_hi 8) 0xff;
- mac_addr[0] = macid_hi 0xff;
-
- return 0;
-}
-
static int cpsw_probe_dt(struct cpsw_platform_data *data,
struct platform_device *pdev)
{
@@ -2090,7 +2058,8 @@ no_phy_slave:
memcpy(slave_data-mac_addr, mac_addr, ETH_ALEN);
} else {
if
Re: [PATCH v2] ARM: AM43xx: hwmod: add VPFE hwmod entries
Paul Walmsley p...@pwsan.com wrote on Mon [2015-Jan-26 18:47:11 +]:
Hi Prabhakar,
On Mon, 26 Jan 2015, Lad, Prabhakar wrote:
Hi Benoit,
On Mon, Jan 26, 2015 at 3:50 PM, Benoit Parrot bpar...@ti.com wrote:
Lad, Prabhakar prabhakar.cse...@gmail.com wrote on Mon [2015-Jan-26
08:13:01 +]:
Hi Paul,
Thanks for the review.
On Mon, Jan 26, 2015 at 2:15 AM, Paul Walmsley p...@pwsan.com wrote:
Hi
On Sun, 25 Jan 2015, Lad, Prabhakar wrote:
From: Benoit Parrot bpar...@ti.com
this patch adds VPFE HWMOD data for AM43xx.
Signed-off-by: Benoit Parrot bpar...@ti.com
Signed-off-by: Darren Etheridge detheri...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
Hi Paul,
You were right, the hardware team has confirmed that, the VPFE
master port is
connected to L3 and the VPFE slave port is connected to L4. The L3
port cannot
serve as a register target because it is initiator only.
OK makes sense to me.,
I have created links referring to dss l3/l4 hwmod and tested it,
lemme know
if I have missed something.
A few minor comments below
[Snip]
/* Interfaces */
static struct omap_hwmod_ocp_if am43xx_l3_main__l4_hs = {
.master = am33xx_l3_main_hwmod,
@@ -788,6 +826,36 @@ static struct omap_hwmod_ocp_if
am43xx_l4_ls__dss_rfbi = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if am43xx_l3__vpfe0 = {
+ .master = am43xx_vpfe0_hwmod,
+ .slave = am33xx_l3_main_hwmod,
+ .clk= l3_gclk,
+ .flags = OCPIF_SWSUP_IDLE,
OCPIF_SWSUP_IDLE probably isn't needed here. Could you please try
without
it?
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l3__vpfe1 = {
+ .master = am43xx_vpfe1_hwmod,
+ .slave = am33xx_l3_main_hwmod,
+ .clk= l3_gclk,
+ .flags = OCPIF_SWSUP_IDLE,
Same point as the above.
Dropped and tested works! posting a v3.
When you tested it without the OCPIF_SWSUP_IDLE, did you go trhough a
complete suspend/resume cycle?
This flag was added early on because otherwise the susbsytem would not go
idle without it...
Can you post the console output during a suspend/resume cycle?
Ah I didn’t test the suspend/resume will do and post the console log.
Could you also do a suspend/resume test on v2?
Prabbhakar,
I tested both v2 and v3 and both successfully went through a suspend/resume
cycle.
So I guess v3 is fine, sorry for the noise.
I'll add a tested-by on V3.
Benoit
thanks
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: AM43xx: hwmod: add VPFE hwmod entries
Hi Benoit, On Wed, Jan 28, 2015 at 7:32 PM, Benoit Parrot bpar...@ti.com wrote: Suspend/resume is functional with this patch. Tested-by: Benoit Parrot bpar...@ti.com Thanks for the test, I was facing issues with loading the pm firmware. Cheers, --Prabhakar Lad -- 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 v7 1/4] Documentation: dt: add common bindings for hwspinlock
On 01/22/2015 12:56 PM, Mark Rutland wrote:
On Wed, Jan 21, 2015 at 05:56:37PM +, Suman Anna wrote:
On 01/21/2015 06:41 AM, Ohad Ben-Cohen wrote:
On Tue, Jan 20, 2015 at 8:05 PM, Tony Lindgren t...@atomide.com wrote:
How about default to Linux id space and allow overriding that with
a module param option if needed?
I'm not sure I'm following.
If the main point of contention is the base_id field, I'm also fine
with removing it entirely, as I'm not aware of any actual user for it
(Suman please confirm?).
Yeah, well the current implementations that I am aware of only have a
single bank, so all of them would be using a value of 0. I am yet to see
a platform with multiple instances where the property really makes a
difference. v7 has the property mandatory, so all the implementations
would need to define this value even if it is 0.
regards
Suman
Mark? Rob? Will you accept Suman's patches if the base_id field is removed?
My concern is that the mapping of hwspinlock IDs doesn't seem to be
explicit in the DT on a per-context basis, which is what I'd expect.
e.g.
lck: hwspinlock-device@f00 {
...
#hwlock-cells = 1;
};
some-other-os-interface {
...
hwlocks = lck 0, lck 1, lck 2, lck 3;
hwlock-names = glbl, pool0, pool1, pool2;
};
a-different-os-interface {
...
hwlocks = lck 18, lck 21, lck 4, lck 5;
hwlock-names = init, teardown, pool0, pool1;
};
That's the only way I would expect this to possibly remain a stable
over time, and it's the entire reason for #hwlock-cells, no?
How do you expect the other components sharing the hwspinlocks to be
described?
Yes indeed, this is what any of the clients will use on Linux. But this is not
necessarily the semantics for exchanging hwlocks with the other processor(s)
which is where the global id space comes into picture.
regards
Suman
--
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: 3.19 on Nokia n900: audio quality awful
On Mon 2015-01-26 15:20:28, Peter Ujfalusi wrote: On 01/18/2015 02:01 PM, Pavel Machek wrote: Hi! If you have any idea about playback problems, help would be still welcome. I'll have to do bisect, otherwise, and it will not be easy. In 3.18, sound is nice and clear. In 3.19, sound is unusable. It produces nasty tone when it should be quiet, and there's at least as much noise as is sound. Unfortunately, list of mixers also changed (and there's cca 120 settings), but a) it does not work with the old list and b) nothing I could figure out did make the sound usable. Some setting resulted in even more noise. Any idea what could have caused it? I tried audio recording this time. In 2.6.28-nokia, it is neccessary to set Input select na digital mic, then it works. Input select being in playback option makes it easy to miss. In 3.18 and 3.19-rc3, all I can record are zeros. Does playback/recording work for you on OMAP 3430-based machines? Same codec (tlv320aic3106) works fine on my am335x and omap-l138 boards. BeagleBoard-xM also fine with twl4030 codec. I don't have my n900 in hacking mode (it is still in use time-to-time) but Actually, with nfsroot / loading kernel using NOLO, it is not neccessary to break your n900. It is possible to boot complete userspace without changing single bit of flash. looking at the dts file: you might want to add ai3x-micbias-vg property to the aic3x nodes to select the correct mic bias voltage. I can't recall what is appropriate for n900, but 2.6.28-nokia sources might give you the answer. Ok, thanks, let me try... 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 4/4] ARM: dts: Add minimal support for dm8168-evm
On 26 January 2015 at 16:58, Tony Lindgren t...@atomide.com wrote: See earlier I was assuming copy paste issues from dm814x to dm816x Ahh, you thought the 816x was 814x-derived... yes I can imagine that will have led to some confusion. I'm pretty sure I verified the that the audio_pll_clk1 is hardwwired to 32KiHz by looking at it with a scope on the clkout pin. Yeah it comes straight from the rtcdivider so it'll produce 0.0016384 * devosc. The global clock structure overview in the TRM (figure 2-6) actually correctly marks the former-audio-fapll clocks (except audio5 := osc0, yielding sysclk22 after divider) but you already need to know what the hell is going on to recognize that. Oh, on the topic of PRCM, a word of caution: while the cold reset default of PM_DEFAULT_PWRSTCTRL is 0, performing _any_ write to it (regardless of value) sets it to 3 (force power-on) until next cold reset. An unfortunately side-effect I stumbled over is that a particular bus lockup that can occur in ducati (dual cortex-m3 subsystem) then becomes warm-reset-insensitive. The statement I got from TI support about the strange behaviour of this power control register was.. vague: In DM814x, complete functionality of PRCM was not used and that resulted into such requirements. This recommendations was made based on DV test cases with POWERONSTATE == ON/0x3. We didn’t do any negative testing to see the behaviour in case POWERONSTATE != ON/0x3. So I can recommend you to test your system without this requirement and see if you will have any issues. I think this requirement is not needed (POWERONSTATE == ON/0x3), as the DM814x EZSDK (u-boot, linux kernel) is working fine without it. The inventory of SecSS on Netra yielded exactly the same list of accelerators and other peripherals as on Centaurus btw. The only changes seem to be in subsystem control stuff. What are you using to identify the devices? The device revision register? Or are there actually some populated interconnect data available with device info that could be used for a real scannable bus? You mean the modules? SecSS unfortunately doesn't have an integrated memory map like the one present in the Sonics S3220 interconnects, so I just probed it manually while making use of the knowledge I already had of SecSS on Centaurus. It helps that I already did quite a bit of exploration of SecSS on Centaurus, and it turns out to barely differ from the original one* on Netra. The differences seem to be permissions-related: the subsystem control module was split into two separate parts and there was a tiny bit of rearrangement for the benefit of being able to cover multiple modules with a single firewall region. I've updated the SecSS sheet of my memory-map spreadsheet to highlight the differences. It's not totally clear what the intentions are of the various default firewall regions. Region 0 will undoubtedly be highly restricted on all but GP devices. On centaurus region 5 looks like it'll be exclusively for the cortex-m3 on devices where it automatically boots stand-alone from ROM (EMU/HS) instead of waiting to boot into user-supplied code on request (Test/GP/EMUL/HSL). *TI's linux driver calls it NSS (Netra Security Subsystem) on both chips, so presumably Netra was the first to have this kind of subsystem. -- 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/3] net: davinci_emac: Get device dm816x MAC address using the cpsw code
At least on dm81xx, we can get the davinci_emac MAC address the same
way as on am33xx cpsw.
Let's also use ether_addr_copy() for davinci_emac while at it.
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/net/ethernet/ti/davinci_emac.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c
b/drivers/net/ethernet/ti/davinci_emac.c
index 5fae435..a716938 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -69,6 +69,7 @@
#include asm/irq.h
#include asm/page.h
+#include cpsw.h
#include davinci_cpdma.h
static int debug_level;
@@ -1838,7 +1839,7 @@ davinci_emac_of_get_pdata(struct platform_device *pdev,
struct emac_priv *priv)
if (!is_valid_ether_addr(pdata-mac_addr)) {
mac_addr = of_get_mac_address(np);
if (mac_addr)
- memcpy(pdata-mac_addr, mac_addr, ETH_ALEN);
+ ether_addr_copy(pdata-mac_addr, mac_addr);
}
of_property_read_u32(np, ti,davinci-ctrl-reg-offset,
@@ -1879,6 +1880,22 @@ davinci_emac_of_get_pdata(struct platform_device *pdev,
struct emac_priv *priv)
return pdata;
}
+static int davinci_emac_try_get_mac(struct platform_device *pdev,
+ int instance, u8 *mac_addr)
+{
+ int error = -EINVAL;
+
+ if (!pdev-dev.of_node)
+ return error;
+
+ if (of_device_is_compatible(pdev-dev.of_node, ti,dm816-emac))
+ error = cpsw_am33xx_cm_get_macid(pdev-dev, 0x30,
+instance,
+mac_addr);
+
+ return error;
+}
+
/**
* davinci_emac_probe - EMAC device probe
* @pdev: The DaVinci EMAC device that we are removing
@@ -2009,6 +2026,10 @@ static int davinci_emac_probe(struct platform_device
*pdev)
}
ndev-irq = res-start;
+ rc = davinci_emac_try_get_mac(pdev, res_ctrl ? 0 : 1, priv-mac_addr);
+ if (!rc)
+ ether_addr_copy(ndev-dev_addr, priv-mac_addr);
+
if (!is_valid_ether_addr(priv-mac_addr)) {
/* Use random MAC if none passed */
eth_hw_addr_random(ndev);
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] net: davinci_emac: Get device MAC on 3517
Looks like on 3517 davinci_emac MAC address registers have a
different layout compared to dm816x and am33xx.
Let's add a function to get the 3517 MAC address.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/am3517.dtsi | 1 +
drivers/net/ethernet/ti/davinci_emac.c | 35 +-
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am3517.dtsi b/arch/arm/boot/dts/am3517.dtsi
index 5a452fd..c90724b 100644
--- a/arch/arm/boot/dts/am3517.dtsi
+++ b/arch/arm/boot/dts/am3517.dtsi
@@ -31,6 +31,7 @@
status = disabled;
reg = 0x5c00 0x3;
interrupts = 67 68 69 70;
+ syscon = omap3_scm_general;
ti,davinci-ctrl-reg-offset = 0x1;
ti,davinci-ctrl-mod-reg-offset = 0;
ti,davinci-ctrl-ram-offset = 0x2;
diff --git a/drivers/net/ethernet/ti/davinci_emac.c
b/drivers/net/ethernet/ti/davinci_emac.c
index a716938..aeebc0a 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -52,6 +52,7 @@
#include linux/dma-mapping.h
#include linux/clk.h
#include linux/platform_device.h
+#include linux/regmap.h
#include linux/semaphore.h
#include linux/phy.h
#include linux/bitops.h
@@ -65,6 +66,7 @@
#include linux/of_mdio.h
#include linux/of_irq.h
#include linux/of_net.h
+#include linux/mfd/syscon.h
#include asm/irq.h
#include asm/page.h
@@ -1880,6 +1882,33 @@ davinci_emac_of_get_pdata(struct platform_device *pdev,
struct emac_priv *priv)
return pdata;
}
+static int davinci_emac_3517_get_macid(struct device *dev, u16 offset,
+ int slave, u8 *mac_addr)
+{
+ u32 macid_lsb;
+ u32 macid_msb;
+ struct regmap *syscon;
+
+ syscon = syscon_regmap_lookup_by_phandle(dev-of_node, syscon);
+ if (IS_ERR(syscon)) {
+ if (PTR_ERR(syscon) == -ENODEV)
+ return 0;
+ return PTR_ERR(syscon);
+ }
+
+ regmap_read(syscon, offset, macid_lsb);
+ regmap_read(syscon, offset + 4, macid_msb);
+
+ mac_addr[0] = (macid_msb 16) 0xff;
+ mac_addr[1] = (macid_msb 8) 0xff;
+ mac_addr[2] = macid_msb 0xff;
+ mac_addr[3] = (macid_lsb 16) 0xff;
+ mac_addr[4] = (macid_lsb 8) 0xff;
+ mac_addr[5] = macid_lsb 0xff;
+
+ return 0;
+}
+
static int davinci_emac_try_get_mac(struct platform_device *pdev,
int instance, u8 *mac_addr)
{
@@ -1888,7 +1917,11 @@ static int davinci_emac_try_get_mac(struct
platform_device *pdev,
if (!pdev-dev.of_node)
return error;
- if (of_device_is_compatible(pdev-dev.of_node, ti,dm816-emac))
+ if (of_device_is_compatible(pdev-dev.of_node, ti,am3517-emac))
+ error = davinci_emac_3517_get_macid(pdev-dev, 0x110,
+ 0, mac_addr);
+ else if (of_device_is_compatible(pdev-dev.of_node,
+ti,dm816-emac))
error = cpsw_am33xx_cm_get_macid(pdev-dev, 0x30,
instance,
mac_addr);
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/7] extcon: usb-gpio: Introduce gpio usb extcon driver
Hi Roger,
We need to discuss one point about 'id_irqwake'.
I don't recommend to use 'id_irqwake' field.
And I catch build warning by using select keywork in Kconfig.
It is my wrong guide of select keyword. So, I'll change it
as 'depends on' keyword.
Looks good to me except for 'id_irqwake'.
I'll apply this patch on 3.21 queue after completing this discussion.
On 01/28/2015 09:15 PM, Roger Quadros wrote:
This driver observes the USB ID pin connected over a GPIO and
updates the USB cable extcon states accordingly.
The existing GPIO extcon driver is not suitable for this purpose
as it needs to be taught to understand USB cable states and it
can't handle more than one cable per instance.
For the USB case we need to handle 2 cable states.
1) USB (attach/detach)
2) USB-Host (attach/detach)
This driver can be easily updated in the future to handle VBUS
events in case it happens to be available on GPIO for any platform.
Signed-off-by: Roger Quadros rog...@ti.com
---
v3:
- removed IRQF_NO_SUSPEND flag. Added IRQF_TRIGGER_RISING and
IRQF_TRIGGER_FALLING
- Added disable_irq() to suspend() and enable_irq() to resume()
.../devicetree/bindings/extcon/extcon-usb-gpio.txt | 18 ++
drivers/extcon/Kconfig | 7 +
drivers/extcon/Makefile| 1 +
drivers/extcon/extcon-usb-gpio.c | 233
+
4 files changed, 259 insertions(+)
create mode 100644
Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
create mode 100644 drivers/extcon/extcon-usb-gpio.c
diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
new file mode 100644
index 000..85fe6b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
@@ -0,0 +1,18 @@
+USB GPIO Extcon device
+
+This is a virtual device used to generate USB cable states from the USB ID
pin
+connected to a GPIO pin.
+
+Required properties:
+- compatible: Should be linux,extcon-usb-gpio
+- id-gpio: gpio for USB ID pin. See gpio binding.
+
+Example:
+ extcon_usb1 {
+ compatible = linux,extcon-usb-gpio;
+ id-gpio = gpio6 1 GPIO_ACTIVE_HIGH;
+ }
+
+ omap_dwc3_1 {
+ extcon = extcon_usb1;
+ };
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index 6a1f7de..fd11536 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -93,4 +93,11 @@ config EXTCON_SM5502
Silicon Mitus SM5502. The SM5502 is a USB port accessory
detector and switch.
+config EXTCON_USB_GPIO
+ tristate USB GPIO extcon support
+ select GPIOLIB
I catch the build warning if using 'select' instead of 'depends on' as
following:
It is my wrong guide to you. So, I'll modify it by using depends on as your
original patch.
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- zImage -j 8
scripts/kconfig/conf --silentoldconfig Kconfig
drivers/gpio/Kconfig:34:error: recursive dependency detected!
drivers/gpio/Kconfig:34:symbol GPIOLIB is selected by EXTCON_USB_GPIO
drivers/extcon/Kconfig:96: symbol EXTCON_USB_GPIO depends on EXTCON
drivers/extcon/Kconfig:1: symbol EXTCON is selected by CHARGER_MANAGER
drivers/power/Kconfig:316: symbol CHARGER_MANAGER depends on POWER_SUPPLY
drivers/power/Kconfig:1:symbol POWER_SUPPLY is selected by HID_SONY
drivers/hid/Kconfig:670:symbol HID_SONY depends on NEW_LEDS
drivers/leds/Kconfig:8: symbol NEW_LEDS is selected by BCMA_DRIVER_GPIO
drivers/bcma/Kconfig:75:symbol BCMA_DRIVER_GPIO depends on GPIOLIB
+ help
+ Say Y here to enable GPIO based USB cable detection extcon support.
+ Used typically if GPIO is used for USB ID pin detection.
+
endif # MULTISTATE_SWITCH
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 0370b42..6a08a98 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997)+= extcon-max8997.o
obj-$(CONFIG_EXTCON_PALMAS) += extcon-palmas.o
obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
obj-$(CONFIG_EXTCON_SM5502) += extcon-sm5502.o
+obj-$(CONFIG_EXTCON_USB_GPIO)+= extcon-usb-gpio.o
diff --git a/drivers/extcon/extcon-usb-gpio.c
b/drivers/extcon/extcon-usb-gpio.c
new file mode 100644
index 000..99a58b2
--- /dev/null
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -0,0 +1,233 @@
+/**
+ * drivers/extcon/extcon-usb-gpio.c - USB GPIO extcon driver
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Roger Quadros rog...@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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ *
Supporting two SMSC9221 interfaces on GPMC in a dts
Hi, The Gumstix Tobi-Duo board has two SMSC9221 NICs attached to the GPMC interface of an OMAP3. I'm trying to figure out how best to include both interfaces in the device tree file. With just one interface, I can #include omap-gpmc-smsc9221.dtsi, add the extra board specific settings in to ethernet@gpmc in the board file as well as any settings needed for the gpmc. For two interfaces though, I can setup the gpmc details, configure one ethernet@gpmc node as before but then, need to manually create (i.e. copy the meat from the omap-gpmc-smsc9221.dtsi) a second node. This works but seems, well, verbose. Is there a way to setup multiple interfaces without having to duplicate the omap-gpmc-smsc9221.dtsi content? Any hints much appreciated! Thanks, --Ash -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mmc: omap_hsmmc: switch to 1-bit before turning off clocks if interrupts expected.
On Wed, 28 Jan 2015 21:18:40 +0100 Ulf Hansson ulf.hans...@linaro.org wrote:
On 28 January 2015 at 00:35, NeilBrown ne...@suse.de wrote:
According to section 7.1.2 of
http://www.sandisk.com/media/File/OEM/Manuals/SD_SDIO_specsv1.pdf
In the case where the interrupt mechanism is used to wake the host while
the card is in a low power state (i.e. no clocks), Both the card and the
host shall be placed into the 1-bit SD mode prior to stopping the clock.
This is particularly important for the Marvell libertas wifi chip
in the GTA04. While in 4-bit mode it will only signal an interrupt
when the clock is running (which is why setting CLKEXTFREE is
important).
In 1-bit mode, the interrupt is asynchronous (explained in OMAP3
TRM description of the CIRQ flag to MMCHS_STAT:
In 1-bit mode, interrupt source is asynchronous (can be a source of
asynchronous wakeup).
In 4-bit mode, interrupt source is sampled during the interrupt
cycle.
)
We cannot simply set 1-bit mode in omap_hsmmc_runtime_suspend
as that is called under a spinlock, and setting 1-bit mode requires
a sleeping call to the card.
So:
- use a work_struct to schedule setting of 1-bit mode
- intro a 'force_narrow' state flag which transitions:
0 - NARROW_PENDING - NARROW_FORCED - 0
- have omap_hsmmc_runtime_suspend fail if interrupts are expected
but bus is not in 1-bit mode. When it fails it schedules
the work to change the width. and sets NARROW_PENDING
- when the host is claimed, if NARROW_FORCED is set, restore the
4-bit bus
- When the host is released (disable_fclk), if NARROW_FORCED,
then suspend immediately, no autosuspend. If NARROW_PENDING,
clear that flag as the device has obviously just been used.
I can't give you more detailed comment about this patch(set) yet. Need
to think a bit more first.
Anyway, I have one concern, see comment below.
This all allows a graceful and race-free switch to 1-bit mode
before switching off the clocks, if interrupts are enabled.
With this, I can use my libertas wifi with a 4-bit bus, with
interrupts and runtime power-management enabled, and get around
14Mb/sec throughput (which is the best I've seen).
Signed-off-by: NeilBrown n...@brown.name
---
drivers/mmc/host/omap_hsmmc.c | 55
-
1 file changed, 53 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index f84cfb01716d..91ddebbec8a3 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -214,6 +214,10 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+ int force_narrow;
+#define NARROW_PENDING 1
+#define NARROW_FORCED 2
+ struct work_struct width_work;
unsigned long clk_rate;
unsigned intflags;
#define AUTO_CMD23 (1 0)/* Auto CMD23 support */
@@ -1778,12 +1782,43 @@ static void omap_hsmmc_conf_bus_power(struct
omap_hsmmc_host *host)
set_sd_bus_power(host);
}
+static void omap_hsmmc_width_work(struct work_struct *work)
+{
+ struct omap_hsmmc_host *host = container_of(work,
+ struct omap_hsmmc_host,
+ width_work);
+ atomic_t noblock;
+
+ atomic_set(noblock, 1);
+ if (__mmc_claim_host(host-mmc, noblock)) {
+ /* Device active again */
+ host-force_narrow = 0;
+ return;
+ }
+ if (host-force_narrow != NARROW_PENDING) {
+ /* Someone claimed and released before we got here */
+ mmc_release_host(host-mmc);
+ return;
+ }
+ if (sdio_disable_wide(host-mmc-card) == 0)
+ host-force_narrow = NARROW_FORCED;
+ else
+ host-force_narrow = 0;
+ mmc_release_host(host-mmc);
+}
+
static int omap_hsmmc_enable_fclk(struct mmc_host *mmc)
{
struct omap_hsmmc_host *host = mmc_priv(mmc);
pm_runtime_get_sync(host-dev);
+ if (host-force_narrow == NARROW_FORCED) {
+ if (sdio_enable_4bit_bus(mmc-card) 0)
+ mmc_set_bus_width(mmc, MMC_BUS_WIDTH_4);
+ host-force_narrow = 0;
+ }
+
return 0;
}
@@ -1791,8 +1826,13 @@ static int omap_hsmmc_disable_fclk(struct mmc_host
*mmc)
{
struct omap_hsmmc_host *host = mmc_priv(mmc);
- pm_runtime_mark_last_busy(host-dev);
- pm_runtime_put_autosuspend(host-dev);
+ if (host-force_narrow == NARROW_FORCED) {
+ pm_runtime_put_sync(host-dev);
Re: 3.19 on Nokia n900: audio quality awful
On Wed, Jan 28, 2015 at 11:41:44PM +0100, Pavel Machek wrote:
On Wed 2015-01-28 20:15:46, Jarkko Nikula wrote:
On 01/26/2015 03:20 PM, Peter Ujfalusi wrote:
On 01/18/2015 02:01 PM, Pavel Machek wrote:
No need to go that far. N900 has been supported in mainline since 2.6.39
or so. Part A of AIC34 (which is basically dual AIC33 in a same package)
drives 2 V for the digital microphone bias and part B 2.5 V for the headset.
Let me try... Umm, no change here :-(
root@n900:/tmp# arecord delme
Recording WAVE 'delme' : Unsigned 8 bit, Rate 8000 Hz, Mono
^CAborted by signal Interrupt...
root@n900:/tmp# hexdump delme
000 4952 4646 987c 4157 4556 6d66 2074
010 0010 0001 0001 1f40 1f40
020 0001 0008 6164 6174 9858 8080 8080
030 8080 8080 8080 8080 8080 8080 8080 8080
*
0009880
root@n900:/tmp# aplay delme
Playing WAVE 'delme' : Unsigned 8 bit, Rate 8000 Hz, Mono
root@n900:/tmp#
I did this:
I'm not sure which one is main microphone and which is headset, but
I guess 2V should be close enough to 2.5V to produce something
different from zeros..?
Main or integrated is digital microphone which does AD conversion itself
and headset is analogue. If DMIC is without bias codec will sample plain
zeros from DMIC input but analogue input should always produce some random
LSB bits from codec's AD converter.
If codec produces zeros also from analogue input then I suppose codec
ADC is not powered up or similar. One way to hunt regression if
bisecting is not possible due reason or another is to dump and diff codec
registers from /sys/kernel/debug/regmap/ using both working commit and head.
diff --git a/arch/arm/boot/dts/omap3-n900.dts
b/arch/arm/boot/dts/omap3-n900.dts
index 48b0987..f18a5b0 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -491,6 +491,8 @@
DRVDD-supply = vmmc2;
IOVDD-supply = vio;
DVDD-supply = vio;
+
+ ai3x-micbias-vg = 1;
};
Looks ok for digital mic.
tlv320aic3x_aux: tlv320aic3x@19 {
@@ -502,6 +504,8 @@
DRVDD-supply = vmmc2;
IOVDD-supply = vio;
DVDD-supply = vio;
+
+ ai3x-micbias-vg = 1;
};
This should be 2, i.e. 2.5 V according to
Documentation/devicetree/bindings/sound/tlv320aic3x.txt. I think 2 V is
too low for some headset mics and that was the reason for 2.5 V.
--
Jarkko
--
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: AM43xx: hwmod: add VPFE hwmod entries
Suspend/resume is functional with this patch.
Tested-by: Benoit Parrot bpar...@ti.com
Lad, Prabhakar prabhakar.cse...@gmail.com wrote on Mon [2015-Jan-26 08:21:28
+]:
From: Benoit Parrot bpar...@ti.com
this patch adds VPFE HWMOD data for AM43xx.
Signed-off-by: Benoit Parrot bpar...@ti.com
Signed-off-by: Darren Etheridge detheri...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
Changes for v3:
a: Dropped OCPIF_SWSUP_IDLE flag from l3 hwmods of vpfe.
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 70
++
arch/arm/mach-omap2/prcm43xx.h | 3 +-
2 files changed, 72 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 5c6c841..8543f9f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -514,6 +514,44 @@ static struct omap_hwmod am43xx_dss_rfbi_hwmod = {
},
};
+static struct omap_hwmod_class_sysconfig am43xx_vpfe_sysc = {
+ .rev_offs = 0x0,
+ .sysc_offs = 0x104,
+ .sysc_flags = SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE,
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_SMART | MSTANDBY_NO),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class am43xx_vpfe_hwmod_class = {
+ .name = vpfe,
+ .sysc = am43xx_vpfe_sysc,
+};
+
+static struct omap_hwmod am43xx_vpfe0_hwmod = {
+ .name = vpfe0,
+ .class = am43xx_vpfe_hwmod_class,
+ .clkdm_name = l3s_clkdm,
+ .prcm = {
+ .omap4 = {
+ .modulemode = MODULEMODE_SWCTRL,
+ .clkctrl_offs = AM43XX_CM_PER_VPFE0_CLKCTRL_OFFSET,
+ },
+ },
+};
+
+static struct omap_hwmod am43xx_vpfe1_hwmod = {
+ .name = vpfe1,
+ .class = am43xx_vpfe_hwmod_class,
+ .clkdm_name = l3s_clkdm,
+ .prcm = {
+ .omap4 = {
+ .modulemode = MODULEMODE_SWCTRL,
+ .clkctrl_offs = AM43XX_CM_PER_VPFE1_CLKCTRL_OFFSET,
+ },
+ },
+};
+
/* Interfaces */
static struct omap_hwmod_ocp_if am43xx_l3_main__l4_hs = {
.master = am33xx_l3_main_hwmod,
@@ -788,6 +826,34 @@ static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_rfbi =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if am43xx_l3__vpfe0 = {
+ .master = am43xx_vpfe0_hwmod,
+ .slave = am33xx_l3_main_hwmod,
+ .clk= l3_gclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l3__vpfe1 = {
+ .master = am43xx_vpfe1_hwmod,
+ .slave = am33xx_l3_main_hwmod,
+ .clk= l3_gclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__vpfe0 = {
+ .master = am33xx_l4_ls_hwmod,
+ .slave = am43xx_vpfe0_hwmod,
+ .clk= l4ls_gclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__vpfe1 = {
+ .master = am33xx_l4_ls_hwmod,
+ .slave = am43xx_vpfe1_hwmod,
+ .clk= l4ls_gclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
am33xx_l4_wkup__synctimer,
am43xx_l4_ls__timer8,
@@ -887,6 +953,10 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[]
__initdata = {
am43xx_l4_ls__dss,
am43xx_l4_ls__dss_dispc,
am43xx_l4_ls__dss_rfbi,
+ am43xx_l3__vpfe0,
+ am43xx_l3__vpfe1,
+ am43xx_l4_ls__vpfe0,
+ am43xx_l4_ls__vpfe1,
NULL,
};
diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h
index ad7b3e9..8aa4c2c 100644
--- a/arch/arm/mach-omap2/prcm43xx.h
+++ b/arch/arm/mach-omap2/prcm43xx.h
@@ -143,5 +143,6 @@
#define AM43XX_CM_PER_USB_OTG_SS1_CLKCTRL_OFFSET0x0268
#define AM43XX_CM_PER_USBPHYOCP2SCP1_CLKCTRL_OFFSET 0x05C0
#define AM43XX_CM_PER_DSS_CLKCTRL_OFFSET 0x0a20
-
+#define AM43XX_CM_PER_VPFE0_CLKCTRL_OFFSET 0x0068
+#define AM43XX_CM_PER_VPFE1_CLKCTRL_OFFSET 0x0070
#endif
--
2.1.0
--
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
