* [PATCH 5/6] OMAPDSS: Fix DSI_FCLK clock source selection
From: Archit Taneja @ 2012-05-07 11:33 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1336389696-21636-1-git-send-email-archit@ti.com>
The wrong bit field was being updated in DSS_CTRL when trying to configure the
clock source of DSI2 functional clock. Use the correct bit field based on the
dsi module number.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/dss.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index e731aa4..e212acb 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -335,7 +335,7 @@ void dss_select_dsi_clk_source(int dsi_module,
enum omap_dss_clk_source clk_src)
{
struct platform_device *dsidev;
- int b;
+ int b, pos;
switch (clk_src) {
case OMAP_DSS_CLK_SRC_FCK:
@@ -357,7 +357,8 @@ void dss_select_dsi_clk_source(int dsi_module,
BUG();
}
- REG_FLD_MOD(DSS_CONTROL, b, 1, 1); /* DSI_CLK_SWITCH */
+ pos = dsi_module = 0 ? 1 : 10;
+ REG_FLD_MOD(DSS_CONTROL, b, pos, pos); /* DSIx_CLK_SWITCH */
dss.dsi_clk_source[dsi_module] = clk_src;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH 4/6] OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device()
From: Archit Taneja @ 2012-05-07 11:33 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1336389696-21636-1-git-send-email-archit@ti.com>
The functions calc_fclk_five_taps() and check_horiz_timing_omap3() use the
function dispc_mgr_get_device() to get the omap_dss_device pointer to which
the manager is connected, the width of the panel is derived from that.
Replace this by using dss_mgr_get_device() which returns the manager's timing
stored in it's private data in APPLY. This contains the latest timings applied
to the manager. Remove the function dispc_mgr_get_device() as it isn't used
any more.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/dispc.c | 29 +++++++++++++++--------------
1 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index c198cc8..ef131cd 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -413,14 +413,6 @@ static inline bool dispc_mgr_is_lcd(enum omap_channel channel)
return false;
}
-static struct omap_dss_device *dispc_mgr_get_device(enum omap_channel channel)
-{
- struct omap_overlay_manager *mgr - omap_dss_get_overlay_manager(channel);
-
- return mgr ? mgr->device : NULL;
-}
-
u32 dispc_mgr_get_vsync_irq(enum omap_channel channel)
{
switch (channel) {
@@ -1665,14 +1657,17 @@ static int check_horiz_timing_omap3(enum omap_channel channel, u16 pos_x,
u16 width, u16 height, u16 out_width, u16 out_height)
{
int DS = DIV_ROUND_UP(height, out_height);
- struct omap_dss_device *dssdev = dispc_mgr_get_device(channel);
- struct omap_video_timings t = dssdev->panel.timings;
+ struct omap_overlay_manager *mgr;
+ struct omap_video_timings *t;
unsigned long nonactive, lclk, pclk;
static const u8 limits[3] = { 8, 10, 20 };
u64 val, blank;
int i;
- nonactive = t.x_res + t.hfp + t.hsw + t.hbp - out_width;
+ mgr = omap_dss_get_overlay_manager(channel);
+ t = dss_mgr_get_timings(mgr);
+
+ nonactive = t->x_res + t->hfp + t->hsw + t->hbp - out_width;
pclk = dispc_mgr_pclk_rate(channel);
if (dispc_mgr_is_lcd(channel))
lclk = dispc_mgr_lclk_rate(channel);
@@ -1684,7 +1679,7 @@ static int check_horiz_timing_omap3(enum omap_channel channel, u16 pos_x,
i++;
if (out_width < width)
i++;
- blank = div_u64((u64)(t.hbp + t.hsw + t.hfp) * lclk, pclk);
+ blank = div_u64((u64)(t->hbp + t->hsw + t->hfp) * lclk, pclk);
DSSDBG("blanking period + ppl = %llu (limit = %u)\n", blank, limits[i]);
if (blank <= limits[i])
return -EINVAL;
@@ -1725,8 +1720,14 @@ static unsigned long calc_core_clk_five_taps(enum omap_channel channel,
return (unsigned long) pclk;
if (height > out_height) {
- struct omap_dss_device *dssdev = dispc_mgr_get_device(channel);
- unsigned int ppl = dssdev->panel.timings.x_res;
+ struct omap_overlay_manager *mgr;
+ struct omap_video_timings *mgr_timings;
+ unsigned int ppl;
+
+ mgr = omap_dss_get_overlay_manager(channel);
+ mgr_timings = dss_mgr_get_timings(mgr);
+
+ ppl = mgr_timings->x_res;
tmp = pclk * height * out_width;
do_div(tmp, 2 * out_height * ppl);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 3/6] OMAPDSS: DISPC: Remove omap_dss_device pointer usage from dispc_mgr_pclk_rate()
From: Archit Taneja @ 2012-05-07 11:33 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1336389696-21636-1-git-send-email-archit@ti.com>
The pixel clock rate for the TV manager is calculated by checking the device
type connected to the manager, and then requesting the VENC/HDMI interface for
the pixel clock rate.
Remove the use of omap_dss_device pointer from here by checking which interface
generates the pixel clock by reading the DSS_CTRL.VENC_HDMI_SWITCH bit.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/dispc.c | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 49015b8..c198cc8 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2643,13 +2643,14 @@ unsigned long dispc_mgr_pclk_rate(enum omap_channel channel)
return r / pcd;
} else {
- struct omap_dss_device *dssdev - dispc_mgr_get_device(channel);
+ enum dss_hdmi_venc_clk_source_select source;
- switch (dssdev->type) {
- case OMAP_DISPLAY_TYPE_VENC:
+ source = dss_get_hdmi_venc_clk_source();
+
+ switch (source) {
+ case DSS_VENC_TV_CLK:
return venc_get_pixel_clock();
- case OMAP_DISPLAY_TYPE_HDMI:
+ case DSS_HDMI_M_PCLK:
return hdmi_get_pixel_clock();
default:
BUG();
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/6] OMAPDSS: APPLY: Remove an unnecessary omap_dss_device pointer
From: Archit Taneja @ 2012-05-07 11:33 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1336389696-21636-1-git-send-email-archit@ti.com>
The omap_dss_device pointer declared in dss_ovl_setup_fifo() isn't used. Remove
the pointer variable declaration and it's assignment.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/apply.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 052d9a2..756c31a 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -977,14 +977,11 @@ static void dss_ovl_setup_fifo(struct omap_overlay *ovl,
bool use_fifo_merge)
{
struct ovl_priv_data *op = get_ovl_priv(ovl);
- struct omap_dss_device *dssdev;
u32 fifo_low, fifo_high;
if (!op->enabled && !op->enabling)
return;
- dssdev = ovl->manager->device;
-
dispc_ovl_compute_fifo_thresholds(ovl->id, &fifo_low, &fifo_high,
use_fifo_merge);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/6] OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled
From: Archit Taneja @ 2012-05-07 11:33 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1336389696-21636-1-git-send-email-archit@ti.com>
The HDMI and DPI interfaces use their 'set_timing' functions to take in a new
set of timings. If the panel is disabled, they do not disable and re-enable
the interface. Currently, the manager timings are applied in hdmi_power_on()
and dpi_set_mode() respectively, these are not called by set_timings if the
panel is disabled.
When checking overlay and manager data, the DSS driver uses the last applied
manager timings, and not the timings stored in omap_dss_device struct. Hence,
there is a need to apply the new manager timings even if the panel is disabled.
Apply the manager timings if the panel is disabled. Eventually, there should be
one common place where the timings are applied independent of the state of the
panel.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/dpi.c | 2 ++
drivers/video/omap2/dss/hdmi.c | 2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 8127f46..1650050 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -298,6 +298,8 @@ void dpi_set_timings(struct omap_dss_device *dssdev,
dispc_runtime_put();
dss_runtime_put();
+ } else {
+ dss_mgr_set_timings(dssdev->manager, timings);
}
}
EXPORT_SYMBOL(dpi_set_timings);
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 8d4ff8c..32ad712 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -435,6 +435,8 @@ void omapdss_hdmi_display_set_timing(struct omap_dss_device *dssdev)
r = hdmi_power_on(dssdev);
if (r)
DSSERR("failed to power on device\n");
+ } else {
+ dss_mgr_set_timings(dssdev->manager, &dssdev->panel.timings);
}
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH 0/6] OMAPDSS: Misc fixes and cleanups
From: Archit Taneja @ 2012-05-07 11:33 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
The first patch in this series is a follow up on the previously posted series
'OMAPDSS: APPLY: Treat overlay manager timings as shadow registers'. It is
required for HDMI and DPI interfaces to work properly, it ensures manager
timings are applied in the set_timing() ops for these interfaces.
The next 3 patches remove some unnecessary usage of omap_dss_device pointer in
DISPC and APPLY.
The last 2 patches are miscellaneous fixes and are self explanatory.
Reference tree containing this series:
git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git mgr_timing_and_fixes
Tested on OMAP4 SDP.
Archit Taneja (6):
OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled
OMAPDSS: APPLY: Remove an unnecessary omap_dss_device pointer
OMAPDSS: DISPC: Remove omap_dss_device pointer usage from
dispc_mgr_pclk_rate()
OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device()
OMAPDSS: Fix DSI_FCLK clock source selection
OMAPDSS: DISPC: Remove Fake VSYNC support
drivers/video/omap2/dss/Kconfig | 9 ------
drivers/video/omap2/dss/apply.c | 3 --
drivers/video/omap2/dss/dispc.c | 61 +++++++++++++-------------------------
drivers/video/omap2/dss/dpi.c | 2 +
drivers/video/omap2/dss/dsi.c | 4 --
drivers/video/omap2/dss/dss.c | 5 ++-
drivers/video/omap2/dss/dss.h | 1 -
drivers/video/omap2/dss/hdmi.c | 2 +
8 files changed, 28 insertions(+), 59 deletions(-)
--
1.7.5.4
^ permalink raw reply
* fb: BUGs related to deferred IO
From: Sasha Levin @ 2012-05-07 9:42 UTC (permalink / raw)
To: FlorianSchandinat; +Cc: Dave Jones, linux-fbdev, linux-kernel@vger.kernel.org
Hi all,
During fuzzing using trinity inside a KVM guest, using latest -next kernel, I got the following BUG:
[ 601.263570] ------------[ cut here ]------------
[ 601.270562] WARNING: at lib/debugobjects.c:261 debug_print_object+0x8d/0xb0()
[ 601.298273] ODEBUG: assert_init not available (active state 0) object type: timer_list hint: stub_timer+0x0/0x20
[ 601.317051] Pid: 23084, comm: trinity Tainted: G W 3.4.0-rc6-next-20120507-sasha-00001-g33621a3-dirty #114
[ 601.353655] Call Trace:
[ 601.358430] [<ffffffff810b6ca7>] warn_slowpath_common+0x87/0xb0
[ 601.369400] [<ffffffff810b6d71>] warn_slowpath_fmt+0x41/0x50
[ 601.376112] [<ffffffff8189dafd>] debug_print_object+0x8d/0xb0
[ 601.382656] [<ffffffff810c5650>] ? usleep_range+0x40/0x40
[ 601.389210] [<ffffffff8189dcf0>] debug_object_assert_init+0xa0/0x110
[ 601.395856] [<ffffffff810c5e26>] del_timer+0x26/0xd0
[ 601.399472] [<ffffffff810d3c87>] __cancel_work_timer+0x27/0xa0
[ 601.403238] [<ffffffff810d3d0d>] cancel_delayed_work_sync+0xd/0x10
[ 601.406969] [<ffffffff819170d2>] fb_deferred_io_fsync+0x52/0x80
[ 601.410281] [<ffffffff811e1ff8>] ? fget_light+0x118/0x3e0
[ 601.413489] [<ffffffff8120cb48>] vfs_fsync_range+0x18/0x30
[ 601.416741] [<ffffffff8120cb77>] vfs_fsync+0x17/0x20
[ 601.419662] [<ffffffff8120cd74>] do_fsync+0x34/0x60
[ 601.422959] [<ffffffff8120cdae>] sys_fdatasync+0xe/0x20
[ 601.425721] [<ffffffff82d8b1f9>] system_call_fastpath+0x16/0x1b
[ 601.449718] ---[ end trace 44593438a59a9537 ]---
[ 601.452359] ------------[ cut here ]------------
[ 601.453315] kernel BUG at kernel/workqueue.c:564!
[ 601.453315] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 601.453315] CPU 1
[ 601.453315] Pid: 23084, comm: trinity Tainted: G W 3.4.0-rc6-next-20120507-sasha-00001-g33621a3-dirty #114
[ 601.453315] RIP: 0010:[<ffffffff810d1621>] [<ffffffff810d1621>] get_work_gcwq+0x41/0x80
[ 601.453315] RSP: 0018:ffff88000ed3fe58 EFLAGS: 00010213
[ 601.453315] RAX: 0000000000000000 RBX: ffff88007f310e58 RCX: 0000000000000006
[ 601.453315] RDX: 0035b5b5b5b5b5b5 RSI: ffff88000f9088e0 RDI: ffff88007f310e58
[ 602.339668] RBP: ffff88000ed3fe58 R08: 0000000000000001 R09: 0000000000000000
[ 602.339668] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88007f310e58
[ 602.339668] R13: 09286401f3b0af98 R14: 13b8db52e413d33a R15: 02be775f01f67918
[ 602.339668] FS: 00007f65d4b65700(0000) GS:ffff88001b800000(0000) knlGS:0000000000000000
[ 602.339668] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 602.339668] CR2: 0000000000f54800 CR3: 0000000016530000 CR4: 00000000000407e0
[ 602.339668] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 602.339668] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 602.339668] Process trinity (pid: 23084, threadinfo ffff88000ed3e000, task ffff88000f908000)
[ 602.339668] Stack:
[ 602.339668] ffff88000ed3fe98 ffffffff810d23db 2222222222222222 2222222222222222
[ 602.339668] 2222222222222222 ffff88007f310e58 ffff88007f310ea8 09286401f3b0af98
[ 602.339668] ffff88000ed3fec8 ffffffff810d3ce0 13b8db52e413d33a ffff88001aeccb98
[ 602.339668] Call Trace:
[ 602.339668] [<ffffffff810d23db>] try_to_grab_pending+0x2b/0xe0
[ 602.339668] [<ffffffff810d3ce0>] __cancel_work_timer+0x80/0xa0
[ 602.339668] [<ffffffff810d3d0d>] cancel_delayed_work_sync+0xd/0x10
[ 602.339668] [<ffffffff819170d2>] fb_deferred_io_fsync+0x52/0x80
[ 602.339668] [<ffffffff811e1ff8>] ? fget_light+0x118/0x3e0
[ 602.339668] [<ffffffff8120cb48>] vfs_fsync_range+0x18/0x30
[ 602.339668] [<ffffffff8120cb77>] vfs_fsync+0x17/0x20
[ 602.339668] [<ffffffff8120cd74>] do_fsync+0x34/0x60
[ 602.339668] [<ffffffff8120cdae>] sys_fdatasync+0xe/0x20
[ 602.339668] [<ffffffff82d8b1f9>] system_call_fastpath+0x16/0x1b
[ 602.339668] Code: 66 2e 0f 1f 84 00 00 00 00 00 48 89 c2 31 c0 48 c1 ea 09 81 fa 01 10 00 00 74 3f 81 fa 00 10 00 00 74 27 39 15 89 ca f1 02 77 09 <0f> 0b 0f 1f 44 00 00 eb fe 48 c7 c0 80 f4 00 00 89 d2 48 03 04
[ 602.339668] RIP [<ffffffff810d1621>] get_work_gcwq+0x41/0x80
[ 602.339668] RSP <ffff88000ed3fe58>
[ 602.674604] ---[ end trace 44593438a59a9538 ]---
It would seem that this is the case of trying to use deferred IO on FBs that don't support it. I had a cirrus fbdev in the guest, which from what I can tell doesn't support deferred IO.
The first and the 2nd bug lead me to believe that 'fbdefio' was set to garbage.
^ permalink raw reply
* Re: [alsa-devel] [PATCH RESEND 0/9] Enable pinctrl support for mach-mxs
From: Dong Aisheng @ 2012-05-07 7:56 UTC (permalink / raw)
To: Shawn Guo
Cc: Dong Aisheng-B29396, linux-arm-kernel@lists.infradead.org,
linux-fbdev@vger.kernel.org, Chris Ball, Arnd Bergmann,
Florian Tobias Schandinat, Artem Bityutskiy, Mark Brown,
linux-mmc@vger.kernel.org, alsa-devel@alsa-project.org,
Wolfram Sang, linux-mtd@lists.infradead.org,
linux-i2c@vger.kernel.org, linux-serial@vger.kernel.org,
Greg Kroah-Hartman, Olof Johansson
In-Reply-To: <20120507074658.GH19389@S2101-09.ap.freescale.net>
On Mon, May 07, 2012 at 03:47:00PM +0800, Shawn Guo wrote:
> On Mon, May 07, 2012 at 03:14:00PM +0800, Dong Aisheng wrote:
> > As IMX, basically i'd prefer to add pinctrl states in dts file at the
> > same time within the patch or using a separate patch to add them before
> > this series to avoid breaking the exist platforms.
> >
> > However i noted that for mxs, most drivers here are still not dt capable,
> > so it may be ok to not add their pinctrl state at this time.
> >
> There no mxs driver on mainline that has been DT aware of. What I'm
> going to do is to ask Arnd abandon the mxs/dt branch I sent him before
> and send him an updated one with the whole mxs DT support based on
> mxs common clk and pinctrl series.
>
> > But for the patch "serial: amba-pl011: adopt pinctrl support" since it is
> > dt capable, so with this patch applied, the mx28 dt boot will fail.
> > Maybe we should at least add pinctrl states for amba-pl011 first.
> >
> The updated mxs/dt will have pinctrl defined in dts for each device
> that is converted to DT.
>
Well, i did not see amba-pl011 pinctrl states defined in this patch.
But it would be ok if you can get it done and applied before this patch.
> > > Shawn Guo (9):
> > > ARM: mxs: enable pinctrl dummy states
> > > serial: amba-pl011: adopt pinctrl support
> > BTW, will this one break other platforms using this driver?
> >
> If the platforms do not turn on CONFIG_PINCTRL, they are fine. If they
> turn on the support, they should provide pinctrl state either dummy or
> real one.
>
Regards
Dong Aisheng
^ permalink raw reply
* Re: [alsa-devel] [PATCH RESEND 0/9] Enable pinctrl support for mach-mxs
From: Shawn Guo @ 2012-05-07 7:47 UTC (permalink / raw)
To: Dong Aisheng
Cc: linux-arm-kernel, linux-fbdev, Chris Ball, Arnd Bergmann,
Florian Tobias Schandinat, Artem Bityutskiy, Mark Brown,
linux-mmc, alsa-devel, Wolfram Sang, linux-mtd, linux-i2c,
linux-serial, Greg Kroah-Hartman, Olof Johansson
In-Reply-To: <20120507071400.GB23607@shlinux2.ap.freescale.net>
On Mon, May 07, 2012 at 03:14:00PM +0800, Dong Aisheng wrote:
> As IMX, basically i'd prefer to add pinctrl states in dts file at the
> same time within the patch or using a separate patch to add them before
> this series to avoid breaking the exist platforms.
>
> However i noted that for mxs, most drivers here are still not dt capable,
> so it may be ok to not add their pinctrl state at this time.
>
There no mxs driver on mainline that has been DT aware of. What I'm
going to do is to ask Arnd abandon the mxs/dt branch I sent him before
and send him an updated one with the whole mxs DT support based on
mxs common clk and pinctrl series.
> But for the patch "serial: amba-pl011: adopt pinctrl support" since it is
> dt capable, so with this patch applied, the mx28 dt boot will fail.
> Maybe we should at least add pinctrl states for amba-pl011 first.
>
The updated mxs/dt will have pinctrl defined in dts for each device
that is converted to DT.
> > Shawn Guo (9):
> > ARM: mxs: enable pinctrl dummy states
> > serial: amba-pl011: adopt pinctrl support
> BTW, will this one break other platforms using this driver?
>
If the platforms do not turn on CONFIG_PINCTRL, they are fine. If they
turn on the support, they should provide pinctrl state either dummy or
real one.
--
Regards,
Shawn
^ permalink raw reply
* Re: [alsa-devel] [PATCH RESEND 0/9] Enable pinctrl support for mach-mxs
From: Dong Aisheng @ 2012-05-07 7:14 UTC (permalink / raw)
To: Shawn Guo
Cc: linux-arm-kernel, linux-fbdev, Chris Ball, Arnd Bergmann,
Florian Tobias Schandinat, Artem Bityutskiy, Mark Brown,
linux-mmc, alsa-devel, Wolfram Sang, linux-mtd, linux-i2c,
linux-serial, Greg Kroah-Hartman, Olof Johansson
In-Reply-To: <1336353374-28939-1-git-send-email-shawn.guo@linaro.org>
On Mon, May 07, 2012 at 09:16:05AM +0800, Shawn Guo wrote:
> [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.
>
As IMX, basically i'd prefer to add pinctrl states in dts file at the
same time within the patch or using a separate patch to add them before
this series to avoid breaking the exist platforms.
However i noted that for mxs, most drivers here are still not dt capable,
so it may be ok to not add their pinctrl state at this time.
But for the patch "serial: amba-pl011: adopt pinctrl support" since it is
dt capable, so with this patch applied, the mx28 dt boot will fail.
Maybe we should at least add pinctrl states for amba-pl011 first.
> Regards,
> Shawn
>
> Shawn Guo (9):
> ARM: mxs: enable pinctrl dummy states
> serial: amba-pl011: adopt pinctrl support
BTW, will this one break other platforms using this driver?
> 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
>
Regards
Dong Aisheng
^ permalink raw reply
* [PATCH RESEND 8/9] video: mxsfb: adopt pinctrl support
From: Shawn Guo @ 2012-05-07 1:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1336353374-28939-1-git-send-email-shawn.guo@linaro.org>
Cc: linux-fbdev@vger.kernel.org
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
drivers/video/mxsfb.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 4a89f88..6c6bc57 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -45,6 +45,7 @@
#include <linux/clk.h>
#include <linux/dma-mapping.h>
#include <linux/io.h>
+#include <linux/pinctrl/consumer.h>
#include <mach/mxsfb.h>
#define REG_SET 4
@@ -756,6 +757,7 @@ static int __devinit mxsfb_probe(struct platform_device *pdev)
struct mxsfb_info *host;
struct fb_info *fb_info;
struct fb_modelist *modelist;
+ struct pinctrl *pinctrl;
int i, ret;
if (!pdata) {
@@ -793,6 +795,12 @@ static int __devinit mxsfb_probe(struct platform_device *pdev)
host->devdata = &mxsfb_devdata[pdev->id_entry->driver_data];
+ pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+ if (IS_ERR(pinctrl)) {
+ ret = PTR_ERR(pinctrl);
+ goto error_getpin;
+ }
+
host->clk = clk_get(&host->pdev->dev, NULL);
if (IS_ERR(host->clk)) {
ret = PTR_ERR(host->clk);
@@ -848,6 +856,7 @@ error_init_fb:
error_pseudo_pallette:
clk_put(host->clk);
error_getclock:
+error_getpin:
iounmap(host->base);
error_ioremap:
framebuffer_release(fb_info);
--
1.7.5.4
^ 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
* [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] 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
* 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
* 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
* [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: 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] 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 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
* 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] 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 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 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: 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
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