* [PATCH] video: EXYNOS: enable interrupt again after sw reset
From: Donghwa Lee @ 2012-05-04 4:59 UTC (permalink / raw)
To: linux-arm-kernel
When exynos_mipi_update_cfg() is called, mipi dsi registers were become
sw reset. So, It needs to enable interrupt again.
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
drivers/video/exynos/exynos_mipi_dsi.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
index 557091d..49c7351 100644
--- a/drivers/video/exynos/exynos_mipi_dsi.c
+++ b/drivers/video/exynos/exynos_mipi_dsi.c
@@ -102,6 +102,8 @@ static void exynos_mipi_update_cfg(struct mipi_dsim_device *dsim)
/* set display timing. */
exynos_mipi_dsi_set_display_mode(dsim, dsim->dsim_config);
+ exynos_mipi_dsi_init_interrupt(dsim);
+
/*
* data from Display controller(FIMD) is transferred in video mode
* but in case of command mode, all settigs is updated to registers.
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 08/25] OMAPDSS: clean up the omapdss platform data mess
From: Archit Taneja @ 2012-05-04 5:44 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336053481-25433-9-git-send-email-tomi.valkeinen@ti.com>
Hi,
On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
> The omapdss pdata handling is a mess. This is more evident when trying
> to use device tree for DSS, as we don't have platform data anymore in
> that case. This patch cleans the pdata handling by:
>
> - Remove struct omap_display_platform_data. It was used just as a
> wrapper for struct omap_dss_board_info.
> - Pass the platform data only to omapdss device. The drivers for omap
> dss hwmods do not need the platform data. This should also work better
> for DT, as we can create omapdss device programmatically in generic omap
> boot code, and thus we can pass the pdata to it.
> - Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
> that the dss hwmod drivers can call.
>
> Signed-off-by: Tomi Valkeinen<tomi.valkeinen@ti.com>
> ---
> arch/arm/mach-omap2/display.c | 39 +++++++++++++++++++--------------------
> drivers/video/omap2/dss/core.c | 35 +++++++++++++++++++++++++++++++++++
> drivers/video/omap2/dss/dispc.c | 21 ++-------------------
> drivers/video/omap2/dss/dsi.c | 17 +++--------------
> drivers/video/omap2/dss/dss.h | 3 +++
> drivers/video/omap2/dss/hdmi.c | 2 --
> include/video/omapdss.h | 5 -----
> 7 files changed, 62 insertions(+), 60 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> index 60cded4..07232fd 100644
> --- a/arch/arm/mach-omap2/display.c
> +++ b/arch/arm/mach-omap2/display.c
> @@ -191,10 +191,24 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)
> struct omap_hwmod *oh;
> struct platform_device *pdev;
> int i, oh_count;
> - struct omap_display_platform_data pdata;
> const struct omap_dss_hwmod_data *curr_dss_hwmod;
>
> - memset(&pdata, 0, sizeof(pdata));
> + /* create omapdss device */
> +
> + board_data->dsi_enable_pads = omap_dsi_enable_pads;
> + board_data->dsi_disable_pads = omap_dsi_disable_pads;
> + board_data->get_context_loss_count = omap_pm_get_dev_context_loss_count;
> + board_data->set_min_bus_tput = omap_dss_set_min_bus_tput;
> +
> + omap_display_device.dev.platform_data = board_data;
> +
> + r = platform_device_register(&omap_display_device);
> + if (r< 0) {
> + pr_err("Unable to register omapdss device\n");
> + return r;
> + }
After this patch, the "omapdss" platform device is registered before the
other dss platform devices. This would change the sequence of probes of
these devices. Was this intentional?
Archit
> +
> + /* create devices for dss hwmods */
>
> if (cpu_is_omap24xx()) {
> curr_dss_hwmod = omap2_dss_hwmod_data;
> @@ -207,16 +221,6 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)
> oh_count = ARRAY_SIZE(omap4_dss_hwmod_data);
> }
>
> - if (board_data->dsi_enable_pads = NULL)
> - board_data->dsi_enable_pads = omap_dsi_enable_pads;
> - if (board_data->dsi_disable_pads = NULL)
> - board_data->dsi_disable_pads = omap_dsi_disable_pads;
> -
> - pdata.board_data = board_data;
> - pdata.board_data->get_context_loss_count > - omap_pm_get_dev_context_loss_count;
> - pdata.board_data->set_min_bus_tput = omap_dss_set_min_bus_tput;
> -
> for (i = 0; i< oh_count; i++) {
> oh = omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);
> if (!oh) {
> @@ -226,21 +230,16 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)
> }
>
> pdev = omap_device_build(curr_dss_hwmod[i].dev_name,
> - curr_dss_hwmod[i].id, oh,&pdata,
> - sizeof(struct omap_display_platform_data),
> + curr_dss_hwmod[i].id, oh,
> + NULL, 0,
> NULL, 0, 0);
>
> if (WARN((IS_ERR(pdev)), "Could not build omap_device for %s\n",
> curr_dss_hwmod[i].oh_name))
> return -ENODEV;
> }
> - omap_display_device.dev.platform_data = board_data;
>
> - r = platform_device_register(&omap_display_device);
> - if (r< 0)
> - printk(KERN_ERR "Unable to register OMAP-Display device\n");
> -
> - return r;
> + return 0;
> }
>
> static void dispc_disable_outputs(void)
> diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
> index 64cb8aa..b37b6f4 100644
> --- a/drivers/video/omap2/dss/core.c
> +++ b/drivers/video/omap2/dss/core.c
> @@ -87,6 +87,41 @@ struct regulator *dss_get_vdds_sdi(void)
> return reg;
> }
>
> +int dss_get_ctx_loss_count(struct device *dev)
> +{
> + struct omap_dss_board_info *board_data = core.pdev->dev.platform_data;
> + int cnt;
> +
> + if (!board_data->get_context_loss_count)
> + return -ENOENT;
> +
> + cnt = board_data->get_context_loss_count(dev);
> +
> + WARN_ONCE(cnt< 0, "get_context_loss_count failed: %d\n", cnt);
> +
> + return cnt;
> +}
> +
> +int dss_dsi_enable_pads(int dsi_id, unsigned lane_mask)
> +{
> + struct omap_dss_board_info *board_data = core.pdev->dev.platform_data;
> +
> + if (!board_data->dsi_enable_pads)
> + return -ENOENT;
> +
> + return board_data->dsi_enable_pads(dsi_id, lane_mask);
> +}
> +
> +void dss_dsi_disable_pads(int dsi_id, unsigned lane_mask)
> +{
> + struct omap_dss_board_info *board_data = core.pdev->dev.platform_data;
> +
> + if (!board_data->dsi_enable_pads)
> + return;
> +
> + return board_data->dsi_disable_pads(dsi_id, lane_mask);
> +}
> +
> int dss_set_min_bus_tput(struct device *dev, unsigned long tput)
> {
> struct omap_dss_board_info *pdata = core.pdev->dev.platform_data;
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index 49015b8..262ed29 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -131,23 +131,6 @@ static inline u32 dispc_read_reg(const u16 idx)
> return __raw_readl(dispc.base + idx);
> }
>
> -static int dispc_get_ctx_loss_count(void)
> -{
> - struct device *dev =&dispc.pdev->dev;
> - struct omap_display_platform_data *pdata = dev->platform_data;
> - struct omap_dss_board_info *board_data = pdata->board_data;
> - int cnt;
> -
> - if (!board_data->get_context_loss_count)
> - return -ENOENT;
> -
> - cnt = board_data->get_context_loss_count(dev);
> -
> - WARN_ONCE(cnt< 0, "get_context_loss_count failed: %d\n", cnt);
> -
> - return cnt;
> -}
> -
> #define SR(reg) \
> dispc.ctx[DISPC_##reg / sizeof(u32)] = dispc_read_reg(DISPC_##reg)
> #define RR(reg) \
> @@ -251,7 +234,7 @@ static void dispc_save_context(void)
> if (dss_has_feature(FEAT_CORE_CLK_DIV))
> SR(DIVISOR);
>
> - dispc.ctx_loss_cnt = dispc_get_ctx_loss_count();
> + dispc.ctx_loss_cnt = dss_get_ctx_loss_count(&dispc.pdev->dev);
> dispc.ctx_valid = true;
>
> DSSDBG("context saved, ctx_loss_count %d\n", dispc.ctx_loss_cnt);
> @@ -266,7 +249,7 @@ static void dispc_restore_context(void)
> if (!dispc.ctx_valid)
> return;
>
> - ctx = dispc_get_ctx_loss_count();
> + ctx = dss_get_ctx_loss_count(&dispc.pdev->dev);
>
> if (ctx>= 0&& ctx = dispc.ctx_loss_cnt)
> return;
> diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
> index f6ecc3a..a5a8316 100644
> --- a/drivers/video/omap2/dss/dsi.c
> +++ b/drivers/video/omap2/dss/dsi.c
> @@ -261,9 +261,6 @@ struct dsi_data {
> struct clk *dss_clk;
> struct clk *sys_clk;
>
> - int (*enable_pads)(int dsi_id, unsigned lane_mask);
> - void (*disable_pads)(int dsi_id, unsigned lane_mask);
> -
> struct dsi_clock_info current_cinfo;
>
> bool vdds_dsi_enabled;
> @@ -2365,7 +2362,7 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
>
> DSSDBGF();
>
> - r = dsi->enable_pads(dsi_get_dsidev_id(dsidev), dsi_get_lane_mask(dssdev));
> + r = dss_dsi_enable_pads(dsi_get_dsidev_id(dsidev), dsi_get_lane_mask(dssdev));
> if (r)
> return r;
>
> @@ -2475,21 +2472,20 @@ err_cio_pwr:
> dsi_cio_disable_lane_override(dsidev);
> err_scp_clk_dom:
> dsi_disable_scp_clk(dsidev);
> - dsi->disable_pads(dsi_get_dsidev_id(dsidev), dsi_get_lane_mask(dssdev));
> + dss_dsi_disable_pads(dsi_get_dsidev_id(dsidev), dsi_get_lane_mask(dssdev));
> return r;
> }
>
> static void dsi_cio_uninit(struct omap_dss_device *dssdev)
> {
> struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
> - struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
>
> /* DDR_CLK_ALWAYS_ON */
> REG_FLD_MOD(dsidev, DSI_CLK_CTRL, 0, 13, 13);
>
> dsi_cio_power(dsidev, DSI_COMPLEXIO_POWER_OFF);
> dsi_disable_scp_clk(dsidev);
> - dsi->disable_pads(dsi_get_dsidev_id(dsidev), dsi_get_lane_mask(dssdev));
> + dss_dsi_disable_pads(dsi_get_dsidev_id(dsidev), dsi_get_lane_mask(dssdev));
> }
>
> static void dsi_config_tx_fifo(struct platform_device *dsidev,
> @@ -4647,8 +4643,6 @@ static void dsi_put_clocks(struct platform_device *dsidev)
> /* DSI1 HW IP initialisation */
> static int omap_dsihw_probe(struct platform_device *dsidev)
> {
> - struct omap_display_platform_data *dss_plat_data;
> - struct omap_dss_board_info *board_info;
> u32 rev;
> int r, i, dsi_module = dsi_get_dsidev_id(dsidev);
> struct resource *dsi_mem;
> @@ -4662,11 +4656,6 @@ static int omap_dsihw_probe(struct platform_device *dsidev)
> dsi_pdev_map[dsi_module] = dsidev;
> dev_set_drvdata(&dsidev->dev, dsi);
>
> - dss_plat_data = dsidev->dev.platform_data;
> - board_info = dss_plat_data->board_data;
> - dsi->enable_pads = board_info->dsi_enable_pads;
> - dsi->disable_pads = board_info->dsi_disable_pads;
> -
> spin_lock_init(&dsi->irq_lock);
> spin_lock_init(&dsi->errors_lock);
> dsi->errors = 0;
> diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
> index 5ca67f1..bb3079d 100644
> --- a/drivers/video/omap2/dss/dss.h
> +++ b/drivers/video/omap2/dss/dss.h
> @@ -159,6 +159,9 @@ struct platform_device;
> struct bus_type *dss_get_bus(void);
> struct regulator *dss_get_vdds_dsi(void);
> struct regulator *dss_get_vdds_sdi(void);
> +int dss_get_ctx_loss_count(struct device *dev);
> +int dss_dsi_enable_pads(int dsi_id, unsigned lane_mask);
> +void dss_dsi_disable_pads(int dsi_id, unsigned lane_mask);
> int dss_set_min_bus_tput(struct device *dev, unsigned long tput);
>
> /* apply */
> diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
> index 56f6e9c..2321b75 100644
> --- a/drivers/video/omap2/dss/hdmi.c
> +++ b/drivers/video/omap2/dss/hdmi.c
> @@ -63,7 +63,6 @@
>
> static struct {
> struct mutex lock;
> - struct omap_display_platform_data *pdata;
> struct platform_device *pdev;
> struct hdmi_ip_data ip_data;
>
> @@ -795,7 +794,6 @@ static int omapdss_hdmihw_probe(struct platform_device *pdev)
> struct resource *hdmi_mem;
> int r;
>
> - hdmi.pdata = pdev->dev.platform_data;
> hdmi.pdev = pdev;
>
> mutex_init(&hdmi.lock);
> diff --git a/include/video/omapdss.h b/include/video/omapdss.h
> index 5f36ddd..49e7073 100644
> --- a/include/video/omapdss.h
> +++ b/include/video/omapdss.h
> @@ -317,11 +317,6 @@ extern int omap_display_init(struct omap_dss_board_info *board_data);
> /* HDMI mux init*/
> extern int omap_hdmi_init(enum omap_hdmi_flags flags);
>
> -struct omap_display_platform_data {
> - struct omap_dss_board_info *board_data;
> - /* TODO: Additional members to be added when PM is considered */
> -};
> -
> struct omap_video_timings {
> /* Unit: pixels */
> u16 x_res;
^ permalink raw reply
* Re: [PATCH 11/25] OMAPDSS: create custom pdevs for DSS omap_devices
From: Archit Taneja @ 2012-05-04 6:15 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336053481-25433-12-git-send-email-tomi.valkeinen@ti.com>
Hi,
On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
> Instead of using omap_device_build() to create the omap_devices for DSS
> hwmods, create them with a custom function. This will allow us to create
> a parent-child hierarchy for the devices so that the omapdss_core device
> is parent for the rest of the dss hwmod devices.
>
> Signed-off-by: Tomi Valkeinen<tomi.valkeinen@ti.com>
> ---
> arch/arm/mach-omap2/display.c | 88 ++++++++++++++++++++++++++++++++++-------
> 1 file changed, 74 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> index 07232fd..46d2a98 100644
> --- a/arch/arm/mach-omap2/display.c
> +++ b/arch/arm/mach-omap2/display.c
> @@ -185,13 +185,71 @@ static int omap_dss_set_min_bus_tput(struct device *dev, unsigned long tput)
> return omap_pm_set_min_bus_tput(dev, OCP_INITIATOR_AGENT, tput);
> }
>
> +static struct platform_device *create_dss_pdev(const char *pdev_name,
> + int pdev_id, const char *oh_name, void *pdata, int pdata_len,
> + struct platform_device *parent)
This function looks quite generic, it's like omap_device_build() but
with a parent associated. omap_device_build() seems to be a special case
of this function with parent passed as null. Won't this
function be needed by other devices too?
Maybe we could modify omap_device_build_ss() to take a parent argument,
and make a function called omap_device_build_parent(), where both
omap_device_build() and omap_device_build_parent() call
omap_device_build_ss()?
Archit
> +{
> + struct platform_device *pdev;
> + struct omap_device *od;
> + struct omap_hwmod *ohs[1];
> + struct omap_hwmod *oh;
> + int r;
> +
> + oh = omap_hwmod_lookup(oh_name);
> + if (!oh) {
> + pr_err("Could not look up %s\n", oh_name);
> + r = -ENODEV;
> + goto err;
> + }
> +
> + pdev = platform_device_alloc(pdev_name, pdev_id);
> + if (!pdev) {
> + pr_err("Could not create pdev for %s\n", pdev_name);
> + r = -ENOMEM;
> + goto err;
> + }
> +
> + if (parent != NULL)
> + pdev->dev.parent =&parent->dev;
> +
> + if (pdev->id != -1)
> + dev_set_name(&pdev->dev, "%s.%d", pdev->name, pdev->id);
> + else
> + dev_set_name(&pdev->dev, "%s", pdev->name);
> +
> + ohs[0] = oh;
> + od = omap_device_alloc(pdev, ohs, 1, NULL, 0);
> + if (!od) {
> + pr_err("Could not alloc omap_device for %s\n", pdev_name);
> + r = -ENOMEM;
> + goto err;
> + }
> +
> + r = platform_device_add_data(pdev, pdata, pdata_len);
> + if (r) {
> + pr_err("Could not set pdata for %s\n", pdev_name);
> + goto err;
> + }
> +
> + r = omap_device_register(pdev);
> + if (r) {
> + pr_err("Could not register omap_device for %s\n", pdev_name);
> + goto err;
> + }
> +
> + return pdev;
> +
> +err:
> + return ERR_PTR(r);
> +}
> +
> int __init omap_display_init(struct omap_dss_board_info *board_data)
> {
> int r = 0;
> - struct omap_hwmod *oh;
> struct platform_device *pdev;
> int i, oh_count;
> const struct omap_dss_hwmod_data *curr_dss_hwmod;
> + struct platform_device *dss_pdev;
>
> /* create omapdss device */
>
> @@ -221,22 +279,24 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)
> oh_count = ARRAY_SIZE(omap4_dss_hwmod_data);
> }
>
> - for (i = 0; i< oh_count; i++) {
> - oh = omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);
> - if (!oh) {
> - pr_err("Could not look up %s\n",
> - curr_dss_hwmod[i].oh_name);
> - return -ENODEV;
> - }
> + dss_pdev = NULL;
>
> - pdev = omap_device_build(curr_dss_hwmod[i].dev_name,
> - curr_dss_hwmod[i].id, oh,
> + for (i = 0; i< oh_count; i++) {
> + pdev = create_dss_pdev(curr_dss_hwmod[i].dev_name,
> + curr_dss_hwmod[i].id,
> + curr_dss_hwmod[i].oh_name,
> NULL, 0,
> - NULL, 0, 0);
> + dss_pdev);
> +
> + if (IS_ERR(pdev)) {
> + pr_err("Could not build omap_device for %s\n",
> + curr_dss_hwmod[i].oh_name);
> +
> + return PTR_ERR(pdev);
> + }
>
> - if (WARN((IS_ERR(pdev)), "Could not build omap_device for %s\n",
> - curr_dss_hwmod[i].oh_name))
> - return -ENODEV;
> + if (i = 0)
> + dss_pdev = pdev;
> }
>
> return 0;
^ permalink raw reply
* [PATCH v2] video: exynos_dp: remove unnecessary header includes
From: Jingoo Han @ 2012-05-04 6:25 UTC (permalink / raw)
To: linux-fbdev
Remove unnecessary headers from the file.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/exynos/exynos_dp_core.c | 2 --
drivers/video/exynos/exynos_dp_reg.c | 2 --
2 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
index 6e9f3ce..ef4d1ab 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -21,8 +21,6 @@
#include <video/exynos_dp.h>
-#include <plat/cpu.h>
-
#include "exynos_dp_core.h"
static int exynos_dp_init_dp(struct exynos_dp_device *dp)
diff --git a/drivers/video/exynos/exynos_dp_reg.c b/drivers/video/exynos/exynos_dp_reg.c
index 3863726..99bafb8 100644
--- a/drivers/video/exynos/exynos_dp_reg.c
+++ b/drivers/video/exynos/exynos_dp_reg.c
@@ -16,8 +16,6 @@
#include <video/exynos_dp.h>
-#include <plat/cpu.h>
-
#include "exynos_dp_core.h"
#include "exynos_dp_reg.h"
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 11/25] OMAPDSS: create custom pdevs for DSS omap_devices
From: Archit Taneja @ 2012-05-04 8:29 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336053481-25433-12-git-send-email-tomi.valkeinen@ti.com>
On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
> Instead of using omap_device_build() to create the omap_devices for DSS
> hwmods, create them with a custom function. This will allow us to create
> a parent-child hierarchy for the devices so that the omapdss_core device
> is parent for the rest of the dss hwmod devices.
>
> Signed-off-by: Tomi Valkeinen<tomi.valkeinen@ti.com>
> ---
> arch/arm/mach-omap2/display.c | 88 ++++++++++++++++++++++++++++++++++-------
> 1 file changed, 74 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> index 07232fd..46d2a98 100644
> --- a/arch/arm/mach-omap2/display.c
> +++ b/arch/arm/mach-omap2/display.c
> @@ -185,13 +185,71 @@ static int omap_dss_set_min_bus_tput(struct device *dev, unsigned long tput)
> return omap_pm_set_min_bus_tput(dev, OCP_INITIATOR_AGENT, tput);
> }
>
> +static struct platform_device *create_dss_pdev(const char *pdev_name,
> + int pdev_id, const char *oh_name, void *pdata, int pdata_len,
> + struct platform_device *parent)
> +{
> + struct platform_device *pdev;
> + struct omap_device *od;
> + struct omap_hwmod *ohs[1];
> + struct omap_hwmod *oh;
> + int r;
> +
> + oh = omap_hwmod_lookup(oh_name);
> + if (!oh) {
> + pr_err("Could not look up %s\n", oh_name);
> + r = -ENODEV;
> + goto err;
> + }
> +
> + pdev = platform_device_alloc(pdev_name, pdev_id);
> + if (!pdev) {
> + pr_err("Could not create pdev for %s\n", pdev_name);
> + r = -ENOMEM;
> + goto err;
> + }
> +
> + if (parent != NULL)
> + pdev->dev.parent =&parent->dev;
> +
> + if (pdev->id != -1)
> + dev_set_name(&pdev->dev, "%s.%d", pdev->name, pdev->id);
> + else
> + dev_set_name(&pdev->dev, "%s", pdev->name);
> +
> + ohs[0] = oh;
> + od = omap_device_alloc(pdev, ohs, 1, NULL, 0);
> + if (!od) {
> + pr_err("Could not alloc omap_device for %s\n", pdev_name);
> + r = -ENOMEM;
> + goto err;
> + }
> +
> + r = platform_device_add_data(pdev, pdata, pdata_len);
> + if (r) {
> + pr_err("Could not set pdata for %s\n", pdev_name);
> + goto err;
> + }
> +
> + r = omap_device_register(pdev);
> + if (r) {
> + pr_err("Could not register omap_device for %s\n", pdev_name);
> + goto err;
> + }
> +
> + return pdev;
> +
> +err:
> + return ERR_PTR(r);
> +}
> +
> int __init omap_display_init(struct omap_dss_board_info *board_data)
> {
> int r = 0;
> - struct omap_hwmod *oh;
> struct platform_device *pdev;
> int i, oh_count;
> const struct omap_dss_hwmod_data *curr_dss_hwmod;
> + struct platform_device *dss_pdev;
>
> /* create omapdss device */
>
> @@ -221,22 +279,24 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)
> oh_count = ARRAY_SIZE(omap4_dss_hwmod_data);
> }
>
> - for (i = 0; i< oh_count; i++) {
> - oh = omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);
> - if (!oh) {
> - pr_err("Could not look up %s\n",
> - curr_dss_hwmod[i].oh_name);
> - return -ENODEV;
> - }
> + dss_pdev = NULL;
>
> - pdev = omap_device_build(curr_dss_hwmod[i].dev_name,
> - curr_dss_hwmod[i].id, oh,
> + for (i = 0; i< oh_count; i++) {
> + pdev = create_dss_pdev(curr_dss_hwmod[i].dev_name,
> + curr_dss_hwmod[i].id,
> + curr_dss_hwmod[i].oh_name,
> NULL, 0,
> - NULL, 0, 0);
> + dss_pdev);
> +
> + if (IS_ERR(pdev)) {
> + pr_err("Could not build omap_device for %s\n",
> + curr_dss_hwmod[i].oh_name);
> +
> + return PTR_ERR(pdev);
> + }
>
> - if (WARN((IS_ERR(pdev)), "Could not build omap_device for %s\n",
> - curr_dss_hwmod[i].oh_name))
> - return -ENODEV;
> + if (i = 0)
> + dss_pdev = pdev;
The above line is a bit tricky to understand, maybe something like this
may explain the parent-child setting better:
if (!strcmp(curr_dss_hwmod[i].oh_name, "dss_core"))
dss_pdev = pdev;
I had another general question about the parent-child series. What is
the use of the platform device omap_display_device (with the name
"omapdss"). Is it just a way to get the board data?
Archit
> }
>
> return 0;
^ permalink raw reply
* Re: [PATCH 08/25] OMAPDSS: clean up the omapdss platform data mess
From: Tomi Valkeinen @ 2012-05-04 8:32 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <4FA369D2.1070809@ti.com>
[-- Attachment #1: Type: text/plain, Size: 3066 bytes --]
On Fri, 2012-05-04 at 11:02 +0530, Archit Taneja wrote:
> Hi,
>
> On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
> > The omapdss pdata handling is a mess. This is more evident when trying
> > to use device tree for DSS, as we don't have platform data anymore in
> > that case. This patch cleans the pdata handling by:
> >
> > - Remove struct omap_display_platform_data. It was used just as a
> > wrapper for struct omap_dss_board_info.
> > - Pass the platform data only to omapdss device. The drivers for omap
> > dss hwmods do not need the platform data. This should also work better
> > for DT, as we can create omapdss device programmatically in generic omap
> > boot code, and thus we can pass the pdata to it.
> > - Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
> > that the dss hwmod drivers can call.
> >
> > Signed-off-by: Tomi Valkeinen<tomi.valkeinen@ti.com>
> > ---
> > arch/arm/mach-omap2/display.c | 39 +++++++++++++++++++--------------------
> > drivers/video/omap2/dss/core.c | 35 +++++++++++++++++++++++++++++++++++
> > drivers/video/omap2/dss/dispc.c | 21 ++-------------------
> > drivers/video/omap2/dss/dsi.c | 17 +++--------------
> > drivers/video/omap2/dss/dss.h | 3 +++
> > drivers/video/omap2/dss/hdmi.c | 2 --
> > include/video/omapdss.h | 5 -----
> > 7 files changed, 62 insertions(+), 60 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> > index 60cded4..07232fd 100644
> > --- a/arch/arm/mach-omap2/display.c
> > +++ b/arch/arm/mach-omap2/display.c
> > @@ -191,10 +191,24 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)
> > struct omap_hwmod *oh;
> > struct platform_device *pdev;
> > int i, oh_count;
> > - struct omap_display_platform_data pdata;
> > const struct omap_dss_hwmod_data *curr_dss_hwmod;
> >
> > - memset(&pdata, 0, sizeof(pdata));
> > + /* create omapdss device */
> > +
> > + board_data->dsi_enable_pads = omap_dsi_enable_pads;
> > + board_data->dsi_disable_pads = omap_dsi_disable_pads;
> > + board_data->get_context_loss_count = omap_pm_get_dev_context_loss_count;
> > + board_data->set_min_bus_tput = omap_dss_set_min_bus_tput;
> > +
> > + omap_display_device.dev.platform_data = board_data;
> > +
> > + r = platform_device_register(&omap_display_device);
> > + if (r< 0) {
> > + pr_err("Unable to register omapdss device\n");
> > + return r;
> > + }
>
> After this patch, the "omapdss" platform device is registered before the
> other dss platform devices. This would change the sequence of probes of
> these devices. Was this intentional?
Hmm. The sequence shouldn't change. The order in which the devices are
registered doesn't matter if there are no drivers registered yet. When
the drivers are registered, and there's a device for it, the probe will
be done. So in this case the order of the driver registration will
dictate the order of probes.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 11/25] OMAPDSS: create custom pdevs for DSS omap_devices
From: Tomi Valkeinen @ 2012-05-04 8:37 UTC (permalink / raw)
To: Archit Taneja, Paul Walmsley, Kevin Hilman; +Cc: linux-omap, linux-fbdev
In-Reply-To: <4FA37139.9020501@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1859 bytes --]
On Fri, 2012-05-04 at 11:33 +0530, Archit Taneja wrote:
> Hi,
>
> On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
> > Instead of using omap_device_build() to create the omap_devices for DSS
> > hwmods, create them with a custom function. This will allow us to create
> > a parent-child hierarchy for the devices so that the omapdss_core device
> > is parent for the rest of the dss hwmod devices.
> >
> > Signed-off-by: Tomi Valkeinen<tomi.valkeinen@ti.com>
> > ---
> > arch/arm/mach-omap2/display.c | 88 ++++++++++++++++++++++++++++++++++-------
> > 1 file changed, 74 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> > index 07232fd..46d2a98 100644
> > --- a/arch/arm/mach-omap2/display.c
> > +++ b/arch/arm/mach-omap2/display.c
> > @@ -185,13 +185,71 @@ static int omap_dss_set_min_bus_tput(struct device *dev, unsigned long tput)
> > return omap_pm_set_min_bus_tput(dev, OCP_INITIATOR_AGENT, tput);
> > }
> >
> > +static struct platform_device *create_dss_pdev(const char *pdev_name,
> > + int pdev_id, const char *oh_name, void *pdata, int pdata_len,
> > + struct platform_device *parent)
>
> This function looks quite generic, it's like omap_device_build() but
> with a parent associated. omap_device_build() seems to be a special case
> of this function with parent passed as null. Won't this
> function be needed by other devices too?
>
> Maybe we could modify omap_device_build_ss() to take a parent argument,
> and make a function called omap_device_build_parent(), where both
> omap_device_build() and omap_device_build_parent() call
> omap_device_build_ss()?
Yes, that sounds good to me.
Paul, Kevin, what do you think, could the omap_device functions be
extended to allow setting a parent device?
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] i2c: Split I2C_M_NOSTART support out of I2C_FUNC_PROTOCOL_MANGLING
From: Jean Delvare @ 2012-05-04 8:39 UTC (permalink / raw)
To: Wolfram Sang
Cc: Mark Brown, Florian Tobias Schandinat, Dmitry Torokhov, linux-i2c,
linux-input, linux-fbdev
In-Reply-To: <20120503113546.GG9574@pengutronix.de>
Hi Wolfram,
On Thu, 3 May 2012 13:35:46 +0200, Wolfram Sang wrote:
> On Thu, May 03, 2012 at 11:53:36AM +0100, Mark Brown wrote:
> > Since there are uses for I2C_M_NOSTART which are much more sensible and
> > standard than most of the protocol mangling functionality (the main one
> > being gather writes to devices where something like a register address
> > needs to be inserted before a block of data) create a new I2C_FUNC_NOSTART
> > for this feature and update all the users to use it.
> >
> > In the case of regmap-i2c we remove the requirement for mangling as
> > I2C_M_NOSTART is the only mangling feature which is being used.
> >
> > Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
>
> Applied to next, thanks! Jean, let me know if you prefer to take it.
> Acks from input and fbdev maintainers still appreciated.
I'd prefer to take it, yes, as it touches the core infrastructure.
Thanks,
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH 08/25] OMAPDSS: clean up the omapdss platform data mess
From: Archit Taneja @ 2012-05-04 8:48 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336120320.2701.1.camel@deskari>
On Friday 04 May 2012 02:02 PM, Tomi Valkeinen wrote:
> On Fri, 2012-05-04 at 11:02 +0530, Archit Taneja wrote:
>> Hi,
>>
>> On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
>>> The omapdss pdata handling is a mess. This is more evident when trying
>>> to use device tree for DSS, as we don't have platform data anymore in
>>> that case. This patch cleans the pdata handling by:
>>>
>>> - Remove struct omap_display_platform_data. It was used just as a
>>> wrapper for struct omap_dss_board_info.
>>> - Pass the platform data only to omapdss device. The drivers for omap
>>> dss hwmods do not need the platform data. This should also work better
>>> for DT, as we can create omapdss device programmatically in generic omap
>>> boot code, and thus we can pass the pdata to it.
>>> - Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
>>> that the dss hwmod drivers can call.
>>>
>>> Signed-off-by: Tomi Valkeinen<tomi.valkeinen@ti.com>
>>> ---
>>> arch/arm/mach-omap2/display.c | 39 +++++++++++++++++++--------------------
>>> drivers/video/omap2/dss/core.c | 35 +++++++++++++++++++++++++++++++++++
>>> drivers/video/omap2/dss/dispc.c | 21 ++-------------------
>>> drivers/video/omap2/dss/dsi.c | 17 +++--------------
>>> drivers/video/omap2/dss/dss.h | 3 +++
>>> drivers/video/omap2/dss/hdmi.c | 2 --
>>> include/video/omapdss.h | 5 -----
>>> 7 files changed, 62 insertions(+), 60 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
>>> index 60cded4..07232fd 100644
>>> --- a/arch/arm/mach-omap2/display.c
>>> +++ b/arch/arm/mach-omap2/display.c
>>> @@ -191,10 +191,24 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)
>>> struct omap_hwmod *oh;
>>> struct platform_device *pdev;
>>> int i, oh_count;
>>> - struct omap_display_platform_data pdata;
>>> const struct omap_dss_hwmod_data *curr_dss_hwmod;
>>>
>>> - memset(&pdata, 0, sizeof(pdata));
>>> + /* create omapdss device */
>>> +
>>> + board_data->dsi_enable_pads = omap_dsi_enable_pads;
>>> + board_data->dsi_disable_pads = omap_dsi_disable_pads;
>>> + board_data->get_context_loss_count = omap_pm_get_dev_context_loss_count;
>>> + board_data->set_min_bus_tput = omap_dss_set_min_bus_tput;
>>> +
>>> + omap_display_device.dev.platform_data = board_data;
>>> +
>>> + r = platform_device_register(&omap_display_device);
>>> + if (r< 0) {
>>> + pr_err("Unable to register omapdss device\n");
>>> + return r;
>>> + }
>>
>> After this patch, the "omapdss" platform device is registered before the
>> other dss platform devices. This would change the sequence of probes of
>> these devices. Was this intentional?
>
> Hmm. The sequence shouldn't change. The order in which the devices are
> registered doesn't matter if there are no drivers registered yet. When
> the drivers are registered, and there's a device for it, the probe will
> be done. So in this case the order of the driver registration will
> dictate the order of probes.
Oh okay, I don't know where the initcalls exactly happen, but I guess
they will happen after the .init_machine op in the board file.
Do you know where the initcalls happen, I couldn't find it by browsing
the kernel code :)
Archit
>
> Tomi
>
^ permalink raw reply
* Re: [PATCH 08/25] OMAPDSS: clean up the omapdss platform data mess
From: Tomi Valkeinen @ 2012-05-04 8:49 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <4FA39501.3070205@ti.com>
[-- Attachment #1: Type: text/plain, Size: 850 bytes --]
On Fri, 2012-05-04 at 14:06 +0530, Archit Taneja wrote:
> On Friday 04 May 2012 02:02 PM, Tomi Valkeinen wrote:
> > Hmm. The sequence shouldn't change. The order in which the devices are
> > registered doesn't matter if there are no drivers registered yet. When
> > the drivers are registered, and there's a device for it, the probe will
> > be done. So in this case the order of the driver registration will
> > dictate the order of probes.
>
> Oh okay, I don't know where the initcalls exactly happen, but I guess
> they will happen after the .init_machine op in the board file.
>
> Do you know where the initcalls happen, I couldn't find it by browsing
> the kernel code :)
Well, include/linux/init.h lists the inits in order. machine init is not
there, I guess it's not part of the init order, but even earlier.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 11/25] OMAPDSS: create custom pdevs for DSS omap_devices
From: Tomi Valkeinen @ 2012-05-04 9:00 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <4FA39091.8010007@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2912 bytes --]
On Fri, 2012-05-04 at 13:47 +0530, Archit Taneja wrote:
> On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
> > @@ -221,22 +279,24 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)
> > oh_count = ARRAY_SIZE(omap4_dss_hwmod_data);
> > }
> >
> > - for (i = 0; i< oh_count; i++) {
> > - oh = omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);
> > - if (!oh) {
> > - pr_err("Could not look up %s\n",
> > - curr_dss_hwmod[i].oh_name);
> > - return -ENODEV;
> > - }
> > + dss_pdev = NULL;
> >
> > - pdev = omap_device_build(curr_dss_hwmod[i].dev_name,
> > - curr_dss_hwmod[i].id, oh,
> > + for (i = 0; i< oh_count; i++) {
> > + pdev = create_dss_pdev(curr_dss_hwmod[i].dev_name,
> > + curr_dss_hwmod[i].id,
> > + curr_dss_hwmod[i].oh_name,
> > NULL, 0,
> > - NULL, 0, 0);
> > + dss_pdev);
> > +
> > + if (IS_ERR(pdev)) {
> > + pr_err("Could not build omap_device for %s\n",
> > + curr_dss_hwmod[i].oh_name);
> > +
> > + return PTR_ERR(pdev);
> > + }
> >
> > - if (WARN((IS_ERR(pdev)), "Could not build omap_device for %s\n",
> > - curr_dss_hwmod[i].oh_name))
> > - return -ENODEV;
> > + if (i == 0)
> > + dss_pdev = pdev;
>
> The above line is a bit tricky to understand, maybe something like this
> may explain the parent-child setting better:
>
> if (!strcmp(curr_dss_hwmod[i].oh_name, "dss_core"))
> dss_pdev = pdev;
I agree that it's a bit confusing. But your suggestion is not very good
either, as the code does not work properly if the dss_core is not the
first one created. I'll look into it. Perhaps I can separate the code
into a small function, and then I can more easily do something like:
dss_pdev = create_the_device();
for () {
// create the rest of the devices
create_the_device();
}
and that would clarify what's going on.
> I had another general question about the parent-child series. What is
> the use of the platform device omap_display_device (with the name
> "omapdss"). Is it just a way to get the board data?
Originally, before hwmods, we had only omapdss device, which contained
all the dss code. Then came hwmods, and the omapdss was split into
smaller devices, but omapdss was still there.
As I see it, omapdss is currently a "virtual" higher level device
(virtual in the sense that it doesn't correspond directly to any HW),
and the code for omapdss is more or less in the core.c file. It's used
to pass the board data, but also has some generic dss stuff that all dss
subdevices can use.
I think in the long run we should remove omapdss device, and probably
handle the generic stuff in dss_core (dss.c), which, as a parent to
other subdevices, should fit fine for the role.
For the time being we can't remove it. It's the only simple way to pass
callbacks from the arch code with device tree.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 24/25] OMAPDSS: DSI: improve DSI module id handling
From: Archit Taneja @ 2012-05-04 9:21 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336053481-25433-25-git-send-email-tomi.valkeinen@ti.com>
On Thursday 03 May 2012 07:28 PM, Tomi Valkeinen wrote:
> We currently use the id of the dsi platform device (dsidev->id) as the
> DSI hardware module ID. This works because we assign the ID manually in
> arch/arm/mach-omap2/display.c at boot time.
>
> However, with device tree the platform device IDs are automatically
> assigned to an arbitrary number, and we can't use it.
If this number is arbitrary we would need to change the "dsi_pdev_map"
approach of mapping a dsi module and it's corresponding platform device.
Currently dsi_pdev_map is:
static struct platform_device *dsi_pdev_map[MAX_NUM_DSI];
So we either need to increase the array size to take larger arbitrary
numbers, or do something else.
We would also need to fix the usage of dsi_get_dsidev_from_id(), as
right now we manually pass 0 and 1 to it only, for example:
static void dsi1_dump_irqs(struct seq_file *s)
{
struct platform_device *dsidev = dsi_get_dsidev_from_id(0);
dsi_dump_dsidev_irqs(dsidev, s);
}
The immediate solution that comes to mind is to maintain 2 id's, one
which is sequential, and the other which the DT has created, and keep an
array to map these. But this seems messy!
Archit
>
> Instead of using dsidev->id during operation, this patch stores the
> value of dsidev->id to a private field of the dsi driver at probe(). The
> future device tree code can thus set the private field with some other
> way.
>
> Signed-off-by: Tomi Valkeinen<tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/dsi.c | 46 +++++++++++++++++++----------------------
> 1 file changed, 21 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
> index 6cc92a8..ce964dd 100644
> --- a/drivers/video/omap2/dss/dsi.c
> +++ b/drivers/video/omap2/dss/dsi.c
> @@ -256,6 +256,8 @@ struct dsi_data {
> struct platform_device *pdev;
> void __iomem *base;
>
> + int module_id;
> +
> int irq;
>
> struct clk *dss_clk;
> @@ -358,11 +360,6 @@ struct platform_device *dsi_get_dsidev_from_id(int module)
> return dsi_pdev_map[module];
> }
>
> -static inline int dsi_get_dsidev_id(struct platform_device *dsidev)
> -{
> - return dsidev->id;
> -}
> -
> static inline void dsi_write_reg(struct platform_device *dsidev,
> const struct dsi_reg idx, u32 val)
> {
> @@ -1181,10 +1178,9 @@ static unsigned long dsi_get_txbyteclkhs(struct platform_device *dsidev)
> static unsigned long dsi_fclk_rate(struct platform_device *dsidev)
> {
> unsigned long r;
> - int dsi_module = dsi_get_dsidev_id(dsidev);
> struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
>
> - if (dss_get_dsi_clk_source(dsi_module) = OMAP_DSS_CLK_SRC_FCK) {
> + if (dss_get_dsi_clk_source(dsi->module_id) = OMAP_DSS_CLK_SRC_FCK) {
> /* DSI FCLK source is DSS_CLK_FCK */
> r = clk_get_rate(dsi->dss_clk);
> } else {
> @@ -1683,7 +1679,7 @@ static void dsi_dump_dsidev_clocks(struct platform_device *dsidev,
> struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
> struct dsi_clock_info *cinfo =&dsi->current_cinfo;
> enum omap_dss_clk_source dispc_clk_src, dsi_clk_src;
> - int dsi_module = dsi_get_dsidev_id(dsidev);
> + int dsi_module = dsi->module_id;
>
> dispc_clk_src = dss_get_dispc_clk_source();
> dsi_clk_src = dss_get_dsi_clk_source(dsi_module);
> @@ -1755,7 +1751,6 @@ static void dsi_dump_dsidev_irqs(struct platform_device *dsidev,
> struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
> unsigned long flags;
> struct dsi_irq_stats stats;
> - int dsi_module = dsi_get_dsidev_id(dsidev);
>
> spin_lock_irqsave(&dsi->irq_stats_lock, flags);
>
> @@ -1772,7 +1767,7 @@ static void dsi_dump_dsidev_irqs(struct platform_device *dsidev,
> #define PIS(x) \
> seq_printf(s, "%-20s %10d\n", #x, stats.dsi_irqs[ffs(DSI_IRQ_##x)-1]);
>
> - seq_printf(s, "-- DSI%d interrupts --\n", dsi_module + 1);
> + seq_printf(s, "-- DSI%d interrupts --\n", dsi->module_id + 1);
> PIS(VC0);
> PIS(VC1);
> PIS(VC2);
> @@ -2272,7 +2267,7 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
>
> DSSDBGF();
>
> - r = dss_dsi_enable_pads(dsi_get_dsidev_id(dsidev), dsi_get_lane_mask(dssdev));
> + r = dss_dsi_enable_pads(dsi->module_id, dsi_get_lane_mask(dssdev));
> if (r)
> return r;
>
> @@ -2382,20 +2377,21 @@ err_cio_pwr:
> dsi_cio_disable_lane_override(dsidev);
> err_scp_clk_dom:
> dsi_disable_scp_clk(dsidev);
> - dss_dsi_disable_pads(dsi_get_dsidev_id(dsidev), dsi_get_lane_mask(dssdev));
> + dss_dsi_disable_pads(dsi->module_id, dsi_get_lane_mask(dssdev));
> return r;
> }
>
> static void dsi_cio_uninit(struct omap_dss_device *dssdev)
> {
> struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
> + struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
>
> /* DDR_CLK_ALWAYS_ON */
> REG_FLD_MOD(dsidev, DSI_CLK_CTRL, 0, 13, 13);
>
> dsi_cio_power(dsidev, DSI_COMPLEXIO_POWER_OFF);
> dsi_disable_scp_clk(dsidev);
> - dss_dsi_disable_pads(dsi_get_dsidev_id(dsidev), dsi_get_lane_mask(dssdev));
> + dss_dsi_disable_pads(dsi->module_id, dsi_get_lane_mask(dssdev));
> }
>
> static void dsi_config_tx_fifo(struct platform_device *dsidev,
> @@ -4277,7 +4273,7 @@ static int dsi_configure_dispc_clocks(struct omap_dss_device *dssdev)
> static int dsi_display_init_dsi(struct omap_dss_device *dssdev)
> {
> struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
> - int dsi_module = dsi_get_dsidev_id(dsidev);
> + struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
> int r;
>
> r = dsi_pll_init(dsidev, true, true);
> @@ -4289,7 +4285,7 @@ static int dsi_display_init_dsi(struct omap_dss_device *dssdev)
> goto err1;
>
> dss_select_dispc_clk_source(dssdev->clocks.dispc.dispc_fclk_src);
> - dss_select_dsi_clk_source(dsi_module, dssdev->clocks.dsi.dsi_fclk_src);
> + dss_select_dsi_clk_source(dsi->module_id, dssdev->clocks.dsi.dsi_fclk_src);
> dss_select_lcd_clk_source(dssdev->manager->id,
> dssdev->clocks.dispc.channel.lcd_clk_src);
>
> @@ -4328,7 +4324,7 @@ err3:
> dsi_cio_uninit(dssdev);
> err2:
> dss_select_dispc_clk_source(OMAP_DSS_CLK_SRC_FCK);
> - dss_select_dsi_clk_source(dsi_module, OMAP_DSS_CLK_SRC_FCK);
> + dss_select_dsi_clk_source(dsi->module_id, OMAP_DSS_CLK_SRC_FCK);
> dss_select_lcd_clk_source(dssdev->manager->id, OMAP_DSS_CLK_SRC_FCK);
>
> err1:
> @@ -4342,7 +4338,6 @@ static void dsi_display_uninit_dsi(struct omap_dss_device *dssdev,
> {
> struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
> struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
> - int dsi_module = dsi_get_dsidev_id(dsidev);
>
> if (enter_ulps&& !dsi->ulps_enabled)
> dsi_enter_ulps(dsidev);
> @@ -4355,7 +4350,7 @@ static void dsi_display_uninit_dsi(struct omap_dss_device *dssdev,
> dsi_vc_enable(dsidev, 3, 0);
>
> dss_select_dispc_clk_source(OMAP_DSS_CLK_SRC_FCK);
> - dss_select_dsi_clk_source(dsi_module, OMAP_DSS_CLK_SRC_FCK);
> + dss_select_dsi_clk_source(dsi->module_id, OMAP_DSS_CLK_SRC_FCK);
> dss_select_lcd_clk_source(dssdev->manager->id, OMAP_DSS_CLK_SRC_FCK);
> dsi_cio_uninit(dssdev);
> dsi_pll_uninit(dsidev, disconnect_lanes);
> @@ -4616,7 +4611,7 @@ static void dsi_put_clocks(struct platform_device *dsidev)
> static int __init omap_dsihw_probe(struct platform_device *dsidev)
> {
> u32 rev;
> - int r, i, dsi_module = dsi_get_dsidev_id(dsidev);
> + int r, i;
> struct resource *dsi_mem;
> struct dsi_data *dsi;
> struct omap_dss_board_info *pdata = dsidev->dev.platform_data;
> @@ -4625,8 +4620,9 @@ static int __init omap_dsihw_probe(struct platform_device *dsidev)
> if (!dsi)
> return -ENOMEM;
>
> + dsi->module_id = dsidev->id;
> dsi->pdev = dsidev;
> - dsi_pdev_map[dsi_module] = dsidev;
> + dsi_pdev_map[dsi->module_id] = dsidev;
> dev_set_drvdata(&dsidev->dev, dsi);
>
> spin_lock_init(&dsi->irq_lock);
> @@ -4712,7 +4708,7 @@ static int __init omap_dsihw_probe(struct platform_device *dsidev)
> if (dssdev->type != OMAP_DISPLAY_TYPE_DSI)
> continue;
>
> - if (dssdev->phy.dsi.module != dsi_module)
> + if (dssdev->phy.dsi.module != dsi->module_id)
> continue;
>
> r = dsi_init_display(dssdev);
> @@ -4729,15 +4725,15 @@ static int __init omap_dsihw_probe(struct platform_device *dsidev)
>
> dsi_runtime_put(dsidev);
>
> - if (dsi_module = 0)
> + if (dsi->module_id = 0)
> dss_debugfs_create_file("dsi1_regs", dsi1_dump_regs);
> - else if (dsi_module = 1)
> + else if (dsi->module_id = 1)
> dss_debugfs_create_file("dsi2_regs", dsi2_dump_regs);
>
> #ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
> - if (dsi_module = 0)
> + if (dsi->module_id = 0)
> dss_debugfs_create_file("dsi1_irqs", dsi1_dump_irqs);
> - else if (dsi_module = 1)
> + else if (dsi->module_id = 1)
> dss_debugfs_create_file("dsi2_irqs", dsi2_dump_irqs);
> #endif
> return 0;
^ permalink raw reply
* Re: [PATCH 11/25] OMAPDSS: create custom pdevs for DSS omap_devices
From: Archit Taneja @ 2012-05-04 9:25 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336122006.2701.19.camel@deskari>
On Friday 04 May 2012 02:30 PM, Tomi Valkeinen wrote:
> On Fri, 2012-05-04 at 13:47 +0530, Archit Taneja wrote:
>> On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
>
>>> @@ -221,22 +279,24 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)
>>> oh_count = ARRAY_SIZE(omap4_dss_hwmod_data);
>>> }
>>>
>>> - for (i = 0; i< oh_count; i++) {
>>> - oh = omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);
>>> - if (!oh) {
>>> - pr_err("Could not look up %s\n",
>>> - curr_dss_hwmod[i].oh_name);
>>> - return -ENODEV;
>>> - }
>>> + dss_pdev = NULL;
>>>
>>> - pdev = omap_device_build(curr_dss_hwmod[i].dev_name,
>>> - curr_dss_hwmod[i].id, oh,
>>> + for (i = 0; i< oh_count; i++) {
>>> + pdev = create_dss_pdev(curr_dss_hwmod[i].dev_name,
>>> + curr_dss_hwmod[i].id,
>>> + curr_dss_hwmod[i].oh_name,
>>> NULL, 0,
>>> - NULL, 0, 0);
>>> + dss_pdev);
>>> +
>>> + if (IS_ERR(pdev)) {
>>> + pr_err("Could not build omap_device for %s\n",
>>> + curr_dss_hwmod[i].oh_name);
>>> +
>>> + return PTR_ERR(pdev);
>>> + }
>>>
>>> - if (WARN((IS_ERR(pdev)), "Could not build omap_device for %s\n",
>>> - curr_dss_hwmod[i].oh_name))
>>> - return -ENODEV;
>>> + if (i = 0)
>>> + dss_pdev = pdev;
>>
>> The above line is a bit tricky to understand, maybe something like this
>> may explain the parent-child setting better:
>>
>> if (!strcmp(curr_dss_hwmod[i].oh_name, "dss_core"))
>> dss_pdev = pdev;
>
> I agree that it's a bit confusing. But your suggestion is not very good
> either, as the code does not work properly if the dss_core is not the
> first one created. I'll look into it. Perhaps I can separate the code
> into a small function, and then I can more easily do something like:
Right, my suggestion wont work either.
>
> dss_pdev = create_the_device();
>
> for () {
> // create the rest of the devices
> create_the_device();
> }
>
> and that would clarify what's going on.
Yes, or you could just add a comment saying i = 0 is the dss_core
hwmod, and we make sure dss_core is the first one on the list.
>
>> I had another general question about the parent-child series. What is
>> the use of the platform device omap_display_device (with the name
>> "omapdss"). Is it just a way to get the board data?
>
> Originally, before hwmods, we had only omapdss device, which contained
> all the dss code. Then came hwmods, and the omapdss was split into
> smaller devices, but omapdss was still there.
>
> As I see it, omapdss is currently a "virtual" higher level device
> (virtual in the sense that it doesn't correspond directly to any HW),
> and the code for omapdss is more or less in the core.c file. It's used
> to pass the board data, but also has some generic dss stuff that all dss
> subdevices can use.
>
> I think in the long run we should remove omapdss device, and probably
> handle the generic stuff in dss_core (dss.c), which, as a parent to
> other subdevices, should fit fine for the role.
>
> For the time being we can't remove it. It's the only simple way to pass
> callbacks from the arch code with device tree.
Okay, makes sense now.
Thanks,
Archit
>
> Tomi
>
^ permalink raw reply
* Re: [PATCH 24/25] OMAPDSS: DSI: improve DSI module id handling
From: Tomi Valkeinen @ 2012-05-04 9:53 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <4FA39CBB.6010500@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2722 bytes --]
On Fri, 2012-05-04 at 14:39 +0530, Archit Taneja wrote:
> On Thursday 03 May 2012 07:28 PM, Tomi Valkeinen wrote:
> > We currently use the id of the dsi platform device (dsidev->id) as the
> > DSI hardware module ID. This works because we assign the ID manually in
> > arch/arm/mach-omap2/display.c at boot time.
> >
> > However, with device tree the platform device IDs are automatically
> > assigned to an arbitrary number, and we can't use it.
>
> If this number is arbitrary we would need to change the "dsi_pdev_map"
> approach of mapping a dsi module and it's corresponding platform device.
> Currently dsi_pdev_map is:
>
> static struct platform_device *dsi_pdev_map[MAX_NUM_DSI];
>
> So we either need to increase the array size to take larger arbitrary
> numbers, or do something else.
>
> We would also need to fix the usage of dsi_get_dsidev_from_id(), as
> right now we manually pass 0 and 1 to it only, for example:
>
> static void dsi1_dump_irqs(struct seq_file *s)
> {
> struct platform_device *dsidev = dsi_get_dsidev_from_id(0);
>
> dsi_dump_dsidev_irqs(dsidev, s);
> }
>
> The immediate solution that comes to mind is to maintain 2 id's, one
> which is sequential, and the other which the DT has created, and keep an
> array to map these. But this seems messy!
This is only a problem with device tree, and I solved it so that I pass
a DSI module ID in the device tree data. So, with old pdata way I
initialize dsi->module_id from the pdev->id, but with DT I initialize
dsi->module_id from the DT data.
So basically we remove the use of pdev->id in this patch, and add
dsi->module_id field, which needs to be initialized to 0 or 1, depending
on the corresponding HW module. We just happen to use the pdev->id to
initialize it when using the old pdata method, as we know it tells the
right id. But we could initialize it from any other source.
This allows us to keep the 0 and 1 DSI IDs, and I think we need those
anyway. Some parts of the code could work fine with arbitrary ID, as
long as a pdev can be linked to/from this ID. However, there are things
where we must have the ID, like configuring the clock source settings in
dss_core, where we set a certain bit for DSI module 0, and certain bit
for module 1.
Perhaps even those could be handled without explicit ID of 0 or 1, but
that doesn't sound trivial and I didn't want to start tackling that in
this series.
I wish there was a way to get the module ID from the HW registers
somehow. Then we wouldn't need to pass the ID via SW, which doesn't feel
very correct. At least with DT it's a bit wrong, in my opinion, but best
I could come up with.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] i2c: Split I2C_M_NOSTART support out of I2C_FUNC_PROTOCOL_MANGLING
From: Mark Brown @ 2012-05-04 10:08 UTC (permalink / raw)
To: Jean Delvare
Cc: Florian Tobias Schandinat, Dmitry Torokhov, Wolfram Sang,
linux-i2c, linux-input, linux-fbdev
In-Reply-To: <20120503203617.31179f9b@endymion.delvare>
[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]
On Thu, May 03, 2012 at 08:36:17PM +0200, Jean Delvare wrote:
> You must also update the description of I2C_FUNC_PROTOCOL_MANGLING to
> no longer mention I2C_M_NOSTART.
For backwards ABI compatibility _PROTCOL_MANGING still has to imply
_NOSTART, though it's unclear if that should be documented here. For
drivers it should for the most part flow naturally as I'd expect they'll
end up implementing one or more of the mangling flags anyway. For
applications I guess it means that they should fall back to checking for
_PROTOCOL_MANGLING if _NOSTART isn't there.
> > +#define I2C_FUNC_NOSTART 0x10000000 /* I2C_M_NOSTART */
> Sorry for nitpicking but wouldn't I2C_FUNC_GATHER be a better name?
> NOSTART is an implementation detail now, the high level feature is the
> ability to gather multiple messages into one.
I kept it this way mostly because it means that the capability flag has
the same name as the feature flag which seemed helpful from a usability
point of view.
There is also the fact you could in theory also implement gather support
in other ways (eg, using DMA) though at present there's no API level
support for this and the users do have to code this specific
implementation.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 24/25] OMAPDSS: DSI: improve DSI module id handling
From: Tomi Valkeinen @ 2012-05-04 10:11 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <4FA3A9E4.3040802@ti.com>
[-- Attachment #1: Type: text/plain, Size: 637 bytes --]
On Fri, 2012-05-04 at 15:35 +0530, Archit Taneja wrote:
> > This is only a problem with device tree, and I solved it so that I
> pass
> > a DSI module ID in the device tree data. So, with old pdata way I
> > initialize dsi->module_id from the pdev->id, but with DT I
> initialize
> > dsi->module_id from the DT data.
>
> Oh ok, so the code which decides how dsi->module_id is
> initialised(from
> DT or pdata) is not in this series right? And it would come later?
> Right
> now it's just set to dsidev->id in probe.
>
Yes, there's no DT code in this series, only cleanups to make adding DT
support easier.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 24/25] OMAPDSS: DSI: improve DSI module id handling
From: Archit Taneja @ 2012-05-04 10:17 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336125229.2701.30.camel@deskari>
On Friday 04 May 2012 03:23 PM, Tomi Valkeinen wrote:
> On Fri, 2012-05-04 at 14:39 +0530, Archit Taneja wrote:
>> On Thursday 03 May 2012 07:28 PM, Tomi Valkeinen wrote:
>>> We currently use the id of the dsi platform device (dsidev->id) as the
>>> DSI hardware module ID. This works because we assign the ID manually in
>>> arch/arm/mach-omap2/display.c at boot time.
>>>
>>> However, with device tree the platform device IDs are automatically
>>> assigned to an arbitrary number, and we can't use it.
>>
>> If this number is arbitrary we would need to change the "dsi_pdev_map"
>> approach of mapping a dsi module and it's corresponding platform device.
>> Currently dsi_pdev_map is:
>>
>> static struct platform_device *dsi_pdev_map[MAX_NUM_DSI];
>>
>> So we either need to increase the array size to take larger arbitrary
>> numbers, or do something else.
>>
>> We would also need to fix the usage of dsi_get_dsidev_from_id(), as
>> right now we manually pass 0 and 1 to it only, for example:
>>
>> static void dsi1_dump_irqs(struct seq_file *s)
>> {
>> struct platform_device *dsidev = dsi_get_dsidev_from_id(0);
>>
>> dsi_dump_dsidev_irqs(dsidev, s);
>> }
>>
>> The immediate solution that comes to mind is to maintain 2 id's, one
>> which is sequential, and the other which the DT has created, and keep an
>> array to map these. But this seems messy!
>
> This is only a problem with device tree, and I solved it so that I pass
> a DSI module ID in the device tree data. So, with old pdata way I
> initialize dsi->module_id from the pdev->id, but with DT I initialize
> dsi->module_id from the DT data.
Oh ok, so the code which decides how dsi->module_id is initialised(from
DT or pdata) is not in this series right? And it would come later? Right
now it's just set to dsidev->id in probe.
>
> So basically we remove the use of pdev->id in this patch, and add
> dsi->module_id field, which needs to be initialized to 0 or 1, depending
> on the corresponding HW module. We just happen to use the pdev->id to
> initialize it when using the old pdata method, as we know it tells the
> right id. But we could initialize it from any other source.
Right, I get it now.
>
> This allows us to keep the 0 and 1 DSI IDs, and I think we need those
> anyway. Some parts of the code could work fine with arbitrary ID, as
> long as a pdev can be linked to/from this ID. However, there are things
> where we must have the ID, like configuring the clock source settings in
> dss_core, where we set a certain bit for DSI module 0, and certain bit
> for module 1.
>
> Perhaps even those could be handled without explicit ID of 0 or 1, but
> that doesn't sound trivial and I didn't want to start tackling that in
> this series.
>
> I wish there was a way to get the module ID from the HW registers
> somehow. Then we wouldn't need to pass the ID via SW, which doesn't feel
> very correct. At least with DT it's a bit wrong, in my opinion, but best
> I could come up with.
We could derive it via a parameter like number of lanes or something
similar through DSI_GNQ, but that doesn't seem very nice, and may not be
usable on future OMAPs.
Archit
>
> Tomi
>
^ permalink raw reply
* [PATCH] i2c: Split I2C_M_NOSTART support out of I2C_FUNC_PROTOCOL_MANGLING
From: Mark Brown @ 2012-05-04 10:26 UTC (permalink / raw)
To: Jean Delvare, Florian Tobias Schandinat, Dmitry Torokhov,
Wolfram Sang
Cc: linux-i2c, linux-input, linux-fbdev, Mark Brown
In-Reply-To: <1335443839-22872-1-git-send-email-broonie@opensource.wolfsonmicro.com>
Since there are uses for I2C_M_NOSTART which are much more sensible and
standard than most of the protocol mangling functionality (the main one
being gather writes to devices where something like a register address
needs to be inserted before a block of data) create a new I2C_FUNC_NOSTART
for this feature and update all the users to use it.
Also strengthen the disrecommendation of the protocol mangling while we're
at it.
In the case of regmap-i2c we remove the requirement for mangling as
I2C_M_NOSTART is the only mangling feature which is being used.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
Documentation/i2c/functionality | 8 +++++---
Documentation/i2c/i2c-protocol | 9 ++++++++-
drivers/base/regmap/regmap-i2c.c | 2 +-
drivers/i2c/algos/i2c-algo-bit.c | 2 +-
drivers/i2c/busses/i2c-nuc900.c | 3 ++-
drivers/i2c/busses/i2c-s3c2410.c | 3 ++-
drivers/input/joystick/as5011.c | 1 +
drivers/video/matrox/matroxfb_maven.c | 1 +
include/linux/i2c.h | 5 +++--
9 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/Documentation/i2c/functionality b/Documentation/i2c/functionality
index 42c17c1..7cbd5da 100644
--- a/Documentation/i2c/functionality
+++ b/Documentation/i2c/functionality
@@ -18,9 +18,8 @@ For the most up-to-date list of functionality constants, please check
adapters typically can not do these)
I2C_FUNC_10BIT_ADDR Handles the 10-bit address extensions
I2C_FUNC_PROTOCOL_MANGLING Knows about the I2C_M_IGNORE_NAK,
- I2C_M_REV_DIR_ADDR, I2C_M_NOSTART and
- I2C_M_NO_RD_ACK flags (which modify the
- I2C protocol!)
+ I2C_M_REV_DIR_ADDR and I2C_M_NO_RD_ACK
+ flags (which modify the I2C protocol!).
I2C_FUNC_SMBUS_QUICK Handles the SMBus write_quick command
I2C_FUNC_SMBUS_READ_BYTE Handles the SMBus read_byte command
I2C_FUNC_SMBUS_WRITE_BYTE Handles the SMBus write_byte command
@@ -33,6 +32,7 @@ For the most up-to-date list of functionality constants, please check
I2C_FUNC_SMBUS_WRITE_BLOCK_DATA Handles the SMBus write_block_data command
I2C_FUNC_SMBUS_READ_I2C_BLOCK Handles the SMBus read_i2c_block_data command
I2C_FUNC_SMBUS_WRITE_I2C_BLOCK Handles the SMBus write_i2c_block_data command
+ I2C_FUNC_NOSTART Can skip repeated start sequence
A few combinations of the above flags are also defined for your convenience:
@@ -50,6 +50,8 @@ A few combinations of the above flags are also defined for your convenience:
emulated by a real I2C adapter (using
the transparent emulation layer)
+In kernel versions prior to 3.5 I2C_FUNC_NOSTART was implemented as
+part of I2C_FUNC_PROTOCOL_MANGLING.
ADAPTER IMPLEMENTATION
----------------------
diff --git a/Documentation/i2c/i2c-protocol b/Documentation/i2c/i2c-protocol
index 10518dd..0b3e62d 100644
--- a/Documentation/i2c/i2c-protocol
+++ b/Documentation/i2c/i2c-protocol
@@ -49,7 +49,9 @@ a byte read, followed by a byte write:
Modified transactions
==========
-We have found some I2C devices that needs the following modifications:
+The following modifications to the I2C protocol can also be generated,
+with the exception of I2C_M_NOSTART these are usually only needed to
+work around device issues:
Flag I2C_M_NOSTART:
In a combined transaction, no 'S Addr Wr/Rd [A]' is generated at some
@@ -60,6 +62,11 @@ We have found some I2C devices that needs the following modifications:
we do not generate Addr, but we do generate the startbit S. This will
probably confuse all other clients on your bus, so don't try this.
+ This is often used to gather transmits from multiple data buffers in
+ system memory into something that appears as a single transfer to the
+ I2C device but may also be used between direction changes by some
+ rare devices.
+
Flags I2C_M_REV_DIR_ADDR
This toggles the Rd/Wr flag. That is, if you want to do a write, but
need to emit an Rd instead of a Wr, or vice versa, you set this
diff --git a/drivers/base/regmap/regmap-i2c.c b/drivers/base/regmap/regmap-i2c.c
index 9a3a8c5..157bbd5 100644
--- a/drivers/base/regmap/regmap-i2c.c
+++ b/drivers/base/regmap/regmap-i2c.c
@@ -40,7 +40,7 @@ static int regmap_i2c_gather_write(struct device *dev,
/* If the I2C controller can't do a gather tell the core, it
* will substitute in a linear write for us.
*/
- if (!i2c_check_functionality(i2c->adapter, I2C_FUNC_PROTOCOL_MANGLING))
+ if (!i2c_check_functionality(i2c->adapter, I2C_FUNC_NOSTART))
return -ENOTSUPP;
xfer[0].addr = i2c->addr;
diff --git a/drivers/i2c/algos/i2c-algo-bit.c b/drivers/i2c/algos/i2c-algo-bit.c
index 7f0b832..fad22b0 100644
--- a/drivers/i2c/algos/i2c-algo-bit.c
+++ b/drivers/i2c/algos/i2c-algo-bit.c
@@ -608,7 +608,7 @@ bailout:
static u32 bit_func(struct i2c_adapter *adap)
{
- return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
+ return I2C_FUNC_I2C | I2C_FUNC_NOSTART | I2C_FUNC_SMBUS_EMUL |
I2C_FUNC_SMBUS_READ_BLOCK_DATA |
I2C_FUNC_SMBUS_BLOCK_PROC_CALL |
I2C_FUNC_10BIT_ADDR | I2C_FUNC_PROTOCOL_MANGLING;
diff --git a/drivers/i2c/busses/i2c-nuc900.c b/drivers/i2c/busses/i2c-nuc900.c
index 03b6157..a26dfb8 100644
--- a/drivers/i2c/busses/i2c-nuc900.c
+++ b/drivers/i2c/busses/i2c-nuc900.c
@@ -502,7 +502,8 @@ static int nuc900_i2c_xfer(struct i2c_adapter *adap,
/* declare our i2c functionality */
static u32 nuc900_i2c_func(struct i2c_adapter *adap)
{
- return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL | I2C_FUNC_PROTOCOL_MANGLING;
+ return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL | I2C_FUNC_NOSTART |
+ I2C_FUNC_PROTOCOL_MANGLING;
}
/* i2c bus registration info */
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 737f721..37b1f90 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -591,7 +591,8 @@ static int s3c24xx_i2c_xfer(struct i2c_adapter *adap,
/* declare our i2c functionality */
static u32 s3c24xx_i2c_func(struct i2c_adapter *adap)
{
- return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL | I2C_FUNC_PROTOCOL_MANGLING;
+ return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL | I2C_FUNC_NOSTART |
+ I2C_FUNC_PROTOCOL_MANGLING;
}
/* i2c bus registration info */
diff --git a/drivers/input/joystick/as5011.c b/drivers/input/joystick/as5011.c
index 3063464..57d19d4 100644
--- a/drivers/input/joystick/as5011.c
+++ b/drivers/input/joystick/as5011.c
@@ -231,6 +231,7 @@ static int __devinit as5011_probe(struct i2c_client *client,
}
if (!i2c_check_functionality(client->adapter,
+ I2C_FUNC_NOSTART |
I2C_FUNC_PROTOCOL_MANGLING)) {
dev_err(&client->dev,
"need i2c bus that supports protocol mangling\n");
diff --git a/drivers/video/matrox/matroxfb_maven.c b/drivers/video/matrox/matroxfb_maven.c
index 31b8f67..217678e 100644
--- a/drivers/video/matrox/matroxfb_maven.c
+++ b/drivers/video/matrox/matroxfb_maven.c
@@ -1243,6 +1243,7 @@ static int maven_probe(struct i2c_client *client,
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_WRITE_WORD_DATA |
I2C_FUNC_SMBUS_BYTE_DATA |
+ I2C_FUNC_NOSTART |
I2C_FUNC_PROTOCOL_MANGLING))
goto ERROR0;
if (!(data = kzalloc(sizeof(*data), GFP_KERNEL))) {
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 195d8b3..85d4ef1 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -540,7 +540,7 @@ struct i2c_msg {
__u16 flags;
#define I2C_M_TEN 0x0010 /* this is a ten bit chip address */
#define I2C_M_RD 0x0001 /* read data, from slave to master */
-#define I2C_M_NOSTART 0x4000 /* if I2C_FUNC_PROTOCOL_MANGLING */
+#define I2C_M_NOSTART 0x4000 /* if I2C_FUNC_NOSTART */
#define I2C_M_REV_DIR_ADDR 0x2000 /* if I2C_FUNC_PROTOCOL_MANGLING */
#define I2C_M_IGNORE_NAK 0x1000 /* if I2C_FUNC_PROTOCOL_MANGLING */
#define I2C_M_NO_RD_ACK 0x0800 /* if I2C_FUNC_PROTOCOL_MANGLING */
@@ -553,8 +553,9 @@ struct i2c_msg {
#define I2C_FUNC_I2C 0x00000001
#define I2C_FUNC_10BIT_ADDR 0x00000002
-#define I2C_FUNC_PROTOCOL_MANGLING 0x00000004 /* I2C_M_NOSTART etc. */
+#define I2C_FUNC_PROTOCOL_MANGLING 0x00000004 /* I2C_M_IGNORE_NAK etc. */
#define I2C_FUNC_SMBUS_PEC 0x00000008
+#define I2C_FUNC_NOSTART 0x00000010 /* I2C_M_NOSTART */
#define I2C_FUNC_SMBUS_BLOCK_PROC_CALL 0x00008000 /* SMBus 2.0 */
#define I2C_FUNC_SMBUS_QUICK 0x00010000
#define I2C_FUNC_SMBUS_READ_BYTE 0x00020000
--
1.7.10
^ permalink raw reply related
* Re: [PATCH] i2c: Split I2C_M_NOSTART support out of I2C_FUNC_PROTOCOL_MANGLING
From: Mark Brown @ 2012-05-04 10:30 UTC (permalink / raw)
To: Jean Delvare
Cc: Florian Tobias Schandinat, Dmitry Torokhov, Wolfram Sang,
linux-i2c, linux-input, linux-fbdev
In-Reply-To: <20120503203617.31179f9b@endymion.delvare>
[-- Attachment #1: Type: text/plain, Size: 736 bytes --]
On Thu, May 03, 2012 at 08:36:17PM +0200, Jean Delvare wrote:
> This is all correct, but it should be documented in
> Documentation/i2c/i2c-protocol. At the moment documentation still says
> that I2C_M_NOSTART is a weird protocol quirk nobody should be using.
> When you update the documentation, I think it is important to stress
> that there are now two use cases of I2C_M_NOSTART. If direction
> changes, it is a rarely needed protocol quirk. If direction doesn't
> change, it is used for buffer gathering.
Hrm, actually rereading the documentation it wasn't all that clear that
these were particularly disrecommended - it just mentioned that the
flags existed and might be needed. I strengthened the documentation
here as well.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] OMAPDSS: OMAPFB: always allow to configure overlay
From: Grazvydas Ignotas @ 2012-05-04 15:16 UTC (permalink / raw)
To: linux-fbdev
Currently when multiple overlays are active, OMAPFB_SETUP_PLANE fails.
Instead of failing, allow it to configure the first overlay as if there
was only one overlay, the remaining ones will have to be configured in
other ways (sysfs).
This allows overlay-controlling programs (like video players) to function
properly when framebuffer is cloned to another display (like TV).
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
---
drivers/video/omap2/omapfb/omapfb-ioctl.c | 36 ++++++++++------------------
1 files changed, 13 insertions(+), 23 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 6a09ef8..58b7f2d 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -70,11 +70,6 @@ static int omapfb_setup_plane(struct fb_info *fbi, struct omapfb_plane_info *pi)
DBG("omapfb_setup_plane\n");
- if (ofbi->num_overlays != 1) {
- r = -EINVAL;
- goto out;
- }
-
/* XXX uses only the first overlay */
ovl = ofbi->overlays[0];
@@ -184,25 +179,20 @@ static int omapfb_setup_plane(struct fb_info *fbi, struct omapfb_plane_info *pi)
static int omapfb_query_plane(struct fb_info *fbi, struct omapfb_plane_info *pi)
{
struct omapfb_info *ofbi = FB2OFB(fbi);
+ struct omap_overlay *ovl;
+ struct omap_overlay_info ovli;
- if (ofbi->num_overlays != 1) {
- memset(pi, 0, sizeof(*pi));
- } else {
- struct omap_overlay *ovl;
- struct omap_overlay_info ovli;
-
- ovl = ofbi->overlays[0];
- ovl->get_overlay_info(ovl, &ovli);
-
- pi->pos_x = ovli.pos_x;
- pi->pos_y = ovli.pos_y;
- pi->enabled = ovl->is_enabled(ovl);
- pi->channel_out = 0; /* xxx */
- pi->mirror = 0;
- pi->mem_idx = get_mem_idx(ofbi);
- pi->out_width = ovli.out_width;
- pi->out_height = ovli.out_height;
- }
+ ovl = ofbi->overlays[0];
+ ovl->get_overlay_info(ovl, &ovli);
+
+ pi->pos_x = ovli.pos_x;
+ pi->pos_y = ovli.pos_y;
+ pi->enabled = ovl->is_enabled(ovl);
+ pi->channel_out = 0; /* xxx */
+ pi->mirror = 0;
+ pi->mem_idx = get_mem_idx(ofbi);
+ pi->out_width = ovli.out_width;
+ pi->out_height = ovli.out_height;
return 0;
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] i2c: Split I2C_M_NOSTART support out of I2C_FUNC_PROTOCOL_MANGLING
From: Wolfram Sang @ 2012-05-04 16:07 UTC (permalink / raw)
To: Jean Delvare
Cc: Mark Brown, Florian Tobias Schandinat, Dmitry Torokhov,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120504103929.644a05ce-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 435 bytes --]
> > Applied to next, thanks! Jean, let me know if you prefer to take it.
> > Acks from input and fbdev maintainers still appreciated.
>
> I'd prefer to take it, yes, as it touches the core infrastructure.
OK, didn't know if you were busy. Dropped it from my tree now.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* RE
From: emilykc @ 2012-05-06 20:45 UTC (permalink / raw)
Your e-mail ID have won £2,500,000.00 GBP
Name:
Country:
Age:
Occupation:
^ permalink raw reply
* [PATCH] video: s3c-fb: use pr_debug instead of printk
From: Jingoo Han @ 2012-05-07 0:20 UTC (permalink / raw)
To: linux-fbdev
This patch uses pr_debug instead of printk to allow dynamic debugging.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c-fb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index ecb82bb..038546a 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -47,7 +47,7 @@
#ifdef CONFIG_FB_S3C_DEBUG_REGWRITE
#undef writel
#define writel(v, r) do { \
- printk(KERN_DEBUG "%s: %08x => %p\n", __func__, (unsigned int)v, r); \
+ pr_debug("%s: %08x => %p\n", __func__, (unsigned int)v, r); \
__raw_writel(v, r); \
} while (0)
#endif /* FB_S3C_DEBUG_REGWRITE */
--
1.7.1
^ permalink raw reply related
* [PATCH] video: EXYNOS: changes mipi dsi regulator name from vdd10 to vdd11
From: Donghwa Lee @ 2012-05-07 0:20 UTC (permalink / raw)
To: linux-arm-kernel
MIPI DSI uses 1.1v regulator, so change its supply name.
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
drivers/video/exynos/exynos_mipi_dsi.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
index 95e33f0..2e779d3 100644
--- a/drivers/video/exynos/exynos_mipi_dsi.c
+++ b/drivers/video/exynos/exynos_mipi_dsi.c
@@ -58,7 +58,7 @@ static struct mipi_dsim_platform_data *to_dsim_plat(struct platform_device
}
static struct regulator_bulk_data supplies[] = {
- { .supply = "vdd10", },
+ { .supply = "vdd11", },
{ .supply = "vdd18", },
};
--
1.7.4.1
^ permalink raw reply related
* [PATCH RESEND 0/9] Enable pinctrl support for mach-mxs
From: Shawn Guo @ 2012-05-07 1:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Arnd Bergmann, Olof Johansson, Shawn Guo, linux-fbdev,
Florian Tobias Schandinat, alsa-devel, Mark Brown, linux-i2c,
Wolfram Sang, linux-mtd, Artem Bityutskiy, linux-mmc, Chris Ball,
linux-serial, Greg Kroah-Hartman
[Resend to have subsystem lists Cc-ed]
With pinctrl-mxs driver (DT only) applied on pinctrl tree, the mxs
device tree conversion can start basing on that support. This series
adopts pinctrl support for mxs device drivers with a dummy pinctrl
state provided for non-DT boot, so that the pinctrl call in the device
drivers will be bypassed for non-DT probe while it starts working for
DT probe.
To ease the merge process, I would like to ask Arnd and Olof to pull
pinctrl tree as a dependency in arm-soc and have this series go through
arm-soc.
Regards,
Shawn
Shawn Guo (9):
ARM: mxs: enable pinctrl dummy states
serial: amba-pl011: adopt pinctrl support
serial: mxs-auart: adopt pinctrl support
mmc: mxs-mmc: adopt pinctrl support
mtd: nand: gpmi: adopt pinctrl support
i2c: mxs: adopt pinctrl support
ASoC: mxs-saif: adopt pinctrl support
video: mxsfb: adopt pinctrl support
ARM: mxs: enable pinctrl support
arch/arm/Kconfig | 1 +
arch/arm/mach-mxs/Kconfig | 2 ++
arch/arm/mach-mxs/include/mach/common.h | 2 ++
arch/arm/mach-mxs/mach-apx4devkit.c | 2 ++
arch/arm/mach-mxs/mach-m28evk.c | 2 ++
arch/arm/mach-mxs/mach-mx23evk.c | 2 ++
arch/arm/mach-mxs/mach-mx28evk.c | 2 ++
arch/arm/mach-mxs/mach-stmp378x_devb.c | 2 ++
arch/arm/mach-mxs/mach-tx28.c | 2 ++
arch/arm/mach-mxs/mm.c | 11 +++++++++++
drivers/i2c/busses/i2c-mxs.c | 6 ++++++
drivers/mmc/host/mxs-mmc.c | 8 ++++++++
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 9 +++++++++
drivers/tty/serial/amba-pl011.c | 8 ++++++++
drivers/tty/serial/mxs-auart.c | 8 ++++++++
drivers/video/mxsfb.c | 9 +++++++++
sound/soc/mxs/mxs-saif.c | 8 ++++++++
17 files changed, 84 insertions(+), 0 deletions(-)
--
1.7.5.4
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox