Re: [PATCH 5/5] tty: serial: Add 8250-core based omap driver
* Sebastian Andrzej Siewior bige...@linutronix.de [140717 03:09]:
On 07/17/2014 10:12 AM, Tony Lindgren wrote:
Hmm it could be that it works for a while because the clocks are on
from the bootloader and pm_runtime calls won't do anything. This
could happen if the interconnect data based on the ti,hwmods entry
is not getting matched to the new driver. This gets initialized when
the device entry gets created in omap_device_build_from_dt().
Or maybe something now affects the clock aliases? It seems that we
are still missing the clocks entries in the .dtsi files, see the
mappings with $ git grep uart drivers/clk/ti/
I've been looking for something completely different while I noticed
this:
in drivers/tty/serial/omap-serial.c
| static struct platform_driver serial_omap_driver = {
| .driver = {
| .name = DRIVER_NAME,
| },
| };
|
and DRIVER_NAME should come from include/linux/platform_data/serial-omap.h
Looking further, I've found arch/arm/mach-omap2/serial.c:
| void __init omap_serial_init_port(struct omap_board_data *bdata,
| struct omap_uart_port_info *info)
| {
| char *name
…
| name = DRIVER_NAME;
…
| pdev = omap_device_build(name, uart-num, oh, pdata, pdata_size);
…
|
Would this explain it?
That would explain it for legacy booting, but not for device tree
based booting. I can try to debug it further on Monday.
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: AM3517 fails to boot 3.16-rc5 device tree kernel
* mwelling mwell...@emacinc.com [140717 16:42]: I am in the process of porting a device tree compatible version of the linux kernel to a AM3517 based device. First I tried 3.10.x and the device tree port appeared to be incomplete. Neither the LCD or Ethernet were supported. Next I tried 3.14.x and the Ethernet driver appeared to work but still no LCD support. Lastly I tried 3.16-rc5 and found that the kernel hangs in early boot without any messages from the serial COM. For device tree based booting on omap3 I would user v.16-rc4 or later. There have been multiple issues fixed over past year and PM is working finally at least for 36xx/37xx. And we do have the DSS panels finally working too. I was using the omap2plus_defconfig and the am3517-evm.dtb from each kernel build. Is there any reason why the kernel would start hanging with the newest release? No reason that I can think of. AFAIK 3517 has been booting in the test farms just fine? Can you please enable debug_ll + earlyprintk and pass also earlyprintk in the kernel cmdline? Are there any versions where the LCD output works? Starting with v3.16-rc1 you should get the LCD working for panel-dpi based devices. Most of them actually are actually ls037v3dw01, so see omap3-panel-sharp-ls037v7dw01.dtsi and omap3-evm-common.dtsi variants if you have similar setup. Looking at the 3.16-rc5 test results just posted it is supposed to be working but I have not been able to replicate this. Any suggestions would be greatly appreciated. Hmm maybe double check your're booting device tree based kernel instead of legacy machine ID based kernel? The legacy booting should still work just fine and no changes has been made to it, but it will get removed 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: [v3 PATCH 1/6] drivers: reset: TI: SoC reset controller support.
Hi,
Dan Murphy wrote:
The TI SoC reset controller support utilizes the
reset controller framework to give device drivers or
function drivers a common set of APIs to call to reset
a module.
The reset-ti is a common interface to the reset framework.
The register data is retrieved during initialization
of the reset driver through the reset-ti-data
file. The array of data is associated with the compatible from the
respective DT entry.
Once the data is available then this is derefenced within the common
interface.
The device driver has the ability to assert, deassert or perform a
complete reset.
This code was derived from previous work by Rajendra Nayak and Afzal Mohammed.
The code was changed to adopt to the reset core and abstract away the SoC
information.
Signed-off-by: Dan Murphy dmur...@ti.com
---
v3 - Resolved comments from v2. To many to call out here -
https://patchwork.kernel.org/patch/4116941/
drivers/reset/Kconfig|9 ++
drivers/reset/Makefile |1 +
drivers/reset/reset-ti.c | 373
++
3 files changed, 383 insertions(+)
create mode 100644 drivers/reset/reset-ti.c
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 0615f50..31a5a79 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -12,4 +12,13 @@ menuconfig RESET_CONTROLLER
If unsure, say no.
+config RESET_TI
+ depends on RESET_CONTROLLER ARCH_OMAP || COMPILE_TEST
+ bool TI reset controller
+ help
+ Reset controller support for TI SoC's
+
+ Reset controller found in TI's AM series of SoC's like
+ AM335x and AM43x and OMAP SoC's like OMAP5 and DRA7
+
source drivers/reset/sti/Kconfig
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 60fed3d..a5986b9 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_RESET_CONTROLLER) += core.o
obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
+obj-$(CONFIG_RESET_TI) += reset-ti.o
obj-$(CONFIG_ARCH_STI) += sti/
diff --git a/drivers/reset/reset-ti.c b/drivers/reset/reset-ti.c
new file mode 100644
index 000..e9d4039
--- /dev/null
+++ b/drivers/reset/reset-ti.c
@@ -0,0 +1,373 @@
+/*
+ * reset-ti.c - PRCM reset driver for TI SoC's
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Author: Dan Murphy dmur...@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.
+ */
+
+#include linux/delay.h
+#include linux/device.h
+#include linux/err.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/reset.h
+#include linux/reset-controller.h
+#include linux/slab.h
+#include linux/spinlock.h
+
+#define DRIVER_NAME prcm_reset_ti
+#define MAX_RESET_SIGNALS 255
+
+/**
+ * struct ti_reset_reg_data - Structure of the reset register information
+ * for a particular SoC.
+ * @rstctrl_offs: This is the reset control offset value from
+ * from the parent reset node.
+ * @rstst_offs: This is the reset status offset value from
+ * from the parent reset node.
+ * @rstctrl_bit: This is the reset control bit for the module.
+ * @rstst_bit: This is the reset status bit for the module.
+ *
+ * Longer description of this structure.
+ */
+struct ti_reset_reg_data {
+ phandle handle;
+ u32 rstctrl_offs;
+ u32 rstst_offs;
+ u32 rstctrl_bit;
+ u32 rstst_bit;
+};
+
+/**
+ * struct ti_reset_data - Structure that contains the reset register data
+ * as well as the total number of resets for a particular SoC.
+ * @ti_data: Pointer to this structure to be dereferenced
+ * @reg_data:Pointer to the register data structure.
+ * @rcdev: Reset controller device instance
+ * @dev: Pointer to the devive structure
+ * @ti_reg_data: Array of register data. Only reset signal with valid
+ * phandles will be stored in this array.
+ * @reg_base:Parent register base address
+ * @lock:Spinlock for accessing the registers
+ * @nr_resets: Total number of resets for the SoC in the reset array.
+ *
+ * This structure contains a pointer to the register data and the modules
+ * register base. The number of resets and reset controller device data is
+ * stored within this structure.
+ *
+ */
+struct ti_reset_data {
+ struct ti_reset_data *ti_data;
+ struct ti_reset_reg_data *reg_data;
+ struct reset_controller_dev rcdev;
+ struct device *dev;
+ struct ti_reset_reg_data ti_reg_data[MAX_RESET_SIGNALS];
+ void __iomem
Re: [PATCH 1/5] arm: dts: omap3-gta04: Add missing nodes to fully describe gta04 board
On 16 July 2014 09:17, Dr. H. Nikolaus Schaller h...@goldelico.com wrote:
Am 15.07.2014 um 14:45 schrieb Joachim Eastwood:
Hi Marek,
You seem to add some DT nodes for hw that doesn't have drivers in
mainline. I think you should leave those out until the driver itself
is upstream and the bindings for it is documented.
is there some policy for only having nodes for existing drivers in DT files?
I am not sure about that, better ask the DT maintainers.
There is however a policy that says new bindings should be reviewed
and documented.
If I understand the device tree concept correctly, it should not describe
drivers
(and hence nothing about the state of them being mainlined), but it should
statically
describe the given hardware in a way that kernel and drivers can read it (or
ignore).
And even other kernels can use it (because they run on the same hardware).
So unless there is an important reason not to have currently unused nodes
in the DT source/binary (loading time is IMHO neglectable), I would ask that
we
can keep with the complete DT instead of splitting it up artificially and
getting back
to the same status (because the hardware does not change over time).
The problem with the nodes is that the bindings may change when the
drivers/bindings are submitted to mainline and reviewed. I don't see
why you want nodes for hardware that right now obviously don't work
with mainline and if the bindings change it will churn and confusion
for the users.
One example is the omap-pwm driver. It should really have #pwm-cells
set to 3 and not 2. This driver is not upstream yet, because it
requires some files to move out of arch/arm. See
http://marc.info/?l=linux-omapm=139903867022779w=2 for the suggested
new bindings.
The normal case for new DT boards is to first submit nodes for the
hardware that is working in mainline and then update the DT with more
nodes for hardware as bindings are decided upon and drivers go
upstream.
Please don't top post.
regards,
Joachim Eastwood
On 14 July 2014 22:20, Marek Belisko ma...@goldelico.com wrote:
Signed-off-by: Marek Belisko ma...@goldelico.com
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
---
arch/arm/boot/dts/omap3-gta04.dts | 443
+++---
1 file changed, 412 insertions(+), 31 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-gta04.dts
b/arch/arm/boot/dts/omap3-gta04.dts
index 215513b..bd6a71d 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -12,7 +12,7 @@
#include omap36xx.dtsi
/ {
- model = OMAP3 GTA04;
+ model = Goldelico GTA04;
compatible = ti,omap3-gta04, ti,omap36xx, ti,omap3;
cpus {
@@ -26,6 +26,11 @@
reg = 0x8000 0x2000; /* 512 MB */
};
+ aliases {
+ display0 = lcd;
+ display1 = tv0;
+ };
+
gpio-keys {
compatible = gpio-keys;
@@ -37,15 +42,78 @@
};
};
+ gpio-keys-wwan-wakeup {
+ compatible = gpio-keys;
+
+ wwan_wakeup_button: wwan-wakeup-button {
+ label = 3G_WOE;
+ linux,code = 240;
+ gpios = gpio1 10 GPIO_ACTIVE_HIGH;
+ gpio-key,wakeup;
+ };
+ };
+
+ hsusb2_phy: hsusb2_phy {
+ compatible = usb-nop-xceiv;
+ reset-gpios = gpio6 14 GPIO_ACTIVE_LOW; /* gpio_174 =
reset for USB3322 */
+ };
+
+ antenna-detect {
+ compatible = linux,extcon-gpio;
+ label = gps_antenna;
+ gpios = gpio5 16 0; /* gpio_144 */
+ debounce-delay-ms = 10;
+ irq-flags = IRQ_TYPE_EDGE_BOTH;
+ state-on = external;
+ state-off = internal;
+ };
+
sound {
compatible = ti,omap-twl4030;
ti,model = gta04;
ti,mcbsp = mcbsp2;
ti,codec = twl_audio;
+
+ ti,mcbsp-voice = mcbsp4;
+ };
+
+ sound_card {
+ compatible = goldelico,gta04-audio;
+ gta04,cpu-dai = mcbsp2;
+ };
+
+ gtm601_codec: voice_codec {
+ compatible = gtm601-codec;
+ };
+
+ sound_voice {
+ compatible = goldelico,gta04-voice;
+ gta04,cpu-dai = mcbsp4;
+ gta04,codec = gtm601_codec;
};
- spi_lcd {
+ w2cbw003_codec: headset_codec {
+ compatible = w2cbw003-codec;
+ };
+
+ sound_headset {
+ compatible = goldelico,gta04-headset;
+ gta04,cpu-dai = mcbsp3;
+ gta04,codec = w2cbw003_codec;
+ };
+
+ sound_fm {
+ compatible = goldelico,gta04-fm;
+ gta04,cpu-dai = mcbsp1;
+ gta04,codec =
[PATCH 1/3] omap_hsmmc: reuse mmc/slot-gpio for write protect detection
Signed-off-by: Andreas Fenkart afenk...@gmail.com
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 2f944d7..1c10e6c 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -36,6 +36,7 @@
#include linux/mmc/host.h
#include linux/mmc/core.h
#include linux/mmc/mmc.h
+#include linux/mmc/slot-gpio.h
#include linux/io.h
#include linux/irq.h
#include linux/gpio.h
@@ -239,15 +240,6 @@ static int omap_hsmmc_card_detect(struct device *dev, int
slot)
return !gpio_get_value_cansleep(mmc-slots[0].switch_pin);
}
-static int omap_hsmmc_get_wp(struct device *dev, int slot)
-{
- struct omap_hsmmc_host *host = dev_get_drvdata(dev);
- struct omap_mmc_platform_data *mmc = host-pdata;
-
- /* NOTE: assumes write protect signal is active-high */
- return gpio_get_value_cansleep(mmc-slots[0].gpio_wp);
-}
-
static int omap_hsmmc_get_cover_state(struct device *dev, int slot)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
@@ -449,7 +441,8 @@ static inline int omap_hsmmc_have_reg(void)
#endif
-static int omap_hsmmc_gpio_init(struct omap_mmc_platform_data *pdata)
+static int omap_hsmmc_gpio_init(struct mmc_host *mmc,
+ struct omap_mmc_platform_data *pdata)
{
int ret;
@@ -471,31 +464,31 @@ static int omap_hsmmc_gpio_init(struct
omap_mmc_platform_data *pdata)
pdata-slots[0].switch_pin = -EINVAL;
if (gpio_is_valid(pdata-slots[0].gpio_wp)) {
- pdata-slots[0].get_ro = omap_hsmmc_get_wp;
- ret = gpio_request(pdata-slots[0].gpio_wp, mmc_wp);
- if (ret)
- goto err_free_cd;
- ret = gpio_direction_input(pdata-slots[0].gpio_wp);
- if (ret)
- goto err_free_wp;
- } else
- pdata-slots[0].gpio_wp = -EINVAL;
+ /* copy paste from from mmc_of_parse */
+ ret = mmc_gpio_request_ro(mmc, pdata-slots[0].gpio_wp);
+ if (ret 0) {
+ dev_err(pdata-dev,
+ Failed to request WP GPIO: %d!\n, ret);
+ goto err;
+ } else {
+ dev_info(pdata-dev, Got WP GPIO #%d.\n,
+pdata-slots[0].gpio_wp);
+ }
+ }
return 0;
-err_free_wp:
- gpio_free(pdata-slots[0].gpio_wp);
-err_free_cd:
+err:
if (gpio_is_valid(pdata-slots[0].switch_pin))
err_free_sp:
gpio_free(pdata-slots[0].switch_pin);
return ret;
}
-static void omap_hsmmc_gpio_free(struct omap_mmc_platform_data *pdata)
+static void omap_hsmmc_gpio_free(struct mmc_host *mmc,
+struct omap_mmc_platform_data *pdata)
{
- if (gpio_is_valid(pdata-slots[0].gpio_wp))
- gpio_free(pdata-slots[0].gpio_wp);
+ mmc_gpio_free_ro(mmc);
if (gpio_is_valid(pdata-slots[0].switch_pin))
gpio_free(pdata-slots[0].switch_pin);
}
@@ -1673,15 +1666,6 @@ static int omap_hsmmc_get_cd(struct mmc_host *mmc)
return mmc_slot(host).card_detect(host-dev, host-slot_id);
}
-static int omap_hsmmc_get_ro(struct mmc_host *mmc)
-{
- struct omap_hsmmc_host *host = mmc_priv(mmc);
-
- if (!mmc_slot(host).get_ro)
- return -ENOSYS;
- return mmc_slot(host).get_ro(host-dev, 0);
-}
-
static void omap_hsmmc_init_card(struct mmc_host *mmc, struct mmc_card *card)
{
struct omap_hsmmc_host *host = mmc_priv(mmc);
@@ -1837,7 +1821,7 @@ static const struct mmc_host_ops omap_hsmmc_ops = {
.request = omap_hsmmc_request,
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
- .get_ro = omap_hsmmc_get_ro,
+ .get_ro = mmc_gpio_get_ro,
.init_card = omap_hsmmc_init_card,
.enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
};
@@ -2063,16 +2047,15 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
if (IS_ERR(base))
return PTR_ERR(base);
- ret = omap_hsmmc_gpio_init(pdata);
- if (ret)
- goto err;
-
mmc = mmc_alloc_host(sizeof(struct omap_hsmmc_host), pdev-dev);
if (!mmc) {
- ret = -ENOMEM;
- goto err_alloc;
+ return -ENOMEM;
}
+ ret = omap_hsmmc_gpio_init(mmc, pdata);
+ if (ret)
+ goto err;
+
host= mmc_priv(mmc);
host-mmc = mmc;
host-pdata = pdata;
@@ -2302,10 +2285,9 @@ err_irq:
if (host-dbclk)
clk_disable_unprepare(host-dbclk);
err1:
- mmc_free_host(mmc);
-err_alloc:
- omap_hsmmc_gpio_free(pdata);
+ omap_hsmmc_gpio_free(mmc, pdata);
err:
+ mmc_free_host(mmc);
return ret;
}
@@ -2330,7 +2312,7 @@ static int omap_hsmmc_remove(struct platform_device *pdev)
if
[PATCH 2/3] omap_hsmmc: separate card_detect/cover detect logic
assuming cover is the door like thing on cameras that needs to be closed
after replacing sd cards. card detect is a gpio connected to sdio slot.
in a follow up patch card_detect will be replaced by generic mmc/slot-gpio
a git bisect patch
Signed-off-by: Andreas Fenkart afenk...@gmail.com
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 1c10e6c..1b9f279 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -447,19 +447,32 @@ static int omap_hsmmc_gpio_init(struct mmc_host *mmc,
int ret;
if (gpio_is_valid(pdata-slots[0].switch_pin)) {
- if (pdata-slots[0].cover)
+ if (pdata-slots[0].cover) {
pdata-slots[0].get_cover_state =
omap_hsmmc_get_cover_state;
- else
+ pdata-slots[0].cover_detect_irq =
+ gpio_to_irq(pdata-slots[0].switch_pin);
+
+ ret = gpio_request(pdata-slots[0].switch_pin,
+ mmc_cd);
+ if (ret)
+ return ret;
+ ret = gpio_direction_input(pdata-slots[0].switch_pin);
+ if (ret)
+ goto err_free_sp;
+ } else {
pdata-slots[0].card_detect = omap_hsmmc_card_detect;
- pdata-slots[0].card_detect_irq =
+ pdata-slots[0].card_detect_irq =
gpio_to_irq(pdata-slots[0].switch_pin);
- ret = gpio_request(pdata-slots[0].switch_pin, mmc_cd);
- if (ret)
- return ret;
- ret = gpio_direction_input(pdata-slots[0].switch_pin);
- if (ret)
- goto err_free_sp;
+
+ ret = gpio_request(pdata-slots[0].switch_pin,
+ mmc_cd);
+ if (ret)
+ return ret;
+ ret = gpio_direction_input(pdata-slots[0].switch_pin);
+ if (ret)
+ goto err_free_sp;
+ }
} else
pdata-slots[0].switch_pin = -EINVAL;
@@ -1282,19 +1295,18 @@ static irqreturn_t omap_hsmmc_detect(int irq, void
*dev_id)
struct omap_mmc_slot_data *slot = mmc_slot(host);
int carddetect;
- sysfs_notify(host-mmc-class_dev.kobj, NULL, cover_switch);
-
- if (slot-card_detect)
+ if (slot-card_detect) {
carddetect = slot-card_detect(host-dev, host-slot_id);
- else {
+ if (carddetect)
+ mmc_detect_change(host-mmc, (HZ * 200) / 1000);
+ else
+ mmc_detect_change(host-mmc, (HZ * 50) / 1000);
+ } else {
+ sysfs_notify(host-mmc-class_dev.kobj, NULL, cover_switch);
omap_hsmmc_protect_card(host);
- carddetect = -ENOSYS;
+ mmc_detect_change(host-mmc, (HZ * 200) / 1000);
}
- if (carddetect)
- mmc_detect_change(host-mmc, (HZ * 200) / 1000);
- else
- mmc_detect_change(host-mmc, (HZ * 50) / 1000);
return IRQ_HANDLED;
}
diff --git a/include/linux/platform_data/mmc-omap.h
b/include/linux/platform_data/mmc-omap.h
index 7fe0c14..d113005 100644
--- a/include/linux/platform_data/mmc-omap.h
+++ b/include/linux/platform_data/mmc-omap.h
@@ -136,6 +136,7 @@ struct omap_mmc_platform_data {
* 0 - closed
* 1 - open
*/
+ int cover_detect_irq;
int (*get_cover_state)(struct device *dev, int slot);
const char *name;
--
2.0.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
[PATCH 0/3] omap_hsmmc: reuse mmc/slot-gpio functions
Hi Balaji,
I'm trying to reuse mmc_of_parse for parsing standard mmc features:
- cd-gpios / wp-gpios
- bus-width
- max-frequency
- keep-power-in-suspend
- enable-sdio-wakeup
- ti,non-removable, evtl.
Currently these are open-coded in of_get_hsmmc_pdata. I tried
removing them all from of_get_hsmmc_pdata and call mmc_of_parse
at the end of the probe function:
@@ -2241,8 +2264,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
omap_hsmmc_protect_card(host);
+ mmc_of_parse(host-mmc);
mmc_add_host(mmc);
This should work transparently for most features except,
cd-gpios/wp-gpios. Pls can you have a look at the followup
patches? I tried an intermediate step mapping card detect /
read-only detect onto mmc/slot-gpio that are used by
mmc_of_parse. I don't have card detect/read-only detect pins, :-(
Do we still need cover_detect functionality or could it be merged
with card detect?
Another issue is 'ti,non-removable' which could be mappend to
'non-removable' if 'no_regulator_off_init' could be handled in a
different way.
if (of_find_property(np, ti,non-removable, NULL)) {
pdata-slots[0].nonremovable = true;
pdata-slots[0].no_regulator_off_init = true;
}
thanks,
Andreas
Andreas Fenkart (3):
omap_hsmmc: reuse mmc/slot-gpio for write protect detection
omap_hsmmc: separate card_detect/cover detect logic
omap_hsmmc: reuse mmc/slot-gpio for card detect instead of open-coded
version
drivers/mmc/host/omap_hsmmc.c | 172 ++---
include/linux/platform_data/mmc-omap.h | 6 +-
2 files changed, 73 insertions(+), 105 deletions(-)
--
2.0.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
[PATCH 3/3] omap_hsmmc: reuse mmc/slot-gpio for card detect instead of open-coded version
Signed-off-by: Andreas Fenkart afenk...@gmail.com
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 1b9f279..25aafa6 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -231,15 +231,6 @@ struct omap_mmc_of_data {
static void omap_hsmmc_start_dma_transfer(struct omap_hsmmc_host *host);
-static int omap_hsmmc_card_detect(struct device *dev, int slot)
-{
- struct omap_hsmmc_host *host = dev_get_drvdata(dev);
- struct omap_mmc_platform_data *mmc = host-pdata;
-
- /* NOTE: assumes card detect signal is active-low */
- return !gpio_get_value_cansleep(mmc-slots[0].switch_pin);
-}
-
static int omap_hsmmc_get_cover_state(struct device *dev, int slot)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
@@ -256,7 +247,7 @@ static int omap_hsmmc_suspend_cdirq(struct device *dev, int
slot)
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
struct omap_mmc_platform_data *mmc = host-pdata;
- disable_irq(mmc-slots[0].card_detect_irq);
+ disable_irq(mmc-slots[0].cover_detect_irq);
return 0;
}
@@ -265,7 +256,7 @@ static int omap_hsmmc_resume_cdirq(struct device *dev, int
slot)
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
struct omap_mmc_platform_data *mmc = host-pdata;
- enable_irq(mmc-slots[0].card_detect_irq);
+ enable_irq(mmc-slots[0].cover_detect_irq);
return 0;
}
@@ -458,23 +449,26 @@ static int omap_hsmmc_gpio_init(struct mmc_host *mmc,
if (ret)
return ret;
ret = gpio_direction_input(pdata-slots[0].switch_pin);
- if (ret)
- goto err_free_sp;
+ if (ret) {
+ gpio_free(pdata-slots[0].switch_pin);
+ return ret;
+ }
} else {
- pdata-slots[0].card_detect = omap_hsmmc_card_detect;
- pdata-slots[0].card_detect_irq =
- gpio_to_irq(pdata-slots[0].switch_pin);
-
- ret = gpio_request(pdata-slots[0].switch_pin,
- mmc_cd);
- if (ret)
+ /* copy paste from from mmc_of_parse */
+ ret = mmc_gpio_request_cd(mmc,
+ pdata-slots[0].switch_pin,
+ 0);
+ if (ret 0) {
+ dev_err(pdata-dev,
+ Failed to request CD GPIO #%d: %d!\n,
+ pdata-slots[0].switch_pin, ret);
return ret;
- ret = gpio_direction_input(pdata-slots[0].switch_pin);
- if (ret)
- goto err_free_sp;
+ } else {
+ dev_info(pdata-dev, Got CD GPIO #%d.\n,
+ pdata-slots[0].switch_pin);
+ }
}
- } else
- pdata-slots[0].switch_pin = -EINVAL;
+ }
if (gpio_is_valid(pdata-slots[0].gpio_wp)) {
/* copy paste from from mmc_of_parse */
@@ -492,8 +486,9 @@ static int omap_hsmmc_gpio_init(struct mmc_host *mmc,
return 0;
err:
- if (gpio_is_valid(pdata-slots[0].switch_pin))
-err_free_sp:
+ mmc_gpio_free_cd(mmc);
+ if (gpio_is_valid(pdata-slots[0].switch_pin)
+ (pdata-slots[0].cover))
gpio_free(pdata-slots[0].switch_pin);
return ret;
}
@@ -501,8 +496,11 @@ err_free_sp:
static void omap_hsmmc_gpio_free(struct mmc_host *mmc,
struct omap_mmc_platform_data *pdata)
{
+ mmc_gpio_free_cd(mmc);
mmc_gpio_free_ro(mmc);
- if (gpio_is_valid(pdata-slots[0].switch_pin))
+
+ if (gpio_is_valid(pdata-slots[0].switch_pin)
+ (pdata-slots[0].cover))
gpio_free(pdata-slots[0].switch_pin);
}
@@ -1289,24 +1287,13 @@ static void omap_hsmmc_protect_card(struct
omap_hsmmc_host *host)
/*
* irq handler to notify the core about card insertion/removal
*/
-static irqreturn_t omap_hsmmc_detect(int irq, void *dev_id)
+static irqreturn_t omap_hsmmc_cover_detect(int irq, void *dev_id)
{
struct omap_hsmmc_host *host = dev_id;
- struct omap_mmc_slot_data *slot = mmc_slot(host);
- int carddetect;
-
- if (slot-card_detect) {
- carddetect = slot-card_detect(host-dev, host-slot_id);
- if (carddetect)
- mmc_detect_change(host-mmc, (HZ * 200) / 1000);
- else
- mmc_detect_change(host-mmc, (HZ * 50) / 1000);
- } else {
-
Re: [PATCH 4/5] tty: serial: 8250 core: add runtime pm
On 07/17/2014 06:18 PM, Felipe Balbi wrote: No, this is okay. If you look, it checks for up-ier UART_IER_THRI. On the second invocation it will see that this bit is already set and therefore won't call get_sync() for the second time. That bit is removed in the _stop_tx() path. oh, right. But that's actually unnecessary. Calling pm_runtime_get() multiple times will just increment the usage counter multiple times, which means you can call __stop_tx() multiple times too and everything gets balanced, right ? No. start_tx() will be called multiple times but only the first invocation invoke pm_runtime_get(). Now I noticed that I forgot to remove pm_runtime_put_autosuspend() at the bottom of it. But you get the idea right? pm_get() on the while the UART_IER_THRI is not yet set. pm_put() once the fifo is completely empty. Do you have other ideas? It doesn't look like this is exported at all. If we call _stop_tx() right away, then we have 64 bytes in the TX fifo in the worst case. They should be gone soon but the HW-flow control may delay it (in theory for a long time)). this can be problematic, specially for OMAP which can go into OFF while idle. Whatever is in the FIFO would get lost. It seems like omap-serial solved this within transmit_chars(). No, it didn't. See how transmit_chars() is called from within IRQ handler with clocks enabled then it conditionally calls serial_omap_stop_tx() which will pm_runtime_get_sync() - do_the_harlem_shake() - pm_runtime_put_autosuspend(). That leaves one unbalanced pm_runtime_get() which is balanced when we're exitting the IRQ handler. omap-serial and the 8250 do the following on tx path: - start_tx() - sets UART_IER_THRI. This will generate an interrupt once the FIFO is empty. - interrupt, notices the empty fifo, invokes serial8250_start_tx()/ transmit_chars(). Both have a while loop that fills the FIFO. This loop is left once the tty-buffer is empty (uart_circ_empty() is true) or the FIFO full. Lets say you filled 64 bytes into the FIFO and then left because your FIFO is full and tty-buffer is empty. That means you will invoke serial_omap_stop_tx() and remove UART_IER_THRI bit. This is okay because you are not interested in further FIFO empty interrupts because you don't have any TX-bytes to be sent. However, once you leave the transmit_chars() you leave serial_omap_irq() which does the last pm_put(). That means you have data in the TX FIFO that is about to be sent and the device is in auto-suspend. This is fine as long as the timeout is greater then the time required for the data be sent (plus assuming HW-float control does not stall it for too long) so nobody notices a thing. For that reason I added the hack / #if0 block in the 8250 driver. To ensure we do not disable the TX-FIFO-empty interrupt even if there is nothing to send. Instead we enter serial8250_tx_chars() once again with empty FIFO and empty tty-buffer and will invoke _stop_tx() which also finally does the pm_put(). That is the plan. The problem I have is how to figure out that the device is using auto-suspend. If I don't then I would have to remove the #if0 block and that would mean for everybody an extra interrupt (which I wanted to avoid). This seems work fine and dandy without DMA, but for DMA work, I think we need to make sure this IP stays powered until we get DMA completion callback. But that's future, I guess. Yes, probably. That means one get at dma start, one put at dma complete callback. And I assume we get that callbacks once the DMA transfer is complete, not when the FIFO is empty :) So lets leave it to the future for now… Sebastian -- 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 1/5] arm: dts: omap3-gta04: Add missing nodes to fully describe gta04 board
Hello Marek and Dr. H. Nikolaus, On Fri, Jul 18, 2014 at 8:55 AM, Joachim Eastwood manab...@gmail.com wrote: On 16 July 2014 09:17, Dr. H. Nikolaus Schaller h...@goldelico.com wrote: Am 15.07.2014 um 14:45 schrieb Joachim Eastwood: Hi Marek, You seem to add some DT nodes for hw that doesn't have drivers in mainline. I think you should leave those out until the driver itself is upstream and the bindings for it is documented. is there some policy for only having nodes for existing drivers in DT files? I strongly agree with Joachim on this regard. If I understand the device tree concept correctly, it should not describe drivers (and hence nothing about the state of them being mainlined), but it should statically describe the given hardware in a way that kernel and drivers can read it (or ignore). And even other kernels can use it (because they run on the same hardware). Yes, it should describe hardware but that description should be previously agreed and properly documented as was mentioned before. So unless there is an important reason not to have currently unused nodes in the DT source/binary (loading time is IMHO neglectable), I would ask that we can keep with the complete DT instead of splitting it up artificially and getting back to the same status (because the hardware does not change over time). I understand your motivation since it will allow you to not have to maintain a patch-set for your downstream DTS changes but I would like to ask you the opposite question. What's the benefit for the kernel community to keep in a mainline DTS a bunch of device nodes with DT bindings that have not been neither discussed nor documented? Developers doing a board bring-up usually use the DTS in mainline as a reference for their boards and having non-documented/agreed DT binding on the upstream DTS will only bring confusion and frustration to them IMHO. We already have some issues with Device Trees (bindings that broke backward compatibility, drivers implementing custom DT binding instead of using standard ones, bindings that don't really reflect the actual H/W, etc), please don't make this even more complicated to developers. 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 0/3] iommu: Remove OMAP IOVMM driver
Hello, The OMAP3 ISP driver was the only user of the OMAP IOVMM API. Now that is has been ported to the DMA API, remove the unused virtual memory manager. The removal is split in three patches to ease upstream merge. The first patch removes the omap-iovmm driver, the second patch removes setting of now unused platform data fields from arch code, and the last patch cleans up the platform data structure. I'd like to get at least the first patch merged in v3.17. To avoid splitting the series across three kernel versions, it would be nice to also merge at least the second patch for v3.17. If there's no risk of conflict everything could be merged in one go through the ARM SoC tree. Otherwise a stable branch with patch 1/3 will be needed to base the arch change on. Joerg, Tony, how would you like to proceed ? Changes compared to v1: - Fix OMAP_IOMMU_DEBUG dependency on OMAP_IOMMU - Remove omap_iommu da_start and da_end fields - Added patches 2/3 and 3/3 Laurent Pinchart (3): iommu/omap: Remove virtual memory manager ARM: omap: Don't set iommu pdata da_start and da_end fields iommu/omap: Remove platform data da_start and da_end fields arch/arm/mach-omap2/omap-iommu.c | 2 - arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 4 - arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 4 - drivers/iommu/Kconfig | 10 +- drivers/iommu/Makefile | 1 - drivers/iommu/omap-iommu-debug.c | 114 - drivers/iommu/omap-iommu.c | 13 - drivers/iommu/omap-iommu.h | 8 +- drivers/iommu/omap-iovmm.c | 791 - include/linux/omap-iommu.h | 37 +- include/linux/platform_data/iommu-omap.h | 6 - 11 files changed, 8 insertions(+), 982 deletions(-) delete mode 100644 drivers/iommu/omap-iovmm.c -- Regards, Laurent Pinchart -- 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] ARM: omap: Don't set iommu pdata da_start and da_end fields
The fields are not used by the driver and will be removed from platform
data. Don't set them.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/arm/mach-omap2/omap-iommu.c | 2 --
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 4
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 4
3 files changed, 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index f1fab56..4068350 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -34,8 +34,6 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh,
void *unused)
pdata-name = oh-name;
pdata-nr_tlb_entries = a-nr_tlb_entries;
- pdata-da_start = a-da_start;
- pdata-da_end = a-da_end;
if (oh-rst_lines_cnt == 1) {
pdata-reset_name = oh-rst_lines-name;
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 1cd0cfd..e9516b4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -2986,8 +2986,6 @@ static struct omap_hwmod_class omap3xxx_mmu_hwmod_class =
{
/* mmu isp */
static struct omap_mmu_dev_attr mmu_isp_dev_attr = {
- .da_start = 0x0,
- .da_end = 0xf000,
.nr_tlb_entries = 8,
};
@@ -3026,8 +3024,6 @@ static struct omap_hwmod omap3xxx_mmu_isp_hwmod = {
/* mmu iva */
static struct omap_mmu_dev_attr mmu_iva_dev_attr = {
- .da_start = 0x1100,
- .da_end = 0xf000,
.nr_tlb_entries = 32,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 41e54f7..b4acc0a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2084,8 +2084,6 @@ static struct omap_hwmod_class omap44xx_mmu_hwmod_class =
{
/* mmu ipu */
static struct omap_mmu_dev_attr mmu_ipu_dev_attr = {
- .da_start = 0x0,
- .da_end = 0xf000,
.nr_tlb_entries = 32,
};
@@ -2133,8 +2131,6 @@ static struct omap_hwmod omap44xx_mmu_ipu_hwmod = {
/* mmu dsp */
static struct omap_mmu_dev_attr mmu_dsp_dev_attr = {
- .da_start = 0x0,
- .da_end = 0xf000,
.nr_tlb_entries = 32,
};
--
1.8.5.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 3/3] iommu/omap: Remove platform data da_start and da_end fields
The fields were used by the now gone omap-iovmm driver. They're not used
anymore, remove them.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/platform_data/iommu-omap.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/include/linux/platform_data/iommu-omap.h
b/include/linux/platform_data/iommu-omap.h
index 5b429c4..54a0a95 100644
--- a/include/linux/platform_data/iommu-omap.h
+++ b/include/linux/platform_data/iommu-omap.h
@@ -31,14 +31,10 @@ struct omap_iommu_arch_data {
/**
* struct omap_mmu_dev_attr - OMAP mmu device attributes for omap_hwmod
- * @da_start: device address where the va space starts.
- * @da_end:device address where the va space ends.
* @nr_tlb_entries:number of entries supported by the translation
* look-aside buffer (TLB).
*/
struct omap_mmu_dev_attr {
- u32 da_start;
- u32 da_end;
int nr_tlb_entries;
};
@@ -46,8 +42,6 @@ struct iommu_platform_data {
const char *name;
const char *reset_name;
int nr_tlb_entries;
- u32 da_start;
- u32 da_end;
int (*assert_reset)(struct platform_device *pdev, const char *name);
int (*deassert_reset)(struct platform_device *pdev, const char *name);
--
1.8.5.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] iommu/omap: Remove virtual memory manager
The OMAP3 ISP driver was the only user of the OMAP IOVMM API. Now that
is has been ported to the DMA API, remove the unused virtual memory
manager.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/Kconfig| 10 +-
drivers/iommu/Makefile | 1 -
drivers/iommu/omap-iommu-debug.c | 114 --
drivers/iommu/omap-iommu.c | 13 -
drivers/iommu/omap-iommu.h | 8 +-
drivers/iommu/omap-iovmm.c | 791 ---
include/linux/omap-iommu.h | 37 +-
7 files changed, 8 insertions(+), 966 deletions(-)
delete mode 100644 drivers/iommu/omap-iovmm.c
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index d260605..154e5a8 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -143,16 +143,12 @@ config OMAP_IOMMU
depends on ARCH_OMAP2PLUS
select IOMMU_API
-config OMAP_IOVMM
- tristate OMAP IO Virtual Memory Manager Support
- depends on OMAP_IOMMU
-
config OMAP_IOMMU_DEBUG
- tristate Export OMAP IOMMU/IOVMM internals in DebugFS
- depends on OMAP_IOVMM DEBUG_FS
+ tristate Export OMAP IOMMU internals in DebugFS
+ depends on OMAP_IOMMU DEBUG_FS
help
Select this to see extensive information about
- the internal state of OMAP IOMMU/IOVMM in debugfs.
+ the internal state of OMAP IOMMU in debugfs.
Say N unless you know you need this.
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 8893bad..6a4a00e 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -11,7 +11,6 @@ obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o
obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o irq_remapping.o
obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
obj-$(CONFIG_OMAP_IOMMU) += omap-iommu2.o
-obj-$(CONFIG_OMAP_IOVMM) += omap-iovmm.o
obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o
obj-$(CONFIG_TEGRA_IOMMU_GART) += tegra-gart.o
obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o
diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-debug.c
index 80fffba..531658d 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -213,116 +213,6 @@ static ssize_t debug_read_pagetable(struct file *file,
char __user *userbuf,
return bytes;
}
-static ssize_t debug_read_mmap(struct file *file, char __user *userbuf,
- size_t count, loff_t *ppos)
-{
- struct device *dev = file-private_data;
- struct omap_iommu *obj = dev_to_omap_iommu(dev);
- char *p, *buf;
- struct iovm_struct *tmp;
- int uninitialized_var(i);
- ssize_t bytes;
-
- buf = (char *)__get_free_page(GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
- p = buf;
-
- p += sprintf(p, %-3s %-8s %-8s %6s %8s\n,
-No, start, end, size, flags);
- p += sprintf(p, -\n);
-
- mutex_lock(iommu_debug_lock);
-
- list_for_each_entry(tmp, obj-mmap, list) {
- size_t len;
- const char *str = %3d %08x-%08x %6x %8x\n;
- const int maxcol = 39;
-
- len = tmp-da_end - tmp-da_start;
- p += snprintf(p, maxcol, str,
- i, tmp-da_start, tmp-da_end, len, tmp-flags);
-
- if (PAGE_SIZE - (p - buf) maxcol)
- break;
- i++;
- }
-
- bytes = simple_read_from_buffer(userbuf, count, ppos, buf, p - buf);
-
- mutex_unlock(iommu_debug_lock);
- free_page((unsigned long)buf);
-
- return bytes;
-}
-
-static ssize_t debug_read_mem(struct file *file, char __user *userbuf,
- size_t count, loff_t *ppos)
-{
- struct device *dev = file-private_data;
- char *p, *buf;
- struct iovm_struct *area;
- ssize_t bytes;
-
- count = min_t(ssize_t, count, PAGE_SIZE);
-
- buf = (char *)__get_free_page(GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
- p = buf;
-
- mutex_lock(iommu_debug_lock);
-
- area = omap_find_iovm_area(dev, (u32)ppos);
- if (!area) {
- bytes = -EINVAL;
- goto err_out;
- }
- memcpy(p, area-va, count);
- p += count;
-
- bytes = simple_read_from_buffer(userbuf, count, ppos, buf, p - buf);
-err_out:
- mutex_unlock(iommu_debug_lock);
- free_page((unsigned long)buf);
-
- return bytes;
-}
-
-static ssize_t debug_write_mem(struct file *file, const char __user *userbuf,
- size_t count, loff_t *ppos)
-{
- struct device *dev = file-private_data;
- struct iovm_struct *area;
- char *p, *buf;
-
- count = min_t(size_t, count, PAGE_SIZE);
-
- buf = (char *)__get_free_page(GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
- p = buf;
-
-
Re: [PATCH] iommu/omap: Remove virtual memory manager
Hi Suman,
Thank you for the review.
On Thursday 17 July 2014 10:53:03 Suman Anna wrote:
On 07/17/2014 06:09 AM, Laurent Pinchart wrote:
The OMAP3 ISP driver was the only user of the OMAP IOVMM API. Now that
is has been ported to the DMA API, remove the unused virtual memory
manager.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Joerg, could you please pick this patch up for v3.17 if possible ?
Need one minor change as below, otherwise patch is good.
drivers/iommu/Kconfig| 10 +-
drivers/iommu/Makefile | 1 -
drivers/iommu/omap-iommu-debug.c | 114 --
drivers/iommu/omap-iommu.c | 2 -
drivers/iommu/omap-iommu.h | 6 +-
drivers/iommu/omap-iovmm.c | 791 --
include/linux/omap-iommu.h | 37 +-
7 files changed, 8 insertions(+), 953 deletions(-)
delete mode 100644 drivers/iommu/omap-iovmm.c
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index d260605..a1f0fad 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -143,16 +143,12 @@ config OMAP_IOMMU
depends on ARCH_OMAP2PLUS
select IOMMU_API
-config OMAP_IOVMM
- tristate OMAP IO Virtual Memory Manager Support
- depends on OMAP_IOMMU
-
config OMAP_IOMMU_DEBUG
- tristate Export OMAP IOMMU/IOVMM internals in DebugFS
- depends on OMAP_IOVMM DEBUG_FS
+ tristate Export OMAP IOMMU internals in DebugFS
+ depends on DEBUG_FS
This module is relevant only when OMAP_IOMMU is enabled, so this should
be depends on OMAP_IOMMU DEBUG_FS. The dependency is inherent before
through OMAP_IOVMM. Otherwise, this module can be built by itself and
results in some build errors.
Oops, my bad. I'll fix that in v2.
help
Select this to see extensive information about
- the internal state of OMAP IOMMU/IOVMM in debugfs.
+ the internal state of OMAP IOMMU in debugfs.
Say N unless you know you need this.
[snip]
diff --git a/drivers/iommu/omap-iommu.h b/drivers/iommu/omap-iommu.h
index ea920c3..36a85f3 100644
--- a/drivers/iommu/omap-iommu.h
+++ b/drivers/iommu/omap-iommu.h
@@ -46,9 +46,6 @@ struct omap_iommu {
int nr_tlb_entries;
- struct list_headmmap;
- struct mutexmmap_lock; /* protect mmap */
-
void *ctx; /* iommu context: registres saved area */
u32 da_start;
u32 da_end;
With the removal of omap-iovmm, the da_start and da_end can also be
removed. No need to block this patch for that, it can be done in a
separate patch.
I'll remove the fields from struct omap_iommu in v2. I'll also remove them
from the platform data, but I'll need to do so in a separate patch, as arch/
code needs to be touched as well.
--
Regards,
Laurent Pinchart
--
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: AM3517 fails to boot 3.16-rc5 device tree kernel
On Fri, Jul 18, 2014 at 1:38 AM, Tony Lindgren t...@atomide.com wrote: * mwelling mwell...@emacinc.com [140717 16:42]: I am in the process of porting a device tree compatible version of the linux kernel to a AM3517 based device. First I tried 3.10.x and the device tree port appeared to be incomplete. Neither the LCD or Ethernet were supported. Next I tried 3.14.x and the Ethernet driver appeared to work but still no LCD support. Lastly I tried 3.16-rc5 and found that the kernel hangs in early boot without any messages from the serial COM. For device tree based booting on omap3 I would user v.16-rc4 or later. There have been multiple issues fixed over past year and PM is working finally at least for 36xx/37xx. And we do have the DSS panels finally working too. I was using the omap2plus_defconfig and the am3517-evm.dtb from each kernel build. Is there any reason why the kernel would start hanging with the newest release? No reason that I can think of. AFAIK 3517 has been booting in the test farms just fine? Can you please enable debug_ll + earlyprintk and pass also earlyprintk in the kernel cmdline? I will try this. Are there any versions where the LCD output works? Starting with v3.16-rc1 you should get the LCD working for panel-dpi based devices. Most of them actually are actually ls037v3dw01, so see omap3-panel-sharp-ls037v7dw01.dtsi and omap3-evm-common.dtsi variants if you have similar setup. Looking at the 3.16-rc5 test results just posted it is supposed to be working but I have not been able to replicate this. Any suggestions would be greatly appreciated. Hmm maybe double check your're booting device tree based kernel instead of legacy machine ID based kernel? The legacy booting should still work just fine and no changes has been made to it, but it will get removed shortly. I downloaded the version from the test results and it did boot. These are combining the uImage and dtb. How do you accomplish this? 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 CFT v2] arm: omap1: Migrate debug_ll macros to use 8250.S
The omap1's debug-macro.S is similar to the generic 8250 code. Compared to the 8520 code the omap1 macro automatically determines what UART to use based on breadcrumbs left by the bootloader and automatically copes with the eccentric register layout on OMAP7XX. This patch drops both these features and relies instead on the generic 8250 macros: 1. Dropping support for the bootloader breadcrumbs is identical to the way the migration was handled for OMAP2 (see 808b7e07464d...). 2. Support for OMAP7XX still exists but it must be configured by hand (DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime. Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org Cc: Russell King li...@arm.linux.org.uk Cc: Tony Lindgren t...@atomide.com Cc: Arnd Bergmann arnd.bergm...@linaro.org Cc: linux-omap@vger.kernel.org --- Notes: Changes since v1: * Removed !ARCH_OMAP7XX from the DEBUG_OMAP1UART1/2/3 options (thanks to Aaro Koskinen) arch/arm/Kconfig.debug | 57 +- arch/arm/mach-omap1/include/mach/debug-macro.S | 101 - 2 files changed, 56 insertions(+), 102 deletions(-) delete mode 100644 arch/arm/mach-omap1/include/mach/debug-macro.S diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 6f9664a..762b3ed 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -463,6 +463,30 @@ choice Say Y here if you want kernel low-level debugging support on TI-NSPIRE CX models. + config DEBUG_OMAP1UART1 + bool Kernel low-level debugging via OMAP1 UART1 + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART1. + + config DEBUG_OMAP1UART2 + bool Kernel low-level debugging via OMAP1 UART2 + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART2. + + config DEBUG_OMAP1UART3 + bool Kernel low-level debugging via OMAP1 UART3 + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART3. + config DEBUG_OMAP2UART1 bool OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 boards) depends on ARCH_OMAP2PLUS @@ -505,6 +529,30 @@ choice depends on ARCH_OMAP2PLUS select DEBUG_OMAP2PLUS_UART + config DEBUG_OMAP7XXUART1 + bool Kernel low-level debugging via OMAP730 UART1 + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART1. + + config DEBUG_OMAP7XXUART2 + bool Kernel low-level debugging via OMAP730 UART2 + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART2. + + config DEBUG_OMAP7XXUART3 + bool Kernel low-level debugging via OMAP730 UART3 + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART3. + config DEBUG_TI81XXUART1 bool Kernel low-level debugging messages via TI81XX UART1 (ti8148evm) depends on ARCH_OMAP2PLUS @@ -1106,6 +1154,9 @@ config DEBUG_UART_PHYS default 0xfe80 if ARCH_IOP32X default 0xffc02000 if DEBUG_SOCFPGA_UART default 0xffd82340 if ARCH_IOP13XX + default 0xfffb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1 + default 0xfffb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2 + default 0xfffb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3 default 0xfff36000 if DEBUG_HIGHBANK_UART default 0xf700 if ARCH_IOP33X depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \ @@ -1173,6 +1224,9 @@ config DEBUG_UART_VIRT default 0xfef0 if ARCH_IXP4XX !CPU_BIG_ENDIAN default 0xfef3 if ARCH_IXP4XX CPU_BIG_ENDIAN default 0xfef36000 if DEBUG_HIGHBANK_UART + default 0xfefb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1 + default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2 + default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3 default
Re: AM3517 fails to boot 3.16-rc5 device tree kernel
On Fri, Jul 18, 2014 at 09:40:48AM -0500, Michael Welling wrote: On Fri, Jul 18, 2014 at 1:38 AM, Tony Lindgren t...@atomide.com wrote: * mwelling mwell...@emacinc.com [140717 16:42]: I am in the process of porting a device tree compatible version of the linux kernel to a AM3517 based device. First I tried 3.10.x and the device tree port appeared to be incomplete. Neither the LCD or Ethernet were supported. Next I tried 3.14.x and the Ethernet driver appeared to work but still no LCD support. Lastly I tried 3.16-rc5 and found that the kernel hangs in early boot without any messages from the serial COM. For device tree based booting on omap3 I would user v.16-rc4 or later. There have been multiple issues fixed over past year and PM is working finally at least for 36xx/37xx. And we do have the DSS panels finally working too. I was using the omap2plus_defconfig and the am3517-evm.dtb from each kernel build. Is there any reason why the kernel would start hanging with the newest release? No reason that I can think of. AFAIK 3517 has been booting in the test farms just fine? Can you please enable debug_ll + earlyprintk and pass also earlyprintk in the kernel cmdline? I will try this. Adding the earlyprintk did not work. It still hangs without any messages. Are there any versions where the LCD output works? Starting with v3.16-rc1 you should get the LCD working for panel-dpi based devices. Most of them actually are actually ls037v3dw01, so see omap3-panel-sharp-ls037v7dw01.dtsi and omap3-evm-common.dtsi variants if you have similar setup. Looking at the 3.16-rc5 test results just posted it is supposed to be working but I have not been able to replicate this. Any suggestions would be greatly appreciated. Hmm maybe double check your're booting device tree based kernel instead of legacy machine ID based kernel? The legacy booting should still work just fine and no changes has been made to it, but it will get removed shortly. How do you determine which you are booting? I downloaded the version from the test results and it did boot. These are combining the uImage and dtb. How do you accomplish this? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] tty: serial: 8250 core: add runtime pm
On Fri, Jul 18, 2014 at 10:35:10AM +0200, Sebastian Andrzej Siewior wrote:
On 07/17/2014 06:18 PM, Felipe Balbi wrote:
No, this is okay. If you look, it checks for up-ier
UART_IER_THRI. On the second invocation it will see that this
bit is already set and therefore won't call get_sync() for the
second time. That bit is removed in the _stop_tx() path.
oh, right. But that's actually unnecessary. Calling
pm_runtime_get() multiple times will just increment the usage
counter multiple times, which means you can call __stop_tx()
multiple times too and everything gets balanced, right ?
No. start_tx() will be called multiple times but only the first
invocation invoke pm_runtime_get(). Now I noticed that I forgot to
right, but that's unnecessary. You can pm_runtime_get() every time
start_tx() is called. Just make sure to put everytime stop_tx() is
called too.
remove pm_runtime_put_autosuspend() at the bottom of it. But you get
the idea right?
pm_get() on the while the UART_IER_THRI is not yet set. pm_put() once
the fifo is completely empty.
Do you have other ideas? It doesn't look like this is exported at
all. If we call _stop_tx() right away, then we have 64 bytes in
the TX fifo in the worst case. They should be gone soon but the
HW-flow control may delay it (in theory for a long time)).
this can be problematic, specially for OMAP which can go into OFF
while idle. Whatever is in the FIFO would get lost. It seems like
omap-serial solved this within transmit_chars().
No, it didn't.
See how transmit_chars() is called from within IRQ handler with
clocks enabled then it conditionally calls serial_omap_stop_tx()
which will pm_runtime_get_sync() - do_the_harlem_shake() -
pm_runtime_put_autosuspend(). That leaves one unbalanced
pm_runtime_get() which is balanced when we're exitting the IRQ
handler.
omap-serial and the 8250 do the following on tx path:
- start_tx()
- sets UART_IER_THRI. This will generate an interrupt once the FIFO
is empty.
- interrupt, notices the empty fifo, invokes serial8250_start_tx()/
transmit_chars().
Both have a while loop that fills the FIFO. This loop is left once
the tty-buffer is empty (uart_circ_empty() is true) or the FIFO full.
Lets say you filled 64 bytes into the FIFO and then left because your
FIFO is full and tty-buffer is empty. That means you will invoke
serial_omap_stop_tx() and remove UART_IER_THRI bit.
This is okay because you are not interested in further FIFO empty
interrupts because you don't have any TX-bytes to be sent. However,
once you leave the transmit_chars() you leave serial_omap_irq() which
does the last pm_put(). That means you have data in the TX FIFO that is
about to be sent and the device is in auto-suspend.
This is fine as long as the timeout is greater then the time required
for the data be sent (plus assuming HW-float control does not stall it
for too long) so nobody notices a thing.
the time is set to -1 by default. I guess this only works because nobody
has ever tested long transfers with slow baud rates :-p
For that reason I added the hack / #if0 block in the 8250 driver. To
ensure we do not disable the TX-FIFO-empty interrupt even if there is
nothing to send. Instead we enter serial8250_tx_chars() once again with
empty FIFO and empty tty-buffer and will invoke _stop_tx() which also
finally does the pm_put().
That is the plan. The problem I have is how to figure out that the
device is using auto-suspend. If I don't then I would have to remove
the #if0 block and that would mean for everybody an extra interrupt
(which I wanted to avoid).
looks like the closest you have is:
if (pm_runtime_autosuspend_expiration(dev) 0)
foo();
Another possibility would be to implement the -runtime_idle() callback
and only return 0 if fifo is empty, otherwise return -EAGAIN ? then, if
the autosuspend timer expires, -runtime_idle gets called and you can do
the right thing depending on fifo empty or not.
Take a look at
drivers/usb/core/driver.c::usb_runtime_{idle,resume,suspend} for
examples. That seems to work pretty well.
This seems work fine and dandy without DMA, but for DMA work, I
think we need to make sure this IP stays powered until we get DMA
completion callback. But that's future, I guess.
Yes, probably. That means one get at dma start, one put at dma complete
callback. And I assume we get that callbacks once the DMA transfer is
complete, not when the FIFO is empty :) So lets leave it to the future
for now…
k
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 4/5] tty: serial: 8250 core: add runtime pm
On 07/18/2014 11:31 AM, Felipe Balbi wrote: On Fri, Jul 18, 2014 at 10:35:10AM +0200, Sebastian Andrzej Siewior wrote: On 07/17/2014 06:18 PM, Felipe Balbi wrote: No, this is okay. If you look, it checks for up-ier UART_IER_THRI. On the second invocation it will see that this bit is already set and therefore won't call get_sync() for the second time. That bit is removed in the _stop_tx() path. oh, right. But that's actually unnecessary. Calling pm_runtime_get() multiple times will just increment the usage counter multiple times, which means you can call __stop_tx() multiple times too and everything gets balanced, right ? No. start_tx() will be called multiple times but only the first invocation invoke pm_runtime_get(). Now I noticed that I forgot to right, but that's unnecessary. You can pm_runtime_get() every time start_tx() is called. Just make sure to put everytime stop_tx() is called too. The interface is asymmetric. start_tx() may be invoked multiple times for which only 1 interrupt will occur, and thus only invoke __stop_tx() once. Regards, Peter Hurley -- 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/5] tty: serial: 8250 core: add runtime pm
On Fri, Jul 18, 2014 at 11:53:21AM -0400, Peter Hurley wrote: On 07/18/2014 11:31 AM, Felipe Balbi wrote: On Fri, Jul 18, 2014 at 10:35:10AM +0200, Sebastian Andrzej Siewior wrote: On 07/17/2014 06:18 PM, Felipe Balbi wrote: No, this is okay. If you look, it checks for up-ier UART_IER_THRI. On the second invocation it will see that this bit is already set and therefore won't call get_sync() for the second time. That bit is removed in the _stop_tx() path. oh, right. But that's actually unnecessary. Calling pm_runtime_get() multiple times will just increment the usage counter multiple times, which means you can call __stop_tx() multiple times too and everything gets balanced, right ? No. start_tx() will be called multiple times but only the first invocation invoke pm_runtime_get(). Now I noticed that I forgot to right, but that's unnecessary. You can pm_runtime_get() every time start_tx() is called. Just make sure to put everytime stop_tx() is called too. The interface is asymmetric. start_tx() may be invoked multiple times for which only 1 interrupt will occur, and thus only invoke __stop_tx() once. alright, thanks for the info. -- balbi signature.asc Description: Digital signature
Re: AM3517 fails to boot 3.16-rc5 device tree kernel
On Fri, Jul 18, 2014 at 09:40:48AM -0500, Michael Welling wrote: On Fri, Jul 18, 2014 at 1:38 AM, Tony Lindgren t...@atomide.com wrote: * mwelling mwell...@emacinc.com [140717 16:42]: I am in the process of porting a device tree compatible version of the linux kernel to a AM3517 based device. First I tried 3.10.x and the device tree port appeared to be incomplete. Neither the LCD or Ethernet were supported. Next I tried 3.14.x and the Ethernet driver appeared to work but still no LCD support. Lastly I tried 3.16-rc5 and found that the kernel hangs in early boot without any messages from the serial COM. For device tree based booting on omap3 I would user v.16-rc4 or later. There have been multiple issues fixed over past year and PM is working finally at least for 36xx/37xx. And we do have the DSS panels finally working too. I was using the omap2plus_defconfig and the am3517-evm.dtb from each kernel build. Is there any reason why the kernel would start hanging with the newest release? No reason that I can think of. AFAIK 3517 has been booting in the test farms just fine? Can you please enable debug_ll + earlyprintk and pass also earlyprintk in the kernel cmdline? I will try this. Are there any versions where the LCD output works? Starting with v3.16-rc1 you should get the LCD working for panel-dpi based devices. Most of them actually are actually ls037v3dw01, so see omap3-panel-sharp-ls037v7dw01.dtsi and omap3-evm-common.dtsi variants if you have similar setup. Looking at the 3.16-rc5 test results just posted it is supposed to be working but I have not been able to replicate this. Any suggestions would be greatly appreciated. Hmm maybe double check your're booting device tree based kernel instead of legacy machine ID based kernel? The legacy booting should still work just fine and no changes has been made to it, but it will get removed shortly. I downloaded the version from the test results and it did boot. These are combining the uImage and dtb. How do you accomplish this? It should be noted that when you try to boot the seperate zImage and dtb from the test build it fails. This replicates my issue. Here are the two binaries that I used: http://www.pwsan.com/omap/testlogs/test_v3.16-rc5/20140716140950/build_z/omap2plus_defconfig/zImage http://www.pwsan.com/omap/testlogs/test_v3.16-rc5/20140716140950/dtbs/am3517-evm.dtb Here is the boot attempt: U-Boot dhcp;set serverip 10.0.2.168;tftp 0x8200 zImage; tftp 0x8000 am3517-evm.dtb;bootz 0x8200 - 0x8000 BOOTP broadcast 1 DHCP client bound to address 10.0.3.33 Using DaVinci-EMAC device TFTP from server 10.0.2.168; our IP address is 10.0.3.33 Filename 'zImage'. Load address: 0x8200 Loading: # # # # ## 2 MiB/s done Bytes transferred = 4360800 (428a60 hex) Using DaVinci-EMAC device TFTP from server 10.0.2.168; our IP address is 10.0.3.33 Filename 'am3517-evm.dtb'. Load address: 0x8000 Loading: 1.8 MiB/s done Bytes transferred = 50145 (c3e1 hex) Kernel image @ 0x8200 [ 0x00 - 0x428a60 ] ## Flattened Device Tree blob at 8000 Booting using the fdt blob at 0x8000 Loading Device Tree to 9ff05000, end 9ff143e0 ... OK Starting kernel ... Using the exact same boot sequence worked for 3.10 and 3.14. 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] iommu/omap: Remove virtual memory manager
On 07/18/2014 05:50 AM, Laurent Pinchart wrote:
Hi Suman,
Thank you for the review.
On Thursday 17 July 2014 10:53:03 Suman Anna wrote:
On 07/17/2014 06:09 AM, Laurent Pinchart wrote:
The OMAP3 ISP driver was the only user of the OMAP IOVMM API. Now that
is has been ported to the DMA API, remove the unused virtual memory
manager.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Joerg, could you please pick this patch up for v3.17 if possible ?
Need one minor change as below, otherwise patch is good.
drivers/iommu/Kconfig| 10 +-
drivers/iommu/Makefile | 1 -
drivers/iommu/omap-iommu-debug.c | 114 --
drivers/iommu/omap-iommu.c | 2 -
drivers/iommu/omap-iommu.h | 6 +-
drivers/iommu/omap-iovmm.c | 791 --
include/linux/omap-iommu.h | 37 +-
7 files changed, 8 insertions(+), 953 deletions(-)
delete mode 100644 drivers/iommu/omap-iovmm.c
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index d260605..a1f0fad 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -143,16 +143,12 @@ config OMAP_IOMMU
depends on ARCH_OMAP2PLUS
select IOMMU_API
-config OMAP_IOVMM
- tristate OMAP IO Virtual Memory Manager Support
- depends on OMAP_IOMMU
-
config OMAP_IOMMU_DEBUG
- tristate Export OMAP IOMMU/IOVMM internals in DebugFS
- depends on OMAP_IOVMM DEBUG_FS
+ tristate Export OMAP IOMMU internals in DebugFS
+ depends on DEBUG_FS
This module is relevant only when OMAP_IOMMU is enabled, so this should
be depends on OMAP_IOMMU DEBUG_FS. The dependency is inherent before
through OMAP_IOVMM. Otherwise, this module can be built by itself and
results in some build errors.
Oops, my bad. I'll fix that in v2.
help
Select this to see extensive information about
- the internal state of OMAP IOMMU/IOVMM in debugfs.
+ the internal state of OMAP IOMMU in debugfs.
Say N unless you know you need this.
[snip]
diff --git a/drivers/iommu/omap-iommu.h b/drivers/iommu/omap-iommu.h
index ea920c3..36a85f3 100644
--- a/drivers/iommu/omap-iommu.h
+++ b/drivers/iommu/omap-iommu.h
@@ -46,9 +46,6 @@ struct omap_iommu {
int nr_tlb_entries;
- struct list_headmmap;
- struct mutexmmap_lock; /* protect mmap */
-
void *ctx; /* iommu context: registres saved area */
u32 da_start;
u32 da_end;
With the removal of omap-iovmm, the da_start and da_end can also be
removed. No need to block this patch for that, it can be done in a
separate patch.
I'll remove the fields from struct omap_iommu in v2. I'll also remove them
from the platform data, but I'll need to do so in a separate patch, as arch/
code needs to be touched as well.
Yeah, that's the reason I said separate patch :)
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: [PATCH v2 0/3] iommu: Remove OMAP IOVMM driver
Hi Laurent, On 07/18/2014 05:49 AM, Laurent Pinchart wrote: Hello, The OMAP3 ISP driver was the only user of the OMAP IOVMM API. Now that is has been ported to the DMA API, remove the unused virtual memory manager. The removal is split in three patches to ease upstream merge. The first patch removes the omap-iovmm driver, the second patch removes setting of now unused platform data fields from arch code, and the last patch cleans up the platform data structure. Thanks for the revised series, it looks good. I have also tested the series on OMAP3, OMAP4 and OMAP5. For the changes in the entire series, Acked-by: Suman Anna s-a...@ti.com regards Suman I'd like to get at least the first patch merged in v3.17. To avoid splitting the series across three kernel versions, it would be nice to also merge at least the second patch for v3.17. If there's no risk of conflict everything could be merged in one go through the ARM SoC tree. Otherwise a stable branch with patch 1/3 will be needed to base the arch change on. Joerg, Tony, how would you like to proceed ? Changes compared to v1: - Fix OMAP_IOMMU_DEBUG dependency on OMAP_IOMMU - Remove omap_iommu da_start and da_end fields - Added patches 2/3 and 3/3 Laurent Pinchart (3): iommu/omap: Remove virtual memory manager ARM: omap: Don't set iommu pdata da_start and da_end fields iommu/omap: Remove platform data da_start and da_end fields arch/arm/mach-omap2/omap-iommu.c | 2 - arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 4 - arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 4 - drivers/iommu/Kconfig | 10 +- drivers/iommu/Makefile | 1 - drivers/iommu/omap-iommu-debug.c | 114 - drivers/iommu/omap-iommu.c | 13 - drivers/iommu/omap-iommu.h | 8 +- drivers/iommu/omap-iovmm.c | 791 - include/linux/omap-iommu.h | 37 +- include/linux/platform_data/iommu-omap.h | 6 - 11 files changed, 8 insertions(+), 982 deletions(-) delete mode 100644 drivers/iommu/omap-iovmm.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap dts changes for v3.17 merge window, part1
On Wed, Jul 16, 2014 at 05:55:58AM -0700, Tony Lindgren wrote: The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f: Linux 3.16-rc1 (2014-06-15 17:45:28 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.17/dt-part1 for you to fetch changes up to 3c9464ed75d6c15ee864da6d8f6a4cd3b0f2c934: ARM: DTS: omap5-uevm: Enable basic audio (McPDM - twl6040) (2014-07-15 00:21:25 -0700) First set of .dts changes for omaps for v3.17 merge window: - Enable irqchip crossbar interrupt mapping. These changes are based on an immutable irqchip branch set up by Jason Cooper to make it easier to merge the related .dts changes. - Removal of omap2 related static clock data that now comes from device tree. - Enabling of PHY regulators for various omaps - Enabling of PCIe for dra7 - Add support for am437x starterkit - Enable audio for for omap5 - Enable display and am335x-evmsk Merged, but: 1) There was a conflict in the qspi node of dra7.dtsi due to a fix to remove the interrupts property. It'd be nice to get these branches based on the fixes so that we don't see these conflicts (or at least get told about them). Besides, if we happen to have an older base in our branch than what had the fix, it'll bubble all the way up to Linus. 2) There was an add/add conflict in the dra7.dtsi file, due to new entries just being appended. Please keep these sorted on address to avoid that. -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
