Re: [PATCH v3 05/10] v4l: Add support for ov5640 sensor
Hi Jean-Philippe,
On Mon, May 7, 2012 at 2:27 AM, jean-philippe francois
jp.franc...@cynove.com wrote:
2012/5/2 Sergio Aguirre saagui...@ti.com:
This adds a very limited driver for ov5640, which
only supports:
- 2592x1944 @ ~7.5 fps
- 1920x1080 @ ~15 fps,
- 1280x720 @ ~24 fps,
- 640x480 @ ~24 fps,
- 320x240 @ ~24 fps,
All in YUV422i format, using 1 CSI2 datalane @ 333 MHz.
There is already a limited driver in mainline for ov5642.
How does the 5642 differ from 5640 ?
Well, it has several differences, see:
- OV5640 product brief:
http://www.ovt.com/download_document.php?type=sensorsensorid=93
- OV5642 product brief:
http://www.ovt.com/download_document.php?type=sensorsensorid=65
Some of the most notable differences are:
- OV5642 has a MIPI input, for using OV ISP with an external sensor.
- OV5640 has JPEG compression, OV5642 apparently not...
- OV5640 supports anti-shake, OV5640 apparently not...
Can a single driver handle both chip ?
Maybe, yeah..
Now, for the OV5640 differences above, I'm not enabling much nice
features so far,
so it might be worth a try to attempt the ov5642 driver on my OV5640
as-is, to see
if we can expand it to support both.
I'll also see if I can reach people at OmniVision to consult
feasibility of register settings
sharing.
Regards,
Sergio
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/Kconfig | 6 +
drivers/media/video/Makefile | 1 +
drivers/media/video/ov5640.c | 948
++
include/media/ov5640.h | 10 +
4 files changed, 965 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/ov5640.c
create mode 100644 include/media/ov5640.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 4482ac4..cc76652 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -480,6 +480,12 @@ config VIDEO_OV7670
OV7670 VGA camera. It currently only works with the M88ALP01
controller.
+config VIDEO_OV5640
+ tristate OmniVision OV5640 sensor support
+ depends on I2C VIDEO_V4L2
+ help
+ This is a ov5640 camera driver
+
config VIDEO_VS6624
tristate ST VS6624 sensor support
depends on VIDEO_V4L2 I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index c95cc0d..da40ab3 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_CX25840) += cx25840/
obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
+obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
diff --git a/drivers/media/video/ov5640.c b/drivers/media/video/ov5640.c
new file mode 100644
index 000..2a64d50
--- /dev/null
+++ b/drivers/media/video/ov5640.c
@@ -0,0 +1,948 @@
+/*
+ * OmniVision OV5640 sensor driver
+ *
+ * Copyright (C) 2011 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 as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/videodev2.h
+#include linux/slab.h
+#include linux/i2c.h
+#include linux/log2.h
+#include linux/delay.h
+#include linux/module.h
+
+#include media/v4l2-device.h
+#include media/v4l2-subdev.h
+#include media/v4l2-ctrls.h
+
+#include media/ov5640.h
+
+/* OV5640 has only one fixed colorspace per pixelcode */
+struct ov5640_datafmt {
+ enum v4l2_mbus_pixelcode code;
+ enum v4l2_colorspace colorspace;
+};
+
+struct ov5640_timing_cfg {
+ u16 x_addr_start;
+ u16 y_addr_start;
+ u16 x_addr_end;
+ u16 y_addr_end;
+ u16 h_output_size;
+ u16 v_output_size;
+ u16 h_total_size;
+ u16 v_total_size;
+ u16 isp_h_offset;
+ u16 isp_v_offset;
+ u8 h_odd_ss_inc;
+ u8 h_even_ss_inc;
+ u8 v_odd_ss_inc;
+ u8 v_even_ss_inc;
+};
+
+enum ov5640_size {
+ OV5640_SIZE_QVGA,
+ OV5640_SIZE_VGA,
+ OV5640_SIZE_720P,
+ OV5640_SIZE_1080P,
+ OV5640_SIZE_5MP,
+ OV5640_SIZE_LAST,
+};
+
+static const struct v4l2_frmsize_discrete ov5640_frmsizes[OV5640_SIZE_LAST]
= {
+ { 320, 240 },
+ { 640, 480 },
+ { 1280, 720 },
+ { 1920, 1080 },
+ { 2592, 1944 },
+};
+
+/* Find a frame size in an array */
+static int ov5640_find_framesize(u32
Re: [PATCH v3 07/10] arm: omap4430sdp: Add support for omap4iss camera
Hi Sakari,
Thanks for reviewing.
On Wed, May 2, 2012 at 2:47 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
Hi Sergio,
Thanks for the patches!!
On Wed, May 02, 2012 at 10:15:46AM -0500, Sergio Aguirre wrote:
...
+static int sdp4430_ov_cam1_power(struct v4l2_subdev *subdev, int on)
+{
+ struct device *dev = subdev-v4l2_dev-dev;
+ int ret;
+
+ if (on) {
+ if (!regulator_is_enabled(sdp4430_cam2pwr_reg)) {
+ ret = regulator_enable(sdp4430_cam2pwr_reg);
+ if (ret) {
+ dev_err(dev,
+ Error in enabling sensor power
regulator 'cam2pwr'\n);
+ return ret;
+ }
+
+ msleep(50);
+ }
+
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 1);
+ msleep(10);
+ ret = clk_enable(sdp4430_cam1_aux_clk); /* Enable XCLK */
+ if (ret) {
+ dev_err(dev,
+ Error in clk_enable() in %s(%d)\n,
+ __func__, on);
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
+ return ret;
+ }
+ msleep(10);
+ } else {
+ clk_disable(sdp4430_cam1_aux_clk);
+ msleep(1);
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
+ if (regulator_is_enabled(sdp4430_cam2pwr_reg)) {
+ ret = regulator_disable(sdp4430_cam2pwr_reg);
+ if (ret) {
+ dev_err(dev,
+ Error in disabling sensor power
regulator 'cam2pwr'\n);
+ return ret;
+ }
+ }
+ }
+
+ return 0;
+}
Isn't this something that should be part of the sensor driver? There's
nothing in the above code that would be board specific, except the names of
the clocks, regulators and GPIOs. The sensor driver could hold the names
instead; this would be also compatible with the device tree.
Agreed. I see what you mean...
I'll take care of that.
It should be possible to have s_power() callback NULL, too.
+static int sdp4430_ov_cam2_power(struct v4l2_subdev *subdev, int on)
+{
+ struct device *dev = subdev-v4l2_dev-dev;
+ int ret;
+
+ if (on) {
+ u8 gpoctl = 0;
+
+ ret = regulator_enable(sdp4430_cam2pwr_reg);
+ if (ret) {
+ dev_err(dev,
+ Error in enabling sensor power regulator
'cam2pwr'\n);
+ return ret;
+ }
+
+ msleep(50);
+
+ if (twl_i2c_read_u8(TWL_MODULE_AUDIO_VOICE, gpoctl,
+ TWL6040_REG_GPOCTL))
+ return -ENODEV;
+ if (twl_i2c_write_u8(TWL_MODULE_AUDIO_VOICE,
+ gpoctl | TWL6040_GPO3,
+ TWL6040_REG_GPOCTL))
+ return -ENODEV;
The above piece of code looks quite interesting. What does it do?
Well, this is because the camera adapter board in 4430SDP has 3
sensors actually:
- 1 Sony IMX060 12.1 MP sensor
- 2 OmniVision OV5650 sensors
And there's 3 wideband analog switches, like this:
http://www.analog.com/static/imported-files/data_sheets/ADG936_936R.pdf
That basically select either IMX060 or OV5650 for CSI2A input.
So, this commands are because the TWL6040 chip has a GPO pin to toggle
this, instead
of an OMAP GPIO (Don't ask me why :) )
Anyways... I see your point, maybe this should be explained better
through a comment.
Regards,
Sergio
Kind regards,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: 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
Re: [PATCH v3 07/10] arm: omap4430sdp: Add support for omap4iss camera
Hi Sakari,
On Thu, May 3, 2012 at 7:03 AM, Aguirre, Sergio saagui...@ti.com wrote:
Hi Sakari,
Thanks for reviewing.
On Wed, May 2, 2012 at 2:47 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
Hi Sergio,
Thanks for the patches!!
On Wed, May 02, 2012 at 10:15:46AM -0500, Sergio Aguirre wrote:
...
+static int sdp4430_ov_cam1_power(struct v4l2_subdev *subdev, int on)
+{
+ struct device *dev = subdev-v4l2_dev-dev;
+ int ret;
+
+ if (on) {
+ if (!regulator_is_enabled(sdp4430_cam2pwr_reg)) {
+ ret = regulator_enable(sdp4430_cam2pwr_reg);
+ if (ret) {
+ dev_err(dev,
+ Error in enabling sensor power
regulator 'cam2pwr'\n);
+ return ret;
+ }
+
+ msleep(50);
+ }
+
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 1);
+ msleep(10);
+ ret = clk_enable(sdp4430_cam1_aux_clk); /* Enable XCLK */
+ if (ret) {
+ dev_err(dev,
+ Error in clk_enable() in %s(%d)\n,
+ __func__, on);
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
+ return ret;
+ }
+ msleep(10);
+ } else {
+ clk_disable(sdp4430_cam1_aux_clk);
+ msleep(1);
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
+ if (regulator_is_enabled(sdp4430_cam2pwr_reg)) {
+ ret = regulator_disable(sdp4430_cam2pwr_reg);
+ if (ret) {
+ dev_err(dev,
+ Error in disabling sensor power
regulator 'cam2pwr'\n);
+ return ret;
+ }
+ }
+ }
+
+ return 0;
+}
Isn't this something that should be part of the sensor driver? There's
nothing in the above code that would be board specific, except the names of
the clocks, regulators and GPIOs. The sensor driver could hold the names
instead; this would be also compatible with the device tree.
Agreed. I see what you mean...
I'll take care of that.
Can you please check out these patches?
1.
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/cb6c10d58053180364461e6bc8d30d1ec87e6e22
2.
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/6732e0db25c6647b34ef8f01c244a49a1fd6b45d
3.
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/d61c4e3142dc9cae972f9128fe73d986838c0ca1
4.
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/e83f36001c7f7cbe184ad094d9b0c95c39e5028f
I want to see if I got your point properly...
Regards,
Sergio
It should be possible to have s_power() callback NULL, too.
+static int sdp4430_ov_cam2_power(struct v4l2_subdev *subdev, int on)
+{
+ struct device *dev = subdev-v4l2_dev-dev;
+ int ret;
+
+ if (on) {
+ u8 gpoctl = 0;
+
+ ret = regulator_enable(sdp4430_cam2pwr_reg);
+ if (ret) {
+ dev_err(dev,
+ Error in enabling sensor power regulator
'cam2pwr'\n);
+ return ret;
+ }
+
+ msleep(50);
+
+ if (twl_i2c_read_u8(TWL_MODULE_AUDIO_VOICE, gpoctl,
+ TWL6040_REG_GPOCTL))
+ return -ENODEV;
+ if (twl_i2c_write_u8(TWL_MODULE_AUDIO_VOICE,
+ gpoctl | TWL6040_GPO3,
+ TWL6040_REG_GPOCTL))
+ return -ENODEV;
The above piece of code looks quite interesting. What does it do?
Well, this is because the camera adapter board in 4430SDP has 3
sensors actually:
- 1 Sony IMX060 12.1 MP sensor
- 2 OmniVision OV5650 sensors
And there's 3 wideband analog switches, like this:
http://www.analog.com/static/imported-files/data_sheets/ADG936_936R.pdf
That basically select either IMX060 or OV5650 for CSI2A input.
So, this commands are because the TWL6040 chip has a GPO pin to toggle
this, instead
of an OMAP GPIO (Don't ask me why :) )
Anyways... I see your point, maybe this should be explained better
through a comment.
Regards,
Sergio
Kind regards,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: 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
Re: [PATCH v3 00/10] v4l2: OMAP4 ISS driver + Sensor + Board support
On Wed, May 2, 2012 at 10:15 AM, Sergio Aguirre saagui...@ti.com wrote: Hi everyone, It's been a long time since last version (5 months)! :) This is the third version of the OMAP4 ISS driver, which uses Media Controller and videobuf2 frameworks. This patchset should apply cleanly on top of v3.4-rc5 kernel tag. This driver attempts to provide an fully open source solution to control the OMAP4 Imaging SubSystem (a.k.a. ISS). Starts with just CSI2-A/B interface support, and pretends to be ready for expansion to add support to the many ISS block modules as possible. Please see newly added documentation for more details: Documentation/video4linux/omap4_camera.txt Any comments/complaints are welcome. :) Apologies, forgot to mention this: Tested with these patchsets: - Sakari's patches for N9 and some v4l2 changes: http://www.spinics.net/lists/linux-media/msg45052.html - CMA v24: http://www.spinics.net/lists/linux-media/msg46106.html Both rebased to v3.4-rc5. Regards, Sergio Changes since v2: - Supports CSI2B now! - Add support for RAW8. - Usage of V4L2_CID_PIXEL_RATE, instead of dphy configuration in boardfile (similar to omap3isp) - Removes save/restore support for now, as it is broken. - Attend several comments form Sakari Ailus (Thanks Sakari!) - Populate hw_revision in media_dev struct. - Ported several fixes pushed for omap3isp (Thanks Laurent!) - Use module_platform_driver. - Use proposed generic v4l2_subdev_link_validate. - Move OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_CAMERA_RX handle to omap4iss code, instead of board file. Changes since v1: - Simplification of auxclk handlign in board files - Use of HWMOD declaration for assisted platform_device creation. - Videobuf2 migration (Removal of custom iss_queue buffer handling driver) Regards, Sergio Sergio Aguirre (10): mfd: twl6040: Fix wrong TWL6040_GPO3 bitfield value OMAP4: hwmod: Include CSI2A/B and CSIPHY1/2 memory sections OMAP4: Add base addresses for ISS v4l: Add support for omap4iss driver v4l: Add support for ov5640 sensor v4l: Add support for ov5650 sensor arm: omap4430sdp: Add support for omap4iss camera arm: omap4panda: Add support for omap4iss camera omap2plus: Add support for omap4iss camera arm: Add support for CMA for omap4iss driver Documentation/video4linux/omap4_camera.txt | 64 ++ arch/arm/configs/omap2plus_defconfig | 2 + arch/arm/mach-omap2/Kconfig | 32 + arch/arm/mach-omap2/Makefile | 3 + arch/arm/mach-omap2/board-4430sdp-camera.c | 415 arch/arm/mach-omap2/board-4430sdp.c | 20 + arch/arm/mach-omap2/board-omap4panda-camera.c | 209 arch/arm/mach-omap2/devices.c | 40 + arch/arm/mach-omap2/devices.h | 4 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 22 +- drivers/media/video/Kconfig | 25 + drivers/media/video/Makefile | 3 + drivers/media/video/omap4iss/Makefile | 6 + drivers/media/video/omap4iss/iss.c | 1159 + drivers/media/video/omap4iss/iss.h | 121 +++ drivers/media/video/omap4iss/iss_csi2.c | 1368 + drivers/media/video/omap4iss/iss_csi2.h | 155 +++ drivers/media/video/omap4iss/iss_csiphy.c | 281 + drivers/media/video/omap4iss/iss_csiphy.h | 51 + drivers/media/video/omap4iss/iss_regs.h | 244 + drivers/media/video/omap4iss/iss_video.c | 1123 drivers/media/video/omap4iss/iss_video.h | 201 drivers/media/video/ov5640.c | 948 + drivers/media/video/ov5650.c | 733 + include/linux/mfd/twl6040.h | 2 +- include/media/omap4iss.h | 65 ++ include/media/ov5640.h | 10 + include/media/ov5650.h | 10 + 28 files changed, 7314 insertions(+), 2 deletions(-) create mode 100644 Documentation/video4linux/omap4_camera.txt create mode 100644 arch/arm/mach-omap2/board-4430sdp-camera.c create mode 100644 arch/arm/mach-omap2/board-omap4panda-camera.c create mode 100644 drivers/media/video/omap4iss/Makefile create mode 100644 drivers/media/video/omap4iss/iss.c create mode 100644 drivers/media/video/omap4iss/iss.h create mode 100644 drivers/media/video/omap4iss/iss_csi2.c create mode 100644 drivers/media/video/omap4iss/iss_csi2.h create mode 100644 drivers/media/video/omap4iss/iss_csiphy.c create mode 100644 drivers/media/video/omap4iss/iss_csiphy.h create mode 100644 drivers/media/video/omap4iss/iss_regs.h create mode 100644 drivers/media/video/omap4iss/iss_video.c create mode 100644 drivers/media/video/omap4iss/iss_video.h create mode 100644 drivers/media/video/ov5640.c create mode 100644 drivers/media/video/ov5650.c create mode
Re: [PATCH v2 06/11] v4l: Add support for omap4iss driver
Hi Sakari,
On Thu, Jan 26, 2012 at 3:05 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
Hi Sergio,
Aguirre, Sergio wrote:
On Wed, Nov 30, 2011 at 06:14:55PM -0600, Sergio Aguirre wrote:
...
+/*
+ * iss_save_ctx - Saves ISS context.
+ * @iss: OMAP4 ISS device
+ *
+ * Routine for saving the context of each module in the ISS.
+ */
+static void iss_save_ctx(struct iss_device *iss)
+{
+ iss_save_context(iss, iss_reg_list);
+}
Do you really, really need to save context related data? Couldn't you
initialise the device the usual way when e.g. returning from suspended
state?
I'll actually have to revisit this more carefuly. I haven't really
tested Runtime PM on this.
I think I'll remove this for now, until i come up with something better.
Usually it's best to recreate the configuration the same way the driver did
it in the first place. Some registers have side effects so that restoring
them requires extra care.
+/*
+ * iss_restore_ctx - Restores ISS context.
+ * @iss: OMAP4 ISS device
+ *
+ * Routine for restoring the context of each module in the ISS.
+ */
+static void iss_restore_ctx(struct iss_device *iss)
+{
+ iss_restore_context(iss, iss_reg_list);
+}
+
...
+/*
+ * csi2_irq_ctx_set - Enables CSI2 Context IRQs.
+ * @enable: Enable/disable CSI2 Context interrupts
+ */
+static void csi2_irq_ctx_set(struct iss_csi2_device *csi2, int enable)
+{
+ u32 reg = CSI2_CTX_IRQ_FE;
+ int i;
+
+ if (csi2-use_fs_irq)
+ reg |= CSI2_CTX_IRQ_FS;
+
+ for (i = 0; i 8; i++) {
8 == number of contexts?
Yes. This loops from 0 to 7.
Are you implying that I need to add a define to this?
I think something that tells it is the number of contexts would be nicer.
...
+ writel(readl(csi2-regs1 + CSI2_SYSCONFIG) |
+ CSI2_SYSCONFIG_SOFT_RESET,
+ csi2-regs1 + CSI2_SYSCONFIG);
+
+ do {
+ reg = readl(csi2-regs1 + CSI2_SYSSTATUS)
+ CSI2_SYSSTATUS_RESET_DONE;
+ if (reg == CSI2_SYSSTATUS_RESET_DONE)
+ break;
+ soft_reset_retries++;
+ if (soft_reset_retries 5)
+ udelay(100);
How about usleep_range() here? Or omit such a long busyloop. Hardware
typically resets quite fast.
I guess i'll try to fine-tune this then.
I think it's fine to replace it with usleep_range() for now. Fine
optimisations can be left for later if really needed.
...
+static void csi2_print_status(struct iss_csi2_device *csi2)
+{
+ struct iss_device *iss = csi2-iss;
+
+ if (!csi2-available)
+ return;
+
+ dev_dbg(iss-dev, -CSI2 Register
dump-\n);
+
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, SYSCONFIG);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, SYSSTATUS);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, IRQENABLE);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, IRQSTATUS);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, CTRL);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, DBG_H);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, COMPLEXIO_CFG);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, COMPLEXIO_IRQSTATUS);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, SHORT_PACKET);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, COMPLEXIO_IRQENABLE);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, DBG_P);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, TIMING);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_CTRL1(0));
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_CTRL2(0));
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_DAT_OFST(0));
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_PING_ADDR(0));
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_PONG_ADDR(0));
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_IRQENABLE(0));
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_IRQSTATUS(0));
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_CTRL3(0));
+
+ dev_dbg(iss-dev,
\n);
_If_ this is user-triggered, you might want to consider using debugfs for
the same. Just FYI.
Ok. I'll see what can I do.
Just FYI. :-) Thinking about this agian, debugfs might not go well with this
since the prints may be triggered by the driver.
...
+ /* Skip interrupts until we reach the frame skip count. The CSI2
will be
+ * automatically disabled, as the frame skip count has been
programmed
+ * in the CSI2_CTx_CTRL1::COUNT field, so reenable it.
+ *
+ * It would have been nice to rely on the FRAME_NUMBER interrupt
instead
+ * but it turned out that the interrupt is only generated when the
CSI2
+ * writes to memory (the CSI2_CTx_CTRL1::COUNT field is decreased
+ * correctly and reaches 0 when data is forwarded to the video
port only
+ * but no interrupt arrives). Maybe a CSI2 hardware bug.
+ */
+ if (csi2-frame_skip) {
+ csi2-frame_skip--;
+ if (csi2
Re: [PATCH] omap2+: add drm device
Hi Rob,
Minor nitpicks.
On Fri, Jan 13, 2012 at 1:41 PM, Rob Clark rob.cl...@linaro.org wrote:
From: Rob Clark r...@ti.com
Register OMAP DRM/KMS platform device, and reserve a CMA region for
the device to use for buffer allocation.
Signed-off-by: Rob Clark r...@ti.com
---
arch/arm/plat-omap/Makefile | 2 +-
arch/arm/plat-omap/common.c | 2 +
arch/arm/plat-omap/drm.c | 88
+++
arch/arm/plat-omap/drm.h | 37 ++
4 files changed, 128 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/plat-omap/drm.c
create mode 100644 arch/arm/plat-omap/drm.h
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 9a58461..b86e6cb 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -4,7 +4,7 @@
# Common support
obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
- usb.o fb.o counter_32k.o
+ usb.o fb.o counter_32k.o drm.o
obj-m :=
obj-n :=
obj- :=
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 06383b5..caf6082 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -24,6 +24,7 @@
#include plat/omap-secure.h
+#include drm.h
#define NO_LENGTH_CHECK 0x
@@ -65,6 +66,7 @@ const void *__init omap_get_var_config(u16 tag, size_t *len)
void __init omap_reserve(void)
{
+ omapdrm_reserve_vram();
omapfb_reserve_sdram_memblock();
omap_vram_reserve_sdram_memblock();
omap_dsp_reserve_sdram_memblock();
diff --git a/arch/arm/plat-omap/drm.c b/arch/arm/plat-omap/drm.c
new file mode 100644
index 000..5d8588f
--- /dev/null
+++ b/arch/arm/plat-omap/drm.c
@@ -0,0 +1,88 @@
+/*
+ * File: arch/arm/plat-omap/drm.c
I believe keeping a file path is frowned upon.
+ *
+ * DRM/KMS device registration for TI OMAP platforms
+ *
+ * Copyright (C) 2011 Texas Instruments
Happy new year! (2012?) :)
+ * Author: Rob Clark rob.cl...@linaro.org
+ *
+ * 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, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/dma-mapping.h
+#ifdef CONFIG_CMA
+# include linux/dma-contiguous.h
+#endif
+
+#include plat/omap_device.h
+#include plat/omap_hwmod.h
+
+#include drm.h
+
+/* files from staging that contain platform data structure definitions */
+#include ../../../drivers/staging/omapdrm/omap_priv.h
+#include ../../../drivers/staging/omapdrm/omap_dmm_tiler.h
+
+#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
+
+static struct omap_drm_platform_data omapdrm_platdata;
+static struct omap_dmm_platform_data dmm_platdata;
+
+static struct platform_device omap_drm_device = {
+ .dev = {
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = omapdrm_platdata,
+ },
+ .name = omapdrm,
+ .id = 0,
+};
+
+static int __init omap_init_gpu(void)
+{
+ struct omap_hwmod *oh = NULL;
+
+ /* lookup and populate the DMM information, if present - OMAP4+ */
+ oh = omap_hwmod_lookup(dmm);
+
+ if (oh) {
+ dmm_platdata.base = omap_hwmod_get_mpu_rt_va(oh);
+ dmm_platdata.irq = oh-mpu_irqs[0].irq;
+
+ if (dmm_platdata.base)
+ omapdrm_platdata.dmm_pdata = dmm_platdata;
+ }
+
+ return platform_device_register(omap_drm_device);
+}
+
+arch_initcall(omap_init_gpu);
+
+void omapdrm_reserve_vram(void)
+{
+#ifdef CONFIG_CMA
+ /* Create private 32MiB contiguous memory area for omapdrm.0 device
+ * TODO revisit size.. if uc/wc buffers are allocated from CMA pages
+ * then the amount of memory we need goes up..
+ */
+ dma_declare_contiguous(omap_drm_device.dev, 32*SZ_1M, 0, 0);
+#else
+# warning CMA is not enabled, there may be limitations about scanout
buffer allocations on OMAP3 and earlier
+#endif
+}
+
+#endif
diff --git a/arch/arm/plat-omap/drm.h b/arch/arm/plat-omap/drm.h
new file mode 100644
index 000..56e0c0e
--- /dev/null
+++ b/arch/arm/plat-omap/drm.h
@@ -0,0 +1,37 @@
+/*
+ * File: arch/arm/plat-omap/drm.c
Again here. (The path is incorrect anyways)
+ *
+ * DRM/KMS device registration
Re: [PATCH 1/1] omap3: add definition for CONTROL_CAMERA_PHY_CTRL
Hi Sakari, On Wed, Jan 11, 2012 at 5:03 PM, Sakari Ailus sakari.ai...@iki.fi wrote: Hi Paul, On Wed, Jan 11, 2012 at 07:11:58AM -0700, Paul Walmsley wrote: On Sun, 8 Jan 2012, Sakari Ailus wrote: Hi Tony and Paul, On Wed, Dec 14, 2011 at 05:14:16PM +0200, Sakari Ailus wrote: The register is used to configure the behaviour of the CSI-2 and CCP-2 receivers. This register is available only in OMAP3630. The original patch was submitted by Vimarsh Zutshi. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- arch/arm/mach-omap2/control.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h index d4ef75d..6a26a0d 100644 --- a/arch/arm/mach-omap2/control.h +++ b/arch/arm/mach-omap2/control.h @@ -183,6 +183,7 @@ #define OMAP3630_CONTROL_FUSE_OPP120_VDD1 (OMAP2_CONTROL_GENERAL + 0x0120) #define OMAP3630_CONTROL_FUSE_OPP50_VDD2 (OMAP2_CONTROL_GENERAL + 0x0128) #define OMAP3630_CONTROL_FUSE_OPP100_VDD2 (OMAP2_CONTROL_GENERAL + 0x012C) +#define OMAP3630_CONTROL_CAMERA_PHY_CTRL (OMAP2_CONTROL_GENERAL + 0x02f0) I assume this patch hasn't gone anywhere yet which might be good. While the definition of this register would appear to belong to this file, it is being included from the OMAP 3 ISP driver, which only uses it if it's running on the 3630. The problem is that control.h isn't apparently intended to be included except locally and I didn't find a suitable file under include/mach to put this definition either. Currently this file is being included by the ISP driver with an explicit path. Do you have an insight how this could be handled better? We've been trying to ensure that register accesses to/from a given IP block only occur in a driver for that IP block. So under that principle, any System Control Module accesses should go into a System Control Module driver. Then that SCM driver should export (via EXPORT_SYMBOL) a higher-level interface to whatever code uses it. The idea is that this interface would remain stable no matter what underlying SoC was in use. Only thing is, we don't yet have a SCM driver. Historically, since the SCM is tightly coupled with the underlying SoC, when we've needed to do something like this in the past, we've added code to arch/arm/mach-omap2/control.c. But that's not really workable now. Do you know if this register, or something like it, is present on later OMAPs? Also, which bitfields are you planning to use? I don't believe it exists on other OMAPs --- possibly on 3730 but the CSI-2 receiver is not officially supported on it. The register does not exist on the 3430, at least not under the same name --- a reason for not existing could be that the 3430 only has one CSI-2 receiver. The 4430 doesn't seem to have it either, at least not under that name. In 4430/4460, there's CONTROL_CAMERA_RX (physical address: 0x4A100608), but it's not exactly compatible. There are some similar bit fields, but in different bit offsets: 3630 has these: - [3:2] R_CONTROL_CAMERA1_PHY_CAMMODE - [1:0] R_CONTROL_CAMERA2_PHY_CAMMODE And 4430/4460 has these fields: - [20:19] CAMERARX_CSI22_CAMMODE - [17:16] CAMERARX_CSI21_CAMMODE Both of them used to configure each CSIPHY module, to use it on: - 0x0: D-PHY mode (for CSI-2 cameras) - 0x1: Data/Strobe mode (for CCP2 mode) - 0x2: Data/Clock mode (for either CCP2 or CSI1 mode) - 0x3: Reserved(4430), or GPI/Parallel (4460/3630) mode But other OMAP4 bitfields are completely unexisting on OMAP3 (3630), as there some slight IP changes on the way the Camera CSIPHY is controlled. Regards, Sergio I think the solution to conditionally access it in the ISP driver would be, albeit not pretty, a workable one: the driver is unlikely to be used on other platforms and this is a single register accessed in a single location. I'm of course open for better options. Cc Sergio. -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: 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
Re: [PATCH v2 03/11] v4l: Introduce sensor operation for getting interface configuration
Hi Stan,
On Fri, Dec 2, 2011 at 7:32 AM, Stanimir Varbanov svarba...@mm-sol.com wrote:
Hi, Sergio
This change in interface is not used from the omap4iss driver.
You could drop it from the patch set, if so.
Oops, yes... I used to depend on this for my soc_camera implementation before...
You're absolutely right, i'll remove it in the next iteration.
Merci!
On 12/01/2011 02:14 AM, Sergio Aguirre wrote:
From: Stanimir Varbanov svarba...@mm-sol.com
Introduce g_interface_parms sensor operation for getting sensor
interface parameters. These parameters are needed from the host side
to determine it's own configuration.
Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
---
include/media/v4l2-subdev.h | 42
++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index f0f3358..0d322ed 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -362,6 +362,42 @@ struct v4l2_subdev_vbi_ops {
int (*s_sliced_fmt)(struct v4l2_subdev *sd, struct
v4l2_sliced_vbi_format *fmt);
};
+/* Which interface the sensor use to provide it's image data */
+enum v4l2_subdev_sensor_iface {
+ V4L2_SUBDEV_SENSOR_PARALLEL,
+ V4L2_SUBDEV_SENSOR_SERIAL,
+};
+
+/* Each interface could use the following modes */
+/* Image sensor provides horizontal and vertical sync signals */
+#define V4L2_SUBDEV_SENSOR_MODE_PARALLEL_SYNC 0
+/* BT.656 interface. Embedded sync */
+#define V4L2_SUBDEV_SENSOR_MODE_PARALLEL_ITU 1
+/* MIPI CSI1 */
+#define V4L2_SUBDEV_SENSOR_MODE_SERIAL_CSI1 2
+/* MIPI CSI2 */
+#define V4L2_SUBDEV_SENSOR_MODE_SERIAL_CSI2 3
+
+struct v4l2_subdev_sensor_serial_parms {
+ unsigned char lanes; /* number of lanes used */
+ unsigned char channel; /* virtual channel */
+ unsigned int phy_rate; /* output rate at CSI phy in bps */
+ unsigned int pix_clk; /* pixel clock in Hz */
+};
+
+struct v4l2_subdev_sensor_parallel_parms {
+ unsigned int pix_clk; /* pixel clock in Hz */
+};
+
+struct v4l2_subdev_sensor_interface_parms {
+ enum v4l2_subdev_sensor_iface if_type;
+ unsigned int if_mode;
+ union {
+ struct v4l2_subdev_sensor_serial_parms serial;
+ struct v4l2_subdev_sensor_parallel_parms parallel;
+ } parms;
+};
+
/**
* struct v4l2_subdev_sensor_ops - v4l2-subdev sensor operations
* @g_skip_top_lines: number of lines at the top of the image to be skipped.
@@ -371,10 +407,16 @@ struct v4l2_subdev_vbi_ops {
* @g_skip_frames: number of frames to skip at stream start. This is needed
for
* buggy sensors that generate faulty frames when they are
* turned on.
+ * @g_interface_parms: get sensor interface parameters. The sensor subdev
should
+ * fill this structure with current interface params. These
+ * interface parameters are needed on host side to
configure
+ * it's own hardware receivers.
*/
struct v4l2_subdev_sensor_ops {
int (*g_skip_top_lines)(struct v4l2_subdev *sd, u32 *lines);
int (*g_skip_frames)(struct v4l2_subdev *sd, u32 *frames);
+ int (*g_interface_parms)(struct v4l2_subdev *sd,
+ struct v4l2_subdev_sensor_interface_parms *parms);
};
/*
--
best regards,
Stan
--
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 PATCH v1 2/7] omap4: build fdif omap device from hwmod
Hi Ming,
Thanks for the patches.
On Fri, Dec 2, 2011 at 9:02 AM, Ming Lei ming@canonical.com wrote:
Signed-off-by: Ming Lei ming@canonical.com
---
arch/arm/mach-omap2/devices.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1166bdc..a392af5 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -728,6 +728,38 @@ void __init omap242x_init_mmc(struct
omap_mmc_platform_data **mmc_data)
#endif
+static struct platform_device* __init omap4_init_fdif(void)
+{
+ int id = -1;
You could remove this , as it is being used only once, and never changed.
+ struct platform_device *pd;
+ struct omap_hwmod *oh;
+ const char *dev_name = fdif;
+
+ oh = omap_hwmod_lookup(fdif);
+ if (!oh) {
+ pr_err(Could not look up fdif hwmod\n);
+ return NULL;
+ }
+
+ pd = omap_device_build(dev_name, id, oh, NULL, 0, NULL, 0, 0);
Just do:
pd = omap_device_build(dev_name, -1, oh, NULL, 0, NULL, 0, 0);
+ WARN(IS_ERR(pd), Can't build omap_device for %s.\n,
+ dev_name);
+ return pd;
+}
+
+static void __init omap_init_fdif(void)
+{
+ if (cpu_is_omap44xx()) {
+ struct platform_device *pd;
+
+ pd = omap4_init_fdif();
+ if (!pd)
+ return;
+
+ pm_runtime_enable(pd-dev);
+ }
+}
IMHO, you could reduce 1 level of indentation here, like this:
static void __init omap_init_fdif(void)
{
struct platform_device *pd;
if (!cpu_is_omap44xx())
return;
pd = omap4_init_fdif();
if (!pd)
return;
pm_runtime_enable(pd-dev);
}
Regards,
Sergio
+
/*-*/
#if defined(CONFIG_HDQ_MASTER_OMAP) || defined(CONFIG_HDQ_MASTER_OMAP_MODULE)
@@ -808,6 +840,7 @@ static int __init omap2_init_devices(void)
omap_init_sham();
omap_init_aes();
omap_init_vout();
+ omap_init_fdif();
return 0;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v1 4/7] media: videobuf2: introduce VIDEOBUF2_PAGE memops
Hi Ming,
On Fri, Dec 2, 2011 at 3:12 AM, Ming Lei ming@canonical.com wrote:
DMA contig memory resource is very limited and precious, also
accessing to it from CPU is very slow on some platform.
For some cases(such as the comming face detection driver), DMA Streaming
buffer is enough, so introduce VIDEOBUF2_PAGE to allocate continuous
physical memory but letting video device driver to handle DMA buffer mapping
and unmapping things.
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/media/video/Kconfig | 4 +
drivers/media/video/Makefile | 1 +
drivers/media/video/videobuf2-page.c | 115
++
include/media/videobuf2-page.h | 20 ++
4 files changed, 140 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/videobuf2-page.c
create mode 100644 include/media/videobuf2-page.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 4e8a0c4..5684a00 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -60,6 +60,10 @@ config VIDEOBUF2_VMALLOC
select VIDEOBUF2_MEMOPS
tristate
+config VIDEOBUF2_PAGE
+ select VIDEOBUF2_CORE
+ select VIDEOBUF2_MEMOPS
+ tristate
config VIDEOBUF2_DMA_SG
#depends on HAS_DMA
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index ddeaa6c..bc797f2 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -125,6 +125,7 @@ obj-$(CONFIG_VIDEO_BTCX) += btcx-risc.o
obj-$(CONFIG_VIDEOBUF2_CORE) += videobuf2-core.o
obj-$(CONFIG_VIDEOBUF2_MEMOPS) += videobuf2-memops.o
obj-$(CONFIG_VIDEOBUF2_VMALLOC) += videobuf2-vmalloc.o
+obj-$(CONFIG_VIDEOBUF2_PAGE) += videobuf2-page.o
obj-$(CONFIG_VIDEOBUF2_DMA_CONTIG) += videobuf2-dma-contig.o
obj-$(CONFIG_VIDEOBUF2_DMA_SG) += videobuf2-dma-sg.o
diff --git a/drivers/media/video/videobuf2-page.c
b/drivers/media/video/videobuf2-page.c
new file mode 100644
index 000..b3f003a
--- /dev/null
+++ b/drivers/media/video/videobuf2-page.c
@@ -0,0 +1,115 @@
+/*
+ * videobuf2-page.c - page memory allocator for videobuf2
+ *
+ * Copyright (C) 2011 Canonical Ltd.
+ *
+ * Author: Ming Lei ming@canonical.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/mm.h
+#include linux/slab.h
+
+#include media/videobuf2-core.h
+#include media/videobuf2-memops.h
+
+struct vb2_page_buf {
+ void *vaddr;
+ unsigned long size;
+ atomic_t refcount;
+ struct vb2_vmarea_handler handler;
+};
+
+static void vb2_page_put(void *buf_priv);
+
+static void *vb2_page_alloc(void *alloc_ctx, unsigned long size)
+{
+ struct vb2_page_buf *buf;
+
+ buf = kzalloc(sizeof *buf, GFP_KERNEL);
+ if (!buf)
+ return NULL;
+
+ buf-size = size;
+ buf-vaddr = (void *)__get_free_pages(GFP_KERNEL,
+ get_order(buf-size));
+ buf-handler.refcount = buf-refcount;
+ buf-handler.put = vb2_page_put;
+ buf-handler.arg = buf;
+
+ if (!buf-vaddr) {
+ printk(KERN_ERR page of size %ld failed\n, buf-size);
+ kfree(buf);
+ return NULL;
+ }
+
+ atomic_inc(buf-refcount);
+ printk(KERN_DEBUG Allocated page buffer of size %ld at vaddr=%p\n,
+ buf-size, buf-vaddr);
+
+ return buf;
+}
+
+static void vb2_page_put(void *buf_priv)
+{
+ struct vb2_page_buf *buf = buf_priv;
+
+ if (atomic_dec_and_test(buf-refcount)) {
+ printk(KERN_DEBUG %s: Freeing page mem at vaddr=%p\n,
+ __func__, buf-vaddr);
+ free_pages((unsigned long)buf-vaddr, get_order(buf-size));
+ kfree(buf);
+ }
+}
+
+static void *vb2_page_vaddr(void *buf_priv)
+{
+ struct vb2_page_buf *buf = buf_priv;
+
+ BUG_ON(!buf);
+
+ if (!buf-vaddr) {
+ printk(KERN_ERR Address of an unallocated plane
requested\n);
+ return NULL;
+ }
+
+ return buf-vaddr;
+}
+
+static unsigned int vb2_page_num_users(void *buf_priv)
+{
+ struct vb2_page_buf *buf = buf_priv;
+ return atomic_read(buf-refcount);
+}
+
+static int vb2_page_mmap(void *buf_priv, struct vm_area_struct *vma)
+{
+ struct vb2_page_buf *buf = buf_priv;
+
+ if (!buf) {
+ printk(KERN_ERR No memory to map\n);
+ return -EINVAL;
+ }
+
+ vma-vm_page_prot = vm_get_page_prot(vma-vm_flags);
+ return vb2_mmap_pfn_range(vma, virt_to_phys(buf-vaddr),
Re: [PATCH v2 04/11] OMAP4: hwmod: Include CSI2A and CSIPHY1 memory sections
Hi Kevin,
Thanks for the review.
On Fri, Dec 2, 2011 at 4:49 PM, Kevin Hilman khil...@ti.com wrote:
+Benoit,
Aguirre, Sergio saagui...@ti.com writes:
Hi Vaibhav,
Thanks for the comments.
On Thu, Dec 1, 2011 at 12:34 AM, Hiremath, Vaibhav hvaib...@ti.com wrote:
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio
Sent: Thursday, December 01, 2011 5:45 AM
To: linux-me...@vger.kernel.org
Cc: linux-omap@vger.kernel.org; laurent.pinch...@ideasonboard.com;
sakari.ai...@iki.fi; Aguirre, Sergio
Subject: [PATCH v2 04/11] OMAP4: hwmod: Include CSI2A and CSIPHY1 memory
sections
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-
omap2/omap_hwmod_44xx_data.c
index 7695e5d..1b59e2f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2623,8 +2623,18 @@ static struct omap_hwmod_ocp_if
*omap44xx_iss_masters[] = {
static struct omap_hwmod_addr_space omap44xx_iss_addrs[] = {
{
- .pa_start = 0x5200,
- .pa_end = 0x52ff,
+ .pa_start = OMAP44XX_ISS_TOP_BASE,
+ .pa_end = OMAP44XX_ISS_TOP_END,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .pa_start = OMAP44XX_ISS_CSI2_A_REGS1_BASE,
+ .pa_end = OMAP44XX_ISS_CSI2_A_REGS1_END,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .pa_start = OMAP44XX_ISS_CAMERARX_CORE1_BASE,
+ .pa_end = OMAP44XX_ISS_CAMERARX_CORE1_END,
.flags = ADDR_TYPE_RT
},
This patch will result in build failure, because, the above base addresses
are getting defined in the next patch
[PATCH v2 05/11] OMAP4: Add base addresses for ISS
Agreed. Will revisit git-bisectability of the patch series. Will fix.
To fix this, just drop the #defines from the header, and use raw
addresses directly.
Ok, i'll drop patch #5 in this series.
Also, work with Benoit to make sure at the scripts that autogenerate
this data are updated to include these two regions.
Ok.
As a side note, I might need more addresses for the rest of the ISP
components later on. I'll enable more subsystems once the CSI2-A only
initial version is in an acceptable state.
Regards,
Sergio
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 05/11] OMAP4: Add base addresses for ISS
Hi Kevin, Thanks for the review. On Fri, Dec 2, 2011 at 4:45 PM, Kevin Hilman khil...@ti.com wrote: Sergio Aguirre saagui...@ti.com writes: NOTE: This isn't the whole list of features that the ISS supports, but the only ones supported at the moment. Signed-off-by: Sergio Aguirre saagui...@ti.com [...] diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h b/arch/arm/plat-omap/include/plat/omap44xx.h index ea2b8a6..31432aa 100644 --- a/arch/arm/plat-omap/include/plat/omap44xx.h +++ b/arch/arm/plat-omap/include/plat/omap44xx.h @@ -49,6 +49,15 @@ #define OMAP44XX_MAILBOX_BASE (L4_44XX_BASE + 0xF4000) #define OMAP44XX_HSUSB_OTG_BASE (L4_44XX_BASE + 0xAB000) +#define OMAP44XX_ISS_BASE 0x5200 +#define OMAP44XX_ISS_TOP_BASE (OMAP44XX_ISS_BASE + 0x0) +#define OMAP44XX_ISS_CSI2_A_REGS1_BASE (OMAP44XX_ISS_BASE + 0x1000) +#define OMAP44XX_ISS_CAMERARX_CORE1_BASE (OMAP44XX_ISS_BASE + 0x1170) + +#define OMAP44XX_ISS_TOP_END (OMAP44XX_ISS_TOP_BASE + 256 - 1) +#define OMAP44XX_ISS_CSI2_A_REGS1_END (OMAP44XX_ISS_CSI2_A_REGS1_BASE + 368 - 1) +#define OMAP44XX_ISS_CAMERARX_CORE1_END (OMAP44XX_ISS_CAMERARX_CORE1_BASE + 32 - 1) + #define OMAP4_MMU1_BASE 0x55082000 #define OMAP4_MMU2_BASE 0x4A066000 Who are the users of thes address ranges? IMO, we shouldn't ned to add anymore based address definitions. These should be done in the hwmod data, and drivers get base addresses using the standard ways of getting resources (DT or platform_get_resource()) I see... I get your point now. Will remove them from this patch series then. Regards, Sergio 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 04/11] OMAP4: hwmod: Include CSI2A and CSIPHY1 memory sections
Hi Vaibhav,
Thanks for the comments.
On Thu, Dec 1, 2011 at 12:34 AM, Hiremath, Vaibhav hvaib...@ti.com wrote:
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio
Sent: Thursday, December 01, 2011 5:45 AM
To: linux-me...@vger.kernel.org
Cc: linux-omap@vger.kernel.org; laurent.pinch...@ideasonboard.com;
sakari.ai...@iki.fi; Aguirre, Sergio
Subject: [PATCH v2 04/11] OMAP4: hwmod: Include CSI2A and CSIPHY1 memory
sections
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-
omap2/omap_hwmod_44xx_data.c
index 7695e5d..1b59e2f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2623,8 +2623,18 @@ static struct omap_hwmod_ocp_if
*omap44xx_iss_masters[] = {
static struct omap_hwmod_addr_space omap44xx_iss_addrs[] = {
{
- .pa_start = 0x5200,
- .pa_end = 0x52ff,
+ .pa_start = OMAP44XX_ISS_TOP_BASE,
+ .pa_end = OMAP44XX_ISS_TOP_END,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .pa_start = OMAP44XX_ISS_CSI2_A_REGS1_BASE,
+ .pa_end = OMAP44XX_ISS_CSI2_A_REGS1_END,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .pa_start = OMAP44XX_ISS_CAMERARX_CORE1_BASE,
+ .pa_end = OMAP44XX_ISS_CAMERARX_CORE1_END,
.flags = ADDR_TYPE_RT
},
This patch will result in build failure, because, the above base addresses
are getting defined in the next patch
[PATCH v2 05/11] OMAP4: Add base addresses for ISS
Agreed. Will revisit git-bisectability of the patch series. Will fix.
Regards,
Sergio
Thanks,
Vaibhav
{ }
@@ -5350,7 +5360,7 @@ static __initdata struct omap_hwmod
*omap44xx_hwmods[] = {
omap44xx_ipu_c1_hwmod,
/* iss class */
-/* omap44xx_iss_hwmod, */
+ omap44xx_iss_hwmod,
/* iva class */
omap44xx_iva_hwmod,
--
1.7.7.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/11] arm: omap4panda: Add support for omap4iss camera
Hi Vaibhav,
Thanks for the comments.
On Thu, Dec 1, 2011 at 12:24 AM, Hiremath, Vaibhav hvaib...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio
Sent: Thursday, December 01, 2011 5:45 AM
To: linux-me...@vger.kernel.org
Cc: linux-omap@vger.kernel.org; laurent.pinch...@ideasonboard.com;
sakari.ai...@iki.fi; Aguirre, Sergio
Subject: [PATCH v2 10/11] arm: omap4panda: Add support for omap4iss camera
This adds support for camera interface with the support for
following sensors:
- OV5640
- OV5650
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/Kconfig | 27
arch/arm/mach-omap2/Makefile | 1 +
arch/arm/mach-omap2/board-omap4panda-camera.c | 198
+
3 files changed, 226 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap4panda-camera.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index f883abb..0fc5ce9 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -358,6 +358,33 @@ config MACH_OMAP4_PANDA
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE
+config MACH_OMAP4_PANDA_CAMERA_SUPPORT
+ bool OMAP4 Panda Board Camera support
+ depends on MACH_OMAP4_PANDA
+ select MEDIA_SUPPORT
+ select MEDIA_CONTROLLER
+ select VIDEO_DEV
+ select VIDEO_V4L2_SUBDEV_API
+ select VIDEO_OMAP4
+ help
+ Enable Camera HW support for PandaBoard.
+ This is for using the OMAP4 ISS CSI2A Camera sensor
+ interface.
+
+choice
+ prompt Camera sensor to use
+ depends on MACH_OMAP4_PANDA_CAMERA_SUPPORT
+ default MACH_OMAP4_PANDA_CAM_OV5650
+
+ config MACH_OMAP4_PANDA_CAM_OV5640
+ bool Use OmniVision OV5640 Camera
+ select VIDEO_OV5640
+
+ config MACH_OMAP4_PANDA_CAM_OV5650
+ bool Use OmniVision OV5650 Camera
+ select VIDEO_OV5650
+endchoice
+
config OMAP3_EMU
bool OMAP3 debugging peripherals
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 8bc446a..e80724d 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -236,6 +236,7 @@ obj-$(CONFIG_MACH_TI8168EVM) += board-
ti8168evm.o
# Platform specific device init code
obj-$(CONFIG_MACH_OMAP_4430SDP_CAMERA_SUPPORT) +=
board-4430sdp-camera.o
+obj-$(CONFIG_MACH_OMAP4_PANDA_CAMERA_SUPPORT) += board-omap4panda-
camera.o
Can't this be merged into single file? Do we really need separate file for
every board here?
I am sure you would have thought about this.
:)
Well, not really, to be honest.
I could have a single file, but wouldn't that make it more complex?
I mean, every board has it's own HW connection specs, like sensor MCLK source,
and different power up sequences. How would you probe for all, without messing
with an invalid GPIO on that board?
Have you resolved a similar case for other OMAP/Davinci boards?
omap-flash-$(CONFIG_MTD_NAND_OMAP2) := board-flash.o
omap-flash-$(CONFIG_MTD_ONENAND_OMAP2) := board-flash.o
diff --git a/arch/arm/mach-omap2/board-omap4panda-camera.c
b/arch/arm/mach-omap2/board-omap4panda-camera.c
new file mode 100644
index 000..02ef36e
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap4panda-camera.c
@@ -0,0 +1,198 @@
+#include linux/gpio.h
+#include linux/clk.h
+#include linux/delay.h
+
+#include plat/i2c.h
+#include plat/omap-pm.h
+
+#include asm/mach-types.h
+
+#include media/ov5640.h
+#include media/ov5650.h
+
+#include devices.h
+#include ../../../drivers/media/video/omap4iss/iss.h
+
I believe this is not good practice to include files directly from drivers
folder. You should divide the header file such that, driver specific
information stays in driver/... and platform specific goes into include/...
Right. Will fix.
+#include control.h
+#include mux.h
+
+#define PANDA_GPIO_CAM_PWRDN 45
+#define PANDA_GPIO_CAM_RESET 83
+
+static struct clk *panda_cam_aux_clk;
+
+static int panda_ov5640_power(struct v4l2_subdev *subdev, int on)
+{
+ struct iss_device *iss = v4l2_dev_to_iss_device(subdev-v4l2_dev);
+ int ret = 0;
You are not using this variable at all, you can get rid of this.
Right. Will fix.
+ struct iss_csiphy_dphy_cfg dphy;
+ struct iss_csiphy_lanes_cfg lanes;
+ unsigned int ddr_freq = 480; /* FIXME: Do an actual query for this
*/
+
+ memset(lanes, 0, sizeof(lanes));
+ memset(dphy, 0, sizeof(dphy));
+
+ lanes.clk.pos = 1;
+ lanes.clk.pol = 0;
+ lanes.data[0].pos = 2;
+ lanes.data[0].pol = 0;
+ lanes.data[1].pos = 3;
+ lanes.data[1].pol = 0;
+
+ dphy.ths_term = 12500 * ddr_freq + 100) / 100) - 1)
0xFF
Re: [PATCH v2 05/11] OMAP4: Add base addresses for ISS
Hi Laurent,
Thanks for the review.
On Thu, Dec 1, 2011 at 11:24 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Sergio,
On Thursday 01 December 2011 01:14:54 Sergio Aguirre wrote:
NOTE: This isn't the whole list of features that the
ISS supports, but the only ones supported at the moment.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/devices.c | 32
arch/arm/plat-omap/include/plat/omap44xx.h |
9 +++
2 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c15cfad..b48aeea 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -32,6 +32,7 @@
#include plat/omap_hwmod.h
#include plat/omap_device.h
#include plat/omap4-keypad.h
+#include plat/omap4-iss.h
I try to keep headers sorted alphabetically when possible, but that might just
be me.
No problem. I can change it.
#include mux.h
#include control.h
@@ -217,6 +218,37 @@ int omap3_init_camera(struct isp_platform_data *pdata)
return platform_device_register(omap3isp_device);
}
+int omap4_init_camera(struct iss_platform_data *pdata, struct
omap_board_data *bdata)
+{
+ struct platform_device *pdev;
+ struct omap_hwmod *oh;
+ struct iss_platform_data *omap4iss_pdata;
+ char *oh_name = iss;
+ char *name = omap4iss;
Would const char or static const char help the compiler putting the strings to
a read-only section ?
Right. Will fix.
+ unsigned int id = -1;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name);
+ return -ENODEV;
+ }
+
+ omap4iss_pdata = pdata;
+
+ pdev = omap_device_build(name, id, oh, omap4iss_pdata,
+ sizeof(struct iss_platform_data), NULL, 0, 0);
This is the only location where id is used, maybe you could pass -1 directly
to the function ?
Ditto.
Thanks and regards,
Sergio
+
+ if (IS_ERR(pdev)) {
+ WARN(1, Can't build omap_device for %s:%s.\n,
+ name, oh-name);
+ return PTR_ERR(pdev);
+ }
+
+ oh-mux = omap_hwmod_mux_init(bdata-pads, bdata-pads_cnt);
+
+ return 0;
+}
+
static inline void omap_init_camera(void)
{
#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h
b/arch/arm/plat-omap/include/plat/omap44xx.h index ea2b8a6..31432aa 100644
--- a/arch/arm/plat-omap/include/plat/omap44xx.h
+++ b/arch/arm/plat-omap/include/plat/omap44xx.h
@@ -49,6 +49,15 @@
#define OMAP44XX_MAILBOX_BASE (L4_44XX_BASE + 0xF4000)
#define OMAP44XX_HSUSB_OTG_BASE (L4_44XX_BASE + 0xAB000)
+#define OMAP44XX_ISS_BASE 0x5200
+#define OMAP44XX_ISS_TOP_BASE (OMAP44XX_ISS_BASE +
0x0)
+#define OMAP44XX_ISS_CSI2_A_REGS1_BASE (OMAP44XX_ISS_BASE +
0x1000)
+#define OMAP44XX_ISS_CAMERARX_CORE1_BASE (OMAP44XX_ISS_BASE + 0x1170)
+
+#define OMAP44XX_ISS_TOP_END (OMAP44XX_ISS_TOP_BASE + 256 -
1)
+#define OMAP44XX_ISS_CSI2_A_REGS1_END
(OMAP44XX_ISS_CSI2_A_REGS1_BASE +
368 - 1) +#define
OMAP44XX_ISS_CAMERARX_CORE1_END
(OMAP44XX_ISS_CAMERARX_CORE1_BASE + 32 -
1) +
#define OMAP4_MMU1_BASE 0x55082000
#define OMAP4_MMU2_BASE 0x4A066000
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 02/11] mfd: twl6040: Fix wrong TWL6040_GPO3 bitfield value
Hi Laurent, Thanks for the review. On Thu, Dec 1, 2011 at 11:24 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Sergio, On Thursday 01 December 2011 01:14:51 Sergio Aguirre wrote: The define should be the result of 1 Bit number. Bit number for GPOCTL.GPO3 field is 2, which results in 0x4 value. Signed-off-by: Sergio Aguirre saagui...@ti.com --- include/linux/mfd/twl6040.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h index 2463c261..2a7ff16 100644 --- a/include/linux/mfd/twl6040.h +++ b/include/linux/mfd/twl6040.h @@ -142,7 +142,7 @@ #define TWL6040_GPO1 0x01 #define TWL6040_GPO2 0x02 -#define TWL6040_GPO3 0x03 +#define TWL6040_GPO3 0x04 What about defining the fields as (1 x) instead then ? I thought about that, but I guess I just wanted to keep it consistent with the rest of the file. Maybe I can create a separate patch for changing all these bitwise flags to use BIT() macros instead. Thanks and Regards, Sergio /* ACCCTL (0x2D) fields */ -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/11] v4l2: OMAP4 ISS driver + Sensor + Board support
Hi Sakari, On Thu, Dec 1, 2011 at 10:14 AM, Sakari Ailus sakari.ai...@iki.fi wrote: Hi Sergio, Thanks for the patchset!! And thanks for your attention :) On Wed, Nov 30, 2011 at 06:14:49PM -0600, Sergio Aguirre wrote: Hi everyone, This is the second version of the OMAP4 ISS driver, now ported to the Media Controller framework AND supporting videobuf2 framework. This patchset should apply cleanly on top of v3.2-rc3 kernel tag. This driver attempts to provide an fully open source solution to control the OMAP4 Imaging SubSystem (a.k.a. ISS). Starts with just CSI2-A interface support, and pretends to be ready for expansion to add support to the many ISS block modules as possible. Please see newly added documentation for more details: Documentation/video4linux/omap4_camera.txt I propose s/omap4_camera/omap4iss/, according to the path name in the drivers/media/video directory. Makes sense. Will fix. Any comments/complaints are welcome. :) Changes since v1: - Simplification of auxclk handling in board files. (Pointed out by: Roger Quadros) - Cleanup of Camera support enablement for 4430sdp panda. (Pointed out by: Roger Quadros) - Use of HWMOD declaration for assisted platform_device creation. (Pointed out by: Felipe Balbi) - Videobuf2 migration (Removal of custom iss_queue buffer handling driver) I'm happy to see it's using videobuf2! Yeah, I'll definitely need it for multi-planar buffer handling for NV12 buffer capturing. Resizer can color convert from YUV422-YUV420 NV12 now, and expects 2 pointers (1 for Y, and 1 for UV 2x2 sampled) to be programmed in HW. I have no other comments quite yet. :-) Ok, let me know if you find something eye-popping ugly in there. I'll be happy to fix it. :) Thanks and Regards, Sergio Cheers, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: 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
Re: [PATCH v2 00/11] v4l2: OMAP4 ISS driver + Sensor + Board support
Hi Laurent, On Thu, Dec 1, 2011 at 11:26 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Sergio, On Thursday 01 December 2011 01:14:49 Sergio Aguirre wrote: Hi everyone, This is the second version of the OMAP4 ISS driver, now ported to the Media Controller framework AND supporting videobuf2 framework. Thanks a lot for working on this. And thanks to you for the patience and interest. I hope to make faster updates from now on :) This patchset should apply cleanly on top of v3.2-rc3 kernel tag. This driver attempts to provide an fully open source solution to control the OMAP4 Imaging SubSystem (a.k.a. ISS). Starts with just CSI2-A interface support, and pretends to be ready for expansion to add support to the many ISS block modules as possible. Please see newly added documentation for more details: Documentation/video4linux/omap4_camera.txt Any comments/complaints are welcome. :) I've started reviewing the patches, but it might take some time as I got lots on my plate at the moment. I will concentrate on the ISS patch (06/11) first. The sensor drivers are needed now for testing purpose, but can get their share of love later. Brilliant! That's fine with me. Thanks for your time. I really appreciate it. Regards, Sergio Changes since v1: - Simplification of auxclk handling in board files. (Pointed out by: Roger Quadros) - Cleanup of Camera support enablement for 4430sdp panda. (Pointed out by: Roger Quadros) - Use of HWMOD declaration for assisted platform_device creation. (Pointed out by: Felipe Balbi) - Videobuf2 migration (Removal of custom iss_queue buffer handling driver) - Proper GPO3 handling for CAM_SEL in 4430sdp. Sergio Aguirre (10): TWL6030: Add mapping for auxiliary regs mfd: twl6040: Fix wrong TWL6040_GPO3 bitfield value OMAP4: hwmod: Include CSI2A and CSIPHY1 memory sections OMAP4: Add base addresses for ISS v4l: Add support for omap4iss driver v4l: Add support for ov5640 sensor v4l: Add support for ov5650 sensor arm: omap4430sdp: Add support for omap4iss camera arm: omap4panda: Add support for omap4iss camera arm: Add support for CMA for omap4iss driver Stanimir Varbanov (1): v4l: Introduce sensor operation for getting interface configuration Documentation/video4linux/omap4_camera.txt | 60 ++ arch/arm/mach-omap2/Kconfig | 54 + arch/arm/mach-omap2/Makefile | 3 + arch/arm/mach-omap2/board-4430sdp-camera.c | 221 arch/arm/mach-omap2/board-omap4panda-camera.c | 198 arch/arm/mach-omap2/devices.c | 40 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 16 +- arch/arm/plat-omap/include/plat/omap4-iss.h | 42 + arch/arm/plat-omap/include/plat/omap44xx.h | 9 + drivers/media/video/Kconfig | 25 + drivers/media/video/Makefile | 3 + drivers/media/video/omap4iss/Makefile | 6 + drivers/media/video/omap4iss/iss.c | 1179 ++ drivers/media/video/omap4iss/iss.h | 133 +++ drivers/media/video/omap4iss/iss_csi2.c | 1324 + drivers/media/video/omap4iss/iss_csi2.h | 166 +++ drivers/media/video/omap4iss/iss_csiphy.c | 215 drivers/media/video/omap4iss/iss_csiphy.h | 69 ++ drivers/media/video/omap4iss/iss_regs.h | 238 + drivers/media/video/omap4iss/iss_video.c | 1192 ++ drivers/media/video/omap4iss/iss_video.h | 205 drivers/media/video/ov5640.c | 972 ++ drivers/media/video/ov5650.c | 524 ++ drivers/mfd/twl-core.c | 2 +- include/linux/mfd/twl6040.h | 2 +- include/media/ov5640.h | 10 + include/media/ov5650.h | 10 + include/media/v4l2-chip-ident.h | 2 + include/media/v4l2-subdev.h | 42 + 29 files changed, 6957 insertions(+), 5 deletions(-) create mode 100644 Documentation/video4linux/omap4_camera.txt create mode 100644 arch/arm/mach-omap2/board-4430sdp-camera.c create mode 100644 arch/arm/mach-omap2/board-omap4panda-camera.c create mode 100644 arch/arm/plat-omap/include/plat/omap4-iss.h create mode 100644 drivers/media/video/omap4iss/Makefile create mode 100644 drivers/media/video/omap4iss/iss.c create mode 100644 drivers/media/video/omap4iss/iss.h create mode 100644 drivers/media/video/omap4iss/iss_csi2.c create mode 100644 drivers/media/video/omap4iss/iss_csi2.h create mode 100644 drivers/media/video/omap4iss/iss_csiphy.c create mode 100644 drivers/media/video/omap4iss/iss_csiphy.h create mode 100644 drivers/media/video/omap4iss/iss_regs.h create mode 100644 drivers/media/video/omap4iss/iss_video.c create mode 100644 drivers/media/video/omap4iss/iss_video.h create mode 100644
Re: [PATCH v2 01/11] TWL6030: Add mapping for auxiliary regs
Hi Balaji,
Thanks for the review.
On Thu, Dec 1, 2011 at 9:58 AM, T Krishnamoorthy, Balaji
balaj...@ti.com wrote:
On Thu, Dec 1, 2011 at 5:44 AM, Sergio Aguirre saagui...@ti.com wrote:
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/mfd/twl-core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index bfbd660..e26b564 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -323,7 +323,7 @@ static struct twl_mapping twl6030_map[] = {
{ SUB_CHIP_ID0, TWL6030_BASEADD_ZERO },
{ SUB_CHIP_ID1, TWL6030_BASEADD_ZERO },
- { SUB_CHIP_ID2, TWL6030_BASEADD_ZERO },
+ { SUB_CHIP_ID1, TWL6030_BASEADD_AUX },
Instead you can use TWL6030_MODULE_ID1, with base address as
zero for all registers in auxiliaries register map.
Ok.
I'm actually thinking about this, and in the process on reviewing the
need to access those registers.
I should probably be using the regulator framework to control VAUX3 instead...
Thanks for your inputs.
Regards,
Sergio
{ SUB_CHIP_ID2, TWL6030_BASEADD_ZERO },
{ SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
{ SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
--
1.7.7.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/11] v4l2: OMAP4 ISS driver + Sensor + Board support
Hi again, On Wed, Nov 30, 2011 at 6:14 PM, Sergio Aguirre saagui...@ti.com wrote: Hi everyone, This is the second version of the OMAP4 ISS driver, now ported to the Media Controller framework AND supporting videobuf2 framework. This patchset should apply cleanly on top of v3.2-rc3 kernel tag. This driver attempts to provide an fully open source solution to control the OMAP4 Imaging SubSystem (a.k.a. ISS). Starts with just CSI2-A interface support, and pretends to be ready for expansion to add support to the many ISS block modules as possible. Please see newly added documentation for more details: Documentation/video4linux/omap4_camera.txt Any comments/complaints are welcome. :) Changes since v1: - Simplification of auxclk handling in board files. (Pointed out by: Roger Quadros) - Cleanup of Camera support enablement for 4430sdp panda. (Pointed out by: Roger Quadros) - Use of HWMOD declaration for assisted platform_device creation. (Pointed out by: Felipe Balbi) - Videobuf2 migration (Removal of custom iss_queue buffer handling driver) - Proper GPO3 handling for CAM_SEL in 4430sdp. Also, you can pull this as a branch in my git tree here: Web URL: http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera git URL: git://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera.git Branch: for3.2-rc3 Regards, Sergio Sergio Aguirre (10): TWL6030: Add mapping for auxiliary regs mfd: twl6040: Fix wrong TWL6040_GPO3 bitfield value OMAP4: hwmod: Include CSI2A and CSIPHY1 memory sections OMAP4: Add base addresses for ISS v4l: Add support for omap4iss driver v4l: Add support for ov5640 sensor v4l: Add support for ov5650 sensor arm: omap4430sdp: Add support for omap4iss camera arm: omap4panda: Add support for omap4iss camera arm: Add support for CMA for omap4iss driver Stanimir Varbanov (1): v4l: Introduce sensor operation for getting interface configuration Documentation/video4linux/omap4_camera.txt | 60 ++ arch/arm/mach-omap2/Kconfig | 54 + arch/arm/mach-omap2/Makefile | 3 + arch/arm/mach-omap2/board-4430sdp-camera.c | 221 arch/arm/mach-omap2/board-omap4panda-camera.c | 198 arch/arm/mach-omap2/devices.c | 40 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 16 +- arch/arm/plat-omap/include/plat/omap4-iss.h | 42 + arch/arm/plat-omap/include/plat/omap44xx.h | 9 + drivers/media/video/Kconfig | 25 + drivers/media/video/Makefile | 3 + drivers/media/video/omap4iss/Makefile | 6 + drivers/media/video/omap4iss/iss.c | 1179 ++ drivers/media/video/omap4iss/iss.h | 133 +++ drivers/media/video/omap4iss/iss_csi2.c | 1324 + drivers/media/video/omap4iss/iss_csi2.h | 166 +++ drivers/media/video/omap4iss/iss_csiphy.c | 215 drivers/media/video/omap4iss/iss_csiphy.h | 69 ++ drivers/media/video/omap4iss/iss_regs.h | 238 + drivers/media/video/omap4iss/iss_video.c | 1192 ++ drivers/media/video/omap4iss/iss_video.h | 205 drivers/media/video/ov5640.c | 972 ++ drivers/media/video/ov5650.c | 524 ++ drivers/mfd/twl-core.c | 2 +- include/linux/mfd/twl6040.h | 2 +- include/media/ov5640.h | 10 + include/media/ov5650.h | 10 + include/media/v4l2-chip-ident.h | 2 + include/media/v4l2-subdev.h | 42 + 29 files changed, 6957 insertions(+), 5 deletions(-) create mode 100644 Documentation/video4linux/omap4_camera.txt create mode 100644 arch/arm/mach-omap2/board-4430sdp-camera.c create mode 100644 arch/arm/mach-omap2/board-omap4panda-camera.c create mode 100644 arch/arm/plat-omap/include/plat/omap4-iss.h create mode 100644 drivers/media/video/omap4iss/Makefile create mode 100644 drivers/media/video/omap4iss/iss.c create mode 100644 drivers/media/video/omap4iss/iss.h create mode 100644 drivers/media/video/omap4iss/iss_csi2.c create mode 100644 drivers/media/video/omap4iss/iss_csi2.h create mode 100644 drivers/media/video/omap4iss/iss_csiphy.c create mode 100644 drivers/media/video/omap4iss/iss_csiphy.h create mode 100644 drivers/media/video/omap4iss/iss_regs.h create mode 100644 drivers/media/video/omap4iss/iss_video.c create mode 100644 drivers/media/video/omap4iss/iss_video.h create mode 100644 drivers/media/video/ov5640.c create mode 100644 drivers/media/video/ov5650.c create mode 100644 include/media/ov5640.h create mode 100644 include/media/ov5650.h -- 1.7.7.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at
RE: [Query] mm: !*pte hit in mm/memory.c:remap_pte_range
Hi Russell,
From: Russell King - ARM Linux [li...@arm.linux.org.uk]
Sent: Friday, January 21, 2011 4:30 AM
To: Aguirre, Sergio
Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org
Subject: Re: [Query] mm: !*pte hit in mm/memory.c:remap_pte_range
On Thu, Jan 20, 2011 at 03:06:30PM -0600, Aguirre, Sergio wrote:
And while debugging further, i realized that the point of stall was
in mm/memory.c, function:
static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd,
unsigned long addr, unsigned long end,
unsigned long pfn, pgprot_t prot)
{
BUG_ON(!pte_none(*pte)); ---*** HERE
}
How should i interpret this? Does this mean something specific?
It is asserting that the pte we are about to overwrite was empty. In
other words, there is no existing mapping in place at that virtual
address.
If there was a pre-existing mapping, you're doing something wrong
because you're potentially overwriting something else.
Ok. I see.
Thanks for the detailed explanation. I appreciate it.
Regards,
Sergio
--
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
[Query] mm: !*pte hit in mm/memory.c:remap_pte_range
Hi,
WARNING: Linux MM newbie here. Please bare with me a bit.
While debugging a new v4l2 driver that makes use of the OMAP4 Tiler allocators
in mmap calls, I found out that
remap_pfn_range was getting completely stalled.
And while debugging further, i realized that the point of stall was in
mm/memory.c, function:
static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd,
unsigned long addr, unsigned long end,
unsigned long pfn, pgprot_t prot)
{
pte_t *pte;
spinlock_t *ptl;
pte = pte_alloc_map_lock(mm, pmd, addr, ptl);
if (!pte)
return -ENOMEM;
arch_enter_lazy_mmu_mode();
do {
BUG_ON(!pte_none(*pte)); ---*** HERE
set_pte_at(mm, addr, pte, pte_mkspecial(pfn_pte(pfn, prot)));
pfn++;
} while (pte++, addr += PAGE_SIZE, addr != end);
arch_leave_lazy_mmu_mode();
pte_unmap_unlock(pte - 1, ptl);
return 0;
}
This is in 2.6.35.6 kernel + TI Android kernel changes. [1]
How should i interpret this? Does this mean something specific?
Any pointers will be appreciated.
Regards,
Sergio
---
[1]
http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-android-omap-2.6.35--
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
Spinlock recursion after root nfs mount
Hi all,
Has anyone been trying to boot w/k.org lately?
I tried with:
- commit e0e736fc + 2 patches attached I got from patchworks
- 4430SDP w/ES2.1
- Busybox FS through NFS.
I see the attached log, which shows a spinlock recursion bug.
I did a git bisect, and found this offending commit:
34286d6662308d82aed891852d04c7c3a2649b16 is the first bad commit
commit 34286d6662308d82aed891852d04c7c3a2649b16
Author: Nick Piggin npig...@kernel.dk
Date: Fri Jan 7 17:49:57 2011 +1100
fs: rcu-walk aware d_revalidate method
Require filesystems be aware of .d_revalidate being called in rcu-walk
mode (nd-flags LOOKUP_RCU). For now do a simple push down, returning
-ECHILD from all implementations.
Signed-off-by: Nick Piggin npig...@kernel.dk
:04 04 409693ac5c32f4daa0c9be786e85b04dea32a24f
1813b382a41b72ccb5d810c282639961e6d81b73 M Documentation
:04 04 a51e00e2f5335f8804e9e5fab10a26b0d67ac302
333fc859d8d1f2badea9023072e1ab356f042215 M drivers
:04 04 53158279a9808c50157dd4b6ec5c35951b3a60af
301c546b257a5b4f3f09289fc5e8f55e66b2b6b9 M fs
:04 04 e68ac1512333db998dc539a40a2b43dcee9cb074
f238839ffc4021e276be9d39d4e9c510575c9f44 M include
And I narrowed it down to this line:
In file fs/namei.c:
...
...
static int nameidata_dentry_drop_rcu(struct nameidata *nd, struct dentry
*dentry)
{
struct fs_struct *fs = current-fs;
struct dentry *parent = nd-path.dentry;
BUG_ON(!(nd-flags LOOKUP_RCU));
if (nd-root.mnt) {
spin_lock(fs-lock);
if (nd-root.mnt != fs-root.mnt ||
nd-root.dentry != fs-root.dentry)
goto err_root;
}
spin_lock(parent-d_lock);
spin_lock_nested(dentry-d_lock, DENTRY_D_LOCK_NESTED); -- HERE THE
RECURSION IS FIRED UP
...
...
I had been googling around and I just saw Uwe Santosh reporting the problem
in LKML, but nobody has answered.
Has anyone seen this aswell in other platforms? (OMAP3 based boards)
Regards,
Sergio
## Booting image at 8030 ...
Image Name: Linux-2.6.37-03740-gbc4a241
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:2941368 Bytes = 2.8 MB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
[0.00] Linux version 2.6.37-03740-gbc4a241
(x0091...@dtx0091359-ubuntu-1) (gcc version 4.4.1 (Sourcery G++ Lite
2010q1-202) ) #3 SMP Mon Jan 10 15:09:12 CST 2011
[0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7f
[0.00] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
[0.00] Machine: OMAP4430 4430SDP board
[0.00] Memory policy: ECC disabled, Data cache writealloc
[0.00] Truncating RAM at a000-bfff to -afff (vmalloc region
overlap).
[0.00] OMAP4430 ES2.0
[0.00] SRAM: Mapped pa 0x4030 to va 0xfe40 size: 0xe000
[0.00] FIXME: omap44xx_sram_init not implemented
[0.00] PERCPU: Embedded 7 pages/cpu @c115f000 s6048 r8192 d14432 u32768
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 181248
[0.00] Kernel command line: console=ttyO2,115200n8 root=/dev/nfs rw
nfsroot=128.247.78.218:/home/x0091359/my-nfs/busybox,tcp,rsize=4096,wsize=4096
mem=4...@0x8000 mem=5...@0xa000 noinitrd ip=dh
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 458MB 512MB = 970MB total
[0.00] Memory: 712916k/712916k available, 18220k reserved, 0K highmem
[0.00] Virtual kernel memory layout:
[0.00] vector : 0x - 0x1000 ( 4 kB)
[0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB)
[0.00] DMA : 0xffc0 - 0xffe0 ( 2 MB)
[0.00] vmalloc : 0xf080 - 0xf800 ( 120 MB)
[0.00] lowmem : 0xc000 - 0xf000 ( 768 MB)
[0.00] modules : 0xbf00 - 0xc000 ( 16 MB)
[0.00] .init : 0xc0008000 - 0xc0052000 ( 296 kB)
[0.00] .text : 0xc0052000 - 0xc0583a94 (5319 kB)
[0.00] .data : 0xc0584000 - 0xc05f9240 ( 469 kB)
[0.00] Hierarchical RCU implementation.
[0.00] RCU-based detection of stalled CPUs is disabled.
[0.00] NR_IRQS:402
[0.00] [ cut here ]
[0.00] WARNING: at arch/arm/mach-omap2/clockdomain.c:876
omap2_clkdm_deny_idle+0x4c/0x7c()
[0.00] clockdomain: OMAP4 wakeup/sleep dependency support is not yet
implemented
[0.00] Modules linked in:
[0.00] [c0063290] (unwind_backtrace+0x0/0xe4) from [c0093f60]
(warn_slowpath_common+0x4c/0x64)
[
RE: [RFC] omap: mailbox: fix detection for previously supported chips
Hi Omar,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Omar Ramirez Luna
Sent: Wednesday, September 22, 2010 7:22 PM
To: Tony Lindgren; Hiroshi DOYU; Felipe Contreras; Anna, Suman; linux-
o...@vger.kernel.org
Cc: Ramirez Luna, Omar
Subject: [RFC] omap: mailbox: fix detection for previously supported chips
Fix the mailbox support detection for OMAP3630, 3530/25 and 2430.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
- Testing was made under 3630 and 3430 boards.
- Given that 2430 uses similar initialization than OMAP3, changes
to handle this case was added to the patch.
- HWMOD adaptation hopefully should solve this mess, but as of now
mailbox should work as before at least.
arch/arm/mach-omap2/mailbox.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 42dbfa4..26d6fb0 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -394,15 +394,19 @@ static int __devinit omap2_mbox_probe(struct
platform_device *pdev)
if (false)
;
-#if defined(CONFIG_ARCH_OMAP3430)
- else if (cpu_is_omap3430()) {
+#if defined(CONFIG_ARCH_OMAP3)
+ else if (omap3_has_iva()) {
list = omap3_mboxes;
list[0]-irq = platform_get_irq_byname(pdev, dsp);
}
#endif
-#if defined(CONFIG_ARCH_OMAP2420)
- else if (cpu_is_omap2420()) {
+#if defined(CONFIG_ARCH_OMAP2)
+ else if (cpu_is_omap2430()) {
+ list = omap2_mboxes;
+
+ list[0]-irq = platform_get_irq_byname(pdev, dsp);
+ } else if (cpu_is_omap2420()) {
Isn't both 2430 and 2420 doing the exact same?
If yes, How about just doing:
else if (cpu_is_omap2430() || cpu_is_omap2420()) {
list = omap2_mboxes;
list[0]-irq = platform_get_irq_byname(pdev, dsp);
Regards,
Sergio
--
1.7.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
--
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] omap: mailbox: fix detection for previously supported chips
Hi Omar,
-Original Message-
From: Ramirez Luna, Omar
Sent: Thursday, September 23, 2010 11:12 AM
To: Aguirre, Sergio; Tony Lindgren; Hiroshi DOYU; Felipe Contreras; Anna,
Suman; linux-omap@vger.kernel.org
Subject: RE: [RFC] omap: mailbox: fix detection for previously supported
chips
Hi Sergio,
Aguirre, Sergio wrote:
Hi Omar,
...
+#if defined(CONFIG_ARCH_OMAP2)
+ else if (cpu_is_omap2430()) {
+ list = omap2_mboxes;
+
+ list[0]-irq = platform_get_irq_byname(pdev, dsp);
+ } else if (cpu_is_omap2420()) {
Isn't both 2430 and 2420 doing the exact same?
Code is not the same, it is 2 line which apply for both but couldn't find
an easy way of making them share the request for dsp mailbox without
changing more code, perhaps a macro to detect if omap2 and then a nested
if for the 2420 case, but since HWMOD should handle it better, I left it
as is.
As the code previous to reorganization treated 2430 has a user with one
single mailbox (same as omap3) I added the code to at least detect it,
2420 has 2 mailboxes one for iva and other for the dsp. From the diagrams
for OMAP2430[1] and OMAP2420[2], it made sense as in the later both dsp
and iva seem to be separated entities; unfortunately I don't have the
hardware to test on any of them.
The patched code should look like:
#if defined(CONFIG_ARCH_OMAP2)
else if (cpu_is_omap2430()) {
list = omap2_mboxes;
list[0]-irq = platform_get_irq_byname(pdev, dsp);
} else if (cpu_is_omap2420()) {
list = omap2_mboxes;
list[0]-irq = platform_get_irq_byname(pdev, dsp);
list[1]-irq = platform_get_irq_byname(pdev, iva);
}
#endif
Ok, I understand.
I guess I missed to see the second element in the list for acquiring IVA irq.
Thanks for the explanation.
Regards,
Sergio
Regards,
Omar
---
[1]
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?contentId=467
2navigationId=12609templateId=6123
[2]
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=61
23navigationId=11990contentId=4671
--
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 13/13 v2] OMAP3: SERIAL: Initialize all omap-uarts for zoom boards
Hi Govindraj,
Just one non-functional comment below.
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Raja, Govindraj
Sent: Wednesday, September 22, 2010 10:15 AM
To: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; linux-ser...@vger.kernel.org;
Kevin Hilman; Tony Lindgren; Gadiyar, Anand
Subject: [PATCH 13/13 v2] OMAP3: SERIAL: Initialize all omap-uarts for
zoom boards
Iniatize all omap-uarts for zoom boards.
Remove serial_init from 3630sdp board init
as zoom_peripheral_init does the same.
I think this description mismatches slightly to what is really
being done in the patch.
I mean, the way you say it, it's like the omap_serial_init
was already in zoom_peripheral_init... which is not.
Regards,
Sergio
Signed-off-by: Kevin Hilman khil...@ti.com
Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/board-3630sdp.c |1 -
arch/arm/mach-omap2/board-zoom-peripherals.c |1 +
2 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3630sdp.c b/arch/arm/mach-
omap2/board-3630sdp.c
index b359c3f..d510451 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -208,7 +208,6 @@ static struct flash_partitions sdp_flash_partitions[]
= {
static void __init omap_sdp_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
- omap_serial_init();
zoom_peripherals_init();
board_smc91x_init();
board_flash_init(sdp_flash_partitions, chip_sel_sdp);
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 6b39849..641765a 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -282,4 +282,5 @@ void __init zoom_peripherals_init(void)
omap_i2c_init();
usb_musb_init(musb_board_data);
enable_board_wakeup_source();
+ omap_serial_init();
}
--
1.6.3.3
--
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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 11/13 v2] serial: Add OMAP high-speed UART driver
Hi Govindraj,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Govindraj.R
Sent: Wednesday, September 22, 2010 10:15 AM
To: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; linux-ser...@vger.kernel.org;
Kevin Hilman; Tony Lindgren
Subject: [PATCH 11/13 v2] serial: Add OMAP high-speed UART driver
This patch adds driver support for OMAP2/3/4 high speed UART.
The driver is made separate from 8250 driver as we cannot
over load 8250 driver with omap platform specific configuration for
features like DMA, it makes easier to implement features like DMA and
hardware flow control and software flow control configuration with
this driver as required for the omap-platform.
This patch involves only the core driver and its dependent.
Cc: Tony Lindgren t...@atomide.com
Tested-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/plat-omap/include/plat/omap-serial.h | 129 +++
drivers/serial/Kconfig| 27 +
drivers/serial/Makefile |1 +
drivers/serial/omap-serial.c | 1332
+
include/linux/serial_core.h |3 +
5 files changed, 1492 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/omap-serial.h
create mode 100644 drivers/serial/omap-serial.c
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
new file mode 100644
index 000..0d6f076
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -0,0 +1,129 @@
+/*
+ * Driver for OMAP-UART controller.
+ * Based on drivers/serial/8250.c
+ *
+ * Copyright (C) 2010 Texas Instruments.
+ *
+ * Authors:
+ * Govindraj R govindraj.r...@ti.com
+ * Thara Gopinath th...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __OMAP_SERIAL_H__
+#define __OMAP_SERIAL_H__
+
+#include linux/serial_core.h
+#include linux/platform_device.h
+
+#include plat/control.h
+#include plat/mux.h
+
+#define DRIVER_NAME omap-hsuart
Is there a reason why you keep 2 names in the driver?
You use this for the platform_driver struct serial_omap_driver,
Meanwhile you send a driver name of OMAP-SERIAL to uart_driver struct...
Also IMHO, if you're just going to use this once, then it makes no sense to
have this macro.
+
+/*
+ * Use tty device name as ttyO, [O - OMAP]
+ * in bootargs we specify as console=ttyO0 if uart1
+ * is used as console uart.
+ */
+#define OMAP_SERIAL_NAME ttyO
+
+#define OMAP_MDR1_DISABLE0x07
+#define OMAP_MDR1_MODE13X0x03
+#define OMAP_MDR1_MODE16X0x00
+#define OMAP_MODE13X_SPEED 230400
+
+/*
+ * LCR = 0XBF: Switch to Configuration Mode B.
+ * In configuration mode b allow access
+ * to EFR,DLL,DLH.
+ * Reference OMAP TRM Chapter 17
+ * Section: 1.4.3 Mode Selection
+ */
+#define OMAP_UART_LCR_CONF_MDB 0XBF
+
+/* WER = 0x7F
+ * Enable module level wakeup in WER reg
+ */
+#define OMAP_UART_WER_MOD_WKUP 0X7F
+
+/* Enable XON/XOFF flow control on output */
+#define OMAP_UART_SW_TX 0x04
+
+/* Enable XON/XOFF flow control on input */
+#define OMAP_UART_SW_RX 0x04
+
+#define OMAP_UART_SYSC_RESET 0X07
+#define OMAP_UART_TCR_TRIG 0X0F
+#define OMAP_UART_SW_CLR 0XF0
+#define OMAP_UART_FIFO_CLR 0X06
+
+#define OMAP_UART_DMA_CH_FREE-1
+
+#define RX_TIMEOUT (3 * HZ)
+#define OMAP_MAX_HSUART_PORTS4
+
+#define MSR_SAVE_FLAGS UART_MSR_ANY_DELTA
+
+struct omap_uart_port_info {
+ booldma_enabled;/* To specify DMA Mode */
+ unsigned intuartclk;/* UART clock rate */
+ void __iomem*membase; /* ioremap cookie or NULL */
+ resource_size_t mapbase;/* resource base */
+ unsigned long irqflags; /* request_irq flags */
+ upf_t flags; /* UPF_* flags */
+};
+
+struct uart_omap_dma {
+ u8 uart_dma_tx;
+ u8 uart_dma_rx;
+ int rx_dma_channel;
+ int tx_dma_channel;
+ dma_addr_t rx_buf_dma_phys;
+ dma_addr_t tx_buf_dma_phys;
+ unsigned intuart_base;
+ /*
+ * Buffer for rx dma.It is not required for tx because the buffer
+ * comes from port structure.
+ */
+ unsigned char *rx_buf;
+ unsigned intprev_rx_dma_pos;
+ int tx_buf_size;
+
omap3_defconfig: USB_OTG unmet dependencies
Hi all, Today, I tried loading the omap3_defconfig from current master commit: ddfc2d1 Linux-omap rebuilt: Updated to v2.6.36-rc1 And I noticed this bad Kconfig dependency: warning: (USB_MUSB_HDRC_HCD USB_SUPPORT USB_MUSB_HDRC (USB_MUSB_HOST || USB_MUSB_OTG) USB_GADGET_MUSB_HDRC || USB_MUSB_OTG choice USB USB_GADGET PM EXPERIMENTAL) selects USB_OTG which has unmet direct dependencies (USB_GADGET_OMAP ARCH_OMAP_OTG USB_OHCI_HCD) warning: (USB_MUSB_HDRC_HCD USB_SUPPORT USB_MUSB_HDRC (USB_MUSB_HOST || USB_MUSB_OTG) USB_GADGET_MUSB_HDRC || USB_MUSB_OTG choice USB USB_GADGET PM EXPERIMENTAL) selects USB_OTG which has unmet direct dependencies (USB_GADGET_OMAP ARCH_OMAP_OTG USB_OHCI_HCD) # # configuration written to .config # Is there a patch to resolve this already? Regards, Sergio -- 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: omap3_defconfig: USB_OTG unmet dependencies
(Looping linux-usb) -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio Sent: Friday, August 20, 2010 2:21 PM To: linux-omap@vger.kernel.org Subject: omap3_defconfig: USB_OTG unmet dependencies Hi all, Today, I tried loading the omap3_defconfig from current master commit: ddfc2d1 Linux-omap rebuilt: Updated to v2.6.36-rc1 And I noticed this bad Kconfig dependency: I noticed that there's 2 Kconfig files that have a config USB_OTG entry. The one in drivers/usb/gadget/Kconfig looks misplaced, and by looking at the Description, it seems to be some OMAP specific thing... Shouldn't that go away? What do you think?: diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index cd27f9b..19a6eb6 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -209,17 +209,6 @@ config USB_OMAP default USB_GADGET select USB_GADGET_SELECTED -config USB_OTG - boolean OTG Support - depends on USB_GADGET_OMAP ARCH_OMAP_OTG USB_OHCI_HCD - help - The most notable feature of USB OTG is support for a - Dual-Role device, which can act as either a device - or a host. The initial role choice can be changed - later, when two dual-role devices talk to each other. - - Select this only if your OMAP board has a Mini-AB connector. - config USB_GADGET_PXA25X boolean PXA 25x or IXP 4xx depends on (ARCH_PXA PXA25x) || ARCH_IXP4XX -- 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
[ANNOUNCE] OMAP3 Camera ISP driver wiki in omappedia.org
Hi all, I'll like to announce a new wikipage entry in http://omappedia.org site for OMAP3 Camera-ISP progress and details. Please find it here. http://omappedia.org/wiki/Camera-ISP_Driver The intention is to provide an online documentation of the work and progress of the patches submission, and its dependencies (Media Controller Framework, specifically). If you're interested to contribute/experiment with the driver, this is intended to be a good start point for that, and also feel free to update it aswell. The more people trying the driver, the better, so we can have as much platforms running with it as possible, and we can claim that the driver is flexible enough for all. Have a great weekend! Regards, Sergio -- 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: omap3camera and linux-omap
Hi Michael, -Original Message- From: Michael Jones [mailto:michael.jo...@matrix-vision.de] Sent: Monday, August 09, 2010 10:42 AM To: Aguirre, Sergio Cc: linux-omap@vger.kernel.org; sakari.ai...@maxwell.research.nokia.com Subject: Re: omap3camera and linux-omap Aguirre, Sergio wrote: Hi Michael, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Michael Jones Sent: Friday, August 06, 2010 8:48 AM To: linux-omap@vger.kernel.org Cc: sakari.ai...@maxwell.research.nokia.com Subject: omap3camera and linux-omap I am currently using Sakari's omap3camera repository (branch 'devel'). 'git merge-base linux-omap omap3camera' tells me that the last commit omap3camera has in common with linux-omap is 40a0c47, from July 7 2010. But there are 1000 commits which are only in omap3camera, dating back to 2008. Is this destined to stay this way? This is because devel branch keeps a detailed development history since we started working on the camera driver. At the end, the patches submitted will be a consolidated set, which should end in something around ~12 patches or so.. Or will the omap3camera tree be merged into linux-omap at some point? The omap3camera submission is on hold, because the camera driver is dependant on Media controller framework, which is holding for merge in linux-media mailing list. When proposing a patch for the omap3camera tree, should it be sent to this list? You should preferably send the patches to linux-media (at) vger.kernel.org mailing with cc to Sakari Ailus and Laurent Pinchart. So far we have been keeping patch review internally, because we didn't want to pollute the mailing list with patches to unsubmitted code. Regards, Sergio Thanks, Michael Hi Sergio, Thanks for the helpful reply. Can you also clarify for me the difference between omap3camera and your linux-omap-camera (http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary) repositories? No problem. The difference is that, in my 'omap-devel' branch, you'll find: 1. Latest linux-omap master. 2. Some yet unmerged OMAP Zoom3 patches (Touchscreen, NEC LCD panel) 3. Some patches to support Beagleboard xM (OMAP3730) 4. Merged Sakari's 'devel' branch. 5. Some omap3 camera driver unmerged legacy nodes removal patches from Laurent Pinchart. 6. Some patches to add support for different RAW Patterns, which I'm still working on. 7. Sony IMX046 8MP CSI-2 Sensor driver, present in Zoom3. 8. LV8093 Lens actuator driver, present on Zoom3 and in tandem with IMX046 sensor I assume this development has mainly happened on the board-rx51* platform? Yeah, Sakari and Laurent maintain the rx51 (a.k.a. Nokia N900) camera support. Ultimately I want to get raw sensor data to memory. Do you foresee any problems doing that with the current state of omap3camera? It shouldn't be a problem, as soon as you configure the pipeline adequately. Please see this Media controller testapp, maintained by Laurent Pinchart, for help on how to do that: http://git.ideasonboard.org/?p=media-ctl.git;a=summary Might I be better off going with a kernel with v4l2_int_device at first? I won't recommend that. You probably noticed that my tree still keeps some branches with support for that old driver, but it was for some maintenance support for a code mainline for Texas Instruments. I'll definitely recommend to stick with the latest code, and most preferably base your work on Sakari's tree (i.e. gitorious.org/omap3camera tree), so we can all reference to a standard codebase. I appreciate your interest in contributing with the camera driver development, and definitely looking forward for any patches you may want to share with us. Regards, Sergio thanks, Michael MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans- Joachim Reich -- 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
Zoom3 not booting with omap3_defconfig
Hi, I'm trying to boot from NFS with my Zoom3 board with current master branch (commit ID: 842849896627701e4c07441f2c7519aeec771058) But, I'm not successful so far. :( Seems that it can't detect the eth0 device. (See attached log: bad.txt) Now, If I take omap_zoom3_defconfig from just before commit: commit 80690ccc41f01df6edfb6684006824d8edff189e Author: Vincent Sanders vi...@simtec.co.uk Date: Tue Aug 3 21:19:21 2010 +0100 Remove ARM default configurations which duplicate omap3_defconfig I'm able to boot fine (see attached log: good.txt) So, somehow, current omap3_defconfig doesn't seem to be as functional as omap_zoom3_defconfig used to be... Is there something that everybody knows, and I'm missing on how to make a usable Zoom3 .config? Regards, Sergio Uncompressing Linux... done, booting the kernel. [0.00] Linux version 2.6.35-08926-g12fafbf (x0091...@dtx0091359-ubuntu-1) (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-72) ) #3 Mon Aug 9 12:15:41 CDT 2010 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: OMAP Zoom3 board [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP3630/3730 ES1.2 (l2cache iva sgx neon isp 192mhz_clk ) [0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x10 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 [0.00] Kernel command line: earlyprintk console=ttyS0,115200n8 noinitrd mem=512M root=/dev/nfs rw nfsroot=128.247.74.241:/home/x0091359/my-nfs/busybox,nolock ip=dhcp nfsvers=3,tcp omap_vout_mod.video1_ numbuffers=6 omap_vout_mod.vid1_static_vrfb_alloc=y omap_vout_mod.video2_numbuffers=6 omap_vout_mod.vid2_static_vrfb_alloc=y [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 512MB = 512MB total [0.00] Memory: 505836k/505836k available, 18452k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] DMA : 0xffc0 - 0xffe0 ( 2 MB) [0.00] vmalloc : 0xe080 - 0xf800 ( 376 MB) [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .init : 0xc0008000 - 0xc0048000 ( 256 kB) [0.00] .text : 0xc0048000 - 0xc0604000 (5872 kB) [0.00] .data : 0xc063 - 0xc0808a40 (1891 kB) [0.00] Hierarchical RCU implementation. [0.00] RCU-based detection of stalled CPUs is disabled. [0.00] Verbose stalled-CPUs detection is disabled. [0.00] NR_IRQS:402 [0.00] Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz [0.00] (null): Could not get uart4_ick [0.00] (null): Could not get uart4_fck [0.00] Reprogramming SDRC clock to 4 Hz [0.00] GPMC revision 5.0 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] Could not get gpios_ick [0.00] Could not get gpios_fck [0.00] OMAP GPIO hardware version 2.5 [0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3951 kB [0.00] per task-struct memory footprint: 2304 bytes [0.00] Calibrating delay loop... 597.64 BogoMIPS (lpj=2334720) [0.00] pid_max: default: 32768 minimum: 301 [0.00] Security Framework initialized [0.00] Mount-cache hash table entries: 512 [0.00] CPU: Testing write buffer coherency: ok [0.00] regulator: core version 0.5 [0.00] NET: Registered protocol family 16 [0.000793] OMAP DMA hardware revision 5.0 [0.084228] bio: create slab bio-0 at 0 [0.093078] SCSI subsystem initialized [0.102752] usbcore: registered new interface driver usbfs [0.104034] usbcore: registered new interface driver hub [0.104949] usbcore: registered new device driver usb [0.107543] i2c_omap i2c_omap.1: bus 1 rev4.0 at 2400 kHz [0.118652] twl4030: PIH (irq 7) chaining IRQs 368..375
RE: Zoom3 not booting with omap3_defconfig (update: sometimes...)
Hi, -Original Message- From: Elvis Dowson [mailto:elvis.dow...@mac.com] Sent: Monday, August 09, 2010 2:17 PM To: Aguirre, Sergio Cc: linux-omap@vger.kernel.org Subject: Re: Zoom3 not booting with omap3_defconfig Hi Sergio, I've seen the exact same thing happen, when I used the linux-omap v2.6.35 tag for a beagleboard based device. It gives me the same kernel panic. Actually, I realized something weird... If I have the exact same kernel, generated with omap3_defconfig, IT sometimes generates me these errors: [2.674804] IP-Config: Failed to open eth0 [2.678924] IP-Config: No network devices available. And sometimes it succeeds: [2.680389] net eth0: SMSC911x/921x identified at 0xe08da000, IRQ: 318 [3.688232] Sending DHCP requests .., OK [6.469879] IP-Config: Got DHCP answer from 0.0.0.0, my address is 128.247.75.216 [6.479034] IP-Config: Complete: So, I don't know... Either I have a faulty HW, or some race condition is happening on the driver that doesn't allow to open it.. I'll try to find out why the open of eth0 fails sometimes.. Regards, Sergio [2.097320] Waiting for root device /dev/mmcblk0p2... [2.235595] mmc0: new SD card at address b874 [2.243530] mmcblk0: mmc0:b874 SU02G 1.87 GiB (ro) [2.250213] mmcblk0: p1 p2 [2.323638] VFS: Cannot open root device mmcblk0p2 or unknown- block(179,2) [2.330871] Please append a correct root= boot option; here are the available partitions: [2.339477] b300 1971712 mmcblk0 driver: mmcblk [2.344848] b301 40131 mmcblk0p1 [2.349182] b302 514080 mmcblk0p2 [2.353973] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2) In my case, I found that using v2.6.35 and using the omap3_beagleboard_defconfig worked. This must an artifact from the defconfig clean up that happened for v2.6.35, breakages due to defective or untested defconfigs. Why don't you try a defconfig from a previous kernel version that works? Best regards, Elvis Dowson -- 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
[Zoom3] smsc911x_soft_reset: Failed to complete reset (sometimes...)
Hi all, Seems that, with current master branch (commit ID: 842849896627701e4c07441f2c7519aeec771058), and doing this change: diff --git a/drivers/net/smsc911x.h b/drivers/net/smsc911x.h index 016360c..2cd4f5a 100644 --- a/drivers/net/smsc911x.h +++ b/drivers/net/smsc911x.h @@ -23,7 +23,7 @@ #define TX_FIFO_LOW_THRESHOLD ((u32)1600) #define SMSC911X_EEPROM_SIZE ((u32)7) -#define USE_DEBUG 0 +#define USE_DEBUG 1 /* This is the maximum number of packets to be received every * NAPI poll */ I see in the console sometimes (not always) these error messages: [2.682342] eth0: smsc911x_soft_reset: Failed to complete reset [2.688385] eth0: smsc911x_open: soft reset failed [2.693176] IP-Config: Failed to open eth0 [2.697326] IP-Config: No network devices available. Is somebody also experiencing this? NOTE: It doesn't seem consistent. I had to reboot several times the board, To reproduce it. Sometimes it comes at the first try. Regards, Sergio -- 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: omap3camera and linux-omap
Hi Michael, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Michael Jones Sent: Friday, August 06, 2010 8:48 AM To: linux-omap@vger.kernel.org Cc: sakari.ai...@maxwell.research.nokia.com Subject: omap3camera and linux-omap I am currently using Sakari's omap3camera repository (branch 'devel'). 'git merge-base linux-omap omap3camera' tells me that the last commit omap3camera has in common with linux-omap is 40a0c47, from July 7 2010. But there are 1000 commits which are only in omap3camera, dating back to 2008. Is this destined to stay this way? This is because devel branch keeps a detailed development history since we started working on the camera driver. At the end, the patches submitted will be a consolidated set, which should end in something around ~12 patches or so.. Or will the omap3camera tree be merged into linux-omap at some point? The omap3camera submission is on hold, because the camera driver is dependant on Media controller framework, which is holding for merge in linux-media mailing list. When proposing a patch for the omap3camera tree, should it be sent to this list? You should preferably send the patches to linux-media (at) vger.kernel.org mailing with cc to Sakari Ailus and Laurent Pinchart. So far we have been keeping patch review internally, because we didn't want to pollute the mailing list with patches to unsubmitted code. Regards, Sergio Thanks, Michael MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans- Joachim Reich -- 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 -- 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 DSS2 coming out of OFF mode without restoring context
Hi,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Friday, July 30, 2010 8:01 AM
To: Tomi Valkeinen
Cc: ext Laine Walker-Avina; linux-omap@vger.kernel.org; linux-
fb...@vger.kernel.org
Subject: Re: OMAP DSS2 coming out of OFF mode without restoring context
Tomi Valkeinen had written, on 07/30/2010 06:17 AM, the following:
On Fri, 2010-07-30 at 13:09 +0200, ext Menon, Nishanth wrote:
- Original message -
Hi,
On Thu, 2010-07-29 at 23:29 +0200, ext Laine Walker-Avina wrote:
Hi,
I'm having a problem where the DSS driver isn't restoring the
framebuffer parameters after going in and out of blanking with OFF
mode enabled. The problem appears to be in dss_get_ctx_id() in that
pdata-get_last_off_on_transaction_id is 0. Commenting out the call
to
dss_need_ctx_restore() in dss_clk_enable() appears to do the right
thing. I'm using the current master branch of linux-omap.
You need to fill the func pointer in the board file:
static struct omap_dss_board_info xxx_dss_data = {
.get_last_off_on_transaction_id =
omap_pm_get_dev_context_loss_count,
none of l-o board files seem to do this. I guess
with off capable master, we need this to be
defaulted under CONFIG_PM within dss/core itself?
I mean the defaults prevent display function
at off, so why ask all boards to fill it up?
If the PM stuff in linux tree starts to be in working order, then yes,
we need some better solution.
I'm not quite sure what the options are, but I was told that the correct
way to get context loss count is as above, fill the platform_data in the
board file with a pointer to omap_pm_get_dev_context_loss_count().
So if that is still the proper way, then we need a DSS platform
initialization function that the board files can call, which then fills
the platform_data with correct data.
But this will still require modifying every board file that uses DSS.
Then again, every board file needs anyway DSS code, so perhaps that's
not such a big issue.
For this particular case there's not much benefit having a separate
initialization function. On the contrary, it'll just have more code
lines. But I think there will be some more platform DSS stuff (like
pinmuxing) which can then use the same mechanism.
Tomi
I was thinking more of the lines of this:
a) omap_pm_get_dev_context_loss_count is exported
OR
b) there is a file arch/arm/mach-omap2/dss.c which would take this..
I'm curious about something...
Why this can't be part of the platform code per-cpu?
It makes no sense to me (unless I'm missing something here) to put this
In mach-omap2/ files... It should be on plat-omap/ somewhere.
What do you think?
Regards,
Sergio
diff --git a/drivers/video/omap2/dss/core.c
b/drivers/video/omap2/dss/core.c
index b3a498f..0b9041a 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -35,6 +35,7 @@
#include plat/display.h
#include plat/clock.h
+#include plat/omap-pm.h
#include dss.h
@@ -502,6 +503,10 @@ static int omap_dss_probe(struct platform_device
*pdev)
core.pdev = pdev;
+ if (!core.pdev-get_last_off_on_transaction_id)
+ core.pdev-get_last_off_on_transaction_id =
+ omap_pm_get_dev_context_loss_count;
+
dss_init_overlay_managers(pdev);
dss_init_overlays(pdev);
--
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
--
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 resend v2] omap: 3630: disable TLL SAR on 3630 ES1
Hi Anand,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Anand Gadiyar
Sent: Wednesday, July 14, 2010 8:39 AM
To: linux-omap@vger.kernel.org
Cc: Gadiyar, Anand
Subject: [PATCH resend v2] omap: 3630: disable TLL SAR on 3630 ES1
USBTLL Save-and-Restore is broken in 3630 ES1.0. Having it
enabled could result in incorrect register restores as
the OMAP exits off-mode. This could potentially result in
unexpected wakeup events.
(Refer 3630 errata ID i579)
This is fixed in ES1.1. So disable it for ES1.0s.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Acked-by: Paul Walmsley p...@pwsan.com
---
(v2: Added a comment to the code with a reference to the errata IDs
for 3430 and 3630. Also added Paul's ack).
This is a fix for buggy hardware, and it would be nice
to see this in the next merge window too.
Depends on the patch I just posted which adds the
CHIP_GE_OMAP3630ES1_1 macro
https://patchwork.kernel.org/patch/47/
arch/arm/mach-omap2/powerdomains34xx.h | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
Index: linux-omap-2.6/arch/arm/mach-omap2/powerdomains34xx.h
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/powerdomains34xx.h
+++ linux-omap-2.6/arch/arm/mach-omap2/powerdomains34xx.h
@@ -75,12 +75,19 @@ static struct powerdomain mpu_3xxx_pwrdm
},
};
+/*
+ * The USBTLL Save-and-Restore mechanism is broken on
+ * 3430s upto ES3.0 and 3630ES1.0. Hence this feature
+ * needs to be disabled on these chips.
+ * Refer: 3430 errata ID i459 and 3630 errata ID i579
+ */
static struct powerdomain core_3xxx_pre_es3_1_pwrdm = {
IMHO, The above name (and below ones) should be revisited, since
its becoming misleading (even before your patch).
Pre ES3.1 on OMAP3 chips is confusing, since both 3630ES1.0 and
ES1.1 _are_ pre ES3.1.
Not sure if this needs to be taken care before or in this patch..
What do you think?
Regards,
Sergio
.name = core_pwrdm,
.prcm_offs= CORE_MOD,
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES1 |
CHIP_IS_OMAP3430ES2 |
-CHIP_IS_OMAP3430ES3_0),
+CHIP_IS_OMAP3430ES3_0 |
+CHIP_IS_OMAP3630ES1),
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 2,
@@ -97,7 +104,8 @@ static struct powerdomain core_3xxx_pre_
static struct powerdomain core_3xxx_es3_1_pwrdm = {
.name = core_pwrdm,
.prcm_offs= CORE_MOD,
- .omap_chip= OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES3_1),
+ .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES3_1 |
+ CHIP_GE_OMAP3630ES1_1),
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.flags= PWRDM_HAS_HDWR_SAR, /* for USBTLL only */
--
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
--
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][PATCH] board-omap3beagle: Remove duplicate DVI reset gpio handling
Hi Tomi,
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Wednesday, June 30, 2010 3:41 AM
To: Aguirre, Sergio
Cc: linux-omap@vger.kernel.org; Tony Lindgren; Koen Kooi
Subject: Re: [RFC][PATCH] board-omap3beagle: Remove duplicate DVI reset
gpio handling
On Tue, 2010-06-29 at 22:32 +0200, ext Sergio Aguirre wrote:
Following commit missed to remove this:
commit 044d32ffbcb4a1d400088e3575508f46c0a9face
Author: Koen Kooi koen.k...@gmail.com
Date: Thu Apr 22 10:23:42 2010 +0200
board-omap3-beagle: add DSS2 support
Signed-off-by: Sergio Aguirre saagui...@ti.com
Cc: Koen Kooi koen.k...@gmail.com
---
arch/arm/mach-omap2/board-omap3beagle.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-
omap2/board-omap3beagle.c
index 7b95cc1..867a4ad 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -169,6 +169,8 @@ static void __init beagle_display_init(void)
{
int r;
+ omap_mux_init_gpio(beagle_dvi_device.reset_gpio, OMAP_PIN_INPUT);
It's a reset gpio (actually power up/down, if I recall right), it should
be configured as output, shouldn't it?
You're probably right :)
I just shuffled around the same code, which I guessed that works already.
(right beagleboard guys?).
Regards,
Sergio
Tomi
--
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: Boot fail on OMAP3430SDP
Hi Vishwa,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Sripathy, Vishwanath
Sent: Tuesday, June 29, 2010 9:15 AM
To: linux-omap@vger.kernel.org
Subject: RE: Boot fail on OMAP3430SDP
Here is the log from Early printk.
snip
Could not get gpios_ick
Could not get gpios_fck
Probably Tony will be the best to answer this, but... This code shouldn't get
executed I think (the one producing above prints)..
Above clocks are declared for omap2 only (in
arch/arm/mach-omap2/clock24[20,30]_data.c), and even this clk_get calls are
inside of a supposedly omap2 only execution in arch/arm/plat-omap/gpio.c:
static int __init _omap_gpio_init(void)
{
...
...
#if defined(CONFIG_ARCH_OMAP2)
if (cpu_class_is_omap2()) {
gpio_ick = clk_get(NULL, gpios_ick);
if (IS_ERR(gpio_ick))
printk(Could not get gpios_ick\n);
else
clk_enable(gpio_ick);
gpio_fck = clk_get(NULL, gpios_fck);
if (IS_ERR(gpio_fck))
printk(Could not get gpios_fck\n);
else
clk_enable(gpio_fck);
/*
* On 2430 3430 GPIO 5 uses CORE L4 ICLK
*/
#if defined(CONFIG_ARCH_OMAP2430)
if (cpu_is_omap2430()) {
gpio5_ick = clk_get(NULL, gpio5_ick);
if (IS_ERR(gpio5_ick))
printk(Could not get gpio5_ick\n);
else
clk_enable(gpio5_ick);
gpio5_fck = clk_get(NULL, gpio5_fck);
if (IS_ERR(gpio5_fck))
printk(Could not get gpio5_fck\n);
else
clk_enable(gpio5_fck);
}
#endif
}
#endif
...
}
So, I guess your board is trying to get initialized as omap2 somehow...
Regards,
Sergio
snip
--
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: ZOOM2 doesn't boot on upstream kernel
Pnesh, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Neshama Parhoti Sent: Friday, June 25, 2010 9:06 AM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org Subject: Re: ZOOM2 doesn't boot on upstream kernel On Wed, Jun 23, 2010 at 4:03 PM, Ghorai, Sukumar s-gho...@ti.com wrote: [Ghorai] It's working for me. it's good to hear ! This is what I see: ## Booting image at 81c0 ... Image Name: Linux-2.6.35-rc3-1-g945a7eb Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2409672 Bytes = 2.3 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. (and then nothing happens, you don't even see the penguin on the screen) 1. console=ttyS0 are you sure ? all TI's docs state ttyS2 (and this works for me with TI's BSP kernels) but since I don't see the penguin on the screen, I don't think this is the problem The penguin on the screen won't come up, since I don't think that the nec panel drivers for DSS2 has been merged in mainline. The latest patch to get this driver is found here: https://patchwork.kernel.org/patch/101435/ Regards, Sergio snip -- 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] DSS2 Include VRFB into omap2-3build only
Senthil, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Koen Kooi Sent: Monday, May 10, 2010 3:03 AM To: Guruswamy, Senthilvadivu Cc: linux-omap@vger.kernel.org; linux-fbdev-de...@lists.sourceforge.net; t...@atomide.com; tomi.valkei...@nokia.com; Hiremath, Vaibhav Subject: Re: [PATCH] DSS2 Include VRFB into omap2-3build only Op 10 mei 2010, om 10:01 heeft Guruswamy, Senthilvadivu het volgende geschreven: Building a multi-omap kernel is not impacted as long as the display is not choosen in the build. Usually display is chosen from the board file. Solving this problem involves doing these selections in run time, NOT in build time. One of the solutions for this is to provide all this selections as part of some platform driver data. It _should_ be possible to build DSS2, VRFB AND Tiler code at the same time for a multi-omap build, and be executed selectively, depending on your silicon detection and board code execution. If you need to deselect it to succeed, then it's broken for multi-omap builds. That's the core problem and it hasn't been addressed until date. Regards, Sergio So you are saying it *IS* broken when wanting vrfb on omap3 and tiler on omap4, right? -Original Message- From: Koen Kooi [mailto:k...@dominion.thruhere.net] Sent: Monday, May 10, 2010 1:10 PM To: Guruswamy, Senthilvadivu Cc: linux-omap@vger.kernel.org; linux-fbdev-de...@lists.sourceforge.net; t...@atomide.com; tomi.valkei...@nokia.com; Hiremath, Vaibhav Subject: Re: [PATCH] DSS2 Include VRFB into omap2-3build only Op 10 mei 2010, om 08:48 heeft Senthilvadivu Guruswamy het volgende geschreven: Exclude VRFB from OMAP4 onwards and include only for OMAP2 and OMAP3 builds. In OMAP4 VRFB HW IP is replaced with a new HW IP TILER --- a/drivers/video/omap2/Kconfig +++ b/drivers/video/omap2/Kconfig @@ -3,6 +3,10 @@ config OMAP2_VRAM config OMAP2_VRFB bool + depends on FB_OMAP2 (!ARCH_OMAP4) + default y if (ARCH_OMAP2 || ARCH_OMAP3) + help + OMAP VRFB buffer support is efficient for rotation How does this work for multi-omap kernels, e.g. building a kernel with beagle and panda support? regards, Koen -- 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 -- 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: Alternative for defconfig
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Felipe Contreras Sent: Friday, June 11, 2010 8:43 AM To: Nagarajan, Rajkumar Cc: Laurent Pinchart; linux-me...@vger.kernel.org; Hiremath, Vaibhav; linux-omap@vger.kernel.org Subject: Re: Alternative for defconfig On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar x0133...@ti.com wrote: 1. What is the alternative way of submitting defconfig changes/files to LO? I don't think defconfig changes are prohibited now. If I understand correctly, Linus just hates the fact that there is a big percentage of patches for defconfigs. Maybe he wants us to hold these, and better provide higher percentage of actual code changes. What about holding defconfig changes in a separate branch, and just send them for upstream once in a while, specially if there's a big quantity of them in the queue? IMHO, defconfigs are just meant to make us life easier, but changes to them should _never_ be a fix/solution to any problem, and therefore I understand that those aren't a priority over regressions. Regards, Sergio I don't think we have any alternative yet. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Alternative for defconfig
Hi Laurent, -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Friday, June 11, 2010 10:08 AM To: Aguirre, Sergio Cc: Felipe Contreras; Nagarajan, Rajkumar; linux-me...@vger.kernel.org; Hiremath, Vaibhav; linux-omap@vger.kernel.org Subject: Re: Alternative for defconfig Hi Sergio, On Friday 11 June 2010 16:55:07 Aguirre, Sergio wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Felipe Contreras Sent: Friday, June 11, 2010 8:43 AM To: Nagarajan, Rajkumar Cc: Laurent Pinchart; linux-me...@vger.kernel.org; Hiremath, Vaibhav; linux-omap@vger.kernel.org Subject: Re: Alternative for defconfig On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar wrote: 1. What is the alternative way of submitting defconfig changes/files to LO? I don't think defconfig changes are prohibited now. If I understand correctly, Linus just hates the fact that there is a big percentage of patches for defconfigs. Maybe he wants us to hold these, and better provide higher percentage of actual code changes. What about holding defconfig changes in a separate branch, and just send them for upstream once in a while, specially if there's a big quantity of them in the queue? IMHO, defconfigs are just meant to make us life easier, but changes to them should _never_ be a fix/solution to any problem, and therefore I understand that those aren't a priority over regressions. My understanding is that Linus will remove all ARM defconfigs in 2.6.36, unless someone can convince him not to. Board-specific defconfigs won't be allowed anymore, the number of defconfigs needs to be reduced drastically (ideally to one or two only). Hmm, Interesting... We will be now forced to resolve some potential hidden issues with ARM multibuilds (like the ones showing up when creating the omap3_defconfig), and that's a great motivation to nail down all possible portability problems. /me likes that :) Regards, Sergio -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Alternative for defconfig
-Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Friday, June 11, 2010 10:26 AM To: Gadiyar, Anand Cc: Aguirre, Sergio; Felipe Contreras; Nagarajan, Rajkumar; linux- me...@vger.kernel.org; Hiremath, Vaibhav; linux-omap@vger.kernel.org Subject: Re: Alternative for defconfig Hi Anand, On Friday 11 June 2010 17:14:19 Gadiyar, Anand wrote: Laurent Pinchart wrote: On Friday 11 June 2010 16:55:07 Aguirre, Sergio wrote: On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar wrote: 1. What is the alternative way of submitting defconfig changes/files to LO? I don't think defconfig changes are prohibited now. If I understand correctly, Linus just hates the fact that there is a big percentage of patches for defconfigs. Maybe he wants us to hold these, and better provide higher percentage of actual code changes. What about holding defconfig changes in a separate branch, and just send them for upstream once in a while, specially if there's a big quantity of them in the queue? IMHO, defconfigs are just meant to make us life easier, but changes to them should _never_ be a fix/solution to any problem, and therefore I understand that those aren't a priority over regressions. My understanding is that Linus will remove all ARM defconfigs in 2.6.36, unless someone can convince him not to. Board-specific defconfigs won't be allowed anymore, the number of defconfigs needs to be reduced drastically (ideally to one or two only). There is some good work going on on the linux-arm-kernel mailing list to cut down heavily the ARM defconfigs. Would be good to join that discussion. For OMAP, I suppose maintaining omap1_defconfig and omap3_defconfig would suffice to cover all OMAPs? I'm not sure what the exact roadmap will be. Linus is complaining about the defconfig changes taking up too much of the diffstat. I don't know if he will accept patches to solve the problem gradually, or if he will just remove all defconfig files in 2.6.36. In any case, all changes that make it possible to built more machine types and platform types in the same kernel are a step in the right direction. I definitely think that one important step to achieve a multi platform build is to detect the minimal arm_defconfig first, and then (most importantly IMHO) proceed with trying to generate kernel modules of almost all peripherals. Many boards tend to be tested with just monolithic single-platform kernels, and making things modular hasn't been addressed at all in some drivers (old OMAP DSS code, for example). Regards, Sergio -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap_hsmmc: Remove unused state variable
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Thursday, June 10, 2010 1:49 AM To: Aguirre, Sergio Cc: linux-omap@vger.kernel.org; Matt Fleming Subject: Re: [PATCH] omap_hsmmc: Remove unused state variable * Sergio Aguirre saagui...@ti.com [100608 23:35]: This fixes the following warning: drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_suspend': drivers/mmc/host/omap_hsmmc.c:2275: warning: unused variable 'state' Introduced by commit ID: commit 1a13f8fa76c880be41d6b1e6a2b44404bcbfdf9e Author: Matt Fleming m...@console-pimps.org Date: Wed May 26 14:42:08 2010 -0700 mmc: remove the state argument to mmc_suspend_host() The unique usage of this var was removed there, and missed removing the respective declaration aswell. This should be sent to linux-mmc list. Ok, No problem. I will do that now. Thanks and Regards, Sergio Tony Signed-off-by: Sergio Aguirre saagui...@ti.com --- drivers/mmc/host/omap_hsmmc.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index b032828..d50e917 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2272,7 +2272,6 @@ static int omap_hsmmc_suspend(struct device *dev) int ret = 0; struct platform_device *pdev = to_platform_device(dev); struct omap_hsmmc_host *host = platform_get_drvdata(pdev); - pm_message_t state = PMSG_SUSPEND; /* unused by MMC core */ if (host host-suspended) return 0; -- 1.6.3.3 -- 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: [pm-wip/uart][PATCH 2/6] Serial: Add UART4 hwmod data.
From: Kevin Hilman [khil...@deeprootsystems.com] Sent: Monday, May 24, 2010 7:07 PM To: Raja, Govindraj; Aguirre, Sergio Cc: linux-omap@vger.kernel.org Subject: Re: [pm-wip/uart][PATCH 2/6] Serial: Add UART4 hwmod data. Govindraj.R govindraj.r...@ti.com writes: not in my This happening because we are missing these patches: https://patchwork.kernel.org/patch/84748/ https://patchwork.kernel.org/patch/84749/ https://patchwork.kernel.org/patch/84755/ https://patchwork.kernel.org/patch/84750/ Not part of LO yet. But we need these patches for uart4 support for 3630. Ah, OK. I thought these had been merged already. Looks like these need to be refreshed/resubmitted for l-o. Sergio? Ah, I forgot about resubmitting these for the merge window. Got dragged for this last weeks into high priority work and have abandoned them a little bit. :/ I'm in a business trip at this point and I don't have access to the 3630SDP to try this. You can either wait for me to go back and test them, or I can just send them, and somebody else can help me out re-vaidating them, once i rebase and resend. Does that sound ok? Regards, Sergio 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] OMAP: Fix Memory leak
Hi Manjunath,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of G, Manjunath Kondaiah
Sent: Friday, May 21, 2010 1:15 AM
To: linux-omap@vger.kernel.org
Cc: Kumar, Satish; Tony Lindgren; vimal singh
Subject: [PATCH v2] OMAP: Fix Memory leak
The subject prefix doesn't help much to know which OMAP code you're
referring to. Maybe a more proper renaming could be:
omap: iovmm: Fix memory leak
Just do 'git log -p arch/arm/plat-omap/iovmm.c' to see the convention taken so
far.
From: Satish x0124...@ti.com
The memory allocated for sgt structure is not freed on error
when sg_alloc_table is called in sgtable_alloc().
Signed-off-by: Satish Kumar x0124...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: vimal singh vimal.neww...@gmail.com
You're missing here the main code maintainer:
Cc: Hiroshi DOYU hiroshi.d...@nokia.com
I'm looping him in this time.
Regards,
Sergio
---
arch/arm/plat-omap/iovmm.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index e43983b..8ce0de2 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -140,8 +140,10 @@ static struct sg_table *sgtable_alloc(const size_t
bytes, u32 flags)
return ERR_PTR(-ENOMEM);
err = sg_alloc_table(sgt, nr_entries, GFP_KERNEL);
- if (err)
+ if (err) {
+ kfree(sgt);
return ERR_PTR(err);
+ }
pr_debug(%s: sgt:%p(%d entries)\n, __func__, sgt, nr_entries);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH RFC 4/5] omap: 3430sdp: add ohci platform init
Anand,
-Original Message-
From: Gadiyar, Anand
Sent: Friday, April 02, 2010 10:04 AM
To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
Cc: David Brownell; Gregory Clement; Felipe Balbi; Aguirre, Sergio;
Gadiyar, Anand
Subject: [PATCH RFC 4/5] omap: 3430sdp: add ohci platform init
Add platform initialization code for OHCI on the 3430SDP.
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c |7 +++
1 file changed, 7 insertions(+)
Index: linux-2.6/arch/arm/mach-omap2/board-3430sdp.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-3430sdp.c
+++ linux-2.6/arch/arm/mach-omap2/board-3430sdp.c
@@ -675,6 +675,12 @@ static const struct ehci_hcd_omap_platfo
.reset_gpio_port[2] = -EINVAL
};
+static const struct ohci_hcd_omap_platform_data ohci_pdata __initconst =
{
+ .port_mode[0] = OMAP_OHCI_PORT_MODE_UNUSED,
+ .port_mode[1] = OMAP_OHCI_PORT_MODE_UNUSED,
+ .port_mode[2] = OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0,
+};
I just noticed that this patch broke the 3430sdp build for me.
I see following error:
arch/arm/mach-omap2/board-3430sdp.c: In function 'omap_3430sdp_init':
arch/arm/mach-omap2/board-3430sdp.c:840: error: ohci_pdata causes a section
type conflict
Removing the const, to make it similar to ehci struct above it, solves the
problem.
Regards,
Sergio
+
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
@@ -817,6 +823,7 @@ static void __init omap_3430sdp_init(voi
sdp3430_display_init();
enable_board_wakeup_source();
usb_ehci_init(ehci_pdata);
+ usb_ohci_init(ohci_pdata);
}
static void __init omap_3430sdp_map_io(void)
--
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: Old DSS code broken as module (was RE: [PATCH 11/11] omap2/3/4: Disable CONFIG_FB_OMAP in omap3_defconfig)
From: Tony Lindgren [mailto:t...@atomide.com] Sent: Wednesday, May 05, 2010 12:44 PM * Aguirre, Sergio saagui...@ti.com [100505 10:27]: Tony, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Friday, April 30, 2010 3:34 PM To: linux-arm-ker...@lists.infradead.org Cc: linux-omap@vger.kernel.org Subject: [PATCH 11/11] omap2/3/4: Disable CONFIG_FB_OMAP in omap3_defconfig Looks like CONFIG_FB_OMAP prevents somehow mounting root on MMC at least on zoom3 for multi-omap. Disable CONFIG_FB until the omap FB code is fixed. This allows booting omap3_defconfig on various omaps. Tested on 2420-n8x0, 3430-n900, 3630-zoom3 and 4430-blaze. Note that n8x0 still has issues with starting user space because of TLS and VFP. (Looping Tomi) Unfortunately, your patch is uncovering an issue with old DSS code to compile it as module, which I think is caused by this: A single omapfb.ko is attempted to be created in drivers/video/omap/ folder, but the included source files (DSS code + lcd drivers), results in multiple module_init entries added in a single module, and therefore giving errors of duplicate init_module entries between omapfb_main.c and the lcd_*.c files. So, either you disable old DSS driver completely, or you have it as built-in. OK thanks for pointing that out. I'll disable it so we have a booting omap3_defconfig (with the modules compiling). In my local tree, I just have created this simple change, which could be reverted IF old DSS is intended to be used as a module in the future. I don't know how acceptable is to have it officially applied though. Regards, Sergio Regards, Tony 0001-omapfb-Remove-tristate-option-in-Kconfig.patch Description: 0001-omapfb-Remove-tristate-option-in-Kconfig.patch
RE: [Query][omap iommu] Consulting iommu if a physical region is mappable before actually mapping it
Hiroshi, Hari, -Original Message- From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com] Sent: Tuesday, May 04, 2010 12:59 AM To: Aguirre, Sergio Cc: Kanigeri, Hari; linux-omap@vger.kernel.org Subject: Re: [Query][omap iommu] Consulting iommu if a physical region is mappable before actually mapping it From: ext Aguirre, Sergio saagui...@ti.com Subject: RE: [Query][omap iommu] Consulting iommu if a physical region is mappable before actually mapping it Date: Mon, 3 May 2010 21:23:46 +0200 -Original Message- From: Kanigeri, Hari Sent: Monday, May 03, 2010 2:09 PM To: Aguirre, Sergio; Hiroshi DOYU Cc: linux-omap@vger.kernel.org Subject: RE: [Query][omap iommu] Consulting iommu if a physical region is mappable before actually mapping it Sergio, Can the iommu driver be consulted if a certain area (contiguous or not) can be mapped or not, before even trying to do it? -- As long as there are physical pages backing the area it should be mappable right ? Ok, well.. maybe my question was more about that, if the ISP MMU has some kind of limited translation table size, in which it has a limited of pages to map to device addresses that the ISP can use. The need for this is that, in camera, there's a Video4Linux2 IOCTL to know if a certain amount of buffers can be handled (and that includes if they could be mapped or not), even before actually doing the whole allocation/mapping. If there's no limitation in the translation table size, then I guess the only concern is to ensure we have enough free RAM to use. (Which I'll like to think that an userspace resource manager will be able to figure out for the camera application, which is the one allocating the buffers.) Right, currently a whole 4GB address space is available, so virtually no limitation for the translation table size. OK, understood. Sorry if I asked dumb questions, but I'm not an expert on that area. Now I know. :) Thanks a lot for your patience and time! Regards, Sergio -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3] arm: Fix .gitignore for boot/compressed folder
Russell, From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Monday, May 03, 2010 2:59 PM On Mon, May 03, 2010 at 02:51:25PM -0500, Sergio Aguirre wrote: This should complement changes done in: commit e7db7b4270ed2a606b8c0b5f944a5f92ade0e84c Author: Albin Tonnerre albin.tonne...@free-electrons.com Date: Fri Jan 8 14:42:43 2010 -0800 arm: add support for LZO-compressed kernels It missed to do the respective changes in '.gitignore' file. Also, add vmlinux to the list, which is generated also during the build. Signed-off-by: Sergio Aguirre saagui...@ti.com Acked-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de Ok. Thanks! Regards, Sergio -- 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] arm: Fix .gitignore for boot/compressed folder
From: Uwe Kleine-König [mailto:u.kleine-koe...@pengutronix.de] Sent: Sunday, May 02, 2010 7:21 AM On Thu, Feb 25, 2010 at 09:55:45AM -0600, Sergio Aguirre wrote: This should complements changes done in: I think this should read complement only, that is, no 's' at the end. Other than that, Oops, typo fixed. Thanks for noticing that! Also... I added arch/arm/boot/compressed/vmlinux to the list, since when I build for my OMAP3 board, it shows in the dirty index. Is it acceptable to add that aswell? If yes, then attached patch contains your ACK + vmlinux added to the list. Acked-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de Thanks! Regards, Sergio snip 0001-arm-Fix-.gitignore-for-boot-compressed-folder.patch Description: 0001-arm-Fix-.gitignore-for-boot-compressed-folder.patch
RE: [PATCH] arm: Fix .gitignore for boot/compressed folder
-Original Message- From: Uwe Kleine-König [mailto:u.kleine-koe...@pengutronix.de] Sent: Monday, May 03, 2010 1:44 PM On Mon, May 03, 2010 at 10:24:07AM -0500, Aguirre, Sergio wrote: From: Uwe Kleine-König [mailto:u.kleine-koe...@pengutronix.de] Sent: Sunday, May 02, 2010 7:21 AM On Thu, Feb 25, 2010 at 09:55:45AM -0600, Sergio Aguirre wrote: This should complements changes done in: I think this should read complement only, that is, no 's' at the end. Other than that, Oops, typo fixed. Thanks for noticing that! No problem. Also... I added arch/arm/boot/compressed/vmlinux to the list, since when I build for my OMAP3 board, it shows in the dirty index. Is it acceptable to add that aswell? If yes, then attached patch contains your ACK + vmlinux added to the list. This is OK, but IMHO you should note it in the commit log. (And I think most people prefer inline patches over attached ones.) Ok, sure. Will resend inlined patch w/commit description changed. Thanks again. Regards, Sergio -- 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: [Query][omap iommu] Consulting iommu if a physical region is mappable before actually mapping it
-Original Message- From: Kanigeri, Hari Sent: Monday, May 03, 2010 2:09 PM To: Aguirre, Sergio; Hiroshi DOYU Cc: linux-omap@vger.kernel.org Subject: RE: [Query][omap iommu] Consulting iommu if a physical region is mappable before actually mapping it Sergio, Can the iommu driver be consulted if a certain area (contiguous or not) can be mapped or not, before even trying to do it? -- As long as there are physical pages backing the area it should be mappable right ? Ok, well.. maybe my question was more about that, if the ISP MMU has some kind of limited translation table size, in which it has a limited of pages to map to device addresses that the ISP can use. The need for this is that, in camera, there's a Video4Linux2 IOCTL to know if a certain amount of buffers can be handled (and that includes if they could be mapped or not), even before actually doing the whole allocation/mapping. If there's no limitation in the translation table size, then I guess the only concern is to ensure we have enough free RAM to use. (Which I'll like to think that an userspace resource manager will be able to figure out for the camera application, which is the one allocating the buffers.) Please correct me if there's something wrong in my reasoning... Regards, Sergio Thank you, Best regards, Hari -- 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
[Query][omap iommu] Consulting iommu if a physical region is mappable before actually mapping it
Hi Hiroshi, While still maintaining an old camera driver version, which uses your latest iommu driver, we have come up with the following question: Can the iommu driver be consulted if a certain area (contiguous or not) can be mapped or not, before even trying to do it? The reason of this is that, in the camera driver case, we want to let the user know if certain capture buffer area (that will be either allocated in kernel or userspace) can be mapped later on without problems, which could help the user don't even try to allocate the buffers, and avoid a trial-and-error kind of cycle. Is that possible with current driver? If not, how complex do you think it'll be to implement that? Regards, Sergio -- 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] arm: Fix .gitignore for boot/compressed folder
Hi, -Original Message- From: Aguirre, Sergio Sent: Thursday, February 25, 2010 9:56 AM To: linux-arm-ker...@lists.infradead.org Cc: linux-omap@vger.kernel.org; Albin Tonnerre; Russell King; Aguirre, Sergio Subject: [PATCH] arm: Fix .gitignore for boot/compressed folder This should complements changes done in: commit e7db7b4270ed2a606b8c0b5f944a5f92ade0e84c Author: Albin Tonnerre albin.tonne...@free-electrons.com Date: Fri Jan 8 14:42:43 2010 -0800 arm: add support for LZO-compressed kernels It missed to do the respective changes in '.gitignore' file. Any comments on this patch? I see no feedback, and still a dirty index everytime I build... Regards, Sergio Signed-off-by: Sergio Aguirre saagui...@ti.com --- arch/arm/boot/compressed/.gitignore |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/arm/boot/compressed/.gitignore b/arch/arm/boot/compressed/.gitignore index ab204db..bb984af 100644 --- a/arch/arm/boot/compressed/.gitignore +++ b/arch/arm/boot/compressed/.gitignore @@ -1,3 +1,5 @@ font.c -piggy.gz +piggy.gzip +piggy.lzo +lib1funcs.S vmlinux.lds -- 1.6.3.3 -- 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] arm: Fix DEBUG_LL for omap zoom2/3
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Tuesday, March 23, 2010 10:27 AM To: Pais, Allen Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; Pandita, Vikram Subject: Re: [PATCH] arm: Fix DEBUG_LL for omap zoom2/3 * Pais, Allen allen.p...@ti.com [100322 22:42]: With this patch[DEBUG_LL + earlyprintk], I still haven't been able to boot the kernel. Is it working on your side. The commit am using is : a842b5f9ce70e1b738eabb4d719860070180ed1c I think you will also need the 3630 serial fixes series posted recently. I just merged those into omap-fixes-for-linus (and master) branch(es). Maybe give it a try with at commit b3c7740a120c8a7775cb63b4d094466da5c01692 + this patch? Thanks, I'll pull in those fixes. I believe the mux errors are fixed. Have a look at http://dev.omapzoom.org/?p=manju/kernel-omap3- dev.git;a=commit;h=3499f5023ee90dc6ee3868a3147b87fe22a1d9b7 Patch must have been missed some how. OK, we really should get fixes like that to mainline kernel ASAP to avoid duplicating the effort. Hi, Without doing cherry-pick of above patch url (that Allen mentioned), there's an error when trying to get uart4_[i,f]ck clocks during bootup. Is this patch being pushed anywhere already? IMHO, at least it should be on omap-testing, but ideally on omap-fixes-for-linus branch. What do you think? Regards, Sergio Then at least one issue remains for zoom3 to be usable.. I'm getting tons of MMC errors trying to mount root on it: mmcblk1: error -110 transferring data, sector 2097024, nr 8, card status 0x900 end_request: I/O error, dev mmcblk1, sector 2097024 ... Any ideas if that's fixed somewhere also? 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 -- 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: Merge plans for Staging Synaptics Touchscreen Driver
Hi Hemanth, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of V, Hemanth Sent: Tuesday, March 23, 2010 4:29 AM To: pa...@ucw.cz; linux-in...@vger.kernel.org Cc: linux-omap@vger.kernel.org Subject: Merge plans for Staging Synaptics Touchscreen Driver Hi All, Are there any plans to merge the synaptics touchscreen driver (drivers/staging/dream/synaptics_i2c_rmi.c) to drivers/input/touchscreen. We are interested in the same since OMAP3 based Zoom boards use this touchscreen. Can you please elaborate on the specific Synaptics touchscreen chip you're attempting to drive? Unless there's only one synaptic chip that exists... Regards, Sergio Pl add (if required) below tested by for the staging driver. Tested-By: Hemanth V heman...@ti.com Thanks Hemanth -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH RFC 1/5] omap3: add platform init code for OHCI driver
Hi Anand,
I just have a very minor comment, nothing functional :)
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Anand Gadiyar
Sent: Sunday, March 21, 2010 6:32 AM
To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
Cc: Gadiyar, Anand
Subject: [PATCH RFC 1/5] omap3: add platform init code for OHCI driver
Add platform init code for the OMAP3 OHCI driver.
Also, by default add mux-mode changes for all 6 pads for a
given port. This needs to be tailored down depending on the
actual port modes used.
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
arch/arm/mach-omap2/usb-ehci.c| 131
++
arch/arm/plat-omap/include/plat/usb.h | 20 +
2 files changed, 151 insertions(+)
Index: linux-2.6/arch/arm/mach-omap2/usb-ehci.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/usb-ehci.c
+++ linux-2.6/arch/arm/mach-omap2/usb-ehci.c
@@ -236,3 +236,134 @@ void __init usb_ehci_init(const struct e
#endif /* CONFIG_USB_EHCI_HCD */
+#if defined(CONFIG_USB_OHCI_HCD) || defined(CONFIG_USB_OHCI_HCD_MODULE)
+
+static struct resource ohci_resources[] = {
+ {
+ .start = OMAP34XX_OHCI_BASE,
+ .end = OMAP34XX_OHCI_BASE + SZ_1K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP34XX_UHH_CONFIG_BASE,
+ .end= OMAP34XX_UHH_CONFIG_BASE + SZ_1K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP34XX_USBTLL_BASE,
+ .end= OMAP34XX_USBTLL_BASE + SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ { /* general IRQ */
+ .start = INT_34XX_OHCI_IRQ,
+ .flags = IORESOURCE_IRQ,
+ }
+};
+
+/* The dmamask must be set for OHCI to work */
+static u64 ohci_dmamask = ~(u32)0;
+
+static void usb_release(struct device *dev)
+{
+ /* normally not freed */
+}
+
+static struct platform_device ohci_device = {
+ .name = ohci-omap3,
+ .id = 0,
+ .dev = {
+ .release= usb_release,
+ .dma_mask = ohci_dmamask,
+ .coherent_dma_mask = 0x,
+ .platform_data = NULL,
+ },
+ .num_resources = ARRAY_SIZE(ohci_resources),
+ .resource = ohci_resources,
+};
+
+static void setup_ohci_io_mux(enum ohci_omap3_port_mode *port_mode)
+{
+ /* REVISIT: these need to be tailored for each of the modes */
+ switch (port_mode[0]) {
+ case OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0:
+ case OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM:
+ omap_mux_init_signal(mm1_rxdp,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(mm1_rxdm,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(mm1_txse0,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(mm1_rxrcv,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(mm1_txdat,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(mm1_txen_n, OMAP_PIN_OUTPUT);
+ break;
+ case OMAP_OHCI_PORT_MODE_UNUSED:
+ default:
+ /* FALLTHROUGH */
Is this the right place for the fall through comment? I guess you meant
Between 'case OMAP_OHCI_PORT_MODE_UNUSED:' and default: lines...
Anyways, IMHO, as there's no code to execute in default case, maybe it's a bit
unnecessary to state you'll falling through.
+ break;
+ }
+ switch (port_mode[1]) {
+ case OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0:
+ case OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM:
+ omap_mux_init_signal(mm2_rxdp,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(mm2_rxdm,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(mm2_txse0,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(mm2_rxrcv,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(mm2_txdat,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(mm2_txen_n, OMAP_PIN_OUTPUT);
+ break;
+ case OMAP_OHCI_PORT_MODE_UNUSED:
+ default:
+ /* FALLTHROUGH */
Same case here.
+ break;
+ }
+ switch (port_mode[2]) {
+ case OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0:
+ case OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM:
+ omap_mux_init_signal(mm3_rxdp,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(mm3_rxdm,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(mm3_txse0,
+
RE: [PATCH RFC 2/5] usb: ohci: introduce omap3 ohci-hcd driver
Hi Anand, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Anand Gadiyar Sent: Sunday, March 21, 2010 6:32 AM To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org Cc: Gadiyar, Anand Subject: [PATCH RFC 2/5] usb: ohci: introduce omap3 ohci-hcd driver Add support for the OHCI controller present in OMAP3 and newer chips. The code is mostly based off the ehci-omap.c driver. Some of it is common to both drivers and will eventually need to be factored out to platform init files. In its current state, the driver cannot co-exist with the EHCI driver, and this will be fixed in later versions. The second one to be loaded will overwrite settings made by the other. For now, this driver should allow the few users of OMAP3 OHCI to get going. Signed-off-by: Anand Gadiyar gadi...@ti.com --- This driver has been sitting in internal trees for a long time, for no real reason. I've finally found the time to clean it up and submit it for review. drivers/usb/host/ohci-omap3.c | 722 ++ 1 files changed, 722 insertions(+) Index: linux-2.6/drivers/usb/host/ohci-omap3.c === --- /dev/null +++ linux-2.6/drivers/usb/host/ohci-omap3.c @@ -0,0 +1,722 @@ +/* + * ohci-omap3.c - driver for OHCI on OMAP3 and later processors + * + * Bus Glue for OMAP3 USBHOST 3 port OHCI controller + * This controller is also used in later OMAPs and AM35x chips + * + * Copyright (C) 2007-2010 Texas Instruments, Inc. + * Author: Vikram Pandita vikram.pand...@ti.com + * Author: Anand Gadiyar gadi...@ti.com + * + * Based on ehci-omap.c and some other ohci glue layers + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + * TODO (last updated Mar 10th, 2010): + * - add kernel-doc + * - Factor out code common to EHCI to a separate file + * - Make EHCI and OHCI coexist together + * - needs newer silicon versions to actually work + * - the last one to be loaded currently steps on the other's toes + * - Add hooks for configuring transceivers, etc. at init/exit + * - Add aggressive clock-management code + */ + +#include linux/platform_device.h +#include linux/clk.h + +#include plat/usb.h + +/* + * OMAP USBHOST Register addresses: VIRTUAL ADDRESSES + * Use ohci_omap_readl()/ohci_omap_writel() functions + */ + +/* TLL Register Set */ +#define OMAP_USBTLL_REVISION(0x00) +#define OMAP_USBTLL_SYSCONFIG (0x10) +#define OMAP_USBTLL_SYSCONFIG_CACTIVITY (1 8) +#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 3) +#define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 2) +#define OMAP_USBTLL_SYSCONFIG_SOFTRESET (1 1) +#define OMAP_USBTLL_SYSCONFIG_AUTOIDLE (1 0) + +#define OMAP_USBTLL_SYSSTATUS (0x14) +#define OMAP_USBTLL_SYSSTATUS_RESETDONE (1 0) + +#define OMAP_USBTLL_IRQSTATUS (0x18) +#define OMAP_USBTLL_IRQENABLE (0x1C) + +#define OMAP_TLL_SHARED_CONF(0x30) +#define OMAP_TLL_SHARED_CONF_USB_90D_DDR_EN (1 6) +#define OMAP_TLL_SHARED_CONF_USB_180D_SDR_EN(1 5) +#define OMAP_TLL_SHARED_CONF_USB_DIVRATION (1 2) +#define OMAP_TLL_SHARED_CONF_FCLK_REQ (1 1) +#define OMAP_TLL_SHARED_CONF_FCLK_IS_ON (1 0) + +#define OMAP_TLL_CHANNEL_CONF(num) (0x040 + 0x004 * num) +#define OMAP_TLL_CHANNEL_CONF_FSLSMODE_SHIFT 24 +#define OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF(1 11) +#define OMAP_TLL_CHANNEL_CONF_ULPI_ULPIAUTOIDLE (1 10) +#define OMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE (1 9) +#define OMAP_TLL_CHANNEL_CONF_ULPIDDRMODE (1 8) +#define OMAP_TLL_CHANNEL_CONF_CHANMODE_FSLS (1 1) +#define OMAP_TLL_CHANNEL_CONF_CHANEN(1 0) + +#define OMAP_TLL_CHANNEL_COUNT
RE: [PATCH 0/7] omap3: serial code for 3630 and zoom2/3 fixes
Tony, Please find attached pull request for your convenience. Regards, Sergio -Original Message- From: Aguirre, Sergio Sent: Friday, March 12, 2010 2:00 PM To: Tony Lindgren Cc: linux-omap@vger.kernel.org; Kevin Hilman; Pandita, Vikram; Paul Walmsley; Felipe Balbi; Aguirre, Sergio Subject: [PATCH 0/7] omap3: serial code for 3630 and zoom2/3 fixes Hi, This series contains fixes for omap2/3/4 serial code, and are fixing: - Avoid doing ioremapp of a zero-based physical address. (causing a kernel panic during early init on 3630boards) - Unproper omap_revision check during uart globals setup. (omap_revision is not yet filled at that point) - Don't try to enable all uarts generically for zoom2/3 and 3630sdp. - Make zoom2/3 just register one serial port (ttyS0). This is a subset of the original series found here: [1] Thanks to: - Vikram Pandita - Paul Walmsley - Kevin Hilman - Manjunath Kondaiah - Felipe Balbi - Tony Lindgreen For all the feedback recieved so far. Regards, Sergio Sergio Aguirre (7): OMAP3: serial: Check for zero-based physical addr OMAP3: serial: Use dev_* macros instead of printk omap2/3/4: serial: Remove condition for getting uart4_phys omap3: zoom2/3 / 3630sdp: Don't init always all uarts omap3: 3630sdp: Explicitly enable all UARTs omap3: zoom 2/3: Change debugboard serial port id omap3: zoom2/3: Register only 1 8250 port arch/arm/configs/omap_zoom2_defconfig|2 +- arch/arm/configs/omap_zoom3_defconfig|2 +- arch/arm/mach-omap2/board-3630sdp.c |1 + arch/arm/mach-omap2/board-zoom-debugboard.c |2 +- arch/arm/mach-omap2/board-zoom-peripherals.c |1 - arch/arm/mach-omap2/serial.c | 35 + 6 files changed, 22 insertions(+), 21 deletions(-) [1] http://marc.info/?l=linux-omapm=126826639903105w=2 The following changes since commit a842b5f9ce70e1b738eabb4d719860070180ed1c: Tony Lindgren (1): Revert omap: Add DSI regulator supply to OMAP3EVM board file are available in the git repository at: git://dev.omapzoom.org/pub/scm/saaguirre/linux-omap-camera.git omap-fixes Sergio Aguirre (7): OMAP3: serial: Check for zero-based physical addr OMAP3: serial: Use dev_* macros instead of printk omap2/3/4: serial: Remove condition for getting uart4_phys omap3: zoom2/3 / 3630sdp: Don't init always all uarts omap3: 3630sdp: Explicitly enable all UARTs omap3: zoom 2/3: Change debugboard serial port id omap3: zoom2/3: Register only 1 8250 port arch/arm/configs/omap_zoom2_defconfig|2 +- arch/arm/configs/omap_zoom3_defconfig|2 +- arch/arm/mach-omap2/board-3630sdp.c |1 + arch/arm/mach-omap2/board-zoom-debugboard.c |2 +- arch/arm/mach-omap2/board-zoom-peripherals.c |1 - arch/arm/mach-omap2/serial.c | 35 + 6 files changed, 22 insertions(+), 21 deletions(-)
RE: [PATCH 0/7] omap3: serial code for 3630 and zoom2/3 fixes
From: Tony Lindgren [mailto:t...@atomide.com] Sent: Monday, March 15, 2010 5:49 PM snip OK, thanks. One more thing: Please repost your fixes one more time with LAKML Cc'd for review. Then assuming no more comments, I'll merge them into omap-fixes-for-linus. Done. Meanwhile, I'll merge it into l-o master branch for testing. Ok, thanks. Regards, Sergio 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: [RFC part1/2 merge v4][PATCH 00/11] omap2/3/4: uart4 fixes + zoom2/3 changes
From: Aguirre, Sergio Sent: Wednesday, March 10, 2010 6:14 PM Hi, This is v4 of my serial work series merge found here: [1]. And it's meant to be applied on top of Thomas's patch: [2] Changelog compared to previous version: - Changed printk to dev_* macros (Thanks Felipe) Please let me know your comments and thoughts. Thanks to: - Vikram Pandita - Paul Walmsley - Kevin Hilman - Manjunath Kondaiah - Felipe Balbi For the feedback recieved so far. I really appreciate it. Regards, Sergio Tony, Should I take out the new code, and just send you the fixes necessary to boot the zoom3, without adding uart4 support? Or what do you recommend about this patchseries? Regards, Sergio snip [1] http://marc.info/?l=linux-omapm=126815136710361w=2 [2] http://marc.info/?l=linux-kernelm=126709078514087w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC part1/2 merge v4][PATCH 00/11] omap2/3/4: uart4 fixes + zoom2/3 changes
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, March 12, 2010 11:34 AM To: Aguirre, Sergio Cc: Kevin Hilman; Pandita, Vikram; Paul Walmsley; Felipe Balbi; linux- o...@vger.kernel.org Subject: Re: [RFC part1/2 merge v4][PATCH 00/11] omap2/3/4: uart4 fixes + zoom2/3 changes * Aguirre, Sergio saagui...@ti.com [100312 09:18]: From: Aguirre, Sergio Sent: Wednesday, March 10, 2010 6:14 PM Hi, This is v4 of my serial work series merge found here: [1]. And it's meant to be applied on top of Thomas's patch: [2] snip Tony, Should I take out the new code, and just send you the fixes necessary to boot the zoom3, without adding uart4 support? Yes please. The series looks good to me, but is also a bit intrusive for the -rc series :) So please split it into fixes for 2.6.34 -rc, and new code for 2.6.35 merge window. I got the [2] below already queued. Ok, so, I'll just drop patches 4, 5, 6, 7 then test and resend. Regards, Sergio Regards, Tony snip [1] http://marc.info/?l=linux-omapm=126815136710361w=2 [2] http://marc.info/?l=linux-kernelm=126709078514087w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] arm: Fix .gitignore for boot/compressed folder
From: Aguirre, Sergio Sent: Thursday, February 25, 2010 9:56 AM This should complements changes done in: commit e7db7b4270ed2a606b8c0b5f944a5f92ade0e84c Author: Albin Tonnerre albin.tonne...@free-electrons.com Date: Fri Jan 8 14:42:43 2010 -0800 arm: add support for LZO-compressed kernels It missed to do the respective changes in '.gitignore' file. Hi, I did not receive any reply about this patch so far. - Is it acceptable? - Should I resend it somewhere else? Regards, Sergio Signed-off-by: Sergio Aguirre saagui...@ti.com --- arch/arm/boot/compressed/.gitignore |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/arm/boot/compressed/.gitignore b/arch/arm/boot/compressed/.gitignore index ab204db..bb984af 100644 --- a/arch/arm/boot/compressed/.gitignore +++ b/arch/arm/boot/compressed/.gitignore @@ -1,3 +1,5 @@ font.c -piggy.gz +piggy.gzip +piggy.lzo +lib1funcs.S vmlinux.lds -- 1.6.3.3 -- 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: compile break on dss2 branch for zoom3
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Gadiyar, Anand Sent: Thursday, March 11, 2010 5:48 AM To: Tomi Valkeinen; Y, Kishore Cc: linux-omap@vger.kernel.org Subject: RE: compile break on dss2 branch for zoom3 Tomi Valkeinen wrote: On Thu, 2010-03-11 at 12:40 +0100, ext Y, Kishore wrote: Hi Tomi, I am unable to compile dss2 tree for zoom3. Commit I am using following commit id 893d461b538e889da350061edaadeb8a9289913c OMAP: DSS2: quick hack for set mode Error I see is related to usb:- drivers/usb/core/hcd.c: In function 'usb_hcd_resume_root_hub': drivers/usb/core/hcd.c:1892: error: 'pm_wq' undeclared (first use in this function) drivers/usb/core/hcd.c:1892: error: (Each undeclared identifier is reported only once drivers/usb/core/hcd.c:1892: error: for each function it appears in.) make[3]: *** [drivers/usb/core/hcd.o] Error 1 make[2]: *** [drivers/usb/core] Error 2 make[1]: *** [drivers/usb] Error 2 make: *** [drivers] Error 2 When I disable usb, build goes through but the board does not bootup with this image. It is stuck at uncompressing linux. Yes, mainstream linux tree seems to be broken. Not much I can do to help you there. You can try rebasing on top of later mainstrean version, perhaps it's been fixed there. I sent this patch [1] to linux-usb to fix this. It's yet to be queued up. The alternative is to enable CONFIG_PM_RUNTIME in the build. This fix is in current linux-omap master branch as: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commitdiff;h=873f7381a049e3814e01d44ba7f12ff13d4653b1 Who's patch is going upstream? Tony's or yours? :) Regards, Sergio Regards, Anand [1] http://marc.info/?l=linux-usbm=126675883221098w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: compile break on dss2 branch for zoom3
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Y, Kishore Sent: Thursday, March 11, 2010 7:29 AM To: Y, Kishore; Gadiyar, Anand; Tomi Valkeinen Cc: linux-omap@vger.kernel.org Subject: RE: compile break on dss2 branch for zoom3 -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Y, Kishore Sent: Thursday, March 11, 2010 5:23 PM To: Gadiyar, Anand; Tomi Valkeinen Cc: linux-omap@vger.kernel.org Subject: RE: compile break on dss2 branch for zoom3 -Original Message- From: Gadiyar, Anand Sent: Thursday, March 11, 2010 5:18 PM To: Tomi Valkeinen; Y, Kishore Cc: linux-omap@vger.kernel.org Subject: RE: compile break on dss2 branch for zoom3 Tomi Valkeinen wrote: On Thu, 2010-03-11 at 12:40 +0100, ext Y, Kishore wrote: Hi Tomi, I am unable to compile dss2 tree for zoom3. Commit I am using following commit id 893d461b538e889da350061edaadeb8a9289913c OMAP: DSS2: quick hack for set mode Error I see is related to usb:- drivers/usb/core/hcd.c: In function 'usb_hcd_resume_root_hub': drivers/usb/core/hcd.c:1892: error: 'pm_wq' undeclared (first use in this function) drivers/usb/core/hcd.c:1892: error: (Each undeclared identifier is reported only once drivers/usb/core/hcd.c:1892: error: for each function it appears in.) make[3]: *** [drivers/usb/core/hcd.o] Error 1 make[2]: *** [drivers/usb/core] Error 2 make[1]: *** [drivers/usb] Error 2 make: *** [drivers] Error 2 When I disable usb, build goes through but the board does not bootup with this image. It is stuck at uncompressing linux. Yes, mainstream linux tree seems to be broken. Not much I can do to help you there. You can try rebasing on top of later mainstrean version, perhaps it's been fixed there. I sent this patch [1] to linux-usb to fix this. It's yet to be queued up. The alternative is to enable CONFIG_PM_RUNTIME in the build. Regards, Anand [1] http://marc.info/?l=linux-usbm=126675883221098w=2 I will try this out. I have tried to use the main line which already has this patch. I am able to compile the code without any issues. But board still does not boot. Am I missing something? My bootargs: setenv bootargs console=ttyS3,115200n8 noinitrd root=/dev/nfs rw nfsroot=192.168.223.72:/home/x0114913/fs1_inc2_rc0,nolock,rsize=1024,wsize =1024 rootdelay=0 ip=192.168.223.251 debug Can you take this series: http://marc.info/?l=linux-omapm=126826639903105w=2 And test with ttyS0? Regards, Sergio -- 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 -- 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 -- 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 12/19] omap: Fix gpio_resume_after_retention
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Thursday, March 11, 2010 5:57 PM To: Aguirre, Sergio Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 12/19] omap: Fix gpio_resume_after_retention * Aguirre, Sergio saagui...@ti.com [100311 15:47]: Hi Tony, -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Thursday, March 11, 2010 5:49 PM To: linux-arm-ker...@lists.infradead.org Cc: Aguirre, Sergio; linux-omap@vger.kernel.org Subject: [PATCH 12/19] omap: Fix gpio_resume_after_retention From: Tony Lindgren Aguirre Something funky mix happened with the authorship here :) Should be: From: Sergio Aguirre saagui...@ti.com Thanks, updated patch below. I think this issue is related to applying patches from patchwork.kernel.org with email addresses in Lastname, Firstname format.. Hmm... I see. I normally send my patches with this alias: alias gsend='git send-email --smtp-server /usr/bin/msmtp --from Sergio Aguirre saagui...@ti.com --envelope-sender=Sergio Aguirre saagui...@ti.com' and then just do: gsend --to='linux-omap@vger.kernel.org' patches/forLO_20100311/0001-mypatch.patch But somehow the patch ends up (I'm guessing through TI LDAP server) changing that to Aguirre, Sergio... and also Patchworks seems to continue display my old fullname: Aguirre Rodriguez, Sergio Alberto... I guess it's in a static data cache somewhere, maybe? Does anyone know how to overcome this kind of scenario, and force what --from param says? Regards, Sergio 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
Is git.kernel.org down?
Hi, Just wondering if anyone is experiencing the inability to access git.kernel.org server... I'm getting a 504 Gateway timeout, but I'm not sure if it's just me.. Regards, Sergio -- 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: Snipping irrelevant text from a discussion (was: RE: [PATCH 15/16] OMAP3: PM: VP force update method of voltage scaling)
Hi, From: Felipe Balbi [mailto:felipe.ba...@nokia.com] Sent: Tuesday, March 09, 2010 12:52 AM On Tue, Mar 09, 2010 at 02:42:36AM +0100, ext Tony Lindgren wrote: After a quick search for mailing list netiquette I cam up with the following links: http://linux.sgms-centre.com/misc/netiquette.php http://en.opensuse.org/OpenSUSE_mailing_list_netiquette We can add that to some of the wiki pages so people can start following the proper standards. Anybody got better links? How about this ? http://en.wikipedia.org/wiki/Top_posting#Interleaved_style it explains all the posting styles but we want the interleaved style or inline reply without top-posting. I think that many things can be inherited from LKML FAQ about Mailing list questions: http://www.kernel.org/pub/linux/docs/lkml/#ss3 But it might be a good idea to have a linux-omap specific wiki with a FAQ section aswell, with the above answers adapted to it (some of the lkml answers might not directly apply). Anyways, just a thought. Regards, Sergio -- balbi -- 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 part1/2 merge v3][PATCH 01/10] OMAP3: serial: Check for zero-based physical addr
Hi Felipe,
From: Felipe Balbi [mailto:m...@felipebalbi.com]
Sent: Tuesday, March 09, 2010 10:21 AM
On Tue, Mar 09, 2010 at 10:16:45AM -0600, Sergio Aguirre wrote:
@@ -664,6 +664,12 @@ void __init omap_serial_early_init(void)
struct device *dev = pdev-dev;
struct plat_serial8250_port *p = dev-platform_data;
+ /* Don't map zero-based physical address */
+ if (p-mapbase == 0) {
+ printk(KERN_WARNING omap serial: No physical address
+ for uart#%d, so skipping early_init...\n, i);
+ continue;
you have a *dev available, could you use some of the dev_* macros ? Then
it's easy to know from where the message come from.
Ok, I didn't do that, since there are other printks in the same function.
I can change it here, no problem.
I guess I can add a separate patch to standardize and change all
printks to dev_* macros... would that make sense?
@@ -727,6 +733,14 @@ void __init omap_serial_init_port(int port)
pdev = uart-pdev;
dev = pdev-dev;
+ /* Don't proceed if there's no clocks available */
+ if (unlikely(!uart-ick || !uart-fck)) {
+ printk(KERN_ERR Can't init uart%d, no clocks available\n,
+ port);
+ WARN_ON(1);
change printk() + WARN_ON() into:
WARN(1, %s: can't init uart%d, no clocks available\n,
koject_name(dev-kobj), port);
That looks nicer. Thanks!
Regards,
Sergio
--
balbi
--
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 part1/2 merge v3][PATCH 00/10] omap2/3/4: uart4 fixes + zoom2/3 changes
Hi, On a general note. To avoid spamming with frequent resends and version changes, I'll better wait for any of you to review it today, and tomorrow I'll resend, grouping all comments I'll receive today. Thanks for your attention, comments and time! Regards, Sergio -Original Message- From: Aguirre, Sergio Sent: Tuesday, March 09, 2010 10:17 AM To: linux-omap@vger.kernel.org Cc: Kevin Hilman; Pandita, Vikram; Paul Walmsley; Tony Lindgren; Felipe Balbi; Aguirre, Sergio Subject: [RFC part1/2 merge v3][PATCH 00/10] omap2/3/4: uart4 fixes + zoom2/3 changes Hi, This is v3 of my serial work series merge found here: [1]. And it's meant to be applied on top of Thomas's patch: [2] Changelog compared to previous version: - Added WARN_ON when no clocks acquired for a uart to be initialized. (Thanks Felipe and Kevin) - Added missing patch description to patch: OMAP3: PRCM: Consider UART4 for 3630 chip in prcm_setup_regs - Replaced unexisting word initted - initialized (Thanks Kevin) Please let me know your comments and thoughts. Thanks to: - Vikram Pandita - Paul Walmsley - Kevin Hilman - Manjunath Kondaiah - Felipe Balbi For the feedback recieved so far. I really appreciate it. Regards, Sergio Detailed changelog: Sergio Aguirre (10): OMAP3: serial: Check for zero-based physical addr omap2/3/4: serial: Remove condition for getting uart4_phys ARM: OMAP3630: PRCM: Add UART4 control bits OMAP clock: Add uart4_ick/fck definitions for 3630 OMAP3: PRCM: Consider UART4 for 3630 chip in prcm_setup_regs omap3: serial: Fix uart4 handling for 3630 omap3: zoom2/3 / 3630sdp: Don't init always all uarts omap3: 3630sdp: Explicitly enable all UARTs omap3: zoom 2/3: Change debugboard serial port id omap3: zoom2/3: Register only 1 8250 port arch/arm/configs/omap_zoom2_defconfig|2 +- arch/arm/configs/omap_zoom3_defconfig|2 +- arch/arm/mach-omap2/board-3630sdp.c |1 + arch/arm/mach-omap2/board-zoom-debugboard.c |2 +- arch/arm/mach-omap2/board-zoom-peripherals.c |1 - arch/arm/mach-omap2/clock3xxx_data.c | 22 +++ arch/arm/mach-omap2/cm-regbits-34xx.h|2 + arch/arm/mach-omap2/pm34xx.c |8 - arch/arm/mach-omap2/prcm-common.h|4 +++ arch/arm/mach-omap2/serial.c | 37 - - arch/arm/plat-omap/include/plat/irqs.h |2 + 11 files changed, 63 insertions(+), 20 deletions(-) mode change 100755 = 100644 arch/arm/mach-omap2/board-3630sdp.c mode change 100755 = 100644 arch/arm/mach-omap2/board-zoom-peripherals.c [1] http://marc.info/?l=linux-omapm=126806929506991w=2 [2] http://marc.info/?l=linux-kernelm=126709078514087w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V4] OMAP: DSS: Add NEC NL8048HL11-01B display panel
Hi Kishore, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Y, Kishore Sent: Saturday, March 06, 2010 8:17 AM To: Tomi Valkeinen Cc: linux-omap@vger.kernel.org Subject: [PATCH V4] OMAP: DSS: Add NEC NL8048HL11-01B display panel From: Erik Gilling konk...@android.com Date: Wed, 2 Dec 2009 22:05:34 +0530 Subject: [PATCH] OMAP: DSS: Add NEC NL8048HL11-01B display panel NEC WVGA LCD NL8048HL11-01B support has been added. I think this driver is out-of-date after the OMAP DSS2 model restructuring patch series got merged: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg23491.html At least I see this error happening: snip$ make ARCH=arm -j4 uImage /dev/null drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c: In function 'nec_8048_panel_probe': drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c:55: error: 'struct anonymous' has no member named 'recommended_bpp' make[4]: *** [drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.o] Error 1 make[3]: *** [drivers/video/omap2/displays] Error 2 make[3]: *** Waiting for unfinished jobs make[2]: *** [drivers/video/omap2] Error 2 make[1]: *** [drivers/video] Error 2 make: *** [drivers] Error 2 Which is firing after applying this patch: OMAP: DSS2: move get_recommended_bpp() So, I guess you have to rework the panel driver to make it work with latest linux-omap master branch. Regards, Sergio -- 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 part1/2 merge][PATCH 06/10] omap3: serial: Fix uart4 handling for 3630
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio Sent: Friday, March 05, 2010 5:12 PM To: Kevin Hilman Cc: linux-omap@vger.kernel.org Subject: RE: [RFC part1/2 merge][PATCH 06/10] omap3: serial: Fix uart4 handling for 3630 From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, March 05, 2010 4:38 PM snip @@ -694,6 +698,10 @@ void __init omap_serial_early_init(void) if (cpu_is_omap44xx()) p-irq += 32; + + /* IRQ for UART4 in omap3630 is 80 */ + if (cpu_is_omap3630() (i == 3)) + p-irq = 80; Should add a symbolic name to irqs.h and use it here, instead of hard-coded constant. Sounds like a nice idea! Thanks! I'll update the patchset and resend. Actually, I have been thinking on a patch to remove all magic numbering, also for OMAP4... I'll think about it and include it in the next version. Regards, Sergio Regards, Sergio 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 -- 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 part1/2 merge][PATCH 06/10] omap3: serial: Fix uart4 handling for 3630
From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Monday, March 08, 2010 10:52 AM Aguirre, Sergio saagui...@ti.com writes: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio Sent: Friday, March 05, 2010 5:12 PM To: Kevin Hilman Cc: linux-omap@vger.kernel.org Subject: RE: [RFC part1/2 merge][PATCH 06/10] omap3: serial: Fix uart4 handling for 3630 From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, March 05, 2010 4:38 PM snip @@ -694,6 +698,10 @@ void __init omap_serial_early_init(void) if (cpu_is_omap44xx()) p-irq += 32; + + /* IRQ for UART4 in omap3630 is 80 */ + if (cpu_is_omap3630() (i == 3)) + p-irq = 80; Should add a symbolic name to irqs.h and use it here, instead of hard-coded constant. Sounds like a nice idea! Thanks! I'll update the patchset and resend. Actually, I have been thinking on a patch to remove all magic numbering, also for OMAP4... I'll think about it and include it in the next version. Don't spend too much time on this. Soon, this serial core will be converted over to hwmod (RFC patches already posted) so all the IRQ and base address stuff will be handled by hwmod. Hmm... ok, thanks for clarifying that. Then I won't touch anything that my original series doesn't cover. I'll just use this define for 3630 as you originally suggested here, and resend. Regards, sergio 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: [RFC part1/2 merge v2][PATCH 00/11] omap2/3/4: uart4 fixes + zoom2/3 changes
-Original Message- From: Aguirre, Sergio Sent: Monday, March 08, 2010 11:21 AM To: linux-omap@vger.kernel.org Cc: Kevin Hilman; Pandita, Vikram; Paul Walmsley; Tony Lindgren; Aguirre, Sergio Subject: [RFC part1/2 merge v2][PATCH 00/11] omap2/3/4: uart4 fixes + zoom2/3 changes Hi, This is v2 of my serial work series merge found here: [1] And it's meant to be applied on top of Thomas's patch: [2] Changelog compared to previous version: - Replaced hardcoded IRQ for UART4 in 3630 by newly created INT_36XX_UART4_IRQ define. (Thanks Kevin) Oops, sent a wrong past internal revision... sorry for the spam, but I'll resend with the correction. Regards, Sergio -- 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 part1/2 merge v2 RESEND][PATCH 05/10] OMAP3: PRCM: Consider UART4 for 3630 chip in prcm_setup_regs
From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Monday, March 08, 2010 11:56 AM Sergio Aguirre saagui...@ti.com writes: Signed-off-by: Sergio Aguirre saagui...@ti.com This one needs a descriptive changelog. Agreed. Will fix. Regards, Sergio snip -- 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 part1/2 merge v2 RESEND][PATCH 09/10] omap3: zoom 2/3: Change debugboard serial port id
From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Monday, March 08, 2010 11:59 AM Sergio Aguirre saagui...@ti.com writes: This is now changed to PLAT8250_DEV_PLATFORM (= 0), because it is the only port that's going to be initted in Zoom 2/3 boards. ^^^ minor nit: not a word. :) please use the much harder to spell: initialized. ;) :) Ok. Will fix. Thanks and Regards, Sergio Kevin snip -- 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 part1/2 merge v2 RESEND][PATCH 01/10] OMAP3: serial: Check for zero-based physical addr
-Original Message- From: Felipe Balbi [mailto:m...@felipebalbi.com] Sent: Monday, March 08, 2010 12:25 PM To: Aguirre, Sergio Cc: linux-omap@vger.kernel.org; Kevin Hilman; Pandita, Vikram; Paul Walmsley; Tony Lindgren Subject: Re: [RFC part1/2 merge v2 RESEND][PATCH 01/10] OMAP3: serial: Check for zero-based physical addr On Mon, Mar 08, 2010 at 11:28:43AM -0600, Sergio Aguirre wrote: @@ -727,6 +733,10 @@ void __init omap_serial_init_port(int port) pdev = uart-pdev; dev = pdev-dev; + /* Don't proceed if there's no clocks available */ + if (!uart-ick || !uart-fck) + return; with that loop getting the clocks I would expect this not to happen. If it happens, then I would guess it deserves a BUG_ON(!uart-ick || !uart-fck) Yeah, makes sense. Will fix. Thanks, Sergio -- balbi -- 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 part1/2 merge v2 RESEND][PATCH 04/10] OMAP clock: Add uart4_ick/fck definitions for 3630
-Original Message-
From: Felipe Balbi [mailto:m...@felipebalbi.com]
Sent: Monday, March 08, 2010 12:29 PM
To: Aguirre, Sergio
Cc: linux-omap@vger.kernel.org; Kevin Hilman; Pandita, Vikram; Paul
Walmsley; Tony Lindgren
Subject: Re: [RFC part1/2 merge v2 RESEND][PATCH 04/10] OMAP clock: Add
uart4_ick/fck definitions for 3630
On Mon, Mar 08, 2010 at 11:28:46AM -0600, Sergio Aguirre wrote:
@@ -3420,6 +3440,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, per_96m_fck, per_96m_fck, CK_3XXX),
CLK(NULL, per_48m_fck, per_48m_fck, CK_3XXX),
CLK(NULL, uart3_fck,uart3_fck, CK_3XXX),
+ CLK(NULL, uart4_fck,uart4_fck, CK_36XX),
CLK(NULL, gpt2_fck, gpt2_fck, CK_3XXX),
CLK(NULL, gpt3_fck, gpt3_fck, CK_3XXX),
CLK(NULL, gpt4_fck, gpt4_fck, CK_3XXX),
@@ -3443,6 +3464,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, gpio2_ick,gpio2_ick, CK_3XXX),
CLK(NULL, wdt3_ick, wdt3_ick, CK_3XXX),
CLK(NULL, uart3_ick,uart3_ick, CK_3XXX),
+ CLK(NULL, uart4_ick,uart4_ick, CK_36XX),
are the uart clocks shared ? Why not defining the devname here if
they're not ? We would loop less to find the clock that way.
I think I'll better wait for hwmod changes, since seems this could change.
(Kevin, correct me if I'm wrong.)
Anyways, maybe this needs to be handled by a separate patch, to assign all uart
clocks, from 1 to 4, to a specific device.
Regards,
Sergio
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/4] DSS2: clear spurious SYNC_LOST_DIGIT interrupts
Hi Ville,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of ville.syrj...@nokia.com
Sent: Friday, March 05, 2010 7:26 AM
To: Tomi Valkeinen
Cc: linux-fb...@vger.kernel.org; linux-omap@vger.kernel.org; Ville Syrjälä
Subject: [PATCH 4/4] DSS2: clear spurious SYNC_LOST_DIGIT interrupts
From: Ville Syrjälä ville.syrj...@nokia.com
When DSS transitions from off mode to on VENC may generate a spurious
SYNC_LOST_DIGIT error. Just ack it when restoring the context. Also
restore IRQENABLE last to avoid triggering interrupts before the
context is fully restored.
(Tomi or anyone can correct me if I'm wrong)
AFAIK, The solution for spurious interrupts is to flush posted bus writes
during interrupt handling, which can be achieved by reading the same register
just after you have written it.
Tomi, what do you think?
Regards,
Sergio
Signed-off-by: Ville Syrjälä ville.syrj...@nokia.com
---
drivers/video/omap2/dss/dispc.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c
b/drivers/video/omap2/dss/dispc.c
index e777e35..b8c1603 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -335,7 +335,7 @@ void dispc_save_context(void)
void dispc_restore_context(void)
{
RR(SYSCONFIG);
- RR(IRQENABLE);
+ /*RR(IRQENABLE);*/
/*RR(CONTROL);*/
RR(CONFIG);
RR(DEFAULT_COLOR0);
@@ -472,6 +472,15 @@ void dispc_restore_context(void)
/* enable last, because LCD DIGIT enable are here */
RR(CONTROL);
+
+ /* clear spurious SYNC_LOST_DIGIT interrupts */
+ dispc_write_reg(DISPC_IRQSTATUS, DISPC_IRQ_SYNC_LOST_DIGIT);
+
+ /*
+ * enable last so IRQs won't trigger before
+ * the context is fully restored
+ */
+ RR(IRQENABLE);
}
#undef SR
--
1.6.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/4] DSS2: clear spurious SYNC_LOST_DIGIT interrupts
-Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Friday, March 05, 2010 9:25 AM To: Aguirre, Sergio Cc: Syrjala Ville (Nokia-D/Helsinki); linux-fb...@vger.kernel.org; linux- o...@vger.kernel.org Subject: RE: [PATCH 4/4] DSS2: clear spurious SYNC_LOST_DIGIT interrupts On Fri, 2010-03-05 at 16:19 +0100, ext Aguirre, Sergio wrote: Hi Ville, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of ville.syrj...@nokia.com Sent: Friday, March 05, 2010 7:26 AM To: Tomi Valkeinen Cc: linux-fb...@vger.kernel.org; linux-omap@vger.kernel.org; Ville Syrjälä Subject: [PATCH 4/4] DSS2: clear spurious SYNC_LOST_DIGIT interrupts From: Ville Syrjälä ville.syrj...@nokia.com When DSS transitions from off mode to on VENC may generate a spurious SYNC_LOST_DIGIT error. Just ack it when restoring the context. Also restore IRQENABLE last to avoid triggering interrupts before the context is fully restored. (Tomi or anyone can correct me if I'm wrong) AFAIK, The solution for spurious interrupts is to flush posted bus writes during interrupt handling, which can be achieved by reading the same register just after you have written it. Tomi, what do you think? That's a different spurious interrupt =). In this case the IRQ mechanism from CPU side is working fine, but VENC is just spamming the error interrupts, for unknown reason. Ohh ok, I see. Thanks for clarifying. And sorry for the noise. I'm trying to learn about DSS subsystem, but I'm just a n00b for the moment :) Regards, Sergio Tomi -- 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
Snipping irrelevant text from a discussion (was: RE: [PATCH 15/16] OMAP3: PM: VP force update method of voltage scaling)
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Felipe Contreras Sent: Friday, March 05, 2010 10:23 AM On Fri, Mar 5, 2010 at 5:30 PM, Gopinath, Thara th...@ti.com wrote: I have been putting Regards Thara at the end of my comments precisely so that people do not have to scroll down and waste their bandwidth. I have seen this as an accepted practice in the mailing list through observing mails from other experts. This is what messages from other experts look like: Peter Zijlstra http://article.gmane.org/gmane.linux.kernel/958012 Alan Cox http://article.gmane.org/gmane.linux.kernel/958009 Andrew Morton http://article.gmane.org/gmane.linux.kernel/957749 Thomas Gleixner http://article.gmane.org/gmane.linux.kernel/957657 Linus Torvalds http://article.gmane.org/gmane.linux.kernel/529672 And this is what yours look like (nothing like them): http://article.gmane.org/gmane.linux.ports.arm.omap/32334 The fact that other people do it (mostly from TI), doesn't mean that it's an *accepted* practice, but I guess it's much easier for me to just filter these messages. Although I'm pretty sure other people find them annoying, I'll push for that in some later time. Hey! You guys take a chill pill, ok? :) Let's not start shouting at people and point fingers. My 2 cents is that, usually, when discussion starts about a topic, or a specific parts of code, you should remove irrelevant text, and substitute by a snip line, just to give reference that some irrelevant text used to be there... so if you're interested, just jump to the mailing list archive, and look it out for yourself. Also, this is completely off topic, and has nothing to do with the original patch subject. Therefore a proper subject rename must happen. If you want to take this topic further, please figure it out between you two And, if necessary, the list maintainer, allright? Regards, Sergio Cheers. -- Felipe Contreras -- 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 -- 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 part1/2 merge][PATCH 06/10] omap3: serial: Fix uart4 handling for 3630
From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, March 05, 2010 4:38 PM snip @@ -694,6 +698,10 @@ void __init omap_serial_early_init(void) if (cpu_is_omap44xx()) p-irq += 32; + + /* IRQ for UART4 in omap3630 is 80 */ + if (cpu_is_omap3630() (i == 3)) + p-irq = 80; Should add a symbolic name to irqs.h and use it here, instead of hard-coded constant. Sounds like a nice idea! Thanks! I'll update the patchset and resend. Regards, Sergio 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] OMAP: Zoom3: Fix Zoom3 booting issue
-Original Message- From: G, Manjunath Kondaiah Sent: Wednesday, March 03, 2010 12:38 AM To: G, Manjunath Kondaiah; Aguirre, Sergio; linux-omap@vger.kernel.org Cc: Tony Lindgren; Shilimkar, Santosh; Raja, Govindraj Subject: RE: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue -Original Message- From: G, Manjunath Kondaiah Sent: Wednesday, March 03, 2010 11:31 AM To: Aguirre, Sergio; linux-omap@vger.kernel.org Cc: Tony Lindgren; Shilimkar, Santosh; Raja, Govindraj Subject: RE: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue Sergio, -Original Message- From: Aguirre, Sergio Sent: Tuesday, March 02, 2010 9:41 PM To: G, Manjunath Kondaiah; linux-omap@vger.kernel.org Cc: G, Manjunath Kondaiah; Tony Lindgren; Shilimkar, Santosh; Raja, Govindraj Subject: RE: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue Manju, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Manjunatha GK Sent: Tuesday, March 02, 2010 7:36 AM To: linux-omap@vger.kernel.org Cc: G, Manjunath Kondaiah; Tony Lindgren; Shilimkar, Santosh; Raja, Govindraj Subject: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue The commit id 5550bc33a1a9002976022cc794fe8c52ad9a0021 seems to be broken zoom3 boot which adds support for UART4 on OMAP4 and OMAP3630. But, it looks like OMAP3630 UART4 interface and functional clock nodes needs to be added for omap3630. Thus limiting no. of UART's for 3630 to 3 to prevent boot up issues until clock nodes are added for UART4 on OMAP3630. I already tried a similar patch here: http://patchwork.kernel.org/patch/81692/ But as it is really not solving anything, and Tony rejected it, I started working on the needed bits to get UART4 enabled, therefore I have came up with this patch series: - [RFC v3][PATCH 0/6] OMAP3630: UART4 startup (+ new bugfix!) [1] Also, I'm working in my spare time on a cleanup proposal [2], which I'll repost today, given some comments from Kevin. So, if you want to boot, take series [1] and [2], and then you should be able to boot with ttyS0. Sergio, did you test this combination on zoom3? It seems to be not working on zoom3 with ttyS0 and also with ttyS3. Where as, reducing number of uarts(for 3630) to 3 seems to working fine for ttyS3 on zoom3. To update further, it seems to be working on zoom3 with ttyS0 with following combination of patches: 1. [RFC,part2,v1,4/4] omap3: zoom 2/3: Change debugboard serial port id [RFC,part2,v1,3/4] omap3: 3630sdp: Explicitly enable all UARTs [RFC,part2,v1,2/4] omap3: zoom2/3 / 3630sdp: Don't init always all uarts [RFC,part2,v1,1/4] omap2/3/4: serial: rename omap_serial_init 2. [RESEND,PATCH/RFC] OMAP2: serial.c: Fix number of uarts in early_init 3. [RFC,v3,6/6] omap3: serial: Fix uart4 handling for 3630 [RFC,v3,5/6] OMAP3: PRCM: Consider UART4 for 3630 chip in prcm_setup_regs [RFC,v3,4/6] OMAP clock: Add uart4_ick/fck definitions for 3630 [RFC,v3,3/6] ARM: OMAP3630: PRCM: Add UART4 control bits [RFC,v3,2/6] omap2/3/4: serial: Remove condition for getting uart4_phys [RFC,v3,1/6] OMAP3: serial: Check for zero-based physical addr Yeah, that should be the total patchlist applied. I'm assuming you're applying from bottom to top order in your list above... Regards, Sergio -Manjunath -- 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] OMAP: Zoom3: Fix Zoom3 booting issue
-Original Message- From: G, Manjunath Kondaiah Sent: Wednesday, March 03, 2010 7:39 AM To: Aguirre, Sergio; linux-omap@vger.kernel.org Cc: Tony Lindgren; Shilimkar, Santosh; Raja, Govindraj Subject: RE: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue To update further, it seems to be working on zoom3 with ttyS0 with following combination of patches: 1. [RFC,part2,v1,4/4] omap3: zoom 2/3: Change debugboard serial port id [RFC,part2,v1,3/4] omap3: 3630sdp: Explicitly enable all UARTs [RFC,part2,v1,2/4] omap3: zoom2/3 / 3630sdp: Don't init always all uarts [RFC,part2,v1,1/4] omap2/3/4: serial: rename omap_serial_init 2. [RESEND,PATCH/RFC] OMAP2: serial.c: Fix number of uarts in early_init 3. [RFC,v3,6/6] omap3: serial: Fix uart4 handling for 3630 [RFC,v3,5/6] OMAP3: PRCM: Consider UART4 for 3630 chip in prcm_setup_regs [RFC,v3,4/6] OMAP clock: Add uart4_ick/fck definitions for 3630 [RFC,v3,3/6] ARM: OMAP3630: PRCM: Add UART4 control bits [RFC,v3,2/6] omap2/3/4: serial: Remove condition for getting uart4_phys [RFC,v3,1/6] OMAP3: serial: Check for zero-based physical addr Yeah, that should be the total patchlist applied. I'm assuming you're applying from bottom to top order in your list above... Yes. But, you will be dropping v1 part2 series right? I'll just drop patch #0001 in that series, and resend. Actually, I'll group the 2 series and resend in a single batch, just to be clear on the dependency between them. Regards, Sergio Regards, Manjunath -- 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 part1/2 merge][PATCH 08/10] omap3: 3630sdp: Explicitly enable all UARTs
-Original Message-
From: Aguirre, Sergio
Sent: Wednesday, March 03, 2010 8:19 AM
To: linux-omap@vger.kernel.org
Cc: Aguirre, Sergio
Subject: [RFC part1/2 merge][PATCH 08/10] omap3: 3630sdp: Explicitly
enable all UARTs
All UARTs seem physically reachable, so, enable them all.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/board-3630sdp.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
mode change 100755 = 100644 arch/arm/mach-omap2/board-3630sdp.c
diff --git a/arch/arm/mach-omap2/board-3630sdp.c b/arch/arm/mach-
omap2/board-3630sdp.c
old mode 100755
new mode 100644
index 4386d2b..35df894
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -96,6 +96,7 @@ static struct omap_board_mux board_mux[] __initdata = {
static void __init omap_sdp_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
+ omap_serial_init_allports();
Oops, forgot to change this one.
Please take attached one instead.
Regards,
Sergio
zoom_peripherals_init();
board_smc91x_init();
enable_board_wakeup_source();
--
1.6.3.3
0008-omap3-3630sdp-Explicitly-enable-all-UARTs.patch
Description: 0008-omap3-3630sdp-Explicitly-enable-all-UARTs.patch
RE: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue
Manju,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Manjunatha GK
Sent: Tuesday, March 02, 2010 7:36 AM
To: linux-omap@vger.kernel.org
Cc: G, Manjunath Kondaiah; Tony Lindgren; Shilimkar, Santosh; Raja,
Govindraj
Subject: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue
The commit id 5550bc33a1a9002976022cc794fe8c52ad9a0021 seems to be
broken
zoom3 boot which adds support for UART4 on OMAP4 and OMAP3630.
But, it looks like OMAP3630 UART4 interface and functional clock nodes
needs
to be added for omap3630. Thus limiting no. of UART's for 3630 to 3 to
prevent
boot up issues until clock nodes are added for UART4 on OMAP3630.
I already tried a similar patch here:
http://patchwork.kernel.org/patch/81692/
But as it is really not solving anything, and Tony rejected it, I started
working on the needed bits to get UART4 enabled, therefore I have came up with
this patch series:
- [RFC v3][PATCH 0/6] OMAP3630: UART4 startup (+ new bugfix!) [1]
Also, I'm working in my spare time on a cleanup proposal [2], which I'll repost
today, given some comments from Kevin.
So, if you want to boot, take series [1] and [2], and then you should be able
to boot with ttyS0.
Regards,
Sergio
---
[1] http://marc.info/?l=linux-omapm=126730356232287w=2
[2] http://marc.info/?l=linux-omapm=126746974103007w=2
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Signed-off-by: Govindraj R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index b79bc89..ac22a4e 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -764,7 +764,12 @@ void __init omap_serial_init(void)
{
int i, nr_ports;
- if (!(cpu_is_omap3630() || cpu_is_omap4430()))
+ /* Limit no.of UART ports to three for OMAP3630 since
+ * clock nodes are yet to be updated for 3630 UART4.
+ * TODO: update clock nodes for 3630 UART4 and then enable
+ * check for !(cpu_is_omap3630())
+ */
+ if (!cpu_is_omap4430())
nr_ports = 3;
else
nr_ports = ARRAY_SIZE(omap_uart);
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 part2 v1][PATCH 1/4] omap2/3/4: serial: rename omap_serial_init
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Monday, March 01, 2010 3:10 PM
To: Aguirre, Sergio
Cc: linux-omap@vger.kernel.org
Subject: Re: [RFC part2 v1][PATCH 1/4] omap2/3/4: serial: rename
omap_serial_init
Sergio Aguirre saagui...@ti.com writes:
The name itself doesn't make clear that all UARTs of the platform
are going to be initted. This is just to give more awareness of the
real action being done here.
Signed-off-by: Sergio Aguirre saagui...@ti.com
IMO, I don't think this adds any more clarity.
OK. But, do you mean that this is clear enough already, or that you have a
better suggestion than mine?
The reason I wanted to propose this change is because, you either use:
omap_serial_init()
or
omap_serial_init_port(number)
And for me it looked more consistent to have it named omap_serial_init_allports
instead...
Regards,
Sergio
Kevin
---
arch/arm/mach-omap2/board-2430sdp.c |2 +-
arch/arm/mach-omap2/board-3430sdp.c |2 +-
arch/arm/mach-omap2/board-4430sdp.c |2 +-
arch/arm/mach-omap2/board-am3517evm.c|2 +-
arch/arm/mach-omap2/board-apollon.c |2 +-
arch/arm/mach-omap2/board-cm-t35.c |2 +-
arch/arm/mach-omap2/board-devkit8000.c |2 +-
arch/arm/mach-omap2/board-generic.c |2 +-
arch/arm/mach-omap2/board-h4.c |2 +-
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-ldp.c |2 +-
arch/arm/mach-omap2/board-n8x0.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c |2 +-
arch/arm/mach-omap2/board-omap3evm.c |2 +-
arch/arm/mach-omap2/board-omap3pandora.c |2 +-
arch/arm/mach-omap2/board-omap3touchbook.c |2 +-
arch/arm/mach-omap2/board-overo.c|2 +-
arch/arm/mach-omap2/board-rx51.c |2 +-
arch/arm/mach-omap2/board-zoom-peripherals.c |2 +-
arch/arm/mach-omap2/serial.c |8
arch/arm/plat-omap/include/plat/serial.h |2 +-
21 files changed, 24 insertions(+), 24 deletions(-)
mode change 100755 = 100644 arch/arm/mach-omap2/board-zoom-
peripherals.c
diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-
omap2/board-2430sdp.c
index 01d113f..abc55bc 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -206,7 +206,7 @@ static void __init omap_2430sdp_init(void)
omap2430_i2c_init();
platform_add_devices(sdp2430_devices, ARRAY_SIZE(sdp2430_devices));
- omap_serial_init();
+ omap_serial_init_allports();
omap2_hsmmc_init(mmc);
usb_musb_init(musb_board_data);
board_smc91x_init();
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-
omap2/board-3430sdp.c
index f312b15..8c84973 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -799,7 +799,7 @@ static void __init omap_3430sdp_init(void)
spi_register_board_info(sdp3430_spi_board_info,
ARRAY_SIZE(sdp3430_spi_board_info));
ads7846_dev_init();
- omap_serial_init();
+ omap_serial_init_allports();
usb_musb_init(musb_board_data);
board_smc91x_init();
sdp_flash_init(sdp_flash_partitions);
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
omap2/board-4430sdp.c
index 029c6c9..1d47064 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -84,7 +84,7 @@ static struct omap_musb_board_data musb_board_data = {
static void __init omap_4430sdp_init(void)
{
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
- omap_serial_init();
+ omap_serial_init_allports();
/* OMAP4 SDP uses internal transceiver so register nop transceiver
*/
usb_nop_xceiv_register();
/* FIXME: allow multi-omap to boot until musb is updated for omap4
*/
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-
omap2/board-am3517evm.c
index e6b8967..d88b31f 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -300,7 +300,7 @@ static void __init am3517_evm_init(void)
platform_add_devices(am3517_evm_devices,
ARRAY_SIZE(am3517_evm_devices));
- omap_serial_init();
+ omap_serial_init_allports();
usb_ehci_init(ehci_pdata);
/* DSS */
am3517_evm_display_init();
diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach-
omap2/board-apollon.c
index aa69fb9..6c14392 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -331,7 +331,7 @@ static void __init omap_apollon_init(void)
* if not needed.
*/
platform_add_devices(apollon_devices, ARRAY_SIZE
RE: [RFC part2 v1][PATCH 1/4] omap2/3/4: serial: rename omap_serial_init
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Monday, March 01, 2010 5:49 PM
To: Aguirre, Sergio
Cc: linux-omap@vger.kernel.org
Subject: Re: [RFC part2 v1][PATCH 1/4] omap2/3/4: serial: rename
omap_serial_init
Aguirre, Sergio saagui...@ti.com writes:
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Monday, March 01, 2010 3:10 PM
To: Aguirre, Sergio
Cc: linux-omap@vger.kernel.org
Subject: Re: [RFC part2 v1][PATCH 1/4] omap2/3/4: serial: rename
omap_serial_init
Sergio Aguirre saagui...@ti.com writes:
The name itself doesn't make clear that all UARTs of the platform
are going to be initted. This is just to give more awareness of the
real action being done here.
Signed-off-by: Sergio Aguirre saagui...@ti.com
IMO, I don't think this adds any more clarity.
OK. But, do you mean that this is clear enough already, or that you have
a better suggestion than mine?
Personally, I think it's clear enough the way it is.
Ok, I think I'll drop it from the series, and repost a new version tomorrow.
Regards,
Sergio
Kevin
The reason I wanted to propose this change is because, you either use:
omap_serial_init()
or
omap_serial_init_port(number)
And for me it looked more consistent to have it named
omap_serial_init_allports instead...
Kevin
---
arch/arm/mach-omap2/board-2430sdp.c |2 +-
arch/arm/mach-omap2/board-3430sdp.c |2 +-
arch/arm/mach-omap2/board-4430sdp.c |2 +-
arch/arm/mach-omap2/board-am3517evm.c|2 +-
arch/arm/mach-omap2/board-apollon.c |2 +-
arch/arm/mach-omap2/board-cm-t35.c |2 +-
arch/arm/mach-omap2/board-devkit8000.c |2 +-
arch/arm/mach-omap2/board-generic.c |2 +-
arch/arm/mach-omap2/board-h4.c |2 +-
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-ldp.c |2 +-
arch/arm/mach-omap2/board-n8x0.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c |2 +-
arch/arm/mach-omap2/board-omap3evm.c |2 +-
arch/arm/mach-omap2/board-omap3pandora.c |2 +-
arch/arm/mach-omap2/board-omap3touchbook.c |2 +-
arch/arm/mach-omap2/board-overo.c|2 +-
arch/arm/mach-omap2/board-rx51.c |2 +-
arch/arm/mach-omap2/board-zoom-peripherals.c |2 +-
arch/arm/mach-omap2/serial.c |8
arch/arm/plat-omap/include/plat/serial.h |2 +-
21 files changed, 24 insertions(+), 24 deletions(-)
mode change 100755 = 100644 arch/arm/mach-omap2/board-zoom-
peripherals.c
diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-
omap2/board-2430sdp.c
index 01d113f..abc55bc 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -206,7 +206,7 @@ static void __init omap_2430sdp_init(void)
omap2430_i2c_init();
platform_add_devices(sdp2430_devices,
ARRAY_SIZE(sdp2430_devices));
- omap_serial_init();
+ omap_serial_init_allports();
omap2_hsmmc_init(mmc);
usb_musb_init(musb_board_data);
board_smc91x_init();
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-
omap2/board-3430sdp.c
index f312b15..8c84973 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -799,7 +799,7 @@ static void __init omap_3430sdp_init(void)
spi_register_board_info(sdp3430_spi_board_info,
ARRAY_SIZE(sdp3430_spi_board_info));
ads7846_dev_init();
- omap_serial_init();
+ omap_serial_init_allports();
usb_musb_init(musb_board_data);
board_smc91x_init();
sdp_flash_init(sdp_flash_partitions);
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
omap2/board-4430sdp.c
index 029c6c9..1d47064 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -84,7 +84,7 @@ static struct omap_musb_board_data musb_board_data
= {
static void __init omap_4430sdp_init(void)
{
platform_add_devices(sdp4430_devices,
ARRAY_SIZE(sdp4430_devices));
- omap_serial_init();
+ omap_serial_init_allports();
/* OMAP4 SDP uses internal transceiver so register nop
transceiver
*/
usb_nop_xceiv_register();
/* FIXME: allow multi-omap to boot until musb is updated for
omap4
*/
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-
omap2/board-am3517evm.c
index e6b8967..d88b31f 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -300,7 +300,7 @@ static void __init am3517_evm_init(void)
platform_add_devices(am3517_evm_devices
Using DEBUG_LL?
Hi, Wit the current master branch, I tried enabling DEBUG_LL, and EARLY_PRINTK options, but I can't see the LL output as usual (#... kind of thing) on my 3630SDP. Is there a patch to enable it after the serial cleanup patches? Regards, Sergio -- 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: Using DEBUG_LL?
-Original Message- From: Shilimkar, Santosh Sent: Friday, February 26, 2010 8:53 AM To: Aguirre, Sergio; Tony Lindgren Cc: linux-omap@vger.kernel.org; Pandita, Vikram Subject: RE: Using DEBUG_LL? -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio Sent: Friday, February 26, 2010 8:03 PM To: Tony Lindgren Cc: linux-omap@vger.kernel.org; Pandita, Vikram Subject: Using DEBUG_LL? Hi, Wit the current master branch, I tried enabling DEBUG_LL, and EARLY_PRINTK options, but I can't see the LL output as usual (#... kind of thing) on my 3630SDP. Is there a patch to enable it after the serial cleanup patches? I think DEBUG_LL on zoom boards is broken because they use external quad- uart. I know that. But I'm not using a Zoom board now, I'm trying with a 3630SDP. So, I'm not using an external UART anymore. Regards, Sergio Vikram reported this on list some time back. Regards, Santosh -- 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: Using DEBUG_LL?
-Original Message- From: Jean Pihet [mailto:jpi...@mvista.com] Sent: Friday, February 26, 2010 9:10 AM To: Gadiyar, Anand Cc: Shilimkar, Santosh; Aguirre, Sergio; Tony Lindgren; linux- o...@vger.kernel.org; Pandita, Vikram Subject: Re: Using DEBUG_LL? Hi, Hi, In addition to DEBUG_LL you need to append 'earlyprintk' to the cmdline. Brilliant! Now it works. :D Thanks a lot for the help! Regards, Sergio Hope this helps, Jean On Friday 26 February 2010 16:02:36 Gadiyar, Anand wrote: Wit the current master branch, I tried enabling DEBUG_LL, and EARLY_PRINTK options, but I can't see the LL output as usual (#... kind of thing) on my 3630SDP. Is there a patch to enable it after the serial cleanup patches? I think DEBUG_LL on zoom boards is broken because they use external quad-uart. Vikram reported this on list some time back. No, looks like this is broken on SDPs as well. Either that, or I haven't understood how to use the early_printk option. I have the same problem on my 3430 SDP and manually patch kernel/printk.c with the patch in Tony's omap-debug branch. - Anand -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2 V2] OMAP: DSS: Add display board file for zoom boards
Manjunath,
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of G, Manjunath Kondaiah
Sent: Thursday, February 11, 2010 5:35 AM
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Y, Kishore
Sent: Thursday, February 11, 2010 3:33 PM
snip
+
+static void zoom_lcd_tv_panel_init(void)
+{
+ int ret;
+ unsigned char lcd_panel_reset_gpio;
+
+ if (omap_rev() OMAP3430_REV_ES3_0) {
+ /* Production Zoom2 board:
+* GPIO-96 is the LCD_RESET_GPIO
+*/
+ lcd_panel_reset_gpio = LCD_PANEL_RESET_GPIO_PROD;
+ } else {
+ /* Pilot Zoom2 board:
+* GPIO-55 is the LCD_RESET_GPIO
+*/
+ lcd_panel_reset_gpio = LCD_PANEL_RESET_GPIO_PILOT;
+ }
How about:
lcd_panel_reset_gpio = (omap_rev() OMAP3430_REV_ES3_0) ?
LCD_PANEL_RESET_GPIO_PROD :
LCD_PANEL_RESET_GPIO_PILOT;
This approach has been discussed many times before, and found incorrect. There
is no way to auto-detect valid GPIO for reset as of now. For example: Zoom
Pilot + 3630 SOM case will fail here.
I'll push again for my thoughts on this one...
There MUST be a configurable option in kernel menuconfig to select the board
revision (Pilot, pre-production). That is the only clean way I can see this
could actually work.
Regards,
Sergio
snip
--
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] omap2/3/4: serial: Half revert multiboot changes
Hi, -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Thursday, February 25, 2010 12:56 PM To: Aguirre, Sergio Cc: linux-omap@vger.kernel.org; Sonasath, Moiz; Pandita, Vikram Subject: Re: [PATCH] omap2/3/4: serial: Half revert multiboot changes * Aguirre, Sergio saagui...@ti.com [100224 19:04]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Wednesday, February 24, 2010 10:21 AM To: Aguirre, Sergio Cc: linux-omap@vger.kernel.org; Sonasath, Moiz; Pandita, Vikram Subject: Re: [PATCH] omap2/3/4: serial: Half revert multiboot changes * Aguirre, Sergio saagui...@ti.com [100223 23:37]: Hmm.. I think I sent this patch too soon... Please ignore it, this is not a proper solution I feel.. But what it is true... is that, patch omap2/3/4: Fix mach- omap2/serial.c for multiboot is definitely breaking Zoom3 boot, and needs to be fixed. Yes sounds like only zoom has the external uart, other 3630 boards may be using the internal uart4. Actually, I don't see any patch to handle uart4 interface/functional clocks, so I assume the addition of uart4 for 3630 chip is incomplete. Shall we apply my 2nd patch, until proper clock handling is in place? I don't have an omap4 to test, but I think my patch shouldn't hurt the initial intention to make multiomap builds possible... agree? See also the recent patch from Thomas. I'd say let's rather fix this properly with your clock related patchset once it's been tested. We already have all these temporary hacks still in place for omap4, let's try not to add more. Ok, sure. I agree. I'll try to get a 3630SDP, which I believe has physical access to UART4. With just my Zoom3 I can't do much :/ Regards, Sergio 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] omap2/3/4: serial: Don't init UART4 for 3630 still
-Original Message-
From: Aguirre, Sergio
Sent: Wednesday, February 24, 2010 3:02 AM
To: Tony Lindgren
Cc: linux-omap@vger.kernel.org; Pandita, Vikram; Sonasath, Moiz; Aguirre,
Sergio
Subject: [PATCH] omap2/3/4: serial: Don't init UART4 for 3630 still
The patch named:
omap2/3/4: Fix mach-omap2/serial.c for multiboot
Which added UART4 init also for 36xx based boards, broke zoom3
booting.
In theory, for zoom3 case, we should have UART4 + external debugboard
UART running with no issues. But unless the real issue is fixed,
this patch is crucial for Zoom3 booting.
Just FYI,
I tried by changing id field in board-zoom-debugboard.c for external UART to
-1, which in theory would add a ttyS4, but somehow it didn't worked for me...
I guess the proper fix will be to have:
ttyS0 - OMAP3_UART1
ttyS1 - OMAP3_UART2
ttyS2 - OMAP3_UART3
ttyS3 - OMAP3_UART4
ttyS4 - ZOOM_UART
Any Zoom debugboard expert that wants to comment on this?
Regards,
Sergio
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/serial.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index b79bc89..c4a810b 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -764,7 +764,7 @@ void __init omap_serial_init(void)
{
int i, nr_ports;
- if (!(cpu_is_omap3630() || cpu_is_omap4430()))
+ if (!cpu_is_omap4430())
nr_ports = 3;
else
nr_ports = ARRAY_SIZE(omap_uart);
--
1.6.3.3
--
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] omap2/3/4: serial: Half revert multiboot changes
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Wednesday, February 24, 2010 10:21 AM
To: Aguirre, Sergio
Cc: linux-omap@vger.kernel.org; Sonasath, Moiz; Pandita, Vikram
Subject: Re: [PATCH] omap2/3/4: serial: Half revert multiboot changes
* Aguirre, Sergio saagui...@ti.com [100223 23:37]:
Hmm..
I think I sent this patch too soon...
Please ignore it, this is not a proper solution I feel..
But what it is true... is that, patch omap2/3/4: Fix mach-
omap2/serial.c for multiboot is definitely breaking Zoom3 boot, and needs
to be fixed.
Yes sounds like only zoom has the external uart, other 3630
boards may be using the internal uart4.
Actually, I don't see any patch to handle uart4 interface/functional clocks, so
I assume the addition of uart4 for 3630 chip is incomplete.
Shall we apply my 2nd patch, until proper clock handling is in place?
I don't have an omap4 to test, but I think my patch shouldn't hurt the initial
intention to make multiomap builds possible... agree?
I'll try to come up with a better patch.
You can call omap_serial_init_port() for each port from
board-zoom3.c instead of calling omap_serial_init().
Perhaphs it would be a good idea to specify in the boardfile somehow how many
UART ports we want to enable.
The boards may not even have physical access for those ports, and if they do,
they need to do proper muxing before initializing them.
Regards,
Sergio
See commit
Regards,
Tony
Regards,
Sergio
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio
Sent: Wednesday, February 24, 2010 1:31 AM
To: Tony Lindgren
Cc: linux-omap@vger.kernel.org; Sonasath, Moiz; Pandita, Vikram
Subject: [PATCH] omap2/3/4: serial: Half revert multiboot changes
From 14bc4ee14ac5a3dab79d9292bf22ab0401879cd5 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre saagui...@ti.com
Date: Wed, 24 Feb 2010 01:15:55 -0600
Subject: [PATCH] omap2/3/4: serial: Half revert multiboot changes
The patch named:
omap2/3/4: Fix mach-omap2/serial.c for multiboot
Which added UART4 init also for 36xx based boards, broke zoom3
booting. External UART must be correctly initialized already
by board-zoom-debugboard.c file, therefore the addition on UART4
initialization can't be done blindly (i.e. board agnostic)
This patch removes the 36xx uart4 init for the above reason.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/serial.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-
omap2/serial.c
index b79bc89..fe3122b 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -115,7 +115,6 @@ static struct plat_serial8250_port
serial_platform_data2[] = {
}
};
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
static struct plat_serial8250_port serial_platform_data3[] = {
{
.irq= 70,
@@ -132,11 +131,6 @@ static inline void omap2_set_globals_uart4(struct
omap_globals *omap2_globals)
{
serial_platform_data3[0].mapbase = omap2_globals-uart4_phys;
}
-#else
-static inline void omap2_set_globals_uart4(struct omap_globals
*omap2_globals)
-{
-}
-#endif
void __init omap2_set_globals_uart(struct omap_globals
*omap2_globals)
{
@@ -597,7 +591,7 @@ static struct omap_uart_state omap_uart[] = {
},
},
},
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#ifdef CONFIG_ARCH_OMAP4
{
.pdev = {
.name = serial8250,
@@ -764,7 +758,7 @@ void __init omap_serial_init(void)
{
int i, nr_ports;
- if (!(cpu_is_omap3630() || cpu_is_omap4430()))
+ if (!cpu_is_omap4430())
nr_ports = 3;
else
nr_ports = ARRAY_SIZE(omap_uart);
--
1.6.3.3
--
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] PM-WIP-OPP: Fixing wrong target level being passed during Core DVFS.
-Original Message-
From: Menon, Nishanth
Sent: Monday, February 22, 2010 11:31 PM
To: Aguirre, Sergio; Gopinath, Thara
Cc: linux-omap@vger.kernel.org; Kevin Hilman; Kristo Tero (Nokia-
D/Tampere)
Subject: RE: [PATCH] PM-WIP-OPP: Fixing wrong target level being passed
during Core DVFS.
From: Aguirre, Sergio
Sent: Tuesday, February 23, 2010 7:28 AM
To: Menon, Nishanth; Gopinath, Thara
[...]
Signed-off-by: Thara Gopinath th...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/resource34xx.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/resource34xx.c b/arch/arm/mach-
omap2/resource34xx.c
index 3604a38..d2336d8 100644
--- a/arch/arm/mach-omap2/resource34xx.c
+++ b/arch/arm/mach-omap2/resource34xx.c
@@ -463,6 +463,7 @@ int set_opp(struct shared_resource *resp, u32
target_level)
} else if (resp == vdd2_resp) {
unsigned long req_l3_freq;
struct omap_opp *oppx = NULL;
+ u8 opp;
/* Convert the tput in KiB/s to Bus frequency in MHz */
req_l3_freq = (target_level * 1000)/4;
@@ -478,10 +479,11 @@ int set_opp(struct shared_resource *resp, u32
target_level)
/* uh uh.. no OPPs?? */
BUG_ON(IS_ERR(oppx));
If you do target_level = 0; here, the entire patch is a oneliner :)
Actually, IMHO will be even more clean, to standardize all OPP value
passing to be u8.
Do you really need to be prepared for 2^32 opp values? ;)
Using OPP ID has to be completely removed from resource34xx.c - this
action is still pending. In this case, using u8 OR initing the
target_level to 0 has the same impact. Why add code that will be removed
later on anyways?
Well, I'm not proposing for code addition, but to fix that code just by
changing opp level parameters to u8, instead of u32, like this:
-int set_opp(struct shared_resource *resp, u32 target_level)
+int set_opp(struct shared_resource *resp, u8 target_level)
If you're going to replace all this in the near future, then it's
understandable to hold even this patch (target_level = 0).
Regards,
Sergio
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
[PATCH] omap2/3/4: serial: Half revert multiboot changes
From 14bc4ee14ac5a3dab79d9292bf22ab0401879cd5 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre saagui...@ti.com
Date: Wed, 24 Feb 2010 01:15:55 -0600
Subject: [PATCH] omap2/3/4: serial: Half revert multiboot changes
The patch named:
omap2/3/4: Fix mach-omap2/serial.c for multiboot
Which added UART4 init also for 36xx based boards, broke zoom3
booting. External UART must be correctly initialized already
by board-zoom-debugboard.c file, therefore the addition on UART4
initialization can't be done blindly (i.e. board agnostic)
This patch removes the 36xx uart4 init for the above reason.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/serial.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index b79bc89..fe3122b 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -115,7 +115,6 @@ static struct plat_serial8250_port serial_platform_data2[]
= {
}
};
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
static struct plat_serial8250_port serial_platform_data3[] = {
{
.irq= 70,
@@ -132,11 +131,6 @@ static inline void omap2_set_globals_uart4(struct
omap_globals *omap2_globals)
{
serial_platform_data3[0].mapbase = omap2_globals-uart4_phys;
}
-#else
-static inline void omap2_set_globals_uart4(struct omap_globals *omap2_globals)
-{
-}
-#endif
void __init omap2_set_globals_uart(struct omap_globals *omap2_globals)
{
@@ -597,7 +591,7 @@ static struct omap_uart_state omap_uart[] = {
},
},
},
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#ifdef CONFIG_ARCH_OMAP4
{
.pdev = {
.name = serial8250,
@@ -764,7 +758,7 @@ void __init omap_serial_init(void)
{
int i, nr_ports;
- if (!(cpu_is_omap3630() || cpu_is_omap4430()))
+ if (!cpu_is_omap4430())
nr_ports = 3;
else
nr_ports = ARRAY_SIZE(omap_uart);
--
1.6.3.3
0001-omap2-3-4-serial-Half-revert-multiboot-changes.patch
Description: 0001-omap2-3-4-serial-Half-revert-multiboot-changes.patch
RE: [PATCH] omap2/3/4: serial: Half revert multiboot changes
Hmm..
I think I sent this patch too soon...
Please ignore it, this is not a proper solution I feel..
But what it is true... is that, patch omap2/3/4: Fix mach-omap2/serial.c for
multiboot is definitely breaking Zoom3 boot, and needs to be fixed.
I'll try to come up with a better patch.
Regards,
Sergio
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio
Sent: Wednesday, February 24, 2010 1:31 AM
To: Tony Lindgren
Cc: linux-omap@vger.kernel.org; Sonasath, Moiz; Pandita, Vikram
Subject: [PATCH] omap2/3/4: serial: Half revert multiboot changes
From 14bc4ee14ac5a3dab79d9292bf22ab0401879cd5 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre saagui...@ti.com
Date: Wed, 24 Feb 2010 01:15:55 -0600
Subject: [PATCH] omap2/3/4: serial: Half revert multiboot changes
The patch named:
omap2/3/4: Fix mach-omap2/serial.c for multiboot
Which added UART4 init also for 36xx based boards, broke zoom3
booting. External UART must be correctly initialized already
by board-zoom-debugboard.c file, therefore the addition on UART4
initialization can't be done blindly (i.e. board agnostic)
This patch removes the 36xx uart4 init for the above reason.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/serial.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index b79bc89..fe3122b 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -115,7 +115,6 @@ static struct plat_serial8250_port
serial_platform_data2[] = {
}
};
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
static struct plat_serial8250_port serial_platform_data3[] = {
{
.irq= 70,
@@ -132,11 +131,6 @@ static inline void omap2_set_globals_uart4(struct
omap_globals *omap2_globals)
{
serial_platform_data3[0].mapbase = omap2_globals-uart4_phys;
}
-#else
-static inline void omap2_set_globals_uart4(struct omap_globals
*omap2_globals)
-{
-}
-#endif
void __init omap2_set_globals_uart(struct omap_globals *omap2_globals)
{
@@ -597,7 +591,7 @@ static struct omap_uart_state omap_uart[] = {
},
},
},
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#ifdef CONFIG_ARCH_OMAP4
{
.pdev = {
.name = serial8250,
@@ -764,7 +758,7 @@ void __init omap_serial_init(void)
{
int i, nr_ports;
- if (!(cpu_is_omap3630() || cpu_is_omap4430()))
+ if (!cpu_is_omap4430())
nr_ports = 3;
else
nr_ports = ARRAY_SIZE(omap_uart);
--
1.6.3.3
--
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
