Re: [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
On Thursday 14 February 2013 12:28 PM, Tomi Valkeinen wrote:
On 2013-02-14 08:51, Archit Taneja wrote:
On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:
Hi,
On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
+static struct panel_acx565akm_data *get_panel_data(struct
omap_dss_device *dssdev)
+{
+return (struct panel_acx565akm_data *) dssdev->data;
+}
+
static int acx_panel_probe(struct omap_dss_device *dssdev)
{
int r;
struct acx565akm_device *md = &acx_dev;
+struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
Why the get_panel_data function is needed, isn't the cast unnecessary?
the 'data' member of omap_dss_device has the type 'void *', we need to
cast it to access the panel_acx565akm_data struct pointer.
You don't need an explicit cast to assign a void pointer to a pointer to
something else (or vice versa, I think).
I remember us having similar constructs in some other panel drivers
also. I think they are unnecessary also.
I was considering keeping the get_panel_data() funcs in the panel
drivers though. This way, whenever the way of retrieving platform data
changes because of DT or CDF or something else, we would just need to
modify the get_panel_data func.
Archit
--
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] omapdrm: Make fixed resolution panels work
On Thursday 14 February 2013 09:24 PM, Rob Clark wrote:
On Thu, Feb 14, 2013 at 6:52 AM, Archit Taneja wrote:
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel driver
has these ops or not, and that leads to a crash.
The following things are done to make fixed panels work:
- The omap_connector's detect function is modified such that it considers panel
types which are generally fixed panels as always connected(provided the panel
driver doesn't have a detect op). Hence, the connector corresponding to these
panels is always in a 'connected' state.
- If a panel driver doesn't have a check_timings op, assume that it supports the
mode passed to omap_connector_mode_valid(the 'mode_valid' drm helper
function)
- The function omap_encoder_update shouldn't really do anything for fixed
resolution panels, make sure that it calls set_timings only if the panel
driver has one.
I tested this with picodlp on a OMAP4 sdp board. I couldn't get any other
working boards with fixed DPI panels. I could try the DSI video mode panel
on an OMAP5 sevm, but that will require me to patch a lot of things to get
omap5 dss work with DT. I can try if needed.
Signed-off-by: Archit Taneja
---
drivers/staging/omapdrm/omap_connector.c | 10 --
drivers/staging/omapdrm/omap_encoder.c |6 --
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_connector.c
b/drivers/staging/omapdrm/omap_connector.c
index 4cc9ee7..839c6e4 100644
--- a/drivers/staging/omapdrm/omap_connector.c
+++ b/drivers/staging/omapdrm/omap_connector.c
@@ -110,6 +110,11 @@ static enum drm_connector_status omap_connector_detect(
ret = connector_status_connected;
else
ret = connector_status_disconnected;
+ } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI ||
+ dssdev->type == OMAP_DISPLAY_TYPE_DBI ||
+ dssdev->type == OMAP_DISPLAY_TYPE_SDI ||
+ dssdev->type == OMAP_DISPLAY_TYPE_DSI) {
+ ret = connector_status_connected;
hmm, why not just have a default detect fxn for panel drivers which
always returns true? Seems a bit cleaner.. otherwise, I guess we
could just change omap_connector so that if dssdev->detect is null,
assume always connected. Seems maybe a slightly better way since
currently omap_connector doesn't really know too much about different
sorts of panels. But I'm not too picky if that is a big pain because
we probably end up changing all this as CFP starts coming into
existence.
Same goes for check_timings/set_timings.. it seems a bit cleaner just
to have default fxns in the panel drivers that do-the-right-thing,
although I suppose it might be a bit more convenient for out-of-tree
panel drivers to just assume fixed panel if these fxns are null.
Maybe having default functions in omapdss might be a better idea. There
is an option of adding default functions in omap_dss_register_driver()
(drivers/video/omap2/dss/core.c).
Tomi, do you think it's fine to add some more default panel driver funcs?
Archit
BR,
-R
} else {
ret = connector_status_unknown;
}
@@ -189,12 +194,13 @@ static int omap_connector_mode_valid(struct drm_connector
*connector,
struct omap_video_timings timings = {0};
struct drm_device *dev = connector->dev;
struct drm_display_mode *new_mode;
- int ret = MODE_BAD;
+ int r, ret = MODE_BAD;
copy_timings_drm_to_omap(&timings, mode);
mode->vrefresh = drm_mode_vrefresh(mode);
- if (!dssdrv->check_timings(dssdev, &timings)) {
+ r = dssdrv->check_timings ? dssdrv->check_timings(dssdev, &timings) : 0;
+ if (!r) {
/* check if vrefresh is still valid */
new_mode = drm_mode_duplicate(dev, mode);
new_mode->clock = timings.pixel_clock;
diff --git a/drivers/staging/omapdrm/omap_encoder.c
b/drivers/staging/omapdrm/omap_encoder.c
index e053160..871af12e 100644
--- a/drivers/staging/omapdrm/omap_encoder.c
+++ b/drivers/staging/omapdrm/omap_encoder.c
@@ -128,13 +128,15 @@ int omap_encoder_update(struct drm_encoder *encoder,
dssdev->output->manager = mgr;
- ret = dssdrv->check_timings(dssdev, timings);
+ ret = dssdrv->check_timings ?
+ dssdrv->check_timings(dssdev, timings) : 0;
if (ret) {
dev_err(dev->dev, "could not set timings: %d\n", ret);
return ret;
}
- dssdrv->set_timings(dssdev, timings);
+ if (dssdrv->set_timings)
+ dssdrv->set_timings(dssdev, timings);
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-om
[RFC 2/8] ARM: twd: register clock event for 1 core SMP
Register percpu local timer for scheduler tick in the case of one core SMP configuration. In other cases - secondary cpu's as well as boot cpu's having more than one core, this is being registered as per existing boot flow, with a difference that they happens after delay calibration. Registering the clock for tick in case of one core should be done before Kernel calibrates delay (this is required to boot, unless local timer is the only one registered for tick). Registering twd local timer at init_time (which platforms are doing now) helps achieve that with the proposed change. This helps in an almost booting Kernel (minimal) by only relying on ARM parts for an A9 one core SMP. Signed-off-by: Afzal Mohammed --- arch/arm/kernel/smp_twd.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c index 616268c..118f4f2 100644 --- a/arch/arm/kernel/smp_twd.c +++ b/arch/arm/kernel/smp_twd.c @@ -335,6 +335,9 @@ static int __init twd_local_timer_common_register(struct device_node *np) twd_get_clock(np); + if (num_possible_cpus() == 1) + twd_timer_setup(evt); + return 0; out_irq: -- 1.7.12 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 3/8] ARM: twd: clock rate from DT (if no DT clk tree)
Add an optional property to find clock-frequency from DT. This helps
as a fallback mechanism in case there is no representation of clock
tree in DT.
Signed-off-by: Afzal Mohammed
---
Documentation/devicetree/bindings/arm/twd.txt | 7 ++-
arch/arm/kernel/smp_twd.c | 8
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/twd.txt
b/Documentation/devicetree/bindings/arm/twd.txt
index 75b8610..fdafa4f 100644
--- a/Documentation/devicetree/bindings/arm/twd.txt
+++ b/Documentation/devicetree/bindings/arm/twd.txt
@@ -7,8 +7,9 @@ and watchdog.
The TWD is usually attached to a GIC to deliver its two per-processor
interrupts.
-** Timer node required properties:
+** Timer node properties:
+Required properties:
- compatible : Should be one of:
"arm,cortex-a9-twd-timer"
"arm,cortex-a5-twd-timer"
@@ -19,12 +20,16 @@ interrupts.
- reg : Specify the base address and the size of the TWD timer
register window.
+Optional property:
+- clock-frequency : frequency(Hz) of peripheral clock fed to timer
+
Example:
twd-timer@2c000600 {
compatible = "arm,arm11mp-twd-timer"";
reg = <0x2c000600 0x20>;
interrupts = <1 13 0xf01>;
+ clock-frequency = <3>;
};
** Watchdog node properties:
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index 118f4f2..aac0f9f 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -247,7 +247,15 @@ static void twd_get_clock(struct device_node *np)
twd_clk = clk_get_sys("smp_twd", NULL);
if (IS_ERR(twd_clk)) {
+ u32 freq;
+
pr_err("smp_twd: clock not found %d\n", (int) PTR_ERR(twd_clk));
+
+ /* If there is no representation of clock tree in DT,
+ provide a fallback option to obtain frequency
+*/
+ if (np && !of_property_read_u32(np, "clock-frequency", &freq))
+ twd_timer_rate = freq;
return;
}
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 8/8] ARM: dts: am43-pre-silicon support
AM43 SoC is in pre-silicon stage, meanwhile it has been modelled in
a pre-silicon platform. To validate and boot Linux in pre-silicon
platform that emulates an AM43 SoC, add DT build support.
As bootloader is not used, bootargs is passed through DT.
Note: This would be replaced by an original board support.
Signed-off-by: Afzal Mohammed
---
arch/arm/boot/dts/Makefile | 3 ++-
arch/arm/boot/dts/am43-pre-silicon.dts | 31 +++
2 files changed, 33 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/am43-pre-silicon.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 94d88b9..b434344 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -124,7 +124,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap5-evm.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
- am335x-bone.dtb
+ am335x-bone.dtb \
+ am43-pre-silicon.dtb
dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
diff --git a/arch/arm/boot/dts/am43-pre-silicon.dts
b/arch/arm/boot/dts/am43-pre-silicon.dts
new file mode 100644
index 000..b9c6297
--- /dev/null
+++ b/arch/arm/boot/dts/am43-pre-silicon.dts
@@ -0,0 +1,31 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/* AM43 Pre Silicon */
+
+/dts-v1/;
+
+/include/ "am4372.dtsi"
+
+/ {
+ model = "TI AM43 Pre Silicon";
+ compatible = "ti,am43-pre-silicon","ti,am4372","ti,am43";
+
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x1000>; /* 256 MB */
+ };
+
+ chosen {
+ bootargs = "console=ttyO0,115200n8 root=/dev/ram rw
initrd=0x8200,32MB earlyprintk";
+ };
+};
+
+&twd1 {
+ clock-frequency = <3>;
+};
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 6/8] ARM: OMAP2+: am43: basic dt support
Describe minimal DT boot machine details for AM43 based SoC's. AM43
family of SoC's are ARM Cortex-A9 based with one core in SMP
configuration. Low level debug could be achieved by selecting
DEBUG_AM33XXUART1. To boot AM43 SoC, this change is sufficient w.r.t
Kernel (considering the fact that strictly speaking DT sources does
not classify as a part of Kernel). Here private timer of the one and
only core is being used as clock event (as well as, as time source).
Signed-off-by: Afzal Mohammed
---
arch/arm/mach-omap2/board-generic.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 0274ff7..e083f08 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,7 +15,10 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include "common.h"
@@ -182,3 +185,18 @@ DT_MACHINE_START(OMAP5_DT, "Generic OMAP5 (Flattened
Device Tree)")
.restart= omap44xx_restart,
MACHINE_END
#endif
+
+#ifdef CONFIG_SOC_AM43
+static const char *am43_boards_compat[] __initdata = {
+ "ti,am43",
+ NULL,
+};
+
+DT_MACHINE_START(AM43_DT, "Generic AM43 (Flattened Device Tree)")
+ .map_io = debug_ll_io_init,
+ .init_irq = irqchip_init,
+ .init_machine = omap_generic_init,
+ .init_time = twd_local_timer_of_register,
+ .dt_compat = am43_boards_compat,
+MACHINE_END
+#endif
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 4/8] ARM: am33xx: ll debug config help
Selecting DEBUG_AM33XXUART1 routes low level debug messages to first UART instance of AM335x based SoC's. This selection is valid for upcoming AM43 based SoC's too. Make this information available upon configuring. Signed-off-by: Afzal Mohammed --- arch/arm/Kconfig.debug | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index aca..b717b78 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -542,6 +542,9 @@ choice config DEBUG_AM33XXUART1 bool "AM33XX UART1" + help + Route low level debug messages to first uart instance + for boards based on am335 and am43 family of SoC's config DEBUG_ZOOM_UART bool "Zoom2/3 UART" -- 1.7.12 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 5/8] ARM: OMAP2+: am43: Kconfig
Add Kconfig option for AM43 family of SoC's, these are ARM Cortex A9 based (SMP configuration with 1 core). Signed-off-by: Afzal Mohammed --- arch/arm/mach-omap2/Kconfig | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 49ac3df..683fbaa 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -141,6 +141,17 @@ config SOC_AM33XX select MULTI_IRQ_HANDLER select COMMON_CLK +config SOC_AM43 + bool "TI AM43" + depends on ARCH_OMAP2PLUS + default y + select CPU_V7 + select HAVE_SMP + select LOCAL_TIMERS if SMP + select MULTI_IRQ_HANDLER + select ARM_GIC + select COMMON_CLK + config OMAP_PACKAGE_ZAF bool -- 1.7.12 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 7/8] ARM: dts: am4372: initial support
DT source (minimal) for AM4372 SoC. Those represented here are the
minimal DT nodes necessary to get kernel booting.
Signed-off-by: Afzal Mohammed
---
arch/arm/boot/dts/am4372.dtsi | 55 +++
1 file changed, 55 insertions(+)
create mode 100644 arch/arm/boot/dts/am4372.dtsi
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
new file mode 100644
index 000..178c41f
--- /dev/null
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -0,0 +1,55 @@
+/*
+ * Device Tree Source for AM4372 SoC
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+ compatible = "ti,am4372", "ti,am43";
+ interrupt-parent = <&gic>;
+
+
+ aliases {
+ serial0 = &uart1;
+ };
+
+ cpus {
+ cpu@0 {
+ compatible = "arm,cortex-a9";
+ };
+ };
+
+ gic: interrupt-controller@48241000 {
+ compatible = "arm,cortex-a9-gic";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0x48241000 0x1000>,
+ <0x48240100 0x0100>;
+ };
+
+ twd1: local-timer@0x48240600 {
+ compatible = "arm,cortex-a9-twd-timer";
+ reg = <0x48240600 0x20>;
+ interrupts = <1 13 0x304>;
+ };
+
+ ocp {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ uart1: serial@44e09000 {
+ compatible = "ti,am4372-uart","ti,omap2-uart";
+ clock-frequency = <4800>;
+ reg = <0x44e09000 0x2000>;
+ interrupts = <0 72 0x4>;
+ };
+ };
+};
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/8] ARM: localtimer: return percpu clkevt on register
Return percpu clock event on local timer register. It is the boot cpu
that calls this and it can use the returned percpu clock event to
register a clock event in the case of SMP configuration with one core.
This helps to have a booting Kernel even if no other timer is
registered for clock tick.
Signed-off-by: Afzal Mohammed
---
arch/arm/include/asm/localtimer.h | 7 ---
arch/arm/kernel/smp.c | 8
arch/arm/kernel/smp_twd.c | 5 +++--
3 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/arm/include/asm/localtimer.h
b/arch/arm/include/asm/localtimer.h
index f77ffc1..c3f89c0 100644
--- a/arch/arm/include/asm/localtimer.h
+++ b/arch/arm/include/asm/localtimer.h
@@ -23,11 +23,12 @@ struct local_timer_ops {
/*
* Register a local timer driver
*/
-int local_timer_register(struct local_timer_ops *);
+struct clock_event_device *local_timer_register(struct local_timer_ops *);
#else
-static inline int local_timer_register(struct local_timer_ops *ops)
+static inline
+struct clock_event_device *local_timer_register(struct local_timer_ops *ops)
{
- return -ENXIO;
+ return ERR_PTR(-ENXIO);
}
#endif
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 5f73f70..42d95d6 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -491,16 +491,16 @@ static void __cpuinit broadcast_timer_setup(struct
clock_event_device *evt)
static struct local_timer_ops *lt_ops;
#ifdef CONFIG_LOCAL_TIMERS
-int local_timer_register(struct local_timer_ops *ops)
+struct clock_event_device *local_timer_register(struct local_timer_ops *ops)
{
if (!is_smp() || !setup_max_cpus)
- return -ENXIO;
+ return ERR_PTR(-ENXIO);
if (lt_ops)
- return -EBUSY;
+ return ERR_PTR(-EBUSY);
lt_ops = ops;
- return 0;
+ return &per_cpu(percpu_clockevent, smp_processor_id());
}
#endif
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index c092115..616268c 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -315,6 +315,7 @@ static struct local_timer_ops twd_lt_ops __cpuinitdata = {
static int __init twd_local_timer_common_register(struct device_node *np)
{
int err;
+ struct clock_event_device *evt;
twd_evt = alloc_percpu(struct clock_event_device *);
if (!twd_evt) {
@@ -328,8 +329,8 @@ static int __init twd_local_timer_common_register(struct
device_node *np)
goto out_free;
}
- err = local_timer_register(&twd_lt_ops);
- if (err)
+ evt = local_timer_register(&twd_lt_ops);
+ if (IS_ERR(evt))
goto out_irq;
twd_get_clock(np);
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/8] ARM: AM43 (OMAP2+) boot support
Hi, This series adds minimal support to boot Linux on platforms having AM43 based SoC's. This is being sent as an RFC to seek opinion about modification in twd to register percpu local timer clock event for scheduler tick in the case of one core SMP. AM43 SoC's are based on ARM Cortex-A9. It is an ARM Cortex-A9 SMP configuration with one core (not uniprocessor configuration). AM43 is similar to AM335x in it's peripheral capabilities, with many of the peripheral register mapping's similar like that of uart. AM43 is in pre-silicon stage and currently there are no public documents. This series has been tested on a pre-silicon platform that emulates AM43 SoC, changes proposed here are minimal - to get it booting. Kernel was directly run without the help of bootloader - Images were directly loaded onto a pre-initialized RAM and ARM registers updated as required for booting. Changes have been made over linux-next (next-20130213) with three "OF" related reverts (which otherwise causes problem in other platforms also) and compiled with omap2plus_defconfig. Multiplatform option was enabled, while most of CONFIG options were deselected for a faster boot. Beagle bone boots as earlier with these changes. An interesting observation is that it may be possible to boot this platform to console without any platform specific modification to proper Kernel (by that I mean excluding DT sources) using Arnd's, "[PATCH,RFC] default machine descriptor for multiplatform", along with a "CLOCKSOURCE_OF_DECLARE" for smp twd. But later on to make SoC do any really useful work or to get done things that the SoC is meant to do, platform changes like omap-hwmod, handling power management, clock tree, detecting SoC capabilities etc would have to be made, necessitating DT_MACHINE_START at least in the foreseeable future. Patch - 8 that makes AM43 boot on pre-silicon platform would be replaced later by a one for original board. Last but not least, thanks to Ankur Kishore (who first made Linux to boot on AM43) for all the help that made Linux bringup easier. Regards Afzal Afzal Mohammed (8): ARM: localtimer: return percpu clkevt on register ARM: twd: register clock event for 1 core SMP ARM: twd: clock rate from DT (if no DT clk tree) ARM: am33xx: ll debug config help ARM: OMAP2+: am43: Kconfig ARM: OMAP2+: am43: basic dt support ARM: dts: am4372: initial support ARM: dts: am43-pre-silicon support Documentation/devicetree/bindings/arm/twd.txt | 7 +++- arch/arm/Kconfig.debug| 3 ++ arch/arm/boot/dts/Makefile| 3 +- arch/arm/boot/dts/am43-pre-silicon.dts| 31 +++ arch/arm/boot/dts/am4372.dtsi | 55 +++ arch/arm/include/asm/localtimer.h | 7 ++-- arch/arm/kernel/smp.c | 8 ++-- arch/arm/kernel/smp_twd.c | 16 +++- arch/arm/mach-omap2/Kconfig | 11 ++ arch/arm/mach-omap2/board-generic.c | 18 + 10 files changed, 148 insertions(+), 11 deletions(-) create mode 100644 arch/arm/boot/dts/am43-pre-silicon.dts create mode 100644 arch/arm/boot/dts/am4372.dtsi -- 1.7.12 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC/RFT PATCH 2/2] SERIAL: OMAP: Remove the idle handling from the driver
Hi, On Fri, Feb 15, 2013 at 19:13:42, Shilimkar, Santosh wrote: > On Friday 15 February 2013 07:04 PM, Felipe Balbi wrote: > > Hi, > > > > On Fri, Feb 15, 2013 at 06:49:20PM +0530, Santosh Shilimkar wrote: > @@ -279,8 +259,6 @@ static void serial_omap_stop_tx(struct uart_port > *port) > serial_out(up, UART_IER, up->ier); > } > > -serial_omap_set_forceidle(up); > - > pm_runtime_mark_last_busy(up->dev); > pm_runtime_put_autosuspend(up->dev); > } > @@ -348,7 +326,6 @@ static void serial_omap_start_tx(struct uart_port > *port) > > pm_runtime_get_sync(up->dev); > serial_omap_enable_ier_thri(up); > -serial_omap_set_noidle(up); > >>> > >>> this patch is changing behavior. Currently driver has: > >>> > >>> start_tx() > >>> get_sync() > >>> set_noidle() > >>> put_autosuspend() > >>> > >>> > >>> > >>> stop_tx() > >>> get_sync() > >>> set_force_idle() > >>> put_autosuspend() > >>> > >>> with this change, you will have: > >>> > >>> start_tx() > >>> get_sync() > >>> set_noidle() > >>> put_autosuspend() > >>> set_force_idle() > >>> > >>> this in itself might be enough to go back to corrupted serial if > >>> put_autosuspend is so quick that set_force_idle() is called before all > >>> data has been shifted out of FIFO and through the UART lines. > >>> > >> Really. Infact the old sequence was buggy because you are setting > >> force_idle even before suspending the device. And that force idle > > > > then that bug has to be fixed first and patch needs to be sent to stable > > before we change that part of the code, wouldn't you agree ? > > > Agree. Will be good to get that fixed for stable. Probably Sourabh > can fix that one. > > >> isn't really force idle but setting ip to smart idle. Just look at > >> what serial.c > > > > indeed. > > > >>> Before doing this, you should at least test that removing > >>> pm_runtime_mark_last_busy() and pm_runtime_put_autosuspend() from > >>> start_tx() and removing pm_runtime_get_sync() from stop_tx() works fine. > >>> > >> Seems to work for me with above changes as well. Can you please > >> try out and see if you see any issue. I doubt you will... > > > > what I'm saying is that current code, as you put it yourself, is buggy, > > so we ought to fix the bugs first before changing behavior. If not for > > anything else, at least to have a clean tree which we can bisect. > > > >>> Also, $SUBJECT isn't improving the situation regarding UART Wakeup, > >>> there is still the regression of UART never being wakeup capable. > >>> > >> You are mixing the stuff here. The subject is correct. > > > > ->enable_wakeup() sets the IP to smart_idle_wakeup, which is done on > > SYSC register. If $SUBJECT wants to fix SYSC usage, it ought to fix them > > all. > > > But SYSC is already in smart_idle_wakeup() mode. I get your point > though. The main purpose of that wakeup hook is to trigger io_ring > and pad wakeup. > > BTW, Rajendra is looking at how to get rid of wakeup function pointer > as well since that also comes in way for DT. > With these changes the async wakeup mechanism for UART which depends on SIDLE bits being set to 0x3 and ENWAKEUP being set to 0x1 breaks. I noticed this while testing these changes on top of the AM335x suspend-resume support. How about leveraging the generic wakeup flag for all devices to get the required functionality for wakeup? A call to device_init_wakeup() in probe, followed by a check for device_may_wakeup() in the driver's suspend routine can be used to have omap_device_idle_hwmods() configure the SIDLE bits appropriately. This should help configure SIDLE to FORCE/NO_IDLE during active mode along with the appropriate SYSC configuration during suspend. The device_may_wakeup() check could even be used to enable IO Daisy chaining feature for the IOs. Regards, Vaibhav -- 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] ADP1653 board code for Nokia RX-51
Hi,
On Sun, Feb 17, 2013 at 04:16:49PM +0100, Pali Rohár wrote:
> I'm sending ADP1653 flash torch board code for Nokia RX-51. Kernel
> driver ADP1653 is already in upstream kernel. Board code was extracted
> from this big camera meego patch:
>
> https://api.pub.meego.com/public/source/CE:Adaptation:N900/kernel-adaptation-n900/linux-2.6-Camera-for-Meego-N900-Adaptation-kernel-2.6.37-patch.patch
You need to sign-off the patch.
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-rx51-camera.c
I'm not sure if adding a new file is sensible. There are already 3 board
files for RX-51, which I think is overkill.
> @@ -0,0 +1,177 @@
> +/*
> + * arch/arm/mach-omap2/board-rx51-camera.c
> + *
> + * Copyright (C) 2008 Nokia Corporation
> + *
> + * Contact: Sakari Ailus
> + * Tuukka Toivonen
You should put these people to CC... Just to see if the addresses are
still valid (which I doubt).
> +static int __init rx51_adp1653_init(void)
> +{
> + int err;
> +
> + err = gpio_request(ADP1653_GPIO_ENABLE, "adp1653 enable");
> + if (err) {
> + printk(KERN_ERR ADP1653_NAME
> +" Failed to request EN gpio\n");
> + err = -ENODEV;
> + goto err_omap_request_gpio;
> + }
> +
> + err = gpio_request(ADP1653_GPIO_INT, "adp1653 interrupt");
> + if (err) {
> + printk(KERN_ERR ADP1653_NAME " Failed to request IRQ gpio\n");
> + err = -ENODEV;
> + goto err_omap_request_gpio_2;
> + }
> +
> + err = gpio_request(ADP1653_GPIO_STROBE, "adp1653 strobe");
> + if (err) {
> + printk(KERN_ERR ADP1653_NAME
> +" Failed to request STROBE gpio\n");
> + err = -ENODEV;
> + goto err_omap_request_gpio_3;
> + }
> +
> + gpio_direction_output(ADP1653_GPIO_ENABLE, 0);
> + gpio_direction_input(ADP1653_GPIO_INT);
> + gpio_direction_output(ADP1653_GPIO_STROBE, 0);
gpio_request_array() should be used.
> +void __init rx51_camera_init(void)
> +{
> + if (rx51_camera_hw_init()) {
> + printk(KERN_WARNING "%s: Unable to initialize camera\n",
> +__func__);
> + return;
> + }
> +
> + if (omap3_init_camera(&rx51_isp_platform_data) < 0)
> + printk(KERN_WARNING "%s: Unable to register camera platform "
> +"device\n", __func__);
pr_warn() should be used.
A.
--
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] ADP1653 board code for Nokia RX-51
Hello,
I'm sending ADP1653 flash torch board code for Nokia RX-51. Kernel
driver ADP1653 is already in upstream kernel. Board code was extracted
from this big camera meego patch:
https://api.pub.meego.com/public/source/CE:Adaptation:N900/kernel-adaptation-n900/linux-2.6-Camera-for-Meego-N900-Adaptation-kernel-2.6.37-patch.patch
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index d0374ea..92117a13 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -75,6 +75,7 @@ static struct platform_device leds_gpio = {
*/
extern void __init rx51_peripherals_init(void);
+extern void __init rx51_camera_init(void);
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
@@ -100,6 +101,7 @@ static void __init rx51_init(void)
usb_musb_init(&musb_board_data);
rx51_peripherals_init();
+ rx51_camera_init();
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
diff --git a/arch/arm/mach-omap2/board-rx51-camera.c
b/arch/arm/mach-omap2/board-rx51-camera.c
new file mode 100644
index 000..26b37ea
--- /dev/null
+++ b/arch/arm/mach-omap2/board-rx51-camera.c
@@ -0,0 +1,177 @@
+/*
+ * arch/arm/mach-omap2/board-rx51-camera.c
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ *
+ * Contact: Sakari Ailus
+ * Tuukka Toivonen
+ *
+ * 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 should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include
+#include
+
+#include
+
+#include "../../../drivers/media/platform/omap3isp/isp.h"
+
+#include
+
+#include "devices.h"
+
+#define ADP1653_GPIO_ENABLE88 /* Used for resetting ADP1653 */
+#define ADP1653_GPIO_INT 167 /* Fault interrupt */
+#define ADP1653_GPIO_STROBE126 /* Pin used in cam_strobe mode ->
+* control using ISP drivers */
+
+static int __init rx51_adp1653_init(void)
+{
+ int err;
+
+ err = gpio_request(ADP1653_GPIO_ENABLE, "adp1653 enable");
+ if (err) {
+ printk(KERN_ERR ADP1653_NAME
+ " Failed to request EN gpio\n");
+ err = -ENODEV;
+ goto err_omap_request_gpio;
+ }
+
+ err = gpio_request(ADP1653_GPIO_INT, "adp1653 interrupt");
+ if (err) {
+ printk(KERN_ERR ADP1653_NAME " Failed to request IRQ gpio\n");
+ err = -ENODEV;
+ goto err_omap_request_gpio_2;
+ }
+
+ err = gpio_request(ADP1653_GPIO_STROBE, "adp1653 strobe");
+ if (err) {
+ printk(KERN_ERR ADP1653_NAME
+ " Failed to request STROBE gpio\n");
+ err = -ENODEV;
+ goto err_omap_request_gpio_3;
+ }
+
+ gpio_direction_output(ADP1653_GPIO_ENABLE, 0);
+ gpio_direction_input(ADP1653_GPIO_INT);
+ gpio_direction_output(ADP1653_GPIO_STROBE, 0);
+
+ return 0;
+
+err_omap_request_gpio_3:
+ gpio_free(ADP1653_GPIO_INT);
+
+err_omap_request_gpio_2:
+ gpio_free(ADP1653_GPIO_ENABLE);
+
+err_omap_request_gpio:
+ return err;
+}
+
+static int __init rx51_camera_hw_init(void)
+{
+ int rval;
+
+ rval = rx51_adp1653_init();
+ if (rval)
+ return rval;
+
+ return 0;
+}
+
+/*
+ *
+ * ADP1653
+ *
+ */
+
+static int rx51_adp1653_power(struct v4l2_subdev *subdev, int on)
+{
+ gpio_set_value(ADP1653_GPIO_ENABLE, on);
+ if (on) {
+ /* Some delay is apparently required. */
+ udelay(20);
+ }
+
+ return 0;
+}
+
+static struct adp1653_platform_data rx51_adp1653_platform_data = {
+ .power = rx51_adp1653_power,
+ /* Must be limited to 500 ms in RX-51 */
+ .max_flash_timeout = 50, /* us */
+ /* Must be limited to 320 mA in RX-51 B3 and newer hardware */
+ .max_flash_intensity = ADP1653_FLASH_INTENSITY_REG_TO_mA(19),
+ /* Must be limited to 50 mA in RX-51 */
+ .max_torch_intensity = ADP1653_FLASH_INTENSITY_REG_TO_mA(1),
+ .max_indicator_intensity = ADP1653_INDICATOR_INTENSITY_REG_TO_uA(
+ ADP1653_REG_OUT_SEL_ILED_MAX),
+};
+
+/*
+ *
+ * Init it all
+ *
+ */
+
+#define ADP1653_I2C_BUS_NUM2
+
+static struct i2c_board_info rx51_camera_i2c_devices[] = {
+ {
+
Re: [PATCH v2 1/1] OMAP4: DSS: Add panel for Blaze Tablet boards
> >> + char name[30];
> >> + char buf[50];
> >> +
> >> + if (size >= sizeof(buf))
> >> + size = sizeof(buf);
> >
> > what's the point of this?
>
> This is a way to limit copied from userspace data by available buffer size,
> widely used in current kernel sources. Are you implying there is some
> better (more graceful) way?
No indeed :)
There is no other way, sorry for polluting the review :)
> >> + if ((pins[2] & 1) || (pins[3] & 1)) {
> >> + lanes |= (1 << 1);
> >> + ret |= tc358765_write_register(dssdev, PPI_D0S_CLRSIPOCOUNT,
> >> + board_data->clrsipo);
> >> + }
> >> + if ((pins[4] & 1) || (pins[5] & 1)) {
> >> + lanes |= (1 << 2);
> >> + ret |= tc358765_write_register(dssdev, PPI_D1S_CLRSIPOCOUNT,
> >> + board_data->clrsipo);
> >> + }
> >> + if ((pins[6] & 1) || (pins[7] & 1)) {
> >> + lanes |= (1 << 3);
> >> + ret |= tc358765_write_register(dssdev, PPI_D2S_CLRSIPOCOUNT,
> >> + board_data->clrsipo);
> >> + }
> >> + if ((pins[8] & 1) || (pins[9] & 1)) {
> >> + lanes |= (1 << 4);
> >> + ret |= tc358765_write_register(dssdev, PPI_D3S_CLRSIPOCOUNT,
> >> + board_data->clrsipo);
> >> + }
> >
> > Can't this be done in one single multiwrighting command since
> > this registers are consecutive?
> >
> > You build once the array to write and you send it at once.
>
> In this particular case I disagree. Yes, it will be a little bit
> faster, however:
> 1) we write this for panel initialization only (so no impact in other cases)
> 2) multiwriting of array will make code reading more difficult
>
> So I would like to leave it as-is
> Same is for next your similar comment.
If the hw is providing us some ways for simplifying the code I
would use it. In this case we are talking about the i2c feature
of multiwriting and multireading.
Let's assume that we want to write on 8 different consecutive
registers. In my opinion this aproach is quite "heavy":
uX register;
register = value1;
i2c_write(REG1, register);
register = value2;
i2c_write(REG2, register);
...
Usually what I do is this:
uX register[8];
for (i = 0; i < 8; i++)
register |= valuei << i; (or register[i] = valuei or whatever)
i2c_multi_write(REG, register, 8);
of course this is a simplified example in pseudocode. I think
it's more readable and we are making a better use of the i2c
protocol.
In your case you have some if statement that are making the multi
writing more difficult, but still is not impossible.
At the end it's still a matter of taste, so that you are free to
choose whatever you prefer :)
Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly
On 2/16/2013 1:35 AM, David Miller wrote: Also please indicate, clearly, what tree your patch is targetted at. Sorry for not mentioning the tree, will mention in the future patches. Regards Mugunthan V N -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly
On 2/16/2013 1:35 AM, David Miller wrote:
From: Mugunthan V N
Date: Thu, 14 Feb 2013 23:56:46 +0530
+enum {
+ CPDMA_EOI_RX_THRESH = 0,
+ CPDMA_EOI_RX,
+ CPDMA_EOI_TX,
+ CPDMA_EOI_MISC,
+};
Do not use enumerations for hardware register values, which must be
exact, otherwise you are potentially going to succumb to the vagaries
of C language enumeration value assignment.
Will change enum to define and submit next version patch.
Regards
Mugunthan V N
--
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
