Re: [PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators
Hi,
On Thu, Apr 24, 2014 at 6:08 AM, Anton Tikhomirov
av.tikhomi...@samsung.com wrote:
Hi,
Hi,
-Original Message-
From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
ow...@vger.kernel.org] On Behalf Of Vivek Gautam
Sent: Monday, April 21, 2014 9:17 PM
Facilitate getting required 3.3V and 1.0V VDD supply for
OHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
---
Based on 'usb-next' branch of Greg's usb tree.
drivers/usb/host/ohci-exynos.c | 47
1 file changed, 47 insertions(+)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
exynos.c
index 68588d8..e2e72a8 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
[snip]
static void exynos_ohci_phy_enable(struct platform_device *pdev)
@@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct
platform_device
*pdev)
exynos_ohci-otg = phy-otg;
}
+ exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+ if (IS_ERR(exynos_ohci-vdd33)) {
+ err = PTR_ERR(exynos_ohci-vdd33);
+ goto fail_regulator1;
+ }
+ err = regulator_enable(exynos_ohci-vdd33);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD33 supply\n);
+ goto fail_regulator1;
+ }
+
+ exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
+ if (IS_ERR(exynos_ohci-vdd10)) {
+ err = PTR_ERR(exynos_ohci-vdd10);
+ goto fail_regulator2;
+ }
+ err = regulator_enable(exynos_ohci-vdd10);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD10 supply\n);
+ goto fail_regulator2;
+ }
+
Do we need to skip regulator settings together with PHY configuration
in case of exynos5440?
skip_phy:
exynos_ohci-clk = devm_clk_get(pdev-dev, usbhost);
[snip]
@@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
struct platform_device *pdev= to_platform_device(dev);
+ int ret;
+
+ ret = regulator_enable(exynos_ohci-vdd33);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD33 supply\n);
+ return ret;
Not sure, but shall we continue resuming and do everything
we can in case of error? At least it will avoid
WARN_ON(clk-enable_count == 0) on next system suspend.
True, i will modify it.
On the other hand, if power is not applied to the controller,
register access in ohci_resume() may lead to undefined behavior.
What's your opinion?
AFA i think, it is obvious that the regulators would not work without
a VDD supply.
So the question is, do we have VDD LDOs available on all Exynos
systems for usb ?
From the schemata of Exynos5250 and Exynos5420 boards, i can see the
required VDD LDOs
for USB. Unfortunately at present i don't have a Exynos4* schemata.
If regulator is not a mandatory, then we can make it option similar to
what Jingoo has also suggested
in subsequent mail.
[snip]
--
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
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/3] usb: ohci-exynos: Make provision for vdd regulators
Hi Jingoo,
On Thu, Apr 24, 2014 at 6:56 AM, Jingoo Han jg1@samsung.com wrote:
On Thursday, April 24, 2014 9:33 AM, Jingoo Han wrote:
On Thursday, April 24, 2014 9:18 AM, Anton Tikhomirov wrote:
On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
Facilitate getting required 3.3V and 1.0V VDD supply for
OHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
---
Based on 'usb-next' branch of Greg's usb tree.
drivers/usb/host/ohci-exynos.c | 47
1 file changed, 47 insertions(+)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
exynos.c
index 68588d8..e2e72a8 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
[snip]
@@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device
*pdev)
exynos_ohci-otg = phy-otg;
}
+ exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+ if (IS_ERR(exynos_ohci-vdd33)) {
+ err = PTR_ERR(exynos_ohci-vdd33);
+ goto fail_regulator1;
+ }
+ err = regulator_enable(exynos_ohci-vdd33);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD33 supply\n);
+ goto fail_regulator1;
+ }
+
+ exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
+ if (IS_ERR(exynos_ohci-vdd10)) {
+ err = PTR_ERR(exynos_ohci-vdd10);
+ goto fail_regulator2;
+ }
+ err = regulator_enable(exynos_ohci-vdd10);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD10 supply\n);
+ goto fail_regulator2;
+ }
+
Do we need to skip regulator settings together with PHY configuration
in case of exynos5440?
Oh, right. In the case of exynos5440, regulator settings is not
necessary. Vivek, would you fix it in order skip regulator settings
in exynos5440? It also applies to ehci-exynos.
Sorry, in the case of exynos5440, this patch already skips
regulator settings.
In the case of exynos5440, there is no need to set PHY setting
and regulator setting.
Right, in case of exynos5440, we are skipping PHY setting and regulator setting.
Actually i had missed taking into account 5440, so just curious. Do we
really not need a regulator
settings for Exynos5440 ?
How about making regulator setting optional?
Then, regulator setting can be done, only when regulator
is supported.
True, so with Exynos5440 not needing the regulator, we should make the
regulator settings optional.
exynos_ohci_probe()
exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
if (IS_ERR(exynos_ohci-vdd33)) {
dev_err(pdev-dev, Failed to get VDD33 supply\n);
} else {
err = regulator_enable(exynos_ohci-vdd33);
if (err) {
dev_err(pdev-dev, Failed to enable VDD33
supply\n);
goto fail_regulator1;
}
}
exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
if (IS_ERR(exynos_ohci-vdd10)) {
dev_err(pdev-dev, Failed to get VDD10 supply\n);
} else {
err = regulator_enable(exynos_ohci-vdd10);
if (err) {
dev_err(pdev-dev, Failed to enable VDD10
supply\n);
goto fail_regulator2;
}
}
In this case, suspend/resume can be fixed as below.
exynos_ohci_suspend()
if (exynos_ohci-vdd10)
regulator_disable(exynos_ohci-vdd10);
if (exynos_ohci-vdd33)
regulator_disable(exynos_ohci-vdd33);
exynos_ohci_resume()
if (exynos_ohci-vdd33) {
ret = regulator_enable(exynos_ohci-vdd33);
if (ret) {
dev_err(dev, Failed to enable VDD33 supply\n);
return ret;
}
}
if (exynos_ohci-vdd10) {
ret = regulator_enable(exynos_ohci-vdd10);
if (ret) {
dev_err(dev, Failed to enable VDD10 supply\n);
return ret;
}
}
Thanks for the suggestion.
I will make the required changes, and post the patchset again.
[snip]
--
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
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: extcon-next regression ?
Hi, On Thu, Apr 24, 2014 at 02:31:29PM +0900, Chanwoo Choi wrote: On 04/24/2014 02:20 AM, Felipe Balbi wrote: Hi, On Wed, Apr 23, 2014 at 11:40:33AM -0500, Felipe Balbi wrote: Hi Chanwoo, I've been testing extcon-next to make sure USB3 on OMAP5 will work out of the box but I see a regression when I merge your tree on top of v3.15-rc2 + Tony's DT fixes. Here's what I see (trimmed): [1.805870] palmas 0-0048: Muxing GPIO 2, PWM 0, LED 0 [1.812516] [ cut here ] [1.817387] WARNING: CPU: 0 PID: 6 at include/linux/kref.h:47 kobject_get+0x64/0x78() [1.817691] mmcblk0boot1: unknown partition table [1.830601] Modules linked in: [1.833827] CPU: 0 PID: 6 Comm: kworker/u4:0 Tainted: GW 3.15.0-rc2-00041-g3019b77 #308 [1.84] Workqueue: deferwq deferred_probe_work_func [1.848728] mmcblk0boot0: unknown partition table [1.853928] [c0015110] (unwind_backtrace) from [c0011d6c] (show_stack+0x10/0x14) [1.862086] [c0011d6c] (show_stack) from [c05426b4] (dump_stack+0x84/0x9c) [1.869667] [c05426b4] (dump_stack) from [c0040928] (warn_slowpath_common+0x6c/0x90) [1.878181] [c0040928] (warn_slowpath_common) from [c00409e8] (warn_slowpath_null+0x1c/0x24) [1.887421] [c00409e8] (warn_slowpath_null) from [c02d50c4] (kobject_get+0x64/0x78) [1.895837] [c02d50c4] (kobject_get) from [c0350188] (device_add+0x18/0x520) [1.903629] [c0350188] (device_add) from [c0462a5c] (extcon_dev_register+0x48/0x104) [1.912145] [c0462a5c] (extcon_dev_register) from [c0462b44] (devm_extcon_dev_register+0x2c/0x68) [1.921847] [c0462b44] (devm_extcon_dev_register) from [c04630c0] (palmas_usb_probe+0x110/0x304) [1.931453] [c04630c0] (palmas_usb_probe) from [c0354284] (platform_drv_probe+0x18/0x48) [1.940333] [c0354284] (platform_drv_probe) from [c0352b0c] (driver_probe_device+0x110/0x22c) [1.949664] [c0352b0c] (driver_probe_device) from [c03511a0] (bus_for_each_drv+0x58/0x8c) [1.958634] [c03511a0] (bus_for_each_drv) from [c03529c8] (device_attach+0x74/0x8c) [1.967003] [c03529c8] (device_attach) from [c035206c] (bus_probe_device+0x88/0xb0) [1.975387] [c035206c] (bus_probe_device) from [c0350590] (device_add+0x420/0x520) [1.983678] [c0350590] (device_add) from [c045a310] (of_platform_device_create_pdata+0x6c/0x8c) [1.993155] [c045a310] (of_platform_device_create_pdata) from [c045a418] (of_platform_bus_create+0xdc/0x168) [2.003818] [c045a418] (of_platform_bus_create) from [c045a5cc] (of_platform_populate+0x5c/0xa0) [2.013399] [c045a5cc] (of_platform_populate) from [c0373c78] (palmas_i2c_probe+0x30c/0x584) [2.022606] [c0373c78] (palmas_i2c_probe) from [c0352b0c] (driver_probe_device+0x110/0x22c) [2.031722] [c0352b0c] (driver_probe_device) from [c03511a0] (bus_for_each_drv+0x58/0x8c) [2.040715] [c03511a0] (bus_for_each_drv) from [c03529c8] (device_attach+0x74/0x8c) [2.049098] [c03529c8] (device_attach) from [c035206c] (bus_probe_device+0x88/0xb0) [2.057482] [c035206c] (bus_probe_device) from [c0350590] (device_add+0x420/0x520) [2.065774] [c0350590] (device_add) from [c0424020] (i2c_new_device+0x12c/0x18c) [2.073885] [c0424020] (i2c_new_device) from [c0424980] (i2c_register_adapter+0x278/0x498) [2.082903] [c0424980] (i2c_register_adapter) from [c04275c0] (omap_i2c_probe+0x4a4/0x6d0) [2.091925] [c04275c0] (omap_i2c_probe) from [c0354284] (platform_drv_probe+0x18/0x48) [2.100582] [c0354284] (platform_drv_probe) from [c0352b0c] (driver_probe_device+0x110/0x22c) [2.109883] [c0352b0c] (driver_probe_device) from [c03511a0] (bus_for_each_drv+0x58/0x8c) [2.118823] [c03511a0] (bus_for_each_drv) from [c03529c8] (device_attach+0x74/0x8c) [2.127194] [c03529c8] (device_attach) from [c035206c] (bus_probe_device+0x88/0xb0) [2.135584] [c035206c] (bus_probe_device) from [c03524ac] (deferred_probe_work_func+0x64/0x94) [2.144975] [c03524ac] (deferred_probe_work_func) from [c0058c70] (process_one_work+0x1ac/0x4cc) [2.154545] [c0058c70] (process_one_work) from [c0059b10] (worker_thread+0x114/0x3b4) [2.163119] [c0059b10] (worker_thread) from [c005f6f0] (kthread+0xd4/0xf0) [2.170695] [c005f6f0] (kthread) from [c000e3c8] (ret_from_fork+0x14/0x2c) [2.178259] ---[ end trace 3006de6450234d28 ]--- [2.183081] kobject 'palmas_usb' (eca58c38): tried to add an uninitialized object, something is seriously wrong. [2.193731] CPU: 0 PID: 6 Comm: kworker/u4:0 Tainted: GW 3.15.0-rc2-00041-g3019b77 #308 [2.203201] Workqueue: deferwq deferred_probe_work_func [2.208687] [c0015110] (unwind_backtrace) from [c0011d6c] (show_stack+0x10/0x14) [2.216789] [c0011d6c] (show_stack) from [c05426b4]
Re: extcon-next regression ?
Hi, On Thu, Apr 24, 2014 at 02:35:44PM +0900, Chanwoo Choi wrote: Hi Felipe, Thanks for your test and review. On 04/24/2014 03:28 AM, Felipe Balbi wrote: Hi, On Wed, Apr 23, 2014 at 12:20:52PM -0500, Felipe Balbi wrote: I've been testing extcon-next to make sure USB3 on OMAP5 will work out of the box but I see a regression when I merge your tree on top of v3.15-rc2 + Tony's DT fixes. Here's what I see (trimmed): [1.805870] palmas 0-0048: Muxing GPIO 2, PWM 0, LED 0 [1.812516] [ cut here ] [1.817387] WARNING: CPU: 0 PID: 6 at include/linux/kref.h:47 kobject_get+0x64/0x78() [1.817691] mmcblk0boot1: unknown partition table [1.830601] Modules linked in: [1.833827] CPU: 0 PID: 6 Comm: kworker/u4:0 Tainted: GW 3.15.0-rc2-00041-g3019b77 #308 [1.84] Workqueue: deferwq deferred_probe_work_func [1.848728] mmcblk0boot0: unknown partition table [1.853928] [c0015110] (unwind_backtrace) from [c0011d6c] (show_stack+0x10/0x14) [1.862086] [c0011d6c] (show_stack) from [c05426b4] (dump_stack+0x84/0x9c) [1.869667] [c05426b4] (dump_stack) from [c0040928] (warn_slowpath_common+0x6c/0x90) [1.878181] [c0040928] (warn_slowpath_common) from [c00409e8] (warn_slowpath_null+0x1c/0x24) [1.887421] [c00409e8] (warn_slowpath_null) from [c02d50c4] (kobject_get+0x64/0x78) [1.895837] [c02d50c4] (kobject_get) from [c0350188] (device_add+0x18/0x520) [1.903629] [c0350188] (device_add) from [c0462a5c] (extcon_dev_register+0x48/0x104) [1.912145] [c0462a5c] (extcon_dev_register) from [c0462b44] (devm_extcon_dev_register+0x2c/0x68) [1.921847] [c0462b44] (devm_extcon_dev_register) from [c04630c0] (palmas_usb_probe+0x110/0x304) [1.931453] [c04630c0] (palmas_usb_probe) from [c0354284] (platform_drv_probe+0x18/0x48) [1.940333] [c0354284] (platform_drv_probe) from [c0352b0c] (driver_probe_device+0x110/0x22c) [1.949664] [c0352b0c] (driver_probe_device) from [c03511a0] (bus_for_each_drv+0x58/0x8c) [1.958634] [c03511a0] (bus_for_each_drv) from [c03529c8] (device_attach+0x74/0x8c) [1.967003] [c03529c8] (device_attach) from [c035206c] (bus_probe_device+0x88/0xb0) [1.975387] [c035206c] (bus_probe_device) from [c0350590] (device_add+0x420/0x520) [1.983678] [c0350590] (device_add) from [c045a310] (of_platform_device_create_pdata+0x6c/0x8c) [1.993155] [c045a310] (of_platform_device_create_pdata) from [c045a418] (of_platform_bus_create+0xdc/0x168) [2.003818] [c045a418] (of_platform_bus_create) from [c045a5cc] (of_platform_populate+0x5c/0xa0) [2.013399] [c045a5cc] (of_platform_populate) from [c0373c78] (palmas_i2c_probe+0x30c/0x584) [2.022606] [c0373c78] (palmas_i2c_probe) from [c0352b0c] (driver_probe_device+0x110/0x22c) [2.031722] [c0352b0c] (driver_probe_device) from [c03511a0] (bus_for_each_drv+0x58/0x8c) [2.040715] [c03511a0] (bus_for_each_drv) from [c03529c8] (device_attach+0x74/0x8c) [2.049098] [c03529c8] (device_attach) from [c035206c] (bus_probe_device+0x88/0xb0) [2.057482] [c035206c] (bus_probe_device) from [c0350590] (device_add+0x420/0x520) [2.065774] [c0350590] (device_add) from [c0424020] (i2c_new_device+0x12c/0x18c) [2.073885] [c0424020] (i2c_new_device) from [c0424980] (i2c_register_adapter+0x278/0x498) [2.082903] [c0424980] (i2c_register_adapter) from [c04275c0] (omap_i2c_probe+0x4a4/0x6d0) [2.091925] [c04275c0] (omap_i2c_probe) from [c0354284] (platform_drv_probe+0x18/0x48) [2.100582] [c0354284] (platform_drv_probe) from [c0352b0c] (driver_probe_device+0x110/0x22c) [2.109883] [c0352b0c] (driver_probe_device) from [c03511a0] (bus_for_each_drv+0x58/0x8c) [2.118823] [c03511a0] (bus_for_each_drv) from [c03529c8] (device_attach+0x74/0x8c) [2.127194] [c03529c8] (device_attach) from [c035206c] (bus_probe_device+0x88/0xb0) [2.135584] [c035206c] (bus_probe_device) from [c03524ac] (deferred_probe_work_func+0x64/0x94) [2.144975] [c03524ac] (deferred_probe_work_func) from [c0058c70] (process_one_work+0x1ac/0x4cc) [2.154545] [c0058c70] (process_one_work) from [c0059b10] (worker_thread+0x114/0x3b4) [2.163119] [c0059b10] (worker_thread) from [c005f6f0] (kthread+0xd4/0xf0) [2.170695] [c005f6f0] (kthread) from [c000e3c8] (ret_from_fork+0x14/0x2c) [2.178259] ---[ end trace 3006de6450234d28 ]--- [2.183081] kobject 'palmas_usb' (eca58c38): tried to add an uninitialized object, something is seriously wrong. [2.193731] CPU: 0 PID: 6 Comm: kworker/u4:0 Tainted: GW 3.15.0-rc2-00041-g3019b77 #308 [2.203201] Workqueue: deferwq deferred_probe_work_func [2.208687] [c0015110] (unwind_backtrace) from [c0011d6c] (show_stack+0x10/0x14) [2.216789] [c0011d6c] (show_stack)
[PATCH v3] gpio: omap: implement get_direction
From: Yegor Yefremov yegorsli...@googlemail.com
This patch implements gpio_chip's get_direction() routine, that
lets other drivers get particular GPIOs direction using
struct gpio_desc.
Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
Acked-by: Javier Martinez Canillas jav...@dowhile0.org
---
Changes:
v3: get rid of _get_gpio_direction() (Linus Walleij)
v2: rework return value calculation
drivers/gpio/gpio-omap.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 19b886c..62c12e4 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -27,6 +27,7 @@
#include linux/irqdomain.h
#include linux/irqchip/chained_irq.h
#include linux/gpio.h
+#include linux/bitops.h
#include linux/platform_data/gpio-omap.h
#define OFF_MODE 1
@@ -936,6 +937,21 @@ static inline void mpuio_init(struct gpio_bank *bank)
/*-*/
+static int gpio_get_direction(struct gpio_chip *chip, unsigned offset)
+{
+ struct gpio_bank *bank;
+ unsigned long flags;
+ void __iomem *reg;
+ int dir;
+
+ bank = container_of(chip, struct gpio_bank, chip);
+ reg = bank-base + bank-regs-direction;
+ spin_lock_irqsave(bank-lock, flags);
+ dir = !!(readl_relaxed(reg) BIT(offset));
+ spin_unlock_irqrestore(bank-lock, flags);
+ return dir;
+}
+
static int gpio_input(struct gpio_chip *chip, unsigned offset)
{
struct gpio_bank *bank;
@@ -1092,6 +1108,7 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
*/
bank-chip.request = omap_gpio_request;
bank-chip.free = omap_gpio_free;
+ bank-chip.get_direction = gpio_get_direction;
bank-chip.direction_input = gpio_input;
bank-chip.get = gpio_get;
bank-chip.direction_output = gpio_output;
--
1.7.7
--
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/3] usb: ohci-exynos: Make provision for vdd regulators
On Thursday, April 24, 2014 3:40 PM, Vivek Gautam wrote:
On Thu, Apr 24, 2014 at 6:56 AM, Jingoo Han jg1@samsung.com wrote:
On Thursday, April 24, 2014 9:33 AM, Jingoo Han wrote:
On Thursday, April 24, 2014 9:18 AM, Anton Tikhomirov wrote:
On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
Facilitate getting required 3.3V and 1.0V VDD supply for
OHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
---
Based on 'usb-next' branch of Greg's usb tree.
drivers/usb/host/ohci-exynos.c | 47
1 file changed, 47 insertions(+)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
exynos.c
index 68588d8..e2e72a8 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
[snip]
@@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device
*pdev)
exynos_ohci-otg = phy-otg;
}
+ exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+ if (IS_ERR(exynos_ohci-vdd33)) {
+ err = PTR_ERR(exynos_ohci-vdd33);
+ goto fail_regulator1;
+ }
+ err = regulator_enable(exynos_ohci-vdd33);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD33 supply\n);
+ goto fail_regulator1;
+ }
+
+ exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
+ if (IS_ERR(exynos_ohci-vdd10)) {
+ err = PTR_ERR(exynos_ohci-vdd10);
+ goto fail_regulator2;
+ }
+ err = regulator_enable(exynos_ohci-vdd10);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD10 supply\n);
+ goto fail_regulator2;
+ }
+
Do we need to skip regulator settings together with PHY configuration
in case of exynos5440?
Oh, right. In the case of exynos5440, regulator settings is not
necessary. Vivek, would you fix it in order skip regulator settings
in exynos5440? It also applies to ehci-exynos.
Sorry, in the case of exynos5440, this patch already skips
regulator settings.
In the case of exynos5440, there is no need to set PHY setting
and regulator setting.
Right, in case of exynos5440, we are skipping PHY setting and regulator
setting.
Actually i had missed taking into account 5440, so just curious. Do we
really not need a regulator
settings for Exynos5440 ?
To be more specific, there is no regulator on ssdk5440 board
which is the Exynos5440-based board.
Best regards,
Jingoo Han
How about making regulator setting optional?
Then, regulator setting can be done, only when regulator
is supported.
True, so with Exynos5440 not needing the regulator, we should make the
regulator settings optional.
[.]
Thanks for the suggestion.
I will make the required changes, and post the patchset again.
OK, I see.
Thank you for accepting my suggestion.
Best regards,
Jingoo Han
--
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] gpio: do not set up hardware for IRQ_TYPE_NONE
On 04/23/2014 05:50 PM, Linus Walleij wrote: Some GPIO irqchip drivers exploit the irqdomain mapping function to set up the IRQ default type in the hardware, make sure that if we pass IRQ_TYPE_NONE, no hardware setup whatsoever takes place (this should be the norm) until later when the IRQ gets utilized. Cc: Nishanth Menon n...@ti.com Cc: Peter Ujfalusi peter.ujfal...@ti.com Cc: Ezequiel Garcia ezequiel.gar...@free-electrons.com Cc: Javier Martinez Canillas jav...@dowhile0.org Cc: Tony Lindgren t...@atomide.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: linux-omap linux-omap@vger.kernel.org Signed-off-by: Linus Walleij linus.wall...@linaro.org --- TI folks: can you provide a Tested-by tag if this makes your OMAPs work? I am pretty sure the other platforms will be unaffected, if they aren't I will switch them over to react to IRQ_TYPE_DEFAULT. --- drivers/gpio/gpiolib.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) Thanks: Tested-by: Peter Ujfalusi peter.ujfal...@ti.com diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index ee1819fdcf35..97d173e9aa2d 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -1409,7 +1409,12 @@ static int gpiochip_irq_map(struct irq_domain *d, unsigned int irq, #else irq_set_noprobe(irq); #endif - irq_set_irq_type(irq, chip-irq_default_type); + /* + * No set-up of the hardware will happen if IRQ_TYPE_NONE + * is passed as default type. + */ + if (chip-irq_default_type != IRQ_TYPE_NONE) + irq_set_irq_type(irq, chip-irq_default_type); return 0; } @@ -1490,7 +1495,8 @@ static void gpiochip_irqchip_remove(struct gpio_chip *gpiochip) * @first_irq: if not dynamically assigned, the base (first) IRQ to * allocate gpiochip irqs from * @handler: the irq handler to use (often a predefined irq core function) - * @type: the default type for IRQs on this irqchip + * @type: the default type for IRQs on this irqchip, pass IRQ_TYPE_NONE + * to have the core avoid setting up any default type in the hardware. * * This function closely associates a certain irqchip with a certain * gpiochip, providing an irq domain to translate the local IRQs to -- 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
[RESEND] dmaengine: edma: Add channel number to debug prints
It helps to identify issues if we have some information regarding to the
channel which the event is associated.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Joel Fernandes jo...@ti.com
---
Hi Vinod,
rebased on:
git://git.infradead.org/users/vkoul/slave-dma.git next
On top of:
406efb1a745c dmaengine: edma: No need save/restore interrupt flags during...
Regards,
Peter
drivers/dma/edma.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index fa87fd52b0ad..473155d34d7b 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -183,7 +183,8 @@ static void edma_execute(struct edma_chan *echan)
}
if (edesc-processed = MAX_NR_SG) {
- dev_dbg(dev, first transfer starting %d\n, echan-ch_num);
+ dev_dbg(dev, first transfer starting on channel %d\n,
+ echan-ch_num);
edma_start(echan-ch_num);
} else {
dev_dbg(dev, chan: %d: completed %d elements, resuming\n,
@@ -197,7 +198,7 @@ static void edma_execute(struct edma_chan *echan)
* MAX_NR_SG
*/
if (echan-missed) {
- dev_dbg(dev, missed event in execute detected\n);
+ dev_dbg(dev, missed event on channel %d\n, echan-ch_num);
edma_clean_channel(echan-ch_num);
edma_stop(echan-ch_num);
edma_start(echan-ch_num);
@@ -779,7 +780,7 @@ static int edma_alloc_chan_resources(struct dma_chan *chan)
echan-alloced = true;
echan-slot[0] = echan-ch_num;
- dev_dbg(dev, allocated channel for %u:%u\n,
+ dev_dbg(dev, allocated channel %d for %u:%u\n, echan-ch_num,
EDMA_CTLR(echan-ch_num), EDMA_CHAN_SLOT(echan-ch_num));
return 0;
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: extcon-next regression ?
Hi, On 04/24/2014 03:47 PM, Felipe Balbi wrote: Hi, On Thu, Apr 24, 2014 at 02:35:44PM +0900, Chanwoo Choi wrote: Hi Felipe, Thanks for your test and review. On 04/24/2014 03:28 AM, Felipe Balbi wrote: Hi, On Wed, Apr 23, 2014 at 12:20:52PM -0500, Felipe Balbi wrote: I've been testing extcon-next to make sure USB3 on OMAP5 will work out of the box but I see a regression when I merge your tree on top of v3.15-rc2 + Tony's DT fixes. Here's what I see (trimmed): [1.805870] palmas 0-0048: Muxing GPIO 2, PWM 0, LED 0 [1.812516] [ cut here ] [1.817387] WARNING: CPU: 0 PID: 6 at include/linux/kref.h:47 kobject_get+0x64/0x78() [1.817691] mmcblk0boot1: unknown partition table [1.830601] Modules linked in: [1.833827] CPU: 0 PID: 6 Comm: kworker/u4:0 Tainted: GW 3.15.0-rc2-00041-g3019b77 #308 [1.84] Workqueue: deferwq deferred_probe_work_func [1.848728] mmcblk0boot0: unknown partition table [1.853928] [c0015110] (unwind_backtrace) from [c0011d6c] (show_stack+0x10/0x14) [1.862086] [c0011d6c] (show_stack) from [c05426b4] (dump_stack+0x84/0x9c) [1.869667] [c05426b4] (dump_stack) from [c0040928] (warn_slowpath_common+0x6c/0x90) [1.878181] [c0040928] (warn_slowpath_common) from [c00409e8] (warn_slowpath_null+0x1c/0x24) [1.887421] [c00409e8] (warn_slowpath_null) from [c02d50c4] (kobject_get+0x64/0x78) [1.895837] [c02d50c4] (kobject_get) from [c0350188] (device_add+0x18/0x520) [1.903629] [c0350188] (device_add) from [c0462a5c] (extcon_dev_register+0x48/0x104) [1.912145] [c0462a5c] (extcon_dev_register) from [c0462b44] (devm_extcon_dev_register+0x2c/0x68) [1.921847] [c0462b44] (devm_extcon_dev_register) from [c04630c0] (palmas_usb_probe+0x110/0x304) [1.931453] [c04630c0] (palmas_usb_probe) from [c0354284] (platform_drv_probe+0x18/0x48) [1.940333] [c0354284] (platform_drv_probe) from [c0352b0c] (driver_probe_device+0x110/0x22c) [1.949664] [c0352b0c] (driver_probe_device) from [c03511a0] (bus_for_each_drv+0x58/0x8c) [1.958634] [c03511a0] (bus_for_each_drv) from [c03529c8] (device_attach+0x74/0x8c) [1.967003] [c03529c8] (device_attach) from [c035206c] (bus_probe_device+0x88/0xb0) [1.975387] [c035206c] (bus_probe_device) from [c0350590] (device_add+0x420/0x520) [1.983678] [c0350590] (device_add) from [c045a310] (of_platform_device_create_pdata+0x6c/0x8c) [1.993155] [c045a310] (of_platform_device_create_pdata) from [c045a418] (of_platform_bus_create+0xdc/0x168) [2.003818] [c045a418] (of_platform_bus_create) from [c045a5cc] (of_platform_populate+0x5c/0xa0) [2.013399] [c045a5cc] (of_platform_populate) from [c0373c78] (palmas_i2c_probe+0x30c/0x584) [2.022606] [c0373c78] (palmas_i2c_probe) from [c0352b0c] (driver_probe_device+0x110/0x22c) [2.031722] [c0352b0c] (driver_probe_device) from [c03511a0] (bus_for_each_drv+0x58/0x8c) [2.040715] [c03511a0] (bus_for_each_drv) from [c03529c8] (device_attach+0x74/0x8c) [2.049098] [c03529c8] (device_attach) from [c035206c] (bus_probe_device+0x88/0xb0) [2.057482] [c035206c] (bus_probe_device) from [c0350590] (device_add+0x420/0x520) [2.065774] [c0350590] (device_add) from [c0424020] (i2c_new_device+0x12c/0x18c) [2.073885] [c0424020] (i2c_new_device) from [c0424980] (i2c_register_adapter+0x278/0x498) [2.082903] [c0424980] (i2c_register_adapter) from [c04275c0] (omap_i2c_probe+0x4a4/0x6d0) [2.091925] [c04275c0] (omap_i2c_probe) from [c0354284] (platform_drv_probe+0x18/0x48) [2.100582] [c0354284] (platform_drv_probe) from [c0352b0c] (driver_probe_device+0x110/0x22c) [2.109883] [c0352b0c] (driver_probe_device) from [c03511a0] (bus_for_each_drv+0x58/0x8c) [2.118823] [c03511a0] (bus_for_each_drv) from [c03529c8] (device_attach+0x74/0x8c) [2.127194] [c03529c8] (device_attach) from [c035206c] (bus_probe_device+0x88/0xb0) [2.135584] [c035206c] (bus_probe_device) from [c03524ac] (deferred_probe_work_func+0x64/0x94) [2.144975] [c03524ac] (deferred_probe_work_func) from [c0058c70] (process_one_work+0x1ac/0x4cc) [2.154545] [c0058c70] (process_one_work) from [c0059b10] (worker_thread+0x114/0x3b4) [2.163119] [c0059b10] (worker_thread) from [c005f6f0] (kthread+0xd4/0xf0) [2.170695] [c005f6f0] (kthread) from [c000e3c8] (ret_from_fork+0x14/0x2c) [2.178259] ---[ end trace 3006de6450234d28 ]--- [2.183081] kobject 'palmas_usb' (eca58c38): tried to add an uninitialized object, something is seriously wrong. [2.193731] CPU: 0 PID: 6 Comm: kworker/u4:0 Tainted: GW 3.15.0-rc2-00041-g3019b77 #308 [2.203201] Workqueue: deferwq deferred_probe_work_func [2.208687] [c0015110] (unwind_backtrace) from [c0011d6c] (show_stack+0x10/0x14) [2.216789] [c0011d6c] (show_stack) from [c05426b4] (dump_stack+0x84/0x9c) [2.224357]
Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT
On 04/16/2014 07:05 PM, Joel Fernandes wrote: On 04/16/2014 07:59 AM, Peter Ujfalusi wrote: [..] If the dma-priority is missing we should assume lowest priority (0). The highest priority depends on the platform. For eDMA3 in AM335x it is three level. For designware controller you might have the range 0-8 as valid. The question is how to get this information into use? We can take the priority number in the core when the dma channel is requested and add field to struct dma_chan in order to store it and the DMA drivers could have access to it. How about Vinod's idea of extending dma_slave_config? Priority is similar to rest of the runtime setup dmaengine_slave_config() is meant to do. The dma_slave_config is prepared by the client drivers, so they would need to be updated to handle the priority for the DMA. This would lead to duplicated code - unless we have a small function in dmaengine core to fetch this information, but still all dmaengine clients would need to call that. IMHO it would be better to let the dmaengine core to take the priority for the channel when it has been asked so client drivers does not need to know about it. I still feel it is much cleaner to keep this out of DT and have audio driver configure the channel manually for higher priority. Because, AFAIK audio is the only device that uses slave DMA and needs higher priority. I'd imagine everyone else who needs high priority, have their own dedicated DMAC, so from that sense I don't see the priority mechanism being used a lot anywhere else but audio, so atleast we can rule out things like code duplication in other drivers. Priority can be set to a default of low for those drivers that don't configure the channel for priority. I'm also OK with EDMA driver configuring channel for higher priority manually for the Cyclic case like you did initially. So how should we go about this? I'm fine to select higher priority in the eDMA driver for now when a cyclic channel is configured and later when we have (if we ever have) generic way to handle DMA channel/transaction priority we can switch eDMA as well to use it. -- Péter -- 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] usb: musb_dsps: fix the exit routine for debugfs
Ok, thank you, I didn't notice the existing thread. On Wed, 23 Apr 2014 10:55:29 -0500 Felipe Balbi ba...@ti.com wrote: On Wed, Apr 23, 2014 at 05:39:43PM +0200, Olivier Gayot wrote: The following commit introduced the debugfs : 40f099e32c2a06bad7d75683421e30fcc74924cd Author: Markus Pargmann m...@pengutronix.de Date: Fri Jan 17 10:22:35 2014 +0100 usb: musb: dsps, debugfs files Unfortunately, a forgotten call to a cleanup function prevents the probing of musb in case of deferred probe. Because musb_init_controller() often retries and creates a new debugfs directory each time it is called, we need to remove that directory in case the initialization fails. Otherwise, the debugfs_create_dir() fails at subsequent calls because the directory already exists. Fixed by calling debugfs_remove_recursive() in the exit function. Signed-off-by: Olivier Gayot oga...@baylibre.com Cc: Markus Pargmann m...@pengutronix.de --- drivers/usb/musb/musb_dsps.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 3372ded..c3de0a5 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -471,6 +471,8 @@ static int dsps_musb_exit(struct musb *musb) del_timer_sync(glue-timer); + debugfs_remove_recursive(glue-dbgfs_root); + usb_phy_shutdown(musb-xceiv); return 0; First of all this commit is wrong, second of all I already have the proper commit: commit 0fca91b8a446d4a38b8f3d4772c4a8665ebcd7b2 Author: Daniel Mack zon...@gmail.com Date: Wed Apr 2 11:46:51 2014 +0200 usb: musb: dsps: move debugfs_remove_recursive() When the platform initialization fails due to missing resources, it will return -EPROBE_DEFER after dsps_musb_init() has been called. dsps_musb_init() calls dsps_musb_dbg_init() to allocate the debugfs nodes. At a later point in time, the probe will be retried, and dsps_musb_dbg_init() will be called again. debugfs_create_dir() will fail this time, as the node already exists, and so the entire device probe will fail with -ENOMEM. Fix this by moving debugfs_remove_recursive() from dsps_remove() to the plaform's exit function, so it will be cleanly torn down when the probe fails. It also feels more natural this way, as .exit is the counterpart to .init. Signed-off-by: Daniel Mack zon...@gmail.com Signed-off-by: Felipe Balbi ba...@ti.com diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 3372ded..e2fd263 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -470,8 +470,9 @@ static int dsps_musb_exit(struct musb *musb) struct dsps_glue *glue = dev_get_drvdata(dev-parent); del_timer_sync(glue-timer); - usb_phy_shutdown(musb-xceiv); + debugfs_remove_recursive(glue-dbgfs_root); + return 0; } @@ -708,8 +709,6 @@ static int dsps_remove(struct platform_device *pdev) pm_runtime_put(pdev-dev); pm_runtime_disable(pdev-dev); - debugfs_remove_recursive(glue-dbgfs_root); - return 0; } a pull request has already been sent to Greg, should be in v3.15-rc3 -- 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] clk: Add driver for Palmas clk32kg and clk32kgaudio clocks
Hi Mike,
On 04/03/2014 01:52 PM, Peter Ujfalusi wrote:
Palmas class of devices have either twl 32K clock outputs:
CLK32K_KG and CLK32K_KGAUDIO
or only one:
CLK32K_KG (TPS659039 for example)
Use separate compatible flags for the two 32K clock.
A system which needs or have only one of the 32k clock from
Palmas will need to add node(s) for each clock as separate section
in the dts file.
The two compatible property is:
ti,palmas-clk32kg for clk32kg clock
ti,palmas-clk32kgaudio for clk32kgaudio clock
Apart from the register control of the clocks - which is done via
the clock API there is a posibility to enable the external sleep
control.
See the documentation for more details.
Can you take a look at this and comment so I can resend it with
documentation/implementation separated.
Thanks,
Péter
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi,
Part of the driver is based on the v4 of palmas clock driver from
Laxman Dewangan, which can be found here:
https://lkml.org/lkml/2013/10/9/146
Since no updates followed after the comments and patches I have squashed my
updates to rewrite the original driver to be able to support more devices from
the Palmas family.
Regards,
Peter
.../devicetree/bindings/clock/clk-palmas.txt | 35 +++
drivers/clk/Kconfig| 7 +
drivers/clk/Makefile | 1 +
drivers/clk/clk-palmas.c | 307
+
include/dt-bindings/mfd/palmas.h | 18 ++
5 files changed, 368 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/clk-palmas.txt
create mode 100644 drivers/clk/clk-palmas.c
create mode 100644 include/dt-bindings/mfd/palmas.h
diff --git a/Documentation/devicetree/bindings/clock/clk-palmas.txt
b/Documentation/devicetree/bindings/clock/clk-palmas.txt
new file mode 100644
index ..4208886d834a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/clk-palmas.txt
@@ -0,0 +1,35 @@
+* Palmas 32KHz clocks *
+
+Palmas device has two clock output pins for 32KHz, KG and KG_AUDIO.
+
+This binding uses the common clock binding ./clock-bindings.txt.
+
+Required properties:
+- compatible : ti,palmas-clk32kg for clk32kg clock
+ ti,palmas-clk32kgaudio for clk32kgaudio clock
+- #clock-cells : shall be set to 0.
+
+Optional property:
+- ti,external-sleep-control: The external enable input pins controlled the
+ enable/disable of clocks. The external enable input pins ENABLE1,
+ ENABLE2 and NSLEEP. The valid values for the external pins are:
+ PALMAS_EXT_CONTROL_PIN_ENABLE1 for ENABLE1 pin
+ PALMAS_EXT_CONTROL_PIN_ENABLE2 for ENABLE2 pin
+ PALMAS_EXT_CONTROL_PIN_NSLEEP for NSLEEP pin
+ Option 0 or missing this property means the clock is enabled/disabled
+ via register access and these pins do not have any control.
+ The macros of external control pins for DTS is defined at
+ dt-bindings/mfd/palmas.h
+
+Example:
+ #include dt-bindings/mfd/palmas.h
+ ...
+ palmas: tps65913@58 {
+ ...
+ clk32kg: palmas_clk32k@0 {
+ compatible = ti,palmas-clk32kg;
+ #clock-cells = 0;
+ ti,external-sleep-control =
PALMAS_EXT_CONTROL_PIN_NSLEEP;
+ };
+ ...
+ };
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 6f56d3a4f010..a070b77a1e17 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -109,6 +109,13 @@ config COMMON_CLK_KEYSTONE
Supports clock drivers for Keystone based SOCs. These SOCs have
local
a power sleep control module that gate the clock to the IPs and PLLs.
+config COMMON_CLK_PALMAS
+ tristate Clock driver for TI Palmas devices
+ depends on MFD_PALMAS
+ ---help---
+ This driver supports TI Palmas devices 32KHz output KG and KG_AUDIO
+ using common clock framework.
+
source drivers/clk/qcom/Kconfig
endmenu
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 5f8a28735c96..d67214debc12 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
obj-$(CONFIG_ARCH_MOXART)+= clk-moxart.o
obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
obj-$(CONFIG_ARCH_NSPIRE)+= clk-nspire.o
+obj-$(CONFIG_COMMON_CLK_PALMAS) += clk-palmas.o
obj-$(CONFIG_CLK_PPC_CORENET)+= clk-ppc-corenet.o
obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
diff --git a/drivers/clk/clk-palmas.c b/drivers/clk/clk-palmas.c
new file mode 100644
index ..e2b7d3cade26
--- /dev/null
+++ b/drivers/clk/clk-palmas.c
@@ -0,0 +1,307 @@
+/*
+ * Clock driver for Palmas
Re: [PATCH 02/13] bluetooth: hci_ldisc: fix deadlock condition
Dear Felipe Balbi, On Wed, Apr 23, 2014 at 09:58:26AM -0500, Felipe Balbi wrote: LDISCs shouldn't call tty-ops-write() from within -write_wakeup(). -write_wakeup() is called with port lock taken and IRQs disabled, tty-ops-write() will try to acquire the same port lock and we will deadlock. Acked-by: Marcel Holtmann mar...@holtmann.org Reviewed-by: Peter Hurley pe...@hurleysoftware.com Reported-by: Huang Shijie b32...@freescale.com Signed-off-by: Felipe Balbi ba...@ti.com Tested-by: Andreas Bießmann andr...@biessmann.de on custom TI AM37xx board with 3.4.87. Therefore I vote for adding this to stable branches (at least 3.4). It applies with a slight line shifting (init_work is not available there). I wonder if you have seen my approach [1] to fix this deadlock. This stuff is quiet new to me. As I understood the work_queue has a bit more overhead than a tasklet. Therefore I implemented my fix with a tasklet. Would be great if one could shed some light on that. Best regards Andreas Bießmann [1] https://lkml.org/lkml/2014/4/16/425 --- drivers/bluetooth/hci_ldisc.c | 24 +++- drivers/bluetooth/hci_uart.h | 1 + 2 files changed, 20 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: ti: clk-7xx: Correct ABE DPLL configuration
Mike, Tero, On 04/03/2014 09:29 AM, Peter Ujfalusi wrote: On 04/02/2014 05:12 PM, Tero Kristo wrote: On 04/02/2014 04:48 PM, Peter Ujfalusi wrote: ABE DPLL frequency need to be lowered from 361267200 to 180633600 to facilitate the ATL requironments. The dpll_abe_m2x2_ck clock need to be set to double of ABE DPLL rate in order to have correct clocks for audio. Do you have some sort of TRM reference for this? The ATL's max divider is 32. For audio purpose the clock coming out from the ATL instance should be 128 * fs. It is only possible to have 44.1KHz sampling rate with ABE DPLL set to 361267200 or 180633600. Which means: The atl generated clock should be 128 * 44100 = 5644800 From ABE_DPLL 361267200 we would need to have 64 as divider (ATL can't do this). From the suggested ABE_DPLL of 180633600 we can use ATL divider of 32, which is the maximum it can do. So the reason for the change is to have ATLPCLK clock which can be used for audio in the future, the 361267200 is just too high. Tero: can I have your ack for this patch or do you have further concerns? Mike: do you want me to resend this patch? Thanks, Péter -Tero Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- drivers/clk/ti/clk-7xx.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c index f7e40734c819..19a55bf407dd 100644 --- a/drivers/clk/ti/clk-7xx.c +++ b/drivers/clk/ti/clk-7xx.c @@ -16,7 +16,7 @@ #include linux/clkdev.h #include linux/clk/ti.h -#define DRA7_DPLL_ABE_DEFFREQ361267200 +#define DRA7_DPLL_ABE_DEFFREQ180633600 #define DRA7_DPLL_GMAC_DEFFREQ10 @@ -322,6 +322,11 @@ int __init dra7xx_dt_clk_init(void) if (rc) pr_err(%s: failed to configure ABE DPLL!\n, __func__); +dpll_ck = clk_get_sys(NULL, dpll_abe_m2x2_ck); +rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ * 2); +if (rc) +pr_err(%s: failed to configure ABE DPLL m2x2!\n, __func__); + dpll_ck = clk_get_sys(NULL, dpll_gmac_ck); rc = clk_set_rate(dpll_ck, DRA7_DPLL_GMAC_DEFFREQ); if (rc) -- 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: [RESEND 0/3] mfd: twl6040: Updates for i2s speed and fix for chip deadlock
Lee, On 04/01/2014 04:44 PM, Peter Ujfalusi wrote: Hi, While looking into a report by Florian Vaussard [1] I have noticed couple of most likely unrelated issues: - all boards using twl6040 configures the i2c bus to 400KHz while twl6040 is set to 100KHz as default. - if I set the audpwron GPIO high [2] in the bootloader the i2c communication towards twl6040 will be broken - got confirmation from HW design teams that twl6040 can work on a bus with 400KHz even if after hard reset but it is optimal to swithc to 400KHz mode as soon as possible. The solution or these are: set the twl6040 to i2c fast mode with regmap patch Clear the INTID register right after we request the audpwron GPIO and set it to low. Do you want me to resend this series again? Thanks, Péter Generated on top of: git://git.linaro.org/people/lee.jones/mfd.git for-mfd-next Tested on PandaBoard, PandaBoardES, OMAP4-blaze (SDP) [1] http://www.spinics.net/lists/arm-kernel/msg310725.html [2] Command in u-boot to enable the audpwron on PandaBoards: gpio set 127 Regards, Peter --- Peter Ujfalusi (3): mfd: twl6040: Select i2c fast mode as default with regmap patch mfd: twl6040: Move register patching earlier in probe mfd: twl6040: Clear the interrupt ID register before requesting IRQ drivers/mfd/twl6040.c | 19 +-- include/linux/mfd/twl6040.h | 1 + 2 files changed, 14 insertions(+), 6 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] clk: Add clock driver for DRA7 ATL (Audio Tracking Logic)
Hi Mike, On 04/02/2014 04:55 PM, Peter Ujfalusi wrote: Hi, Audio Tracking Logic is designed to be used by HD Radio applications to synchronize the audio output clocks to the baseband clock. ATL can be also used to track errors between two reference clocks (BWS, AWS) and generate a modulated clock output which averages to some desired frequency. To be able to integrate the ATL provided clocks to the clock tree we need two types of DT binding: - DT clock nodes to represent the ATL clocks towards the CCF - binding for the ATL IP itself which is going to handle the hw configuration The reason for this type of setup is that ATL itself is a separate device in the SoC, it has it's own address space and clock domain. Other IPs can use the ATL generated clock as their functional clock (McASPs for example) and external components like audio codecs can also use the very same clock as their MCLK. With setup pm_runtime can handle the ATL clock on demand of it's use and all the IP which needs ATL clock can be sure that it is enabled for them. The first patch fixes the name of atl clkin3 node in dtsi file. Can you take a look at this series? Thanks, Péter Regards, Peter --- Peter Ujfalusi (3): ARM: dts: dra7xx-clocks: Correct name for atl clkin3 clock clk: Driver for DRA7 ATL (Audio Tracking Logic) ARM: DTS: dra7/dra7xx-clocks: ATL related changes .../devicetree/bindings/clock/ti/dra7-atl.txt | 97 +++ arch/arm/boot/dts/dra7.dtsi| 11 + arch/arm/boot/dts/dra7xx-clocks.dtsi | 38 +-- drivers/clk/ti/Makefile| 3 +- drivers/clk/ti/clk-7xx.c | 2 +- drivers/clk/ti/clk-dra7-atl.c | 313 + include/dt-bindings/clk/ti-dra7-atl.h | 40 +++ 7 files changed, 483 insertions(+), 21 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/ti/dra7-atl.txt create mode 100644 drivers/clk/ti/clk-dra7-atl.c create mode 100644 include/dt-bindings/clk/ti-dra7-atl.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
omap-serial: use mctrl_gpio helpers
This patch is based on Richard Genoud' patch adding generic GPIO support [1] and my patch adding get_direction() functionality to OMAP's GPIO driver [2]. So far RTS/DTR are working both as modem control outputs and RTS as RS-485 2-wire controller. CTS/DSR/DSR/RI are generating interrupts. Richard, Greg, what is the status of [1]? It seems like it will be available in 3.16 first? TODO: 1. remove rts_gpio from uart_omap_port 2. perhaps add rts_gpiod to uart_omap_port to avoid numerous invocations of rts_gpiod = mctrl_gpio_to_gpiod(up-gpios, UART_GPIO_RTS); 3. add device tree documentation Yegor [1] http://comments.gmane.org/gmane.linux.serial/13967 [2] http://www.spinics.net/lists/arm-kernel/msg325162.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
[RFC] tty: serial: omap: use mctrl_gpio helpers
From: Yegor Yefremov yegorsli...@googlemail.com
This patch permits to use GPIOs to control the CTS/RTS/DTR/DSR/DCD/RI
signals.
Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
---
drivers/tty/serial/Kconfig |1 +
drivers/tty/serial/omap-serial.c | 168 --
2 files changed, 162 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 6e748dc..3eeaa09 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1088,6 +1088,7 @@ config SERIAL_OMAP
tristate OMAP serial port support
depends on ARCH_OMAP2PLUS
select SERIAL_CORE
+ select SERIAL_MCTRL_GPIO
help
If you have a machine based on an Texas Instruments OMAP CPU you
can enable its onboard serial ports by enabling this option.
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 08b6b94..87dcad7 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -43,9 +43,13 @@
#include linux/gpio.h
#include linux/of_gpio.h
#include linux/platform_data/serial-omap.h
+#include linux/gpio/consumer.h
+#include linux/err.h
#include dt-bindings/gpio/gpio.h
+#include serial_mctrl_gpio.h
+
#define OMAP_MAX_HSUART_PORTS 6
#define UART_BUILD_REVISION(x, y) (((x) 8) | (y))
@@ -169,6 +173,9 @@ struct uart_omap_port {
struct serial_rs485 rs485;
int rts_gpio;
+ struct mctrl_gpios *gpios;
+ int gpio_irq[UART_GPIO_MAX];
+ boolms_irq_enabled;
struct pm_qos_request pm_qos_request;
u32 latency;
@@ -294,6 +301,27 @@ static void serial_omap_enable_ms(struct uart_port *port)
dev_dbg(up-port.dev, serial_omap_enable_ms+%d\n, up-port.line);
pm_runtime_get_sync(up-dev);
+
+ /*
+ * Interrupt should not be enabled twice
+ */
+ if (up-ms_irq_enabled)
+ return;
+
+ up-ms_irq_enabled = true;
+
+ if (up-gpio_irq[UART_GPIO_CTS] = 0)
+ enable_irq(up-gpio_irq[UART_GPIO_CTS]);
+
+ if (up-gpio_irq[UART_GPIO_DSR] = 0)
+ enable_irq(up-gpio_irq[UART_GPIO_DSR]);
+
+ if (up-gpio_irq[UART_GPIO_RI] = 0)
+ enable_irq(up-gpio_irq[UART_GPIO_RI]);
+
+ if (up-gpio_irq[UART_GPIO_DCD] = 0)
+ enable_irq(up-gpio_irq[UART_GPIO_DCD]);
+
up-ier |= UART_IER_MSI;
serial_out(up, UART_IER, up-ier);
pm_runtime_mark_last_busy(up-dev);
@@ -310,6 +338,10 @@ static void serial_omap_stop_tx(struct uart_port *port)
/* Handle RS-485 */
if (up-rs485.flags SER_RS485_ENABLED) {
if (up-scr OMAP_UART_SCR_TX_EMPTY) {
+ struct gpio_desc *rts_gpiod;
+
+ rts_gpiod = mctrl_gpio_to_gpiod(up-gpios,
UART_GPIO_RTS);
+
/* THR interrupt is fired when both TX FIFO and TX
* shift register are empty. This means there's nothing
* left to transmit now, so make sure the THR interrupt
@@ -320,10 +352,10 @@ static void serial_omap_stop_tx(struct uart_port *port)
up-scr = ~OMAP_UART_SCR_TX_EMPTY;
serial_out(up, UART_OMAP_SCR, up-scr);
res = (up-rs485.flags SER_RS485_RTS_AFTER_SEND) ? 1
: 0;
- if (gpio_get_value(up-rts_gpio) != res) {
+ if (gpiod_get_value(rts_gpiod) != res) {
if (up-rs485.delay_rts_after_send 0)
mdelay(up-rs485.delay_rts_after_send);
- gpio_set_value(up-rts_gpio, res);
+ gpiod_set_value(rts_gpiod, res);
}
} else {
/* We're asked to stop, but there's still stuff in the
@@ -425,14 +457,18 @@ static void serial_omap_start_tx(struct uart_port *port)
/* Handle RS-485 */
if (up-rs485.flags SER_RS485_ENABLED) {
+ struct gpio_desc *rts_gpiod;
+
+ rts_gpiod = mctrl_gpio_to_gpiod(up-gpios, UART_GPIO_RTS);
+
/* Fire THR interrupts when FIFO is below trigger level */
up-scr = ~OMAP_UART_SCR_TX_EMPTY;
serial_out(up, UART_OMAP_SCR, up-scr);
/* if rts not already enabled */
res = (up-rs485.flags SER_RS485_RTS_ON_SEND) ? 1 : 0;
- if (gpio_get_value(up-rts_gpio) != res) {
- gpio_set_value(up-rts_gpio, res);
+ if (gpiod_get_value(rts_gpiod) != res) {
+ gpiod_set_value(rts_gpiod, res);
if (up-rs485.delay_rts_before_send 0)
mdelay(up-rs485.delay_rts_before_send);
}
Re: [PATCH V2 00/19] bus: omap_l3_noc: driver cleanups and support for DRA7/AM4372
On 04/18/2014 12:00 AM, Nishanth Menon wrote: On 04/17/2014 03:57 PM, Santosh Shilimkar wrote: I looked at the series and its looks pretty good. Thanks for fixups, updates. For whole series, Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Thanks. Patches(including Peter's) is available here: https://github.com/nmenon/linux-2.6-playground/commits/l3noc/driver-fixes-v2 Can Tony pull this branch for 3.16 then which includes Peter's series as well ? there is just an empty commit with information about peter's patches that i lined up to differentiate the series.. I can drop it if Tony would like me to. Looking at the branch I see my patches underneath so they are in the branch. It would be great if Tony pulls this... Will be a great present to my patches (omap_l3 patches in the branch) for their 1 year anniversary of being out on the mailing list ;) -- Péter -- 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: [PATCHv3 19/41] OMAPDSS: panel-dpi: Add DT support
On 18/04/14 18:51, Tony Lindgren wrote:
+gpio = of_get_gpio(node, 0);
+if (gpio_is_valid(gpio) || gpio == -ENOENT) {
+ddata-enable_gpio = gpio;
+} else {
+dev_err(pdev-dev, failed to parse enable gpio\n);
+return gpio;
+}
We should set the GPIO polarity based on the OF_GPIO_ACTIVE_LOW like
gpio_backlight_probe_dt is doing.
Instead of doing it with the old gpio API, and checking the 'active'
flag everywhere, I think we can use the new gpiod API which handles the
polarity automatically.
I attached prototype patches (based on -rc2) for panel dpi using that
approach. It's a bit messier than I'd like, because for non-DT boot we
need to request the gpio using the old API, and then convert it to
gpio_desc. We can remove that code when all the boards use DT.
I've compiled tested this only, as I don't have DPI panels I could use.
I did try similar approach for TFP410, and it seemed to work fine.
Tomi
From f2280114f0eb814370664f24eba8ffee8280c840 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@ti.com
Date: Thu, 24 Apr 2014 12:36:52 +0300
Subject: [PATCH 1/3] panel-dpi: use gpiod for enable gpio
---
drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 32 +-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
index 5f8f7e7c81ef..d379dec3bd4a 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
@@ -25,8 +25,10 @@ struct panel_drv_data {
struct omap_video_timings videomode;
+ /* used for non-DT boot, to be removed */
int backlight_gpio;
- int enable_gpio;
+
+ struct gpio_desc *enable_gpio;
};
#define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
@@ -77,8 +79,8 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
if (r)
return r;
- if (gpio_is_valid(ddata-enable_gpio))
- gpio_set_value_cansleep(ddata-enable_gpio, 1);
+ if (ddata-enable_gpio)
+ gpiod_set_value_cansleep(ddata-enable_gpio, 1);
if (gpio_is_valid(ddata-backlight_gpio))
gpio_set_value_cansleep(ddata-backlight_gpio, 1);
@@ -96,8 +98,8 @@ static void panel_dpi_disable(struct omap_dss_device *dssdev)
if (!omapdss_device_is_enabled(dssdev))
return;
- if (gpio_is_valid(ddata-enable_gpio))
- gpio_set_value_cansleep(ddata-enable_gpio, 0);
+ if (ddata-enable_gpio)
+ gpiod_set_value_cansleep(ddata-enable_gpio, 0);
if (gpio_is_valid(ddata-backlight_gpio))
gpio_set_value_cansleep(ddata-backlight_gpio, 0);
@@ -156,6 +158,7 @@ static int panel_dpi_probe_pdata(struct platform_device *pdev)
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
struct omap_dss_device *dssdev, *in;
struct videomode vm;
+ int r;
pdata = dev_get_platdata(pdev-dev);
@@ -176,10 +179,20 @@ static int panel_dpi_probe_pdata(struct platform_device *pdev)
dssdev = ddata-dssdev;
dssdev-name = pdata-name;
- ddata-enable_gpio = pdata-enable_gpio;
+ r = devm_gpio_request_one(pdev-dev, pdata-enable_gpio,
+ GPIOF_OUT_INIT_LOW, panel enable);
+ if (r)
+ goto err_gpio;
+
+ ddata-enable_gpio = gpio_to_desc(pdata-enable_gpio);
+
ddata-backlight_gpio = pdata-backlight_gpio;
return 0;
+
+err_gpio:
+ omap_dss_put_device(ddata-in);
+ return r;
}
static int panel_dpi_probe(struct platform_device *pdev)
@@ -202,13 +215,6 @@ static int panel_dpi_probe(struct platform_device *pdev)
return -ENODEV;
}
- if (gpio_is_valid(ddata-enable_gpio)) {
- r = devm_gpio_request_one(pdev-dev, ddata-enable_gpio,
-GPIOF_OUT_INIT_LOW, panel enable);
- if (r)
- goto err_gpio;
- }
-
if (gpio_is_valid(ddata-backlight_gpio)) {
r = devm_gpio_request_one(pdev-dev, ddata-backlight_gpio,
GPIOF_OUT_INIT_LOW, panel backlight);
--
1.9.1
From fe2a85da34499fab70212c4cc5870378678da709 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@ti.com
Date: Thu, 16 May 2013 15:14:16 +0300
Subject: [PATCH 2/3] OMAPDSS: panel-dpi: Add DT support
Add DT support for panel-dpi.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Reviewed-by: Archit Taneja arc...@ti.com
---
drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 59 +-
1 file changed, 58 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
index d379dec3bd4a..dca6b10d1157 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
@@ -13,9 +13,12 @@
#include linux/module.h
#include linux/platform_device.h
#include linux/slab.h
+#include linux/of.h
+#include linux/of_gpio.h
#include video/omapdss.h
#include video/omap-panel-data.h
+#include video/of_display_timing.h
struct panel_drv_data {
struct omap_dss_device dssdev;
@@ -72,7 +75,8 @@ static int panel_dpi_enable(struct omap_dss_device
[PATCH v3 4/4] ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() varients
Use the corresponding compatibles to identify the devices. Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/mach-omap2/soc.h |7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h index 30abcc8..5ff724e 100644 --- a/arch/arm/mach-omap2/soc.h +++ b/arch/arm/mach-omap2/soc.h @@ -245,6 +245,8 @@ IS_AM_SUBCLASS(437x, 0x437) #define soc_is_omap54xx() 0 #define soc_is_omap543x() 0 #define soc_is_dra7xx()0 +#define soc_is_dra74x()0 +#define soc_is_dra72x()0 #if defined(MULTI_OMAP2) # if defined(CONFIG_ARCH_OMAP2) @@ -393,7 +395,12 @@ IS_OMAP_TYPE(3430, 0x3430) #if defined(CONFIG_SOC_DRA7XX) #undef soc_is_dra7xx +#undef soc_is_dra74x +#undef soc_is_dra72x #define soc_is_dra7xx()(of_machine_is_compatible(ti,dra7)) +#define soc_is_dra74x()(of_machine_is_compatible(ti,dra74)) +#define soc_is_dra72x()(of_machine_is_compatible(ti,dra72)) + #endif /* Various silicon revisions for omap2 */ -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/4] ARM: OMAP2+: Add machine entry for dra72x devices
The only difference from the dra74x devices is the missing .smp entry.
While at it, also fix the use of __initdata (across the file) and replace them
with __initconst as reported by checkpatch
ERROR: Use of const init definition must use __initconst
+static const char *dra72x_boards_compat[] __initdata = {
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/board-generic.c | 45 ---
1 file changed, 31 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index b8920b6..dabb9f6 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -43,7 +43,7 @@ static void __init omap_generic_init(void)
}
#ifdef CONFIG_SOC_OMAP2420
-static const char *omap242x_boards_compat[] __initdata = {
+static const char *omap242x_boards_compat[] __initconst = {
ti,omap2420,
NULL,
};
@@ -62,7 +62,7 @@ MACHINE_END
#endif
#ifdef CONFIG_SOC_OMAP2430
-static const char *omap243x_boards_compat[] __initdata = {
+static const char *omap243x_boards_compat[] __initconst = {
ti,omap2430,
NULL,
};
@@ -81,7 +81,7 @@ MACHINE_END
#endif
#ifdef CONFIG_ARCH_OMAP3
-static const char *omap3_boards_compat[] __initdata = {
+static const char *omap3_boards_compat[] __initconst = {
ti,omap3430,
ti,omap3,
NULL,
@@ -100,7 +100,7 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened Device
Tree))
.restart= omap3xxx_restart,
MACHINE_END
-static const char *omap36xx_boards_compat[] __initdata = {
+static const char *omap36xx_boards_compat[] __initconst = {
ti,omap36xx,
NULL,
};
@@ -118,7 +118,7 @@ DT_MACHINE_START(OMAP36XX_DT, Generic OMAP36xx (Flattened
Device Tree))
.restart= omap3xxx_restart,
MACHINE_END
-static const char *omap3_gp_boards_compat[] __initdata = {
+static const char *omap3_gp_boards_compat[] __initconst = {
ti,omap3-beagle,
timll,omap3-devkit8000,
NULL,
@@ -137,7 +137,7 @@ DT_MACHINE_START(OMAP3_GP_DT, Generic OMAP3-GP (Flattened
Device Tree))
.restart= omap3xxx_restart,
MACHINE_END
-static const char *am3517_boards_compat[] __initdata = {
+static const char *am3517_boards_compat[] __initconst = {
ti,am3517,
NULL,
};
@@ -157,7 +157,7 @@ MACHINE_END
#endif
#ifdef CONFIG_SOC_AM33XX
-static const char *am33xx_boards_compat[] __initdata = {
+static const char *am33xx_boards_compat[] __initconst = {
ti,am33xx,
NULL,
};
@@ -177,7 +177,7 @@ MACHINE_END
#endif
#ifdef CONFIG_ARCH_OMAP4
-static const char *omap4_boards_compat[] __initdata = {
+static const char *omap4_boards_compat[] __initconst = {
ti,omap4460,
ti,omap4430,
ti,omap4,
@@ -199,7 +199,7 @@ MACHINE_END
#endif
#ifdef CONFIG_SOC_OMAP5
-static const char *omap5_boards_compat[] __initdata = {
+static const char *omap5_boards_compat[] __initconst = {
ti,omap5432,
ti,omap5430,
ti,omap5,
@@ -221,7 +221,7 @@ MACHINE_END
#endif
#ifdef CONFIG_SOC_AM43XX
-static const char *am43_boards_compat[] __initdata = {
+static const char *am43_boards_compat[] __initconst = {
ti,am4372,
ti,am43,
NULL,
@@ -240,13 +240,13 @@ MACHINE_END
#endif
#ifdef CONFIG_SOC_DRA7XX
-static const char *dra7xx_boards_compat[] __initdata = {
- ti,dra7xx,
+static const char *dra74x_boards_compat[] __initconst = {
+ ti,dra74,
ti,dra7,
NULL,
};
-DT_MACHINE_START(DRA7XX_DT, Generic DRA7XX (Flattened Device Tree))
+DT_MACHINE_START(DRA74X_DT, Generic DRA74X (Flattened Device Tree))
.reserve= omap_reserve,
.smp= smp_ops(omap4_smp_ops),
.map_io = omap5_map_io,
@@ -255,7 +255,24 @@ DT_MACHINE_START(DRA7XX_DT, Generic DRA7XX (Flattened
Device Tree))
.init_irq = omap_gic_of_init,
.init_machine = omap_generic_init,
.init_time = omap5_realtime_timer_init,
- .dt_compat = dra7xx_boards_compat,
+ .dt_compat = dra74x_boards_compat,
+ .restart= omap44xx_restart,
+MACHINE_END
+
+static const char *dra72x_boards_compat[] __initconst = {
+ ti,dra72,
+ NULL,
+};
+
+DT_MACHINE_START(DRA72_DT, Generic DRA72X (Flattened Device Tree))
+ .reserve= omap_reserve,
+ .map_io = omap5_map_io,
+ .init_early = dra7xx_init_early,
+ .init_late = dra7xx_init_late,
+ .init_irq = omap_gic_of_init,
+ .init_machine = omap_generic_init,
+ .init_time = omap5_realtime_timer_init,
+ .dt_compat = dra72x_boards_compat,
.restart= omap44xx_restart,
MACHINE_END
#endif
--
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
[PATCH v3 2/4] ARM: dts: Add support for DRA72x family of devices
DRA72x is a single core cortex A15 device with most infrastructure IPs otherwise
same as whats on the DRA74x devices.
So move the cpu nodes into dra74x.dtsi and dra72x.dtsi respectively.
Also add a minimal dra72-evm dts file.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: linux-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
---
.../devicetree/bindings/arm/omap/omap.txt | 14 +--
arch/arm/boot/dts/Makefile |3 +-
arch/arm/boot/dts/dra7-evm.dts |6 +--
arch/arm/boot/dts/dra7.dtsi| 27 -
arch/arm/boot/dts/dra72-evm.dts| 24
arch/arm/boot/dts/dra72x.dtsi | 25
arch/arm/boot/dts/dra74x.dtsi | 41
7 files changed, 105 insertions(+), 35 deletions(-)
create mode 100644 arch/arm/boot/dts/dra72-evm.dts
create mode 100644 arch/arm/boot/dts/dra72x.dtsi
create mode 100644 arch/arm/boot/dts/dra74x.dtsi
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 36ede19..1bc2338 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -79,8 +79,11 @@ SoCs:
- OMAP5432
compatible = ti,omap5432, ti,omap5
-- DRA742
- compatible = ti,dra7xx, ti,dra7
+- DRA74x
+ compatible = ti,dra74, ti,dra7
+
+- DRA72x
+ compatible = ti,dra72, ti,dra7
- AM4372
compatible = ti,am4372, ti,am43
@@ -120,5 +123,8 @@ Boards:
- AM437x GP EVM
compatible = ti,am437x-gp-evm, ti,am4372, ti,am43
-- DRA7 EVM: Software Developement Board for DRA7XX
- compatible = ti,dra7-evm, ti,dra7
+- DRA74 EVM: Software Developement Board for DRA74x
+ compatible = ti,dra7-evm, ti,dra74, ti,dra7
+
+- DRA72 EVM: Software Development Board for DRA72x
+ compatible = ti,dra72-evm, ti,dra72, ti,dra7
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 35c146f..ff98a97 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -288,7 +288,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am3517_mt_ventoux.dtb \
am43x-epos-evm.dtb \
am437x-gp-evm.dtb \
- dra7-evm.dtb
+ dra7-evm.dtb \
+ dra72-evm.dtb
dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcom-msm8660-surf.dtb \
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 7807429..df6a6db 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -7,11 +7,11 @@
*/
/dts-v1/;
-#include dra7.dtsi
+#include dra74x.dtsi
/ {
- model = TI DRA7;
- compatible = ti,dra7-evm, ti,dra7;
+ model = TI DRA74x;
+ compatible = ti,dra7-evm, ti,dra74, ti,dra7;
memory {
device_type = memory;
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1c0f8e1..e27fec7 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -33,33 +33,6 @@
serial5 = uart6;
};
- cpus {
- #address-cells = 1;
- #size-cells = 0;
-
- cpu0: cpu@0 {
- device_type = cpu;
- compatible = arm,cortex-a15;
- reg = 0;
-
- operating-points =
- /* kHzuV */
- 100 106
- 1176000 116
- ;
-
- clocks = dpll_mpu_ck;
- clock-names = cpu;
-
- clock-latency = 30; /* From omap-cpufreq driver */
- };
- cpu@1 {
- device_type = cpu;
- compatible = arm,cortex-a15;
- reg = 1;
- };
- };
-
timer {
compatible = arm,armv7-timer;
interrupts = GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) |
IRQ_TYPE_LEVEL_LOW),
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
new file mode 100644
index 000..ead6440
--- /dev/null
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include dra72x.dtsi
+
+/ {
+ model = TI DRA72x;
+ compatible = ti,dra72-evm, ti,dra72, ti,dra7;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x4000; /* 1024 MB */
+ };
+};
+
+uart1 {
+ status = okay;
+};
diff --git
[PATCH v3 1/4] ARM: dts: dra7-evm: Remove the wrong and undocumented compatible
ti,dra752 is neither documented nor correct, since the device is actually a
dra742 device as rightly documented in dt bindings.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/dra7-evm.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 5babba0..7807429 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -11,7 +11,7 @@
/ {
model = TI DRA7;
- compatible = ti,dra7-evm, ti,dra752, ti,dra7;
+ compatible = ti,dra7-evm, ti,dra7;
memory {
device_type = memory;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/4] ARM: DRA7: Add support for DRA72x devices
changes in v3: Removed wildcards from compatible strings and duplicates from .dt_compat strings as suggested by Arnd DRA72x devices are single core Cortex A15 devices belonging to the DRA7 family (Similar to the DRA74x devices which are dual core Cortex A15 based) The patches (based off 3.15-rc2) add minimal DT/kernel modifications to add boot support for DRA72x devices reusing all the kernel data for DRA74x devices. Rajendra Nayak (4): ARM: dts: dra7-evm: Remove the wrong and undocumented compatible ARM: dts: Add support for DRA72x family of devices ARM: OMAP2+: Add machine entry for dra72x devices ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() varients .../devicetree/bindings/arm/omap/omap.txt | 14 -- arch/arm/boot/dts/Makefile |3 +- arch/arm/boot/dts/dra7-evm.dts |6 +-- arch/arm/boot/dts/dra7.dtsi| 27 arch/arm/boot/dts/dra72-evm.dts| 24 +++ arch/arm/boot/dts/dra72x.dtsi | 25 +++ arch/arm/boot/dts/dra74x.dtsi | 41 ++ arch/arm/mach-omap2/board-generic.c| 45 ++-- arch/arm/mach-omap2/soc.h |7 +++ 9 files changed, 143 insertions(+), 49 deletions(-) create mode 100644 arch/arm/boot/dts/dra72-evm.dts create mode 100644 arch/arm/boot/dts/dra72x.dtsi create mode 100644 arch/arm/boot/dts/dra74x.dtsi -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/23] OMAPDSS: OMAP5 display support
Hi, This series implements OMAP5 display support. The series is based on -rc2. Tested on OMAP5 uEVM with HDMI output, and OMAP5 uEVM with a custom DSI panel (patches for the panel are not included here). Tomi Archit Taneja (4): ARM: OMAP: hwmod: OMAP5 DSS hwmod data OMAPDSS: HDMI: support larger register offsets for OMAP5 HDMI core OMAPDSS: HDMI: PHY changes for OMAP5 OMAPDSS: HDMI: PLL changes for OMAP5 Tomi Valkeinen (19): OMAPDSS: HDMI: lane config support Doc/DT: ti,omap4-dss: hdmi lanes OMAPDSS: HDMI4: set regulator voltage to 1.8V OMAPDSS: DSI: set regulator voltage to 1.8V ARM: OMAP: add OMAP5 DSI muxing ARM: OMAP: add detection of omap5-dss ARM: dts: omap5-clocks.dtsi: add dss iclk ARM: dts: omap5-clocks.dtsi: add ti,set-rate-parent to dss_dss_clk ARM: dts: omap5.dtsi: add DSS nodes ARM: dts: omap5-uevm.dts: add tca6424a ARM: dts: omap5-uevm.dts: add display nodes OMAPDSS: DSS DISPC DT support for OMAP5 OMAPDSS: features: fix OMAP5 features OMAPDSS: DPI: fix LCD3 DSI source OMAPDSS: DSI: Add OMAP5 DSI module IDs OMAPDSS: HDMI: improve Makefile OMAPDSS: HDMI: move irq phy pwr handling OMAPDSS: HDMI: Add OMAP5 HDMI support Doc/DT: Add OMAP5 DSS DT bindings .../devicetree/bindings/video/ti,omap4-dss.txt | 4 + .../devicetree/bindings/video/ti,omap5-dss.txt | 96 +++ arch/arm/boot/dts/omap5-uevm.dts | 89 ++ arch/arm/boot/dts/omap5.dtsi | 70 ++ arch/arm/boot/dts/omap54xx-clocks.dtsi | 9 + arch/arm/mach-omap2/display.c | 39 +- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 283 +++ drivers/video/fbdev/omap2/dss/Kconfig | 22 +- drivers/video/fbdev/omap2/dss/Makefile | 6 +- drivers/video/fbdev/omap2/dss/core.c | 6 + drivers/video/fbdev/omap2/dss/dispc.c | 1 + drivers/video/fbdev/omap2/dss/dpi.c| 2 + drivers/video/fbdev/omap2/dss/dsi.c| 17 + drivers/video/fbdev/omap2/dss/dss.c| 1 + drivers/video/fbdev/omap2/dss/dss.h| 3 + drivers/video/fbdev/omap2/dss/dss_features.c | 3 +- drivers/video/fbdev/omap2/dss/hdmi.h | 17 +- drivers/video/fbdev/omap2/dss/hdmi4.c | 113 ++- drivers/video/fbdev/omap2/dss/hdmi5.c | 829 ++ drivers/video/fbdev/omap2/dss/hdmi5_core.c | 922 + drivers/video/fbdev/omap2/dss/hdmi5_core.h | 306 +++ drivers/video/fbdev/omap2/dss/hdmi_common.c| 41 + drivers/video/fbdev/omap2/dss/hdmi_phy.c | 231 -- drivers/video/fbdev/omap2/dss/hdmi_pll.c | 81 +- drivers/video/fbdev/omap2/dss/hdmi_wp.c| 2 +- 25 files changed, 3111 insertions(+), 82 deletions(-) create mode 100644 Documentation/devicetree/bindings/video/ti,omap5-dss.txt create mode 100644 drivers/video/fbdev/omap2/dss/hdmi5.c create mode 100644 drivers/video/fbdev/omap2/dss/hdmi5_core.c create mode 100644 drivers/video/fbdev/omap2/dss/hdmi5_core.h -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/23] OMAPDSS: DPI: fix LCD3 DSI source
At the moment the dpi driver does not handle LCD3 clock source at all. LCD3 channel gets the DSI PLL clock from DSI2 instance. Add support for LCD3's clock source in the dpi driver. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/fbdev/omap2/dss/dpi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/fbdev/omap2/dss/dpi.c b/drivers/video/fbdev/omap2/dss/dpi.c index 157921db447a..8e097fb58a9c 100644 --- a/drivers/video/fbdev/omap2/dss/dpi.c +++ b/drivers/video/fbdev/omap2/dss/dpi.c @@ -103,6 +103,8 @@ static enum omap_dss_clk_source dpi_get_alt_clk_src(enum omap_channel channel) return OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC; case OMAP_DSS_CHANNEL_LCD2: return OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC; + case OMAP_DSS_CHANNEL_LCD3: + return OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC; default: /* this shouldn't happen */ WARN_ON(1); -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/23] ARM: dts: omap5-clocks.dtsi: add ti,set-rate-parent to dss_dss_clk
Add ti,set-rate-parent to dss_dss_clk so that the DSS driver can
set the rate.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/boot/dts/omap54xx-clocks.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi
b/arch/arm/boot/dts/omap54xx-clocks.dtsi
index 26c02f9e92c4..b53ca885c021 100644
--- a/arch/arm/boot/dts/omap54xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi
@@ -859,6 +859,7 @@
clocks = dpll_per_h12x2_ck;
ti,bit-shift = 8;
reg = 0x1420;
+ ti,set-rate-parent;
};
dss_sys_clk: dss_sys_clk {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
Add support to set OMAP5 DSI pin muxing.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/display.c | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 16d33d831287..974461441fc3 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -137,11 +137,42 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
return 0;
}
+#define CONTROL_PAD_BASE 0x4A002800
+#define CONTROL_DSIPHY 0x614
+
+static int omap5_dsi_mux_pads(int dsi_id, unsigned lanes)
+{
+ u32 enable_mask, enable_shift, reg;
+ void __iomem *ctrl_pad_base = NULL;
+
+ ctrl_pad_base = ioremap(CONTROL_PAD_BASE, SZ_4K);
+ if (!ctrl_pad_base)
+ return -ENXIO;
+
+ if (dsi_id == 0) {
+ enable_mask = OMAP4_DSI1_LANEENABLE_MASK;
+ enable_shift = OMAP4_DSI1_LANEENABLE_SHIFT;
+ } else if (dsi_id == 1) {
+ enable_mask = OMAP4_DSI2_LANEENABLE_MASK;
+ enable_shift = OMAP4_DSI2_LANEENABLE_SHIFT;
+ } else {
+ return -ENODEV;
+ }
+
+ reg = __raw_readl(ctrl_pad_base + CONTROL_DSIPHY);
+ reg = ~enable_mask;
+ reg |= (lanes enable_shift) enable_mask;
+ __raw_writel(reg, ctrl_pad_base + CONTROL_DSIPHY);
+
+ return 0;
+}
+
static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
{
if (cpu_is_omap44xx())
return omap4_dsi_mux_pads(dsi_id, lane_mask);
-
+ else if (soc_is_omap54xx())
+ return omap5_dsi_mux_pads(dsi_id, lane_mask);
return 0;
}
@@ -149,6 +180,8 @@ static void omap_dsi_disable_pads(int dsi_id, unsigned
lane_mask)
{
if (cpu_is_omap44xx())
omap4_dsi_mux_pads(dsi_id, 0);
+ else if (soc_is_omap54xx())
+ omap5_dsi_mux_pads(dsi_id, 0);
}
static int omap_dss_set_min_bus_tput(struct device *dev, unsigned long tput)
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/23] ARM: dts: omap5.dtsi: add DSS nodes
Add OMAP5 DSS nodes to omap5.dtsi.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap5.dtsi | 70
1 file changed, 70 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 6f3de22fb266..b2a28e6575df 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -863,6 +863,76 @@
#thermal-sensor-cells = 1;
};
+
+ dss: dss@5800 {
+ compatible = ti,omap5-dss;
+ reg = 0x5800 0x80;
+ status = disabled;
+ ti,hwmods = dss_core;
+ clocks = dss_dss_clk;
+ clock-names = fck;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dispc@58001000 {
+ compatible = ti,omap5-dispc;
+ reg = 0x58001000 0x1000;
+ interrupts = GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = dss_dispc;
+ clocks = dss_dss_clk;
+ clock-names = fck;
+ };
+
+ rfbi: encoder@58002000 {
+ compatible = ti,omap5-rfbi;
+ reg = 0x58002000 0x100;
+ status = disabled;
+ ti,hwmods = dss_rfbi;
+ clocks = dss_dss_clk, dss_l3_iclk;
+ clock-names = fck, ick;
+ };
+
+ dsi1: encoder@58004000 {
+ compatible = ti,omap5-dsi;
+ reg = 0x58004000 0x200,
+ 0x58004200 0x40,
+ 0x58004300 0x40;
+ reg-names = proto, phy, pll;
+ interrupts = GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ ti,hwmods = dss_dsi1;
+ clocks = dss_dss_clk, dss_sys_clk;
+ clock-names = fck, sys_clk;
+ };
+
+ dsi2: encoder@58005000 {
+ compatible = ti,omap5-dsi;
+ reg = 0x58009000 0x200,
+ 0x58009200 0x40,
+ 0x58009300 0x40;
+ reg-names = proto, phy, pll;
+ interrupts = GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ ti,hwmods = dss_dsi2;
+ clocks = dss_dss_clk, dss_sys_clk;
+ clock-names = fck, sys_clk;
+ };
+
+ hdmi: encoder@5806 {
+ compatible = ti,omap5-hdmi;
+ reg = 0x5804 0x400,
+ 0x58040200 0x80,
+ 0x58040300 0x80,
+ 0x5806 0x19000;
+ reg-names = wp, pll, phy, core;
+ interrupts = GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ ti,hwmods = dss_hdmi;
+ clocks = dss_48mhz_clk, dss_sys_clk;
+ clock-names = fck, sys_clk;
+ };
+ };
};
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 21/23] OMAPDSS: HDMI: PLL changes for OMAP5
From: Archit Taneja arc...@ti.com
Add a features struct to differentiate between the HDMI PLLs on OMAP4
and OMAP5. The OMAP5 PLL is more sensitive when it comes to locking. We
need to ensure that the DCO freq isn't too low for lower pixel clocks.
Modify the PLL computation slightly to ensure the HDMI PLL locks for lower
frequencies. This will be later replaced by a more complex computation
which makes sure all the PLL constraints are met.
Signed-off-by: Archit Taneja arc...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/hdmi_pll.c | 81 +++-
1 file changed, 79 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi_pll.c
b/drivers/video/fbdev/omap2/dss/hdmi_pll.c
index 5fc71215c303..2b910cb9eee4 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi_pll.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi_pll.c
@@ -23,6 +23,18 @@
#define HDMI_DEFAULT_REGN 16
#define HDMI_DEFAULT_REGM2 1
+struct hdmi_pll_features {
+ bool sys_reset;
+ /* this is a hack, need to replace it with a better computation of M2 */
+ bool bound_dcofreq;
+ unsigned long fint_min, fint_max;
+ u16 regm_max;
+ unsigned long dcofreq_low_min, dcofreq_low_max;
+ unsigned long dcofreq_high_min, dcofreq_high_max;
+};
+
+static const struct hdmi_pll_features *pll_feat;
+
void hdmi_pll_dump(struct hdmi_pll_data *pll, struct seq_file *s)
{
#define DUMPPLL(r) seq_printf(s, %-35s %08x\n, #r,\
@@ -57,7 +69,11 @@ void hdmi_pll_compute(struct hdmi_pll_data *pll, unsigned
long clkin, int phy)
refclk = clkin / pi-regn;
- pi-regm2 = HDMI_DEFAULT_REGM2;
+ /* temorary hack to make sure DCO freq isn't calculated too low */
+ if (pll_feat-bound_dcofreq phy = 65000)
+ pi-regm2 = 3;
+ else
+ pi-regm2 = HDMI_DEFAULT_REGM2;
/*
* multiplier is pixel_clk/ref_clk
@@ -154,7 +170,7 @@ static int hdmi_pll_config(struct hdmi_pll_data *pll)
static int hdmi_pll_reset(struct hdmi_pll_data *pll)
{
/* SYSRESET controlled by power FSM */
- REG_FLD_MOD(pll-base, PLLCTRL_PLL_CONTROL, 0x0, 3, 3);
+ REG_FLD_MOD(pll-base, PLLCTRL_PLL_CONTROL, pll_feat-sys_reset, 3, 3);
/* READ 0x0 reset is in progress */
if (hdmi_wait_for_bit_change(pll-base, PLLCTRL_PLL_STATUS, 0, 0, 1)
@@ -197,11 +213,72 @@ void hdmi_pll_disable(struct hdmi_pll_data *pll, struct
hdmi_wp_data *wp)
#define PLL_OFFSET 0x200
#define PLL_SIZE 0x100
+static const struct hdmi_pll_features omap44xx_pll_feats = {
+ .sys_reset = false,
+ .bound_dcofreq = false,
+ .fint_min = 50,
+ .fint_max = 250,
+ .regm_max = 4095,
+ .dcofreq_low_min= 5,
+ .dcofreq_low_max= 10,
+ .dcofreq_high_min = 10,
+ .dcofreq_high_max = 20,
+};
+
+static const struct hdmi_pll_features omap54xx_pll_feats = {
+ .sys_reset = true,
+ .bound_dcofreq = true,
+ .fint_min = 62,
+ .fint_max = 250,
+ .regm_max = 2046,
+ .dcofreq_low_min= 75000,
+ .dcofreq_low_max= 15,
+ .dcofreq_high_min = 125000,
+ .dcofreq_high_max = 25UL,
+};
+
+static int hdmi_pll_init_features(struct platform_device *pdev)
+{
+ struct hdmi_pll_features *dst;
+ const struct hdmi_pll_features *src;
+
+ dst = devm_kzalloc(pdev-dev, sizeof(*dst), GFP_KERNEL);
+ if (!dst) {
+ dev_err(pdev-dev, Failed to allocate HDMI PHY Features\n);
+ return -ENOMEM;
+ }
+
+ switch (omapdss_get_version()) {
+ case OMAPDSS_VER_OMAP4430_ES1:
+ case OMAPDSS_VER_OMAP4430_ES2:
+ case OMAPDSS_VER_OMAP4:
+ src = omap44xx_pll_feats;
+ break;
+
+ case OMAPDSS_VER_OMAP5:
+ src = omap54xx_pll_feats;
+ break;
+
+ default:
+ return -ENODEV;
+ }
+
+ memcpy(dst, src, sizeof(*dst));
+ pll_feat = dst;
+
+ return 0;
+}
+
int hdmi_pll_init(struct platform_device *pdev, struct hdmi_pll_data *pll)
{
+ int r;
struct resource *res;
struct resource temp_res;
+ r = hdmi_pll_init_features(pdev);
+ if (r)
+ return r;
+
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, pll);
if (!res) {
DSSDBG(can't get PLL mem resource by name\n);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH 14/23] OMAPDSS: features: fix OMAP5 features
OMAP5 has LCD3 overlay manager, and total 4 overlay managers. These are
not correctly defined in the dss features. Fix them.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/dss_features.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/dss/dss_features.c
b/drivers/video/fbdev/omap2/dss/dss_features.c
index 7f8969191dc6..ec1527de218d 100644
--- a/drivers/video/fbdev/omap2/dss/dss_features.c
+++ b/drivers/video/fbdev/omap2/dss/dss_features.c
@@ -595,6 +595,7 @@ static const enum dss_feat_id omap4_dss_feat_list[] = {
static const enum dss_feat_id omap5_dss_feat_list[] = {
FEAT_MGR_LCD2,
+ FEAT_MGR_LCD3,
FEAT_CORE_CLK_DIV,
FEAT_LCD_CLK_SRC,
FEAT_DSI_DCS_CMD_CONFIG_VC,
@@ -777,7 +778,7 @@ static const struct omap_dss_features omap5_dss_features = {
.features = omap5_dss_feat_list,
.num_features = ARRAY_SIZE(omap5_dss_feat_list),
- .num_mgrs = 3,
+ .num_mgrs = 4,
.num_ovls = 4,
.supported_displays = omap5_dss_supported_displays,
.supported_outputs = omap5_dss_supported_outputs,
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/23] OMAPDSS: HDMI: support larger register offsets for OMAP5 HDMI core
From: Archit Taneja arc...@ti.com
The HDMI core IP on OMAP5 has a wider address range for registers. The offsets
for the later registers can't fit into the u16 type currently used for hdmi
register read and write functions. Use u32 for offsets instead.
Signed-off-by: Archit Taneja arc...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/hdmi.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h
b/drivers/video/fbdev/omap2/dss/hdmi.h
index d784b2cced9d..0e5979ef933c 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -361,13 +361,13 @@ struct hdmi_core_data {
struct hdmi_core_infoframe_avi avi_cfg;
};
-static inline void hdmi_write_reg(void __iomem *base_addr, const u16 idx,
+static inline void hdmi_write_reg(void __iomem *base_addr, const u32 idx,
u32 val)
{
__raw_writel(val, base_addr + idx);
}
-static inline u32 hdmi_read_reg(void __iomem *base_addr, const u16 idx)
+static inline u32 hdmi_read_reg(void __iomem *base_addr, const u32 idx)
{
return __raw_readl(base_addr + idx);
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/23] OMAPDSS: DSI: Add OMAP5 DSI module IDs
Add OMAP5 DSI module ID support to the OMAP DSI driver.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/dsi.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/dsi.c
b/drivers/video/fbdev/omap2/dss/dsi.c
index 57f120896b43..a888d28fd055 100644
--- a/drivers/video/fbdev/omap2/dss/dsi.c
+++ b/drivers/video/fbdev/omap2/dss/dsi.c
@@ -5733,9 +5733,16 @@ static const struct dsi_module_id_data
dsi_of_data_omap4[] = {
{ },
};
+static const struct dsi_module_id_data dsi_of_data_omap5[] = {
+ { .address = 0x58004000, .id = 0, },
+ { .address = 0x58009000, .id = 1, },
+ { },
+};
+
static const struct of_device_id dsi_of_match[] = {
{ .compatible = ti,omap3-dsi, .data = dsi_of_data_omap3, },
{ .compatible = ti,omap4-dsi, .data = dsi_of_data_omap4, },
+ { .compatible = ti,omap5-dsi, .data = dsi_of_data_omap5, },
{},
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 20/23] OMAPDSS: HDMI: PHY changes for OMAP5
From: Archit Taneja arc...@ti.com
OMAP5 HDMI PHY has some differences compared to OMAP4 HDMI PHY. This
patch creates a features struct which help the driver configure the PHY
based on what SoC it is.
Some of the features aren't currenlty used, but will come in use later.
Signed-off-by: Archit Taneja arc...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/hdmi.h | 1 +
drivers/video/fbdev/omap2/dss/hdmi_phy.c | 95 +++-
2 files changed, 94 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h
b/drivers/video/fbdev/omap2/dss/hdmi.h
index 0e5979ef933c..1819f93cd49e 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -80,6 +80,7 @@
#define HDMI_TXPHY_DIGITAL_CTRL0x4
#define HDMI_TXPHY_POWER_CTRL 0x8
#define HDMI_TXPHY_PAD_CFG_CTRL0xC
+#define HDMI_TXPHY_BIST_CONTROL0x1C
enum hdmi_pll_pwr {
HDMI_PLLPWRCMD_ALLOFF = 0,
diff --git a/drivers/video/fbdev/omap2/dss/hdmi_phy.c
b/drivers/video/fbdev/omap2/dss/hdmi_phy.c
index 8d13e422de5e..2614cf9dafb0 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi_phy.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi_phy.c
@@ -12,11 +12,22 @@
#include linux/err.h
#include linux/io.h
#include linux/platform_device.h
+#include linux/slab.h
#include video/omapdss.h
#include dss.h
#include hdmi.h
+struct hdmi_phy_features {
+ bool bist_ctrl;
+ bool calc_freqout;
+ bool ldo_voltage;
+ unsigned long dcofreq_min;
+ unsigned long max_phy;
+};
+
+static const struct hdmi_phy_features *phy_feat;
+
void hdmi_phy_dump(struct hdmi_phy_data *phy, struct seq_file *s)
{
#define DUMPPHY(r) seq_printf(s, %-35s %08x\n, #r,\
@@ -26,6 +37,8 @@ void hdmi_phy_dump(struct hdmi_phy_data *phy, struct seq_file
*s)
DUMPPHY(HDMI_TXPHY_DIGITAL_CTRL);
DUMPPHY(HDMI_TXPHY_POWER_CTRL);
DUMPPHY(HDMI_TXPHY_PAD_CFG_CTRL);
+ if (phy_feat-bist_ctrl)
+ DUMPPHY(HDMI_TXPHY_BIST_CONTROL);
}
int hdmi_phy_parse_lanes(struct hdmi_phy_data *phy, const u32 *lanes)
@@ -121,6 +134,8 @@ static void hdmi_phy_configure_lanes(struct hdmi_phy_data
*phy)
int hdmi_phy_configure(struct hdmi_phy_data *phy, struct hdmi_config *cfg)
{
+ u8 freqout;
+
/*
* Read address 0 in order to get the SCP reset done completed
* Dummy access performed to make sure reset is done
@@ -128,16 +143,39 @@ int hdmi_phy_configure(struct hdmi_phy_data *phy, struct
hdmi_config *cfg)
hdmi_read_reg(phy-base, HDMI_TXPHY_TX_CTRL);
/*
+* In OMAP5+, the HFBITCLK must be divided by 2 before issuing the
+* HDMI_PHYPWRCMD_LDOON command.
+ */
+ if (phy_feat-bist_ctrl)
+ REG_FLD_MOD(phy-base, HDMI_TXPHY_BIST_CONTROL, 1, 11, 11);
+
+ if (phy_feat-calc_freqout) {
+ /* DCOCLK/10 is pixel clock, compare pclk with DCOCLK_MIN/10 */
+ u32 dco_min = phy_feat-dcofreq_min / 10;
+ u32 pclk = cfg-timings.pixelclock;
+
+ if (pclk dco_min)
+ freqout = 0;
+ else if ((pclk = dco_min) (pclk phy_feat-max_phy))
+ freqout = 1;
+ else
+ freqout = 2;
+ } else {
+ freqout = 1;
+ }
+
+ /*
* Write to phy address 0 to configure the clock
* use HFBITCLK write HDMI_TXPHY_TX_CONTROL_FREQOUT field
*/
- REG_FLD_MOD(phy-base, HDMI_TXPHY_TX_CTRL, 0x1, 31, 30);
+ REG_FLD_MOD(phy-base, HDMI_TXPHY_TX_CTRL, freqout, 31, 30);
/* Write to phy address 1 to start HDMI line (TXVALID and TMDSCLKEN) */
hdmi_write_reg(phy-base, HDMI_TXPHY_DIGITAL_CTRL, 0xF000);
/* Setup max LDO voltage */
- REG_FLD_MOD(phy-base, HDMI_TXPHY_POWER_CTRL, 0xB, 3, 0);
+ if (phy_feat-ldo_voltage)
+ REG_FLD_MOD(phy-base, HDMI_TXPHY_POWER_CTRL, 0xB, 3, 0);
hdmi_phy_configure_lanes(phy);
@@ -147,11 +185,64 @@ int hdmi_phy_configure(struct hdmi_phy_data *phy, struct
hdmi_config *cfg)
#define PHY_OFFSET 0x300
#define PHY_SIZE 0x100
+static const struct hdmi_phy_features omap44xx_phy_feats = {
+ .bist_ctrl = false,
+ .calc_freqout = false,
+ .ldo_voltage= true,
+ .dcofreq_min= 5,
+ .max_phy= 185675000,
+};
+
+static const struct hdmi_phy_features omap54xx_phy_feats = {
+ .bist_ctrl = true,
+ .calc_freqout = true,
+ .ldo_voltage= false,
+ .dcofreq_min= 75000,
+ .max_phy= 18600,
+};
+
+static int hdmi_phy_init_features(struct platform_device *pdev)
+{
+ struct hdmi_phy_features *dst;
+ const struct hdmi_phy_features
[PATCH 17/23] OMAPDSS: HDMI: improve Makefile
We'll soon add support for OMAP5 HDMI, which uses some of the same files as OMAP4 HDMI does. This patch adds a new config entry OMAP2_DSS_HDMI_COMMON, which both OMAP4 and OMAP5 HDMI config entries can select. OMAP2_DSS_HDMI_COMMON will cause the common HDMI files to be compiled. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/fbdev/omap2/dss/Kconfig | 9 ++--- drivers/video/fbdev/omap2/dss/Makefile | 5 +++-- 2 files changed, 9 insertions(+), 5 deletions(-) diff --git a/drivers/video/fbdev/omap2/dss/Kconfig b/drivers/video/fbdev/omap2/dss/Kconfig index dde4281663b1..36de3d5d2896 100644 --- a/drivers/video/fbdev/omap2/dss/Kconfig +++ b/drivers/video/fbdev/omap2/dss/Kconfig @@ -59,12 +59,15 @@ config OMAP2_DSS_VENC help OMAP Video Encoder support for S-Video and composite TV-out. +config OMAP2_DSS_HDMI_COMMON + bool + config OMAP4_DSS_HDMI - bool HDMI support + bool HDMI support for OMAP4 default y + select OMAP2_DSS_HDMI_COMMON help - HDMI Interface. This adds the High Definition Multimedia Interface. - See http://www.hdmi.org/ for HDMI specification. + HDMI support for OMAP4 based SoCs. config OMAP4_DSS_HDMI_AUDIO bool diff --git a/drivers/video/fbdev/omap2/dss/Makefile b/drivers/video/fbdev/omap2/dss/Makefile index 8aec8bda27cc..4cbe7ce406f9 100644 --- a/drivers/video/fbdev/omap2/dss/Makefile +++ b/drivers/video/fbdev/omap2/dss/Makefile @@ -10,6 +10,7 @@ omapdss-$(CONFIG_OMAP2_DSS_RFBI) += rfbi.o omapdss-$(CONFIG_OMAP2_DSS_VENC) += venc.o omapdss-$(CONFIG_OMAP2_DSS_SDI) += sdi.o omapdss-$(CONFIG_OMAP2_DSS_DSI) += dsi.o -omapdss-$(CONFIG_OMAP4_DSS_HDMI) += hdmi4.o hdmi_common.o hdmi_wp.o hdmi_pll.o \ - hdmi_phy.o hdmi4_core.o +omapdss-$(CONFIG_OMAP2_DSS_HDMI_COMMON) += hdmi_common.o hdmi_wp.o hdmi_pll.o \ + hdmi_phy.o +omapdss-$(CONFIG_OMAP4_DSS_HDMI) += hdmi4.o hdmi4_core.o ccflags-$(CONFIG_OMAP2_DSS_DEBUG) += -DDEBUG -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 18/23] OMAPDSS: HDMI: move irq phy pwr handling
HDMI IRQ handling was moved into hdmi_phy.c when restructuring the HDMI
driver. While this worked fine, it's not correct.
The HDMI IRQ handling should be either in the hdmi_wp, or in the main
hdmi driver. This patch moves the handling to the main hdmi driver, as I
feel it's a more appropriate choice.
This move also requires changing the handling of the PHY power, as that
was partly handled in the IRQ handler. The PHY power is handled via the
WP module. An option would be to give HDMI PHY driver function pointers
that it could use to manage the PHY power, but as the PHY power is not
needed to access the PHY registers, the handling was also moved to the
main HDMI driver. This could be changed later if need be.
Note that there's slightly similar power issue with the PLL: the HDMI
PLLs power is also handled via the WP module. For now, the PLL power
handling is still done inside the PLL driver.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/hdmi.h | 6 +--
drivers/video/fbdev/omap2/dss/hdmi4.c| 75 +---
drivers/video/fbdev/omap2/dss/hdmi_phy.c | 70 +
3 files changed, 71 insertions(+), 80 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h
b/drivers/video/fbdev/omap2/dss/hdmi.h
index 4e5c44e7eeb3..d784b2cced9d 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -351,8 +351,6 @@ struct hdmi_pll_data {
struct hdmi_phy_data {
void __iomem *base;
- int irq;
-
u8 lane_function[4];
u8 lane_polarity[4];
};
@@ -420,9 +418,7 @@ void hdmi_pll_compute(struct hdmi_pll_data *pll, unsigned
long clkin, int phy);
int hdmi_pll_init(struct platform_device *pdev, struct hdmi_pll_data *pll);
/* HDMI PHY funcs */
-int hdmi_phy_enable(struct hdmi_phy_data *phy, struct hdmi_wp_data *wp,
- struct hdmi_config *cfg);
-void hdmi_phy_disable(struct hdmi_phy_data *phy, struct hdmi_wp_data *wp);
+int hdmi_phy_configure(struct hdmi_phy_data *phy, struct hdmi_config *cfg);
void hdmi_phy_dump(struct hdmi_phy_data *phy, struct seq_file *s);
int hdmi_phy_init(struct platform_device *pdev, struct hdmi_phy_data *phy);
int hdmi_phy_parse_lanes(struct hdmi_phy_data *phy, const u32 *lanes);
diff --git a/drivers/video/fbdev/omap2/dss/hdmi4.c
b/drivers/video/fbdev/omap2/dss/hdmi4.c
index 5c7dd5c06593..626aad2bef46 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi4.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi4.c
@@ -81,6 +81,37 @@ static void hdmi_runtime_put(void)
WARN_ON(r 0 r != -ENOSYS);
}
+static irqreturn_t hdmi_irq_handler(int irq, void *data)
+{
+ struct hdmi_wp_data *wp = data;
+ u32 irqstatus;
+
+ irqstatus = hdmi_wp_get_irqstatus(wp);
+ hdmi_wp_set_irqstatus(wp, irqstatus);
+
+ if ((irqstatus HDMI_IRQ_LINK_CONNECT)
+ irqstatus HDMI_IRQ_LINK_DISCONNECT) {
+ /*
+* If we get both connect and disconnect interrupts at the same
+* time, turn off the PHY, clear interrupts, and restart, which
+* raises connect interrupt if a cable is connected, or nothing
+* if cable is not connected.
+*/
+ hdmi_wp_set_phy_pwr(wp, HDMI_PHYPWRCMD_OFF);
+
+ hdmi_wp_set_irqstatus(wp, HDMI_IRQ_LINK_CONNECT |
+ HDMI_IRQ_LINK_DISCONNECT);
+
+ hdmi_wp_set_phy_pwr(wp, HDMI_PHYPWRCMD_LDOON);
+ } else if (irqstatus HDMI_IRQ_LINK_CONNECT) {
+ hdmi_wp_set_phy_pwr(wp, HDMI_PHYPWRCMD_TXON);
+ } else if (irqstatus HDMI_IRQ_LINK_DISCONNECT) {
+ hdmi_wp_set_phy_pwr(wp, HDMI_PHYPWRCMD_LDOON);
+ }
+
+ return IRQ_HANDLED;
+}
+
static int hdmi_init_regulator(void)
{
int r;
@@ -150,11 +181,16 @@ static int hdmi_power_on_full(struct omap_dss_device
*dssdev)
struct omap_video_timings *p;
struct omap_overlay_manager *mgr = hdmi.output.manager;
unsigned long phy;
+ struct hdmi_wp_data *wp = hdmi.wp;
r = hdmi_power_on_core(dssdev);
if (r)
return r;
+ /* disable and clear irqs */
+ hdmi_wp_clear_irqenable(wp, 0x);
+ hdmi_wp_set_irqstatus(wp, 0x);
+
p = hdmi.cfg.timings;
DSSDBG(hdmi_power_on x_res= %d y_res = %d\n, p-x_res, p-y_res);
@@ -171,12 +207,16 @@ static int hdmi_power_on_full(struct omap_dss_device
*dssdev)
goto err_pll_enable;
}
- r = hdmi_phy_enable(hdmi.phy, hdmi.wp, hdmi.cfg);
+ r = hdmi_phy_configure(hdmi.phy, hdmi.cfg);
if (r) {
- DSSDBG(Failed to start PHY\n);
- goto err_phy_enable;
+ DSSDBG(Failed to configure PHY\n);
+ goto err_phy_cfg;
}
+ r = hdmi_wp_set_phy_pwr(wp, HDMI_PHYPWRCMD_LDOON);
+ if (r)
+ goto
[PATCH 11/23] ARM: dts: omap5-uevm.dts: add tca6424a
omap5-uevm has a tca6424a I/O expander. Add it to the .dts file.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap5-uevm.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 3b99ec25b748..9e7581eaeb23 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -434,6 +434,13 @@
pinctrl-0 = i2c5_pins;
clock-frequency = 40;
+
+ tca6424a: tca6424a@22 {
+ compatible = ti,tca6424;
+ reg = 0x22;
+ gpio-controller;
+ #gpio-cells = 2;
+ };
};
mcbsp3 {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 23/23] Doc/DT: Add OMAP5 DSS DT bindings
Add DT binding documentation for OMAP5 Display Subsystem. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: devicet...@vger.kernel.org --- .../devicetree/bindings/video/ti,omap5-dss.txt | 96 ++ 1 file changed, 96 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/ti,omap5-dss.txt diff --git a/Documentation/devicetree/bindings/video/ti,omap5-dss.txt b/Documentation/devicetree/bindings/video/ti,omap5-dss.txt new file mode 100644 index ..38ffc8fcd816 --- /dev/null +++ b/Documentation/devicetree/bindings/video/ti,omap5-dss.txt @@ -0,0 +1,96 @@ +Texas Instruments OMAP5 Display Subsystem += + +See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic +description about OMAP Display Subsystem bindings. + +DSS Core + + +Required properties: +- compatible: ti,omap5-dss +- reg: address and length of the register space +- ti,hwmods: dss_core +- clocks: handle to fclk +- clock-names: fck + +Required nodes: +- DISPC + +Optional nodes: +- DSS Submodules: RFBI, DSI, HDMI +- Video port for DPI output + +DPI Endpoint required properties: +- data-lines: number of lines used + + +DISPC +- + +Required properties: +- compatible: ti,omap5-dispc +- reg: address and length of the register space +- ti,hwmods: dss_dispc +- interrupts: the DISPC interrupt +- clocks: handle to fclk +- clock-names: fck + + +RFBI + + +Required properties: +- compatible: ti,omap5-rfbi +- reg: address and length of the register space +- ti,hwmods: dss_rfbi +- clocks: handles to fclk and iclk +- clock-names: fck, ick + +Optional nodes: +- Video port for RFBI output +- RFBI controlled peripherals + + +DSI +--- + +Required properties: +- compatible: ti,omap5-dsi +- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll' +- reg-names: proto, phy, pll +- interrupts: the DSI interrupt line +- ti,hwmods: dss_dsi1 or dss_dsi2 +- vdd-supply: power supply for DSI +- clocks: handles to fclk and pll clock +- clock-names: fck, sys_clk + +Optional nodes: +- Video port for DSI output +- DSI controlled peripherals + +DSI Endpoint required properties: +- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-, + DATA1+, DATA1-, ... + + +HDMI + + +Required properties: +- compatible: ti,omap5-hdmi +- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy', + 'core' +- reg-names: wp, pll, phy, core +- interrupts: the HDMI interrupt line +- ti,hwmods: dss_hdmi +- vdda-supply: vdda power supply +- clocks: handles to fclk and pll clock +- clock-names: fck, sys_clk + +Optional nodes: +- Video port for HDMI output + +HDMI Endpoint optional properties: +- lanes: list of 8 pin numbers for the HDMI lanes: CLK+, CLK-, D0+, D0-, + D1+, D1-, D2+, D2-. (default: 0,1,2,3,4,5,6,7) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/23] OMAPDSS: HDMI4: set regulator voltage to 1.8V
Set the HDMI vdda regulator voltage to the required 1.8V.
This is required for the case when the regulator in the DT data defines
a range of allowed voltages. In this case it's required to set the
voltage, as otherwise enabling the voltage fails.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/hdmi4.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi4.c
b/drivers/video/fbdev/omap2/dss/hdmi4.c
index e15b89d49c28..5c7dd5c06593 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi4.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi4.c
@@ -83,6 +83,7 @@ static void hdmi_runtime_put(void)
static int hdmi_init_regulator(void)
{
+ int r;
struct regulator *reg;
if (hdmi.vdda_hdmi_dac_reg != NULL)
@@ -96,6 +97,15 @@ static int hdmi_init_regulator(void)
return PTR_ERR(reg);
}
+ if (regulator_can_change_voltage(reg)) {
+ r = regulator_set_voltage(reg, 180, 180);
+ if (r) {
+ devm_regulator_put(reg);
+ DSSWARN(can't set the regulator voltage\n);
+ return r;
+ }
+ }
+
hdmi.vdda_hdmi_dac_reg = reg;
return 0;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/23] OMAPDSS: DSS DISPC DT support for OMAP5
Add omap5 entries to dispc's and dss's of_device_id tables.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/dispc.c | 1 +
drivers/video/fbdev/omap2/dss/dss.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/dispc.c
b/drivers/video/fbdev/omap2/dss/dispc.c
index f18397c33e8f..82a6ee9930a0 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -3829,6 +3829,7 @@ static const struct of_device_id dispc_of_match[] = {
{ .compatible = ti,omap2-dispc, },
{ .compatible = ti,omap3-dispc, },
{ .compatible = ti,omap4-dispc, },
+ { .compatible = ti,omap5-dispc, },
{},
};
diff --git a/drivers/video/fbdev/omap2/dss/dss.c
b/drivers/video/fbdev/omap2/dss/dss.c
index d55266c0e029..ae870a569ddf 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -946,6 +946,7 @@ static const struct of_device_id dss_of_match[] = {
{ .compatible = ti,omap2-dss, },
{ .compatible = ti,omap3-dss, },
{ .compatible = ti,omap4-dss, },
+ { .compatible = ti,omap5-dss, },
{},
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/23] ARM: dts: omap5-uevm.dts: add display nodes
omap5-uevm has a single HDMI output. Add the necessary display
information, including pinmuxing.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap5-uevm.dts | 82
1 file changed, 82 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 9e7581eaeb23..f625a8708567 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -183,6 +183,19 @@
;
};
+ dss_hdmi_pins: pinmux_dss_hdmi_pins {
+ pinctrl-single,pins =
+ 0x0fc (PIN_INPUT_PULLUP | MUX_MODE0)/*
hdmi_cec.hdmi_cec */
+ 0x100 (PIN_INPUT | MUX_MODE0) /*
hdmi_ddc_scl.hdmi_ddc_scl */
+ 0x102 (PIN_INPUT | MUX_MODE0) /*
hdmi_ddc_sda.hdmi_ddc_sda */
+ ;
+ };
+
+ tpd12s015_pins: pinmux_tpd12s015_pins {
+ pinctrl-single,pins =
+ 0x0fe (PIN_INPUT_PULLDOWN | MUX_MODE6) /*
hdmi_hpd.gpio7_193 */
+ ;
+ };
};
omap5_pmx_wkup {
@@ -498,3 +511,72 @@
cpu0 {
cpu0-supply = smps123_reg;
};
+
+/ {
+ aliases {
+ display0 = hdmi0;
+ };
+
+ tpd12s015: encoder@0 {
+ compatible = ti,tpd12s015;
+
+ pinctrl-names = default;
+ pinctrl-0 = tpd12s015_pins;
+
+ gpios = tca6424a 0 GPIO_ACTIVE_HIGH, /* TCA6424A P01, CT CP
HPD */
+ tca6424a 1 GPIO_ACTIVE_HIGH, /* TCA6424A P00, LS OE
*/
+ gpio7 1 GPIO_ACTIVE_HIGH;/* GPIO 193, HPD */
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ tpd12s015_in: endpoint@0 {
+ remote-endpoint = hdmi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ tpd12s015_out: endpoint@0 {
+ remote-endpoint = hdmi_connector_in;
+ };
+ };
+ };
+ };
+
+ hdmi0: connector@0 {
+ compatible = hdmi-connector;
+ label = hdmi;
+
+ type = b;
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = tpd12s015_out;
+ };
+ };
+ };
+};
+
+dss {
+ status = ok;
+};
+
+hdmi {
+ status = ok;
+ vdda-supply = ldo4_reg;
+
+ pinctrl-names = default;
+ pinctrl-0 = dss_hdmi_pins;
+
+ port {
+ hdmi_out: endpoint {
+ remote-endpoint = tpd12s015_in;
+ };
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/23] ARM: OMAP: hwmod: OMAP5 DSS hwmod data
From: Archit Taneja arc...@ti.com
Add hwmod data for dss core, dispc dsi1, dsi2, rfbi and hdmi. It's more
or less similar to omap4 hwmod data.
Signed-off-by: Archit Taneja arc...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 283 +
1 file changed, 283 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 892317294fdc..e8bdd7a91090 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -334,6 +334,235 @@ static struct omap_hwmod omap54xx_dmic_hwmod = {
};
/*
+ * 'dss' class
+ * display sub-system
+ */
+static struct omap_hwmod_class_sysconfig omap54xx_dss_sysc = {
+ .rev_offs = 0x,
+ .syss_offs = 0x0014,
+ .sysc_flags = SYSS_HAS_RESET_STATUS,
+};
+
+static struct omap_hwmod_class omap54xx_dss_hwmod_class = {
+ .name = dss,
+ .sysc = omap54xx_dss_sysc,
+ .reset = omap_dss_reset,
+};
+
+/* dss */
+static struct omap_hwmod_opt_clk dss_opt_clks[] = {
+ { .role = 32khz_clk, .clk = dss_32khz_clk },
+ { .role = sys_clk, .clk = dss_sys_clk },
+ { .role = hdmi_clk, .clk = dss_48mhz_clk },
+};
+
+static struct omap_hwmod omap54xx_dss_hwmod = {
+ .name = dss_core,
+ .class = omap54xx_dss_hwmod_class,
+ .clkdm_name = dss_clkdm,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+ .main_clk = dss_dss_clk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET,
+ .context_offs = OMAP54XX_RM_DSS_DSS_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+ .opt_clks = dss_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(dss_opt_clks),
+};
+
+/*
+ * 'dispc' class
+ * display controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_dispc_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_MIDLEMODE |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_dispc_hwmod_class = {
+ .name = dispc,
+ .sysc = omap54xx_dispc_sysc,
+};
+
+/* dss_dispc */
+static struct omap_hwmod_opt_clk dss_dispc_opt_clks[] = {
+ { .role = sys_clk, .clk = dss_sys_clk },
+};
+
+/* dss_dispc dev_attr */
+static struct omap_dss_dispc_dev_attr dss_dispc_dev_attr = {
+ .has_framedonetv_irq= 1,
+ .manager_count = 4,
+};
+
+static struct omap_hwmod omap54xx_dss_dispc_hwmod = {
+ .name = dss_dispc,
+ .class = omap54xx_dispc_hwmod_class,
+ .clkdm_name = dss_clkdm,
+ .main_clk = dss_dss_clk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET,
+ .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
+ },
+ },
+ .opt_clks = dss_dispc_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(dss_dispc_opt_clks),
+ .dev_attr = dss_dispc_dev_attr,
+};
+
+/*
+ * 'dsi1' class
+ * display serial interface controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_dsi1_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_dsi1_hwmod_class = {
+ .name = dsi1,
+ .sysc = omap54xx_dsi1_sysc,
+};
+
+/* dss_dsi1_a */
+static struct omap_hwmod_opt_clk dss_dsi1_a_opt_clks[] = {
+ { .role = sys_clk, .clk = dss_sys_clk },
+};
+
+static struct omap_hwmod omap54xx_dss_dsi1_a_hwmod = {
+ .name = dss_dsi1,
+ .class = omap54xx_dsi1_hwmod_class,
+ .clkdm_name = dss_clkdm,
+ .main_clk = dss_dss_clk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET,
+ .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
+ },
+ },
+ .opt_clks =
[PATCH 08/23] ARM: dts: omap5-clocks.dtsi: add dss iclk
Add missing DSS interface clock node.
Note: The TRM says DSS's interface clock is DSS_L3_GICLK, but it is not
clear to me from reading the TRM and looking at the
arch/arm/boot/dts/omap54xx-clocks.dtsi whether using 'l3_iclk_div' as
the parent for 'dss_l3_iclk' is the correct clock.
The clock is explicitly used only by the RFBI, and we don't have any
boards using the RFBI, so I have no means to test it.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/boot/dts/omap54xx-clocks.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi
b/arch/arm/boot/dts/omap54xx-clocks.dtsi
index d487fdab3921..26c02f9e92c4 100644
--- a/arch/arm/boot/dts/omap54xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi
@@ -418,6 +418,14 @@
clock-div = 1;
};
+ dss_l3_iclk: dss_l3_iclk {
+ #clock-cells = 0;
+ compatible = fixed-factor-clock;
+ clocks = l3_iclk_div;
+ clock-mult = 1;
+ clock-div = 1;
+ };
+
slimbus1_slimbus_clk: slimbus1_slimbus_clk {
#clock-cells = 0;
compatible = ti,gate-clock;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/23] ARM: OMAP: add detection of omap5-dss
Add detection of omap5-dss nodes so that the related devices get initialized. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/display.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c index 974461441fc3..74869326dadc 100644 --- a/arch/arm/mach-omap2/display.c +++ b/arch/arm/mach-omap2/display.c @@ -665,6 +665,10 @@ struct device_node * __init omapdss_find_dss_of_node(void) if (node) return node; + node = of_find_compatible_node(NULL, NULL, ti,omap5-dss); + if (node) + return node; + return NULL; } -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/23] OMAPDSS: HDMI: lane config support
Add support to configure the pins used for the HDMI lanes. The order and
polarity of the lanes can be defined in the DT data.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/hdmi.h| 6 ++
drivers/video/fbdev/omap2/dss/hdmi4.c | 28 +
drivers/video/fbdev/omap2/dss/hdmi_common.c | 41 +
drivers/video/fbdev/omap2/dss/hdmi_phy.c| 94 -
4 files changed, 167 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h
b/drivers/video/fbdev/omap2/dss/hdmi.h
index e25681ff5a70..4e5c44e7eeb3 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -352,6 +352,9 @@ struct hdmi_phy_data {
void __iomem *base;
int irq;
+
+ u8 lane_function[4];
+ u8 lane_polarity[4];
};
struct hdmi_core_data {
@@ -422,11 +425,14 @@ int hdmi_phy_enable(struct hdmi_phy_data *phy, struct
hdmi_wp_data *wp,
void hdmi_phy_disable(struct hdmi_phy_data *phy, struct hdmi_wp_data *wp);
void hdmi_phy_dump(struct hdmi_phy_data *phy, struct seq_file *s);
int hdmi_phy_init(struct platform_device *pdev, struct hdmi_phy_data *phy);
+int hdmi_phy_parse_lanes(struct hdmi_phy_data *phy, const u32 *lanes);
/* HDMI common funcs */
const struct hdmi_config *hdmi_default_timing(void);
const struct hdmi_config *hdmi_get_timings(int mode, int code);
struct hdmi_cm hdmi_get_code(struct omap_video_timings *timing);
+int hdmi_parse_lanes_of(struct platform_device *pdev, struct device_node *ep,
+ struct hdmi_phy_data *phy);
#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
int hdmi_compute_acr(u32 pclk, u32 sample_freq, u32 *n, u32 *cts);
diff --git a/drivers/video/fbdev/omap2/dss/hdmi4.c
b/drivers/video/fbdev/omap2/dss/hdmi4.c
index f5f7944a1fd1..e15b89d49c28 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi4.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi4.c
@@ -600,6 +600,28 @@ static void __exit hdmi_uninit_output(struct
platform_device *pdev)
omapdss_unregister_output(out);
}
+static int hdmi_probe_of(struct platform_device *pdev)
+{
+ struct device_node *node = pdev-dev.of_node;
+ struct device_node *ep;
+ int r;
+
+ ep = omapdss_of_get_first_endpoint(node);
+ if (!ep)
+ return 0;
+
+ r = hdmi_parse_lanes_of(pdev, ep, hdmi.phy);
+ if (r)
+ goto err;
+
+ of_node_put(ep);
+ return 0;
+
+err:
+ of_node_put(ep);
+ return r;
+}
+
/* HDMI HW IP initialisation */
static int omapdss_hdmihw_probe(struct platform_device *pdev)
{
@@ -609,6 +631,12 @@ static int omapdss_hdmihw_probe(struct platform_device
*pdev)
mutex_init(hdmi.lock);
+ if (pdev-dev.of_node) {
+ r = hdmi_probe_of(pdev);
+ if (r)
+ return r;
+ }
+
r = hdmi_wp_init(pdev, hdmi.wp);
if (r)
return r;
diff --git a/drivers/video/fbdev/omap2/dss/hdmi_common.c
b/drivers/video/fbdev/omap2/dss/hdmi_common.c
index 0b12a3f62fe1..9a2c39cf297f 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi_common.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi_common.c
@@ -17,6 +17,7 @@
#include linux/kernel.h
#include linux/err.h
+#include linux/of.h
#include video/omapdss.h
#include hdmi.h
@@ -323,6 +324,46 @@ end:
return cm;
}
+int hdmi_parse_lanes_of(struct platform_device *pdev, struct device_node *ep,
+ struct hdmi_phy_data *phy)
+{
+ struct property *prop;
+ int r, len;
+
+ prop = of_find_property(ep, lanes, len);
+ if (prop) {
+ u32 lanes[8];
+
+ if (len / sizeof(u32) != ARRAY_SIZE(lanes)) {
+ dev_err(pdev-dev, bad number of lanes\n);
+ return -EINVAL;
+ }
+
+ r = of_property_read_u32_array(ep, lanes, lanes,
+ ARRAY_SIZE(lanes));
+ if (r) {
+ dev_err(pdev-dev, failed to read lane data\n);
+ return r;
+ }
+
+ r = hdmi_phy_parse_lanes(phy, lanes);
+ if (r) {
+ dev_err(pdev-dev, failed to parse lane data\n);
+ return r;
+ }
+ } else {
+ static const u32 default_lanes[] = { 0, 1, 2, 3, 4, 5, 6, 7 };
+
+ r = hdmi_phy_parse_lanes(phy, default_lanes);
+ if (WARN_ON(r)) {
+ dev_err(pdev-dev, failed to parse lane data\n);
+ return r;
+ }
+ }
+
+ return 0;
+}
+
#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
int hdmi_compute_acr(u32 pclk, u32 sample_freq, u32 *n, u32 *cts)
{
diff --git a/drivers/video/fbdev/omap2/dss/hdmi_phy.c
b/drivers/video/fbdev/omap2/dss/hdmi_phy.c
index dd376ce8da01..c1c65624fd5d 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi_phy.c
+++
[PATCH/RFC 2/4] PM / clock_ops: Add pm_clk_add_clk()
The existing pm_clk_add() allows to pass a clock by con_id. However,
when referring to a specific clock from DT, no con_id is available.
Add pm_clk_add_clk(), which allows to specify the struct clk * directly.
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
---
drivers/base/power/clock_ops.c | 40 ++--
include/linux/pm_clock.h |3 +++
2 files changed, 33 insertions(+), 10 deletions(-)
diff --git a/drivers/base/power/clock_ops.c b/drivers/base/power/clock_ops.c
index b99e6c06ee67..2d5c9c1eceb1 100644
--- a/drivers/base/power/clock_ops.c
+++ b/drivers/base/power/clock_ops.c
@@ -53,7 +53,8 @@ static inline int __pm_clk_enable(struct device *dev, struct
clk *clk)
*/
static void pm_clk_acquire(struct device *dev, struct pm_clock_entry *ce)
{
- ce-clk = clk_get(dev, ce-con_id);
+ if (!ce-clk)
+ ce-clk = clk_get(dev, ce-con_id);
if (IS_ERR(ce-clk)) {
ce-status = PCE_STATUS_ERROR;
} else {
@@ -63,15 +64,8 @@ static void pm_clk_acquire(struct device *dev, struct
pm_clock_entry *ce)
}
}
-/**
- * pm_clk_add - Start using a device clock for power management.
- * @dev: Device whose clock is going to be used for power management.
- * @con_id: Connection ID of the clock.
- *
- * Add the clock represented by @con_id to the list of clocks used for
- * the power management of @dev.
- */
-int pm_clk_add(struct device *dev, const char *con_id)
+static int __pm_clk_add(struct device *dev, const char *con_id,
+ struct clk *clk)
{
struct pm_subsys_data *psd = dev_to_psd(dev);
struct pm_clock_entry *ce;
@@ -93,6 +87,8 @@ int pm_clk_add(struct device *dev, const char *con_id)
kfree(ce);
return -ENOMEM;
}
+ } else {
+ ce-clk = clk;
}
pm_clk_acquire(dev, ce);
@@ -102,6 +98,30 @@ int pm_clk_add(struct device *dev, const char *con_id)
spin_unlock_irq(psd-lock);
return 0;
}
+/**
+ * pm_clk_add - Start using a device clock for power management.
+ * @dev: Device whose clock is going to be used for power management.
+ * @con_id: Connection ID of the clock.
+ *
+ * Add the clock represented by @con_id to the list of clocks used for
+ * the power management of @dev.
+ */
+int pm_clk_add(struct device *dev, const char *con_id)
+{
+ return __pm_clk_add(dev, con_id, NULL);
+}
+
+/**
+ * pm_clk_add_clk - Start using a device clock for power management.
+ * @dev: Device whose clock is going to be used for power management.
+ * @clk: Clock pointer
+ *
+ * Add the clock to the list of clocks used for the power management of @dev.
+ */
+int pm_clk_add_clk(struct device *dev, struct clk *clk)
+{
+ return __pm_clk_add(dev, NULL, clk);
+}
/**
* __pm_clk_remove - Destroy PM clock entry.
diff --git a/include/linux/pm_clock.h b/include/linux/pm_clock.h
index 8348866e7b05..6981aa288c45 100644
--- a/include/linux/pm_clock.h
+++ b/include/linux/pm_clock.h
@@ -18,6 +18,8 @@ struct pm_clk_notifier_block {
char *con_ids[];
};
+struct clk;
+
#ifdef CONFIG_PM_CLK
static inline bool pm_clk_no_clocks(struct device *dev)
{
@@ -29,6 +31,7 @@ extern void pm_clk_init(struct device *dev);
extern int pm_clk_create(struct device *dev);
extern void pm_clk_destroy(struct device *dev);
extern int pm_clk_add(struct device *dev, const char *con_id);
+extern int pm_clk_add_clk(struct device *dev, struct clk *clk);
extern void pm_clk_remove(struct device *dev, const char *con_id);
extern int pm_clk_suspend(struct device *dev);
extern int pm_clk_resume(struct device *dev);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/23] OMAPDSS: DSI: set regulator voltage to 1.8V
Set the DSI vdd regulator voltage to the required 1.8V.
This is required for the case when the regulator in the DT data defines
a range of allowed voltages. In this case it's required to set the
voltage, as otherwise enabling the voltage fails.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/dsi.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/dsi.c
b/drivers/video/fbdev/omap2/dss/dsi.c
index 8be9b04d8849..57f120896b43 100644
--- a/drivers/video/fbdev/omap2/dss/dsi.c
+++ b/drivers/video/fbdev/omap2/dss/dsi.c
@@ -1161,6 +1161,7 @@ static int dsi_regulator_init(struct platform_device
*dsidev)
{
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
struct regulator *vdds_dsi;
+ int r;
if (dsi-vdds_dsi_reg != NULL)
return 0;
@@ -1173,6 +1174,15 @@ static int dsi_regulator_init(struct platform_device
*dsidev)
return PTR_ERR(vdds_dsi);
}
+ if (regulator_can_change_voltage(vdds_dsi)) {
+ r = regulator_set_voltage(vdds_dsi, 180, 180);
+ if (r) {
+ devm_regulator_put(vdds_dsi);
+ DSSERR(can't set the DSI regulator voltage\n);
+ return r;
+ }
+ }
+
dsi-vdds_dsi_reg = vdds_dsi;
return 0;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core
When adding a device from DT, check if its clocks are suitable for Runtime
PM, and register them with the PM core.
If Runtime PM is disabled, just enable the clock.
This allows the PM core to automatically manage gate clocks of devices for
Runtime PM.
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
---
drivers/of/Makefile|1 +
drivers/of/of_clk.c| 103
drivers/of/platform.c |3 ++
include/linux/of_clk.h | 18 +
4 files changed, 125 insertions(+)
create mode 100644 drivers/of/of_clk.c
create mode 100644 include/linux/of_clk.h
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index ed9660adad77..49bcd413906f 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
obj-$(CONFIG_OF_MTD) += of_mtd.o
obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
+obj-$(CONFIG_COMMON_CLK) += of_clk.o
diff --git a/drivers/of/of_clk.c b/drivers/of/of_clk.c
new file mode 100644
index ..35f5e9f3dd42
--- /dev/null
+++ b/drivers/of/of_clk.c
@@ -0,0 +1,103 @@
+/*
+ * Copyright (C) 2014 Glider bvba
+ */
+
+#include linux/clk.h
+#include linux/err.h
+#include linux/of.h
+#include linux/of_clk.h
+#include linux/platform_device.h
+#include linux/pm_clock.h
+#include linux/pm_runtime.h
+
+
+#ifdef CONFIG_PM_RUNTIME
+
+static int of_clk_pm_runtime_suspend(struct device *dev)
+{
+ int ret;
+
+ ret = pm_generic_runtime_suspend(dev);
+ if (ret)
+ return ret;
+
+ ret = pm_clk_suspend(dev);
+ if (ret) {
+ pm_generic_runtime_resume(dev);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int of_clk_pm_runtime_resume(struct device *dev)
+{
+ pm_clk_resume(dev);
+ return pm_generic_runtime_resume(dev);
+}
+
+static struct dev_pm_domain of_clk_pm_domain = {
+ .ops = {
+ .runtime_suspend = of_clk_pm_runtime_suspend,
+ .runtime_resume = of_clk_pm_runtime_resume,
+ USE_PLATFORM_PM_SLEEP_OPS
+ },
+};
+
+static int of_clk_register(struct device *dev, struct clk *clk)
+{
+ int error;
+
+ if (!dev-pm_domain) {
+ error = pm_clk_create(dev);
+ if (error)
+ return error;
+
+ dev-pm_domain = of_clk_pm_domain;
+ }
+
+ dev_dbg(dev, Setting up clock for runtime PM management\n);
+ return pm_clk_add_clk(dev, clk);
+}
+
+#else /* !CONFIG_PM_RUNTIME */
+
+static int of_clk_register(struct device *dev, struct clk *clk)
+{
+ dev_dbg(dev, Runtime PM disabled, enabling clock\n);
+ return clk_prepare_enable(clk);
+}
+
+#endif /* !CONFIG_PM_RUNTIME */
+
+
+/**
+ * of_clk_register_runtime_pm_clocks - Register clocks suitable for Runtime PM
+ * with the PM core
+ * @np: pointer to device tree node
+ * @pdev: pointer to corresponding device to register suitable clocks for
+ *
+ * Returns an error code
+ */
+int of_clk_register_runtime_pm_clocks(struct device_node *np,
+ struct device *dev)
+{
+ unsigned int i;
+ struct clk *clk;
+ int error;
+
+ for (i = 0; (clk = of_clk_get(np, i)) !IS_ERR(clk); i++) {
+ if (!clk_may_runtime_pm(clk)) {
+ clk_put(clk);
+ continue;
+ }
+
+ error = of_clk_register(dev, clk);
+ if (error) {
+ clk_put(clk);
+ return error;
+ }
+ }
+
+ return 0;
+}
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 404d1daebefa..29145302b6f8 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -18,6 +18,7 @@
#include linux/dma-mapping.h
#include linux/slab.h
#include linux/of_address.h
+#include linux/of_clk.h
#include linux/of_device.h
#include linux/of_irq.h
#include linux/of_platform.h
@@ -182,6 +183,8 @@ struct platform_device *of_device_alloc(struct device_node
*np,
else
of_device_make_bus_id(dev-dev);
+ of_clk_register_runtime_pm_clocks(np, dev-dev);
+
return dev;
}
EXPORT_SYMBOL(of_device_alloc);
diff --git a/include/linux/of_clk.h b/include/linux/of_clk.h
new file mode 100644
index ..b9b15614e39b
--- /dev/null
+++ b/include/linux/of_clk.h
@@ -0,0 +1,18 @@
+#ifndef _LINUX_OF_CLK_H
+#define _LINUX_OF_CLK_H
+
+struct device_node;
+struct device;
+
+#if defined(CONFIG_OF) defined(CONFIG_COMMON_CLK)
+int of_clk_register_runtime_pm_clocks(struct device_node *np,
+ struct device *dev);
+#else
+static inline int of_clk_register_runtime_pm_clocks(struct device_node *np,
+ struct device *dev)
+{
+ return 0;
+}
+#endif /* CONFIG_OF CONFIG_COMMON_CLK */
+
+#endif /*
[PATCH/RFC 1/4] clk: Add CLK_RUNTIME_PM and clk_may_runtime_pm()
Add a flag CLK_RUNTIME_PM, to let low-level clock drivers indicate that
a clock is suitable for Runtime PM.
Add clk_may_runtime_pm(), to get the status of the flag.
This will allow the device core to enable automatic Runtime PM management
for devices tied to clocks that are suitable for Runtime PM.
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
---
drivers/clk/clk.c| 12
include/linux/clk-provider.h |1 +
include/linux/clk.h |1 +
3 files changed, 14 insertions(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 0b2819551756..a83a2cc0af67 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1115,6 +1115,18 @@ long clk_get_accuracy(struct clk *clk)
EXPORT_SYMBOL_GPL(clk_get_accuracy);
/**
+ * clk_may_runtime_pm - check if the clock is suitable for Runtime PM
+ * @clk: the clock to check
+ *
+ * Return true if the clock is suitable for Runtime PM
+ * Return false if clk is NULL, or if the clock is not suitable for Runtime PM.
+ */
+bool clk_may_runtime_pm(const struct clk *clk)
+{
+ return clk clk-flags CLK_RUNTIME_PM;
+}
+
+/**
* __clk_recalc_rates
* @clk: first clk in the subtree
* @msg: notification type (see include/linux/clk.h)
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 24c8ba4fa6ae..3ca9a7c1f02d 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -30,6 +30,7 @@
#define CLK_GET_RATE_NOCACHE BIT(6) /* do not use the cached clk rate */
#define CLK_SET_RATE_NO_REPARENT BIT(7) /* don't re-parent on rate change */
#define CLK_GET_ACCURACY_NOCACHE BIT(8) /* do not use the cached clk accuracy
*/
+#define CLK_RUNTIME_PM BIT(9) /* clock is suitable for Runtime PM */
struct clk_hw;
struct dentry;
diff --git a/include/linux/clk.h b/include/linux/clk.h
index d030fce1d77e..07f156580064 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -106,6 +106,7 @@ int clk_notifier_unregister(struct clk *clk, struct
notifier_block *nb);
*/
long clk_get_accuracy(struct clk *clk);
+bool clk_may_runtime_pm(const struct clk *clk);
#else /* !CONFIG_COMMON_CLK */
static inline long clk_get_accuracy(struct clk *clk)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 4/4] clk: shmobile: mstp: Set CLK_RUNTIME_PM flag
Renesas MSTP (Module Stop) clocks are suitable for Runtime PM. Hence set the CLK_RUNTIME_PM flag, to make of_clk enable automatic Runtime PM management for DT devices that are tied to an MSTP clock. Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be --- drivers/clk/shmobile/clk-mstp.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/shmobile/clk-mstp.c b/drivers/clk/shmobile/clk-mstp.c index 2e3c08fff173..6f860bad551e 100644 --- a/drivers/clk/shmobile/clk-mstp.c +++ b/drivers/clk/shmobile/clk-mstp.c @@ -139,7 +139,7 @@ cpg_mstp_clock_register(const char *name, const char *parent_name, init.name = name; init.ops = cpg_mstp_clock_ops; - init.flags = CLK_IS_BASIC | CLK_SET_RATE_PARENT; + init.flags = CLK_IS_BASIC | CLK_SET_RATE_PARENT | CLK_RUNTIME_PM; init.parent_names = parent_name; init.num_parents = 1; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 0/4] of: Register clocks for Runtime PM with PM core
On SoCs like ARM/SH-mobile, gate clocks are available for modules, allowing
Runtime PM for a device controlled by a gate clock.
On legacy shmobile kernels, this is handled by the PM runtime code in
drivers/sh/pm_runtime.c, which installs a clock notifier for the platform
bus, registering the NULL clock of each platform device with the PM core.
This approach is also used on davinci, keystone, and omap1.
On multi-platform shmobile kernels, this was not handled at all, leading
to spurious disabled clocks on drivers relying on Runtime PM, depending on
implicit reset state, or on the bootloader.
A first solution, enabling the PM runtime code in drivers/sh/pm_runtime.c
in a multi-platform-safe way, was provided by the patch series
[PATCH v2 00/17] ARM: shmobile: Enable drivers/sh/pm_runtime.c on
multi-platform (http://www.spinics.net/lists/linux-sh/msg30887.html).
Here is an alternative approach, avoiding the reliance on C board files,
which are being phased out.
This is also related to a patch series by Felipe Balbi ([RFC/PATCH] base:
platform: add generic clock handling for platform-bus,
https://lkml.org/lkml/2014/1/31/290)
This series:
1. Lets the MSTP clock driver indicate that its clocks are suitable for
Runtime PM,
2. Lets the DT code retrieve clock information when adding a device
(it already retrieves information for resources (registers, irq) ---
unfortunately clocks are not resources), and registering clocks
suitable for Runtime PM with the PM core.
If Runtime PM is disabled, the clocks are just enabled.
Note that this works for devices instantiated from DT only.
Fortunately the drivers for the remaining platform devices (SCI and CMT)
handle clocks theirselves, without Runtime PM, so they get properly enabled.
Patches:
- [1/4] clk: Add CLK_RUNTIME_PM and clk_may_runtime_pm()
- [2/4] PM / clock_ops: Add pm_clk_add_clk()
- [3/4] of/clk: Register clocks suitable for Runtime PM with the
- [4/4] clk: shmobile: mstp: Set CLK_RUNTIME_PM flag
This series was tested on Renesas r8a7791, using the Koelsch development
board.
Thanks for your comments!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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/6] ARM: davinci: Use generic runtime and clock helpers
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
---
arch/arm/mach-davinci/pm_domain.c | 34 ++
1 file changed, 2 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-davinci/pm_domain.c
b/arch/arm/mach-davinci/pm_domain.c
index 6b98413cebd6..eb2eb126fdc0 100644
--- a/arch/arm/mach-davinci/pm_domain.c
+++ b/arch/arm/mach-davinci/pm_domain.c
@@ -10,43 +10,13 @@
* warranty of any kind, whether express or implied.
*/
#include linux/init.h
-#include linux/pm_runtime.h
#include linux/pm_clock.h
#include linux/platform_device.h
-#ifdef CONFIG_PM_RUNTIME
-static int davinci_pm_runtime_suspend(struct device *dev)
-{
- int ret;
-
- dev_dbg(dev, %s\n, __func__);
-
- ret = pm_generic_runtime_suspend(dev);
- if (ret)
- return ret;
-
- ret = pm_clk_suspend(dev);
- if (ret) {
- pm_generic_runtime_resume(dev);
- return ret;
- }
-
- return 0;
-}
-
-static int davinci_pm_runtime_resume(struct device *dev)
-{
- dev_dbg(dev, %s\n, __func__);
-
- pm_clk_resume(dev);
- return pm_generic_runtime_resume(dev);
-}
-#endif
-
static struct dev_pm_domain davinci_pm_domain = {
.ops = {
- SET_RUNTIME_PM_OPS(davinci_pm_runtime_suspend,
- davinci_pm_runtime_resume, NULL)
+ SET_RUNTIME_PM_OPS(pm_generic_runtime_clk_suspend,
+ pm_generic_clk_runtime_resume, NULL)
USE_PLATFORM_PM_SLEEP_OPS
},
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] ARM: omap: Use generic runtime and clock helpers
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
---
arch/arm/mach-omap1/pm_bus.c | 32 ++--
1 file changed, 2 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap1/pm_bus.c b/arch/arm/mach-omap1/pm_bus.c
index 3f2d39672393..e2d4b93580d1 100644
--- a/arch/arm/mach-omap1/pm_bus.c
+++ b/arch/arm/mach-omap1/pm_bus.c
@@ -12,7 +12,6 @@
#include linux/init.h
#include linux/kernel.h
#include linux/io.h
-#include linux/pm_runtime.h
#include linux/pm_clock.h
#include linux/platform_device.h
#include linux/mutex.h
@@ -22,37 +21,10 @@
#include soc.h
#ifdef CONFIG_PM_RUNTIME
-static int omap1_pm_runtime_suspend(struct device *dev)
-{
- int ret;
-
- dev_dbg(dev, %s\n, __func__);
-
- ret = pm_generic_runtime_suspend(dev);
- if (ret)
- return ret;
-
- ret = pm_clk_suspend(dev);
- if (ret) {
- pm_generic_runtime_resume(dev);
- return ret;
- }
-
- return 0;
-}
-
-static int omap1_pm_runtime_resume(struct device *dev)
-{
- dev_dbg(dev, %s\n, __func__);
-
- pm_clk_resume(dev);
- return pm_generic_runtime_resume(dev);
-}
-
static struct dev_pm_domain default_pm_domain = {
.ops = {
- .runtime_suspend = omap1_pm_runtime_suspend,
- .runtime_resume = omap1_pm_runtime_resume,
+ .runtime_suspend = pm_generic_runtime_clk_suspend,
+ .runtime_resume = pm_generic_clk_runtime_resume,
USE_PLATFORM_PM_SLEEP_OPS
},
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] drivers: sh: Use generic runtime and clock helpers
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
---
This depends on drivers: sh: pm_runtime does not need idle callback and
drivers: sh: pm_runtime implementation needs to suspend and resume devices
---
drivers/sh/pm_runtime.c | 38 ++
1 file changed, 2 insertions(+), 36 deletions(-)
diff --git a/drivers/sh/pm_runtime.c b/drivers/sh/pm_runtime.c
index f0c4a384d49f..05b719637dd4 100644
--- a/drivers/sh/pm_runtime.c
+++ b/drivers/sh/pm_runtime.c
@@ -11,7 +11,6 @@
#include linux/init.h
#include linux/kernel.h
#include linux/io.h
-#include linux/pm_runtime.h
#include linux/pm_domain.h
#include linux/pm_clock.h
#include linux/platform_device.h
@@ -21,43 +20,10 @@
#include linux/slab.h
#ifdef CONFIG_PM_RUNTIME
-static int sh_pm_runtime_suspend(struct device *dev)
-{
- int ret;
-
- ret = pm_generic_runtime_suspend(dev);
- if (ret) {
- dev_err(dev, failed to suspend device\n);
- return ret;
- }
-
- ret = pm_clk_suspend(dev);
- if (ret) {
- dev_err(dev, failed to suspend clock\n);
- pm_generic_runtime_resume(dev);
- return ret;
- }
-
- return 0;
-}
-
-static int sh_pm_runtime_resume(struct device *dev)
-{
- int ret;
-
- ret = pm_clk_resume(dev);
- if (ret) {
- dev_err(dev, failed to resume clock\n);
- return ret;
- }
-
- return pm_generic_runtime_resume(dev);
-}
-
static struct dev_pm_domain default_pm_domain = {
.ops = {
- .runtime_suspend = sh_pm_runtime_suspend,
- .runtime_resume = sh_pm_runtime_resume,
+ .runtime_suspend = pm_generic_runtime_clk_suspend,
+ .runtime_resume = pm_generic_clk_runtime_resume,
USE_PLATFORM_PM_SLEEP_OPS
},
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] of/clk: Use generic runtime and clock helpers
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
---
This depends on of/clk: Register clocks suitable for Runtime PM with the
PM core
---
drivers/of/of_clk.c | 28 ++--
1 file changed, 2 insertions(+), 26 deletions(-)
diff --git a/drivers/of/of_clk.c b/drivers/of/of_clk.c
index 35f5e9f3dd42..3e8561dce998 100644
--- a/drivers/of/of_clk.c
+++ b/drivers/of/of_clk.c
@@ -8,38 +8,14 @@
#include linux/of_clk.h
#include linux/platform_device.h
#include linux/pm_clock.h
-#include linux/pm_runtime.h
#ifdef CONFIG_PM_RUNTIME
-static int of_clk_pm_runtime_suspend(struct device *dev)
-{
- int ret;
-
- ret = pm_generic_runtime_suspend(dev);
- if (ret)
- return ret;
-
- ret = pm_clk_suspend(dev);
- if (ret) {
- pm_generic_runtime_resume(dev);
- return ret;
- }
-
- return 0;
-}
-
-static int of_clk_pm_runtime_resume(struct device *dev)
-{
- pm_clk_resume(dev);
- return pm_generic_runtime_resume(dev);
-}
-
static struct dev_pm_domain of_clk_pm_domain = {
.ops = {
- .runtime_suspend = of_clk_pm_runtime_suspend,
- .runtime_resume = of_clk_pm_runtime_resume,
+ .runtime_suspend = pm_generic_runtime_clk_suspend,
+ .runtime_resume = pm_generic_clk_runtime_resume,
USE_PLATFORM_PM_SLEEP_OPS
},
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] ARM: keystone: Use generic runtime and clock helpers
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
---
arch/arm/mach-keystone/pm_domain.c | 35 ++-
1 file changed, 2 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-keystone/pm_domain.c
b/arch/arm/mach-keystone/pm_domain.c
index ca79ddac38bc..f9e36c73b6fc 100644
--- a/arch/arm/mach-keystone/pm_domain.c
+++ b/arch/arm/mach-keystone/pm_domain.c
@@ -13,46 +13,15 @@
*/
#include linux/init.h
-#include linux/pm_runtime.h
#include linux/pm_clock.h
#include linux/platform_device.h
#include linux/clk-provider.h
#include linux/of.h
-#ifdef CONFIG_PM_RUNTIME
-static int keystone_pm_runtime_suspend(struct device *dev)
-{
- int ret;
-
- dev_dbg(dev, %s\n, __func__);
-
- ret = pm_generic_runtime_suspend(dev);
- if (ret)
- return ret;
-
- ret = pm_clk_suspend(dev);
- if (ret) {
- pm_generic_runtime_resume(dev);
- return ret;
- }
-
- return 0;
-}
-
-static int keystone_pm_runtime_resume(struct device *dev)
-{
- dev_dbg(dev, %s\n, __func__);
-
- pm_clk_resume(dev);
-
- return pm_generic_runtime_resume(dev);
-}
-#endif
-
static struct dev_pm_domain keystone_pm_domain = {
.ops = {
- SET_RUNTIME_PM_OPS(keystone_pm_runtime_suspend,
- keystone_pm_runtime_resume, NULL)
+ SET_RUNTIME_PM_OPS(pm_generic_runtime_clk_suspend,
+ pm_generic_clk_runtime_resume, NULL)
USE_PLATFORM_PM_SLEEP_OPS
},
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] PM / clock_ops: Add helpers combining generic runtime and generic clock PM
Several platform support codes combine pm_generic_runtime_suspend() and
pm_clk_suspend(), resp. pm_clk_resume() and pm_generic_runtime_resume() in
their .runtime_suspend resp. .runtime_resume callbacks.
Create helpers to consolidate.
- [1/6] PM / clock_ops: Add helpers combining generic runtime and generic
clock PM
- [2/6] ARM: davinci: Use generic runtime and clock helpers
- [3/6] ARM: keystone: Use generic runtime and clock helpers
- [4/6] ARM: omap: Use generic runtime and clock helpers
- [5/6] drivers: sh: Use generic runtime and clock helpers
- [6/6] of/clk: Use generic runtime and clock helpers
Patches 5 and 6 have dependencies (listed in the individual patches),
but they can be postponed and handled later.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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/6] PM / clock_ops: Add helpers combining generic runtime and generic clock PM
Add helpers pm_generic_runtime_clk_suspend() and
pm_generic_clk_runtime_resume(), combining generic runtime PM and generic
clock PM.
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
---
drivers/base/power/clock_ops.c | 40
include/linux/pm_clock.h |6 ++
2 files changed, 46 insertions(+)
diff --git a/drivers/base/power/clock_ops.c b/drivers/base/power/clock_ops.c
index 2d5c9c1eceb1..3cdb9fa2920d 100644
--- a/drivers/base/power/clock_ops.c
+++ b/drivers/base/power/clock_ops.c
@@ -11,6 +11,7 @@
#include linux/io.h
#include linux/pm.h
#include linux/pm_clock.h
+#include linux/pm_runtime.h
#include linux/clk.h
#include linux/slab.h
#include linux/err.h
@@ -523,3 +524,42 @@ void pm_clk_add_notifier(struct bus_type *bus,
clknb-nb.notifier_call = pm_clk_notify;
bus_register_notifier(bus, clknb-nb);
}
+
+/**
+ * pm_generic_runtime_clk_suspend - Generic runtime suspend and clock disable
+ * callback for subsystems.
+ * @dev: Device to resume.
+ */
+int pm_generic_runtime_clk_suspend(struct device *dev)
+{
+ int ret;
+
+ dev_dbg(dev, %s\n, __func__);
+
+ ret = pm_generic_runtime_suspend(dev);
+ if (ret)
+ return ret;
+
+ ret = pm_clk_suspend(dev);
+ if (ret) {
+ pm_generic_runtime_resume(dev);
+ return ret;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pm_generic_runtime_clk_suspend);
+
+/**
+ * pm_generic_clk_runtime_resume - Generic clock enable and runtime resume
+ *callback for subsystems.
+ * @dev: Device to resume.
+ */
+int pm_generic_clk_runtime_resume(struct device *dev)
+{
+ dev_dbg(dev, %s\n, __func__);
+
+ pm_clk_resume(dev);
+ return pm_generic_runtime_resume(dev);
+}
+EXPORT_SYMBOL_GPL(pm_generic_clk_runtime_resume);
diff --git a/include/linux/pm_clock.h b/include/linux/pm_clock.h
index 6981aa288c45..bf1e4d09a0ca 100644
--- a/include/linux/pm_clock.h
+++ b/include/linux/pm_clock.h
@@ -35,6 +35,8 @@ extern int pm_clk_add_clk(struct device *dev, struct clk
*clk);
extern void pm_clk_remove(struct device *dev, const char *con_id);
extern int pm_clk_suspend(struct device *dev);
extern int pm_clk_resume(struct device *dev);
+extern int pm_generic_runtime_clk_suspend(struct device *dev);
+extern int pm_generic_clk_runtime_resume(struct device *dev);
#else
static inline bool pm_clk_no_clocks(struct device *dev)
{
@@ -59,6 +61,10 @@ static inline void pm_clk_remove(struct device *dev, const
char *con_id)
}
#define pm_clk_suspend NULL
#define pm_clk_resume NULL
+static inline int pm_generic_runtime_clk_suspend(struct device *dev)
+ { return 0; }
+static inline int pm_generic_clk_runtime_resume(struct device *dev)
+ { return 0; }
#endif
#ifdef CONFIG_HAVE_CLK
--
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 1/6] PM / clock_ops: Add helpers combining generic runtime and generic clock PM
Hello. On 24-04-2014 14:26, Geert Uytterhoeven wrote: Add helpers pm_generic_runtime_clk_suspend() and pm_generic_clk_runtime_resume(), combining generic runtime PM and generic clock PM. Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be [...] diff --git a/include/linux/pm_clock.h b/include/linux/pm_clock.h index 6981aa288c45..bf1e4d09a0ca 100644 --- a/include/linux/pm_clock.h +++ b/include/linux/pm_clock.h @@ -35,6 +35,8 @@ extern int pm_clk_add_clk(struct device *dev, struct clk *clk); extern void pm_clk_remove(struct device *dev, const char *con_id); extern int pm_clk_suspend(struct device *dev); extern int pm_clk_resume(struct device *dev); +extern int pm_generic_runtime_clk_suspend(struct device *dev); +extern int pm_generic_clk_runtime_resume(struct device *dev); Shouldn't these function names be symmetric? I think '_clk' and '_runtime' need swapping in one case. WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/13] video/omap: fix modular build
From: Arnd Bergmann a...@arndb.de The framebuffer layer can be a loadable module, which forces omapfb to be a module as well. However, this breaks the lcd drivers, which are linked into the omapfb driver but each have their own module_init() function. To solve this, we split out the lcd drivers into separate modules and export omapfb_register_panel, which is the only interface required between the main omapfb driver and the lcd panel drivers. We also have to introduce a new Kconfig symbol for H3, since that lcd driver has a dependency on TPS65010, which we can express better in Kconfig than Makefile syntax. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Peter Griffin peter.grif...@linaro.org Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: linux-fb...@vger.kernel.org Cc: linux-omap@vger.kernel.org --- drivers/video/fbdev/omap/Kconfig |9 + drivers/video/fbdev/omap/Makefile | 23 --- drivers/video/fbdev/omap/omapfb_main.c |1 + include/linux/omap-dma.h |2 +- 4 files changed, 23 insertions(+), 12 deletions(-) diff --git a/drivers/video/fbdev/omap/Kconfig b/drivers/video/fbdev/omap/Kconfig index 0bc3a93..18c4cb0 100644 --- a/drivers/video/fbdev/omap/Kconfig +++ b/drivers/video/fbdev/omap/Kconfig @@ -39,6 +39,15 @@ config FB_OMAP_LCD_MIPID the Mobile Industry Processor Interface DBI-C/DCS specification. (Supported LCDs: Philips LPH8923, Sharp LS041Y3) +config FB_OMAP_LCD_H3 + bool TPS65010 LCD controller on OMAP-H3 + depends on MACH_OMAP_H3 + depends on TPS65010 + default y + help + Say Y here if you want to have support for the LCD on the + H3 board. + config FB_OMAP_DMA_TUNE bool Set DMA SDRAM access priority high depends on FB_OMAP diff --git a/drivers/video/fbdev/omap/Makefile b/drivers/video/fbdev/omap/Makefile index 1927faf..732e071 100644 --- a/drivers/video/fbdev/omap/Makefile +++ b/drivers/video/fbdev/omap/Makefile @@ -10,17 +10,18 @@ objs-y$(CONFIG_FB_OMAP_LCDC_EXTERNAL) += sossi.o objs-y$(CONFIG_FB_OMAP_LCDC_HWA742) += hwa742.o -objs-y$(CONFIG_MACH_AMS_DELTA) += lcd_ams_delta.o -objs-y$(CONFIG_MACH_OMAP_H3) += lcd_h3.o -objs-y$(CONFIG_MACH_OMAP_PALMTE) += lcd_palmte.o -objs-y$(CONFIG_MACH_OMAP_PALMTT) += lcd_palmtt.o -objs-y$(CONFIG_MACH_OMAP_PALMZ71) += lcd_palmz71.o -objs-$(CONFIG_ARCH_OMAP16XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1610.o -objs-$(CONFIG_ARCH_OMAP15XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1510.o -objs-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o - -objs-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o -objs-y$(CONFIG_MACH_HERALD) += lcd_htcherald.o +lcds-y$(CONFIG_MACH_AMS_DELTA) += lcd_ams_delta.o +lcds-y$(CONFIG_FB_OMAP_LCD_H3) += lcd_h3.o +lcds-y$(CONFIG_MACH_OMAP_PALMTE) += lcd_palmte.o +lcds-y$(CONFIG_MACH_OMAP_PALMTT) += lcd_palmtt.o +lcds-y$(CONFIG_MACH_OMAP_PALMZ71) += lcd_palmz71.o +lcds-$(CONFIG_ARCH_OMAP16XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1610.o +lcds-$(CONFIG_ARCH_OMAP15XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1510.o +lcds-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o + +lcds-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o +lcds-y$(CONFIG_MACH_HERALD) += lcd_htcherald.o omapfb-objs := $(objs-yy) +obj-$(CONFIG_FB_OMAP) += $(lcds-yy) diff --git a/drivers/video/fbdev/omap/omapfb_main.c b/drivers/video/fbdev/omap/omapfb_main.c index e4fc6d9..d8d028d 100644 --- a/drivers/video/fbdev/omap/omapfb_main.c +++ b/drivers/video/fbdev/omap/omapfb_main.c @@ -1823,6 +1823,7 @@ void omapfb_register_panel(struct lcd_panel *panel) if (fbdev_pdev != NULL) omapfb_do_probe(fbdev_pdev, fbdev_panel); } +EXPORT_SYMBOL_GPL(omapfb_register_panel); /* Called when the device is being detached from the driver */ static int omapfb_remove(struct platform_device *pdev) diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h index 41a13e7..0a1a2e2 100644 --- a/include/linux/omap-dma.h +++ b/include/linux/omap-dma.h @@ -393,7 +393,7 @@ extern int omap_modify_dma_chain_params(int chain_id, extern int omap_dma_chain_status(int chain_id); #endif -#if defined(CONFIG_ARCH_OMAP1) defined(CONFIG_FB_OMAP) +#if defined(CONFIG_ARCH_OMAP1) IS_ENABLED(CONFIG_FB_OMAP) #include mach/lcd_dma.h #else static inline int omap_lcd_dma_running(void) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/13] video: omap: allow building on !MMU
From: Arnd Bergmann a...@arndb.de
The omap lcdc driver has an elaborate mmap_kern function
to map the frame buffer into kernel address space as
write-combined. This uses functions that are only available
on MMU-enabled builds.
It does seem equivalent to ioremap_wc though, so we should
be able to just use that instead.
This patch is build-tested only, it needs to be run on real
hardware before applying.
Signed-off-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Peter Griffin peter.grif...@linaro.org
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
---
drivers/video/fbdev/omap/lcdc.c | 28 +---
1 file changed, 5 insertions(+), 23 deletions(-)
diff --git a/drivers/video/fbdev/omap/lcdc.c b/drivers/video/fbdev/omap/lcdc.c
index b52f625..40e8200 100644
--- a/drivers/video/fbdev/omap/lcdc.c
+++ b/drivers/video/fbdev/omap/lcdc.c
@@ -613,29 +613,11 @@ static void lcdc_dma_handler(u16 status, void *data)
static int mmap_kern(void)
{
- struct vm_struct*kvma;
- struct vm_area_struct vma;
- pgprot_tpgprot;
- unsigned long vaddr;
-
- kvma = get_vm_area(lcdc.vram_size, VM_IOREMAP);
- if (kvma == NULL) {
- dev_err(lcdc.fbdev-dev, can't get kernel vm area\n);
+ void __iomem *vaddr;
+
+ vaddr = ioremap_wc(lcdc.vram_phys, lcdc.vram_size);
+ if (!vaddr)
return -ENOMEM;
- }
- vma.vm_mm = init_mm;
-
- vaddr = (unsigned long)kvma-addr;
- vma.vm_start = vaddr;
- vma.vm_end = vaddr + lcdc.vram_size;
-
- pgprot = pgprot_writecombine(pgprot_kernel);
- if (io_remap_pfn_range(vma, vaddr,
- lcdc.vram_phys PAGE_SHIFT,
- lcdc.vram_size, pgprot) 0) {
- dev_err(lcdc.fbdev-dev, kernel mmap for FB memory failed\n);
- return -EAGAIN;
- }
lcdc.vram_virt = (void *)vaddr;
@@ -644,7 +626,7 @@ static int mmap_kern(void)
static void unmap_kern(void)
{
- vunmap(lcdc.vram_virt);
+ iounmap(lcdc.vram_virt);
}
static int alloc_palette_ram(void)
--
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: [PATCHv3 19/41] OMAPDSS: panel-dpi: Add DT support
Hi Tomi,
On Thursday 24 April 2014 12:52:42 Tomi Valkeinen wrote:
On 18/04/14 18:51, Tony Lindgren wrote:
+ gpio = of_get_gpio(node, 0);
+ if (gpio_is_valid(gpio) || gpio == -ENOENT) {
+ ddata-enable_gpio = gpio;
+ } else {
+ dev_err(pdev-dev, failed to parse enable gpio\n);
+ return gpio;
+ }
We should set the GPIO polarity based on the OF_GPIO_ACTIVE_LOW like
gpio_backlight_probe_dt is doing.
Instead of doing it with the old gpio API, and checking the 'active'
flag everywhere, I think we can use the new gpiod API which handles the
polarity automatically.
I attached prototype patches (based on -rc2) for panel dpi using that
approach. It's a bit messier than I'd like, because for non-DT boot we
need to request the gpio using the old API, and then convert it to
gpio_desc. We can remove that code when all the boards use DT.
Just FYI, you can use the gpiod API with non-DT platforms if you register GPIO
lookup entries in board code with gpiod_add_lookup_table().
I've compiled tested this only, as I don't have DPI panels I could use.
I did try similar approach for TFP410, and it seemed to work fine.
--
Regards,
Laurent Pinchart
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core
On 24 April 2014 12:13, Geert Uytterhoeven geert+rene...@glider.be wrote:
When adding a device from DT, check if its clocks are suitable for Runtime
PM, and register them with the PM core.
If Runtime PM is disabled, just enable the clock.
This allows the PM core to automatically manage gate clocks of devices for
Runtime PM.
Normally I don't think it's a good idea to automatically manage
clocks from PM core or any other place but from the driver (and
possibly the subsystem).
The reason is simply that we hide things that normally is supposed to
be handled by the driver. Typically a cross SOC driver should work
fine both with and without a pm_domain. It should also not rely on
CONFIG_PM_RUNTIME.
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
---
drivers/of/Makefile|1 +
drivers/of/of_clk.c| 103
drivers/of/platform.c |3 ++
include/linux/of_clk.h | 18 +
4 files changed, 125 insertions(+)
create mode 100644 drivers/of/of_clk.c
create mode 100644 include/linux/of_clk.h
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index ed9660adad77..49bcd413906f 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
obj-$(CONFIG_OF_MTD) += of_mtd.o
obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
+obj-$(CONFIG_COMMON_CLK) += of_clk.o
diff --git a/drivers/of/of_clk.c b/drivers/of/of_clk.c
new file mode 100644
index ..35f5e9f3dd42
--- /dev/null
+++ b/drivers/of/of_clk.c
@@ -0,0 +1,103 @@
+/*
+ * Copyright (C) 2014 Glider bvba
+ */
+
+#include linux/clk.h
+#include linux/err.h
+#include linux/of.h
+#include linux/of_clk.h
+#include linux/platform_device.h
+#include linux/pm_clock.h
+#include linux/pm_runtime.h
+
+
+#ifdef CONFIG_PM_RUNTIME
+
+static int of_clk_pm_runtime_suspend(struct device *dev)
+{
+ int ret;
+
+ ret = pm_generic_runtime_suspend(dev);
+ if (ret)
+ return ret;
+
+ ret = pm_clk_suspend(dev);
+ if (ret) {
+ pm_generic_runtime_resume(dev);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int of_clk_pm_runtime_resume(struct device *dev)
+{
+ pm_clk_resume(dev);
+ return pm_generic_runtime_resume(dev);
+}
+
+static struct dev_pm_domain of_clk_pm_domain = {
+ .ops = {
+ .runtime_suspend = of_clk_pm_runtime_suspend,
+ .runtime_resume = of_clk_pm_runtime_resume,
+ USE_PLATFORM_PM_SLEEP_OPS
+ },
+};
+
+static int of_clk_register(struct device *dev, struct clk *clk)
+{
+ int error;
+
+ if (!dev-pm_domain) {
+ error = pm_clk_create(dev);
+ if (error)
+ return error;
+
+ dev-pm_domain = of_clk_pm_domain;
I am concerned about how this will work in conjunction with the
generic power domain.
A device can't reside in more than one pm_domain; thus I think it
would be better to always use the generic power domain and not have a
specific one for clocks. Typically the genpd should invoke
pm_clk_resume|suspend from it's runtime PM callbacks.
+ }
+
+ dev_dbg(dev, Setting up clock for runtime PM management\n);
+ return pm_clk_add_clk(dev, clk);
+}
+
+#else /* !CONFIG_PM_RUNTIME */
+
+static int of_clk_register(struct device *dev, struct clk *clk)
+{
+ dev_dbg(dev, Runtime PM disabled, enabling clock\n);
+ return clk_prepare_enable(clk);
+}
+
+#endif /* !CONFIG_PM_RUNTIME */
+
+
+/**
+ * of_clk_register_runtime_pm_clocks - Register clocks suitable for Runtime
PM
+ * with the PM core
+ * @np: pointer to device tree node
+ * @pdev: pointer to corresponding device to register suitable clocks for
+ *
+ * Returns an error code
+ */
+int of_clk_register_runtime_pm_clocks(struct device_node *np,
+ struct device *dev)
+{
+ unsigned int i;
+ struct clk *clk;
+ int error;
+
+ for (i = 0; (clk = of_clk_get(np, i)) !IS_ERR(clk); i++) {
+ if (!clk_may_runtime_pm(clk)) {
+ clk_put(clk);
+ continue;
+ }
+
+ error = of_clk_register(dev, clk);
+ if (error) {
+ clk_put(clk);
+ return error;
+ }
+ }
+
+ return 0;
+}
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 404d1daebefa..29145302b6f8 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -18,6 +18,7 @@
#include linux/dma-mapping.h
#include linux/slab.h
#include linux/of_address.h
+#include linux/of_clk.h
#include linux/of_device.h
#include linux/of_irq.h
#include linux/of_platform.h
Re: [PATCHv3 19/41] OMAPDSS: panel-dpi: Add DT support
On 24/04/14 15:44, Laurent Pinchart wrote: I attached prototype patches (based on -rc2) for panel dpi using that approach. It's a bit messier than I'd like, because for non-DT boot we need to request the gpio using the old API, and then convert it to gpio_desc. We can remove that code when all the boards use DT. Just FYI, you can use the gpiod API with non-DT platforms if you register GPIO lookup entries in board code with gpiod_add_lookup_table(). Right, but as the board files are going away, I'd rather not touch them at all if possible. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 2/4] ARM: dts: Add support for DRA72x family of devices
On Thursday 24 April 2014, Rajendra Nayak wrote: -- DRA742 - compatible = ti,dra7xx, ti,dra7 +- DRA74x + compatible = ti,dra74, ti,dra7 + +- DRA72x + compatible = ti,dra72, ti,dra7 Actually, what I meant was that you should list the fill name of the SoC, e.g. ti,dra742, not just ti,dra74. Leaving out the 'x' is not going to prevent this from breaking when you have a new dra745 that is incompatible. You can always list more strings, e.g. compatible = ti,dra745, ti,dra742, ti,dra74, ti,dra7; if you have a dra745 product that is fully compatible with dra742, but the important part here is that the first string must be the full name. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] gpio: omap: implement get_direction
On Thu, Apr 24, 2014 at 8:57 AM, yegorsli...@googlemail.com wrote:
From: Yegor Yefremov yegorsli...@googlemail.com
This patch implements gpio_chip's get_direction() routine, that
lets other drivers get particular GPIOs direction using
struct gpio_desc.
Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
Acked-by: Javier Martinez Canillas jav...@dowhile0.org
---
Changes:
v3: get rid of _get_gpio_direction() (Linus Walleij)
v2: rework return value calculation
Looks good to me, Kevin, Santosh?
Part of me wants to list Javier as maintainer for this driver.
+static int gpio_get_direction(struct gpio_chip *chip, unsigned offset)
+{
+ struct gpio_bank *bank;
+ unsigned long flags;
+ void __iomem *reg;
+ int dir;
That is a bool, actually. But no big deal.
+
+ bank = container_of(chip, struct gpio_bank, chip);
+ reg = bank-base + bank-regs-direction;
+ spin_lock_irqsave(bank-lock, flags);
+ dir = !!(readl_relaxed(reg) BIT(offset));
+ spin_unlock_irqrestore(bank-lock, flags);
+ return dir;
+}
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] gpio: omap: implement get_direction
On Thursday 24 April 2014 09:13 AM, Linus Walleij wrote: On Thu, Apr 24, 2014 at 8:57 AM, yegorsli...@googlemail.com wrote: From: Yegor Yefremov yegorsli...@googlemail.com This patch implements gpio_chip's get_direction() routine, that lets other drivers get particular GPIOs direction using struct gpio_desc. Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com Acked-by: Javier Martinez Canillas jav...@dowhile0.org --- Changes: v3: get rid of _get_gpio_direction() (Linus Walleij) v2: rework return value calculation Looks good to me, Kevin, Santosh? Looks fine to me as well. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Part of me wants to list Javier as maintainer for this driver. Am ok with it as well. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] PM / clock_ops: Add helpers combining generic runtime and generic clock PM
On 24 April 2014 12:26, Geert Uytterhoeven geert+rene...@glider.be wrote:
Several platform support codes combine pm_generic_runtime_suspend() and
pm_clk_suspend(), resp. pm_clk_resume() and pm_generic_runtime_resume() in
their .runtime_suspend resp. .runtime_resume callbacks.
Create helpers to consolidate.
- [1/6] PM / clock_ops: Add helpers combining generic runtime and generic
clock PM
How about adding the code from the above patch into the generic power
domain instead?
- [2/6] ARM: davinci: Use generic runtime and clock helpers
- [3/6] ARM: keystone: Use generic runtime and clock helpers
- [4/6] ARM: omap: Use generic runtime and clock helpers
- [5/6] drivers: sh: Use generic runtime and clock helpers
Then convert the above power domains implementations to the generic
power domain? Would that work?
Kind regards
Ulf Hansson
- [6/6] of/clk: Use generic runtime and clock helpers
Patches 5 and 6 have dependencies (listed in the individual patches),
but they can be postponed and handled later.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like
that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-pm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] regulator: core: Disable unused regulators after deferred probing is done
On Wed, Apr 23, 2014 at 06:10:50PM -0500, Nishanth Menon wrote: From: Saravana Kannan skan...@codeaurora.org regulator_init_complete does a scan of regulators which dont have always-on or consumers are automatically disabled as being unused. However, with deferred probing, late_initcall() is too soon to declare a regulator as unused as the regulator itself might not have registered due to defferal - Example: A regulator deffered due to i2bus not available which in turn is deffered due to pinctrl availability. Since deferred probing is done in late_initcall(), do the cleanup of unused regulators by regulator_init_complete in late_initcall_sync instead of late_initcall. I'll apply this however since as we discussed on IRC last night it's going to make the issues with unconfigured regulators getting powered off more severe before I do so I'll change things so that regulators with no configuration at all don't get touched by the core. signature.asc Description: Digital signature
Re: [PATCH v3] gpio: omap: implement get_direction
On Thu, Apr 24, 2014 at 8:57 AM, yegorsli...@googlemail.com wrote: From: Yegor Yefremov yegorsli...@googlemail.com This patch implements gpio_chip's get_direction() routine, that lets other drivers get particular GPIOs direction using struct gpio_desc. Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com Acked-by: Javier Martinez Canillas jav...@dowhile0.org --- Changes: v3: get rid of _get_gpio_direction() (Linus Walleij) v2: rework return value calculation This v3 version applied with Santosh's ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/23] ARM: dts: omap5-uevm.dts: add tca6424a
Hello.
On 24-04-2014 14:17, Tomi Valkeinen wrote:
omap5-uevm has a tca6424a I/O expander. Add it to the .dts file.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap5-uevm.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 3b99ec25b748..9e7581eaeb23 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -434,6 +434,13 @@
pinctrl-0 = i2c5_pins;
clock-frequency = 40;
+
+ tca6424a: tca6424a@22 {
The ePAPR standard [1] says: The name of a node should be somewhat generic,
reflecting the function of the device and not its precise programming model.
If appropriate, the name should be one of the following choices:
[...]
- gpio;
+ compatible = ti,tca6424;
+ reg = 0x22;
+ gpio-controller;
+ #gpio-cells = 2;
+ };
};
[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core
Hi Ulf,
On Thu, Apr 24, 2014 at 3:11 PM, Ulf Hansson ulf.hans...@linaro.org wrote:
+static int of_clk_register(struct device *dev, struct clk *clk)
+{
+ int error;
+
+ if (!dev-pm_domain) {
+ error = pm_clk_create(dev);
+ if (error)
+ return error;
+
+ dev-pm_domain = of_clk_pm_domain;
I am concerned about how this will work in conjunction with the
generic power domain.
A device can't reside in more than one pm_domain; thus I think it
would be better to always use the generic power domain and not have a
specific one for clocks. Typically the genpd should invoke
pm_clk_resume|suspend from it's runtime PM callbacks.
On shmobile SoCs supporting power domains, the power domain is
overridden later by calling rmobile_add_devices_to_domains() and friends.
My patch doesn't change that: the code behaved the same in the
non-multi-platform case before: dev-pm_domain as set from
drivers/sh/pm_runtime.c was overridden later.
I'll have a deeper look into the power domain code later anyway.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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: extcon-next regression ?
On Thu, Apr 24, 2014 at 05:13:09PM +0900, Chanwoo Choi wrote: Hi, On 04/24/2014 03:47 PM, Felipe Balbi wrote: Hi, On Thu, Apr 24, 2014 at 02:35:44PM +0900, Chanwoo Choi wrote: Hi Felipe, Thanks for your test and review. On 04/24/2014 03:28 AM, Felipe Balbi wrote: Hi, On Wed, Apr 23, 2014 at 12:20:52PM -0500, Felipe Balbi wrote: I've been testing extcon-next to make sure USB3 on OMAP5 will work out of the box but I see a regression when I merge your tree on top of v3.15-rc2 + Tony's DT fixes. Here's what I see (trimmed): [1.805870] palmas 0-0048: Muxing GPIO 2, PWM 0, LED 0 [1.812516] [ cut here ] [1.817387] WARNING: CPU: 0 PID: 6 at include/linux/kref.h:47 kobject_get+0x64/0x78() [1.817691] mmcblk0boot1: unknown partition table [1.830601] Modules linked in: [1.833827] CPU: 0 PID: 6 Comm: kworker/u4:0 Tainted: GW 3.15.0-rc2-00041-g3019b77 #308 [1.84] Workqueue: deferwq deferred_probe_work_func [1.848728] mmcblk0boot0: unknown partition table [1.853928] [c0015110] (unwind_backtrace) from [c0011d6c] (show_stack+0x10/0x14) [1.862086] [c0011d6c] (show_stack) from [c05426b4] (dump_stack+0x84/0x9c) [1.869667] [c05426b4] (dump_stack) from [c0040928] (warn_slowpath_common+0x6c/0x90) [1.878181] [c0040928] (warn_slowpath_common) from [c00409e8] (warn_slowpath_null+0x1c/0x24) [1.887421] [c00409e8] (warn_slowpath_null) from [c02d50c4] (kobject_get+0x64/0x78) [1.895837] [c02d50c4] (kobject_get) from [c0350188] (device_add+0x18/0x520) [1.903629] [c0350188] (device_add) from [c0462a5c] (extcon_dev_register+0x48/0x104) [1.912145] [c0462a5c] (extcon_dev_register) from [c0462b44] (devm_extcon_dev_register+0x2c/0x68) [1.921847] [c0462b44] (devm_extcon_dev_register) from [c04630c0] (palmas_usb_probe+0x110/0x304) [1.931453] [c04630c0] (palmas_usb_probe) from [c0354284] (platform_drv_probe+0x18/0x48) [1.940333] [c0354284] (platform_drv_probe) from [c0352b0c] (driver_probe_device+0x110/0x22c) [1.949664] [c0352b0c] (driver_probe_device) from [c03511a0] (bus_for_each_drv+0x58/0x8c) [1.958634] [c03511a0] (bus_for_each_drv) from [c03529c8] (device_attach+0x74/0x8c) [1.967003] [c03529c8] (device_attach) from [c035206c] (bus_probe_device+0x88/0xb0) [1.975387] [c035206c] (bus_probe_device) from [c0350590] (device_add+0x420/0x520) [1.983678] [c0350590] (device_add) from [c045a310] (of_platform_device_create_pdata+0x6c/0x8c) [1.993155] [c045a310] (of_platform_device_create_pdata) from [c045a418] (of_platform_bus_create+0xdc/0x168) [2.003818] [c045a418] (of_platform_bus_create) from [c045a5cc] (of_platform_populate+0x5c/0xa0) [2.013399] [c045a5cc] (of_platform_populate) from [c0373c78] (palmas_i2c_probe+0x30c/0x584) [2.022606] [c0373c78] (palmas_i2c_probe) from [c0352b0c] (driver_probe_device+0x110/0x22c) [2.031722] [c0352b0c] (driver_probe_device) from [c03511a0] (bus_for_each_drv+0x58/0x8c) [2.040715] [c03511a0] (bus_for_each_drv) from [c03529c8] (device_attach+0x74/0x8c) [2.049098] [c03529c8] (device_attach) from [c035206c] (bus_probe_device+0x88/0xb0) [2.057482] [c035206c] (bus_probe_device) from [c0350590] (device_add+0x420/0x520) [2.065774] [c0350590] (device_add) from [c0424020] (i2c_new_device+0x12c/0x18c) [2.073885] [c0424020] (i2c_new_device) from [c0424980] (i2c_register_adapter+0x278/0x498) [2.082903] [c0424980] (i2c_register_adapter) from [c04275c0] (omap_i2c_probe+0x4a4/0x6d0) [2.091925] [c04275c0] (omap_i2c_probe) from [c0354284] (platform_drv_probe+0x18/0x48) [2.100582] [c0354284] (platform_drv_probe) from [c0352b0c] (driver_probe_device+0x110/0x22c) [2.109883] [c0352b0c] (driver_probe_device) from [c03511a0] (bus_for_each_drv+0x58/0x8c) [2.118823] [c03511a0] (bus_for_each_drv) from [c03529c8] (device_attach+0x74/0x8c) [2.127194] [c03529c8] (device_attach) from [c035206c] (bus_probe_device+0x88/0xb0) [2.135584] [c035206c] (bus_probe_device) from [c03524ac] (deferred_probe_work_func+0x64/0x94) [2.144975] [c03524ac] (deferred_probe_work_func) from [c0058c70] (process_one_work+0x1ac/0x4cc) [2.154545] [c0058c70] (process_one_work) from [c0059b10] (worker_thread+0x114/0x3b4) [2.163119] [c0059b10] (worker_thread) from [c005f6f0] (kthread+0xd4/0xf0) [2.170695] [c005f6f0] (kthread) from [c000e3c8] (ret_from_fork+0x14/0x2c) [2.178259] ---[ end trace 3006de6450234d28 ]--- [2.183081] kobject 'palmas_usb' (eca58c38): tried to add an uninitialized object, something is seriously wrong. [2.193731] CPU: 0 PID: 6 Comm: kworker/u4:0 Tainted: GW 3.15.0-rc2-00041-g3019b77 #308 [2.203201] Workqueue: deferwq deferred_probe_work_func [
Re: [RESEND PATCH] regulator: core: Disable unused regulators after deferred probing is done
On 04/24/2014 08:34 AM, Mark Brown wrote: On Wed, Apr 23, 2014 at 06:10:50PM -0500, Nishanth Menon wrote: From: Saravana Kannan skan...@codeaurora.org regulator_init_complete does a scan of regulators which dont have always-on or consumers are automatically disabled as being unused. However, with deferred probing, late_initcall() is too soon to declare a regulator as unused as the regulator itself might not have registered due to defferal - Example: A regulator deffered due to i2bus not available which in turn is deffered due to pinctrl availability. Since deferred probing is done in late_initcall(), do the cleanup of unused regulators by regulator_init_complete in late_initcall_sync instead of late_initcall. I'll apply this however since as we discussed on IRC last night it's going to make the issues with unconfigured regulators getting powered off more severe before I do so I'll change things so that regulators with no configuration at all don't get touched by the core. Thanks Mark. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 00/19] bus: omap_l3_noc: driver cleanups and support for DRA7/AM4372
On 04/24/2014 03:55 AM, Peter Ujfalusi wrote: On 04/18/2014 12:00 AM, Nishanth Menon wrote: On 04/17/2014 03:57 PM, Santosh Shilimkar wrote: I looked at the series and its looks pretty good. Thanks for fixups, updates. For whole series, Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Thanks. Patches(including Peter's) is available here: https://github.com/nmenon/linux-2.6-playground/commits/l3noc/driver-fixes-v2 Can Tony pull this branch for 3.16 then which includes Peter's series as well ? there is just an empty commit with information about peter's patches that i lined up to differentiate the series.. I can drop it if Tony would like me to. Looking at the branch I see my patches underneath so they are in the branch. It would be great if Tony pulls this... Will be a great present to my patches (omap_l3 patches in the branch) for their 1 year anniversary of being out on the mailing list ;) Peter, can I take this as an Ack for this series? if yes, I can repost a v3 with all the acks, updates together. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/13] tty: serial: omap: remove some dead code
But I don't have discrete hardware. I have a bunch of stuff soldered onto a board with ad-hoc connections chosen to make the life of the hardware builder easy rather than chosen to make the life of the software developer easy (which I think is the correct choice). So I need to tell DT This device is plugged into this UART, and there is no DTR line, but when the UARTs DTR line would be asserted (if it had one), then I need that regulator of there turned on. or maybe I need to toggle this GPIO with exactly this pattern, while watching that GPIO to see if it is working. So I thought: 1/ give the UART a virtual DTR so it could drive any GPIO 2/ create a gpio-to-regulator driver which presented as a (virtual) gpio and responded to state changes on that GPIO by turning on or off the regulator 3/ create a dedicated driver which knows how to toggle the magic GPIO while watching the other GPIO to convince the silly device to wakeup, or go to sleep, as required, and have this appear as a (virtual) GPIO. Unless you are using it as a real' DTR line then I think this is the wrong approach. This problem actually is turning up in both PC class and ARM boxes now all over the place for three reasons I am seeing. 1. We are getting a lot of hardware moving to serial attached bluetooth/gps/etc because of the power win. In addition ACPI can describe power relationships and what is on the other end of a UART embedded in the device 2. We've got cheap hardware with modem lines being retrofitted via gpio 3. There are a subset of devices that have extra control lines beyond the usual serial port ones. These range from additional control lines for things like smartcard programmers to port muxing. I have no problem either way, just that unused code doesn't have to be sitting in the tree and I'm not entirely sure this GPIO should be handled by omap-serial.c, perhaps something more generic inside serial-core so other UART drivers can benefit from it. serial-core provides power hooks. If the goal is that this comes on when you power up the uart and goes away on the last close then the hooks are there already. If its ldisc specific then the tty layer also calls the device on ldisc changes precisely so it can make hardware specific twiddles in such cases. A set of gpios on the tty_port object would not go amiss and would also address the PC case. considering this is a BTUART device, why didn't you do this at the ldisc level ? hci_uart_open() sounds like a good choice from a quick thinking. ldiscs are hardware independent. Nothing about hardware belongs in an ldisc. Any ldisc should within reason work on any port. What I propsed when it came up ages ago was to expose some gpio settings in the tty, to provide ways for them to be set by default and also ioctls to configure them. I still think this (but moved into the tty_port as its a persistent hardware property) is a good idea now that we are starting to see more use cases than weird dongles and muxes on pre-production reference boards. With my tty and serial hat on I think a power gpio is a no-brainer even without doing the other work and therefore it should probably be described generically for a serial port in the DT as well as in the ACPI data. If you should also be able to give it a regulator to use as well that also seems to make complete sense. Alan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] mmc: host: omap_hsmmc: a few improvements
On Thursday 27 March 2014 05:34 AM, Felipe Balbi wrote: Hi, this series lets us access the newer registers introduced back in OMAP4 which give us some valid information about the OMAP HSMMC IP like max block size, support for ADMA, support for Retention. Support for Retention looks interesting, can you shed more lights on it Right now, only setting max_blk_size correctly as supporting ADMA and Retention will take a lot of work. Tested on OMAP5 uEVM. Felipe Balbi (5): mmc: host: omap_hsmmc: pass host as an argument mmc: host: omap_hsmmc: add reg_offset field mmc: host: omap_hsmmc: introduce new accessor functions mmc: host: omap_hsmmc: switch over to new accessors mmc: host: omap_hsmmc: set max_blk_size correctly drivers/mmc/host/omap_hsmmc.c | 291 ++ 1 file changed, 182 insertions(+), 109 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/23] ARM: dts: omap5-uevm.dts: add tca6424a
On 24/04/14 16:49, Sergei Shtylyov wrote:
Hello.
On 24-04-2014 14:17, Tomi Valkeinen wrote:
omap5-uevm has a tca6424a I/O expander. Add it to the .dts file.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap5-uevm.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 3b99ec25b748..9e7581eaeb23 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -434,6 +434,13 @@
pinctrl-0 = i2c5_pins;
clock-frequency = 40;
+
+tca6424a: tca6424a@22 {
The ePAPR standard [1] says: The name of a node should be somewhat
generic,
reflecting the function of the device and not its precise programming
model.
If appropriate, the name should be one of the following choices:
[...]
- gpio;
Right. I wonder what the name should be... gpio is out, as the name
should be more specific. We already have gpio1-8, which are the gpio
banks from the SoC. It could be 'gpio9', but that makes it sound it's
just one more SoC gpio bank. 'gpio-expander1'?
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 0/5] mmc: host: omap_hsmmc: a few improvements
On Thu, Apr 24, 2014 at 08:01:19PM +0530, Balaji T K wrote: On Thursday 27 March 2014 05:34 AM, Felipe Balbi wrote: Hi, this series lets us access the newer registers introduced back in OMAP4 which give us some valid information about the OMAP HSMMC IP like max block size, support for ADMA, support for Retention. Support for Retention looks interesting, can you shed more lights on it HWINFO has a bit (bit 6) which tells you whether retention is supported, it's in all TRMs since OMAP3630 or so. 6 RERETMODE Retention mode generic parameter This bit field indicates whether the retention mode is supported using the pin PIRFFRET. 0x0: Retention mode disabled 0x1: Retention mode enabled -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/5] mmc: host: omap_hsmmc: a few improvements
On Thursday 24 April 2014 08:09 PM, Felipe Balbi wrote: On Thu, Apr 24, 2014 at 08:01:19PM +0530, Balaji T K wrote: On Thursday 27 March 2014 05:34 AM, Felipe Balbi wrote: Hi, this series lets us access the newer registers introduced back in OMAP4 which give us some valid information about the OMAP HSMMC IP like max block size, support for ADMA, support for Retention. Support for Retention looks interesting, can you shed more lights on it HWINFO has a bit (bit 6) which tells you whether retention is supported, it's in all TRMs since OMAP3630 or so. 6 RERETMODE Retention mode generic parameter This bit field indicates whether the retention mode is supported using the pin PIRFFRET. 0x0: Retention mode disabled 0x1: Retention mode enabled I have seen that but just wondering how the driver can make use of it :-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] mmc: host: omap_hsmmc: a few improvements
On Thu, Apr 24, 2014 at 08:13:16PM +0530, Balaji T K wrote: On Thursday 24 April 2014 08:09 PM, Felipe Balbi wrote: On Thu, Apr 24, 2014 at 08:01:19PM +0530, Balaji T K wrote: On Thursday 27 March 2014 05:34 AM, Felipe Balbi wrote: Hi, this series lets us access the newer registers introduced back in OMAP4 which give us some valid information about the OMAP HSMMC IP like max block size, support for ADMA, support for Retention. Support for Retention looks interesting, can you shed more lights on it HWINFO has a bit (bit 6) which tells you whether retention is supported, it's in all TRMs since OMAP3630 or so. 6 RERETMODE Retention mode generic parameter This bit field indicates whether the retention mode is supported using the pin PIRFFRET. 0x0: Retention mode disabled 0x1: Retention mode enabled I have seen that but just wondering how the driver can make use of it :-) oh, perhaps you can use to conditionally save context. The difficulty is knowing if we're going to RET or OFF, but that could be extrapolated from pm_qos, perhaps ?!? just a thought. -- balbi signature.asc Description: Digital signature
Re: [PATCH] clk: ti: clk-7xx: Correct ABE DPLL configuration
On 04/24/2014 12:11 PM, Peter Ujfalusi wrote: Mike, Tero, On 04/03/2014 09:29 AM, Peter Ujfalusi wrote: On 04/02/2014 05:12 PM, Tero Kristo wrote: On 04/02/2014 04:48 PM, Peter Ujfalusi wrote: ABE DPLL frequency need to be lowered from 361267200 to 180633600 to facilitate the ATL requironments. The dpll_abe_m2x2_ck clock need to be set to double of ABE DPLL rate in order to have correct clocks for audio. Do you have some sort of TRM reference for this? The ATL's max divider is 32. For audio purpose the clock coming out from the ATL instance should be 128 * fs. It is only possible to have 44.1KHz sampling rate with ABE DPLL set to 361267200 or 180633600. Which means: The atl generated clock should be 128 * 44100 = 5644800 From ABE_DPLL 361267200 we would need to have 64 as divider (ATL can't do this). From the suggested ABE_DPLL of 180633600 we can use ATL divider of 32, which is the maximum it can do. So the reason for the change is to have ATLPCLK clock which can be used for audio in the future, the 361267200 is just too high. Tero: can I have your ack for this patch or do you have further concerns? Yea looks good to me, except for the fact that there is some work on getting default rate/parent support through DT. I would like a comment from Mike about the estimate when this can get in, and whether we should merge intermediate solutions still like this. Anyway, you can consider this patch acked by me, I'll let Mike to decide what to do with it though. -Tero Mike: do you want me to resend this patch? Thanks, Péter -Tero Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- drivers/clk/ti/clk-7xx.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c index f7e40734c819..19a55bf407dd 100644 --- a/drivers/clk/ti/clk-7xx.c +++ b/drivers/clk/ti/clk-7xx.c @@ -16,7 +16,7 @@ #include linux/clkdev.h #include linux/clk/ti.h -#define DRA7_DPLL_ABE_DEFFREQ361267200 +#define DRA7_DPLL_ABE_DEFFREQ180633600 #define DRA7_DPLL_GMAC_DEFFREQ10 @@ -322,6 +322,11 @@ int __init dra7xx_dt_clk_init(void) if (rc) pr_err(%s: failed to configure ABE DPLL!\n, __func__); +dpll_ck = clk_get_sys(NULL, dpll_abe_m2x2_ck); +rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ * 2); +if (rc) +pr_err(%s: failed to configure ABE DPLL m2x2!\n, __func__); + dpll_ck = clk_get_sys(NULL, dpll_gmac_ck); rc = clk_set_rate(dpll_ck, DRA7_DPLL_GMAC_DEFFREQ); if (rc) -- 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] usb: musb_dsps: fix the exit routine for debugfs
Hi, On Thu, Apr 24, 2014 at 11:07:34AM +0200, Olivier Gayot wrote: Ok, thank you, I didn't notice the existing thread. no problem, but don't top-post please :-s -- balbi signature.asc Description: Digital signature
Re: regressions in linux-next?
Linus Walleij linus.wall...@linaro.org writes: On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: I've revised the patch again and I couldn't find the reason why certain boards are failing to boot. I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it. It would really REALLY appreciate if some of the people maintaining and using OMAP1 would help Javier out in this refactoring operation. I'd really *hate* to have to drop his patches because of a lack of boards. This refactoring is necessary to handle the exploding multitude of GPIO drivers moving forward. We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/ Unfortunately, my OMAP1 (omap5912/OSK[1]) died last year and I haven't been able to get it booting again. I wonder if Spectrum Digital still has these available? Their websites[1] says call for price. Kevin [1] http://www.spectrumdigital.com/product_info.php?products_id=39 -- 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/5] mmc: host: omap_hsmmc: introduce new accessor functions
On Thursday 27 March 2014 05:34 AM, Felipe Balbi wrote:
we introduce new accessors which provide for register
access with and without offsets.
This is just to make sure newer versions of the IP
can access the new registers prepended at the beginning
of the address space.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d46f768..e596c6a 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -211,6 +211,42 @@ struct omap_hsmmc_host {
struct omap_mmc_platform_data *pdata;
};
+static inline int _omap_hsmmc_read(struct omap_hsmmc_host *host,
+ u32 reg, bool offset)
+{
+ return readl(host-base + reg + (offset ? host-reg_offset : 0));
+}
+
+static inline void _omap_hsmmc_write(struct omap_hsmmc_host *host,
+ u32 reg, u32 val, bool offset)
+{
+ writel(val, host-base + reg + (offset ? host-reg_offset : 0));
+}
+
+static inline int omap_hsmmc_read_offset(struct omap_hsmmc_host *host,
I think you can rename this function as just omap_hsmmc_read
(removing _offset suffix)
+ u32 reg)
+{
+ return _omap_hsmmc_read(host, reg, true);
+}
+
+static inline void omap_hsmmc_write_offset(struct omap_hsmmc_host *host,
and this one as omap_hsmmc_write since this version of read/write is most often
used, the one with no_offset might be used less often.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] mmc: host: omap_hsmmc: a few improvements
On Tuesday 22 April 2014 09:18 PM, Felipe Balbi wrote: Hi, On Tue, Apr 22, 2014 at 09:00:12PM +0530, Balaji T K wrote: On Monday 21 April 2014 11:02 PM, Felipe Balbi wrote: Hi, On Wed, Mar 26, 2014 at 07:04:45PM -0500, Felipe Balbi wrote: this series lets us access the newer registers introduced back in OMAP4 which give us some valid information about the OMAP HSMMC IP like max block size, support for ADMA, support for Retention. Right now, only setting max_blk_size correctly as supporting ADMA and Retention will take a lot of work. Tested on OMAP5 uEVM. Felipe Balbi (5): mmc: host: omap_hsmmc: pass host as an argument mmc: host: omap_hsmmc: add reg_offset field mmc: host: omap_hsmmc: introduce new accessor functions mmc: host: omap_hsmmc: switch over to new accessors mmc: host: omap_hsmmc: set max_blk_size correctly Got mislead by your reply to this series, about the alternative way of reading memory size from CAPA register sure, we can do that if you prefer, I just felt I wouldn't touch platforms I can't really test :-s I think so, since those 3 newer registers are not documented for all platforms. Not sure whether it is valid in those cases where it is not documented. Since capa register has these info and can be applied uniformly across all paltforms, I feel reading capa register is the way to go. Do you still think there is a need for new api with no offset ? this has been here for almost a month, any comments ? Do you see any performance impact with this series ? in the normal case ? no... it helps only with large transfers Do you have the numbers ? Is it for read or write, how large should the transfer size be ? I couldn't get any performance improvements with this patch series, Could you please share your test setup, may be I am missing something. -- 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: regressions in linux-next?
On Thu, Apr 24, 2014 at 10:16 AM, Kevin Hilman khil...@linaro.org wrote: Linus Walleij linus.wall...@linaro.org writes: On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: I've revised the patch again and I couldn't find the reason why certain boards are failing to boot. I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it. It would really REALLY appreciate if some of the people maintaining and using OMAP1 would help Javier out in this refactoring operation. I'd really *hate* to have to drop his patches because of a lack of boards. This refactoring is necessary to handle the exploding multitude of GPIO drivers moving forward. We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/ Unfortunately, my OMAP1 (omap5912/OSK[1]) died last year and I haven't been able to get it booting again. I wonder if Spectrum Digital still has these available? Their websites[1] says call for price. Kevin [1] http://www.spectrumdigital.com/product_info.php?products_id=39 Perhaps dumb question: but are there folks who really care about omap1 boot anymore in upstream? should it be time to deprecate it - say for 3.17 or so? Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] mmc: host: omap_hsmmc: a few improvements
On Thu, Apr 24, 2014 at 08:51:25PM +0530, Balaji T K wrote: On Tuesday 22 April 2014 09:18 PM, Felipe Balbi wrote: Hi, On Tue, Apr 22, 2014 at 09:00:12PM +0530, Balaji T K wrote: On Monday 21 April 2014 11:02 PM, Felipe Balbi wrote: Hi, On Wed, Mar 26, 2014 at 07:04:45PM -0500, Felipe Balbi wrote: this series lets us access the newer registers introduced back in OMAP4 which give us some valid information about the OMAP HSMMC IP like max block size, support for ADMA, support for Retention. Right now, only setting max_blk_size correctly as supporting ADMA and Retention will take a lot of work. Tested on OMAP5 uEVM. Felipe Balbi (5): mmc: host: omap_hsmmc: pass host as an argument mmc: host: omap_hsmmc: add reg_offset field mmc: host: omap_hsmmc: introduce new accessor functions mmc: host: omap_hsmmc: switch over to new accessors mmc: host: omap_hsmmc: set max_blk_size correctly Got mislead by your reply to this series, about the alternative way of reading memory size from CAPA register sure, we can do that if you prefer, I just felt I wouldn't touch platforms I can't really test :-s I think so, since those 3 newer registers are not documented for all platforms. Not sure whether it is valid in those cases where it is not documented. Since capa register has these info and can be applied uniformly across all paltforms, I feel reading capa register is the way to go. Do you still think there is a need for new api with no offset ? that same HWINFO register gives you information about availability of ADMA or not. this has been here for almost a month, any comments ? Do you see any performance impact with this series ? in the normal case ? no... it helps only with large transfers Do you have the numbers ? Is it for read or write, how large should the transfer size be ? no numbers available... didn't save anything. I couldn't get any performance improvements with this patch series, Could you please share your test setup, may be I am missing something. just OMAP5 uEVM with UHS-I memory card. -- balbi signature.asc Description: Digital signature
Re: regressions in linux-next?
Hello, On Thu, Apr 24, 2014 at 5:25 PM, Nishanth Menon n...@ti.com wrote: On Thu, Apr 24, 2014 at 10:16 AM, Kevin Hilman khil...@linaro.org wrote: Linus Walleij linus.wall...@linaro.org writes: On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: I've revised the patch again and I couldn't find the reason why certain boards are failing to boot. I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it. It would really REALLY appreciate if some of the people maintaining and using OMAP1 would help Javier out in this refactoring operation. I'd really *hate* to have to drop his patches because of a lack of boards. This refactoring is necessary to handle the exploding multitude of GPIO drivers moving forward. We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/ Unfortunately, my OMAP1 (omap5912/OSK[1]) died last year and I haven't been able to get it booting again. I wonder if Spectrum Digital still has these available? Their websites[1] says call for price. Kevin [1] http://www.spectrumdigital.com/product_info.php?products_id=39 Perhaps dumb question: but are there folks who really care about omap1 boot anymore in upstream? should it be time to deprecate it - say for 3.17 or so? Regards, Nishanth Menon I know that at least Aaro Koskinen (cc'ed here) still uses mainline on OMAP1 boards and he is always very helpful when is asked to test some changes on this platform. Having said that I also wonder if at least we should split omap drivers to have separate support for DT-only (or in a path to be) and non-DT (and with no work towards migration) platforms. Since trying to support both DT and legacy booting is each time more hard. Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regressions in linux-next?
* Nishanth Menon n...@ti.com [140424 08:25]: On Thu, Apr 24, 2014 at 10:16 AM, Kevin Hilman khil...@linaro.org wrote: Linus Walleij linus.wall...@linaro.org writes: On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: I've revised the patch again and I couldn't find the reason why certain boards are failing to boot. I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it. It would really REALLY appreciate if some of the people maintaining and using OMAP1 would help Javier out in this refactoring operation. I'd really *hate* to have to drop his patches because of a lack of boards. This refactoring is necessary to handle the exploding multitude of GPIO drivers moving forward. We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/ Unfortunately, my OMAP1 (omap5912/OSK[1]) died last year and I haven't been able to get it booting again. I wonder if Spectrum Digital still has these available? Their websites[1] says call for price. Kevin [1] http://www.spectrumdigital.com/product_info.php?products_id=39 Perhaps dumb question: but are there folks who really care about omap1 boot anymore in upstream? should it be time to deprecate it - say for 3.17 or so? Why? There are people still using omap1 and it works just fine. And in general the maintenance work needed for omap1 is really minimal. And in the GPIO case the issue was also discovered on new TI boards. 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: regressions in linux-next?
* Javier Martinez Canillas jav...@dowhile0.org [140424 08:37]: Hello, On Thu, Apr 24, 2014 at 5:25 PM, Nishanth Menon n...@ti.com wrote: On Thu, Apr 24, 2014 at 10:16 AM, Kevin Hilman khil...@linaro.org wrote: Linus Walleij linus.wall...@linaro.org writes: On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: I've revised the patch again and I couldn't find the reason why certain boards are failing to boot. I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it. It would really REALLY appreciate if some of the people maintaining and using OMAP1 would help Javier out in this refactoring operation. I'd really *hate* to have to drop his patches because of a lack of boards. This refactoring is necessary to handle the exploding multitude of GPIO drivers moving forward. We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/ Unfortunately, my OMAP1 (omap5912/OSK[1]) died last year and I haven't been able to get it booting again. I wonder if Spectrum Digital still has these available? Their websites[1] says call for price. Kevin [1] http://www.spectrumdigital.com/product_info.php?products_id=39 Perhaps dumb question: but are there folks who really care about omap1 boot anymore in upstream? should it be time to deprecate it - say for 3.17 or so? Regards, Nishanth Menon I know that at least Aaro Koskinen (cc'ed here) still uses mainline on OMAP1 boards and he is always very helpful when is asked to test some changes on this platform. Having said that I also wonder if at least we should split omap drivers to have separate support for DT-only (or in a path to be) and non-DT (and with no work towards migration) platforms. Since trying to support both DT and legacy booting is each time more hard. It really should not matter what the configuration data for the drivers is. Both platform_data and DT data should be easily supported. And we're moving towards using platform_get_irq() and other functions for drivers anyways as that's generic for all the drivers no matter what the driver data source is. 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: regressions in linux-next?
On 04/24/2014 10:40 AM, Tony Lindgren wrote: * Nishanth Menon n...@ti.com [140424 08:25]: On Thu, Apr 24, 2014 at 10:16 AM, Kevin Hilman khil...@linaro.org wrote: Linus Walleij linus.wall...@linaro.org writes: On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: [...] We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/ Unfortunately, my OMAP1 (omap5912/OSK[1]) died last year and I haven't been able to get it booting again. I wonder if Spectrum Digital still has these available? Their websites[1] says call for price. Kevin [1] http://www.spectrumdigital.com/product_info.php?products_id=39 Perhaps dumb question: but are there folks who really care about omap1 boot anymore in upstream? should it be time to deprecate it - say for 3.17 or so? Why? There are people still using omap1 and it works just fine. And in general the maintenance work needed for omap1 is really minimal. And in the GPIO case the issue was also discovered on new TI boards. I mean, yeah - hobby usage is nice.. but there is maintenance burden when it comes to ensuring generic drivers such as timers, gpio etc.. I am not saying we cannot maintain it, but if there are no strong reasons why to keep it alive, it kinda reduces the scope of modifications as kernel frameworks evolve to be generic. The OMAP1 generation of processors based boards are so hard to get and go running that developer access to these boards slow things down as well. I understand that strong reasons to keep it alive is pretty subjective in nature.. but just throwing the thought out here. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 00/19] bus: omap_l3_noc: driver cleanups and support for DRA7/AM4372
Nishanth, Nishanth Menon n...@ti.com wrote on Thu [2014-Apr-17 15:49:16 -0500]: V2 introduces the following changes: - Additional bug fix detected during additional testing (all tests complete now). patch #12 - reordering of patches to order logical changes and reduce code churn. - interrupt handler split up and additional information now provided in log to aid debug when error occur - patches are marked where new (12,14,15,16). - DRA7 updated from master document for all DRA7 variants. This series cleansup omap_l3_noc driver and adds data to support DRA7 and AM437x SoCs. This L3 noc driver patch series is working great for me and has already flagged a very difficult to detect problem in a driver I am working on with a DMA access to an invalid memory address on DRA7. Tested-by: Darren Etheridge detheri...@ti.com Darren -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 00/19] bus: omap_l3_noc: driver cleanups and support for DRA7/AM4372
On 04/24/2014 10:54 AM, Darren Etheridge wrote: Nishanth, Nishanth Menon n...@ti.com wrote on Thu [2014-Apr-17 15:49:16 -0500]: V2 introduces the following changes: - Additional bug fix detected during additional testing (all tests complete now). patch #12 - reordering of patches to order logical changes and reduce code churn. - interrupt handler split up and additional information now provided in log to aid debug when error occur - patches are marked where new (12,14,15,16). - DRA7 updated from master document for all DRA7 variants. This series cleansup omap_l3_noc driver and adds data to support DRA7 and AM437x SoCs. This L3 noc driver patch series is working great for me and has already flagged a very difficult to detect problem in a driver I am working on with a DMA access to an invalid memory address on DRA7. Glad it was of use. All the more reason why this should be in upstream kernel and not just in evil vendor kernel. Tested-by: Darren Etheridge detheri...@ti.com Thanks. will pick this up for v3 post. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regressions in linux-next?
* Nishanth Menon n...@ti.com [140424 08:47]: On 04/24/2014 10:40 AM, Tony Lindgren wrote: * Nishanth Menon n...@ti.com [140424 08:25]: On Thu, Apr 24, 2014 at 10:16 AM, Kevin Hilman khil...@linaro.org wrote: Linus Walleij linus.wall...@linaro.org writes: On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: [...] We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/ Unfortunately, my OMAP1 (omap5912/OSK[1]) died last year and I haven't been able to get it booting again. I wonder if Spectrum Digital still has these available? Their websites[1] says call for price. Kevin [1] http://www.spectrumdigital.com/product_info.php?products_id=39 Perhaps dumb question: but are there folks who really care about omap1 boot anymore in upstream? should it be time to deprecate it - say for 3.17 or so? Why? There are people still using omap1 and it works just fine. And in general the maintenance work needed for omap1 is really minimal. And in the GPIO case the issue was also discovered on new TI boards. I mean, yeah - hobby usage is nice.. but there is maintenance burden when it comes to ensuring generic drivers such as timers, gpio etc.. I am not saying we cannot maintain it, but if there are no strong reasons why to keep it alive, it kinda reduces the scope of modifications as kernel frameworks evolve to be generic. The OMAP1 generation of processors based boards are so hard to get and go running that developer access to these boards slow things down as well. It's not a burden by any means like I said. And like I said, the drivers should work just fine no matter what the data source. Having the platform_data around actually forces us to fix up the drivers so they work in the standard Linux way. So it's really the mixed state of drivers that are the issue here. I understand that strong reasons to keep it alive is pretty subjective in nature.. but just throwing the thought out here. Strong reasons as in people are using it. There just isn't any stronger reason available in Linux land. Or what do you think is a stronger reason then? Merging random corporate snapshots of kernel code upstream from some hacked up kernel tree where the code has never even been even tested with the mainline kernel and is not usable for any available product? I don't think so :) 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 V2 00/19] bus: omap_l3_noc: driver cleanups and support for DRA7/AM4372
* Peter Ujfalusi peter.ujfal...@ti.com [140424 01:55]: On 04/18/2014 12:00 AM, Nishanth Menon wrote: On 04/17/2014 03:57 PM, Santosh Shilimkar wrote: I looked at the series and its looks pretty good. Thanks for fixups, updates. For whole series, Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Thanks. Patches(including Peter's) is available here: https://github.com/nmenon/linux-2.6-playground/commits/l3noc/driver-fixes-v2 Can Tony pull this branch for 3.16 then which includes Peter's series as well ? there is just an empty commit with information about peter's patches that i lined up to differentiate the series.. I can drop it if Tony would like me to. Looking at the branch I see my patches underneath so they are in the branch. It would be great if Tony pulls this... Will be a great present to my patches (omap_l3 patches in the branch) for their 1 year anniversary of being out on the mailing list ;) If you insist :) Maybe we should have some cake or something with it? Seriously, I always thought that's a nice clean-up set, but never thought I'm supposed to merge it. Will merge it as soon as I'm out of the fixes and regressions land as that way I can easier test for any kind of new regressions that might occur related to PM at least. 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 V2 00/19] bus: omap_l3_noc: driver cleanups and support for DRA7/AM4372
On Thu, Apr 24, 2014 at 11:25 AM, Tony Lindgren t...@atomide.com wrote: * Peter Ujfalusi peter.ujfal...@ti.com [140424 01:55]: On 04/18/2014 12:00 AM, Nishanth Menon wrote: On 04/17/2014 03:57 PM, Santosh Shilimkar wrote: I looked at the series and its looks pretty good. Thanks for fixups, updates. For whole series, Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Thanks. Patches(including Peter's) is available here: https://github.com/nmenon/linux-2.6-playground/commits/l3noc/driver-fixes-v2 Can Tony pull this branch for 3.16 then which includes Peter's series as well ? there is just an empty commit with information about peter's patches that i lined up to differentiate the series.. I can drop it if Tony would like me to. Looking at the branch I see my patches underneath so they are in the branch. It would be great if Tony pulls this... Will be a great present to my patches (omap_l3 patches in the branch) for their 1 year anniversary of being out on the mailing list ;) If you insist :) Maybe we should have some cake or something with it? Seriously, I always thought that's a nice clean-up set, but never thought I'm supposed to merge it. Will merge it as soon as I'm out of the fixes and regressions land as that way I can easier test for any kind of new regressions that might occur related to PM at least. Thanks Tony. I will try and post a v3 tomorrow as a clean set of patches and a v3.15-rc1 based branch to ease integration. This should also give additional time for any further comments as well. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regressions in linux-next?
Hello Tony, On Thu, Apr 24, 2014 at 5:42 PM, Tony Lindgren t...@atomide.com wrote: * Javier Martinez Canillas jav...@dowhile0.org [140424 08:37]: Hello, On Thu, Apr 24, 2014 at 5:25 PM, Nishanth Menon n...@ti.com wrote: On Thu, Apr 24, 2014 at 10:16 AM, Kevin Hilman khil...@linaro.org wrote: Linus Walleij linus.wall...@linaro.org writes: On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: I've revised the patch again and I couldn't find the reason why certain boards are failing to boot. I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it. It would really REALLY appreciate if some of the people maintaining and using OMAP1 would help Javier out in this refactoring operation. I'd really *hate* to have to drop his patches because of a lack of boards. This refactoring is necessary to handle the exploding multitude of GPIO drivers moving forward. We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/ Unfortunately, my OMAP1 (omap5912/OSK[1]) died last year and I haven't been able to get it booting again. I wonder if Spectrum Digital still has these available? Their websites[1] says call for price. Kevin [1] http://www.spectrumdigital.com/product_info.php?products_id=39 Perhaps dumb question: but are there folks who really care about omap1 boot anymore in upstream? should it be time to deprecate it - say for 3.17 or so? Regards, Nishanth Menon I know that at least Aaro Koskinen (cc'ed here) still uses mainline on OMAP1 boards and he is always very helpful when is asked to test some changes on this platform. Having said that I also wonder if at least we should split omap drivers to have separate support for DT-only (or in a path to be) and non-DT (and with no work towards migration) platforms. Since trying to support both DT and legacy booting is each time more hard. It really should not matter what the configuration data for the drivers is. Both platform_data and DT data should be easily supported. Yes, I think I expressed myself badly. I actually meant platforms that keep evolving vs platforms that nobody is active developing on them and is unlikely that will ever use the newer infrastructure/API/whatever that is added on the different subsystems. In the GPIO OMAP driver example we have a lot of #ifdefery to separate OMAP1 and OMAP2+ code since OMAP1 does not support sparse IRQ (and probably never will) so it can't dynamically allocate IRQ numbers and I've seen similar things in other OMAP drivers. But yes, the maintenance burden is not that much either, I was just thinking aloud if splitting these drivers would make sense or not. And we're moving towards using platform_get_irq() and other functions for drivers anyways as that's generic for all the drivers no matter what the driver data source is. Regards, Tony Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] gpio: omap: implement get_direction
* Santosh Shilimkar santosh.shilim...@ti.com [140424 06:30]: On Thursday 24 April 2014 09:13 AM, Linus Walleij wrote: On Thu, Apr 24, 2014 at 8:57 AM, yegorsli...@googlemail.com wrote: From: Yegor Yefremov yegorsli...@googlemail.com This patch implements gpio_chip's get_direction() routine, that lets other drivers get particular GPIOs direction using struct gpio_desc. Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com Acked-by: Javier Martinez Canillas jav...@dowhile0.org --- Changes: v3: get rid of _get_gpio_direction() (Linus Walleij) v2: rework return value calculation Looks good to me, Kevin, Santosh? Looks fine to me as well. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com OK finally got around testing gpio/for-next here. Could not use todays linux next as it's broken again for whatever reasons and does not even compile for me. Boot tested gpio/next on few omap1 boards: h2, osk and 770 and things behave the same way as earlier for me on these boards. Also made sure the PM does not break as tested on n900 with the GPIO changes. So for the following patches, feel free to add: cb2a5fb059b5 gpio: do not set up hardware for IRQ_TYPE_NONE da09ceae78f7 gpio: omap: implement get_direction d04b76626e94 gpio: omap: convert driver to use gpiolib irqchip d4094cd7577c gpio: omap: check gpiochip_add() return value 820eade1b7f3 gpio: omap: convert to use irq_domain_add_simple() 717f70e39a98 gpio: omap: Use devm_ioremap_resource() Tested-by: Tony Lindgren t...@atomide.com Naturally no need to go back to edit the commits for my acks unless there are other reasons to redo the branches. Part of me wants to list Javier as maintainer for this driver. Am ok with it as well. That sounds good to me too, looks like Javier is doing a good job on that 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
