Re: [PATCH 1/8] OMAPDSS: HDMI: Move GPIO handling to HDMI driver
On Thursday 23 August 2012 07:15 PM, Tomi Valkeinen wrote:
We currently manage HDMI GPIOs in the board files via
platform_enable/disable calls. This won't work with device tree, and in
any case the correct place to manage the GPIOs is in the HDMI driver.
This patch moves the handling of the GPIOs to the HDMI driver. The GPIO
handling is moved to the common hdmi.c file, and this probably needs to
be revisited when adding OMAP5 HDMI support to see if the GPIO handling
needs to be moved to IP specific files.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c| 27 +---
arch/arm/mach-omap2/board-omap4panda.c | 27 +---
drivers/video/omap2/dss/hdmi.c | 75 +++-
include/video/omapdss.h|2 +
4 files changed, 61 insertions(+), 70 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 8e17284..852e05c 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -601,29 +601,6 @@ static void __init omap_sfh7741prox_init(void)
__func__, OMAP4_SFH7741_ENABLE_GPIO, error);
}
-static struct gpio sdp4430_hdmi_gpios[] = {
- { HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ct_cp_hpd },
- { HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH,hdmi_gpio_ls_oe },
- { HDMI_GPIO_HPD, GPIOF_DIR_IN, hdmi_gpio_hpd },
-};
-
-static int sdp4430_panel_enable_hdmi(struct omap_dss_device *dssdev)
-{
- int status;
-
- status = gpio_request_array(sdp4430_hdmi_gpios,
- ARRAY_SIZE(sdp4430_hdmi_gpios));
- if (status)
- pr_err(%s: Cannot request HDMI GPIOs\n, __func__);
-
- return status;
-}
-
-static void sdp4430_panel_disable_hdmi(struct omap_dss_device *dssdev)
-{
- gpio_free_array(sdp4430_hdmi_gpios, ARRAY_SIZE(sdp4430_hdmi_gpios));
-}
-
static struct nokia_dsi_panel_data dsi1_panel = {
.name = taal,
.reset_gpio = 102,
@@ -718,6 +695,8 @@ static struct omap_dss_device sdp4430_lcd2_device = {
};
static struct omap_dss_hdmi_data sdp4430_hdmi_data = {
+ .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
+ .ls_oe_gpio = HDMI_GPIO_LS_OE,
.hpd_gpio = HDMI_GPIO_HPD,
};
@@ -725,8 +704,6 @@ static struct omap_dss_device sdp4430_hdmi_device = {
.name = hdmi,
.driver_name = hdmi_panel,
.type = OMAP_DISPLAY_TYPE_HDMI,
- .platform_enable = sdp4430_panel_enable_hdmi,
- .platform_disable = sdp4430_panel_disable_hdmi,
.channel = OMAP_DSS_CHANNEL_DIGIT,
.data = sdp4430_hdmi_data,
};
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 982fb26..5415faa 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -405,30 +405,9 @@ static struct omap_dss_device omap4_panda_dvi_device = {
.channel= OMAP_DSS_CHANNEL_LCD2,
};
-static struct gpio panda_hdmi_gpios[] = {
- { HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ct_cp_hpd },
- { HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ls_oe },
- { HDMI_GPIO_HPD, GPIOF_DIR_IN, hdmi_gpio_hpd },
-};
-
-static int omap4_panda_panel_enable_hdmi(struct omap_dss_device *dssdev)
-{
- int status;
-
- status = gpio_request_array(panda_hdmi_gpios,
- ARRAY_SIZE(panda_hdmi_gpios));
- if (status)
- pr_err(Cannot request HDMI GPIOs\n);
-
- return status;
-}
-
-static void omap4_panda_panel_disable_hdmi(struct omap_dss_device *dssdev)
-{
- gpio_free_array(panda_hdmi_gpios, ARRAY_SIZE(panda_hdmi_gpios));
-}
-
static struct omap_dss_hdmi_data omap4_panda_hdmi_data = {
+ .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
+ .ls_oe_gpio = HDMI_GPIO_LS_OE,
.hpd_gpio = HDMI_GPIO_HPD,
};
@@ -436,8 +415,6 @@ static struct omap_dss_device omap4_panda_hdmi_device = {
.name = hdmi,
.driver_name = hdmi_panel,
.type = OMAP_DISPLAY_TYPE_HDMI,
- .platform_enable = omap4_panda_panel_enable_hdmi,
- .platform_disable = omap4_panda_panel_disable_hdmi,
.channel = OMAP_DSS_CHANNEL_DIGIT,
.data = omap4_panda_hdmi_data,
};
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 0cdf246..4fbe271 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -32,6 +32,7 @@
#include linux/platform_device.h
#include linux/pm_runtime.h
#include linux/clk.h
+#include linux/gpio.h
#include video/omapdss.h
#include ti_hdmi.h
@@ -61,6 +62,10 @@ static struct {
struct hdmi_ip_data ip_data;
struct clk *sys_clk;
+
+ int ct_cp_hpd_gpio;
+ int ls_oe_gpio;
+ int hpd_gpio;
} hdmi;
/*
@@ -314,12 +319,34 @@
[PATCH] MMC: OMAP MSDI: fix broken PIO mode
After commit 26b88520b80695a6fa5fd95b5d97c03f4daf87e0 (mmc:
omap_hsmmc: remove private DMA API implementation), the Nokia N800
here stopped booting:
[2.086181] Waiting for root device /dev/mmcblk0p1...
[2.324066] Unhandled fault: imprecise external abort (0x406) at 0x
[2.331451] Internal error: : 406 [#1] ARM
[2.335784] Modules linked in:
[2.339050] CPU: 0Not tainted (3.6.0-rc3 #60)
[2.344146] PC is at default_idle+0x28/0x30
[2.348602] LR is at trace_hardirqs_on_caller+0x15c/0x1b0
...
This turned out to be due to memory corruption caused by long-broken
PIO code in drivers/mmc/host/omap.c. (Previously, this driver had
been using DMA; but the above commit caused the MMC driver to fall
back to PIO mode with an unmodified Kconfig.)
The PIO code, added with the rest of the driver in commit
730c9b7e6630f786fcec026fb11d2e6f2c90fdcb ([MMC] Add OMAP MMC host
driver), confused bytes with 16-bit words. This bug caused memory
located after the PIO transfer buffer to be corrupted with transfers
larger than 32 bytes. The driver also did not increment the buffer
pointer after the transfer occurred. This bug resulted in data
corruption during any transfer larger than 64 bytes.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Juha Yrjölä juha.yrj...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Carlos Aguiar carlos.agu...@indt.org.br
Cc: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/mmc/host/omap.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 50e08f0..a5999a7 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -668,7 +668,7 @@ mmc_omap_clk_timer(unsigned long data)
static void
mmc_omap_xfer_data(struct mmc_omap_host *host, int write)
{
- int n;
+ int n, nwords;
if (host-buffer_bytes_left == 0) {
host-sg_idx++;
@@ -678,15 +678,23 @@ mmc_omap_xfer_data(struct mmc_omap_host *host, int write)
n = 64;
if (n host-buffer_bytes_left)
n = host-buffer_bytes_left;
+
+ nwords = n / 2;
+ nwords += n 1; /* handle odd number of bytes to transfer */
+
host-buffer_bytes_left -= n;
host-total_bytes_left -= n;
host-data-bytes_xfered += n;
if (write) {
- __raw_writesw(host-virt_base + OMAP_MMC_REG(host, DATA),
host-buffer, n);
+ __raw_writesw(host-virt_base + OMAP_MMC_REG(host, DATA),
+ host-buffer, nwords);
} else {
- __raw_readsw(host-virt_base + OMAP_MMC_REG(host, DATA),
host-buffer, n);
+ __raw_readsw(host-virt_base + OMAP_MMC_REG(host, DATA),
+host-buffer, nwords);
}
+
+ host-buffer += nwords;
}
static inline void mmc_omap_report_irq(u16 status)
--
1.7.10.4
Re: [PATCH 6/8] OMAPDSS: DSI: calculate dsi clock
On Thursday 23 August 2012 07:15 PM, Tomi Valkeinen wrote:
Currently the way to configure clocks related to DSI (both DSI and DISPC
clocks) happens via omapdss platform data. The reason for this is that
configuring the DSS clocks is a very complex problem, and it's
impossible for the SW to know requirements about things like
interference.
However, for general cases it should be fine to calculate the dividers
for clocks in the SW. The calculated clocks are probably not perfect,
but should work.
This patch adds support to calculate the dividers when using DSI command
mode panels. The panel gives the required DDR clock rate and LP clock
rate, and the DSI driver configures itself and DISPC accordingly.
This patch is somewhat ugly, though. The code does its job by modifying
the platform data where the clock dividers would be if the board file
gave them. This is not how it's going to be in the future, but allows us
to have quite simple patch and keep the backward compatibility.
It also allows the developer to still give the exact dividers from the
board file when there's need for that, as long as the panel driver does
not override them.
There are also other areas for improvement. For example, it would be
better if the panel driver could ask for a DSI clock in a certain range,
as, at least command mode panels, the panel can work fine with many
different clock speeds.
While the patch is not perfect, it allows us to remove the hardcoded
clock dividers from the board file, making it easier to bring up a new
panel and to use device tree from omapdss.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays/panel-taal.c |6 ++
drivers/video/omap2/dss/dsi.c | 126 +
include/video/omapdss.h |2 +
3 files changed, 134 insertions(+)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index 77aed0e..ddda96a 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -1065,6 +1065,12 @@ static int taal_power_on(struct omap_dss_device *dssdev)
omapdss_dsi_set_pixel_format(dssdev, OMAP_DSS_DSI_FMT_RGB888);
omapdss_dsi_set_operation_mode(dssdev, OMAP_DSS_DSI_CMD_MODE);
+ r = omapdss_dsi_set_clocks(dssdev, 21600, 1000);
+ if (r) {
+ dev_err(dssdev-dev, failed to set HS and LP clocks\n);
+ goto err0;
+ }
+
r = omapdss_dsi_display_enable(dssdev);
if (r) {
dev_err(dssdev-dev, failed to enable DSI\n);
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 96d0024..340c832 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1454,6 +1454,68 @@ found:
return 0;
}
+static int dsi_pll_calc_ddrfreq(struct platform_device *dsidev,
+ unsigned long req_clk, struct dsi_clock_info *cinfo)
+{
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+ struct dsi_clock_info cur, best;
+ unsigned long dss_sys_clk, max_dss_fck, max_dsi_fck;
+ unsigned long req_clkin4ddr;
+
+ DSSDBG(dsi_pll_calc_ddrfreq\n);
+
+ dss_sys_clk = clk_get_rate(dsi-sys_clk);
+
+ max_dss_fck = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
+ max_dsi_fck = dss_feat_get_param_max(FEAT_PARAM_DSI_FCK);
+
+ memset(best, 0, sizeof(best));
+ memset(cur, 0, sizeof(cur));
+
+ cur.clkin = dss_sys_clk;
+
+ req_clkin4ddr = req_clk * 4;
+
+ for (cur.regn = 1; cur.regn dsi-regn_max; ++cur.regn) {
+ cur.fint = cur.clkin / cur.regn;
+
+ if (cur.fint dsi-fint_max || cur.fint dsi-fint_min)
+ continue;
+
+ /* DSIPHY(MHz) = (2 * regm / regn) * clkin */
+ for (cur.regm = 1; cur.regm dsi-regm_max; ++cur.regm) {
+ unsigned long a, b;
+
+ a = 2 * cur.regm * (cur.clkin/1000);
+ b = cur.regn;
+ cur.clkin4ddr = a / b * 1000;
+
+ if (cur.clkin4ddr 1800 * 1000 * 1000)
+ break;
+
+ if (abs(cur.clkin4ddr - req_clkin4ddr)
+ abs(best.clkin4ddr - req_clkin4ddr)) {
+ best = cur;
+ DSSDBG(best %ld\n, best.clkin4ddr);
+ }
+
+ if (cur.clkin4ddr == req_clkin4ddr)
+ goto found;
+ }
+ }
+found:
+ best.regm_dispc = DIV_ROUND_UP(best.clkin4ddr, max_dss_fck);
+ best.dsi_pll_hsdiv_dispc_clk = best.clkin4ddr / best.regm_dispc;
+
+ best.regm_dsi = DIV_ROUND_UP(best.clkin4ddr, max_dsi_fck);
+ best.dsi_pll_hsdiv_dsi_clk = best.clkin4ddr / best.regm_dsi;
+
+ if (cinfo)
+ *cinfo = best;
+
+
Re: [PATCH 4/8] OMAPDSS: HDMI: use vdda_hdmi_dac
On Thursday 23 August 2012 07:15 PM, Tomi Valkeinen wrote:
The HDMI driver requires vdda_hdmi_dac power for operation, but does not
enable it. This has worked because the regulator has been always
enabled.
But this may not always be the case, as I encountered when implementing
HDMI device tree support.
This patch changes the HDMI driver to use the vdda_hdmi_dac.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 96a6e29..ccfc677 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -33,6 +33,7 @@
#include linux/pm_runtime.h
#include linux/clk.h
#include linux/gpio.h
+#include linux/regulator/consumer.h
#include video/omapdss.h
#include ti_hdmi.h
@@ -62,6 +63,7 @@ static struct {
struct hdmi_ip_data ip_data;
struct clk *sys_clk;
+ struct regulator *vdda_hdmi_dac_reg;
int ct_cp_hpd_gpio;
int ls_oe_gpio;
@@ -331,6 +333,19 @@ static int __init hdmi_init_display(struct omap_dss_device
*dssdev)
dss_init_hdmi_ip_ops(hdmi.ip_data);
+ if (hdmi.vdda_hdmi_dac_reg == NULL) {
+ struct regulator *reg;
+
+ reg = devm_regulator_get(hdmi.pdev-dev, vdda_hdmi_dac);
There is no corresponding devm_regulator_put() call here, I guess that's
what devm_* calls are supposed to help us with. But the only place I saw
the usage of dev_regulator_get() is here:
sound/soc/ux500/ux500_msp_dai.c
And here, they are doing devm_regulator_put() calls to, so I was
wondering what the deal is.
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] arm/dts: Add tps65217 regulator DT data to am335x-bone.dts
Op 24 aug. 2012, om 07:50 heeft AnilKumar, Chimata anilku...@ti.com het volgende geschreven: Hi Koen, On Thu, Aug 23, 2012 at 19:43:48, Koen Kooi wrote: Op 21 aug. 2012, om 13:17 heeft AnilKumar Ch anilku...@ti.com het volgende geschreven: Add tps65217 regulator device tree data to AM335x-Bone by adding regulator consumers with tightened constraints and regulator-name. TPS65217 regulator handle can be obtained by using this regulator name. This patch also add I2C node with I2C frequency and tps65217 PMIC I2C slave address. Signed-off-by: AnilKumar Ch anilku...@ti.com I tried this and the kernel immediately crashes on my beaglebone. Could you upload the complete git tree and .config you used to test this to somewhere public please? Use this repo to test on beaglebone https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging-pinctrl This wiki talks about how to build and use? https://github.com/hvaibhav/am335x-linux/wiki/How-To-Use-Upstream-Tree Note: Enable tps65217 regulator in kernel config. I used that repo and as a seperate test I rebased that to latest mainline, same thing: as soon as I turn on the TPS in the .config it crashes on boot. Is the pinctrl repo the *exact* repo you used to test the patches on beaglebone?-- 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/8] OMAPDSS: HDMI: Move GPIO handling to HDMI driver
On Fri, 2012-08-24 at 11:30 +0530, Archit Taneja wrote:
On Thursday 23 August 2012 07:15 PM, Tomi Valkeinen wrote:
We currently manage HDMI GPIOs in the board files via
platform_enable/disable calls. This won't work with device tree, and in
any case the correct place to manage the GPIOs is in the HDMI driver.
This patch moves the handling of the GPIOs to the HDMI driver. The GPIO
handling is moved to the common hdmi.c file, and this probably needs to
be revisited when adding OMAP5 HDMI support to see if the GPIO handling
needs to be moved to IP specific files.
snip
static int __init hdmi_init_display(struct omap_dss_device *dssdev)
{
+ int r;
+
+ struct gpio gpios[] = {
+ { hdmi.ct_cp_hpd_gpio, GPIOF_OUT_INIT_LOW, hdmi_ct_cp_hpd },
+ { hdmi.ls_oe_gpio, GPIOF_OUT_INIT_LOW, hdmi_ls_oe },
+ { hdmi.hpd_gpio, GPIOF_DIR_IN, hdmi_hpd },
+ };
+
DSSDBG(init_display\n);
dss_init_hdmi_ip_ops(hdmi.ip_data);
+
+ r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
+ if (r)
+ return r;
+
Is there a reason to request these gpios in hdmi_init_display()? Why
can't these be requested simply in the probe of the hdmi platform
device. These gpios are sort of specific to the hdmi output on OMAP,
aren't they?
Well, it is a bit ugly, agreed. But I'm not sure it can be helped
easily.
First, the struct omap_dss_hdmi_data where the gpios are passed from
board file, is really panel platform data. I.e. it's attached to the
hdmi dssdev, and thus we can't handle it in hdmi output driver's probe,
as we don't have dssdevs there.
Second, the gpios are actually not OMAP HDMI stuff. They belong to the
tpd12s015 chip, sitting between OMAP HDMI output and the HDMI connector,
which is the ESD/level shifter/whatnot (I don't remember exactly what it
does =). So making the GPIOs a property of the OMAP HDMI device wouldn't
be right either.
tpd12s015 is rather simple chip, but it still has the gpios and require
special handling. I think the only way to properly handle this would be
to have a chain of external display devices, and the tpd12s015 would be
handled by a separate driver. Until then, the gpio handling is quite
hacky.
We could move the gpios to omapdss's platform data, but it would still
be wrong, and I'm not sure if it'd be any cleaner hack.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 4/8] OMAPDSS: HDMI: use vdda_hdmi_dac
On Fri, 2012-08-24 at 11:50 +0530, Archit Taneja wrote:
On Thursday 23 August 2012 07:15 PM, Tomi Valkeinen wrote:
The HDMI driver requires vdda_hdmi_dac power for operation, but does not
enable it. This has worked because the regulator has been always
enabled.
But this may not always be the case, as I encountered when implementing
HDMI device tree support.
This patch changes the HDMI driver to use the vdda_hdmi_dac.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 96a6e29..ccfc677 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -33,6 +33,7 @@
#include linux/pm_runtime.h
#include linux/clk.h
#include linux/gpio.h
+#include linux/regulator/consumer.h
#include video/omapdss.h
#include ti_hdmi.h
@@ -62,6 +63,7 @@ static struct {
struct hdmi_ip_data ip_data;
struct clk *sys_clk;
+ struct regulator *vdda_hdmi_dac_reg;
int ct_cp_hpd_gpio;
int ls_oe_gpio;
@@ -331,6 +333,19 @@ static int __init hdmi_init_display(struct
omap_dss_device *dssdev)
dss_init_hdmi_ip_ops(hdmi.ip_data);
+ if (hdmi.vdda_hdmi_dac_reg == NULL) {
+ struct regulator *reg;
+
+ reg = devm_regulator_get(hdmi.pdev-dev, vdda_hdmi_dac);
There is no corresponding devm_regulator_put() call here, I guess that's
what devm_* calls are supposed to help us with. But the only place I saw
the usage of dev_regulator_get() is here:
sound/soc/ux500/ux500_msp_dai.c
And here, they are doing devm_regulator_put() calls to, so I was
wondering what the deal is.
No idea. But there are other places also: sound/soc/codecs/wm5100.c,
sound/soc/codecs/wm8996.c, sound/soc/soc-dapm.c, and those don't use
put().
Anyway, I think it's quite clear how devm_* functions are used, so the
put call in ux500_msp_dai.c is probably just a mistake.
I also want to mention that doing the regulator_get in
hdmi_init_display() is somewhat strange, but the point is to do the
regulator_get only if a hdmi display has been defined in the board file.
If we did it unconditionally in hdmi's probe, we'd try to get the
regulator always, and it could be that there's no regulator if the hdmi
is not used on a particular board. This is again something that feels
hackish, and I'd like to find a cleaner solution to it.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
On Fri, Aug 24, 2012 at 2:30 AM, Peter Meerwald pme...@pmeerw.net wrote: On Wed, 18 Jul 2012, Javier Martinez Canillas wrote: On Wed, Jul 18, 2012 at 10:36 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Wed, Jul 18, 2012 at 1:14 PM, S, Venkatraman svenk...@ti.com wrote: On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120718 00:09]: On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren t...@atomide.com wrote: * Javier Martinez Canillas jav...@dowhile0.org [120716 23:56]: On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Hi, On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA engine API instead of the previous private DMA API implementation. So, if the kernel is built with support for any of these hosts but it doesn't support DMA devices nor OMAP DMA support, it fails when trying to obtain a DMA channel which leads to the following error on an OMAP3 IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support): [ 2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48 [2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62 selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it. Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org --- Considering, we are updating drivers to select the DMA engine, can you also include drivers/spi/spi-omap2-mcspi.c which is also updated for DMA engine. Regards Santosh Hi Santosh, Ok, I'll send a v2 now which includes spi-omap2-mcspi then. I don't think we should do this, the drivers should work with and without dma. This just needs to be added to the omap2plus_defconfig. Well this was not decided based on any DMA CONFIG option before for the subject drivers. It is already by default enabled if the DMA is supported by the driver IP. There is a possibility to disable it from driver platform/dt data so that still remains. I think it should rather be that if the driver is broken and does not work without DMA, it should have depends on CONFIG_DMA_OMAP. I can confirm that omap MMC can't work without DMA; polled mode is not supported / implemented. Same case for SPI driver as well. It uses DMA for everything except the cases where DMA doesn't make sense like 1 byte/2 byte etc. And its not configurable, At least considering this, it is better we do this per driver than enabling it at SOC config. Regards Santosh -- Hi Santosh, And what about enabling it at the SoC config level but making the drivers dependant on CONFIG_DMADEVICES and CONFIG_DMA_OMAP? If you agree I can send something like this in two different patches (one for the omap2plus_defconfig and another to make the drivers dependant on the config option): diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index b152de7..e58edc3 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -193,6 +193,8 @@ CONFIG_MMC_OMAP_HS=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_TWL92330=y CONFIG_RTC_DRV_TWL4030=y +CONFIG_DMADEVICES=y +CONFIG_DMA_OMAP=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set above has been merged, 89269ef1f0abc72c551198123e19cd4edfd43cf4 but I am missing the patches below in mainline (3.6-rc3) -- what happened? as Javier pointed out in https://patchwork.kernel.org/patch/1203391/, MMC is broken support e.g. on beagleboard unless DMA_OMAP is defined I suggest to take below patches and help to avoid some extra gray hair for people looking for a fix for non-booting beagleboards May be I am missing something, but why you would need below patch for beagle with 89269ef1f0abc72c551198123e19cd4edfd43cf4 commit enabling the DMA_OMAP for all OMAP boards. 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: [alsa-devel] [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
On Tue, 2012-08-21 at 13:05 +0100, Mark Brown wrote: On Tue, Aug 21, 2012 at 07:28:34AM +0200, Takashi Iwai wrote: Ricardo Neri wrote: I was wondering about how much sense does it make to you guys use a snd_soc_jack in this case? HD-audio already uses the generic jack event for the HDMI/DP connection change notification as well, so I think it would make sense in general. The whole problem here is that we don't *have* a generic jack interface. We've got: - sound/core/jack.c which was written to be a generic API and is used by everything that does jack support currently. - sound/core/ctljack.c which was added later and provides separate in-kernel and userspace APIs and is currently only used by HDA. - extcon which does have a good reason to be a separate API since that it's not audio specific (and is likely to be picked up by Android as the code was originally taken from there); it's currently not supported by the frameworks in ALSA. I'd suggest Pulse should be using it too. This is a complete shambles for both driver authors and userspace, the ABI varies randomly with drivers and in theory driver authors have to implement everything three times which is just nuts. What I'd like to see happening is that we merge ctljack into jack (since only HDA is going to be affected by that change it seems like the right direction to make the merge) and also add extcon support, I have looked at the extcon support. Short term for drivers used on embedded systems I'd have to recommend extcon rather than anything ALSA-specific. It's been in shambles for an absurdly long time. Would be good to actually try to tackle it again at Plumbers or sth. -- Arun -- 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 4/4] arm/dts: Add tps65217 regulator DT data to am335x-bone.dts
Hi Koen, On Fri, Aug 24, 2012 at 11:58:34, Koen Kooi wrote: Op 24 aug. 2012, om 07:50 heeft AnilKumar, Chimata anilku...@ti.com het volgende geschreven: Hi Koen, On Thu, Aug 23, 2012 at 19:43:48, Koen Kooi wrote: Op 21 aug. 2012, om 13:17 heeft AnilKumar Ch anilku...@ti.com het volgende geschreven: Add tps65217 regulator device tree data to AM335x-Bone by adding regulator consumers with tightened constraints and regulator-name. TPS65217 regulator handle can be obtained by using this regulator name. This patch also add I2C node with I2C frequency and tps65217 PMIC I2C slave address. Signed-off-by: AnilKumar Ch anilku...@ti.com I tried this and the kernel immediately crashes on my beaglebone. Could you upload the complete git tree and .config you used to test this to somewhere public please? Use this repo to test on beaglebone https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging-pinctrl This wiki talks about how to build and use? https://github.com/hvaibhav/am335x-linux/wiki/How-To-Use-Upstream-Tree Note: Enable tps65217 regulator in kernel config. I used that repo and as a seperate test I rebased that to latest mainline, same thing: as soon as I turn on the TPS in the .config it crashes on boot. Is the pinctrl repo the *exact* repo you used to test the patches on beaglebone? I tested on latest mainline after merging to am335x-upstream-staging-pinctrl (voltage also changing) Can you share your .config and uImage? My config details:- (After merge) 1. omap2plus_defconfig 2. Enable tps65217 MFD driver 3. Enable tps65217 regulator driver Thanks AnilKumar -- 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] MMC: OMAP MSDI: fix broken PIO mode
Hi,
On Fri, Aug 24, 2012 at 06:00:18AM +, Paul Walmsley wrote:
After commit 26b88520b80695a6fa5fd95b5d97c03f4daf87e0 (mmc:
omap_hsmmc: remove private DMA API implementation), the Nokia N800
here stopped booting:
[2.086181] Waiting for root device /dev/mmcblk0p1...
[2.324066] Unhandled fault: imprecise external abort (0x406) at 0x
[2.331451] Internal error: : 406 [#1] ARM
[2.335784] Modules linked in:
[2.339050] CPU: 0Not tainted (3.6.0-rc3 #60)
[2.344146] PC is at default_idle+0x28/0x30
[2.348602] LR is at trace_hardirqs_on_caller+0x15c/0x1b0
...
This turned out to be due to memory corruption caused by long-broken
PIO code in drivers/mmc/host/omap.c. (Previously, this driver had
been using DMA; but the above commit caused the MMC driver to fall
back to PIO mode with an unmodified Kconfig.)
The PIO code, added with the rest of the driver in commit
730c9b7e6630f786fcec026fb11d2e6f2c90fdcb ([MMC] Add OMAP MMC host
driver), confused bytes with 16-bit words. This bug caused memory
located after the PIO transfer buffer to be corrupted with transfers
larger than 32 bytes. The driver also did not increment the buffer
pointer after the transfer occurred. This bug resulted in data
corruption during any transfer larger than 64 bytes.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Juha Yrjölä juha.yrj...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Carlos Aguiar carlos.agu...@indt.org.br
Cc: Russell King rmk+ker...@arm.linux.org.uk
this looks good to me, though I don't have how to test. FWIW:
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mmc/host/omap.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 50e08f0..a5999a7 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -668,7 +668,7 @@ mmc_omap_clk_timer(unsigned long data)
static void
mmc_omap_xfer_data(struct mmc_omap_host *host, int write)
{
- int n;
+ int n, nwords;
if (host-buffer_bytes_left == 0) {
host-sg_idx++;
@@ -678,15 +678,23 @@ mmc_omap_xfer_data(struct mmc_omap_host *host, int
write)
n = 64;
if (n host-buffer_bytes_left)
n = host-buffer_bytes_left;
+
+ nwords = n / 2;
+ nwords += n 1; /* handle odd number of bytes to transfer */
+
host-buffer_bytes_left -= n;
host-total_bytes_left -= n;
host-data-bytes_xfered += n;
if (write) {
- __raw_writesw(host-virt_base + OMAP_MMC_REG(host, DATA),
host-buffer, n);
+ __raw_writesw(host-virt_base + OMAP_MMC_REG(host, DATA),
+ host-buffer, nwords);
} else {
- __raw_readsw(host-virt_base + OMAP_MMC_REG(host, DATA),
host-buffer, n);
+ __raw_readsw(host-virt_base + OMAP_MMC_REG(host, DATA),
+ host-buffer, nwords);
}
+
+ host-buffer += nwords;
}
static inline void mmc_omap_report_irq(u16 status)
--
1.7.10.4
--
balbi
signature.asc
Description: Digital signature
Re: linux 3.6-rc2, undefined reference to omap_musb_mailbox
On Thu, Aug 23, 2012 at 10:38:59PM +0200, Peter Meerwald wrote: On Mon, 20 Aug 2012, Felipe Balbi wrote: On Mon, Aug 20, 2012 at 04:37:28PM +0530, ABRAHAM, KISHON VIJAY wrote: Hi, On Mon, Aug 20, 2012 at 3:56 PM, Felipe Balbi ba...@ti.com wrote: On Mon, Aug 20, 2012 at 03:46:07PM +0530, ABRAHAM, KISHON VIJAY wrote: Hi, On Mon, Aug 20, 2012 at 3:24 PM, Felipe Balbi ba...@ti.com wrote: On Mon, Aug 20, 2012 at 11:06:34AM +0530, ABRAHAM, KISHON VIJAY wrote: Hi, On Sat, Aug 18, 2012 at 9:34 PM, Peter Meerwald pme...@pmeerw.net wrote: 3.6-rc2 fails to compile with CONFIG_USB_MUSB_HDRC=m CONFIG_USB_MUSB_OMAP2PLUS=m LD init/built-in.o drivers/built-in.o: In function `twl4030_usb_irq': /home/pmeerw/linux-3.6-rc2/drivers/usb/otg/twl4030-usb.c:518: undefined reference to `omap_musb_mailbox' drivers/built-in.o: In function `twl4030_usb_phy_init': /home/pmeerw/linux-3.6-rc2/drivers/usb/otg/twl4030-usb.c:540: undefined reference to `omap_musb_mailbox' Having TWL4030_USB as a module will get rid of this. I'll see how this can be resolved when some modules are *built-in* and some are made as *modules*. EXPORT_SYMBOL_GPL() should sort that out, right ? No :-( I already have EXPORT_SYMBOL_GPL() in omap2430.c. I see you're missing an extern on the function prototype (on the header). Not sure how modules.dep is generated, but maybe it needs the extern there. Can you check it out ? That isn't helping either. oh, ok... twl4030-usb is built-in... now that makes sense. Since twl4030-usb uses a symbol from omap2430, then it should depend on it, otherwise this will always happen. so add USB_MUSB_OMAP2PLUS to the depends of TWL4030_USB in drivers/usb/otg/Kconfig? correct ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb otg: TWL4030_USB depends on USB_MUSB_OMAP2PLUS in Kconfig
On Thu, Aug 23, 2012 at 10:38:44PM +0200, Peter Meerwald wrote: Signed-off-by: Peter Meerwald pme...@pmeerw.net I need a commit log explaining why we need to add this extra depend ;-) --- drivers/usb/otg/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig index 13fd1ddf..fefca18 100644 --- a/drivers/usb/otg/Kconfig +++ b/drivers/usb/otg/Kconfig @@ -58,7 +58,7 @@ config USB_ULPI_VIEWPORT config TWL4030_USB tristate TWL4030 USB Transceiver Driver - depends on TWL4030_CORE REGULATOR_TWL4030 + depends on TWL4030_CORE REGULATOR_TWL4030 USB_MUSB_OMAP2PLUS select USB_OTG_UTILS help Enable this to support the USB OTG transceiver on TWL4030 -- 1.7.9.5 -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
On Fri, 24 Aug 2012, Shilimkar, Santosh wrote: On Fri, Aug 24, 2012 at 2:30 AM, Peter Meerwald pme...@pmeerw.net wrote: On Wed, 18 Jul 2012, Javier Martinez Canillas wrote: On Wed, Jul 18, 2012 at 10:36 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Wed, Jul 18, 2012 at 1:14 PM, S, Venkatraman svenk...@ti.com wrote: On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120718 00:09]: On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren t...@atomide.com wrote: * Javier Martinez Canillas jav...@dowhile0.org [120716 23:56]: On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Hi, On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA engine API instead of the previous private DMA API implementation. So, if the kernel is built with support for any of these hosts but it doesn't support DMA devices nor OMAP DMA support, it fails when trying to obtain a DMA channel which leads to the following error on an OMAP3 IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support): [ 2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48 [2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62 selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it. Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org --- Considering, we are updating drivers to select the DMA engine, can you also include drivers/spi/spi-omap2-mcspi.c which is also updated for DMA engine. Regards Santosh Hi Santosh, Ok, I'll send a v2 now which includes spi-omap2-mcspi then. I don't think we should do this, the drivers should work with and without dma. This just needs to be added to the omap2plus_defconfig. Well this was not decided based on any DMA CONFIG option before for the subject drivers. It is already by default enabled if the DMA is supported by the driver IP. There is a possibility to disable it from driver platform/dt data so that still remains. I think it should rather be that if the driver is broken and does not work without DMA, it should have depends on CONFIG_DMA_OMAP. I can confirm that omap MMC can't work without DMA; polled mode is not supported / implemented. Same case for SPI driver as well. It uses DMA for everything except the cases where DMA doesn't make sense like 1 byte/2 byte etc. And its not configurable, At least considering this, it is better we do this per driver than enabling it at SOC config. Regards Santosh -- Hi Santosh, And what about enabling it at the SoC config level but making the drivers dependant on CONFIG_DMADEVICES and CONFIG_DMA_OMAP? If you agree I can send something like this in two different patches (one for the omap2plus_defconfig and another to make the drivers dependant on the config option): diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index b152de7..e58edc3 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -193,6 +193,8 @@ CONFIG_MMC_OMAP_HS=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_TWL92330=y CONFIG_RTC_DRV_TWL4030=y +CONFIG_DMADEVICES=y +CONFIG_DMA_OMAP=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set above has been merged, 89269ef1f0abc72c551198123e19cd4edfd43cf4 but I am missing the patches below in mainline (3.6-rc3) -- what happened? as Javier pointed out in https://patchwork.kernel.org/patch/1203391/, MMC is broken support e.g. on beagleboard unless DMA_OMAP is defined I suggest to take below patches and help to avoid some extra gray hair for people looking for a fix for non-booting beagleboards May be I am missing something, but why you would need below patch for beagle with 89269ef1f0abc72c551198123e19cd4edfd43cf4 commit enabling the DMA_OMAP for all OMAP boards. the commit just sets CONFIG_DMA_OMAP=y and CONFIG_DMADEVICES=y in omap2plus_defconfig; this does not help people updating the kernel while keeping the config, nor does it help people in configuring the kernel there is a dependency (at least for beagleboard) between MMC_OMAP_HS and DMA_OMAP, and I think this should be made explicit regards, p. -- Peter Meerwald +43-664-218 (mobile) -- 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: [PATCH v3 4/4] arm/dts: Add tps65217 regulator DT data to am335x-bone.dts
Op 24 aug. 2012, om 09:26 heeft AnilKumar, Chimata anilku...@ti.com het volgende geschreven: Hi Koen, On Fri, Aug 24, 2012 at 11:58:34, Koen Kooi wrote: Op 24 aug. 2012, om 07:50 heeft AnilKumar, Chimata anilku...@ti.com het volgende geschreven: Hi Koen, On Thu, Aug 23, 2012 at 19:43:48, Koen Kooi wrote: Op 21 aug. 2012, om 13:17 heeft AnilKumar Ch anilku...@ti.com het volgende geschreven: Add tps65217 regulator device tree data to AM335x-Bone by adding regulator consumers with tightened constraints and regulator-name. TPS65217 regulator handle can be obtained by using this regulator name. This patch also add I2C node with I2C frequency and tps65217 PMIC I2C slave address. Signed-off-by: AnilKumar Ch anilku...@ti.com I tried this and the kernel immediately crashes on my beaglebone. Could you upload the complete git tree and .config you used to test this to somewhere public please? Use this repo to test on beaglebone https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging-pinctrl This wiki talks about how to build and use? https://github.com/hvaibhav/am335x-linux/wiki/How-To-Use-Upstream-Tree Note: Enable tps65217 regulator in kernel config. I used that repo and as a seperate test I rebased that to latest mainline, same thing: as soon as I turn on the TPS in the .config it crashes on boot. Is the pinctrl repo the *exact* repo you used to test the patches on beaglebone? I tested on latest mainline after merging to am335x-upstream-staging-pinctrl (voltage also changing) Can you share your .config and uImage? Config: https://github.com/beagleboard/kernel/blob/beaglebone-3.6/patches/configs/beaglebone My config details:- (After merge) 1. omap2plus_defconfig 2. Enable tps65217 MFD driver 3. Enable tps65217 regulator driver I rebased onto latest mainline and refreshed the base patches from Vaibhav and I now get: [0.246796] tps65217 0-0024: TPS65217 ID 0xf version 1.1 So it boots! I don't know what made it break before, but it's working now :) 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
Re: [PATCH v3 4/4] arm/dts: Add tps65217 regulator DT data to am335x-bone.dts
Op 24 aug. 2012, om 09:56 heeft Koen Kooi k...@dominion.thruhere.net het volgende geschreven: Op 24 aug. 2012, om 09:26 heeft AnilKumar, Chimata anilku...@ti.com het volgende geschreven: Hi Koen, On Fri, Aug 24, 2012 at 11:58:34, Koen Kooi wrote: Op 24 aug. 2012, om 07:50 heeft AnilKumar, Chimata anilku...@ti.com het volgende geschreven: Hi Koen, On Thu, Aug 23, 2012 at 19:43:48, Koen Kooi wrote: Op 21 aug. 2012, om 13:17 heeft AnilKumar Ch anilku...@ti.com het volgende geschreven: Add tps65217 regulator device tree data to AM335x-Bone by adding regulator consumers with tightened constraints and regulator-name. TPS65217 regulator handle can be obtained by using this regulator name. This patch also add I2C node with I2C frequency and tps65217 PMIC I2C slave address. Signed-off-by: AnilKumar Ch anilku...@ti.com I tried this and the kernel immediately crashes on my beaglebone. Could you upload the complete git tree and .config you used to test this to somewhere public please? Use this repo to test on beaglebone https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging-pinctrl This wiki talks about how to build and use? https://github.com/hvaibhav/am335x-linux/wiki/How-To-Use-Upstream-Tree Note: Enable tps65217 regulator in kernel config. I used that repo and as a seperate test I rebased that to latest mainline, same thing: as soon as I turn on the TPS in the .config it crashes on boot. Is the pinctrl repo the *exact* repo you used to test the patches on beaglebone? I tested on latest mainline after merging to am335x-upstream-staging-pinctrl (voltage also changing) Can you share your .config and uImage? Config: https://github.com/beagleboard/kernel/blob/beaglebone-3.6/patches/configs/beaglebone My config details:- (After merge) 1. omap2plus_defconfig 2. Enable tps65217 MFD driver 3. Enable tps65217 regulator driver I rebased onto latest mainline and refreshed the base patches from Vaibhav and I now get: [0.246796] tps65217 0-0024: TPS65217 ID 0xf version 1.1 So it boots! I don't know what made it break before, but it's working now :) *sigh* I'm an idiot: root@beaglebone:~# uname -a Linux beaglebone 3.6.0-rc3-00103-gfd02083 #86 SMP Fri Aug 24 09:45:54 CEST 2012 armv7l GNU/Linux root@beaglebone:~# zcat /proc/config.gz | grep 217 CONFIG_MFD_TPS65217=y # CONFIG_REGULATOR_TPS65217 is not set Will retry with regulator driver actually turned on in a bit.-- 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 7/8] ir-rx51: Remove MPU wakeup latency adjustments
Hi Jean,
On 08/23/12 14:58, Jean Pihet wrote:
Hi Timo,
On Wed, Aug 22, 2012 at 9:50 PM, Timo Kokkonen timo.t.kokko...@iki.fi wrote:
That is correct. The API to use is the PM QoS API which cpuidle uses
to determine the next MPU state based on the allowed latency.
A more appropriate fix for the problem would be to modify the idle
layer so that it does not allow MPU going to too deep sleep modes when
it is expected that the timers need to wake up MPU.
The idle layer already uses the PM QoS framework to decide the next
MPU state. I think the right solution is to convert from
omap_pm_set_max_mpu_wakeup_lat to the PM QoS API.
Cf. http://marc.info/?l=linux-omapm=133968658305580w=2 for an
example of the conversion.
Thanks. It looks like really easy and straightforward conversion.
However, I couldn't find the patch you were referring to from any trees
I could find. So, I take that this API does not really have omap2
support in it yet? I tried git grepping through the source and to me it
appears there is nothing in place yet that actually restricts the MPU
sleep states on omap2 when requested.
Which puzzles me.. The patch you are referring to transfers the omap I2C
from the old omap PM API to the new QOS API is not applied yet in
mainline. The I2C is definitely working with the old API too, I'm just
wondering why I can't make it working with either of the APIs.. Am I
missing something here?
Therefore, it makes sense to actually remove this call entirely from
the ir-rx51 driver as it is both wrong and does nothing useful at the
moment.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
Regards,
Jean
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 2 --
drivers/media/rc/ir-rx51.c | 9 -
include/media/ir-rx51.h | 2 --
3 files changed, 13 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index ca07264..e0750cb 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -34,7 +34,6 @@
#include plat/gpmc.h
#include plat/onenand.h
#include plat/gpmc-smc91x.h
-#include plat/omap-pm.h
#include mach/board-rx51.h
@@ -1227,7 +1226,6 @@ static void __init rx51_init_tsc2005(void)
#if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
static struct lirc_rx51_platform_data rx51_lirc_data = {
- .set_max_mpu_wakeup_lat = omap_pm_set_max_mpu_wakeup_lat,
.pwm_timer = 9, /* Use GPT 9 for CIR */
};
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 7eed541..ac7d3f0 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -267,12 +267,6 @@ static ssize_t lirc_rx51_write(struct file *file, const
char *buf,
if (count WBUF_LEN)
lirc_rx51-wbuf[count] = -1; /* Insert termination mark */
- /*
-* Adjust latency requirements so the device doesn't go in too
-* deep sleep states
-*/
- lirc_rx51-pdata-set_max_mpu_wakeup_lat(lirc_rx51-dev, 50);
-
lirc_rx51_on(lirc_rx51);
lirc_rx51-wbuf_index = 1;
pulse_timer_set_timeout(lirc_rx51, lirc_rx51-wbuf[0]);
@@ -292,9 +286,6 @@ static ssize_t lirc_rx51_write(struct file *file, const
char *buf,
*/
lirc_rx51_stop_tx(lirc_rx51);
- /* We can sleep again */
- lirc_rx51-pdata-set_max_mpu_wakeup_lat(lirc_rx51-dev, -1);
-
return n;
}
diff --git a/include/media/ir-rx51.h b/include/media/ir-rx51.h
index 104aa89..57523f2 100644
--- a/include/media/ir-rx51.h
+++ b/include/media/ir-rx51.h
@@ -3,8 +3,6 @@
struct lirc_rx51_platform_data {
int pwm_timer;
-
- int(*set_max_mpu_wakeup_lat)(struct device *dev, long t);
};
#endif
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] OMAPDSS: Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays
On Tue, 2012-08-21 at 10:29 -0400, Raphaël Assénat wrote:
On 21/08/12 06:49 AM, Tomi Valkeinen wrote:
On Wed, 2012-08-15 at 11:26 -0400, Raphaël Assénat wrote:
+
+ /* ChiMei G121S1-L01 */
+ {
+ {
...
+ .vsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
+ .hsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
+ .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
+ .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
+ .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
Actually those 3 panels only use the DE signal. The hsync/vsync signals
are not used and on our system we mux them out to make sure they are
kept low as recommended in the panel datasheets.
Since vsync/hsync are not used, I think the vsync_level, hsync_level and
sync_pclk_edge entries could be removed. Otherwise the updated patch
works fine as is.
Okay. How do panels like that work? How can they know where a new frame
starts?
By DE being inactive for a different number of pixel clock cycles during
the vertical and horizontal blanking periods.
Ok. Interesting architecture. I wonder what's the reason for a design
like that...
Actually, I now googled for those panels, and they are all LVDS panels,
not DPI panels. So the patch doesn't look correct at all.
Do you have a DPI-to-LVDS converter chip on your board?
Yes, we do. Depending on the board, we use a SN75LVDS83B or a SN65LVDS84.
The reason for using this approach was that the panels covered by
this patch seemed not to be compatible with Flatlink 3G, which meant
driving them directly from the AM35xx SDI serial interface was not possible.
We unfortunately do not get to select which LVDS deserializer is
used at the panel side..
Ok. I'm a bit reluctant to add the panels to panel-generic-dpi.c, as
they are not DPI panels at all. Also, you should have drivers for the
DPI-to-LVDS converters. However, this cannot be done properly with the
current DSS driver model, so I'm not sure what to do with your patch.
If you had just one panel and DPI-to-LVDS chip, I'd suggest to create a
combined driver which handles both the chip and the panel. But you have
two chips and three panels...
I'm hoping the common panel framework which is being discussed on the
mailinglists will help here. For the moment, I think it's best if you
keep the panel patches in your kernel tree, and see later how to add
them to common panel framework.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 6/8] OMAPDSS: DSI: calculate dsi clock
On Fri, 2012-08-24 at 11:46 +0530, Archit Taneja wrote: On Thursday 23 August 2012 07:15 PM, Tomi Valkeinen wrote: + /* pck = TxByteClkHS * datalanes * 8 / bitsperpixel */ This formula looks a bit simplified, we aren't considering the header and footers of long packets that will add to the DDR clock. But I guess not considering these would only give a higher pixel clock than needed, which isn't that bad. Hmm. The TRM (omap4460) gives this formula in 10.3.4.5.12 How to Configure the DSI PLL in Video Mode. The headers/footers etc. are handled with adjusting the blanking periods so that DISPC and DSI Tline times match. But obviously they are not used for command mode transfers, so perhaps you have a point there. Then again, at least in theory, in command mode the DISPC pck should be configurable as high as possible because the stall mechanism should stop DISPC when DSI has had enough. And so the pck calculation is a bit unneeded for cmd mode, we could just configure pck to max. But if it's correct for video mode, and very close for cmd mode, I guess it should be fine? Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 7/8] ir-rx51: Remove MPU wakeup latency adjustments
Hi Timo, On Fri, Aug 24, 2012 at 10:14 AM, Timo Kokkonen timo.t.kokko...@iki.fi wrote: Hi Jean, On 08/23/12 14:58, Jean Pihet wrote: Hi Timo, On Wed, Aug 22, 2012 at 9:50 PM, Timo Kokkonen timo.t.kokko...@iki.fi wrote: That is correct. The API to use is the PM QoS API which cpuidle uses to determine the next MPU state based on the allowed latency. A more appropriate fix for the problem would be to modify the idle layer so that it does not allow MPU going to too deep sleep modes when it is expected that the timers need to wake up MPU. The idle layer already uses the PM QoS framework to decide the next MPU state. I think the right solution is to convert from omap_pm_set_max_mpu_wakeup_lat to the PM QoS API. Cf. http://marc.info/?l=linux-omapm=133968658305580w=2 for an example of the conversion. Thanks. It looks like really easy and straightforward conversion. However, I couldn't find the patch you were referring to from any trees Correct, this patch is not applied to the mainline code yet, it is provided as an example of the conversion. I could find. So, I take that this API does not really have omap2 support in it yet? I tried git grepping through the source and to me it appears there is nothing in place yet that actually restricts the MPU sleep states on omap2 when requested. The MPU state is controlled from the cpuidle framework, which retrieves the MPU allowed latency from the PM QoS framework. This is supported on OMAP2. Cf. the table of states and the associated latency in arch/arm/mach-omap2/cpuidle34xx.c. Which puzzles me.. The patch you are referring to transfers the omap I2C from the old omap PM API to the new QOS API is not applied yet in mainline. The I2C is definitely working with the old API too, I'm just wondering why I can't make it working with either of the APIs.. Am I missing something here? AFAIK the old API is a noop in mainline. Using the PM QoS API defnitely is supported, that is why I think the conversion needs to be performed. Therefore, it makes sense to actually remove this call entirely from the ir-rx51 driver as it is both wrong and does nothing useful at the moment. Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi Regards, Jean Thanks, Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] usb otg: TWL4030_USB to depend on USB_MUSB_OMAP2PLUS in Kconfig
3.6-rc2 fails to compile with CONFIG_USB_MUSB_HDRC=m CONFIG_USB_MUSB_OMAP2PLUS=m CONFIG_TWL4030_USB=y LD init/built-in.o drivers/built-in.o: In function `twl4030_usb_irq': /home/pmeerw/linux-3.6-rc2/drivers/usb/otg/twl4030-usb.c:518: undefined reference to `omap_musb_mailbox' drivers/built-in.o: In function `twl4030_usb_phy_init': /home/pmeerw/linux-3.6-rc2/drivers/usb/otg/twl4030-usb.c:540: undefined reference to `omap_musb_mailbox' twl4030-usb uses a symbol from omap2430, hence it should depend on it Signed-off-by: Peter Meerwald pme...@pmeerw.net --- drivers/usb/otg/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig index 13fd1ddf..fefca18 100644 --- a/drivers/usb/otg/Kconfig +++ b/drivers/usb/otg/Kconfig @@ -58,7 +58,7 @@ config USB_ULPI_VIEWPORT config TWL4030_USB tristate TWL4030 USB Transceiver Driver - depends on TWL4030_CORE REGULATOR_TWL4030 + depends on TWL4030_CORE REGULATOR_TWL4030 USB_MUSB_OMAP2PLUS select USB_OTG_UTILS help Enable this to support the USB OTG transceiver on TWL4030 -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] OMAPDSS: DSI: calculate dsi clock
On Friday 24 August 2012 02:25 PM, Tomi Valkeinen wrote: On Fri, 2012-08-24 at 11:46 +0530, Archit Taneja wrote: On Thursday 23 August 2012 07:15 PM, Tomi Valkeinen wrote: + /* pck = TxByteClkHS * datalanes * 8 / bitsperpixel */ This formula looks a bit simplified, we aren't considering the header and footers of long packets that will add to the DDR clock. But I guess not considering these would only give a higher pixel clock than needed, which isn't that bad. Hmm. The TRM (omap4460) gives this formula in 10.3.4.5.12 How to Configure the DSI PLL in Video Mode. The headers/footers etc. are handled with adjusting the blanking periods so that DISPC and DSI Tline times match. But obviously they are not used for command mode transfers, so perhaps you have a point there. Then again, at least in theory, in command mode the DISPC pck should be configurable as high as possible because the stall mechanism should stop DISPC when DSI has had enough. And so the pck calculation is a bit unneeded for cmd mode, we could just configure pck to max. But if it's correct for video mode, and very close for cmd mode, I guess it should be fine? Yes, it's fine, and we shouldn't try to have an unnecessarily high pixel clock in command mode anyway, that would reduce the amount of downscaling we could do. Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] backlight: Add TPS65217 WLED driver
Op 22 aug. 2012, om 23:04 heeft Matthias Kaehlcke matth...@kaehlcke.net het volgende geschreven: The TPS65217 chip contains a boost converter and current sinks which can be used to drive LEDs for use as backlights. Expose this functionality via the backlight API. Tested on an AM335x based custom board with a single WLED string, using different values for ISEL and FDIM (though it would be hard to tell the difference except for the value in WLEDCTRL1). Both instantiation through the device tree and by passing platform data have been tested. Testing has been done with an Androidized 3.2 kernel from the rowboat project This patch is based on the mfd/for-next branch (20120822) Changes since v2: * adapted to the latest version of the tps65217 mfd driver * register backlight as mfd subdevice * allocate struct tps65217_bl after validation of the device tree/platform data Signed-off-by: Matthias Kaehlcke matth...@kaehlcke.net Work beautifully on a beaglebone + 3 LCD cape, although there's no FB driver yet: Tested-by: Koen Kooi k...@dominion.thruhere.net-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
On Fri, Aug 24, 2012 at 09:51:15AM +0200, Peter Meerwald wrote: the commit just sets CONFIG_DMA_OMAP=y and CONFIG_DMADEVICES=y in omap2plus_defconfig; this does not help people updating the kernel while keeping the config, nor does it help people in configuring the kernel there is a dependency (at least for beagleboard) between MMC_OMAP_HS and DMA_OMAP, and I think this should be made explicit Well, this is where stuff starts to get really yucky, because that means if you have DMA_OMAP as a module, you have to have MMC_OMAP_HS as a module too. Or vice versa. Which is a real pain for further development of DMA_OMAP. Whatever, the solution here is NOT to add select statements to the Kconfig to force DMA engine support and DMA_OMAP to 'y' for OMAP. The best solution is for MMC_OMAP_HS to depend on DMA_OMAP, but that will just mean that you'll end up with MMC_OMAP_HS disabled in your config witout DMA engine support. Another less desirable solution is to have MMC_OMAP_HS select DMA engine and DMA_OMAP. -- 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 2/8] ir-rx51: Handle signals properly
On Wed, Aug 22, 2012 at 10:50:35PM +0300, Timo Kokkonen wrote:
The lirc-dev expects the ir-code to be transmitted when the write call
returns back to the user space. We should not leave TX ongoing no
matter what is the reason we return to the user space. Easiest
solution for that is to simply remove interruptible sleeps.
The first wait_event_interruptible is thus replaced with return -EBUSY
in case there is still ongoing transfer. This should suffice as the
concept of sending multiple codes in parallel does not make sense.
The second wait_event_interruptible call is replaced with
wait_even_timeout with a fixed and safe timeout that should prevent
the process from getting stuck in kernel for too long.
Also, from now on we will force the TX to stop before we return from
write call. If the TX happened to time out for some reason, we should
not leave the HW transmitting anything.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
drivers/media/rc/ir-rx51.c | 39 ---
1 file changed, 28 insertions(+), 11 deletions(-)
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 9487dd3..a7b787a 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -74,6 +74,19 @@ static void lirc_rx51_off(struct lirc_rx51 *lirc_rx51)
OMAP_TIMER_TRIGGER_NONE);
}
+static void lirc_rx51_stop_tx(struct lirc_rx51 *lirc_rx51)
+{
+ if (lirc_rx51-wbuf_index 0)
+ return;
+
+ lirc_rx51_off(lirc_rx51);
+ lirc_rx51-wbuf_index = -1;
+ omap_dm_timer_stop(lirc_rx51-pwm_timer);
+ omap_dm_timer_stop(lirc_rx51-pulse_timer);
+ omap_dm_timer_set_int_enable(lirc_rx51-pulse_timer, 0);
+ wake_up_interruptible(lirc_rx51-wqueue);
Unless I'm mistaken, wait_up_interruptable() won't wake up any
non-interruptable sleepers. Should this not be wake_up()?
+}
+
static int init_timing_params(struct lirc_rx51 *lirc_rx51)
{
u32 load, match;
@@ -160,13 +173,7 @@ static irqreturn_t lirc_rx51_interrupt_handler(int irq,
void *ptr)
return IRQ_HANDLED;
end:
- /* Stop TX here */
- lirc_rx51_off(lirc_rx51);
- lirc_rx51-wbuf_index = -1;
- omap_dm_timer_stop(lirc_rx51-pwm_timer);
- omap_dm_timer_stop(lirc_rx51-pulse_timer);
- omap_dm_timer_set_int_enable(lirc_rx51-pulse_timer, 0);
- wake_up_interruptible(lirc_rx51-wqueue);
+ lirc_rx51_stop_tx(lirc_rx51);
return IRQ_HANDLED;
}
@@ -246,8 +253,9 @@ static ssize_t lirc_rx51_write(struct file *file, const
char *buf,
if ((count WBUF_LEN) || (count % 2 == 0))
return -EINVAL;
- /* Wait any pending transfers to finish */
- wait_event_interruptible(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0);
+ /* We can have only one transmit at a time */
+ if (lirc_rx51-wbuf_index = 0)
+ return -EBUSY;
if (copy_from_user(lirc_rx51-wbuf, buf, n))
return -EFAULT;
@@ -273,9 +281,18 @@ static ssize_t lirc_rx51_write(struct file *file, const
char *buf,
/*
* Don't return back to the userspace until the transfer has
- * finished
+ * finished. However, we wish to not spend any more than 500ms
+ * in kernel. No IR code TX should ever take that long.
+ */
+ i = wait_event_timeout(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0,
Note non-interruptable sleeper.
+ HZ / 2);
+
+ /*
+ * Ensure transmitting has really stopped, even if the timers
+ * went mad or something else happened that caused it still
+ * sending out something.
*/
- wait_event_interruptible(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0);
+ lirc_rx51_stop_tx(lirc_rx51);
/* We can sleep again */
lirc_rx51-pdata-set_max_mpu_wakeup_lat(lirc_rx51-dev, -1);
--
1.7.12
--
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] usb otg: TWL4030_USB depends on USB_MUSB_OMAP2PLUS in Kconfig
Hi, On Fri, Aug 24, 2012 at 12:57 PM, Felipe Balbi ba...@ti.com wrote: On Thu, Aug 23, 2012 at 10:38:44PM +0200, Peter Meerwald wrote: Signed-off-by: Peter Meerwald pme...@pmeerw.net I need a commit log explaining why we need to add this extra depend ;-) --- drivers/usb/otg/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig index 13fd1ddf..fefca18 100644 --- a/drivers/usb/otg/Kconfig +++ b/drivers/usb/otg/Kconfig @@ -58,7 +58,7 @@ config USB_ULPI_VIEWPORT config TWL4030_USB tristate TWL4030 USB Transceiver Driver - depends on TWL4030_CORE REGULATOR_TWL4030 + depends on TWL4030_CORE REGULATOR_TWL4030 USB_MUSB_OMAP2PLUS Can you add this for twl6030 also? Thanks Kishon -- 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/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
On Fri, Aug 24, 2012 at 3:12 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Aug 24, 2012 at 09:51:15AM +0200, Peter Meerwald wrote: the commit just sets CONFIG_DMA_OMAP=y and CONFIG_DMADEVICES=y in omap2plus_defconfig; this does not help people updating the kernel while keeping the config, nor does it help people in configuring the kernel there is a dependency (at least for beagleboard) between MMC_OMAP_HS and DMA_OMAP, and I think this should be made explicit Well, this is where stuff starts to get really yucky, because that means if you have DMA_OMAP as a module, you have to have MMC_OMAP_HS as a module too. Or vice versa. Which is a real pain for further development of DMA_OMAP. Whatever, the solution here is NOT to add select statements to the Kconfig to force DMA engine support and DMA_OMAP to 'y' for OMAP. The best solution is for MMC_OMAP_HS to depend on DMA_OMAP, but that will just mean that you'll end up with MMC_OMAP_HS disabled in your config witout DMA engine support. Another less desirable solution is to have MMC_OMAP_HS select DMA engine and DMA_OMAP. Part of the patch [1] does the last part. MMC_OMAP_HS select DMA engine and DMA_OMAP. Regards Santosh [1] https://patchwork.kernel.org/patch/1203391/ -- 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 2/8] ir-rx51: Handle signals properly
On 08/24/12 13:03, Sean Young wrote:
On Wed, Aug 22, 2012 at 10:50:35PM +0300, Timo Kokkonen wrote:
The lirc-dev expects the ir-code to be transmitted when the write call
returns back to the user space. We should not leave TX ongoing no
matter what is the reason we return to the user space. Easiest
solution for that is to simply remove interruptible sleeps.
The first wait_event_interruptible is thus replaced with return -EBUSY
in case there is still ongoing transfer. This should suffice as the
concept of sending multiple codes in parallel does not make sense.
The second wait_event_interruptible call is replaced with
wait_even_timeout with a fixed and safe timeout that should prevent
the process from getting stuck in kernel for too long.
Also, from now on we will force the TX to stop before we return from
write call. If the TX happened to time out for some reason, we should
not leave the HW transmitting anything.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
drivers/media/rc/ir-rx51.c | 39 ---
1 file changed, 28 insertions(+), 11 deletions(-)
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 9487dd3..a7b787a 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -74,6 +74,19 @@ static void lirc_rx51_off(struct lirc_rx51 *lirc_rx51)
OMAP_TIMER_TRIGGER_NONE);
}
+static void lirc_rx51_stop_tx(struct lirc_rx51 *lirc_rx51)
+{
+if (lirc_rx51-wbuf_index 0)
+return;
+
+lirc_rx51_off(lirc_rx51);
+lirc_rx51-wbuf_index = -1;
+omap_dm_timer_stop(lirc_rx51-pwm_timer);
+omap_dm_timer_stop(lirc_rx51-pulse_timer);
+omap_dm_timer_set_int_enable(lirc_rx51-pulse_timer, 0);
+wake_up_interruptible(lirc_rx51-wqueue);
Unless I'm mistaken, wait_up_interruptable() won't wake up any
non-interruptable sleepers. Should this not be wake_up()?
Thanks for pointing out that. I guess I never noticed that because I'm
using a timeout with the wait, so it will wake up anyway. I'll fix it.
-Timo
+}
+
static int init_timing_params(struct lirc_rx51 *lirc_rx51)
{
u32 load, match;
@@ -160,13 +173,7 @@ static irqreturn_t lirc_rx51_interrupt_handler(int irq,
void *ptr)
return IRQ_HANDLED;
end:
-/* Stop TX here */
-lirc_rx51_off(lirc_rx51);
-lirc_rx51-wbuf_index = -1;
-omap_dm_timer_stop(lirc_rx51-pwm_timer);
-omap_dm_timer_stop(lirc_rx51-pulse_timer);
-omap_dm_timer_set_int_enable(lirc_rx51-pulse_timer, 0);
-wake_up_interruptible(lirc_rx51-wqueue);
+lirc_rx51_stop_tx(lirc_rx51);
return IRQ_HANDLED;
}
@@ -246,8 +253,9 @@ static ssize_t lirc_rx51_write(struct file *file, const
char *buf,
if ((count WBUF_LEN) || (count % 2 == 0))
return -EINVAL;
-/* Wait any pending transfers to finish */
-wait_event_interruptible(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0);
+/* We can have only one transmit at a time */
+if (lirc_rx51-wbuf_index = 0)
+return -EBUSY;
if (copy_from_user(lirc_rx51-wbuf, buf, n))
return -EFAULT;
@@ -273,9 +281,18 @@ static ssize_t lirc_rx51_write(struct file *file, const
char *buf,
/*
* Don't return back to the userspace until the transfer has
- * finished
+ * finished. However, we wish to not spend any more than 500ms
+ * in kernel. No IR code TX should ever take that long.
+ */
+i = wait_event_timeout(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0,
Note non-interruptable sleeper.
+HZ / 2);
+
+/*
+ * Ensure transmitting has really stopped, even if the timers
+ * went mad or something else happened that caused it still
+ * sending out something.
*/
-wait_event_interruptible(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0);
+lirc_rx51_stop_tx(lirc_rx51);
/* We can sleep again */
lirc_rx51-pdata-set_max_mpu_wakeup_lat(lirc_rx51-dev, -1);
--
1.7.12
--
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
--
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/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
On Fri, Aug 24, 2012 at 03:51:26PM +0530, Shilimkar, Santosh wrote: On Fri, Aug 24, 2012 at 3:12 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Aug 24, 2012 at 09:51:15AM +0200, Peter Meerwald wrote: the commit just sets CONFIG_DMA_OMAP=y and CONFIG_DMADEVICES=y in omap2plus_defconfig; this does not help people updating the kernel while keeping the config, nor does it help people in configuring the kernel there is a dependency (at least for beagleboard) between MMC_OMAP_HS and DMA_OMAP, and I think this should be made explicit Well, this is where stuff starts to get really yucky, because that means if you have DMA_OMAP as a module, you have to have MMC_OMAP_HS as a module too. Or vice versa. Which is a real pain for further development of DMA_OMAP. Whatever, the solution here is NOT to add select statements to the Kconfig to force DMA engine support and DMA_OMAP to 'y' for OMAP. The best solution is for MMC_OMAP_HS to depend on DMA_OMAP, but that will just mean that you'll end up with MMC_OMAP_HS disabled in your config witout DMA engine support. Another less desirable solution is to have MMC_OMAP_HS select DMA engine and DMA_OMAP. Part of the patch [1] does the last part. MMC_OMAP_HS select DMA engine and DMA_OMAP. Regards Santosh [1] https://patchwork.kernel.org/patch/1203391/ Well, I never saw that patch. When I say I'm going to be away for most of July, and I won't be reading email, and I won't catch up with email when I'm back and when I get back I explicitly ask for stuff which needs my attention sending, that's hardly surprising... But anyway, as I said above, the select option is less desirable because it forces stuff. And if you've seen the kind of crap that you have to go through to figure out why the hell you can't disable an option, you'll understand why I consider that solution revolting. Take, for instance, a list of dependencies spits out by menuconfig that fills your entire screen, and you have to work out by reading carefully through 2K of characters which combination of options is forcing the one you want to turn off back on. That is why select used inappropriately is pure evil incarnate. -- 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/23] OMAP UART patches
Forgot to Cc greg initially, my bad On Thu, Aug 23, 2012 at 01:32:40PM +0300, Felipe Balbi wrote: Hi guys, here's v3 and hopefully final version of this series. A whole bunch of new patches added but the good thing is that now I had another engineer's help to test, so he's got his Tested-by in all patches. Changes since v2: . Added a bunch of new patches . Fixed a problem where we would always return IRQ_NONE even though we handled IRQ Changes since v1: . improved commit log on patch 9/13 (formerly 10/13) . removed patch 2/13 . added a new patch switching from spin_lock_irqsave() to spin_lock and spin_unlock_irqrestore to spin_unlock Alan, if you prefer in pull request form, here it is: The following changes since commit d9875690d9b89a866022ff49e3fcea892345ad92: Linux 3.6-rc2 (2012-08-16 14:51:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git uart for you to fetch changes up to a29230f14d8466c9b8c25171715378bf52189453: serial: omap: enable RX and TX FIFO usage (2012-08-23 09:25:16 +0300) Felipe Balbi (20): serial: omap: define and use to_uart_omap_port() serial: omap: define helpers for pdata function pointers serial: omap: don't access the platform_device serial: omap: drop DMA support serial: add OMAP-specific defines serial: omap: simplify IRQ handling serial: omap: refactor receive_chars() into rdi/rlsi handlers serial: omap: move THRE check to transmit_chars() serial: omap: stick to put_autosuspend serial: omap: set dev-drvdata before enabling pm_runtime serial: omap: drop unnecessary check from remove serial: omap: make sure to suspend device before remove serial: omap: don't save IRQ flags on hardirq serial: omap: optimization with section annotations serial: omap: drop inline from IRQ handler prototype serial: omap: implement set_wake serial: omap: make sure to put() on poll_get_char serial: omap: remove unnecessary header and add a missing one serial: omap: move uart_omap_port definition to C file serial: omap: enable RX and TX FIFO usage Ruchika Kharwar (2): serial: omap: fix sequence of pm_runtime_* calls. serial: omap: unlock the port lock Vikram Pandita (1): serial: omap: fix software flow control arch/arm/mach-omap2/serial.c | 15 +- arch/arm/plat-omap/include/plat/omap-serial.h | 47 +- drivers/tty/serial/omap-serial.c | 808 ++ include/linux/serial_reg.h| 4 + 4 files changed, 330 insertions(+), 544 deletions(-) -- 1.7.12.rc3 -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
On Fri, Aug 24, 2012 at 4:09 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Aug 24, 2012 at 03:51:26PM +0530, Shilimkar, Santosh wrote: On Fri, Aug 24, 2012 at 3:12 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Aug 24, 2012 at 09:51:15AM +0200, Peter Meerwald wrote: the commit just sets CONFIG_DMA_OMAP=y and CONFIG_DMADEVICES=y in omap2plus_defconfig; this does not help people updating the kernel while keeping the config, nor does it help people in configuring the kernel there is a dependency (at least for beagleboard) between MMC_OMAP_HS and DMA_OMAP, and I think this should be made explicit Well, this is where stuff starts to get really yucky, because that means if you have DMA_OMAP as a module, you have to have MMC_OMAP_HS as a module too. Or vice versa. Which is a real pain for further development of DMA_OMAP. Whatever, the solution here is NOT to add select statements to the Kconfig to force DMA engine support and DMA_OMAP to 'y' for OMAP. The best solution is for MMC_OMAP_HS to depend on DMA_OMAP, but that will just mean that you'll end up with MMC_OMAP_HS disabled in your config witout DMA engine support. Another less desirable solution is to have MMC_OMAP_HS select DMA engine and DMA_OMAP. Part of the patch [1] does the last part. MMC_OMAP_HS select DMA engine and DMA_OMAP. Regards Santosh [1] https://patchwork.kernel.org/patch/1203391/ Well, I never saw that patch. When I say I'm going to be away for most of July, and I won't be reading email, and I won't catch up with email when I'm back and when I get back I explicitly ask for stuff which needs my attention sending, that's hardly surprising... But anyway, as I said above, the select option is less desirable because it forces stuff. And if you've seen the kind of crap that you have to go through to figure out why the hell you can't disable an option, you'll understand why I consider that solution revolting. Take, for instance, a list of dependencies spits out by menuconfig that fills your entire screen, and you have to work out by reading carefully through 2K of characters which combination of options is forcing the one you want to turn off back on. That is why select used inappropriately is pure evil incarnate. I fully agree on the select and it's undesirable side effects. Since the polling mode isn't supported yet on OMAP MMC drivers, there was no choice. As per the previous discussion on [1], MMC and SPI driver folks are looking at supporting polling mode support which can remove the force select needed for OMAP_DMA. Regards santosh 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: [PATCH 7/8] ir-rx51: Remove MPU wakeup latency adjustments
On 08/24/12 12:04, Jean Pihet wrote: Hi Timo, On Fri, Aug 24, 2012 at 10:14 AM, Timo Kokkonen timo.t.kokko...@iki.fi wrote: Hi Jean, On 08/23/12 14:58, Jean Pihet wrote: Hi Timo, On Wed, Aug 22, 2012 at 9:50 PM, Timo Kokkonen timo.t.kokko...@iki.fi wrote: That is correct. The API to use is the PM QoS API which cpuidle uses to determine the next MPU state based on the allowed latency. A more appropriate fix for the problem would be to modify the idle layer so that it does not allow MPU going to too deep sleep modes when it is expected that the timers need to wake up MPU. The idle layer already uses the PM QoS framework to decide the next MPU state. I think the right solution is to convert from omap_pm_set_max_mpu_wakeup_lat to the PM QoS API. Cf. http://marc.info/?l=linux-omapm=133968658305580w=2 for an example of the conversion. Thanks. It looks like really easy and straightforward conversion. However, I couldn't find the patch you were referring to from any trees Correct, this patch is not applied to the mainline code yet, it is provided as an example of the conversion. I could find. So, I take that this API does not really have omap2 support in it yet? I tried git grepping through the source and to me it appears there is nothing in place yet that actually restricts the MPU sleep states on omap2 when requested. The MPU state is controlled from the cpuidle framework, which retrieves the MPU allowed latency from the PM QoS framework. This is supported on OMAP2. Cf. the table of states and the associated latency in arch/arm/mach-omap2/cpuidle34xx.c. Thanks for the pointer. I took a look at the state table and adjusted the latency requirements in my code. If I lower the latency from 50us to 10us, the timers are then waking up as they should be. I'll replace this patch with one where I convert it using the new API. Thanks! -Timo -- 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/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
the commit just sets CONFIG_DMA_OMAP=y and CONFIG_DMADEVICES=y in omap2plus_defconfig; this does not help people updating the kernel while keeping the config, nor does it help people in configuring the kernel there is a dependency (at least for beagleboard) between MMC_OMAP_HS and DMA_OMAP, and I think this should be made explicit Well, this is where stuff starts to get really yucky, because that means if you have DMA_OMAP as a module, you have to have MMC_OMAP_HS as a module too. Or vice versa. Which is a real pain for further development of DMA_OMAP. Whatever, the solution here is NOT to add select statements to the Kconfig to force DMA engine support and DMA_OMAP to 'y' for OMAP. The best solution is for MMC_OMAP_HS to depend on DMA_OMAP, but that will just mean that you'll end up with MMC_OMAP_HS disabled in your config witout DMA engine support. Another less desirable solution is to have MMC_OMAP_HS select DMA engine and DMA_OMAP. Part of the patch [1] does the last part. MMC_OMAP_HS select DMA engine and DMA_OMAP. Regards Santosh [1] https://patchwork.kernel.org/patch/1203391/ Well, I never saw that patch. When I say I'm going to be away for most of July, and I won't be reading email, and I won't catch up with email when I'm back and when I get back I explicitly ask for stuff which needs my attention sending, that's hardly surprising... But anyway, as I said above, the select option is less desirable because it forces stuff. And if you've seen the kind of crap that you have to go through to figure out why the hell you can't disable an option, you'll understand why I consider that solution revolting. Take, for instance, a list of dependencies spits out by menuconfig that fills your entire screen, and you have to work out by reading carefully through 2K of characters which combination of options is forcing the one you want to turn off back on. That is why select used inappropriately is pure evil incarnate. I fully agree on the select and it's undesirable side effects. Since the polling mode isn't supported yet on OMAP MMC drivers, there was no choice. As per the previous discussion on [1], MMC and SPI driver folks are looking at supporting polling mode support which can remove the force select needed for OMAP_DMA. with Linux 3.6-rc3: CONFIG_DMA_OMAP=m CONFIG_DMA_ENGINE=y CONFIG_DMA_VIRTUAL_CHANNELS=m CONFIG_MMC_OMAP_HS=y CONFIG_SPI_OMAP24XX=y CONFIG_MTD_NAND_OMAP2=y LD init/built-in.o drivers/built-in.o: In function `omap2_mcspi_setup': /home/pmeerw/linux-pmeerw/drivers/spi/spi-omap2-mcspi.c:859: undefined reference to `omap_dma_filter_fn' drivers/built-in.o: In function `omap_nand_probe': /home/pmeerw/linux-pmeerw/drivers/mtd/nand/omap2.c:1371: undefined reference to `omap_dma_filter_fn' drivers/built-in.o: In function `omap_hsmmc_probe': /home/pmeerw/linux-pmeerw/drivers/mmc/host/omap_hsmmc.c:2039: undefined reference to `omap_dma_filter_fn' make: *** [vmlinux] Error 1 in addition to SPI and MMC, there seems to be also a NAND dependency regards, p. -- Peter Meerwald +43-664-218 (mobile) -- 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 01/23] OMAPDSS: outputs: Create a new entity called outputs
On Tue, 2012-08-21 at 11:28 +0530, Archit Taneja wrote:
diff --git a/drivers/video/omap2/dss/output.c
b/drivers/video/omap2/dss/output.c
new file mode 100644
index 000..034ebbe
--- /dev/null
+++ b/drivers/video/omap2/dss/output.c
@@ -0,0 +1,58 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Ltd
+ * Author: Archit Taneja arc...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * 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/kernel.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+#include video/omapdss.h
+
+#include dss.h
+
+static struct list_head output_list;
You can do:
static LIST_HEAD(output_list);
Then you don't need to initialize it separately.
+
+struct omap_dss_output *dss_create_output(struct platform_device *pdev)
+{
+ struct omap_dss_output *out;
+
+ out = kzalloc(sizeof(struct omap_dss_output *), GFP_KERNEL);
+ if (!out)
+ return NULL;
A patch that adds kzalloc but no free is always a bit suspicious =).
+
+ out-pdev = pdev;
+
+ list_add_tail(out-list, output_list);
+
+ return out;
+}
Instead of allocating omap_dss_output here, you could let the caller do
it, and only initialize it here with default values (if that's even
needed). Then the caller can use kzalloc, or can just embed the stuct
into its own data-struct, which may be often a better choice.
+struct omap_dss_output *omap_dss_get_output(enum omap_dss_output_id id)
+{
+ struct omap_dss_output *out;
+
+ list_for_each_entry(out, output_list, list) {
+ if (out-id == id)
+ return out;
+ }
+
+ return NULL;
+}
+
+void dss_init_outputs(void)
+{
+ INIT_LIST_HEAD(output_list);
+}
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index b868123..0ba613f 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -207,6 +207,16 @@ enum omap_hdmi_flags {
OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP = 1 0,
};
+enum omap_dss_output_id {
+ OMAP_DSS_OUTPUT_DPI = 1 0,
+ OMAP_DSS_OUTPUT_DBI = 1 1,
+ OMAP_DSS_OUTPUT_SDI = 1 2,
+ OMAP_DSS_OUTPUT_DSI1= 1 3,
+ OMAP_DSS_OUTPUT_VENC= 1 4,
+ OMAP_DSS_OUTPUT_DSI2= 1 5,
+ OMAP_DSS_OUTPUT_HDMI= 1 6,
+};
I'm not sure about this. We already have enum omap_display_type. If you
need the instance number, you could have that as a separate int field.
Where do you need the output_id?
+
/* RFBI */
struct rfbi_timings {
@@ -492,6 +502,24 @@ struct omap_dsi_pin_config {
int pins[OMAP_DSS_MAX_DSI_PINS];
};
+struct omap_dss_output {
+ struct list_head list;
+
+ /* display type supported by the output */
+ enum omap_display_type type;
+
+ /* output instance */
+ enum omap_dss_output_id id;
So instead of omap_dss_output_id, you'd have omap_display_type type and
int id, which together tell the supported output and also the output
driver instance.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 01/23] OMAPDSS: outputs: Create a new entity called outputs
On Friday 24 August 2012 06:11 PM, Tomi Valkeinen wrote:
On Tue, 2012-08-21 at 11:28 +0530, Archit Taneja wrote:
diff --git a/drivers/video/omap2/dss/output.c b/drivers/video/omap2/dss/output.c
new file mode 100644
index 000..034ebbe
--- /dev/null
+++ b/drivers/video/omap2/dss/output.c
@@ -0,0 +1,58 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Ltd
+ * Author: Archit Taneja arc...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * 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/kernel.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+#include video/omapdss.h
+
+#include dss.h
+
+static struct list_head output_list;
You can do:
static LIST_HEAD(output_list);
Then you don't need to initialize it separately.
Oh ok. I'll fix this.
+
+struct omap_dss_output *dss_create_output(struct platform_device *pdev)
+{
+ struct omap_dss_output *out;
+
+ out = kzalloc(sizeof(struct omap_dss_output *), GFP_KERNEL);
+ if (!out)
+ return NULL;
A patch that adds kzalloc but no free is always a bit suspicious =).
+
+ out-pdev = pdev;
+
+ list_add_tail(out-list, output_list);
+
+ return out;
+}
Instead of allocating omap_dss_output here, you could let the caller do
it, and only initialize it here with default values (if that's even
needed). Then the caller can use kzalloc, or can just embed the stuct
into its own data-struct, which may be often a better choice.
So output can be in each interface driver's private data, and we just
add that to our list of outputs?
+struct omap_dss_output *omap_dss_get_output(enum omap_dss_output_id id)
+{
+ struct omap_dss_output *out;
+
+ list_for_each_entry(out, output_list, list) {
+ if (out-id == id)
+ return out;
+ }
+
+ return NULL;
+}
+
+void dss_init_outputs(void)
+{
+ INIT_LIST_HEAD(output_list);
+}
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index b868123..0ba613f 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -207,6 +207,16 @@ enum omap_hdmi_flags {
OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP = 1 0,
};
+enum omap_dss_output_id {
+ OMAP_DSS_OUTPUT_DPI = 1 0,
+ OMAP_DSS_OUTPUT_DBI = 1 1,
+ OMAP_DSS_OUTPUT_SDI = 1 2,
+ OMAP_DSS_OUTPUT_DSI1= 1 3,
+ OMAP_DSS_OUTPUT_VENC= 1 4,
+ OMAP_DSS_OUTPUT_DSI2= 1 5,
+ OMAP_DSS_OUTPUT_HDMI= 1 6,
+};
I'm not sure about this. We already have enum omap_display_type. If you
need the instance number, you could have that as a separate int field.
Where do you need the output_id?
output_id is used to take care of situations where there our multiple
outputs of the same type, like DSI1 and DSI2. An enum helps when we
check if an overlay manager supports that output instance or not. For
ex, on OMAP4, LCD1 connects to DSI1 and not DSI2.
I add a func called dss_feat_get_supported_outputs(channel) later to
check for this. When setting a new output for a manager, we just do an
'' to see if the output in question is in the mask of the manager's set
of supported outputs.
+
/* RFBI */
struct rfbi_timings {
@@ -492,6 +502,24 @@ struct omap_dsi_pin_config {
int pins[OMAP_DSS_MAX_DSI_PINS];
};
+struct omap_dss_output {
+ struct list_head list;
+
+ /* display type supported by the output */
+ enum omap_display_type type;
+
+ /* output instance */
+ enum omap_dss_output_id id;
So instead of omap_dss_output_id, you'd have omap_display_type type and
int id, which together tell the supported output and also the output
driver instance.
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: [PATCH 02/23] OMAPDSS: outputs: Create and initialize output instances
On Tue, 2012-08-21 at 11:28 +0530, Archit Taneja wrote:
Create output instances by having an init function in the probes of the
platform
device drivers for different interfaces. Create a small function for each
interface to initialize the output entity's fields type and id.
In the probe of each interface driver, the output entities are created before
the *_probe_pdata() functions intentionally. This is done to ensure that the
output entity is prepared before the panels connected to the output are
registered. We need the output entities to be ready because OMAPDSS will try
to make connections between overlays, managers, outputs and devices during the
panel's probe.
You're referring to the recheck_connections stuff? I have a patch that
moves that to omapfb side. But of course it doesn't hurt to initialize
the output early.
We should generally do the initialization in output driver's probe more
or less so that we first setup everything related to the output driver,
and after that we register the dssdevs. But I think that's what is
already done.
So, no complaints =).
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dpi.c | 20
drivers/video/omap2/dss/dsi.c | 26 --
drivers/video/omap2/dss/hdmi.c | 18 ++
drivers/video/omap2/dss/rfbi.c | 19 +++
drivers/video/omap2/dss/sdi.c | 20
drivers/video/omap2/dss/venc.c | 20
6 files changed, 121 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index f260343..4eca2e7 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -408,10 +408,30 @@ static void __init dpi_probe_pdata(struct
platform_device *pdev)
}
}
+static int __init dpi_init_output(struct platform_device *pdev)
+{
+ struct omap_dss_output *out;
+
+ out = dss_create_output(pdev);
+ if (!out)
+ return -ENOMEM;
+
+ out-id = OMAP_DSS_OUTPUT_DPI;
+ out-type = OMAP_DISPLAY_TYPE_DPI;
+
+ return 0;
+}
+
static int __init omap_dpi_probe(struct platform_device *pdev)
{
+ int r;
+
mutex_init(dpi.lock);
+ r = dpi_init_output(pdev);
+ if (r)
+ return r;
+
dpi_probe_pdata(pdev);
return 0;
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 659b6cd..22e0873 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4903,6 +4903,23 @@ static void __init dsi_probe_pdata(struct
platform_device *dsidev)
}
}
+static int __init dsi_init_output(struct platform_device *dsidev,
+ struct dsi_data *dsi)
+{
+ struct omap_dss_output *out;
+
+ out = dss_create_output(dsidev);
+ if (!out)
+ return -ENOMEM;
+
+ out-id = dsi-module_id == 0 ?
+ OMAP_DSS_OUTPUT_DSI1 : OMAP_DSS_OUTPUT_DSI2;
+
+ out-type = OMAP_DISPLAY_TYPE_DSI;
+
+ return 0;
As I mentioned in the last email, I think this could be something like:
struct omap_dss_output *out = dsi-output;
out-pdev = dsidev;
out-id = xxx;
out-type = yyy;
dss_register_output(out);
+}
+
/* DSI1 HW IP initialisation */
static int __init omap_dsihw_probe(struct platform_device *dsidev)
{
@@ -4997,10 +5014,14 @@ static int __init omap_dsihw_probe(struct
platform_device *dsidev)
else
dsi-num_lanes_supported = 3;
- dsi_probe_pdata(dsidev);
-
dsi_runtime_put(dsidev);
+ r = dsi_init_output(dsidev, dsi);
+ if (r)
+ goto err_init_output;
+
+ dsi_probe_pdata(dsidev);
+
Why do you change the sequence here? Isn't it enough to just add the
init_output before probe_pdata?
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] OMAPDSS: Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays
On 24/08/12 04:38 AM, Tomi Valkeinen wrote:
On Tue, 2012-08-21 at 10:29 -0400, Raphaël Assénat wrote:
On 21/08/12 06:49 AM, Tomi Valkeinen wrote:
On Wed, 2012-08-15 at 11:26 -0400, Raphaël Assénat wrote:
+
+ /* ChiMei G121S1-L01 */
+ {
+ {
...
+ .vsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
+ .hsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
+ .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
+ .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
+ .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
Actually those 3 panels only use the DE signal. The hsync/vsync signals
are not used and on our system we mux them out to make sure they are
kept low as recommended in the panel datasheets.
Since vsync/hsync are not used, I think the vsync_level, hsync_level and
sync_pclk_edge entries could be removed. Otherwise the updated patch
works fine as is.
Okay. How do panels like that work? How can they know where a new frame
starts?
By DE being inactive for a different number of pixel clock cycles during
the vertical and horizontal blanking periods.
Ok. Interesting architecture. I wonder what's the reason for a design
like that...
Actually, I now googled for those panels, and they are all LVDS panels,
not DPI panels. So the patch doesn't look correct at all.
Do you have a DPI-to-LVDS converter chip on your board?
Yes, we do. Depending on the board, we use a SN75LVDS83B or a SN65LVDS84.
The reason for using this approach was that the panels covered by
this patch seemed not to be compatible with Flatlink 3G, which meant
driving them directly from the AM35xx SDI serial interface was not possible.
We unfortunately do not get to select which LVDS deserializer is
used at the panel side..
Ok. I'm a bit reluctant to add the panels to panel-generic-dpi.c, as
they are not DPI panels at all. Also, you should have drivers for the
DPI-to-LVDS converters. However, this cannot be done properly with the
current DSS driver model, so I'm not sure what to do with your patch.
But internally, perhaps with the exception of the DE only operation,
all the same concepts apply. LVDS is just only one extra layer used to
transmit the parallel data more effectively (differential, less
conductors, etc).
Consider the case where an LVDS transmitter is used on the main board
in conjunction with a remote LVDS receiver on a board connected to
a true DPI panel as follows:
[OMAPDSS - LVDS XMIT] - [long cable] - [LVDS RXCV - DPI Panel]
|parallel| lvds serial|parallel |
Given the above use case, adding a new panel to panel-generic-dpi.c would
be obvious since doing without LVDS and driving the panel directly may
still happen if a specific design does not benefit from the use of LVDS.
There are a few different conventions for LVDS transmission where the total
number of bits transmitted by pairs as well as the bit order varies. The
hardware designer selects a compatible pair of chips based on the number of
color bits the panel supports and other factors. But no matter which are
selected and how they are wired, the LVDS layer remains transparent to the
graphics controller and the panel.
My situation is only different from the above by the fact that our panels
have an LVDS receiver built-in, which means the choice of transmitter is
limited to what will be compatible and that a specific bit order (i.e.
wiring)
must be observed. This is why I tend to consider those LVDS panels simply
as DPI panels having a built-in LVDS receiver.
If you had just one panel and DPI-to-LVDS chip, I'd suggest to create a
combined driver which handles both the chip and the panel. But you have
two chips and three panels...
I'm not sure what the chip driver would do. The LVDS layer is totally
transparent to the operation. Why would the kernel need to be aware of
which chip is used?
One thing that might be useful would be the ability to control the
enable pin, but this is not different from the enable pin on a level shifter
placed between the OMAP and a real DPI panel. At the moment, our userspace
software simply controls this using a GPIO.
Best regards,
Raphaël Assénat
--
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] ARM: OMAP2+: dpll: Add missing soc_is_am33xx() check for common functions
Add missing soc_is_am33xx() check for DPLL common control clock
related functions, without this dpll programmability would be broken
for am33xx family of devices.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
Not sure whether this should go as a fix in -rc, as AM33XX device
doesn't still boot without hwmod data (which is not yet upstream).
arch/arm/mach-omap2/clkt_dpll.c |4 ++--
arch/arm/mach-omap2/dpll3xxx.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt_dpll.c b/arch/arm/mach-omap2/clkt_dpll.c
index cd7fd0f..05ff99e 100644
--- a/arch/arm/mach-omap2/clkt_dpll.c
+++ b/arch/arm/mach-omap2/clkt_dpll.c
@@ -211,7 +211,7 @@ void omap2_init_dpll_parent(struct clk *clk)
if (v == OMAP3XXX_EN_DPLL_LPBYPASS ||
v == OMAP3XXX_EN_DPLL_FRBYPASS)
clk_reparent(clk, dd-clk_bypass);
- } else if (cpu_is_omap44xx()) {
+ } else if (soc_is_am33xx() || cpu_is_omap44xx()) {
if (v == OMAP4XXX_EN_DPLL_LPBYPASS ||
v == OMAP4XXX_EN_DPLL_FRBYPASS ||
v == OMAP4XXX_EN_DPLL_MNBYPASS)
@@ -257,7 +257,7 @@ u32 omap2_get_dpll_rate(struct clk *clk)
if (v == OMAP3XXX_EN_DPLL_LPBYPASS ||
v == OMAP3XXX_EN_DPLL_FRBYPASS)
return dd-clk_bypass-rate;
- } else if (cpu_is_omap44xx()) {
+ } else if (soc_is_am33xx() || cpu_is_omap44xx()) {
if (v == OMAP4XXX_EN_DPLL_LPBYPASS ||
v == OMAP4XXX_EN_DPLL_FRBYPASS ||
v == OMAP4XXX_EN_DPLL_MNBYPASS)
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index b9c8d2f..063e1f9 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -311,7 +311,7 @@ static int omap3_noncore_dpll_program(struct clk *clk, u16
m, u8 n, u16 freqsel)
* Set jitter correction. No jitter correction for OMAP4 and 3630
* since freqsel field is no longer present
*/
- if (!cpu_is_omap44xx() !cpu_is_omap3630()) {
+ if (!soc_is_am33xx() !cpu_is_omap44xx() !cpu_is_omap3630()) {
v = __raw_readl(dd-control_reg);
v = ~dd-freqsel_mask;
v |= freqsel __ffs(dd-freqsel_mask);
@@ -471,7 +471,7 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned
long rate)
return -EINVAL;
/* No freqsel on OMAP4 and OMAP3630 */
- if (!cpu_is_omap44xx() !cpu_is_omap3630()) {
+ if (!soc_is_am33xx() !cpu_is_omap44xx()
!cpu_is_omap3630()) {
freqsel = _omap3_dpll_compute_freqsel(clk,
dd-last_rounded_n);
if (!freqsel)
--
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
Re: [PATCH] OMAPDSS: Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays
On Fri, 2012-08-24 at 09:50 -0400, Raphaël Assénat wrote: But internally, perhaps with the exception of the DE only operation, all the same concepts apply. LVDS is just only one extra layer used to transmit the parallel data more effectively (differential, less conductors, etc). Consider the case where an LVDS transmitter is used on the main board in conjunction with a remote LVDS receiver on a board connected to a true DPI panel as follows: [OMAPDSS - LVDS XMIT] - [long cable] - [LVDS RXCV - DPI Panel] |parallel| lvds serial|parallel | Given the above use case, adding a new panel to panel-generic-dpi.c would be obvious since doing without LVDS and driving the panel directly may still happen if a specific design does not benefit from the use of LVDS. There are a few different conventions for LVDS transmission where the total number of bits transmitted by pairs as well as the bit order varies. The hardware designer selects a compatible pair of chips based on the number of color bits the panel supports and other factors. But no matter which are selected and how they are wired, the LVDS layer remains transparent to the graphics controller and the panel. My situation is only different from the above by the fact that our panels have an LVDS receiver built-in, which means the choice of transmitter is limited to what will be compatible and that a specific bit order (i.e. wiring) must be observed. This is why I tend to consider those LVDS panels simply as DPI panels having a built-in LVDS receiver. In your case the LVDS panels are dummy, and require no configuration, and thus look like DPI panels. But consider an LVDS panel which can be controlled via, say, i2c, and you can configure the number of LVDS lanes used. And consider a SoC with LVDS transmitter, which again needs to be configured depending on the LVDS lanes used (and probably some other parameters). In those cases the use doesn't look like DPI anymore. If you had just one panel and DPI-to-LVDS chip, I'd suggest to create a combined driver which handles both the chip and the panel. But you have two chips and three panels... I'm not sure what the chip driver would do. The LVDS layer is totally transparent to the operation. Why would the kernel need to be aware of which chip is used? The chip must require power to operate, so it needs to enable regulators. For example, SN75LVDS83B requires VCC, IOVCC, PLLVCC, LVDSVCC. In your case the regulators may be always-on regulators, but a driver cannot make such assumptions. One thing that might be useful would be the ability to control the enable pin, but this is not different from the enable pin on a level shifter placed between the OMAP and a real DPI panel. At the moment, our userspace software simply controls this using a GPIO. Yes, the driver should also handle the enable GPIO (for the DPI case also). Now, as I said, the current omapdss model doesn't really allow chaining of display devices, so you can't currently create proper drivers. That's why I'm not sure what to do. It would be nice to support your boards, but on the other hand, I think it's not correct to add these panels. Tomi signature.asc Description: This is a digitally signed message part
[PATCHv2 0/8] ir-rx51: Fixes in response to review comments
These patches fix most of the issues pointed out in the patch review
by Sean Young and Sakari Ailus.
The most noticeable change after these patch set is that the IR
transmission no longer times out even if the timers are not waking up
the MPU as it should be. Now that Jean Pihet kindly instructed me how
to use the PM QoS API for setting the latency constraints, the driver
will now work without any background load. Someone might consider such
restriction a blocker bug, that is fixed on this patch set.
Changes since v1:
- Replace wake_up_interruptible with wake_up, as the driver is having
non-interruptible sleeps
- Instead of just removing the set_max_mpu_wakeup_lat calls, replace
them with QoS API calls
Timo Kokkonen (8):
ir-rx51: Adjust dependencies
ir-rx51: Handle signals properly
ir-rx51: Trivial fixes
ir-rx51: Clean up timer initialization code
ir-rx51: Move platform data checking into probe function
ir-rx51: Replace module_{init,exit} macros with
module_platform_driver
ir-rx51: Convert latency constraints to PM QoS API
ir-rx51: Remove useless variable from struct lirc_rx51
arch/arm/mach-omap2/board-rx51-peripherals.c | 2 -
drivers/media/rc/Kconfig | 4 +-
drivers/media/rc/ir-rx51.c | 100 ++-
include/media/ir-rx51.h | 2 -
4 files changed, 54 insertions(+), 54 deletions(-)
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 1/8] ir-rx51: Adjust dependencies
Although this kind of IR diode circuitry is known to exist only in N900 hardware, nothing prevents making similar circuitry on any OMAP based board. The MACH_NOKIA_RX51 dependency is thus not something we want to be there. Also, this should depend on LIRC as it is a LIRC driver. Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi --- drivers/media/rc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig index ffef8b4..093982b 100644 --- a/drivers/media/rc/Kconfig +++ b/drivers/media/rc/Kconfig @@ -273,7 +273,7 @@ config IR_IGUANA config IR_RX51 tristate Nokia N900 IR transmitter diode - depends on MACH_NOKIA_RX51 OMAP_DM_TIMER + depends on OMAP_DM_TIMER LIRC ---help--- Say Y or M here if you want to enable support for the IR transmitter diode built in the Nokia N900 (RX51) device. -- 1.7.12 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 3/8] ir-rx51: Trivial fixes
-Fix typo
-Change pwm_timer_num type to match type in platform data
-Remove extra parenthesis
-Replace magic constant with proper bit defintions
-Remove duplicate exit pointer
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
drivers/media/rc/Kconfig | 2 +-
drivers/media/rc/ir-rx51.c | 10 ++
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 093982b..4a68014 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -278,7 +278,7 @@ config IR_RX51
Say Y or M here if you want to enable support for the IR
transmitter diode built in the Nokia N900 (RX51) device.
- The driver uses omap DM timers for gereating the carrier
+ The driver uses omap DM timers for generating the carrier
wave and pulses.
config RC_LOOPBACK
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index e2db94e..125d4c3 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -59,7 +59,7 @@ struct lirc_rx51 {
int wbuf[WBUF_LEN];
int wbuf_index;
unsigned long device_is_open;
- unsigned intpwm_timer_num;
+ int pwm_timer_num;
};
static void lirc_rx51_on(struct lirc_rx51 *lirc_rx51)
@@ -138,11 +138,14 @@ static irqreturn_t lirc_rx51_interrupt_handler(int irq,
void *ptr)
if (!retval)
return IRQ_NONE;
- if ((retval ~OMAP_TIMER_INT_MATCH))
+ if (retval ~OMAP_TIMER_INT_MATCH)
dev_err_ratelimited(lirc_rx51-dev,
: Unexpected interrupt source: %x\n, retval);
- omap_dm_timer_write_status(lirc_rx51-pulse_timer, 7);
+ omap_dm_timer_write_status(lirc_rx51-pulse_timer,
+ OMAP_TIMER_INT_MATCH|
+ OMAP_TIMER_INT_OVERFLOW |
+ OMAP_TIMER_INT_CAPTURE);
if (lirc_rx51-wbuf_index 0) {
dev_err_ratelimited(lirc_rx51-dev,
: BUG wbuf_index has value of %i\n,
@@ -489,7 +492,6 @@ struct platform_driver lirc_rx51_platform_driver = {
.remove = __exit_p(lirc_rx51_remove),
.suspend= lirc_rx51_suspend,
.resume = lirc_rx51_resume,
- .remove = __exit_p(lirc_rx51_remove),
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 2/8] ir-rx51: Handle signals properly
The lirc-dev expects the ir-code to be transmitted when the write call
returns back to the user space. We should not leave TX ongoing no
matter what is the reason we return to the user space. Easiest
solution for that is to simply remove interruptible sleeps.
The first wait_event_interruptible is thus replaced with return -EBUSY
in case there is still ongoing transfer. This should suffice as the
concept of sending multiple codes in parallel does not make sense.
The second wait_event_interruptible call is replaced with
wait_even_timeout with a fixed and safe timeout that should prevent
the process from getting stuck in kernel for too long.
Also, from now on we will force the TX to stop before we return from
write call. If the TX happened to time out for some reason, we should
not leave the HW transmitting anything.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
drivers/media/rc/ir-rx51.c | 39 ---
1 file changed, 28 insertions(+), 11 deletions(-)
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 9487dd3..e2db94e 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -74,6 +74,19 @@ static void lirc_rx51_off(struct lirc_rx51 *lirc_rx51)
OMAP_TIMER_TRIGGER_NONE);
}
+static void lirc_rx51_stop_tx(struct lirc_rx51 *lirc_rx51)
+{
+ if (lirc_rx51-wbuf_index 0)
+ return;
+
+ lirc_rx51_off(lirc_rx51);
+ lirc_rx51-wbuf_index = -1;
+ omap_dm_timer_stop(lirc_rx51-pwm_timer);
+ omap_dm_timer_stop(lirc_rx51-pulse_timer);
+ omap_dm_timer_set_int_enable(lirc_rx51-pulse_timer, 0);
+ wake_up(lirc_rx51-wqueue);
+}
+
static int init_timing_params(struct lirc_rx51 *lirc_rx51)
{
u32 load, match;
@@ -160,13 +173,7 @@ static irqreturn_t lirc_rx51_interrupt_handler(int irq,
void *ptr)
return IRQ_HANDLED;
end:
- /* Stop TX here */
- lirc_rx51_off(lirc_rx51);
- lirc_rx51-wbuf_index = -1;
- omap_dm_timer_stop(lirc_rx51-pwm_timer);
- omap_dm_timer_stop(lirc_rx51-pulse_timer);
- omap_dm_timer_set_int_enable(lirc_rx51-pulse_timer, 0);
- wake_up_interruptible(lirc_rx51-wqueue);
+ lirc_rx51_stop_tx(lirc_rx51);
return IRQ_HANDLED;
}
@@ -246,8 +253,9 @@ static ssize_t lirc_rx51_write(struct file *file, const
char *buf,
if ((count WBUF_LEN) || (count % 2 == 0))
return -EINVAL;
- /* Wait any pending transfers to finish */
- wait_event_interruptible(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0);
+ /* We can have only one transmit at a time */
+ if (lirc_rx51-wbuf_index = 0)
+ return -EBUSY;
if (copy_from_user(lirc_rx51-wbuf, buf, n))
return -EFAULT;
@@ -273,9 +281,18 @@ static ssize_t lirc_rx51_write(struct file *file, const
char *buf,
/*
* Don't return back to the userspace until the transfer has
-* finished
+* finished. However, we wish to not spend any more than 500ms
+* in kernel. No IR code TX should ever take that long.
+*/
+ i = wait_event_timeout(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0,
+ HZ / 2);
+
+ /*
+* Ensure transmitting has really stopped, even if the timers
+* went mad or something else happened that caused it still
+* sending out something.
*/
- wait_event_interruptible(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0);
+ lirc_rx51_stop_tx(lirc_rx51);
/* We can sleep again */
lirc_rx51-pdata-set_max_mpu_wakeup_lat(lirc_rx51-dev, -1);
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 4/8] ir-rx51: Clean up timer initialization code
Remove a redundant macro definition. This is unneeded and becomes more
readable once the actual timer code is refactored a little.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
drivers/media/rc/ir-rx51.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 125d4c3..f22e5e4 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -105,11 +105,9 @@ static int init_timing_params(struct lirc_rx51 *lirc_rx51)
return 0;
}
-#define tics_after(a, b) ((long)(b) - (long)(a) 0)
-
static int pulse_timer_set_timeout(struct lirc_rx51 *lirc_rx51, int usec)
{
- int counter;
+ int counter, counter_now;
BUG_ON(usec 0);
@@ -122,11 +120,8 @@ static int pulse_timer_set_timeout(struct lirc_rx51
*lirc_rx51, int usec)
omap_dm_timer_set_match(lirc_rx51-pulse_timer, 1, counter);
omap_dm_timer_set_int_enable(lirc_rx51-pulse_timer,
OMAP_TIMER_INT_MATCH);
- if (tics_after(omap_dm_timer_read_counter(lirc_rx51-pulse_timer),
- counter)) {
- return 1;
- }
- return 0;
+ counter_now = omap_dm_timer_read_counter(lirc_rx51-pulse_timer);
+ return (counter - counter_now) 0;
}
static irqreturn_t lirc_rx51_interrupt_handler(int irq, void *ptr)
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 8/8] ir-rx51: Remove useless variable from struct lirc_rx51
As clearly visible from the patch, this variable has no useful purpose
what so ever. Thus, it can be removed altogether without any side
effects.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
drivers/media/rc/ir-rx51.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 008cdab..179b64d 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -57,7 +57,6 @@ struct lirc_rx51 {
unsigned intfreq; /* carrier frequency */
unsigned intduty_cycle; /* carrier duty cycle */
unsigned intirq_num;
- unsigned intmatch;
int wbuf[WBUF_LEN];
int wbuf_index;
unsigned long device_is_open;
@@ -102,8 +101,6 @@ static int init_timing_params(struct lirc_rx51 *lirc_rx51)
omap_dm_timer_set_int_enable(lirc_rx51-pulse_timer, 0);
omap_dm_timer_start(lirc_rx51-pulse_timer);
- lirc_rx51-match = 0;
-
return 0;
}
@@ -113,11 +110,7 @@ static int pulse_timer_set_timeout(struct lirc_rx51
*lirc_rx51, int usec)
BUG_ON(usec 0);
- if (lirc_rx51-match == 0)
- counter = omap_dm_timer_read_counter(lirc_rx51-pulse_timer);
- else
- counter = lirc_rx51-match;
-
+ counter = omap_dm_timer_read_counter(lirc_rx51-pulse_timer);
counter += (u32)(lirc_rx51-fclk_khz * usec / (1000));
omap_dm_timer_set_match(lirc_rx51-pulse_timer, 1, counter);
omap_dm_timer_set_int_enable(lirc_rx51-pulse_timer,
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 7/8] ir-rx51: Convert latency constraints to PM QoS API
Convert the driver from the obsolete omap_pm_set_max_mpu_wakeup_lat
API to the new PM QoS API. This allows the callback to be removed from
the platform data structure.
The latency requirements are also adjusted to prevent the MPU from
going into sleep mode. This is needed as the GP timers have no means
to wake up the MPU once it has gone into sleep. The side effect is
that from now on the driver actually works even if there is no
background load keeping the MPU awake.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 2 --
drivers/media/rc/ir-rx51.c | 15 ++-
include/media/ir-rx51.h | 2 --
3 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index ca07264..e0750cb 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -34,7 +34,6 @@
#include plat/gpmc.h
#include plat/onenand.h
#include plat/gpmc-smc91x.h
-#include plat/omap-pm.h
#include mach/board-rx51.h
@@ -1227,7 +1226,6 @@ static void __init rx51_init_tsc2005(void)
#if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
static struct lirc_rx51_platform_data rx51_lirc_data = {
- .set_max_mpu_wakeup_lat = omap_pm_set_max_mpu_wakeup_lat,
.pwm_timer = 9, /* Use GPT 9 for CIR */
};
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 6e1ffa6..008cdab 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -25,6 +25,7 @@
#include linux/platform_device.h
#include linux/sched.h
#include linux/wait.h
+#include linux/pm_qos.h
#include plat/dmtimer.h
#include plat/clock.h
@@ -49,6 +50,7 @@ struct lirc_rx51 {
struct omap_dm_timer *pulse_timer;
struct device*dev;
struct lirc_rx51_platform_data *pdata;
+ struct pm_qos_request pm_qos_request;
wait_queue_head_t wqueue;
unsigned long fclk_khz;
@@ -268,10 +270,14 @@ static ssize_t lirc_rx51_write(struct file *file, const
char *buf,
lirc_rx51-wbuf[count] = -1; /* Insert termination mark */
/*
-* Adjust latency requirements so the device doesn't go in too
-* deep sleep states
+* If the MPU is going into too deep sleep state while we are
+* transmitting the IR code, timers will not be able to wake
+* up the MPU. Thus, we need to set a strict enough latency
+* requirement in order to ensure the interrupts come though
+* properly.
*/
- lirc_rx51-pdata-set_max_mpu_wakeup_lat(lirc_rx51-dev, 50);
+ pm_qos_add_request(lirc_rx51-pm_qos_request,
+ PM_QOS_CPU_DMA_LATENCY, 10);
lirc_rx51_on(lirc_rx51);
lirc_rx51-wbuf_index = 1;
@@ -292,8 +298,7 @@ static ssize_t lirc_rx51_write(struct file *file, const
char *buf,
*/
lirc_rx51_stop_tx(lirc_rx51);
- /* We can sleep again */
- lirc_rx51-pdata-set_max_mpu_wakeup_lat(lirc_rx51-dev, -1);
+ pm_qos_remove_request(lirc_rx51-pm_qos_request);
return n;
}
diff --git a/include/media/ir-rx51.h b/include/media/ir-rx51.h
index 104aa89..57523f2 100644
--- a/include/media/ir-rx51.h
+++ b/include/media/ir-rx51.h
@@ -3,8 +3,6 @@
struct lirc_rx51_platform_data {
int pwm_timer;
-
- int(*set_max_mpu_wakeup_lat)(struct device *dev, long t);
};
#endif
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 6/8] ir-rx51: Replace module_{init,exit} macros with module_platform_driver
No reason to avoid using the existing helpers.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
drivers/media/rc/ir-rx51.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 16b3c1f..6e1ffa6 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -495,17 +495,7 @@ struct platform_driver lirc_rx51_platform_driver = {
},
};
-static int __init lirc_rx51_init(void)
-{
- return platform_driver_register(lirc_rx51_platform_driver);
-}
-module_init(lirc_rx51_init);
-
-static void __exit lirc_rx51_exit(void)
-{
- platform_driver_unregister(lirc_rx51_platform_driver);
-}
-module_exit(lirc_rx51_exit);
+module_platform_driver(lirc_rx51_platform_driver);
MODULE_DESCRIPTION(LIRC TX driver for Nokia RX51);
MODULE_AUTHOR(Nokia Corporation);
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 5/8] ir-rx51: Move platform data checking into probe function
This driver is useless without proper platform data. If data is not
available, we should not register the driver at all. Once this check
is done, the BUG_ON check during device open is no longer needed.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
drivers/media/rc/ir-rx51.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index f22e5e4..16b3c1f 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -378,7 +378,6 @@ static long lirc_rx51_ioctl(struct file *filep,
static int lirc_rx51_open(struct inode *inode, struct file *file)
{
struct lirc_rx51 *lirc_rx51 = lirc_get_pdata(file);
- BUG_ON(!lirc_rx51);
file-private_data = lirc_rx51;
@@ -458,6 +457,9 @@ static int lirc_rx51_resume(struct platform_device *dev)
static int __devinit lirc_rx51_probe(struct platform_device *dev)
{
+ if (!dev-dev.platform_data)
+ return -ENODEV;
+
lirc_rx51_driver.features = LIRC_RX51_DRIVER_FEATURES;
lirc_rx51.pdata = dev-dev.platform_data;
lirc_rx51.pwm_timer_num = lirc_rx51.pdata-pwm_timer;
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap_hwmod: Fix up resource names when booted with devicetree
Hello Péter, On Thu, 23 Aug 2012, Peter Ujfalusi wrote: When booted with some resource will have their name set to NULL. This can cause later kernel crash since this is not expected by the platform code. When we boot without DT the devices are created with platform_device_add() which itself fixes up the missing resource names: if (r-name == NULL) r-name = dev_name(pdev-dev); The of core also fixes up the resource names when taking the information from DT data - in __of_address_to_resource(): r-name = name ? name : dev-full_name; When we boot OMAP with devicetree: of will create the devices based on the DT data so the resource names are guarantied to be not NULL. Since we have the 'ti,hwmod' tag, we remove the of created resources from the device and re-create them based on hwmod data. If the hwmod data does not specify a name for a resource it will be NULL. This can cause kernel crash if the driver uses platform_get_resource_byname() to get any resource. Do we need both this one and your '[PATCH] driver core: Check if r-name is valid in platform_get_resource_byname()' ? Or would that second patch be enough? Is the crash happening in the platform_get_resource_byname() iterator? - Paul
RE: OMAP HWMOD: Query regarding parent-child support
On Fri, Aug 17, 2012 at 18:00:54, Cousson, Benoit wrote:
Hi Vaibhav,
On 08/17/2012 12:12 PM, Vaibhav Hiremath wrote:
On 7/16/2012 7:41 PM, Vaibhav Hiremath wrote:
Hi All,
Paul,
From last couple of days I am almost spending my whole time trying to
get to somewhere on below issue and based on my understanding and
learning so far I started feeling that, probably we might have made
wrong decision to remove all leaf-nodes from the clock-tree. Instead we
should have it removed from hwmod. :)
Let's take a example of PWM Module (which is the context of my debugging) -
As I mentioned before, PWM module present in AM33XX looks something like -
--
| |
| | PWMSS | |
| |
| --- - |
| | eCAP | | ePWM | | eQEP | |
| --- - |
--
PWMSS: This actually controls all PM related signals like idle,
standby, etc...
eCAP/ePWM/eQEP: Technically it is independent module, reused from
Davinci devices and is implemented as independent
drivers in kernel.
In case of AM33xx, the basic resources like, clock, idle signal and
standby signal are abstracted at PWMSS level.
This means the core IP (eCAP/ePWM/eQEP) have not changed from their
original implementation.
These core IP's (eCAP/ePWM/eQEP) are being used in Davinci family of
devices, but without encapsulation of PWMSS, unlike AM33XX. This means,
each module has its own clock enable/disable control mechanism and there
is no dependency between them, unlike AM33XX.
Options to support:
1. Use existing Clock Framework infrastructure to handle, which
basically supports clock enable/disable function based on usecount and
parent-child relation. Driver will simply work, without knowing
anything about underneath platform, which is what expected.
So create a dummy-clocks for submodules, making PWMSS clock as a parent
will solve the issue here.
And nothing wrong here, we are just treating,
clock-enable = module-enable
Yeah, but that looks like a hack to me. That clock hierarchy does not
exist for real and the pm_runtime infrastructure can handle that
properly. In that case you do have a PM dependency and not necessarily a
clock dependency.
In one sense, yes.
The only issue here is sysconf register access at hwmod level, if you
leave sysconf idle and standby configuration at smart state, it works
properly. I have validated it at my end.
2. MFD Driver: I think it will be miss-use of MFD driver and should be
explored at all.
I do think this is the proper use of MFD.
Not certainly, as I said, here we are trying to solve some weird SoC
integration dependency and will not work across devices, like Davinci.
In fact with DT, you don't
even need an MFD. The DT nodes hierarchy will create the parent-child
link automatically.
pm_runtime events are taking care of the parent state. It means that if
you are enabling a child, the parent will be enabled first automatically
by the PM fmwk.
Fortunately before going on vacation last week I attempted this and found
some issues -
What I did was,
ehrpwmss0: ehrpwmss0@4830 {
compatible = ti,ehrpwmss;
ti,hwmods = ehrpwmss0;
#address-cells = 1;
#size-cells = 1;
ranges;
ehrpwm0: ehrpwm@48300200 {
compatible = ti,ehrpwm;
ti,hwmods = ehrpwm0;
#pwm-cells = 3;
has_configspace = 1;
};
ecap0: ecap@48300100 {
compatible = ti,ecap;
ti,hwmods = ecap0;
#pwm-cells = 3;
has_configspace = 1;
};
};
Above DT implementation created device nodes like,
ehrpwmss0 (no Linux driver) -
- ehrpwm0 (driver/pwm/ehrpwm.c)
- ecap0 (drivers/pwm/ecap.c)
Please note that, we do not have any driver code available for parent
device, as it is AM33XX specific and we don't want eCAP and eHRPWM drivers
should know about it.
The runtime_pm api's implementation is based on disable_depth, and it
works something like,
Driver -
Pm_runtime_enable() - decrement disable_depth
- pm_runtime_get_sync() - Check for disable_depth and if
It is 0 then call reached platform code.
Now somebody has to call pm_runtime_enable() function for parent device,
which I believe is our problem area here.
Please note that, I have actually changed code to see whether it is really
possible, so please let me know if you have any suggestions
Re: [PATCH] MMC: OMAP MSDI: fix broken PIO mode
* Felipe Balbi ba...@ti.com [120824 00:29]: this looks good to me, though I don't have how to test. FWIW: Reviewed-by: Felipe Balbi ba...@ti.com Works for me: Tested-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC RESEND 2/4] ARM: OMAP3: Dynamically disable secure timer nodes for secure devices
On Fri, Aug 17, 2012 at 17:54:09, Hunter, Jon wrote:
On 08/17/2012 12:32 AM, Hiremath, Vaibhav wrote:
On Thu, Aug 16, 2012 at 22:27:42, Hunter, Jon wrote:
On 08/15/2012 04:13 AM, Vaibhav Hiremath wrote:
On 7/14/2012 3:56 AM, Jon Hunter wrote:
OMAP3 devices may or may not have security features enabled. Security
enabled
devices are known as high-secure (HS) and devices without security are
known as
general purpose (GP).
For OMAP3 devices there are 12 general purpose timers available. On
secure
devices the 12th timer is reserved for secure usage and so cannot be
used by
the kernel, where as for a GP device it is available. We can detect the
OMAP
device type, secure or GP, at runtime via an on-chip register. Today,
when not
using DT, we do not register the 12th timer as a linux device if the
device is
secure.
When using device tree, device tree is going to register all the timer
devices
it finds in the device tree blob. To prevent device tree from
registering 12th
timer on a secure OMAP3 device we can add a status property to the timer
binding with the value disabled at boot time. Note that timer 12 on a
OMAP3
device has a property ti,timer-secure to indicate that it will not be
available on a secure device and so for secure OMAP3 devices, we search
for
timers with this property and then disable them. Using the
prom_add_property()
function to dynamically add a property was a recommended approach
suggested by
Rob Herring [1].
I have tested this on an OMAP3 GP device and faking it to pretend to be a
secure device to ensure that any timers marked with ti,timer-secure
are not
registered on boot. I have also made sure that all timers are registered
as
expected on a GP device by default.
[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/79203
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/board-generic.c |1 +
arch/arm/mach-omap2/common.h|1 +
arch/arm/mach-omap2/timer.c | 36
+++
3 files changed, 38 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 6f93a20..20124d7 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -40,6 +40,7 @@ static struct of_device_id omap_dt_match_table[]
__initdata = {
static void __init omap_generic_init(void)
{
omap_sdrc_init(NULL, NULL);
+omap_dmtimer_init();
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
}
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 1f65b18..d6a4875 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -326,6 +326,7 @@ extern void omap_sdrc_init(struct omap_sdrc_params
*sdrc_cs0,
struct omap_sdrc_params
*sdrc_cs1);
struct omap2_hsmmc_info;
extern int omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info
*controllers);
+extern void omap_dmtimer_init(void);
#endif /* __ASSEMBLER__ */
#endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 13d20c8..e3b9931 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -36,6 +36,7 @@
#include linux/clocksource.h
#include linux/clockchips.h
#include linux/slab.h
+#include linux/of.h
#include asm/mach/time.h
#include plat/dmtimer.h
@@ -482,6 +483,41 @@ static int __init omap2_dm_timer_init(void)
}
arch_initcall(omap2_dm_timer_init);
+static struct property timer_disabled = {
+.name = status,
+.length = sizeof(disabled),
+.value = disabled,
+};
+
+static struct of_device_id omap3_timer_match[] __initdata = {
+{ .compatible = ti,omap3-timer, },
+{ }
+};
+
+/**
+ * omap_dmtimer_init - initialisation function when device tree is used
+ *
+ * For secure OMAP3 devices, timers with device type timer-secure
cannot
+ * be used by the kernel as they are reserved. Therefore, to prevent the
+ * kernel registering these devices remove them dynamically from the
device
+ * tree on boot.
+ */
+void __init omap_dmtimer_init(void)
+{
+struct device_node *np;
+
+if (!cpu_is_omap34xx())
+return;
+
Sorry for responding so late, but why only omap34xx check here?
Isn't this applicable to all omap non-omap devices?
It is only applicable to omap3 devices as far as omap is concerned.
By non-omap, you are referring to the AMxxx stuff?
Do AMxxx devices even support security (ie. secure boot and have secure
peripherals)? If not then this will work for AMxxx devices too.
Yes it does.
AM33xx has 8 timers and Timer-0 is a secure timer. As in case of
Re: [PATCH] ARM: omap_hwmod: Fix up resource names when booted with devicetree
Hi Paul, On 08/24/2012 06:38 PM, Paul Walmsley wrote: Do we need both this one and your '[PATCH] driver core: Check if r-name is valid in platform_get_resource_byname()' ? Or would that second patch be enough? Is the crash happening in the platform_get_resource_byname() iterator? The crash happens in platform_get_resource_byname(). What I see as a problem that when we boot without DT the r-name is configured for the hwmods. If we boot with DT we discard the resources created by the OF (which also have the r-name configured). We replace the resources from hwmods but we do not fix up the resource names (which is done in other cases). I have sent the patch for the drivers core as well since I think it is a good practice anyway to check for NULL pointer before strcmp(). Either is good, but IMHO we should fix this in omap_hwmod (at least). -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 20/23] serial: omap: fix software flow control
* Felipe Balbi ba...@ti.com [120823 03:38]: From: Vikram Pandita vikram.pand...@ti.com Software flow control register bits were not defined correctly. Also clarify the IXON and IXOFF logic to reflect what userspace wants. Cc: sta...@vger.kernel.org Tested-by: Shubhrajyoti D shubhrajy...@ti.com Signed-off-by: Vikram Pandita vikram.pand...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 10/10] mtd: nand: omap2: use gpmc provided irqs
Artem,
* Afzal Mohammed af...@ti.com [120821 02:44]:
GPMC platform initialization provides it's clients
with interrupts that can be used through struct
resource. Make use of it for irq mode functionality.
Also now write protect disable is done by GPMC,
hence remove it.
Signed-off-by: Afzal Mohammed af...@ti.com
---
v3: Handle error path properly
Care to (re)ack this one as the error path handling changed?
Regards,
Tony
drivers/mtd/nand/omap2.c | 76
+-
1 files changed, 48 insertions(+), 28 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index f65f7f8..0e9d7b3 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -137,7 +137,8 @@ struct omap_nand_info {
unsigned long mem_size;
struct completion comp;
struct dma_chan *dma;
- int gpmc_irq;
+ int gpmc_irq_fifo;
+ int gpmc_irq_count;
enum {
OMAP_NAND_IO_READ = 0, /* read */
OMAP_NAND_IO_WRITE, /* write */
@@ -553,14 +554,12 @@ static irqreturn_t omap_nand_irq(int this_irq, void
*dev)
{
struct omap_nand_info *info = (struct omap_nand_info *) dev;
u32 bytes;
- u32 irq_stat;
- irq_stat = gpmc_read_status(GPMC_GET_IRQ_STATUS);
bytes = readl(info-reg.gpmc_prefetch_status);
bytes = GPMC_PREFETCH_STATUS_FIFO_CNT(bytes);
bytes = bytes 0xFFFC; /* io in multiple of 4 bytes */
if (info-iomode == OMAP_NAND_IO_WRITE) { /* checks for write io */
- if (irq_stat 0x2)
+ if (this_irq == info-gpmc_irq_count)
goto done;
if (info-buf_len (info-buf_len bytes))
@@ -577,20 +576,17 @@ static irqreturn_t omap_nand_irq(int this_irq, void
*dev)
(u32 *)info-buf, bytes 2);
info-buf = info-buf + bytes;
- if (irq_stat 0x2)
+ if (this_irq == info-gpmc_irq_count)
goto done;
}
- gpmc_cs_configure(info-gpmc_cs, GPMC_SET_IRQ_STATUS, irq_stat);
return IRQ_HANDLED;
done:
complete(info-comp);
- /* disable irq */
- gpmc_cs_configure(info-gpmc_cs, GPMC_ENABLE_IRQ, 0);
- /* clear status */
- gpmc_cs_configure(info-gpmc_cs, GPMC_SET_IRQ_STATUS, irq_stat);
+ disable_irq_nosync(info-gpmc_irq_fifo);
+ disable_irq_nosync(info-gpmc_irq_count);
return IRQ_HANDLED;
}
@@ -624,9 +620,9 @@ static void omap_read_buf_irq_pref(struct mtd_info *mtd,
u_char *buf, int len)
goto out_copy;
info-buf_len = len;
- /* enable irq */
- gpmc_cs_configure(info-gpmc_cs, GPMC_ENABLE_IRQ,
- (GPMC_IRQ_FIFOEVENTENABLE | GPMC_IRQ_COUNT_EVENT));
+
+ enable_irq(info-gpmc_irq_count);
+ enable_irq(info-gpmc_irq_fifo);
/* waiting for read to complete */
wait_for_completion(info-comp);
@@ -674,12 +670,13 @@ static void omap_write_buf_irq_pref(struct mtd_info
*mtd,
goto out_copy;
info-buf_len = len;
- /* enable irq */
- gpmc_cs_configure(info-gpmc_cs, GPMC_ENABLE_IRQ,
- (GPMC_IRQ_FIFOEVENTENABLE | GPMC_IRQ_COUNT_EVENT));
+
+ enable_irq(info-gpmc_irq_count);
+ enable_irq(info-gpmc_irq_fifo);
/* waiting for write to complete */
wait_for_completion(info-comp);
+
/* wait for data to flushed-out before reset the prefetch */
tim = 0;
limit = (loops_per_jiffy * msecs_to_jiffies(OMAP_NAND_TIMEOUT_MS));
@@ -1300,9 +1297,6 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
info-nand.options = pdata-devsize;
info-nand.options |= NAND_SKIP_BBTSCAN;
- /* NAND write protect off */
- gpmc_cs_configure(info-gpmc_cs, GPMC_CONFIG_WP, 0);
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL) {
err = -EINVAL;
@@ -1393,17 +1387,37 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
break;
case NAND_OMAP_PREFETCH_IRQ:
- err = request_irq(pdata-gpmc_irq,
- omap_nand_irq, IRQF_SHARED, gpmc-nand, info);
+ info-gpmc_irq_fifo = platform_get_irq(pdev, 0);
+ if (info-gpmc_irq_fifo = 0) {
+ dev_err(pdev-dev, error getting fifo irq\n);
+ goto out_release_mem_region;
+ }
+ err = request_irq(info-gpmc_irq_fifo, omap_nand_irq,
+ IRQF_SHARED, gpmc-nand-fifo, info);
if (err) {
dev_err(pdev-dev, requesting irq(%d) error:%d,
-
Re: [PATCH v3 22/23] serial: omap: move uart_omap_port definition to C file
* Felipe Balbi ba...@ti.com [120823 03:38]: nobody needs to access the uart_omap_port structure other than omap-serial.c file. Let's move that structure definition to the C source file in order to prevent anyone from accessing our structure. Tested-by: Shubhrajyoti D shubhrajy...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 10/10] ARM: OMAP2+: tusb6010: generic timing calculation
* Afzal Mohammed af...@ti.com [120821 03:46]: Generic gpmc timing calculation helper is available now, use it instead of custom timing calculation. This hangs n800 during the boot. 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 v6 07/10] ARM: OMAP2+: gpmc: generic timing calculation
* Jon Hunter jon-hun...@ti.com [120822 19:58]: So although this may consolidate how the timings are calculated today, I am concerned it will be confusing to add timings for a new device. At least if I am calculating timings, I am taking the timing information for the device and translating that to the how I need to program the gpmc register fields. Yes agreed. Also as some values make sense only in cycles, converting them back and forth to time is wrong. So at least some values should have an option to specify them in cycles directly, and then ignore any time based values. 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] arm/dts: omap5: Add mmc controller nodes and board data
* Arnd Bergmann a...@arndb.de [120807 02:21]: On Tuesday 07 August 2012, Balaji T K wrote: Add OMAP MMC related device tree data for OMAP5. Signed-off-by: Balaji T K balaj...@ti.com --- Acked-by: Arnd Bergmann a...@arndb.de Applying this into omap devel-dt branch. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V2] arm/dts: AM33XX: Set the default status of module to disabled state
* Vaibhav Hiremath hvaib...@ti.com [120815 04:24]: Ideally in common SoC dtsi file should set all modules to disabled state and it should get enabled in respective EVM/Board dts file as per usage. This patch sets default status of all modules to disabled state in am33xx.dtsi file. Currently there are no modules supported as part of Bone and EVM dts support, so care to add entry status = okay while adding support for any module. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Acked-by: Arnd Bergmann a...@arndb.de Cc: Benoit Cousson b-cous...@ti.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Tony Lindgren t...@atomide.com --- Changes from V1: - Fixed indentation issue caused due to extra spaces. Thanks applying into devel-dt branch. 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 v3 01/23] serial: omap: define and use to_uart_omap_port()
* Felipe Balbi ba...@ti.com [120823 03:37]:
current code only works because struct uart_port
is the first member on the uart_omap_port structure.
If, for whatever reason, someone puts another
member as the first of the structure, that cast
won't work anymore. In order to be safe, let's use
a container_of() which, for now, gets optimized into
a cast anyway.
Tested-by: Shubhrajyoti D shubhrajy...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/plat-omap/include/plat/omap-serial.h | 2 ++
drivers/tty/serial/omap-serial.c | 36
+--
2 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 1a52725..f3b35d9 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -137,4 +137,6 @@ struct uart_omap_port {
struct work_struct qos_work;
};
+#define to_uart_omap_port(p) ((container_of((p), struct uart_omap_port,
port)))
+
#endif /* __OMAP_SERIAL_H__ */
For the arch/arm/*omap*/* parts:
Acked-by: Tony Lindgren t...@atomide.com
FYI, note that there are ARM SoC patches to move various header files to
live under include/linux/platform_data which may cause conflicts with these
changes.
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 v3 3/4] arm/dts: AM33XX: Configure pinmuxs for D_CAN1 on AM335x-EVM
* AnilKumar Ch anilku...@ti.com [120816 05:20]:
Add D_CAN1 pinctrl node to am3358_pinmux master node to export
D_CAN functionality on AM335x EVM according to pinctrl-single
driver.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
Changes from v2:
- Incorporated Vaibhav H's comments on v2
* Added dcan0 instances to am33xx.dtsi file
Changes from v1:
- These two patches separated from c_can DT support
patch series.
arch/arm/boot/dts/am335x-evm.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index 5dd8a6b..a64c30a 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -18,6 +18,18 @@
reg = 0x8000 0x1000; /* 256 MB */
};
+ am3358_pinmux: pinmux@44E10800 {
This should be just am3358_pinmux as you already include it.
+ pinctrl-names = default;
+ pinctrl-0 = d_can1_pins;
+
+ d_can1_pins: pinmux_d_can_pins {
+ pinctrl-single,pins =
+ 0x168 0x2 /* uart0_ctsn.d_can1_tx, OUTPUT
| MODE2 */
+ 0x16C 0x32 /* uart0_rtsn.d_can1_rx,
INPUT_PULLUP | MODE2 */
+ ;
+ };
+ };
+
It would better to claim these pins in the dcan driver entry
rather than set them as pins enabled by the pinctrl driver.
The reason is that in case you want to enable runtime PM related
stuff, like some more advanced wake-up features, for the rx pin
you can do it in the driver.
Then one nit.. Please lowercase all hex number in this series as that's the
style
here.
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 v3 1/4] arm/dts: regulator: Add tps65910 device tree data
* Mark Brown broo...@opensource.wolfsonmicro.com [120821 11:09]: On Tue, Aug 21, 2012 at 12:05:15PM -0600, Stephen Warren wrote: On 08/21/2012 10:38 AM, Mark Brown wrote: This isn't the general view for the regualtor API - we generally want all regulators to be registered in order to allow us to see what's going on with things even if we've not figured them out from software. Oh, I said the above specifically because when I added the LDO configuration for the regulators that weren't used to the Tegra .dts files, you told me to remove it, based on the comment I put in there that they weren't used on the board. The board shouldn't have to define the regulators, the regulator driver really ought to be able to figure out that they're there by itself if there's no configuration based purely on knowing which chip is there. From that point of view it's OK for the chip .dtsi to have them (though ideally the driver wouldn't *need* that either) which was what was happening here. So I assume no changes needed here then? 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] ARM: omap: add dtb targets
* Olof Johansson o...@lixom.net [120823 09:52]: Makes it easier to just do 'make dtbs' for whatever the kernel was configured for, just like some other platforms. Thanks applying into omap devel-dt branch. Tony Signed-off-by: Olof Johansson o...@lixom.net --- arch/arm/mach-omap2/Makefile.boot | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/mach-omap2/Makefile.boot b/arch/arm/mach-omap2/Makefile.boot index b03e562..6cf1c2d 100644 --- a/arch/arm/mach-omap2/Makefile.boot +++ b/arch/arm/mach-omap2/Makefile.boot @@ -1,3 +1,9 @@ zreladdr-y += 0x80008000 params_phys-y:= 0x8100 initrd_phys-y:= 0x8080 + +dtb-$(CONFIG_SOC_OMAP2420) += omap2420-h4.dtb +dtb-$(CONFIG_ARCH_OMAP3) += omap3-beagle.dtb omap3-evm.dtb +dtb-$(CONFIG_ARCH_OMAP4) += omap4-panda.dtb omap4-pandaES.dtb +dtb-$(CONFIG_ARCH_OMAP4) += omap4-var_som.dtb omap4-sdp.dtb +dtb-$(CONFIG_SOC_OMAP5) += omap5-evm.dtb -- 1.7.10.1.488.g05fbf7a -- 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 2/2] arm/dts: Cleanup regulator naming and remove @0,1..
* Rajendra Nayak rna...@ti.com [120730 06:17]: regulators do not have a 'reg' property, hence the regulator@0, regulator@1 do not make sense. get rid of it. Looks like this needs to be refreshed to apply. Care to refresh against current devel-dt branch in case other places need the same change? 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: [PATCHv2 7/8] ir-rx51: Convert latency constraints to PM QoS API
* Timo Kokkonen timo.t.kokko...@iki.fi [120824 08:11]:
Convert the driver from the obsolete omap_pm_set_max_mpu_wakeup_lat
API to the new PM QoS API. This allows the callback to be removed from
the platform data structure.
The latency requirements are also adjusted to prevent the MPU from
going into sleep mode. This is needed as the GP timers have no means
to wake up the MPU once it has gone into sleep. The side effect is
that from now on the driver actually works even if there is no
background load keeping the MPU awake.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
This should get acked by Kevin ideally. Other than that:
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 2 --
drivers/media/rc/ir-rx51.c | 15 ++-
include/media/ir-rx51.h | 2 --
3 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index ca07264..e0750cb 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -34,7 +34,6 @@
#include plat/gpmc.h
#include plat/onenand.h
#include plat/gpmc-smc91x.h
-#include plat/omap-pm.h
#include mach/board-rx51.h
@@ -1227,7 +1226,6 @@ static void __init rx51_init_tsc2005(void)
#if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
static struct lirc_rx51_platform_data rx51_lirc_data = {
- .set_max_mpu_wakeup_lat = omap_pm_set_max_mpu_wakeup_lat,
.pwm_timer = 9, /* Use GPT 9 for CIR */
};
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 6e1ffa6..008cdab 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -25,6 +25,7 @@
#include linux/platform_device.h
#include linux/sched.h
#include linux/wait.h
+#include linux/pm_qos.h
#include plat/dmtimer.h
#include plat/clock.h
@@ -49,6 +50,7 @@ struct lirc_rx51 {
struct omap_dm_timer *pulse_timer;
struct device*dev;
struct lirc_rx51_platform_data *pdata;
+ struct pm_qos_request pm_qos_request;
wait_queue_head_t wqueue;
unsigned long fclk_khz;
@@ -268,10 +270,14 @@ static ssize_t lirc_rx51_write(struct file *file, const
char *buf,
lirc_rx51-wbuf[count] = -1; /* Insert termination mark */
/*
- * Adjust latency requirements so the device doesn't go in too
- * deep sleep states
+ * If the MPU is going into too deep sleep state while we are
+ * transmitting the IR code, timers will not be able to wake
+ * up the MPU. Thus, we need to set a strict enough latency
+ * requirement in order to ensure the interrupts come though
+ * properly.
*/
- lirc_rx51-pdata-set_max_mpu_wakeup_lat(lirc_rx51-dev, 50);
+ pm_qos_add_request(lirc_rx51-pm_qos_request,
+ PM_QOS_CPU_DMA_LATENCY, 10);
lirc_rx51_on(lirc_rx51);
lirc_rx51-wbuf_index = 1;
@@ -292,8 +298,7 @@ static ssize_t lirc_rx51_write(struct file *file, const
char *buf,
*/
lirc_rx51_stop_tx(lirc_rx51);
- /* We can sleep again */
- lirc_rx51-pdata-set_max_mpu_wakeup_lat(lirc_rx51-dev, -1);
+ pm_qos_remove_request(lirc_rx51-pm_qos_request);
return n;
}
diff --git a/include/media/ir-rx51.h b/include/media/ir-rx51.h
index 104aa89..57523f2 100644
--- a/include/media/ir-rx51.h
+++ b/include/media/ir-rx51.h
@@ -3,8 +3,6 @@
struct lirc_rx51_platform_data {
int pwm_timer;
-
- int(*set_max_mpu_wakeup_lat)(struct device *dev, long t);
};
#endif
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 03/23] serial: omap: don't access the platform_device
* Felipe Balbi ba...@ti.com [120823 03:37]: The driver doesn't need to know about its platform_device. Everything the driver needs can be done through the struct device pointer. In case we need to use the OMAP-specific PM function pointers, those can make sure to find the device's platform_device pointer so they can find the struct omap_device through pdev-archdata field. Tested-by: Shubhrajyoti D shubhrajy...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
