[PATCH v4 6/7] ARM: dts: am335x-boneblack: Use new binding for HDMI
Use new binding for the external tda19988 HDMI encoder.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
arch/arm/boot/dts/am335x-boneblack.dts | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 5c42d25..eadbba3 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -68,16 +68,26 @@
lcdc {
status = okay;
+ port {
+ lcdc_0: endpoint@0 {
+ remote-endpoint = hdmi_0;
+ };
+ };
};
-/ {
- hdmi {
- compatible = ti,tilcdc,slave;
- i2c = i2c0;
+i2c0 {
+ tda19988 {
+ compatible = nxp,tda998x;
+ reg = 0x70;
pinctrl-names = default, off;
pinctrl-0 = nxp_hdmi_bonelt_pins;
pinctrl-1 = nxp_hdmi_bonelt_off_pins;
- status = okay;
+
+ port {
+ hdmi_0: endpoint@0 {
+ remote-endpoint = lcdc_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 v4 5/7] drm/tilcdc: Force building of DRM_TILCDC_SLAVE_COMPAT
If I read Documentation/kbuild/makefiles.txt section 3.6 right, this patch should not be needed. However, without this patch the objects needed for DRM_TILCDC_SLAVE_COMPAT are not linked, if DRM_TILCDC is built as module. Signed-off-by: Jyri Sarha jsa...@ti.com --- drivers/gpu/drm/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 2c239b9..c93ca0e 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -59,7 +59,7 @@ obj-$(CONFIG_DRM_ATMEL_HLCDC) += atmel-hlcdc/ obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/ obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/ obj-$(CONFIG_DRM_OMAP) += omapdrm/ -obj-$(CONFIG_DRM_TILCDC) += tilcdc/ +obj-y += tilcdc/ obj-$(CONFIG_DRM_QXL) += qxl/ obj-$(CONFIG_DRM_BOCHS) += bochs/ obj-$(CONFIG_DRM_MSM) += msm/ -- 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 v4 0/7] Use DRM component API in tilcdc to connect to tda998x
Ok, let's do one more full review round. The mode filtering issue was the main reason for this new patch series version. However, I found couple other things to fix too after scrutinizing the patches once more. Changes since v3 version of the patch-set: * drm/tilcdc: Add support for external tda998x encoder - Hijack external connectors helper functions - Remove select of nonexistent DRM_TILCDC_INIT in tilcdc Kconfig - Correct author mail address to tilcdc_exteral.h * drm/tilcdc: Add DRM_TILCDC_SLAVE_COMPAT for ti,tilcdc,slave binding - Add a header file for tilcdc_slave_compat.dtb symbol declarations Changes since v2 version of the patch-set: - use obj-y in Makefle for tilcdc subdir in: drm/tilcdc: Force building of DRM_TILCDC_SLAVE_COMPAT - move to last: drm/tilcdc: Decrement refcount of ep-node from of_graph_get_next_endpoint Changes since first version of the patch-set: - Rename DRM_TILCDC_INIT to DRM_TILCDC_SLAVE_COMPAT and make it visible - Add separate: drm/tilcdc: Decrement refcount of ep-node from of_graph_get_next_endpoint - Reduce info-level spam - Use component_master_add_with_match() - Be more explicit about tda998x being the only supported external encoder Remove tilcdc slave support and connect to tda998x trough its component DRM API. For dtb backward compatibility the code creates at boot time a DT overlay based on the earlier binding. The overlay conforms to the new graph based binding. The drm/tilcdc: Decrement refcount of ep-node from of_graph_get_next_endpoint should probably not be merged. The of: Decrement refcount of previous endpoint in of_graph_get_next_endpoint is eventually going to be merged and before that leaking of two of-node refcount increments each time the module is loaded is not that serious. The of-nodes live forever anyway. The merge of the dts patch can be delayed until the next merger window, when the other patches are already in. The DRM_TILCDC_SLAVE_COMPAT should keep the bbb HDMI operational until then. The first patch is just a bugfix and can be applied or dropped independently. Jyri Sarha (7): drm/tilcdc: Fix module unloading drm/tilcdc: Remove tilcdc slave support for tda998x driver drm/tilcdc: Add support for external tda998x encoder drm/tilcdc: Add DRM_TILCDC_SLAVE_COMPAT for ti,tilcdc,slave binding support drm/tilcdc: Force building of DRM_TILCDC_SLAVE_COMPAT ARM: dts: am335x-boneblack: Use new binding for HDMI drm/tilcdc: Decrement refcount of ep-node from of_graph_get_next_endpoint .../devicetree/bindings/drm/tilcdc/slave.txt | 18 - .../devicetree/bindings/drm/tilcdc/tilcdc.txt | 27 ++ arch/arm/boot/dts/am335x-boneblack.dts | 20 +- drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/tilcdc/Kconfig | 12 + drivers/gpu/drm/tilcdc/Makefile| 5 +- drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 36 +- drivers/gpu/drm/tilcdc/tilcdc_drv.c| 94 +++-- drivers/gpu/drm/tilcdc/tilcdc_drv.h| 6 +- drivers/gpu/drm/tilcdc/tilcdc_external.c | 159 drivers/gpu/drm/tilcdc/tilcdc_external.h | 25 ++ drivers/gpu/drm/tilcdc/tilcdc_slave.c | 411 - drivers/gpu/drm/tilcdc/tilcdc_slave.h | 26 -- drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 270 ++ drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts | 72 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.h | 25 ++ 16 files changed, 718 insertions(+), 490 deletions(-) delete mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.h delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.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
Re: [PATCH] mm/migrate: Mark unmap_and_move() noinline to avoid ICE in gcc 4.7.3
On 01/04/15 10:37, Geert Uytterhoeven wrote:
Hi Kevin,
On Tue, 31 Mar 2015, Kevin Hilman wrote:
Ard Biesheuvel ard.biesheu...@linaro.org writes:
Nope, that branch is already part of linux-next, and linux-next still
fails to compile for 20+ defconfigs[1]
Could you elaborate on the issue please? What is the error you are
getting, and can you confirm that is is caused by ld choking on the
linker script? If not, this is another error than the one we have been
trying to fix
It's definitely not linker script related.
Using arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3,
here's the error when building for multi_v7_defconfig (full log
available[2]):
../mm/migrate.c: In function 'migrate_pages':
../mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at
config/arm/arm.c:13101
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions.
Preprocessed source stored into /tmp/ccO1Nz1m.out file, please attach
this to your bugreport.
make[2]: *** [mm/migrate.o] Error 1
make[2]: Target `__build' not remade because of errors.
make[1]: *** [mm] Error 2
build bisect points to commit 21f992084aeb[3], but that doesn't revert
cleanly so I haven't got any further than that yet.
I installed gcc-arm-linux-gnueabi (4:4.7.2-1 from Ubuntu 14.04 LTS) and could
reproduce the ICE. I came up with the workaround below.
Does this work for you?
From 7ebe83316eaf1952e55a76754ce7a5832e461b8c Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven geert+rene...@glider.be
Date: Wed, 1 Apr 2015 11:22:51 +0200
Subject: [PATCH] mm/migrate: Mark unmap_and_move() noinline to avoid ICE in
gcc 4.7.3
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
With gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) :
mm/migrate.c: In function ‘migrate_pages’:
mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at
config/arm/arm.c:13500
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions.
Preprocessed source stored into /tmp/ccPoM1tr.out file, please attach
this to your bugreport.
make[1]: *** [mm/migrate.o] Error 1
make: *** [mm/migrate.o] Error 2
Mark unmap_and_move() (which is used in a single place only) noinline
to work around this compiler bug.
Reported-by: Kevin Hilman khil...@kernel.org
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
---
mm/migrate.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/mm/migrate.c b/mm/migrate.c
index 114602a68111d809..98f8574456c2010c 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -904,9 +904,10 @@ out:
* Obtain the lock on page, remove all ptes and migrate the page
* to the newly allocated page in newpage.
*/
-static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
- unsigned long private, struct page *page, int force,
- enum migrate_mode mode)
+static noinline int unmap_and_move(new_page_t get_new_page,
+free_page_t put_new_page,
+unsigned long private, struct page *page,
+int force, enum migrate_mode mode)
{
int rc = 0;
int *result = NULL;
Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
the parameters on the stack, which is not going to help performance
either (not that this would be useful on 32bit ARM anyway...).
Any chance you could make this dependent on some compiler detection
mechanism?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
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 v4 1/7] drm/tilcdc: Fix module unloading
Force crtc dpms off before destroying the crtc instead of just
checking the dpms state. This fixes warning message and frozen picture
after tilcdc module unloading.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index c735884..c2d5980 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -135,11 +135,12 @@ static void stop(struct drm_crtc *crtc)
tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
}
+static void tilcdc_crtc_dpms(struct drm_crtc *crtc, int mode);
static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
{
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
- WARN_ON(tilcdc_crtc-dpms == DRM_MODE_DPMS_ON);
+ tilcdc_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
drm_crtc_cleanup(crtc);
drm_flip_work_cleanup(tilcdc_crtc-unref_work);
--
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] mm/migrate: Mark unmap_and_move() noinline to avoid ICE in gcc 4.7.3 (was: Re: Possible regression in gcc 4.7.3 next-20150323 due to ARM, arm64: kvm: get rid of the bounce page)
Hi Kevin,
On Tue, 31 Mar 2015, Kevin Hilman wrote:
Ard Biesheuvel ard.biesheu...@linaro.org writes:
Nope, that branch is already part of linux-next, and linux-next still
fails to compile for 20+ defconfigs[1]
Could you elaborate on the issue please? What is the error you are
getting, and can you confirm that is is caused by ld choking on the
linker script? If not, this is another error than the one we have been
trying to fix
It's definitely not linker script related.
Using arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3,
here's the error when building for multi_v7_defconfig (full log
available[2]):
../mm/migrate.c: In function 'migrate_pages':
../mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at
config/arm/arm.c:13101
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions.
Preprocessed source stored into /tmp/ccO1Nz1m.out file, please attach
this to your bugreport.
make[2]: *** [mm/migrate.o] Error 1
make[2]: Target `__build' not remade because of errors.
make[1]: *** [mm] Error 2
build bisect points to commit 21f992084aeb[3], but that doesn't revert
cleanly so I haven't got any further than that yet.
I installed gcc-arm-linux-gnueabi (4:4.7.2-1 from Ubuntu 14.04 LTS) and could
reproduce the ICE. I came up with the workaround below.
Does this work for you?
From 7ebe83316eaf1952e55a76754ce7a5832e461b8c Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven geert+rene...@glider.be
Date: Wed, 1 Apr 2015 11:22:51 +0200
Subject: [PATCH] mm/migrate: Mark unmap_and_move() noinline to avoid ICE in
gcc 4.7.3
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
With gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) :
mm/migrate.c: In function ‘migrate_pages’:
mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at
config/arm/arm.c:13500
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions.
Preprocessed source stored into /tmp/ccPoM1tr.out file, please attach this
to your bugreport.
make[1]: *** [mm/migrate.o] Error 1
make: *** [mm/migrate.o] Error 2
Mark unmap_and_move() (which is used in a single place only) noinline
to work around this compiler bug.
Reported-by: Kevin Hilman khil...@kernel.org
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
---
mm/migrate.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/mm/migrate.c b/mm/migrate.c
index 114602a68111d809..98f8574456c2010c 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -904,9 +904,10 @@ out:
* Obtain the lock on page, remove all ptes and migrate the page
* to the newly allocated page in newpage.
*/
-static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
- unsigned long private, struct page *page, int force,
- enum migrate_mode mode)
+static noinline int unmap_and_move(new_page_t get_new_page,
+ free_page_t put_new_page,
+ unsigned long private, struct page *page,
+ int force, enum migrate_mode mode)
{
int rc = 0;
int *result = NULL;
--
1.9.1
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 v4 4/7] drm/tilcdc: Add DRM_TILCDC_SLAVE_COMPAT for ti,tilcdc,slave binding support
Adds a CONFIG_DRM_TILCDC_SLAVE_COMPAT module for ti,tilcdc,slave
node conversion. The implementation is in tilcdc_slave_compat.c and it
uses tilcdc_slave_compat.dts as a basis for creating a DTS
overlay. The DTS overlay adds an external tda998x encoder to tilcdc
that corresponds to the old tda998x based slave encoder.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
drivers/gpu/drm/tilcdc/Kconfig | 12 ++
drivers/gpu/drm/tilcdc/Makefile| 3 +
drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 270 +
drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts | 72 +++
drivers/gpu/drm/tilcdc/tilcdc_slave_compat.h | 25 +++
5 files changed, 382 insertions(+)
create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts
create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.h
diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
index 8394a0b..bfbef69 100644
--- a/drivers/gpu/drm/tilcdc/Kconfig
+++ b/drivers/gpu/drm/tilcdc/Kconfig
@@ -1,3 +1,15 @@
+config DRM_TILCDC_SLAVE_COMPAT
+ bool Support device tree blobs using TI LCDC Slave binding
+ depends on DRM_TILCDC
+ default y
+ select OF_RESOLVE
+ select OF_OVERLAY
+ help
+ Choose this option if you need a kernel that is compatible
+ with device tree blobs using the obsolete ti,tilcdc,slave
+ binding. If you find ti,tilcdc,slave-string from your DTB,
+ you probably need this. Otherwise you do not.
+
config DRM_TILCDC
tristate DRM Support for TI LCDC Display Controller
depends on DRM OF ARM HAVE_DMA_ATTRS
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index e1f738b..deeca48 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -3,6 +3,9 @@ ifeq (, $(findstring -W,$(EXTRA_CFLAGS)))
ccflags-y += -Werror
endif
+obj-$(CONFIG_DRM_TILCDC_SLAVE_COMPAT) += tilcdc_slave_compat.o \
+tilcdc_slave_compat.dtb.o
+
tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
new file mode 100644
index 000..106679b
--- /dev/null
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
@@ -0,0 +1,270 @@
+/*
+ * Copyright (C) 2015 Texas Instruments
+ * Author: Jyri Sarha jsa...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ */
+
+/*
+ * To support the old ti,tilcdc,slave binding the binding has to be
+ * transformed to the new external encoder binding.
+ */
+
+#include linux/kernel.h
+#include linux/of.h
+#include linux/of_graph.h
+#include linux/of_fdt.h
+#include linux/slab.h
+#include linux/list.h
+
+#include tilcdc_slave_compat.h
+
+struct kfree_table {
+ int total;
+ int num;
+ void **table;
+};
+
+static int __init kfree_table_init(struct kfree_table *kft)
+{
+ kft-total = 32;
+ kft-num = 0;
+ kft-table = kmalloc(kft-total * sizeof(*kft-table),
+GFP_KERNEL);
+ if (!kft-table)
+ return -ENOMEM;
+
+ return 0;
+}
+
+static int __init kfree_table_add(struct kfree_table *kft, void *p)
+{
+ if (kft-num == kft-total) {
+ void **old = kft-table;
+
+ kft-total *= 2;
+ kft-table = krealloc(old, kft-total * sizeof(*kft-table),
+ GFP_KERNEL);
+ if (!kft-table) {
+ kft-table = old;
+ kfree(p);
+ return -ENOMEM;
+ }
+ }
+ kft-table[kft-num++] = p;
+ return 0;
+}
+
+static void __init kfree_table_free(struct kfree_table *kft)
+{
+ int i;
+
+ for (i = 0; i kft-num; i++)
+ kfree(kft-table[i]);
+
+ kfree(kft-table);
+}
+
+static
+struct property * __init tilcdc_prop_dup(const struct property *prop,
+struct kfree_table *kft)
+{
+ struct property *nprop;
+
+ nprop = kzalloc(sizeof(*nprop), GFP_KERNEL);
+ if (!nprop || kfree_table_add(kft, nprop))
+ return NULL;
+
+ nprop-name = kstrdup(prop-name, GFP_KERNEL);
+ if (!nprop-name || kfree_table_add(kft, nprop-name))
+ return NULL;
+
+ nprop-value = kmemdup(prop-value, prop-length, GFP_KERNEL);
+ if (!nprop-value || kfree_table_add(kft, nprop-value))
+ return NULL;
+
+ nprop-length = prop-length;
+
+ return nprop;
+}
+
+static void __init tilcdc_copy_props(struct device_node *from,
+struct device_node *to,
+const char *
[PATCH v4 7/7] drm/tilcdc: Decrement refcount of ep-node from of_graph_get_next_endpoint
This patch should be dropped/reverterd if/after of: Decrement refcount
of previous endpoint in of_graph_get_next_endpoint patch has been
merged.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
drivers/gpu/drm/tilcdc/tilcdc_external.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c
b/drivers/gpu/drm/tilcdc/tilcdc_external.c
index f932f52..7232647 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
@@ -137,6 +137,7 @@ int tilcdc_get_external_components(struct device *dev,
struct device_node *node;
node = of_graph_get_remote_port_parent(ep);
+ of_node_put(ep);
if (!node !of_device_is_available(node)) {
of_node_put(node);
continue;
--
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 v4 3/7] drm/tilcdc: Add support for external tda998x encoder
Add support for an external compontised DRM encoder. The external
encoder can be connected to tilcdc trough device tree graph binding.
The binding document for tilcdc has been updated. The current
implementation supports only tda998x encoder.
To be able to filter out the unsupported video modes the tilcdc driver
needs to hijack the external connectors helper functions. The tilcdc
installes new helper functions that are otherwise identical to
orignals, but the mode_valid() call-back check the mode first localy,
before calling the original call-back. The tilcdc dirver restores the
original helper functions before it is unbound from the external
device.
I got the idea and some lines of code from Jean-Francois Moine's
drm/tilcdc: Change the interface with the tda998x driver-patch.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
.../devicetree/bindings/drm/tilcdc/tilcdc.txt | 27
drivers/gpu/drm/tilcdc/Makefile| 1 +
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 33 +
drivers/gpu/drm/tilcdc/tilcdc_drv.c| 81 +--
drivers/gpu/drm/tilcdc/tilcdc_drv.h| 5 +
drivers/gpu/drm/tilcdc/tilcdc_external.c | 158 +
drivers/gpu/drm/tilcdc/tilcdc_external.h | 25
7 files changed, 317 insertions(+), 13 deletions(-)
create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.c
create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.h
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
index fff10da..2136ee8 100644
--- a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
@@ -18,6 +18,12 @@ Optional properties:
- max-pixelclock: The maximum pixel clock that can be supported
by the lcd controller in KHz.
+Optional nodes:
+
+ - port/ports: to describe a connection to an external encoder. The
+ binding follows Documentation/devicetree/bindings/graph.txt and
+ suppors a single port with a single endpoint.
+
Example:
fb: fb@4830e000 {
@@ -26,4 +32,25 @@ Example:
interrupt-parent = intc;
interrupts = 36;
ti,hwmods = lcdc;
+
+ port {
+ lcdc_0: endpoint@0 {
+ remote-endpoint = hdmi_0;
+ };
+ };
+ };
+
+ tda19988: tda19988 {
+ compatible = nxp,tda998x;
+ reg = 0x70;
+
+ pinctrl-names = default, off;
+ pinctrl-0 = nxp_hdmi_bonelt_pins;
+ pinctrl-1 = nxp_hdmi_bonelt_off_pins;
+
+ port {
+ hdmi_0: endpoint@0 {
+ remote-endpoint = lcdc_0;
+ };
+ };
};
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index 44485f9..e1f738b 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -7,6 +7,7 @@ tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
tilcdc_panel.o \
+ tilcdc_external.o \
tilcdc_drv.o
obj-$(CONFIG_DRM_TILCDC) += tilcdc.o
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index c2d5980..7d07733 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -37,6 +37,9 @@ struct tilcdc_crtc {
/* for deferred fb unref's: */
struct drm_flip_work unref_work;
+
+ /* Only set if an external encoder is connected */
+ bool simulate_vesa_sync;
};
#define to_tilcdc_crtc(x) container_of(x, struct tilcdc_crtc, base)
@@ -214,6 +217,28 @@ static bool tilcdc_crtc_mode_fixup(struct drm_crtc *crtc,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
+ struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+
+ if (!tilcdc_crtc-simulate_vesa_sync)
+ return true;
+
+ /*
+* tilcdc does not generate VESA-compliant sync but aligns
+* VS on the second edge of HS instead of first edge.
+* We use adjusted_mode, to fixup sync by aligning both rising
+* edges and add HSKEW offset to fix the sync.
+*/
+ adjusted_mode-hskew = mode-hsync_end - mode-hsync_start;
+ adjusted_mode-flags |= DRM_MODE_FLAG_HSKEW;
+
+ if (mode-flags DRM_MODE_FLAG_NHSYNC) {
+ adjusted_mode-flags |= DRM_MODE_FLAG_PHSYNC;
+ adjusted_mode-flags = ~DRM_MODE_FLAG_NHSYNC;
+ } else {
+ adjusted_mode-flags |= DRM_MODE_FLAG_NHSYNC;
+ adjusted_mode-flags = ~DRM_MODE_FLAG_PHSYNC;
+ }
+
return true;
}
@@ -534,6 +559,14 @@ void tilcdc_crtc_set_panel_info(struct drm_crtc *crtc,
tilcdc_crtc-info = info;
}
+void
[PATCH v4 2/7] drm/tilcdc: Remove tilcdc slave support for tda998x driver
Remove tilcdc slave support for tda998x driver. The tilcdc slave
support would conflicts with componentized use of tda998x.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
.../devicetree/bindings/drm/tilcdc/slave.txt | 18 -
drivers/gpu/drm/tilcdc/Makefile| 1 -
drivers/gpu/drm/tilcdc/tilcdc_drv.c| 13 -
drivers/gpu/drm/tilcdc/tilcdc_drv.h| 1 -
drivers/gpu/drm/tilcdc/tilcdc_slave.c | 411 -
drivers/gpu/drm/tilcdc/tilcdc_slave.h | 26 --
6 files changed, 470 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt
delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
b/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
deleted file mode 100644
index 3d2c524..000
--- a/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Device-Tree bindings for tilcdc DRM encoder slave output driver
-
-Required properties:
- - compatible: value should be ti,tilcdc,slave.
- - i2c: the phandle for the i2c device the encoder slave is connected to
-
-Recommended properties:
- - pinctrl-names, pinctrl-0: the pincontrol settings to configure
- muxing properly for pins that connect to TFP410 device
-
-Example:
-
- hdmi {
- compatible = ti,tilcdc,slave;
- i2c = i2c0;
- pinctrl-names = default;
- pinctrl-0 = nxp_hdmi_bonelt_pins;
- };
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index 7d2eefe..44485f9 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -6,7 +6,6 @@ endif
tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
- tilcdc_slave.o \
tilcdc_panel.o \
tilcdc_drv.o
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 095fca9..0f1e099 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -20,13 +20,11 @@
#include tilcdc_drv.h
#include tilcdc_regs.h
#include tilcdc_tfp410.h
-#include tilcdc_slave.h
#include tilcdc_panel.h
#include drm_fb_helper.h
static LIST_HEAD(module_list);
-static bool slave_probing;
void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
const struct tilcdc_module_ops *funcs)
@@ -42,11 +40,6 @@ void tilcdc_module_cleanup(struct tilcdc_module *mod)
list_del(mod-list);
}
-void tilcdc_slave_probedefer(bool defered)
-{
- slave_probing = defered;
-}
-
static struct of_device_id tilcdc_of_match[];
static struct drm_framebuffer *tilcdc_fb_create(struct drm_device *dev,
@@ -620,10 +613,6 @@ static int tilcdc_pdev_probe(struct platform_device *pdev)
return -ENXIO;
}
- /* defer probing if slave is in deferred probing */
- if (slave_probing == true)
- return -EPROBE_DEFER;
-
return drm_platform_init(tilcdc_driver, pdev);
}
@@ -654,7 +643,6 @@ static int __init tilcdc_drm_init(void)
{
DBG(init);
tilcdc_tfp410_init();
- tilcdc_slave_init();
tilcdc_panel_init();
return platform_driver_register(tilcdc_platform_driver);
}
@@ -664,7 +652,6 @@ static void __exit tilcdc_drm_fini(void)
DBG(fini);
platform_driver_unregister(tilcdc_platform_driver);
tilcdc_panel_fini();
- tilcdc_slave_fini();
tilcdc_tfp410_fini();
}
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 7596c14..6336512 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -116,7 +116,6 @@ struct tilcdc_module {
void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
const struct tilcdc_module_ops *funcs);
void tilcdc_module_cleanup(struct tilcdc_module *mod);
-void tilcdc_slave_probedefer(bool defered);
/* Panel config that needs to be set in the crtc, but is not coming from
* the mode timings. The display module is expected to call
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
deleted file mode 100644
index 3775fd4..000
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ /dev/null
@@ -1,411 +0,0 @@
-/*
- * Copyright (C) 2012 Texas Instruments
- * Author: Rob Clark robdcl...@gmail.com
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
- * more details.
- *
- * You
Re: Possible regression in next-20150323 due to ARM, arm64: kvm: get rid of the bounce page
Hi Kevin, On Tue, Mar 31, 2015 at 07:58:21PM +0100, Kevin Hilman wrote: Will Deacon will.dea...@arm.com writes: On Fri, Mar 27, 2015 at 12:25:54AM +, Simon Horman wrote: On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote: On 26 March 2015 at 06:36, Will Deacon will.dea...@arm.com wrote: On Thu, Mar 26, 2015 at 12:39:39AM +, Simon Horman wrote: On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote: I think we now have a new error: (seen with omap2plus_defconfig) on next-20150324 : ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size' referenced in expression make: *** [vmlinux] Error 1 Thanks, I am seeing that too. My armchair suggestion is that the following should be reverted. e60a1fec44a2f (ARM: kvm: implement replacement for ld's LOG2CEIL()) 06f75a1f62000 (ARM, arm64: kvm: get rid of the bounce page) Can you try again with the latest -next please? We've merged an additional patch aimed at sorting this out. Reverting isn't really an option, as there's an awful lot of code that depends on the bounce page removal. Here are the kernelci.org -next results[1], if you click the build status you can dig down into the build failures. next-20150326 has now hit a compiler bug, Arnd mentioned he was looking into this issue. I have confirmed that next-20150326 does not compile without the following reverted: 12eb3e833961 (ARM: kvm: assert on HYP section boundaries not actual code size) e60a1fec44a2 (ARM: kvm: implement replacement for ld's LOG2CEIL()) 06f75a1f6200 (ARM, arm64: kvm: get rid of the bounce page) Thanks for testing this and sorry for the continued breakage. Which toolchain did you say you were using? Ard has some more patches trying to fix this, but none of our toolchains seem to tickle the issue. I've also tested on the default ARM toolchains available with ubuntu[1] Are there any updates on this issue? It's been fixed since the end of last week! (see ARM: kvm: round HYP section to page size instead of log2 upper bound) This was confirmed by both my testing and also Simon Horman, who reported the initial breakage. It ha broken most of the ARM defconfigs in linux-next[2], and since it's been broken for a week now, it is masking other types of issues that we can normally find via automated boot testing. If you're referring to failures such as: http://storage.kernelci.org/next/next-20150331/arm-axm55xx_defconfig/build.log Then that's not coming from the arm64 tree, and is a completely separate issue from the one originally reported in this thread. Will -- 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 v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi Pavel, Am 31.03.2015 um 09:26 schrieb Pavel Machek pa...@ucw.cz: Hi! + io-channels = twl_madc 1, + twl_madc 10, + twl_madc 12; + io-channel-names = temp, +ichg, +vbat; + }; Rather than just making platform_data into device tree properties.. Can't you hide the these custom properties behind the compatible flag? You can initialize that data in the driver based on the compatible flag and the match data. This makes sense if you can group things to similar configurations. Maybe I have not completely understood your proposal. Do you mean to go back to have big parameter tables for each device/battery combination in the driver code and the compatible flag (e.g. compatible = “board17”) chooses the right data set for the charging map and channels? If you can somehow group them, then yes. Not for every board if there are many of them naturally. I thought this is what the DT was introduced for - to have the same driver code but adapt to different boards depending on hardware variations. Yeah but you also need to consider the issues related to introducing new device tree properties. The device tree properties introduced should be generic where possible. And batteries have very different characteristics and vary between devices… Right. Maybe that has been already agreed on to use capacity-uah for batteries in general? In that case I have not problem with that as it's a generic property :) The charging maps are depending on the battery type connected to the twl4030 and which madc channel is which value is also a little hardware dependent (although the twl4030 doesn’t give much choice). Just to consider alternatives before introducing driver specific property for the maps.. Maybe here you could have few different type of maps and select something safe by default? Of course it could be this is higly board specific, I think some devices may be able to run below 3.3V for example.. As I explained in some other mail, those tables should not be neccessary at all. They can be computed from li-ion characteristics and internal resistance, and assumed current during charge and discharge. I already explained that we do not know the charging and discharging current well enough for such a calculation. And I explained that the “internal resistance” is a system (battery + cables + connectors + other circuits) parameter that is not easy to derive or measure and type into the .dts source code. At least I have no idea how I should find it out for my boards. While I can easily determine the curves (and we already have them for the platform_data driver). Please propose your own code doing that so that we can test if it is better. Running below 3.3V.. not really. At that point, the battery is really _empty_, and voltage is going down really really fast. It is the diffference between 2% and 0% where a fuel indication might be most important… Plus, you are damaging the battery at that point. The power controller will shut down - but the driver should report reasonable (but IMHO not necessarily perfect) values until the last moment. BR, Nikolaus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap voltage management
On 04/01/2015 08:18 AM, Ryan wrote: Hi, I would like to ask a related question here Please try not to top post :). If i use performance governor alone - constantly running at the highest frequency. Does the smart reflex still has a role to play? Yes. cpufreq governor are just policies - cpufreq policies just selects a frequency to run the CPU from a list of frequencies. for each frequency to be achieved, there is ABB, AVS configuration needed (strategy specific to SoC). Does smart-reflex involves reprogramming only the mpu power line alone? AVS strategies apply to all rails in TI SoCs which need such strategies. -- 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: Possible regression in next-20150323 due to ARM, arm64: kvm: get rid of the bounce page
On 04/01/2015 03:58 AM, Will Deacon wrote: Hi Kevin, On Tue, Mar 31, 2015 at 07:58:21PM +0100, Kevin Hilman wrote: Will Deacon will.dea...@arm.com writes: On Fri, Mar 27, 2015 at 12:25:54AM +, Simon Horman wrote: On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote: On 26 March 2015 at 06:36, Will Deacon will.dea...@arm.com wrote: On Thu, Mar 26, 2015 at 12:39:39AM +, Simon Horman wrote: On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote: I think we now have a new error: (seen with omap2plus_defconfig) on next-20150324 : ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size' referenced in expression make: *** [vmlinux] Error 1 Thanks, I am seeing that too. My armchair suggestion is that the following should be reverted. e60a1fec44a2f (ARM: kvm: implement replacement for ld's LOG2CEIL()) 06f75a1f62000 (ARM, arm64: kvm: get rid of the bounce page) Can you try again with the latest -next please? We've merged an additional patch aimed at sorting this out. Reverting isn't really an option, as there's an awful lot of code that depends on the bounce page removal. Here are the kernelci.org -next results[1], if you click the build status you can dig down into the build failures. next-20150326 has now hit a compiler bug, Arnd mentioned he was looking into this issue. I have confirmed that next-20150326 does not compile without the following reverted: 12eb3e833961 (ARM: kvm: assert on HYP section boundaries not actual code size) e60a1fec44a2 (ARM: kvm: implement replacement for ld's LOG2CEIL()) 06f75a1f6200 (ARM, arm64: kvm: get rid of the bounce page) Thanks for testing this and sorry for the continued breakage. Which toolchain did you say you were using? Ard has some more patches trying to fix this, but none of our toolchains seem to tickle the issue. I've also tested on the default ARM toolchains available with ubuntu[1] Are there any updates on this issue? It's been fixed since the end of last week! I can confirm that my tests have started functioning again (gcc 4.6) https://github.com/nmenon/kernel-test-logs/tree/linux-next -- 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: omap voltage management
Hi, I would like to ask a related question here If i use performance governor alone - constantly running at the highest frequency. Does the smart reflex still has a role to play? Does smart-reflex involves reprogramming only the mpu power line alone? Regards, Ryan On Thu, Mar 26, 2015 at 4:17 AM, Nishanth Menon n...@ti.com wrote: On Wed, Mar 25, 2015 at 4:47 PM, Tony Lindgren t...@atomide.com wrote: * Ran Shalit ransha...@gmail.com [150321 12:18]: On Fri, Mar 20, 2015 at 7:11 AM, Ran Shalit ransha...@gmail.com wrote: We currently are missing dm8148 support from mainline, dm8168 does have basic support now. Adding dm8148 will hopefully happen too with time permitting :) Hi Tony, What is exactly the voltage driver capability ? Does it mean that it does not support AVS (feature for power saving) ? Regards, Ran Hi Tony, Is it AVS or voltage scaling (used with cpufreq) ? Nishanth might be able to summarize what all is happening :) Oh Boy, where do i start? Overall quick 5 min write up: PMIC Voltage rail- voltage domain - power domain - clock domain - clocks IP TRM for each OMAP technology IPs should show how this looks like Voltage domain and voltage rail can be tweaked depending on how the frequency of IPs are. We do a lot of stuff to save power depending on SoC family.. Some places like OMAP5/DRA7 certain features might be originally designed, but later descoped due to various other reasons.. anyways.. Lets take OMAP3 and beagleboard as an example SMPS1 supplies MPU voltage domain that has MPU power domain and A8 under it MPU DPLL clocks A8, and you can play around with frequency for it.. as we reduce frequency, we can actually operate it at lower voltage - these are discrete pairs called OPPs - even though intermediate frequencies are possible to function, SoC companies like TI cannot test all possible combinations, so do not guarentee functionality at intermediate frequencies beyond what is provided in the data sheet. we let cpufreq control that depending on the various load conditions... For a specific frequency, the simplest thing is just reduce voltage - but can we do better? ofcourse yes. it kinda plays with how SoC production wafers behave.. and the silicon process itself.. this is where AVS comes into play - AVS (or Adaptive Voltage Scaling) is a set of different techniques depending on the SoC and process node, process type etc.. but basically, the game is to find the least possible voltage for functioning at frequency X, for a specific sample instance at a certain point in time. AVS class0, class1, 1.5, 2 and class 3 are some of the techniques used, there are aspects of temperature compensation on certain SoCs as well. But this just ensures that the worst possible usecase can still function at frequency X and tries to reduce voltage below the OPP start voltage point (start voltage is called nominal voltage in some parts of TI).. Now, for the specific frequency, you can play further games by controlling transistor leakage by providing a bias voltage - this is called ABB - which is an SoC internal LDO, which can be controlled as well - we can reverse or forward bias depending on vdd (voltage domain voltage) in a nut shell: - A8 can operate in multiple frequencies - for each frequency X, we can come with a common voltage which works on every single silicon for every time for worst case usecase for the worst possible conditions - we call this as nominal voltage(Y), this, and the tuple (X,Y) is what we define as OPP - which is generic for any OMAP3 sample. - to do optimization per sample, we now need to tweak Y to lower value - this is done along with tweaking ABB. - this ensures that as little leakage of transistor at the least voltage is used for achieving frequency X. Does the game end there? nope. we can play even more.. Lets say at frequency X, we dont have anything to do... ok, we can go to lower power state - cpuidle, here we can gate clocks and go into different deeper power saving states which trades off with wakeup latency times.. at some lower power states, we dont even need the AVS optimized voltage anymore.. - the voltage for operating in low power state is called retention voltage - only some SoCs+PMIC combination have ability to automatically do this since A8 itself is in idle when the SoC decides it can achieve this low power state. So voltage driver is a bit of a misnomer... - Do we have a common entity that can ensure sequencing of AVS, ABB, frequency in the right order in upstream - answer is no.. I did attempt to post [1] but folks did not like it yet.. and i have'nt had time to respin it - actually I dont really know where to go given that maintainers differ in opinions.. - can we control a smps PMIC power supply? yeah - regulator framework and corresponding regulator driver - can we control ABB - yep - we have abb regulator driver in upstream - can we
Re: [PATCH] crypto: omap-sham: Check for HIGHMEM before mapping SG pages
On Tue, Mar 31, 2015 at 09:52:23AM +0530, Lokesh Vutla wrote:
Commit 26a05489ee0e (crypto: omap-sham - Map SG pages if they are HIGHMEM
before accessing)
says that HIGHMEM pages may not be mapped so we must
kmap them before accessing, but it doesn't check whether the
corresponding page is in highmem or not. Because of this all
the crypto tests are failing.
: d9 a1 1b 7c aa 90 3b aa 11 ab cb 25 00 b8 ac bf
[2.338169] 0010: c1 39 cd ff 48 d0 a8 e2 2b fa 33 a1
[2.344008] alg: hash: Chunking test 1 failed for omap-sha256
So Checking for HIGHMEM before mapping SG pages.
Fixes: 26a05489ee0 (crypto: omap-sham - Map SG pages if they are HIGHMEM
before accessing)
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/crypto/omap-sham.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 3c76696..ace5852 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -639,13 +639,17 @@ static size_t omap_sham_append_sg(struct
omap_sham_reqctx *ctx)
const u8 *vaddr;
while (ctx-sg) {
- vaddr = kmap_atomic(sg_page(ctx-sg));
+ if (PageHighMem(sg_page(ctx-sg)))
+ vaddr = kmap_atomic(sg_page(ctx-sg));
+ else
+ vaddr = sg_virt(ctx-sg);
This is completely bogus. kmap_atomic should be identical to
sg_virt(sg_page()) for the lowmem case.
So either your architecture is broken (because the same problem
would obviously affect the core crypto code which does exactly
the same thing), or there is some other bug causing the selftest
to fail.
Cheers,
--
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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] crypto: omap-sham: Use pm_runtime_irq_safe()
On Tue, Mar 31, 2015 at 09:52:24AM +0530, Lokesh Vutla wrote: omap_sham_handle_queue() can be called as part of done_task tasklet. During this its atomic and any calls to pm functions cannot sleep. But there is a call to pm_runtime_get_sync() (which can sleep) in omap_sham_handle_queue(), because of which the following appears: [ 116.169969] BUG: scheduling while atomic: kworker/0:2/2676/0x0100 Add pm_runtime_irq_safe() to avoid this. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com Applied. -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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] crypto: omap-aes: Fix support for unequal lengths
On Tue, Mar 31, 2015 at 09:52:25AM +0530, Lokesh Vutla wrote: For cases where total length of an input SGs is not same as length of the input data for encryption, omap-aes driver crashes. This happens in the case when IPsec is trying to use omap-aes driver. To avoid this, we copy all the pages from the input SG list into a contiguous buffer and prepare a single element SG list for this buffer with length as the total bytes to crypt, which is similar thing that is done in case of unaligned lengths. Fixes: 6242332ff2f3 (crypto: omap-aes - Add support for cases of unaligned lengths) Signed-off-by: Lokesh Vutla lokeshvu...@ti.com Applied. -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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: [rtc-linux] [PATCH 3/3] rtc: omap: use module_platform_driver
On 01/04/2015 at 11:24:58 +0530, Lokesh Vutla wrote :
module_platform_driver_probe() prevents driver from requesting probe deferral.
So using module_platform_drive() to support probe deferral.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Acked-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
drivers/rtc/rtc-omap.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 96cc613..a4965a0 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -510,7 +510,7 @@ static const struct of_device_id omap_rtc_of_match[] = {
};
MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
-static int __init omap_rtc_probe(struct platform_device *pdev)
+static int omap_rtc_probe(struct platform_device *pdev)
{
struct omap_rtc *rtc;
struct resource *res;
@@ -745,6 +745,7 @@ static void omap_rtc_shutdown(struct platform_device
*pdev)
}
static struct platform_driver omap_rtc_driver = {
+ .probe = omap_rtc_probe,
.remove = __exit_p(omap_rtc_remove),
.shutdown = omap_rtc_shutdown,
.driver = {
@@ -755,7 +756,7 @@ static struct platform_driver omap_rtc_driver = {
.id_table = omap_rtc_id_table,
};
-module_platform_driver_probe(omap_rtc_driver, omap_rtc_probe);
+module_platform_driver(omap_rtc_driver);
MODULE_ALIAS(platform:omap_rtc);
MODULE_AUTHOR(George G. Davis (and others));
--
1.9.1
--
--
You received this message because you are subscribed to rtc-linux.
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups
rtc-linux group.
To unsubscribe from this group and stop receiving emails from it, send an
email to rtc-linux+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings
On Tue, Mar 10, 2015 at 4:27 PM, Marek Belisko ma...@goldelico.com wrote:
Signed-off-by: Marek Belisko ma...@goldelico.com
---
.../bindings/power_supply/twl4030_madc_battery.txt | 43
++
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
diff --git
a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
new file mode 100644
index 000..d3dd9d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
@@ -0,0 +1,43 @@
+twl4030_madc_battery
+
+Required properties:
+ - compatible : ti,twl4030-madc-battery
Is this a sub-node of the twl4030 or something? Please define where
this fits (hint: I would expect to be a sub node of a charging
controller or battery monitor).
+ - capacity-uah : battery capacity in uAh
+ - ti,volt-to-capacity-charging-map : list of voltage(mV):level(%) values
+ for charging calibration (see example)
+ - ti,volt-to-capacity-discharging-map : list of voltage(mV):level(%) values
+ for discharging calibration (see example)
These seem like properties of the battery independent of the
battery/charging controller which is the twl4030. Ideally we would
define battery nodes generically and independent of the charge
controllers. Then there are smart batteries to consider too.
Rob
+ - io-channels: Should contain IIO channel specifiers
+ for each element in io-channel-names.
+- io-channel-names: Should contain the following values:
+ * temp - The ADC channel for temperature reading
+ * ichg - The ADC channel for battery charging status
+ * vbat - The ADC channel to measure the battery voltage
+
+Example:
+ madc-battery {
+ compatible = ti,twl4030-madc-battery;
+ capacity-uah = 120;
+ ti,volt-to-capacity-charging-map = 4200 100,
+ 4100 75,
+ 4000 55,
+ 3900 25,
+ 3800 5,
+ 3700 2,
+ 3600 1,
+ 3300 0;
+
+ ti,volt-to-capacity-discharging-map = 4200 100
+ 4100 95,
+ 4000 70,
+ 3800 50,
+ 3700 10,
+ 3600 5,
+ 3300 0;
+ io-channels = twl_madc 1,
+ twl_madc 10,
+ twl_madc 12;
+ io-channel-names = temp,
+ ichg,
+ vbat;
+ };
--
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
Re: [rtc-linux] [PATCH 2/3] rtc: omap: Update Kconfig for OMAP RTC
On 01/04/2015 at 11:24:57 +0530, Lokesh Vutla wrote : RTC is present in AM43xx and DRA7xx also. Updating the Kconfig to depend on ARCH_OMAP or ARCH_DAVINCI Signed-off-by: Lokesh Vutla lokeshvu...@ti.com Acked-by: Alexandre Belloni alexandre.bell...@free-electrons.com --- drivers/rtc/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig index b5b5c3d..40faf56 100644 --- a/drivers/rtc/Kconfig +++ b/drivers/rtc/Kconfig @@ -1121,11 +1121,11 @@ config RTC_DRV_IMXDI will be called rtc-imxdi. config RTC_DRV_OMAP - tristate TI OMAP1 - depends on ARCH_OMAP15XX || ARCH_OMAP16XX || ARCH_OMAP730 || ARCH_DAVINCI_DA8XX || SOC_AM33XX + tristate TI OMAP Real Time Clock + depends on ARCH_OMAP || ARCH_DAVINCI help Say yes here to support the on chip real time clock - present on TI OMAP1, AM33xx and DA8xx/OMAP-L13x. + present on TI OMAP1, AM33xx, DA8xx/OMAP-L13x, AM43xx and DRA7xx. This driver can also be built as a module, if so, module will be called rtc-omap. -- 1.9.1 -- -- You received this message because you are subscribed to rtc-linux. Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups rtc-linux group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rtc-linux] [PATCH 1/3] rtc: omap: Unlock and Lock rtc registers before and after register writes
Hi,
On 01/04/2015 at 11:24:56 +0530, Lokesh Vutla wrote :
RTC module contains a kicker mechanism to prevent any spurious writes
from changing the register values. This mechanism requires two MMR
writes to the KICK0 and KICK1 registers with exact data values
before the kicker lock mechanism is released.
Currently the driver release the lock in the probe and leaves it enabled
until the rtc driver removal. This eliminates the idea of preventing
spurious writes when RTC driver is loaded.
So implement rtc lock and unlock functions before and after register writes.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
- This is as advised by Paul to implement lock and unlock functions in
the driver and not to unlock and leave it in probe.
The same discussion can be seen here:
http://www.mail-archive.com/linux-omap%40vger.kernel.org/msg111588.html
drivers/rtc/rtc-omap.c | 46 ++
1 file changed, 38 insertions(+), 8 deletions(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 8e5851a..96cc613 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -156,6 +156,22 @@ static inline void rtc_writel(struct omap_rtc *rtc,
unsigned int reg, u32 val)
writel(val, rtc-base + reg);
}
+static void rtc_unlock(struct omap_rtc *rtc)
+{
+ if (rtc-type-has_kicker) {
Instead of testing for has_kicker each time, I would add .lock and
.unlock to omap_rtc_device_type and directly use rtc-type-lock and
rtc-type-unlock.
+ rtc_writel(rtc, OMAP_RTC_KICK0_REG, KICK0_VALUE);
+ rtc_writel(rtc, OMAP_RTC_KICK1_REG, KICK1_VALUE);
+ }
+}
+
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible regression in next-20150323 due to ARM, arm64: kvm: get rid of the bounce page
Hi Will, Will Deacon will.dea...@arm.com writes: [...] Thanks for testing this and sorry for the continued breakage. Which toolchain did you say you were using? Ard has some more patches trying to fix this, but none of our toolchains seem to tickle the issue. I've also tested on the default ARM toolchains available with ubuntu[1] Are there any updates on this issue? It's been fixed since the end of last week! (see ARM: kvm: round HYP section to page size instead of log2 upper bound) This was confirmed by both my testing and also Simon Horman, who reported the initial breakage. It ha broken most of the ARM defconfigs in linux-next[2], and since it's been broken for a week now, it is masking other types of issues that we can normally find via automated boot testing. If you're referring to failures such as: http://storage.kernelci.org/next/next-20150331/arm-axm55xx_defconfig/build.log Yes, that's the one I'm trying to track down. Then that's not coming from the arm64 tree, and is a completely separate issue from the one originally reported in this thread. Ugh, womehow I got wires crossed and thought they were related problems. Looks like Geert now has a proposed fix for the issue I'm tracking. Sorry for the noise, Kevin -- 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 linux-next] clk: constify of_device_id array
On 03/31/15 11:50, Fabian Frederick wrote: of_device_id is always used as const. (See driver.of_match_table and open firmware functions) __initdata updated to __initconst for static const struct of_device_id ti_clkdm_match_table[] Signed-off-by: Fabian Frederick f...@skynet.be Thanks. Applied to clk-next. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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] mm/migrate: Mark unmap_and_move() noinline to avoid ICE in gcc 4.7.3
On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier marc.zyng...@arm.com wrote:
-static int unmap_and_move(new_page_t get_new_page, free_page_t
put_new_page,
- unsigned long private, struct page *page, int force,
- enum migrate_mode mode)
+static noinline int unmap_and_move(new_page_t get_new_page,
+ free_page_t put_new_page,
+ unsigned long private, struct page *page,
+ int force, enum migrate_mode mode)
{
int rc = 0;
int *result = NULL;
Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
the parameters on the stack, which is not going to help performance
either (not that this would be useful on 32bit ARM anyway...).
Any chance you could make this dependent on some compiler detection
mechanism?
With my arm compiler (gcc-4.4.4) the patch makes no difference -
unmap_and_move() isn't being inlined anyway.
How does this look?
Kevin, could you please retest? I might have fat-fingered something...
---
a/mm/migrate.c~mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix
+++ a/mm/migrate.c
@@ -901,10 +901,20 @@ out:
}
/*
+ * gcc-4.7.3 on arm gets an ICE when inlining unmap_and_move(). Work around
+ * it.
+ */
+#if GCC_VERSION == 40703 defined(CONFIG_ARM)
+#define ICE_noinline noinline
+#else
+#define ICE_noinline
+#endif
+
+/*
* Obtain the lock on page, remove all ptes and migrate the page
* to the newly allocated page in newpage.
*/
-static noinline int unmap_and_move(new_page_t get_new_page,
+static ICE_noinline int unmap_and_move(new_page_t get_new_page,
free_page_t put_new_page,
unsigned long private, struct page *page,
int force, enum migrate_mode mode)
_
--
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] mm/migrate: Mark unmap_and_move() noinline to avoid ICE in gcc 4.7.3
Geert Uytterhoeven ge...@linux-m68k.org writes:
[...]
build bisect points to commit 21f992084aeb[3], but that doesn't revert
cleanly so I haven't got any further than that yet.
I installed gcc-arm-linux-gnueabi (4:4.7.2-1 from Ubuntu 14.04 LTS) and could
reproduce the ICE. I came up with the workaround below.
Awesome, thanks!
Does this work for you?
Yes, that patch works well and fixes the regression. Build results for
all the defconfigs here:
http://kernelci.org/build/khilman/kernel/v4.0-rc6-8294-g2ef3958cc27e/
and the remaining issues arent' realted to this ICE.
From 7ebe83316eaf1952e55a76754ce7a5832e461b8c Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven geert+rene...@glider.be
Date: Wed, 1 Apr 2015 11:22:51 +0200
Subject: [PATCH] mm/migrate: Mark unmap_and_move() noinline to avoid ICE in
gcc 4.7.3
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
With gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) :
mm/migrate.c: In function ‘migrate_pages’:
mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at
config/arm/arm.c:13500
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions.
Preprocessed source stored into /tmp/ccPoM1tr.out file, please attach
this to your bugreport.
make[1]: *** [mm/migrate.o] Error 1
make: *** [mm/migrate.o] Error 2
Mark unmap_and_move() (which is used in a single place only) noinline
to work around this compiler bug.
Reported-by: Kevin Hilman khil...@kernel.org
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
Tested-by: Kevin Hilman khil...@linaro.org
---
mm/migrate.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/mm/migrate.c b/mm/migrate.c
index 114602a68111d809..98f8574456c2010c 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -904,9 +904,10 @@ out:
* Obtain the lock on page, remove all ptes and migrate the page
* to the newly allocated page in newpage.
*/
-static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
- unsigned long private, struct page *page, int force,
- enum migrate_mode mode)
+static noinline int unmap_and_move(new_page_t get_new_page,
+free_page_t put_new_page,
+unsigned long private, struct page *page,
+int force, enum migrate_mode mode)
{
int rc = 0;
int *result = NULL;
--
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] remoteproc: Introduce wkup_m3_rproc driver
Hi, This patch series is version three of the series to add a wkup_m3_rproc driver for TI AM335x SoCs. This family of SoCs contains an ARM Cortex M3 coprocessor that is responsible for low-level power tasks that cannot be handled by the main ARM Cortex A8 so firmware running from the CM3 can be used instead. This driver handles loading of the firmware and reset of the CM3 once it is booted. The previous version of this series can be found here [1]. I have pushed a branch based on v4.0-rc5 containing the entire am335x suspend series here for a higher level view of the entire series of patch sets here [2]. This series depends on remoteproc: add IOMMU hardware capability flag which is currently queued here [3]. Based on comments on the DT node included in the ARM: OMAP2+: wkup_m3_rproc support patches series (v3 of that will immediately follow this series) the DT node moved under a different parent node so some changes to the driver were necessary to calculate proper device addresses for firmware loading. This series also now includes a patch to introduce an rproc_get_by_phandle API to the remoteproc core so that users of this wkup_m3_rproc driver are able to get a handle to the rproc and boot it as the rproc must be booted directly by the user. An example user, wkup_m3_ipc, can be seen in previously mentioned branch at [2]. v2 - v3: -Modify wkup_m3_rproc driver to properly handle device address based on new DT location in l4_wkup node. -In binding doc, change ti,am3352-wkup-m3 from am3353-wkup_m3 to match other am3352 compats -General cleanup of address representation in wkup_m3_rproc driver -Includes rproc_get_by_phandle patch now The driver expects to load firmware am335x-pm-firmware.elf from /lib/firmware which is found here [4]. Regards, Dave [1] http://www.spinics.net/lists/linux-omap/msg116364.html [2] https://github.com/dgerlach/linux-pm/tree/pm-v4.0-rc5-am335x-suspend [3] https://git.kernel.org/cgit/linux/kernel/git/ohad/remoteproc.git/commit/?h=for-nextid=315491e5d6ee66838a18a8ca0c14e6ffb376e48c [4] https://git.ti.com/ti-cm3-pm-firmware/amx3-cm3/commits/next-upstream Dave Gerlach (3): remoteproc: introduce rproc_get_by_phandle API Documentation: dt: add bindings for TI Wakeup M3 processor remoteproc/wkup_m3: add a remoteproc driver for TI Wakeup M3 Suman Anna (1): remoteproc: add a rproc ops for performing address translation .../bindings/remoteproc/wkup_m3_rproc.txt | 52 + Documentation/remoteproc.txt | 6 + drivers/remoteproc/Kconfig | 13 ++ drivers/remoteproc/Makefile| 1 + drivers/remoteproc/remoteproc_core.c | 114 +- drivers/remoteproc/wkup_m3_rproc.c | 249 + include/linux/platform_data/wkup_m3.h | 30 +++ include/linux/remoteproc.h | 4 + 8 files changed, 463 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt create mode 100644 drivers/remoteproc/wkup_m3_rproc.c create mode 100644 include/linux/platform_data/wkup_m3.h -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/4] remoteproc/wkup_m3: add a remoteproc driver for TI Wakeup M3
Add a remoteproc driver to load the firmware and boot a small
Wakeup M3 processor present on TI AM33xx and AM43xx SoCs. This
Wakeup M3 remote processor is an integrated Cortex M3 that allows
the SoC to enter the lowest possible power state by taking control
from the MPU after it has gone into its own low power state and
shutting off any additional peripherals.
Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
drivers/remoteproc/Kconfig| 13 ++
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/wkup_m3_rproc.c| 249 ++
include/linux/platform_data/wkup_m3.h | 30
4 files changed, 293 insertions(+)
create mode 100644 drivers/remoteproc/wkup_m3_rproc.c
create mode 100644 include/linux/platform_data/wkup_m3.h
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 5e343ba..28c711f 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -41,6 +41,19 @@ config STE_MODEM_RPROC
This can be either built-in or a loadable module.
If unsure say N.
+config WKUP_M3_RPROC
+ tristate AMx3xx Wakeup M3 remoteproc support
+ depends on SOC_AM33XX || SOC_AM43XX
+ select REMOTEPROC
+ help
+ Say y here to support Wakeup M3 remote processor on TI AM33xx
+ and AM43xx family of SoCs.
+
+ Required for Suspend-to-RAM on AM33xx and AM43xx SoCs. Also needed
+ for deep CPUIdle states on AM33xx SoCs. Allows for loading of the
+ firmware onto these remote processors.
+ If unsure say N.
+
config DA8XX_REMOTEPROC
tristate DA8xx/OMAP-L13x remoteproc support
depends on ARCH_DAVINCI_DA8XX
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index ac2ff75..81b04d1 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -9,4 +9,5 @@ remoteproc-y+= remoteproc_virtio.o
remoteproc-y += remoteproc_elf_loader.o
obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
obj-$(CONFIG_STE_MODEM_RPROC) += ste_modem_rproc.o
+obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
diff --git a/drivers/remoteproc/wkup_m3_rproc.c
b/drivers/remoteproc/wkup_m3_rproc.c
new file mode 100644
index 000..134ffa7
--- /dev/null
+++ b/drivers/remoteproc/wkup_m3_rproc.c
@@ -0,0 +1,249 @@
+/*
+ * TI AMx3 Wakeup M3 Remote Processor driver
+ *
+ * Copyright (C) 2014-2015 Texas Instruments, Inc.
+ *
+ * Dave Gerlach d-gerl...@ti.com
+ * Suman Anna s-a...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/err.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/of_address.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/remoteproc.h
+
+#include linux/platform_data/wkup_m3.h
+
+#include remoteproc_internal.h
+
+#define WKUPM3_MEM_MAX 2
+
+/**
+ * struct wkup_m3_mem - WkupM3 internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address from Wakeup M3 view
+ * @size: Size of the memory region
+ */
+struct wkup_m3_mem {
+ void __iomem *cpu_addr;
+ phys_addr_t bus_addr;
+ u32 dev_addr;
+ size_t size;
+};
+
+/**
+ * struct wkup_m3_rproc - WkupM3 remote processor state
+ * @rproc: rproc handle
+ * @pdev: pointer to platform device
+ * @mem: WkupM3 memory information
+ */
+struct wkup_m3_rproc {
+ struct rproc *rproc;
+ struct platform_device *pdev;
+ struct wkup_m3_mem mem[WKUPM3_MEM_MAX];
+};
+
+static int wkup_m3_rproc_start(struct rproc *rproc)
+{
+ struct wkup_m3_rproc *wkupm3 = rproc-priv;
+ struct platform_device *pdev = wkupm3-pdev;
+ struct device *dev = pdev-dev;
+ struct wkup_m3_platform_data *pdata = dev_get_platdata(dev);
+
+ if (pdata-deassert_reset(pdev, pdata-reset_name)) {
+ dev_err(dev, Unable to reset wkup_m3!\n);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static int wkup_m3_rproc_stop(struct rproc *rproc)
+{
+ struct wkup_m3_rproc *wkupm3 = rproc-priv;
+ struct platform_device *pdev = wkupm3-pdev;
+ struct device *dev = pdev-dev;
+ struct wkup_m3_platform_data *pdata = dev_get_platdata(dev);
+
+ if (pdata-assert_reset(pdev, pdata-reset_name)) {
+
[PATCH v3 2/4] remoteproc: add a rproc ops for performing address translation
From: Suman Anna s-a...@ti.com
The rproc_da_to_va API is currently used to perform any device to
kernel address translations to meet the different needs of the remoteproc
core/drivers (eg: loading). The functionality is achieved within the
remoteproc core, and is limited only for carveouts allocated within the
core.
A new rproc ops, da_to_va, is added to provide flexibility to platform
implementations to perform the address translation themselves when the
above conditions cannot be met by the implementations. The rproc_da_to_va()
API is extended to invoke this ops if present, and fallback to regular
processing if the platform implementation cannot provide the translation.
This will allow any remoteproc implementations to translate addresses for
dedicated memories like internal memories.
While at this, also update the rproc_da_to_va() documentation since it
is an exported function.
Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
drivers/remoteproc/remoteproc_core.c | 31 +--
include/linux/remoteproc.h | 2 ++
2 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 5a6c192..f1efe62 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -159,28 +159,46 @@ static void rproc_disable_iommu(struct rproc *rproc)
return;
}
-/*
+/**
+ * rproc_da_to_va() - lookup the kernel virtual address for a remoteproc
address
+ * @rproc: handle of a remote processor
+ * @da: remoteproc device address to translate
+ * @len: length of the memory region @da is pointing to
+ *
* Some remote processors will ask us to allocate them physically contiguous
* memory regions (which we call carveouts), and map them to specific
- * device addresses (which are hardcoded in the firmware).
+ * device addresses (which are hardcoded in the firmware). They may also have
+ * dedicated memory regions internal to the processors, and use them either
+ * exclusively or alongside carveouts.
*
* They may then ask us to copy objects into specific device addresses (e.g.
* code/data sections) or expose us certain symbols in other device address
* (e.g. their trace buffer).
*
- * This function is an internal helper with which we can go over the allocated
- * carveouts and translate specific device address to kernel virtual addresses
- * so we can access the referenced memory.
+ * This function is a helper function with which we can go over the allocated
+ * carveouts and translate specific device addresses to kernel virtual
addresses
+ * so we can access the referenced memory. This function also allows to perform
+ * translations on the internal remoteproc memory regions through a platform
+ * implementation specific da_to_va ops, if present.
+ *
+ * The function returns a valid kernel address on success or NULL on failure.
*
* Note: phys_to_virt(iommu_iova_to_phys(rproc-domain, da)) will work too,
* but only on kernel direct mapped RAM memory. Instead, we're just using
- * here the output of the DMA API, which should be more correct.
+ * here the output of the DMA API for the carveouts, which should be more
+ * correct.
*/
void *rproc_da_to_va(struct rproc *rproc, u64 da, int len)
{
struct rproc_mem_entry *carveout;
void *ptr = NULL;
+ if (rproc-ops-da_to_va) {
+ ptr = rproc-ops-da_to_va(rproc, da, len);
+ if (ptr)
+ goto out;
+ }
+
list_for_each_entry(carveout, rproc-carveouts, node) {
int offset = da - carveout-da;
@@ -197,6 +215,7 @@ void *rproc_da_to_va(struct rproc *rproc, u64 da, int len)
break;
}
+out:
return ptr;
}
EXPORT_SYMBOL(rproc_da_to_va);
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 0c7d403..81b224d 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -331,11 +331,13 @@ struct rproc;
* @start: power on the device and boot it
* @stop: power off the device
* @kick: kick a virtqueue (virtqueue id given as a parameter)
+ * @da_to_va: optional platform hook to perform address translations
*/
struct rproc_ops {
int (*start)(struct rproc *rproc);
int (*stop)(struct rproc *rproc);
void (*kick)(struct rproc *rproc, int vqid);
+ void * (*da_to_va)(struct rproc *rproc, u64 da, int len);
};
/**
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 00/34] ARM: OMAP2+: PRCM+SCM cleanup against 4.0-rc1
* Tero Kristo t-kri...@ti.com [150331 12:15]: Hi, Decided to post a new version because of the number of minor changes compared to v5, just to avoid any misunderstandings: - dropped patch #1 (clk: ti: fix ti_clk_get_reg_addr...), this has been merged through clock tree now - fixed scm_conf area size issues on am33xx/am43xx - fixed scm area size issue on am43xx - fixed size issues on omap3_pmx_core (was 8 bytes short) - added warnings on omap2_clk_readl/writel in case legacy access is attempted - fixed omap3 legacy boot - fixed boot time warning on omap4+ where scm_conf does not contain clocks node yet (these may be added to DT later if support is required) - fixed some randconfig warnings Testing done: 1: am335x-evm : boot 2: am335x-evmsk: boot 3: am3517-evm : boot 4: am43x-epos-evm : boot 5: am437x-gp-evm : boot 6: omap3-beagle-xm : boot 7: omap3-beagle: boot, cpuidle (ret/off), suspend (ret/off), legacy boot 8: am335x-boneblack: boot 9: am335x-bone : boot 10: dra7xx-evm : boot 11: omap3-n900 : boot 12: omap5-uevm : boot 13: omap4-panda-es : boot, cpuidle (ret), suspend (ret) 14: omap4-panda : boot 15: omap2430-sdp: boot 16: omap3430-sdp: boot 17: omap4-sdp-es23plus: boot New branch also pushed: tree: https://github.com/t-kristo/linux-pm.git branch: 4.0-rc1-prcm-cleanup-v6 OK great, this version seems to work for me. I'll merge this into omap-for-v4.1/prcm-cleanup and will send a pull request probably on Thursday or Friday to arm-soc. Note that it's getting late for v4.1 (except for fixes), so no guarantees this will still get in. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/4] remoteproc: introduce rproc_get_by_phandle API
Allow users of remoteproc the ability to get a handle to an rproc by
passing a phandle supplied in the user's device tree node. This is
useful in situations that require manual booting of the rproc.
This patch uses the code removed by commit 40e575b1d0b3 (remoteproc:
remove the get_by_name/put API) for the ref counting a rproc klist
code but has rproc_get_by_name replaced with an rproc_get_by_phandle API.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
Signed-off-by: Suman Anna s-a...@ti.com
---
Documentation/remoteproc.txt | 6 +++
drivers/remoteproc/remoteproc_core.c | 83
include/linux/remoteproc.h | 2 +
3 files changed, 91 insertions(+)
diff --git a/Documentation/remoteproc.txt b/Documentation/remoteproc.txt
index e6469fd..ef0219f 100644
--- a/Documentation/remoteproc.txt
+++ b/Documentation/remoteproc.txt
@@ -51,6 +51,12 @@ cost.
rproc_shutdown() returns, and users can still use it with a subsequent
rproc_boot(), if needed.
+ struct rproc *rproc_get_by_phandle(phandle phandle)
+- Find an rproc handle using a device tree phandle. Returns the rproc
+ handle on success, and NULL on failure. This function increments
+ the remote processor's refcount, so always use rproc_put() to
+ decrement it back once rproc isn't needed anymore.
+
3. Typical usage
#include linux/remoteproc.h
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 3cd85a63..5a6c192 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -36,6 +36,7 @@
#include linux/remoteproc.h
#include linux/iommu.h
#include linux/idr.h
+#include linux/klist.h
#include linux/elf.h
#include linux/crc32.h
#include linux/virtio_ids.h
@@ -44,6 +45,17 @@
#include remoteproc_internal.h
+static void klist_rproc_get(struct klist_node *n);
+static void klist_rproc_put(struct klist_node *n);
+
+/*
+ * klist of the available remote processors.
+ *
+ * We need this in order to support rproc lookups (needed by the
+ * rproc_get_by_phandle()).
+ */
+static DEFINE_KLIST(rprocs, klist_rproc_get, klist_rproc_put);
+
typedef int (*rproc_handle_resources_t)(struct rproc *rproc,
struct resource_table *table, int len);
typedef int (*rproc_handle_resource_t)(struct rproc *rproc,
@@ -1162,6 +1174,71 @@ out:
}
EXPORT_SYMBOL(rproc_shutdown);
+/* will be called when an rproc is added to the rprocs klist */
+static void klist_rproc_get(struct klist_node *n)
+{
+ struct rproc *rproc = container_of(n, struct rproc, node);
+
+ get_device(rproc-dev);
+}
+
+/* will be called when an rproc is removed from the rprocs klist */
+static void klist_rproc_put(struct klist_node *n)
+{
+ struct rproc *rproc = container_of(n, struct rproc, node);
+
+ put_device(rproc-dev);
+}
+
+static struct rproc *next_rproc(struct klist_iter *i)
+{
+ struct klist_node *n;
+
+ n = klist_next(i);
+ if (!n)
+ return NULL;
+
+ return container_of(n, struct rproc, node);
+}
+
+/**
+ * rproc_get_by_phandle() - find a remote processor by phandle
+ * @phandle: phandle to the rproc
+ *
+ * Finds an rproc handle using the remote processor's phandle, and then
+ * return a handle to the rproc.
+ *
+ * Returns the rproc handle on success, and NULL on failure.
+ *
+ * This function increments the remote processor's refcount, so always
+ * use rproc_put() to decrement it back once rproc isn't needed anymore.
+ *
+ */
+struct rproc *rproc_get_by_phandle(phandle phandle)
+{
+ struct rproc *rproc;
+ struct klist_iter i;
+ struct device_node *np;
+
+ np = of_find_node_by_phandle(phandle);
+ if (!np)
+ return NULL;
+
+ /* find the remote processor, and upref its refcount */
+ klist_iter_init(rprocs, i);
+ while ((rproc = next_rproc(i)) != NULL)
+ if (rproc-dev.parent rproc-dev.parent-of_node == np) {
+ get_device(rproc-dev);
+ break;
+ }
+ klist_iter_exit(i);
+
+ of_node_put(np);
+
+ return rproc;
+}
+EXPORT_SYMBOL(rproc_get_by_phandle);
+
/**
* rproc_add() - register a remote processor
* @rproc: the remote processor handle to register
@@ -1191,6 +1268,9 @@ int rproc_add(struct rproc *rproc)
if (ret 0)
return ret;
+ /* expose to rproc_get_by_phandle users */
+ klist_add_tail(rproc-node, rprocs);
+
dev_info(dev, %s is available\n, rproc-name);
dev_info(dev, Note: remoteproc is still under development and
considered experimental.\n);
@@ -1380,6 +1460,9 @@ int rproc_del(struct rproc *rproc)
/* Free the copy of the resource table */
kfree(rproc-cached_table);
+ /* the rproc is downref'ed as soon as it's removed from the klist */
+ klist_del(rproc-node);
+
device_del(rproc-dev);
[PATCH v3 3/4] Documentation: dt: add bindings for TI Wakeup M3 processor
Add the device tree bindings document for the TI Wakeup M3 remote
processor devices on AM33xx and AM43xx SoCs. These devices are used
to offload low-level power management functionality, and are handled
by the wkup_m3 remoteproc driver.
Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
.../bindings/remoteproc/wkup_m3_rproc.txt | 52 ++
1 file changed, 52 insertions(+)
create mode 100644
Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
diff --git a/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
b/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
new file mode 100644
index 000..3a70073
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
@@ -0,0 +1,52 @@
+TI Wakeup M3 Remoteproc Driver
+==
+
+The TI AM33xx and AM43xx family of devices use a small Cortex M3 co-processor
+(commonly referred to as Wakeup M3 or CM3) to help with various low power tasks
+that cannot be controlled from the MPU. This CM3 processor requires a firmware
+binary to accomplish this. The wkup_m3 remoteproc driver handles the loading of
+the firmware and booting of the CM3.
+
+Wkup M3 Device Node:
+
+A wkup_m3 device node is used to represent the Wakeup M3 processor instance
+within the SoC. It is added as a child node of the parent interconnect bus
+(l4_wkup) through which it is accessible to the MPU.
+
+Required properties:
+
+- compatible: Should be one of,
+ ti,am3352-wkup-m3 for AM33xx SoCs
+ ti,am4372-wkup-m3 for AM43xx SoCs
+- reg: Should contain the address ranges for the two internal
+ memory regions, UMEM and DMEM. The parent node should
+ provide an appropriate ranges property for properly
+ translating these into bus addresses.
+- reg-names: Contains the corresponding names for the two memory
+ regions. These should be named umem dmem.
+- ti,hwmods: Name of the hwmod associated with the wkupm3 device.
+- ti,pm-firmware: Name of firmware file to be used for loading and
+ booting the wkup_m3 remote processor.
+
+Example:
+
+/* AM33xx */
+ocp {
+l4_wkup: l4_wkup@44c0 {
+ compatible = am335-l4-wkup, simple-bus;
+ ranges = 0 0x44c0 0x40;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ wkup_m3: wkup_m3@10 {
+ compatible = ti,am3352-wkup-m3;
+ reg = 0x10 0x4000,
+ 0x18 0x2000;
+ reg-names = umem, dmem;
+ ti,hwmods = wkup_m3;
+ ti,pm-firmware = am335x-pm-firmware.elf;
+ };
+ };
+
+ ...
+};
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: Fix fifo reads for dm816x with musb_dsps
* Andrew Morton a...@linux-foundation.org [150401 14:36]:
On Wed, 18 Mar 2015 15:48:02 -0700 Tony Lindgren t...@atomide.com wrote:
Looks like dm81xx can only do 32-bit fifo reads like am35x. Let's set
up musb-dsps with a custom read_fifo function based on the compatible
flag.
Otherwise we can get the following errors when starting dhclient on a
asix USB Ethernet adapter:
asix 2-1:1.0 eth2: asix_rx_fixup() Bad Header Length 0x003c, offset 4
While at it, let's also remove pointless cast of the driver data.
This breaks my i386 allmodconfig build.
+/* Similar to am35x, dm81xx support only 32-bit read operation */
+static void dsps_read_fifo32(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
+{
+ void __iomem *fifo = hw_ep-fifo;
+ u32 val;
+ int i;
+
+ /* Read for 32bit-aligned destination address */
+ if (likely((0x03 (unsigned long)dst) == 0) len = 4) {
+ readsl(fifo, dst, len 2);
akpm3:/usr/src/linux-4.0-rc6 grep -r readsl arch/x86
akpm3:/usr/src/linux-4.0-rc6
Yes sorry, the fix is to use ioread32_rep() instead. I already sent a fix
for that on the 25th as:
[PATCH 1/1] usb: musb: dsps: fix build on i386 when COMPILE_TEST is set
https://www.marc.info/?l=linux-usbm=142731859732737w=1
Felipe, can you please get that into Linux next?
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] mm/migrate: Mark unmap_and_move() noinline to avoid ICE in gcc 4.7.3
Andrew Morton a...@linux-foundation.org writes:
On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier marc.zyng...@arm.com wrote:
-static int unmap_and_move(new_page_t get_new_page, free_page_t
put_new_page,
- unsigned long private, struct page *page, int force,
- enum migrate_mode mode)
+static noinline int unmap_and_move(new_page_t get_new_page,
+ free_page_t put_new_page,
+ unsigned long private, struct page *page,
+ int force, enum migrate_mode mode)
{
int rc = 0;
int *result = NULL;
Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
the parameters on the stack, which is not going to help performance
either (not that this would be useful on 32bit ARM anyway...).
Any chance you could make this dependent on some compiler detection
mechanism?
With my arm compiler (gcc-4.4.4) the patch makes no difference -
unmap_and_move() isn't being inlined anyway.
How does this look?
Kevin, could you please retest? I might have fat-fingered something...
Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
However, I'm not sure how specific we can be on the versions.
/me goes to test a few more compilers... OK...
ICE: 4.7.1, 4.7.3, 4.8.3
OK: 4.6.3, 4.9.2, 4.9.3
The diff below[2] on top of yours compiles fine here and at least covers
the compilers I *know* to trigger the ICE.
Kevin
[1]
diff --git a/mm/migrate.c b/mm/migrate.c
index 25fd7f6291de..6e15ae3248e0 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -901,10 +901,10 @@ out:
}
/*
- * gcc-4.7.3 on arm gets an ICE when inlining unmap_and_move(). Work around
+ * gcc 4.7 and 4.8 on arm gets an ICE when inlining unmap_and_move(). Work
around
* it.
*/
-#if GCC_VERSION == 40703 defined(CONFIG_ARM)
+#if (GCC_VERSION = 40700 GCC_VERSION 40900) defined(CONFIG_ARM)
#define ICE_noinline noinline
#else
#define ICE_noinline
--
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] mm/migrate: Mark unmap_and_move() noinline to avoid ICE in gcc 4.7.3
On Wed, Apr 01, 2015 at 02:54:59PM -0700, Kevin Hilman wrote: Your patch on top of Geert's still compiles fine for me with gcc-4.7.3. However, I'm not sure how specific we can be on the versions. /me goes to test a few more compilers... OK... ICE: 4.7.1, 4.7.3, 4.8.3 OK: 4.6.3, 4.9.2, 4.9.3 The diff below[2] on top of yours compiles fine here and at least covers the compilers I *know* to trigger the ICE. Interesting. I'm using stock gcc 4.7.4 here, though I'm not building -next (only mainline + my tree + arm-soc) and it hasn't shown a problem yet. I think we need to ask the question: is the bug in stock GCC or Linaro GCC? If it's not in stock GCC, then it's a GCC vendor problem :) -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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 v4 3/7] drm/tilcdc: Add support for external tda998x encoder
On Wed, Apr 01, 2015 at 11:49:27AM +0300, Jyri Sarha wrote: Add support for an external compontised DRM encoder. The external encoder can be connected to tilcdc trough device tree graph binding. The binding document for tilcdc has been updated. The current implementation supports only tda998x encoder. To be able to filter out the unsupported video modes the tilcdc driver needs to hijack the external connectors helper functions. The tilcdc installes new helper functions that are otherwise identical to orignals, but the mode_valid() call-back check the mode first localy, before calling the original call-back. The tilcdc dirver restores the original helper functions before it is unbound from the external device. This is where the DRM model is weak - we don't really have a way to say this is the set of CRTCs which /can/ be associated with this connector, can any of the CRTCs accept this mode? and eliminate modes which fail that check. This problem seems to be one which recurrs, so I wonder if it's something which ought to be solved properly. It's made slightly more difficult because we don't really know which connectors could be associated with which CRTCs - that information is stored at the encoder level (with the encoders possible_crtcs), and I'm not sure we have a way for generic DRM code to know which encoders could be associated with which connectors. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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 v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi,
Am 01.04.2015 um 18:30 schrieb Rob Herring robherri...@gmail.com:
On Tue, Mar 10, 2015 at 4:27 PM, Marek Belisko ma...@goldelico.com wrote:
Signed-off-by: Marek Belisko ma...@goldelico.com
---
.../bindings/power_supply/twl4030_madc_battery.txt | 43
++
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
diff --git
a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
new file mode 100644
index 000..d3dd9d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
@@ -0,0 +1,43 @@
+twl4030_madc_battery
+
+Required properties:
+ - compatible : ti,twl4030-madc-battery
Is this a sub-node of the twl4030 or something? Please define where
this fits (hint: I would expect to be a sub node of a charging
controller or battery monitor).
It is a driver connecting some battery parameters with measurements provided
by the twl4030-madc to present a /sys/class/power_supply node for the battery
with a coarse estimate for the charging level.
So maybe the best wording is that it is a battery-driver assuming a twl4030-madc
providing raw measurements (voltage, charging).
Therefore it could as well be battery-twl4030-madc.
+ - capacity-uah : battery capacity in uAh
+ - ti,volt-to-capacity-charging-map : list of voltage(mV):level(%) values
+ for charging calibration (see example)
+ - ti,volt-to-capacity-discharging-map : list of voltage(mV):level(%) values
+ for discharging calibration (see example)
These seem like properties of the battery independent of the
battery/charging controller which is the twl4030. Ideally we would
define battery nodes generically and independent of the charge
controllers. Then there are smart batteries to consider too.
For smart batteries there are completely independent mechanisms
like I2C and HDQ/1-wire communication with fuel gauge chips (e.g. b27xxx).
Those do not need such battery properties because they are stored
in EEPROMs within these chips.
So all this is a quite special solution just for those handful of board that
have no smart battery and use exactly this twl4030 chip.
It is not intended to become a generic charging/fuel solution. Just
make it work with DT (it worked with platform_data since ~3.12).
BR,
Nikolaus
Rob
+ - io-channels: Should contain IIO channel specifiers
+ for each element in io-channel-names.
+- io-channel-names: Should contain the following values:
+ * temp - The ADC channel for temperature reading
+ * ichg - The ADC channel for battery charging status
+ * vbat - The ADC channel to measure the battery voltage
+
+Example:
+ madc-battery {
+ compatible = ti,twl4030-madc-battery;
+ capacity-uah = 120;
+ ti,volt-to-capacity-charging-map = 4200 100,
+ 4100 75,
+ 4000 55,
+ 3900 25,
+ 3800 5,
+ 3700 2,
+ 3600 1,
+ 3300 0;
+
+ ti,volt-to-capacity-discharging-map = 4200 100
+ 4100 95,
+ 4000 70,
+ 3800 50,
+ 3700 10,
+ 3600 5,
+ 3300 0;
+ io-channels = twl_madc 1,
+ twl_madc 10,
+ twl_madc 12;
+ io-channel-names = temp,
+ ichg,
+ vbat;
+ };
--
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
Re: [PATCH] usb: musb: Fix fifo reads for dm816x with musb_dsps
On Wed, 18 Mar 2015 15:48:02 -0700 Tony Lindgren t...@atomide.com wrote:
Looks like dm81xx can only do 32-bit fifo reads like am35x. Let's set
up musb-dsps with a custom read_fifo function based on the compatible
flag.
Otherwise we can get the following errors when starting dhclient on a
asix USB Ethernet adapter:
asix 2-1:1.0 eth2: asix_rx_fixup() Bad Header Length 0x003c, offset 4
While at it, let's also remove pointless cast of the driver data.
This breaks my i386 allmodconfig build.
+/* Similar to am35x, dm81xx support only 32-bit read operation */
+static void dsps_read_fifo32(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
+{
+ void __iomem *fifo = hw_ep-fifo;
+ u32 val;
+ int i;
+
+ /* Read for 32bit-aligned destination address */
+ if (likely((0x03 (unsigned long)dst) == 0) len = 4) {
+ readsl(fifo, dst, len 2);
akpm3:/usr/src/linux-4.0-rc6 grep -r readsl arch/x86
akpm3:/usr/src/linux-4.0-rc6
+ dst += len ~0x03;
+ len = 0x03;
+ }
+ /*
+ * Now read the remaining 1 to 3 byte or complete length if
+ * unaligned address.
+ */
+ if (len 4) {
+ for (i = 0; i (len 2); i++) {
+ *(u32 *)dst = musb_readl(fifo, 0);
+ dst += 4;
+ }
+ len = 0x03;
+ }
+ if (len 0) {
+ val = musb_readl(fifo, 0);
+ memcpy(dst, val, len);
+ }
+}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] ARM: OMAP2+: Use pdata-quirks for wkup_m3 reset management
Use pdata-quirks to provide platform data required for reset
management during boot and shutdown of the wkup_m3 processor
on both the AM33xx and AM43xx SoCs. The WkupM3 remote processor
is used to implement and achieve low-power functionality on
the AM33xx AM43xx SoCs.
Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/mach-omap2/pdata-quirks.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index e642b07..7b4a4c1 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -18,6 +18,7 @@
#include linux/platform_data/pinctrl-single.h
#include linux/platform_data/iommu-omap.h
+#include linux/platform_data/wkup_m3.h
#include common.h
#include common-board-devices.h
@@ -314,6 +315,14 @@ static struct iommu_platform_data omap4_iommu_pdata = {
};
#endif
+#if defined(CONFIG_SOC_AM33XX) || defined(CONFIG_SOC_AM43XX)
+static struct wkup_m3_platform_data wkup_m3_data = {
+ .reset_name = wkup_m3,
+ .assert_reset = omap_device_assert_hardreset,
+ .deassert_reset = omap_device_deassert_hardreset,
+};
+#endif
+
#ifdef CONFIG_SOC_AM33XX
static void __init am335x_evmsk_legacy_init(void)
{
@@ -383,6 +392,10 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA(ti,am3517-emac, 0x5c00, davinci_emac.0,
am35xx_emac_pdata),
#endif
+#ifdef CONFIG_SOC_AM33XX
+ OF_DEV_AUXDATA(ti,am3352-wkup-m3, 0x44d0, 44d0.wkup_m3,
+ wkup_m3_data),
+#endif
#ifdef CONFIG_ARCH_OMAP4
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a100040, 4a100040.pinmux,
pcs_pdata),
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a31e040, 4a31e040.pinmux,
pcs_pdata),
@@ -396,6 +409,8 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
#endif
#ifdef CONFIG_SOC_AM43XX
OF_DEV_AUXDATA(ti,am437-padconf, 0x44e10800, 44e10800.pinmux,
pcs_pdata),
+ OF_DEV_AUXDATA(ti,am4372-wkup-m3, 0x44d0, 44d0.wkup_m3,
+ wkup_m3_data),
#endif
#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
OF_DEV_AUXDATA(ti,omap4-iommu, 0x4a066000, 4a066000.mmu,
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/3] ARM: dts: AM33xx: Update and move wkup_m3 node to l4 node
From: Suman Anna s-a...@ti.com
The WakeupM3 remote processor device node has been moved to
be a child node of the newly created l4_wkup node, to reflect
its presence properly within the SoC. The node was added
previously before any driver support, it is now updated as
per the wkup_m3_rproc bindings added alongside the driver
support.
Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 21fcc44..4c1b4a8 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -103,6 +103,15 @@
#size-cells = 1;
ranges = 0 0x44c0 0x28;
+ wkup_m3: wkup_m3@10 {
+ compatible = ti,am3352-wkup-m3;
+ reg = 0x10 0x4000,
+ 0x18 0x2000;
+ reg-names = umem, dmem;
+ ti,hwmods = wkup_m3;
+ ti,pm-firmware = am335x-pm-firmware.elf;
+ };
+
prcm: prcm@20 {
compatible = ti,am3-prcm;
reg = 0x20 0x4000;
@@ -762,14 +771,6 @@
reg = 0x4030 0x1; /* 64k */
};
- wkup_m3: wkup_m3@44d0 {
- compatible = ti,am3353-wkup-m3;
- reg = 0x44d0 0x4000/* M3 UMEM */
- 0x44d8 0x2000; /* M3 DMEM */
- ti,hwmods = wkup_m3;
- ti,no-reset-on-init;
- };
-
elm: elm@4808 {
compatible = ti,am3352-elm;
reg = 0x4808 0x2000;
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/3] ARM: OMAP2+: wkup_m3_rproc support patches
This series adds the mach-omap2 code and DT nodes for v3 of the wkup_m3_rproc driver submitted here [1]. pdata-quirks patch requires the pdata added with patch 4 of the aforementioned series. Based on previous discussion here [2], the wkup_m3 DT node has been moved as a child of the l4_wkup as is done for l4_wkup components in Tero Kristo's series PRCM+SCM cleanup against 4.0-rc1 found here [3]. Because of that, this series applies cleanly on top of that series in order to leverage the l4_wkup parent node introduced there. In addition to the move of the wkup_m3 node for am33xx, a new patch has been added to introduce the wkup_m3 node in the same fashion for am43xx as both SoCs use the same configuration. With this change support was also added to pdata-quirks for passing reset handlers to the driver for the am43xx binding as was already done for am33xx. I have pushed a branch containing all patches for am335x suspend here for a big picture view of how all patches fit together with these wkup_m3_rproc series [4]. v2-v3: -Change ti,am3353-wkup-m3 compat to ti,am3352-wkup-m3 to reflect binding documentation change -Add ti,am4372-wkup-m3 node to am4372 SoC dt file -Add am4372 support to pdata-quirks for reset handlers Regards, Dave [1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg115869.html [2] http://www.spinics.net/lists/linux-omap/msg116366.html [3] http://www.spinics.net/lists/arm-kernel/msg409842.html [4] https://github.com/dgerlach/linux-pm/tree/pm-v4.0-rc5-am335x-suspend Dave Gerlach (1): ARM: OMAP2+: Use pdata-quirks for wkup_m3 reset management Suman Anna (2): ARM: dts: AM33xx: Update and move wkup_m3 node to l4 node ARM: dts: AM4372: Add the wkupm3 rproc node arch/arm/boot/dts/am33xx.dtsi | 17 + arch/arm/boot/dts/am4372.dtsi | 9 + arch/arm/mach-omap2/pdata-quirks.c | 15 +++ 3 files changed, 33 insertions(+), 8 deletions(-) -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi! As I explained in some other mail, those tables should not be neccessary at all. They can be computed from li-ion characteristics and internal resistance, and assumed current during charge and discharge. I already explained that we do not know the charging and discharging current well enough for such a calculation. And I explained that the “internal resistance” is a system (battery + cables + connectors + other circuits) parameter that is not easy to derive or measure and type into the .dts source code. At least I have no idea how I should find it out for my boards. While I can easily determine the curves (and we already have them for the platform_data driver). Please propose your own code doing that so that we can test if it is better. So, how does this look? It looks to me like you have cca 0.1 Ohm resistance in your system, and are using cca 75mA while discharging, and charge by cca 1.4A. (And these are all the coefficients the code should need; rest is battery characteristics -- common to all li-ions, and charger characteristics -- that will be common to all cellphones. If current can be measured, this code should go more precise answers). pavel@amd:~/g/tui/ofone$ ./liion_maps Charging Voltage 4.2 V ; table 100 % internal voltage 4.18 V current 0.233 A computed 97 % Voltage 4.1 V ; table 75 % internal voltage 4.08 V current 0.233 A computed 87 % Voltage 4.0 V ; table 55 % internal voltage 3.93 V current 0.700 A computed 69 % Voltage 3.9 V ; table 25 % internal voltage 3.76 V current 1.400 A computed 26 % Voltage 3.8 V ; table 5 % internal voltage 3.66 V current 1.400 A computed 3 % Voltage 3.7 V ; table 2 % internal voltage 3.56 V current 1.400 A computed 2 % Voltage 3.6 V ; table 1 % internal voltage 3.46 V current 1.400 A computed 1 % Voltage 3.3 V ; table 0 % internal voltage 3.16 V current 1.400 A computed -1 % Badness 395.4861761427434 Discharging Voltage 4.2 V ; table 100 % internal voltage 4.21 V current -0.075 A computed 100 % Voltage 4.1 V ; table 95 % internal voltage 4.11 V current -0.075 A computed 91 % Voltage 4.0 V ; table 70 % internal voltage 4.01 V current -0.075 A computed 79 % Voltage 3.8 V ; table 50 % internal voltage 3.81 V current -0.075 A computed 46 % Voltage 3.7 V ; table 10 % internal voltage 3.71 V current -0.075 A computed 3 % Voltage 3.6 V ; table 5 % internal voltage 3.61 V current -0.075 A computed 2 % Voltage 3.3 V ; table 0 % internal voltage 3.31 V current -0.075 A computed 0 % Badness 171.69576218433212 Running below 3.3V.. not really. At that point, the battery is really _empty_, and voltage is going down really really fast. It is the diffference between 2% and 0% where a fuel indication might be most important… Plus, you are damaging the battery at that point. The power controller will shut down - but the driver should report reasonable (but IMHO not necessarily perfect) values until the last moment. It is tricky to do a good job near 0%... or anywhere else. See for example http://cseweb.ucsd.edu/~trosing/lectures/battery.pdf You start a call, percentage goes down, end a call, it will go back up. I'm pretty sure you will not be able to make a call with 5% indication from your code at low battery temperature (say -10C). Anyway, see above, I think I provide reasonable values even in that range. Signed-off-by: Pavel Machek pa...@ucw.cz Pavel #!/usr/bin/python3 import math def percent_internal(v): u = 0.0387-(1.4523*(3.7835-v)) if u 0: # Formula above does gives 19.66% for 3.756, and refuses to # work below that. Assume 3.3V is empty battery, and provide # linear dependency below that. u = (v - 3.3) * ((3.756 - 3.3) * 19.66) return u return (0.1966+math.sqrt(u))*100 charging = [ [4200, 100], [4100, 75], [4000, 55], [3900, 25], [3800, 5], [3700, 2], [3600, 1], [3300, 0] ] discharging = [ [4200, 100], [4100, 95], [4000, 70], [3800, 50], [3700, 10], [3600, 5], [3300, 0] ] # current 0: charging def percent_ohm(v, current): v_int = v - current * 0.1 print( internal voltage %1.2f V current %.3f A % (v_int, current), end='') return percent_internal(v_int) def percent(v, charging): if charging: # Charger model. Chargers will do constant current then # constant voltage, so current will go down as voltage # approaches 4.2V i = 2.8 if v = 4.: i = i/2 if v = 4.05: i = i/3 else: i = -0.15 # With current forced to 0, we get badness 4014 and 258 # 2.5A, sloped: badness 576 # +4A - badness 1293 # +3A - badness 890 # +2.5A - 339 # +2.4A - badness 389 # +2.3A - badness 444 # +2.2A - badness 504 # +2A - badness 634 # +1A - badness 1450 # +0.5A - badness 2865 #
Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi, Am 01.04.2015 um 22:16 schrieb Pavel Machek pa...@ucw.cz: Hi! As I explained in some other mail, those tables should not be neccessary at all. They can be computed from li-ion characteristics and internal resistance, and assumed current during charge and discharge. I already explained that we do not know the charging and discharging current well enough for such a calculation. And I explained that the “internal resistance” is a system (battery + cables + connectors + other circuits) parameter that is not easy to derive or measure and type into the .dts source code. At least I have no idea how I should find it out for my boards. While I can easily determine the curves (and we already have them for the platform_data driver). Please propose your own code doing that so that we can test if it is better. So, how does this look? It looks to me like you have cca 0.1 Ohm resistance in your system, This is completely unknown. and are using cca 75mA while discharging, and charge by cca 1.4A. Where do you get these figures from? A GTA04 board discharges usually between 50 and 400 mA (depending on activities) and if you turn on WiFi, it will be up to 600 mA. If you use 3G it can draw even more during operation. Total current going in is 500-800 mA (depending on USB negotiations) and this is split into system operation and charging current. So 1.4A charging current is not possible. Rather 200-500 mA. So it might be that the battery is discharged although the system is connected to a charger. (And these are all the coefficients the code should need; rest is battery characteristics -- common to all li-ions, and charger characteristics -- that will be common to all cellphones. If current can be measured, this code should go more precise answers). pavel@amd:~/g/tui/ofone$ ./liion_maps Charging Voltage 4.2 V ; table 100 % internal voltage 4.18 V current 0.233 A computed 97 % Voltage 4.1 V ; table 75 % internal voltage 4.08 V current 0.233 A computed 87 % Voltage 4.0 V ; table 55 % internal voltage 3.93 V current 0.700 A computed 69 % Voltage 3.9 V ; table 25 % internal voltage 3.76 V current 1.400 A computed 26 % Voltage 3.8 V ; table 5 % internal voltage 3.66 V current 1.400 A computed 3 % Voltage 3.7 V ; table 2 % internal voltage 3.56 V current 1.400 A computed 2 % Voltage 3.6 V ; table 1 % internal voltage 3.46 V current 1.400 A computed 1 % Voltage 3.3 V ; table 0 % internal voltage 3.16 V current 1.400 A computed -1 % Badness 395.4861761427434 Discharging Voltage 4.2 V ; table 100 % internal voltage 4.21 V current -0.075 A computed 100 % Voltage 4.1 V ; table 95 % internal voltage 4.11 V current -0.075 A computed 91 % Voltage 4.0 V ; table 70 % internal voltage 4.01 V current -0.075 A computed 79 % Voltage 3.8 V ; table 50 % internal voltage 3.81 V current -0.075 A computed 46 % Voltage 3.7 V ; table 10 % internal voltage 3.71 V current -0.075 A computed 3 % Voltage 3.6 V ; table 5 % internal voltage 3.61 V current -0.075 A computed 2 % Voltage 3.3 V ; table 0 % internal voltage 3.31 V current -0.075 A computed 0 % Badness 171.69576218433212 Running below 3.3V.. not really. At that point, the battery is really _empty_, and voltage is going down really really fast. It is the diffference between 2% and 0% where a fuel indication might be most important… Plus, you are damaging the battery at that point. The power controller will shut down - but the driver should report reasonable (but IMHO not necessarily perfect) values until the last moment. It is tricky to do a good job near 0%... or anywhere else. See for example http://cseweb.ucsd.edu/~trosing/lectures/battery.pdf You start a call, percentage goes down, end a call, it will go back up. I'm pretty sure you will not be able to make a call with 5% indication from your code at low battery temperature (say -10C). The whole system is heating up a little, so that you never have -10C for the battery. I think you are trying to solve situations that don’t exist in practice. And AFAIK, the GTA04 board is the only user of this driver in case the battery has no built-in fuel gauge. So why improve it beyond what the GTA04 users need? I repeat myself: this driver is not built for highest precision because there are better methods (fuel gauge chip). These might not be available so this fall-back driver has been built. It is definitively better than no driver and worse than the optimum. Anyway, see above, I think I provide reasonable values even in that range. Signed-off-by: Pavel Machek pa...@ucw.cz Pavel #!/usr/bin/python3 import math def percent_internal(v): u = 0.0387-(1.4523*(3.7835-v)) if u 0: # Formula above does gives 19.66% for 3.756, and refuses to # work below that.
Re: [PATCH RESEND] ARM: dts: OMAP3-N900: Add microphone bias voltages
* Sebastian Reichel s...@kernel.org [150331 05:33]: Hi, On Mon, Mar 30, 2015 at 10:50:52AM -0700, Tony Lindgren wrote: * Jarkko Nikula jarkko.nik...@bitmer.com [150330 10:46]: Well, there has been regression but finding exactly how far should the fix go didn't look instantly straightforward due all DT, codec driver mic bias etc changes and I ended up not cc'ing stable. But well, I guess first kernel where this commit makes sense is 3.16+ due commit f7d0f2a08567 (ARM: dts: omap3-n900: Add sound support). Although it applies on top of commit 14e3e295b2b9 (ARM: dts: omap3-n900: Add TLV320AIC3X support) too (3.12+) but not before that. OK I think debian is using v3.16 kernel Yes. It will be used for Debian jessie (not yet released) and the N900 related drivers are enabled in the armmp flavour. Unfortunately it does not work together with thumb using userland because the errata 430973 workaround is not enabled. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768890 Hmm I believe many ARMv8 boards will be randomly oopsing with armhf without that. I sort of recall random oopses just with running apt-get update on ARMv8 omaps on armhf without that: http://www.spinics.net/lists/linux-omap/msg108511.html See also 5c86c5339c56 (ARM: omap2plus_defconfig: Enable ARM erratum 430973 for omap3). I wonder if the ARMv8 revision range might be wrong 430973 in kernel or errata? Also I recall that 430973 change to the arch/arm/mm/proc-v7-2level.S fixed the issue, this should be verified though. I guess it should be tried to change the workaround, so that it does only change the behaviour of affected platforms. Otherwise its a hard decision for distributions to enable the workaround. Well we should figure out first why flush BTAC/BTB is needed in cpu_v7_switch_mm.. And if what I'm describing above is still reproducable. and that's pretty much the first kernel that is usable with dts on many omap3 devices so might make sense for that. DT support for N900's soundcard has been added in 3.16, so before that the audio stuff didn't work at all. I can add it if you think it makes sense. I guess backporting this makes sense because of fewer broken DTB files in the wild. Anyways yeah adding $subject patch into omap-for-v4.0/fixes with cc stable v3.16+. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/3] ARM: dts: AM4372: Add the wkupm3 rproc node
From: Suman Anna s-a...@ti.com
Add the Wakeup M3 remote processor device node for
the AM4372 SoC. The WkupM3 remote processor is used
to implement and achieve low-power functionality on
the AM33xx AM43xx SoCs.
This node is added as a child of the recently added
l4_wkup node to reflect its presence within the SoC.
Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index f8a02a2..821bb772 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -74,6 +74,15 @@
#size-cells = 1;
ranges = 0 0x44c0 0x287000;
+ wkup_m3: wkup_m3@10 {
+ compatible = ti,am4372-wkup-m3;
+ reg = 0x10 0x4000,
+ 0x18 0x2000;
+ reg-names = umem, dmem;
+ ti,hwmods = wkup_m3;
+ ti,pm-firmware = am335x-pm-firmware.elf;
+ };
+
prcm: prcm@1f {
compatible = ti,am4-prcm;
reg = 0x1f 0x11000;
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ASoC: davinci-mcasp: Index ruledata in drvdata with substream-stream
On Fri, Mar 27, 2015 at 11:47:51AM +0200, Jyri Sarha wrote: The serializer direction definitions runs from 1 to 2, which does not suite the purpose. The substream-stream is perfect for the purpose and should have been used from the beginning. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 1/1] omap3isp: Don't pass uninitialised arguments to of_graph_get_next_endpoint()
Hi Sebastian,
On Tue, Mar 31, 2015 at 03:37:20AM +0200, Sebastian Reichel wrote:
Hi,
On Tue, Mar 31, 2015 at 02:13:28AM +0300, Sakari Ailus wrote:
isp_of_parse_nodes() passed an uninitialised prev argument to
of_graph_get_next_endpoint(). This is bad, fix it by assigning NULL to it in
the initialisation.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Reported-by: Sebastian Reichel s...@kernel.org
---
drivers/media/platform/omap3isp/isp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index ff8f633..ff51c4f 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -2338,7 +2338,7 @@ static int isp_of_parse_node(struct device *dev,
struct device_node *node,
static int isp_of_parse_nodes(struct device *dev,
struct v4l2_async_notifier *notifier)
{
- struct device_node *node;
+ struct device_node *node = NULL;
notifier-subdevs = devm_kcalloc(
dev, ISP_MAX_SUBDEVS, sizeof(*notifier-subdevs), GFP_KERNEL);
Acked-By: Sebastian Reichel s...@kernel.org
Note, that this actually triggered the following stacktrace for me,
so you may want to add a Fixes: commitid and the stacktrace to the
commit message if its not merged with the original commit (relevant
for people doing git bisect).
Thanks.
Laurent merged the patch with the original one, and will send a new pull
request.
--
Regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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
