Re: [PATCH] drm/omap: update for interlaced
Hi Rob,
On Thu, Sep 6, 2012 at 3:18 AM, Rob Clark rob.cl...@linaro.org wrote:
From: Rob Clark r...@ti.com
'struct omap_video_timings' was updated w/ a 'bool interlaced'. Without
a matching update in omap_connector, this field could have undefined
values from the stack, which isn't quite ideal.
Update the fxns to convert omapdss-drm timings structs, and zero-init
'struct omap_video_timings' when it is declared on stack to avoid issues
like this in the future.
Signed-off-by: Rob Clark r...@ti.com
Feel free to use
Reviewed-by: Sumit Semwal sumit.sem...@ti.com
---
drivers/staging/omapdrm/omap_connector.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_connector.c
b/drivers/staging/omapdrm/omap_connector.c
index 5e2856c..5f4a89b 100644
--- a/drivers/staging/omapdrm/omap_connector.c
+++ b/drivers/staging/omapdrm/omap_connector.c
@@ -48,13 +48,10 @@ static inline void copy_timings_omap_to_drm(struct
drm_display_mode *mode,
mode-vsync_end = mode-vsync_start + timings-vsw;
mode-vtotal = mode-vsync_end + timings-vbp;
- /* note: whether or not it is interlaced, +/- h/vsync, etc,
-* which should be set in the mode flags, is not exposed in
-* the omap_video_timings struct.. but hdmi driver tracks
-* those separately so all we have to have to set the mode
-* is the way to recover these timings values, and the
-* omap_dss_driver would do the rest.
-*/
+ mode-flags = 0;
+
+ if (timings-interlace)
+ mode-flags |= DRM_MODE_FLAG_INTERLACE;
}
static inline void copy_timings_drm_to_omap(struct omap_video_timings
*timings,
@@ -71,6 +68,8 @@ static inline void copy_timings_drm_to_omap(struct
omap_video_timings *timings,
timings-vfp = mode-vsync_start - mode-vdisplay;
timings-vsw = mode-vsync_end - mode-vsync_start;
timings-vbp = mode-vtotal - mode-vsync_end;
+
+ timings-interlace = !!(mode-flags DRM_MODE_FLAG_INTERLACE);
}
static void omap_connector_dpms(struct drm_connector *connector, int mode)
@@ -187,7 +186,7 @@ static int omap_connector_get_modes(struct drm_connector
*connector)
}
} else {
struct drm_display_mode *mode = drm_mode_create(dev);
- struct omap_video_timings timings;
+ struct omap_video_timings timings = {0};
dssdrv-get_timings(dssdev, timings);
@@ -291,7 +290,7 @@ void omap_connector_mode_set(struct drm_connector
*connector,
struct omap_connector *omap_connector = to_omap_connector(connector);
struct omap_dss_device *dssdev = omap_connector-dssdev;
struct omap_dss_driver *dssdrv = dssdev-driver;
- struct omap_video_timings timings;
+ struct omap_video_timings timings = {0};
copy_timings_drm_to_omap(timings, mode);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: omapdrm: Fix DMM sparse warnings
On Thu, Aug 9, 2012 at 10:26 PM, Rob Clark rob.cl...@linaro.org wrote:
On Thu, Aug 9, 2012 at 12:14 AM, Andy Gross andy.gr...@ti.com wrote:
Fix the following sparse warnings:
drivers/staging/omapdrm/omap_dmm_tiler.c:123:13:
warning: symbol 'omap_dmm_irq_handler' was not declared.
Should it be static?
drivers/staging/omapdrm/omap_dmm_tiler.c:370:24:
warning: Using plain integer as NULL pointer
Signed-off-by: Andy Gross andy.gr...@ti.com
Signed-off-by: Rob Clark rob.cl...@linaro.org
Reviewed-by: Sumit Semwal sumit.sem...@ti.com
---
drivers/staging/omapdrm/omap_dmm_tiler.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c
b/drivers/staging/omapdrm/omap_dmm_tiler.c
index 8619783..ec7a5c8 100644
--- a/drivers/staging/omapdrm/omap_dmm_tiler.c
+++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
@@ -120,7 +120,7 @@ static int wait_status(struct refill_engine *engine,
uint32_t wait_mask)
return 0;
}
-irqreturn_t omap_dmm_irq_handler(int irq, void *arg)
+static irqreturn_t omap_dmm_irq_handler(int irq, void *arg)
{
struct dmm *dmm = arg;
uint32_t status = readl(dmm-base + DMM_PAT_IRQSTATUS);
@@ -367,7 +367,7 @@ struct tiler_block *tiler_reserve_1d(size_t size)
int num_pages = (size + PAGE_SIZE - 1) PAGE_SHIFT;
if (!block)
- return 0;
+ return ERR_PTR(-ENOMEM);
block-fmt = TILFMT_PAGE;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/3] solving omapdrm/omapdss layering issues
Hi Rob, Tomi, On Thu, Aug 2, 2012 at 7:46 PM, Rob Clark rob.cl...@linaro.org wrote: On Thu, Aug 2, 2012 at 8:15 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Thu, 2012-08-02 at 07:45 -0500, Rob Clark wrote: On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote: On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: I guess the fact is that DRM concepts do not really match the OMAP DSS hardware, and we'll have to use whatever gives us least problems. Actually, I think it does map fairly well to the hardware.. at least more so than to omapdss ;-) Hm, I'm not sure I understand, omapdss concepts map directly to the hardware. I think it is mainly exposing the encoder and panel as two separate entities.. which seems to be what Archit is working on I still don't follow =) They are separate entities. Omapdss models the HW quite directly, I think. It doesn't expose everything, though, as the output drivers (dsi.c, dpi.c etc) are used via the panel drivers. right.. so we just need to expose the output drivers as separate entities, and let omapdrm propagate information such as timings between them in case of something like DVI bridge from DPI, this seems pretty straightforward.. only the connector needs to know about DDC stuff, which i2c to use and that sort of thing. So at kms level we would have (for example) an omap_dpi_encoder which would be the same for DPI panel (connector) or DPI-DVI bridge. For HDMI I'm still looking through the code to see how this would work. Honestly I've looked less at this part of code and encoder related registers in the TRM, compared to the ovl/mgr parts, but at least from the 'DSS overview' picture in the TRM it seems to make sense ;-) KMS even exposes the idea that certain crtcs can connect to only certain encoders. Or that you could you could have certain connectors switched between encoders. For example if you had a hw w/ DPI out, and some mux to switch that back and forth between a DPI lcd panel and a DPI-DVI bridge. (Ok, I'm not aware of any board that actually does this, but it is in theory possible.) So we could expose possible video chain topologies to userspace in this way. OMAP3 SDP board has such a setup, with manual switch to select between LCD and DVI. ahh, good to know.. so I'm not crazy for wanting to expose this possibility to userspace The other thing is that we don't need to propagate timings from the panel up to the mgr at the dss level.. kms is already handling this for us. In my latest version, which I haven't pushed, I removed the 'struct omap_overlay_mgr' ptr from 'struct omap_dss_device'. You're thinking only about simple DPI cases. Consider this example, with a DSI-to-DP bridge chip. What we have is the following flow of data: DISPC - DSI - DSI-2-DP - DP monitor The timings you are thinking about are in the DISPC, but here they are only one part of the link. And here the DISPC timings are not actually the timings what the user is interested about. The user wants his timings to be between DSI-2-DP chip and the DP monitor. Timings programmed to DISPC are not the same. The timings for DISPC come from the DSI driver, and they may be very different than the user's timings. With DSI video mode, the DISPC timings would have some resemblance to the user's timings, mainly the time to send one line would be the same. With DSI cmd mode, the DISPC timings would be something totally different, most likely with 0 blank times and as fast pixel clock as possible. hmm, well kms already has a concept of adjusted_timings, which could perhaps be used here to propagate the timings between crtc-encoder.. although the order is probably backwards from what we want (it comes from the crtc to the encoder.. and if I understand properly we want it the other way and actually possibly from the connector). But that isn't to say that internally in omapdrm the crtc couldn't get the adjusted timings from the connector. So I still think the parameter flow doesn't need to be 'under the hood' in omapdss. And fwiw, the adjusted_timings stuff is handled by drm_crtc_helper fxns, so if the way the core kms handles it isn't what we want, we can just plug in our own fxn instead of using drm_crtc_helper_set_mode(), so that isn't really a big problem. What omapdss does currently is that you set the user's timings to the right side of the chain, which propagate back to DSS. This allows the DSI-2-DP bridge use DSI timings that work optimally for the bridge, and DSI driver will use DISPC timings that work optimally for it. And it's not only about timings above, but also other settings related to the busses between the components. Clock dividers, polarities, stuff like that. I expect we could handle other settings in the same way as the timings. I think the problem was there were some
Re: [PATCH] staging: drm/omap: remove reclaim_buffers callback
On Wed, Aug 1, 2012 at 3:02 PM, Chandrabhanu Mahapatra
cmahapa...@ti.com wrote:
The reclaim_buffers callback has already been removed by Daniel Vetter
daniel.vet...@ffwll.ch with his patch drm: kill reclaim_buffers callback
for which the kernel compilation fails with omapdrm support. So, the callback
for reclaim_buffers is removed from omapdrm.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
Reviewed-by: Sumit Semwal sumit.sem...@ti.com
---
drivers/staging/omapdrm/omap_drv.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/omapdrm/omap_drv.c
b/drivers/staging/omapdrm/omap_drv.c
index 342645a..b8e79eb 100644
--- a/drivers/staging/omapdrm/omap_drv.c
+++ b/drivers/staging/omapdrm/omap_drv.c
@@ -778,7 +778,6 @@ static struct drm_driver omap_drm_driver = {
.irq_postinstall = dev_irq_postinstall,
.irq_uninstall = dev_irq_uninstall,
.irq_handler = dev_irq_handler,
- .reclaim_buffers = drm_core_reclaim_buffers,
#ifdef CONFIG_DEBUG_FS
.debugfs_init = omap_debugfs_init,
.debugfs_cleanup = omap_debugfs_cleanup,
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap_vout: Set DSS overlay_info only if paddr is non zero
On Mon, Mar 19, 2012 at 5:16 PM, Archit Taneja a0393...@ti.com wrote:
On Monday 19 March 2012 02:15 PM, Hiremath, Vaibhav wrote:
On Fri, Mar 16, 2012 at 16:41:27, Taneja, Archit wrote:
Hi,
On Friday 16 March 2012 03:46 PM, Archit Taneja wrote:
On Monday 12 March 2012 03:34 PM, Hiremath, Vaibhav wrote:
On Wed, Mar 07, 2012 at 14:31:16, Taneja, Archit wrote:
The omap_vout driver tries to set the DSS overlay_info using
set_overlay_info()
when the physical address for the overlay is still not configured.
This happens
in omap_vout_probe() and vidioc_s_fmt_vid_out().
The calls to omapvid_init(which internally calls set_overlay_info())
are removed
from these functions. They don't need to be called as the
omap_vout_device
struct anyway maintains the overlay related changes made. Also,
remove the
explicit call to set_overlay_info() in vidioc_streamon(), this was
used to set
the paddr, this isn't needed as omapvid_init() does the same thing
later.
These changes are required as the DSS2 driver since 3.3 kernel
doesn't let you
set the overlay info with paddr as 0.
Signed-off-by: Archit Tanejaarc...@ti.com
---
drivers/media/video/omap/omap_vout.c | 36
-
1 files changed, 5 insertions(+), 31 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 1fb7d5b..dffcf66 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -1157,13 +1157,6 @@ static int vidioc_s_fmt_vid_out(struct file
*file, void *fh,
/* set default crop and win */
omap_vout_new_format(vout-pix,vout-fbuf,vout-crop,vout-win);
- /* Save the changes in the overlay strcuture */
- ret = omapvid_init(vout, 0);
- if (ret) {
- v4l2_err(vout-vid_dev-v4l2_dev, failed to change mode\n);
- goto s_fmt_vid_out_exit;
- }
-
ret = 0;
s_fmt_vid_out_exit:
@@ -1664,20 +1657,6 @@ static int vidioc_streamon(struct file *file,
void *fh, enum v4l2_buf_type i)
omap_dispc_register_isr(omap_vout_isr, vout, mask);
- for (j = 0; j ovid-num_overlays; j++) {
- struct omap_overlay *ovl = ovid-overlays[j];
-
- if (ovl-manager ovl-manager-device) {
- struct omap_overlay_info info;
- ovl-get_overlay_info(ovl,info);
- info.paddr = addr;
- if (ovl-set_overlay_info(ovl,info)) {
- ret = -EINVAL;
- goto streamon_err1;
- }
- }
- }
-
Have you checked for build warnings? I am getting build warnings
CC drivers/media/video/omap/omap_vout.o
CC drivers/media/video/omap/omap_voutlib.o
CC drivers/media/video/omap/omap_vout_vrfb.o
drivers/media/video/omap/omap_vout.c: In function 'vidioc_streamon':
drivers/media/video/omap/omap_vout.c:1619:25: warning: unused variable
'ovid'
drivers/media/video/omap/omap_vout.c:1615:15: warning: unused variable
'j'
LD drivers/media/video/omap/omap-vout.o
LD drivers/media/video/omap/built-in.o
Can you fix this and submit the next version?
I applied the patch on the current mainline kernel, it doesn't give any
build warnings. Even after applying the patch, 'j and ovid' are still
used in vidioc_streamon().
Can you check if it was applied correctly?
Archit,
I could able to trace what's going on here,
I am using v4l_for_linus branch, which has one missing patch,
commit aaa874a985158383c4b394c687c716ef26288741
Author: Tomi Valkeinentomi.valkei...@ti.com
Date: Tue Nov 15 16:37:53 2011 +0200
OMAPDSS: APPLY: rewrite overlay enable/disable
So, I do not have below changes,
@@ -1686,6 +1681,16 @@ static int vidioc_streamon(struct file *file, void
*fh, enum v4l2_buf_type i)
if (ret)
v4l2_err(vout-vid_dev-v4l2_dev, failed to change
mode\n);
+ for (j = 0; j ovid-num_overlays; j++) {
+ struct omap_overlay *ovl = ovid-overlays[j];
+
+ if (ovl-manager ovl-manager-device) {
+ ret = ovl-enable(ovl);
+ if (ret)
+ goto streamon_err1;
+ }
+ }
+
This explains why I am seeing these warnings. Let me give pull request
based on master branch.
Okay. Thanks for looking into this.
Archit
Hi Vaibhav,
This patch has been outstanding since March, and we have received
reports from various users. Could you please push it ASAP to Mauro for
the upcoming -rc?
Or Did I miss a pull request from you containing this?
Thanks and best regards,
~Sumit.
Thanks,
Vaibhav
Regards,
Archit
Will fix this and submit.
Archit
Thanks,
Vaibhav
/* First save the configuration in ovelray structure */
ret = omapvid_init(vout, addr);
if (ret)
@@ -2071,11 +2050,12 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
}
video_set_drvdata(vfd, vout);
- /* Configure the overlay structure */
- ret = omapvid_init(vid_dev-vouts[k], 0);
- if (!ret)
- goto success;
+ dev_info(pdev-dev, : registered and initialized
+ video device %d\n, vfd-minor);
+ if (k
Re: [PATCH v4 2/5] OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr
On Wed, Sep 28, 2011 at 8:19 PM, Archit Taneja arc...@ti.com wrote: Currently, there is a lot of redundant code is between DPI and VENC panels, this can be made common by moving out field/interlace specific code to a separate function called omapvid_handle_interlace_display(). There is no functional change made. Signed-off-by: Archit Taneja arc...@ti.com Reviewed-by: Sumit Semwal sumit.sem...@ti.com snip -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/5] OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr
On Wed, Sep 28, 2011 at 8:19 PM, Archit Taneja arc...@ti.com wrote: Currently, in omap_vout_isr(), if the panel type is DPI, and if we get either VSYNC or VSYNC2 interrupts, we proceed ahead to set the current buffers state to VIDEOBUF_DONE and prepare to display the next frame in the queue. On OMAP4, because we have 2 LCD managers, the panel type itself is not sufficient to tell if we have received the correct irq, i.e, we shouldn't proceed ahead if we get a VSYNC interrupt for LCD2 manager, or a VSYNC2 interrupt for LCD manager. Fix this by correlating LCD manager to VSYNC interrupt and LCD2 manager to VSYNC2 interrupt. Signed-off-by: Archit Taneja arc...@ti.com Reviewed-by: Sumit Semwal sumit.sem...@ti.com snip -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr
Hi Vaibhav, On Tue, Sep 27, 2011 at 12:09 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: -Original Message- From: Semwal, Sumit Sent: Tuesday, September 27, 2011 11:12 AM To: Hiremath, Vaibhav Cc: Taneja, Archit; Valkeinen, Tomi; linux-omap@vger.kernel.org; linux- me...@vger.kernel.org Subject: Re: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr Hi Vaibhav, snip Archit, I think I am still not understood or convinced with your description above, The code snippet which we are referring here, does check whether the interrupt is either VSYNC or VSYNC2, else fall back to vout_isr_err. I am not quite sure I understand what is the confusing part here - below is my understanding; please correct me if you think otherwise. As I understand, this patch creates a (missing) correlation between a manager and the corresponding ISR. The earlier code would accept a VSYNC2 for LCD1 manager, which is not the correct thing to do. That is why the check of 'if ((mgr==LCD) (IRQ==VSYNC))' kind of thing is needed; Which part of this do you think the above patch doesn't do? Or, do you think it is not needed / done correctly? Sumit, Please look at the patch carefully, it does exactly same thing. I understand the use-case what Archit explained in the last email but in this patch context, the use-case change anything here in this patch. Can you review it carefully again? Thanks - I did review it carefully (the first time, and again), and maybe it is something that you're able to see which I can't. Could you please explain why you think (1) if (!(irqstatus (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2))) goto vout_isr_err; is *exactly* the same as (2) if (!((mgr==LCD) (irqstatus DISPC_IRQ_VSYNC)) || (mgr==LCD2) (irqstatus DISPC_IRQ_VSYNC2)) ) goto vout_isr_err; [which I understand is what Archit's patch does] I am not able to see any correlation in (1) between mgr and irq, whereas it is quite clear in (2). Let me know if I missed something? Best regards, ~Sumit. Thanks, Vaibhav snip -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr
Hi Vaibhav, On Mon, Sep 26, 2011 at 3:49 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: -Original Message- From: Taneja, Archit Sent: Thursday, September 22, 2011 11:46 AM To: Hiremath, Vaibhav Cc: Valkeinen, Tomi; linux-omap@vger.kernel.org; Semwal, Sumit; linux- me...@vger.kernel.org Subject: Re: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr Hi, snip - if (!(irqstatus (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2))) + if (mgr_id == OMAP_DSS_CHANNEL_LCD) + irq = DISPC_IRQ_VSYNC; + else if (mgr_id == OMAP_DSS_CHANNEL_LCD2) + irq = DISPC_IRQ_VSYNC2; + else + goto vout_isr_err; + + if (!(irqstatus irq)) goto vout_isr_err; break; I understand what this patch meant for, but I am more curious to know What is value addition of this patch? if (!(irqstatus (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2))) Vs if (mgr_id == OMAP_DSS_CHANNEL_LCD) irq = DISPC_IRQ_VSYNC; else if (mgr_id == OMAP_DSS_CHANNEL_LCD2) irq = DISPC_IRQ_VSYNC2; Isn't this same, because we are not doing anything separate and special for VSYNC and VSYNC2? Consider a use case where the primary LCD panel(connected to LCD manager) is configured at a 60 Hz refresh rate, and the secondary panel(connected to LCD2) refreshes at 30 Hz. Let the overlay configuration be something like this: /dev/video1-overlay1-LCD manager-Primary panel(60 Hz) /dev/video2-overlay2-LCD2 manager-Secondary Panel(30 Hz) Now if we are doing streaming on both video1 and video2, since we deque on either VSYNC or VSYNC2, video2 buffers will deque faster than the panels refresh, which is incorrect. So for video2, we should only deque when we get a VSYNC2 interrupt. Thats why there is a need to correlate the interrupt and the overlay manager. Archit, I think I am still not understood or convinced with your description above, The code snippet which we are referring here, does check whether the interrupt is either VSYNC or VSYNC2, else fall back to vout_isr_err. I am not quite sure I understand what is the confusing part here - below is my understanding; please correct me if you think otherwise. As I understand, this patch creates a (missing) correlation between a manager and the corresponding ISR. The earlier code would accept a VSYNC2 for LCD1 manager, which is not the correct thing to do. That is why the check of 'if ((mgr==LCD) (IRQ==VSYNC))' kind of thing is needed; Which part of this do you think the above patch doesn't do? Or, do you think it is not needed / done correctly? For me both are doing same thing, the original code is optimized way of implementation. Can you please review it again? Thanks, Vaibhav Thanks and best regards, ~Sumit. snip -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 09/10] OMAP4: DSS2: HDMI: Function pointer approach to call
On Fri, Sep 2, 2011 at 4:17 PM, mythr...@ti.com wrote: From: Mythri P K mythr...@ti.com snip + hdmi.hdmi_data.ops-video_enable(hdmi.hdmi_data, 0); Still too much of 'hdmi' in this line - maybe you can just replace hdmi_data w/ data (like you did for hdmi_ops w/ ops)? snip -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] OMAP4: DSS2: VIDEO3 pipeline support
On Fri, Aug 5, 2011 at 8:42 AM, Archit Taneja arc...@ti.com wrote: Add support for VIDEO3 pipeline on OMAP4: - Add VIDEO3 pipeline information in dss_features and omapdss.h - Add VIDEO3 pipeline register coefficients in dispc.h - Create a new overlay structure corresponding to VIDEO3. Signed-off-by: Archit Taneja arc...@ti.com --- snip - u32 fifo_size[3]; + u32 fifo_size[MAX_DSS_OVERLAYS]; Do you think it makes some sense in splitting the 'generalisation' like this that you've done in the patch from the xxx_VIDEO3 changes? It might make it look a little cleaner; otherwise the changes look good to me; feel free to add my reviewed-by. [and to other patches in this series]. snip -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 05/18] OMAP2,3 DSS2 Change driver name to omap_display
Hi, On Mon, Feb 28, 2011 at 12:57 PM, archit taneja arc...@ti.com wrote: Hi, On Monday 28 February 2011 12:49 PM, Valkeinen, Tomi wrote: On Mon, 2011-02-28 at 01:09 -0600, Taneja, Archit wrote: Hi, On Monday 28 February 2011 12:23 PM, Valkeinen, Tomi wrote: snip I just realized that changing the driver name will break all scripts and applications using omapdss sysfs files. How does this sound: Let's leave the omapdss device name as it is. It represents a super device, containing the dss sysfs files and upper level dss management. Name the HW module platform drivers as: omapdss_dss, omapdss_venc, omapdss_dispc, etc. This would indicate them to be clearly parts of DSS, and would also prevent any possible name conflict if there would happen to be a, say, dsi block in some other HW component. Any comments on this? I also think we need to stick to the older name, omapdss_dss sounds a bit confusing, and I think one of the previous versions had something like dss_dss in it and it wasn't approved. Does something like omapdss_core or omapdss_dss_core make sense, or is it more misleading? It is confusing, but so is the hardware naming =). There is a DSS module inside the omap display subsystem. That's why I would like to name it dss, not core, so it's clear it refers to this DSS module. dss_dss looks a bit silly, but I think omapdss_dss is slightly better in the sense that it doesn't repeat the same dss, and there is an omapdss device, which acts like manager for these module devices. But yes, I wouldn't call it perfect either. omapdss_dss_core is one option. But then again, TRM doesn't speak of core. Yes, it might get misleading if someone looking at the code tries to find core in the TRM, I guess we should stick to omapdss_dss, this also ensures a uniform matching of the platform driver names and the beginning of register names for each HW module. Hmmm... I guess omapdss_dss seems a better name in this view; I'm ok with this way of naming - do you want me to send a patch for it, or would you update this patch itself? ~Sumit. Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 1/2] OMAP2PLUS: DSS2: Add dss_opt_clk_roles in pdata
Hi Tomi,
On Mon, Feb 28, 2011 at 2:40 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
snip
+ oc = oh-opt_clks;
+ oc_count = oh-opt_clks_cnt;
+
+ /* copy roles of opt_clocks available from hwmod into pdata */
+ pdata.dss_opt_clk_roles = kzalloc(sizeof(char *) * oc_count,
+ GFP_KERNEL);
+ if (!pdata.dss_opt_clk_roles) {
+ pr_err(could not allocate memory for dss_opt_clk_roles\n);
+ return -ENOMEM;
+ }
+
+ for (i = 0; i oc_count; i++) {
+ int oc_length = strlen(oc[i].role);
+
+ pdata.dss_opt_clk_roles[i] = kzalloc(oc_length + 1,
+ GFP_KERNEL);
+ if (!pdata.dss_opt_clk_roles[i]) {
+ int j = i - 1;
+
+ pr_err(kzalloc failed for dss_opt_clk[%i]\n, i);
+ for (; j = 0; j--)
+ kfree(pdata.dss_opt_clk_roles[j]);
+
+ kfree(pdata.dss_opt_clk_roles);
+
+ return -ENOMEM;
+ }
+
+ strncpy(pdata.dss_opt_clk_roles[i], oc[i].role, oc_length+1);
+ }
Do you actually need to copy the role strings? Can they every change? If
they are const data, you could just point to the original strings.
Right; no, I don't think they can change, so I could point to the
original strings.
And is there even need to create clk_roles array. If I'm not mistaken,
the only use for this data is for the opt_clock_available() function. We
could just have an opt_clock_available() function pointer in the
omap_display_platform_data, and the function itself would be in
display.c. And the function could use the original hwmod data.
Ok, but in that case, we do the same hwmod lookup everytime, is it?
That may not be so bad though, considering we check that very rarely
[in dsshw_probe=dss_get_clocks() path].
Ok, will do and send the updated one soon.
~Sumit.
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v2 0/2] OMAP2PLUS:DSS2: use opt-clocks information from hwmod.
Minor correction: On Mon, Feb 28, 2011 at 8:32 PM, Sumit Semwal sumit.sem...@ti.com wrote: snip Based on top of: http://gitorious.org/linux-omap-dss2/linux/commits/master commit: ad1c76c: OMAP: Overo Palo43 LCD support The correct base is: http://gitorious.org/linux-omap-dss2/linux/commits/for-next commit: 799a626: MAINTAINERS: Update OMAP DSS maintainer Please let me know if you want me to rebase on top of master. BR, ~S. snip -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v2 1/2] OMAP2PLUS:DSS2: add opt_clock_available in pdata
On Mon, Feb 28, 2011 at 9:33 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2011-02-28 at 09:02 -0600, Semwal, Sumit wrote:
Provide a function in pdata to allow dss submodules to check if a given
clock is available on a platform as an optional clock.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
(based on implementation from Senthil)
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
arch/arm/mach-omap2/display.c | 20
arch/arm/plat-omap/include/plat/display.h | 2 ++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 5ab6a74..9f4f862 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -42,6 +42,25 @@ static struct omap_device_pm_latency omap_dss_latency[] =
{
},
};
+static bool opt_clock_available(const char *clk_role)
+{
+ int i;
+ struct omap_hwmod *oh;
+
+ /* opt_clks are always associated with dss hwmod */
+ oh = omap_hwmod_lookup(dss_core);
+ if (!oh) {
+ pr_err(Could not look up dss_core.\n);
+ return -ENODEV;
The function returns a bool. Perhaps the lookup would be better done in
omap_display_init(), and stored in a static variable.
Yes; I guess I should go with your earlier suggestion - of keeping
this 'oh' as part of pdata, and then use it here.
Or if it's clear that this should never happen, BUG_ON(!oh);
Well, multiple people have 'frowned' upon using BUG_ON in dss -
especially because some people might still want their kernel to keep
working despite a display failure?
~Sumit.
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v2 1/2] OMAP2PLUS:DSS2: add opt_clock_available in pdata
On Tue, Mar 1, 2011 at 11:49 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2011-02-28 at 23:42 -0600, Semwal, Sumit wrote:
On Mon, Feb 28, 2011 at 9:33 PM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Mon, 2011-02-28 at 09:02 -0600, Semwal, Sumit wrote:
Provide a function in pdata to allow dss submodules to check if a given
clock is available on a platform as an optional clock.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
(based on implementation from Senthil)
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
arch/arm/mach-omap2/display.c | 20
arch/arm/plat-omap/include/plat/display.h | 2 ++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 5ab6a74..9f4f862 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -42,6 +42,25 @@ static struct omap_device_pm_latency
omap_dss_latency[] = {
},
};
+static bool opt_clock_available(const char *clk_role)
+{
+ int i;
+ struct omap_hwmod *oh;
+
+ /* opt_clks are always associated with dss hwmod */
+ oh = omap_hwmod_lookup(dss_core);
+ if (!oh) {
+ pr_err(Could not look up dss_core.\n);
+ return -ENODEV;
The function returns a bool. Perhaps the lookup would be better done in
omap_display_init(), and stored in a static variable.
Yes; I guess I should go with your earlier suggestion - of keeping
this 'oh' as part of pdata, and then use it here.
I don't think it needs to be part of pdata. It's internal to this file,
and if I'm not mistaken, omap_display_init() is called just once from
the current board file. Thus the data could as well be stored in a
static variable.
:) ok, that's correct; though we might need to make 'oh' part of pdata
based on our adaptation to the reset functionality - but that will
come later.
Or if it's clear that this should never happen, BUG_ON(!oh);
Well, multiple people have 'frowned' upon using BUG_ON in dss -
especially because some people might still want their kernel to keep
working despite a display failure?
Yes, BUG is an easy, not good, way out =).
:) hmmm... should I just return 'false' and print out a warning?
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v2 1/2] OMAP2PLUS:DSS2: add opt_clock_available in pdata
On Tue, Mar 1, 2011 at 12:07 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2011-03-01 at 00:27 -0600, Semwal, Sumit wrote:
On Tue, Mar 1, 2011 at 11:49 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Mon, 2011-02-28 at 23:42 -0600, Semwal, Sumit wrote:
On Mon, Feb 28, 2011 at 9:33 PM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Mon, 2011-02-28 at 09:02 -0600, Semwal, Sumit wrote:
Provide a function in pdata to allow dss submodules to check if a given
clock is available on a platform as an optional clock.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
(based on implementation from Senthil)
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
arch/arm/mach-omap2/display.c | 20
arch/arm/plat-omap/include/plat/display.h | 2 ++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c
b/arch/arm/mach-omap2/display.c
index 5ab6a74..9f4f862 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -42,6 +42,25 @@ static struct omap_device_pm_latency
omap_dss_latency[] = {
},
};
+static bool opt_clock_available(const char *clk_role)
+{
+ int i;
+ struct omap_hwmod *oh;
+
+ /* opt_clks are always associated with dss hwmod */
+ oh = omap_hwmod_lookup(dss_core);
+ if (!oh) {
+ pr_err(Could not look up dss_core.\n);
+ return -ENODEV;
The function returns a bool. Perhaps the lookup would be better done in
omap_display_init(), and stored in a static variable.
Yes; I guess I should go with your earlier suggestion - of keeping
this 'oh' as part of pdata, and then use it here.
I don't think it needs to be part of pdata. It's internal to this file,
and if I'm not mistaken, omap_display_init() is called just once from
the current board file. Thus the data could as well be stored in a
static variable.
:) ok, that's correct; though we might need to make 'oh' part of pdata
based on our adaptation to the reset functionality - but that will
come later.
Or if it's clear that this should never happen, BUG_ON(!oh);
Well, multiple people have 'frowned' upon using BUG_ON in dss -
especially because some people might still want their kernel to keep
working despite a display failure?
Yes, BUG is an easy, not good, way out =).
:) hmmm... should I just return 'false' and print out a warning?
From opt_clock_available() if the hwmod was not found? Well, preferably
opt_clock_available() will never be called, if the hwmod is not found in
omap_display_init(). So omap_display_init() should fail - DSS driver
refuses to start - opt_clock_available() is never called.
:) Yes, that's true. will leave out the check then.
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omapfb: no driver for display
Hi, On Sat, Feb 19, 2011 at 6:10 PM, Ming Lei tom.leim...@gmail.com wrote: Hi, 2011/2/19 archit taneja arc...@ti.com: Hi, Which board are you on? For all the display devices you add in the board file, you should have the corresponding drivers in the menuconfig set also. Pandaboard. DVI support for pandaboard is slated to be in for 2.6.39. There are around 6-7 patch series which enable it. You could look at the top patches at: git://dev.omapzoom.org/pub/scm/anand/linux-omap-usb.git, branch: display-patches-for-v2.6.38-rc4. Best regards, ~Sumit. For example, in board3430-sdp.c, we add a sharp ls, a dvi and venc panel. We therefore select sharpls and generic dpi panel in menuconfig. and at least DPI and VENC in the interfaces menu. I also selected all the options above. thanks, -- Lei Ming -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] OMAP4: hwmod data: Add DSS, DISPC, DSI12, RFBI, HDMI and VENC
Hi Benoit, One minor comment; On Thu, Feb 17, 2011 at 3:54 PM, Benoit Cousson b-cous...@ti.com wrote: Add dss, dispc, dsi1, dsi2, hdmi, rfbi and venc hwmods. In OMAP4 there are severals IPs that can be reached by differents interconnect paths depending of the access initiator (MPU vs. SDMA). In the case of the DSS, both L3 direct path and L4 CFG path can be used to access all the DSS IPs. The two ocp_ip already exists to support the two address spaces. ++-- L3_MAIN --+ MPU IP | | +-- L4_CFG --+ L3 main address range is specified first, since it is used by default. dss is also considered as an IP as dispc, rfbi, and named as dss_core. Signed-off-by: Benoit Cousson b-cous...@ti.com Signed-off-by: Mayuresh Janorkar ma...@ti.com Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com Signed-off-by: Sumit Semwal sumit.sem...@ti.com [b-cous...@ti.com: Re-organize structures to match file convention and remove irq entry from dss_hwmod] --- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 612 +++- 1 files changed, 604 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c index 37b3024..aafe60d 100644 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c @@ -1,7 +1,7 @@ /* * Hardware modules present on the OMAP44xx chips * - * Copyright (C) 2009-2010 Texas Instruments, Inc. + * Copyright (C) 2009-2011 Texas Instruments, Inc. * Copyright (C) 2009-2010 Nokia Corporation * * Paul Walmsley @@ -43,6 +43,7 @@ static struct omap_hwmod omap44xx_dma_system_hwmod; static struct omap_hwmod omap44xx_dmm_hwmod; static struct omap_hwmod omap44xx_dsp_hwmod; +static struct omap_hwmod omap44xx_dss_hwmod; I guess we agreed to name this dss_core - any specific reason to change it? Best regards, ~Sumit. snip -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] OMAP4: hwmod data: Add DSS, DISPC, DSI12, RFBI, HDMI and VENC
On Thu, Feb 17, 2011 at 8:32 PM, Semwal, Sumit sumit.sem...@ti.com wrote: Hi Benoit, One minor comment; On Thu, Feb 17, 2011 at 3:54 PM, Benoit Cousson b-cous...@ti.com wrote: Add dss, dispc, dsi1, dsi2, hdmi, rfbi and venc hwmods. In OMAP4 there are severals IPs that can be reached by differents interconnect paths depending of the access initiator (MPU vs. SDMA). In the case of the DSS, both L3 direct path and L4 CFG path can be used to access all the DSS IPs. The two ocp_ip already exists to support the two address spaces. ++-- L3_MAIN --+ MPU IP | | +-- L4_CFG --+ L3 main address range is specified first, since it is used by default. dss is also considered as an IP as dispc, rfbi, and named as dss_core. Signed-off-by: Benoit Cousson b-cous...@ti.com Signed-off-by: Mayuresh Janorkar ma...@ti.com Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com Signed-off-by: Sumit Semwal sumit.sem...@ti.com [b-cous...@ti.com: Re-organize structures to match file convention and remove irq entry from dss_hwmod] --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c @@ -1,7 +1,7 @@ /* * Hardware modules present on the OMAP44xx chips * - * Copyright (C) 2009-2010 Texas Instruments, Inc. + * Copyright (C) 2009-2011 Texas Instruments, Inc. * Copyright (C) 2009-2010 Nokia Corporation * * Paul Walmsley @@ -43,6 +43,7 @@ static struct omap_hwmod omap44xx_dma_system_hwmod; static struct omap_hwmod omap44xx_dmm_hwmod; static struct omap_hwmod omap44xx_dsp_hwmod; +static struct omap_hwmod omap44xx_dss_hwmod; I guess we agreed to name this dss_core - any specific reason to change it? Oh well, blame it on weary eyes - I do see that you've named the device correctly as 'dss_core', so please ignore this comment! Best regards, ~Sumit. Best regards, ~Sumit. snip -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP: DSS2: Common IRQ handler for all OMAPs
Hi Benoit,
On Tue, Feb 15, 2011 at 3:53 PM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Archit,
On 2/15/2011 10:25 AM, Taneja, Archit wrote:
Copying Benoit,
On Tuesday 15 February 2011 02:07 PM, Valkeinen, Tomi wrote:
On Tue, 2011-02-15 at 02:30 -0600, Taneja, Archit wrote:
Hi,
On Tuesday 15 February 2011 12:57 PM, Valkeinen, Tomi wrote:
snip
I meant something like this:
dispc.c:
dispc_init()
{
/* did we have a pdev for dispc? if not, this needs to be
dss.pdev */
request_irq(platform_get_irq(dispc.pdev, 0), irq_handler,
IRQF_SHARED, dispc irq, foo);
}
irq_handler()
{
if (irq_can_be_shared) {
check if the irq is for us. exit if not;
}
handle;
}
dsi.c:
dsi_init()
{
request_irq(platform_get_irq(dsi.pdev, 0), irq_handler,
IRQF_SHARED, dsi irq, foo);
}
irq_handler()
{
if (irq_can_be_shared) {
check if the irq is for us. exit if not;
}
handle;
}
This approach looks clean, but isn't IRQF_SHARED used the other way
around. One irq line and multiple handlers?
That is the case here, isn't it (on omap3)? One interrupt line (the DSS
irq, the same returned both from dsi.pdev and dispc.pdev), and two
handlers, one in dispc and one in dsi? Or what do you mean?
On omap2 there's no dsi code ran, so dispc is the only one requesting
the irq, and thus IRQF_SHARED is extra. In omap4 there are separate irq
lines (dsi.pdev and dispc.pdev return different irqs), and so
IRQF_SHARED is again extra. But I don't see any harm in IRQF_SHARED even
in omap2/4.
Tomi
Benoit,
Is it okay to have the same irq entry for 2 different hwmods?
This requirement comes from OMAP3 where dispc and dsi have a common irq
line, where as on OMAP4 dispc and dsi have separate irq lines.
Well, no. I explained that in one of my comment about hwmod modification.
The hwmod data are reflecting the exact HW capabilities.
So, if there is a change in the HW, the hwmod will be different.
It is up to the driver to adapt to this change.
I guess what Archit wanted to say is, for hw IPs DISPC and DSI, on
OMAP3, have a common IRQ line, so could both their hwmod databases
have the same IRQ added for them? This would us call, for a common IRQ
line shared w/ DISPC and DSI, like
mentioned in Tomi's sample code above.
How is hwmod data for these cases handled today? [shared IRQ,
different platform devices?]
Best regards,
~Sumit.
The driver has to evolve to handle properly the new HW capabilities while
keeping the old stuff working.
We basically want to get rid of a central dss irq handler (hence, remove
irq entries for dss_core hwmod) and instead have separate irq handlers
for each module which may or may not share an irq line.
Then you need to hack your driver but not the hwmod data:-(
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v3,1/3] OMAP2PLUS: DSS2: Add OMAP4 Kconfig support
Hi Tomi, Sent an updated one; apologies for double posting, as I posted the first one with your earlier email Id. Best regards, ~Sumit. On Fri, Feb 11, 2011 at 5:36 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi, On Thu, 2011-01-27 at 11:17 +, Sumit Semwal wrote: From: Mayuresh Janorkar ma...@ti.com Enable DSS2 and OMAPFB for OMAP4 in Kconfig The indentation in this patch seems to be a bit inconsistent with the current Kconfigs. For example, you use two tabs in the help lines, and the current files use either one tab and 2 spaces, or 10 spaces. Please stick to the current indentation, or change the indentation for the whole file in a separate patch. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 18/18] OMAP2,3: DSS2: Get DSS IRQ from platform device
Hi,
On Mon, Feb 14, 2011 at 7:39 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hi,
On Mon, 2011-01-24 at 11:52 +0530, ext Sumit Semwal wrote:
From: Senthilvadivu Guruswamy svad...@ti.com
DSS IRQ number can be obtained from platform_get_irq(). This API in turn
picks the right IRQ number belonging to HW IP from the hwmod database.
So hardcoding of IRQ number could be removed.
Reviewed-by: Paul Walmsley p...@pwsan.com
Reviewed-by: Kevin Hilman khil...@ti.com
Tested-by: Kevin Hilman khil...@ti.com
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
drivers/video/omap2/dss/dss.c | 21 ++---
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 4d7a816..f9390b4 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -563,7 +563,7 @@ void dss_set_dac_pwrdn_bgz(bool enable)
static int dss_init(bool skip_init)
{
- int r;
+ int r, dss_irq;
u32 rev;
struct resource *dss_mem;
@@ -609,11 +609,18 @@ static int dss_init(bool skip_init)
REG_FLD_MOD(DSS_CONTROL, 0, 2, 2); /* venc clock mode = normal */
#endif
- r = request_irq(INT_24XX_DSS_IRQ,
- cpu_is_omap24xx()
- ? dss_irq_handler_omap2
- : dss_irq_handler_omap3,
- 0, OMAP DSS, NULL);
+ dss_irq = platform_get_irq(dss.pdev, 0);
+ if (dss_irq 0) {
+ DSSERR(omap2 dss: platform_get_irq failed\n);
+ r = -ENODEV;
+ goto fail1;
+ }
+
+ r = request_irq(dss_irq,
+ cpu_is_omap24xx()
+ ? dss_irq_handler_omap2
+ : dss_irq_handler_omap3,
+ 0, OMAP DSS, NULL);
if (r 0) {
DSSERR(omap2 dss: request_irq failed\n);
@@ -641,7 +648,7 @@ static int dss_init(bool skip_init)
return 0;
fail2:
- free_irq(INT_24XX_DSS_IRQ, NULL);
+ free_irq(dss_irq, NULL);
You change this free_irq, as you should, but you missed another a few
lines later.
Archit fixes it in his OMAP: DSS2: Common IRQ handler for all OMAPs
patch silently, but I think it should be fixed here already, as the
patches haven't been pulled to anywhere yet.
Perhaps you could use the same method as Archit used, create a new field
irq in the dss struct which can be used in the dss_exit's free_irq
call.
Yes, you're right; I guess since it was already in your tree by the
time we noticed this oversight, we assumed Archit could submit a new
one. I can send you an updated one tomorrow for this.
Regards,
~Sumit.
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] OMAP4: hwmod data: add DSS DISPC DSI1,2 RFBI HDMI VENC
Hi Benoit,
On Fri, Feb 11, 2011 at 10:20 PM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Sumit,
While I was trying to merge that patch for 2.6.39, I found some changes that
I didn't expected. I will take care of cleaning this patch, but I'd to get
the rational first.
All the other comments are purely cosmetic.
On 1/27/2011 12:17 PM, Semwal, Sumit wrote:
From: Benoit Coussonb-cous...@ti.com
Add dss, dispc, dsi1, dsi2, hdmi, rfbi and venc hwmods.
In OMAP4 there are severals IPs that can be reached by differents
interconnect paths depending of the access initiator (MPU vs. SDMA).
In the case of the DSS, both L3 direct path and L4 CFG path can be
used to access all the DSS IPs. The two ocp_ip already exists to support
the two address spaces.
++-- L3_MAIN --+ MPU
IP | |
+-- L4_CFG --+
L3 main address range is specified first, since it is used by default.
dss is also considered as an IP as dispc, rfbi, and named as dss_core.
Signed-off-by: Benoit Coussonb-cous...@ti.com
Signed-off-by: Mayuresh Janorkarma...@ti.com
Signed-off-by: Senthilvadivu Guruswamysvad...@ti.com
Signed-off-by: Sumit Semwalsumit.sem...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 603
1 files changed, 603 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index c2806bd..0bd579e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -43,6 +43,13 @@
static struct omap_hwmod omap44xx_dma_system_hwmod;
static struct omap_hwmod omap44xx_dmm_hwmod;
static struct omap_hwmod omap44xx_dsp_hwmod;
+static struct omap_hwmod omap44xx_dss_core_hwmod;
+static struct omap_hwmod omap44xx_dss_dispc_hwmod;
+static struct omap_hwmod omap44xx_dss_dsi1_hwmod;
+static struct omap_hwmod omap44xx_dss_dsi2_hwmod;
+static struct omap_hwmod omap44xx_dss_hdmi_hwmod;
+static struct omap_hwmod omap44xx_dss_rfbi_hwmod;
+static struct omap_hwmod omap44xx_dss_venc_hwmod;
static struct omap_hwmod omap44xx_emif_fw_hwmod;
static struct omap_hwmod omap44xx_iva_hwmod;
static struct omap_hwmod omap44xx_l3_instr_hwmod;
@@ -237,12 +244,21 @@ static struct omap_hwmod_ocp_if
omap44xx_mpu__l3_main_1 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* dss - l3_main_1 */
+static struct omap_hwmod_ocp_if omap44xx_dss__l3_main_1 = {
+ .master =omap44xx_dss_core_hwmod,
+ .slave =omap44xx_l3_main_1_hwmod,
+ .clk = l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l3_main_1 slave ports */
static struct omap_hwmod_ocp_if *omap44xx_l3_main_1_slaves[] = {
omap44xx_dsp__l3_main_1,
omap44xx_l3_main_2__l3_main_1,
omap44xx_l4_cfg__l3_main_1,
omap44xx_mpu__l3_main_1,
+omap44xx_dss__l3_main_1,
};
static struct omap_hwmod omap44xx_l3_main_1_hwmod = {
@@ -746,6 +762,584 @@ static struct omap_hwmod omap44xx_dsp_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/* DSS related classes */
That line should not be removed.
+ /*
+ * 'dispc' class
+ * display controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_dispc_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_MIDLEMODE |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields =omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_dispc_hwmod_class = {
+ .name = dispc,
+ .sysc =omap44xx_dispc_sysc,
+};
+
+/* dss_dispc */
+static struct omap_hwmod_irq_info omap44xx_dss_dispc_irqs[] = {
+ { .irq = 25 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_dma_info omap44xx_dss_dispc_sdma_reqs[] = {
+ { .dma_req = 5 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_dss_dispc_addrs[] = {
+ {
+ .pa_start = 0x48041000,
+ .pa_end = 0x48041fff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_per - dss_dispc */
+static struct omap_hwmod_ocp_if omap44xx_l4_per__dss_dispc = {
+ .master =omap44xx_l4_per_hwmod,
+ .slave =omap44xx_dss_dispc_hwmod,
+ .clk = l4_div_ck,
+ .addr = omap44xx_dss_dispc_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_dss_dispc_addrs),
+ .user = OCP_USER_MPU,
+};
+
+static struct
Re: [PATCH v10 18/18] OMAP2, 3: DSS2: Get DSS IRQ from platform device
Raghuveer, On Thu, Jan 27, 2011 at 6:34 PM, Raghuveer Murthy x0075...@ti.com wrote: On Thursday 27 January 2011 06:29 PM, Russell King - ARM Linux wrote: On Thu, Jan 27, 2011 at 06:19:21PM +0530, Raghuveer Murthy wrote: + r = request_irq(dss_irq, + cpu_is_omap24xx() + ? dss_irq_handler_omap2 + : dss_irq_handler_omap3, it should be cpu_is_omap24xx() ? dss_irq_handler_omap3 : dss_irq_handler_omap2, I am seeing a crash on Panda, which gets rectified with this change. The root cause is access to DSS_IRQSTATUS register in the dss_irq_handler_omap3 handler, which is not valid for OMAP4. That really doesn't look right. Let me translate the code you've just written: if (cpu_is_omap24xx()) handler = dss_irq_handler_omap3; else handler = dss_irq_handler_omap2; Which means: if we have an OMAP24xx device, use the OMAP3 handler, otherwise use the OMAP2 handler. That's got to be wrong. I agree, that the logic seems counter-intuitive. I was doing a quick test. However, to keep the correct sequence, the logic inside the respective handlers need to be looked at. If you see the patch series, this is relevant only for OMAP2,3. OMAP4 related IRQ handling is not yet introduced. There would a different patch set which should set the correct irq handler for OMAP4. Regards, Raghuveer -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] OMAP4: DSS2: clocks: Add ick as dummy clock
On Thu, Jan 27, 2011 at 11:16 PM, Kevin Hilman khil...@ti.com wrote:
Sumit Semwal sumit.sem...@ti.com writes:
DSS code uses ick as one of the clocks in clk_get/clk_put. OMAP4 clock
database
doesn't have ick for DSS, so adding ick as dummy clock.
Once pm_runtime* APIs get introduced in DSS, this will be revisited.
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 74db324..8603b1f 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3109,6 +3109,8 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, dsp_fck, dsp_fck,
CK_443X),
/* dss clocks */
CLK(NULL, fck, dss_fck,
CK_443X),
+ CLK(omap_dss, ick, dummy_ck,
CK_443X),
+ /* on OMAP4, ick is a dummy clock */
minor nit: the comment should go above the code, and should also state
it's needed for OMAP2/3 compatibility.
Sure, thanks! Will update in next version.
~Sumit.
Kevin
/*
* clocks handled via hwmod opt_clk mechanism need dev=NULL,
* con=clock name as per actual clk structure, NOT role
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V2] OMAP3EVM: Made backlight GPIO default state to off
Vaibhav,
On Tue, Jan 25, 2011 at 12:52 AM, Vaibhav Hiremath hvaib...@ti.com wrote:
If you choose default output to DVI, the LCD backlight used to
stay on, since panel-disable function never gets called.
So, during init put backlight GPIO to off state and the driver
code will decide which output to enable.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
Changes from V1 -
- Added check for return value
arch/arm/mach-omap2/board-omap3evm.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 7119380..a888a7d 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -411,6 +411,8 @@ static struct platform_device leds_gpio = {
static int omap3evm_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
+ int r;
+
/* gpio + 0 is mmc0_cd (input/IRQ) */
omap_mux_init_gpio(63, OMAP_PIN_INPUT);
mmc[0].gpio_cd = gpio + 0;
@@ -426,8 +428,17 @@ static int omap3evm_twl_gpio_setup(struct device *dev,
*/
/* TWL4030_GPIO_MAX + 0 == ledA, LCD Backlight control */
- gpio_request(gpio + TWL4030_GPIO_MAX, EN_LCD_BKL);
- gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
+ r = gpio_request(gpio + TWL4030_GPIO_MAX, EN_LCD_BKL);
+ if (r)
+ printk(KERN_ERR failed to get lcd_bkl gpio\n);
So even if the gpio_request fails, this code prints an error and continues?
+
+ if (get_omap3_evm_rev() = OMAP3EVM_BOARD_GEN_2)
+ r = gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1);
+ else
+ r = gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
+
+ if (r)
+ printk(KERN_ERR failed to set direction of lcd_bkl gpio\n);
/* gpio + 7 == DVI Enable */
gpio_request(gpio + 7, EN_DVI);
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 18/18] OMAP2,3: DSS2: Get DSS IRQ from platform device
On Sun, Jan 23, 2011 at 6:22 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Sun, Jan 23, 2011 at 03:39:23PM +0300, Sergei Shtylyov wrote:
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 4d7a816..22690e9 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
[...]
@@ -609,15 +609,18 @@ static int dss_init(bool skip_init)
REG_FLD_MOD(DSS_CONTROL, 0, 2, 2); /* venc clock mode = normal */
#endif
- r = request_irq(INT_24XX_DSS_IRQ,
+ dss_irq = platform_get_irq(dss.pdev, 0);
+ if (dss_irq != -ENXIO) {
Better just 'dss_irq 0', IMHO.
If a function returns negative error codes, the correct test is
ret 0
not
ret = 0
The fact that it happens to be dealing with IRQ numbers where IRQ0
may not be valid is neither here nor there.
Thanks Sergei, Russell,
I will update this to check for (ret 0) as the error case, and re-submit.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 00/18] OMAP2,3: hwmod DSS Adaptation
Hi Kevin, On Fri, Jan 21, 2011 at 10:36 AM, Kevin Hilman khil...@ti.com wrote: Hi Sumit, Sumit Semwal sumit.sem...@ti.com writes: [...] Testing: - The patches are tested on 2420-n800, 2430sdp, 3630zoom, 3430sdp. Complete bootup with penguins on panel is done on 3430sdp. For the rest of the mentioned platforms, kernel is built with OMAP2_DSS and bootup is tested so that base address and clk_get calls are successful. I think this series needs more validation on the other platforms. Getting a visible framebuffer w/tux on all tested platforms seems like a minimal requirement. I gave a test of this on 3530/Beagle with CONFIG_PANEL_GENERIC_DPI=y and driving a DVI monitor, using the following kernel cmdline # cat /proc/cmdline console=ttyO2,115200n8 mpurate=600 vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait Without your series, I see penguin logo and get a console login on the screen with this boot log (from dmesg |grep -i omapfb): [ 2.651885] OMAPFB: omapfb_init [ 2.652160] OMAPFB: omapfb_probe [ 2.657653] OMAPFB: create 3 framebuffers [ 2.657714] OMAPFB: fb_infos allocated [ 2.657714] OMAPFB: allocating 1572864 bytes for fb 0 [ 2.668212] OMAPFB: allocated VRAM paddr 8f40, vaddr d0a0 [ 2.668243] OMAPFB: region0 phys 8f40 virt d0a0 size=1572864 [ 2.668243] OMAPFB: region1 phys virt (null) size=0 [ 2.668273] OMAPFB: region2 phys virt (null) size=0 [ 2.668273] OMAPFB: fbmems allocated [ 2.668518] OMAPFB: check_fb_var 0 [ 2.668548] OMAPFB: max frame size 1572864, line size 2048 [ 2.668548] OMAPFB: xres = 1024, yres = 768, vxres = 1024, vyres = 768 [ 2.668579] OMAPFB: set_fb_fix [ 2.669036] OMAPFB: fb_infos initialized [ 2.673522] OMAPFB: set_par(0) [ 2.673614] OMAPFB: set_fb_fix [ 2.673614] OMAPFB: apply_changes, fb 0, ovl 0 [ 2.673645] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 1024, outh 768 [ 2.673645] OMAPFB: paddr 8f40, vaddr d0a0 [ 2.674346] OMAPFB: pan_display(0) [ 2.674346] OMAPFB: setcmap [ 2.674377] OMAPFB: setcmap [ 2.683746] OMAPFB: pan_display(0) [ 2.683776] OMAPFB: setcmap [ 2.692108] OMAPFB: setcmap [ 2.701599] OMAPFB: framebuffers registered [ 2.701629] OMAPFB: apply_changes, fb 0, ovl 0 [ 2.701660] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 1024, outh 768 [ 2.701690] OMAPFB: paddr 8f40, vaddr d0a0 [ 2.701721] OMAPFB: apply_changes, fb 1, ovl 1 [ 2.701751] OMAPFB: apply_changes, fb 2, ovl 2 [ 2.701751] OMAPFB: create_framebuffers done [ 2.702331] OMAPFB: mgr-apply'ed [ 2.704803] OMAPFB: create sysfs for fbs [ 2.704833] OMAPFB: create sysfs for fbs With your series applied (no other changes), I don't see anything on the screen because omapfb_probe() fails: [ 2.519653] OMAPFB: omapfb_init [ 2.519958] OMAPFB: omapfb_probe [ 2.520019] omapfb omapfb: no driver for display [ 2.525115] OMAPFB: free_resources [ 2.525146] OMAPFB: free all fbmem [ 2.525177] omapfb omapfb: failed to setup omapfb which indicates that omap_dss_get_device() is failing in omapfb_probe(). Thanks for testing this out - yes, you're right. I was able to reproduce this here, after getting hold of a beagle from someone, and found out the reason. The patch series misses some updates of device names [they were done for 3430sdp, but left out for other platforms somehow in the version of patches I got from the original authors.] I am updating this now, and will send out an updated patchset in some time. Unfortunately, the platforms available to me right now for testing were rather limited, so I would truly appreciate testing on other platforms not mentioned in the mail. Best regards, ~Sumit. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 00/18] OMAP2,3: hwmod DSS Adaptation
Hi Kevin, On Fri, Jan 21, 2011 at 10:05 PM, Kevin Hilman khil...@ti.com wrote: Sumit Semwal sumit.sem...@ti.com writes: v8 of the DSS hwmod patch series fixes some issues based on findings of Kevin Hilman on beagle. Thanks. I re-tested on beagle and it looks good. I also briefly tested on beagle with PM. I tested suspend/resume to verify we could still hit full-chip retention. I also verified idle with and without screen blanked. As expected, with the screen (external DVI monitor) active, the DSS power domain did not hit retentiond during idle, but allowing the screen to blank, DSS powerdomain then hits idle. Feel free to add: Reviewed-by: Kevin Hilman khil...@ti.com Tested-by: Kevin Hilman khil...@ti.com Also, can you repost one more time with the linux-arm-ker...@lists.infradead.org Cc'd? Thanks. Thanks very much for helping out with the testing! I will post an updated one w/ your reviewed-by and tested-by in a bit. Best regards, ~Sumit. Kevin The VENC platform driver was not getting registered due to missed device name update for vdda_dac regulator in some board files. This was moved from 'omap_display' device to 'omap_venc' device in patch 14/18. Also, similarly for DSI platform driver, the regulator name 'vdds_dsi' needs two instances - one for dpi, and one for dsi. This version corrects the above two for all board files where 'vdda_dac' and 'vdds_dsi' regulators are defined. [patches 14/18 and 15/18] Post this change, boot w/ visible framebuffer and tux was successfully validated on beagle, 3430SDP and zoom3. A patch mentioned in http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42384.html was needed to get OMAP3 to boot up on top of linux-next of 20110115. OMAP4 hwmod support will be posted after the acceptance of this basic change in the dss2 design. - [original patch introduction] This patch series decouples the Clocks for DSS in hwmod adaptation changes from this series. Another series would be posted which could be discussed w.r.t clocks in DSS across omap2,3. Removing the SYSCONFIG settings from DSS driver would also be part of these clock changes series and not covered in this series as it depends on some of the omap_hwmod framework changes w.r.t opt clocks handling. Summary of the hwmod DSS design: DSS, DISPC, DSI, RFBI, VENC are made as platform drivers each corresponding to the hwmod class in the hwmod database. Each of these platform drivers' init / deinit are handled from core.c's omap_dss_probe() in the exact sequence as required. No Hardcoding of silicon data: hwmod database abstracts the SOC data like base addr, irq numbers and are implemented in this patch series. Continue to have custom bus for display panels: omap_display driver continues to be a platform driver that registers the custom bus. It also continues to register the display panels(omap_dss_device) on the board to the panel drivers (omap_dss_driver) For Eg: primary lcd device would be registered with lcd panel driver. lcd panel driver if it is on a parallel interface would use library functions exported from dpi.o. if it is on a dsi interface would use library functions exported from dsi platform driver(dsi.o). Clocks: Handling of clocks in DSS only is one of the design approaches, that does not change the existing implementation. If each of the DSS HW IPs had to handle their own clocks, then corresponding clock changes can be requested in the hwmod database as well which is not the current design/implementation. As stated, this would be handled in another series seperately. For Eg: VENC would need 54MCLK which is termed as dss_opt clocks as of now apart for the dss main clocks. Currently VENC driver needs to be aware of this and has to use clk_get/put, clk_enable/disable, since VENC hwmod is not aware of 54MCLK. Current dss driver: --- 1. Omapdss platform driver - initialises necessary Ips dss, dispc. - also initialises Ips like sdi, dsi, venc, rfbi - creates a custom bus and registers the display devices/drivers connected on the board to the custom bus. 2. Suspend/resume of omapdss - in turn sends suspend/resume calls for each of the display devices registered to it. Modified change: --- Platform driver for each DSS HW IP in addition to the software omap_display driver. Omapdss platform driver - initialises necessary h/w IPs' platform drivers [dss, dispc, dsi, venc, rfbi] and software libraries like dpi, sdi. - continues to have a custom bus and registers the display devices and drivers connected on the board to the custom bus. - continues to handle suspend/resume of the display devices registered to the custom bus. DSS platform driver - initialises DSS IP
Re: [PATCH 0/3] OMAP4: DSS OMAP4 hwmod support
Hi Kevin, On Tue, Jan 11, 2011 at 7:06 AM, Kevin Hilman khil...@ti.com wrote: Hi Sumit, Semwal, Sumit sumit.sem...@ti.com writes: On Sat, Jan 8, 2011 at 4:32 AM, Kevin Hilman khil...@ti.com wrote: Sumit Semwal sumit.sem...@ti.com writes: This patch series enables support for OMAP4 DSS, and adds hwmod support for dss, dispc, dsi1, dsi2, hdmi, rfbi and venc hwmods. This series is confusing as the 3 patches here do not do all the things described here. It also doesn't apply to the master branch (e.g. PATCH 3/3 modifies display.c, which doesn't exist until your other series.) First up, apologies for submitting these patches while the dependent patch series is still under discussion - I guess I should've waited till the hwmod patch series is accepted, but I thought mentioning the dependency might be sufficient. will take care in future. No, stating the dependency in the changelog/cover letter is sufficient. This is my fault for not fully parsing your description of the dependencies and trying to apply directly to linux-omap. My apologies. Sorry for the noise, Thanks, and no worries! :) ~Sumit. Kevin Though I don't quite understand why you think that the 3 patches don't do all that is described. The first patch enables building DSS for OMAP4 by updating the Kconfig accordingly. The second patch enables hwmod support for all the dss IP hwmod devices, and the third one enhances the hwmod lookup to lookup OMAP4 devices as well. If you could tell me what is missing or extra, I would correct that and send an updated version. Thanks, and best regards, ~Sumit. Please take care when writing these cover letters to be sure they are accurate, otherwise reviewers/maintainers can't help but be confused about what is going on. Kevin In OMAP4 there are severals IPs that can be reached by differents interconnect paths depending of the access initiator (MPU vs. SDMA). In the case of the DSS, both L3 direct path and L4 CFG path can be used to access all the DSS IPs. dss is also considered as an IP as dispc, rfbi, and named as dss_dss. TODO: This patch doesn't handle the opt clocks via hwmod - there will be a separate patch series which will take opt clock roles from hwmod, populate them in the device structure, so that the driver can ask for relevant opt-clocks. Also TBD is the migration to pm_runtime APIs, which need to be adapted a little for handling DSS-family of clocks completely. Patch Base: === url = git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git branch master Commit id: fa3b4e23ec20cfc944db7cc2b30b0d82c20e4472 Description: cbus: Fix retu_rtc_do_reset + hwmod patches under discussion: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41534.html + patch series: OMAP2PLUS: DSS: Generalize clock names Benoit Cousson (1): OMAP4: hwmod data: add DSS DISPC DSI1,2 RFBI HDMI VENC Mayuresh Janorkar (1): OMAP2PLUS: DSS2: Add OMAP4 support Sumit Semwal (1): OMAP4: DSS2: Add hwmod device names for OMAP4. arch/arm/mach-omap2/display.c | 23 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 588 drivers/video/omap2/dss/Kconfig | 6 +- drivers/video/omap2/omapfb/Kconfig | 6 +- 4 files changed, 609 insertions(+), 14 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 10/17] OMAP2,3: DSS2: Move clocks from core driver to dss driver
Hi Paul,
On Tue, Jan 11, 2011 at 5:29 AM, Paul Walmsley p...@pwsan.com wrote:
On Fri, 7 Jan 2011, Sumit Semwal wrote:
From: Senthilvadivu Guruswamy svad...@ti.com
All clock management is moved to dss platform driver. clk_get/put APIs use
dss device instead of core platform device.
Hwmod adaptation design requires each of the DSS HW IP to be a platform
driver.
So the device name is changed from omap_display to omap_dss in 2420, 2430,
3xxx clock database files. Now the core driver omap_display only takes care
of panel registration with the custom bus.
core driver also uses the clk_enable() / clk_disable() APIs exposed by DSS
for
clock management.
DSS driver would do clock management of clocks needed by DISPC, RFBI, DSI,
VENC
TODO: The clock content would be adapted to omap_hwmod in a seperate series.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
arch/arm/mach-omap2/clock2420_data.c | 8 +-
arch/arm/mach-omap2/clock2430_data.c | 8 +-
arch/arm/mach-omap2/clock3xxx_data.c | 14 +-
...
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index a220820..7a56c67 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1786,10 +1786,10 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, gfx_2d_fck, gfx_2d_fck, CK_242X),
CLK(NULL, gfx_ick, gfx_ick, CK_242X),
/* DSS domain clocks */
- CLK(omap_display, ick, dss_ick, CK_242X),
- CLK(omap_display, dss1_fck, dss1_fck, CK_242X),
- CLK(omap_display, dss2_fck, dss2_fck, CK_242X),
- CLK(omap_display, tv_fck, dss_54m_fck, CK_242X),
+ CLK(omap_dss, ick, dss_ick, CK_242X),
+ CLK(omap_dss, dss1_fck, dss1_fck, CK_242X),
+ CLK(omap_dss, dss2_fck, dss2_fck, CK_242X),
+ CLK(omap_dss, tv_fck, dss_54m_fck, CK_242X),
/* L3 domain clocks */
CLK(NULL, core_l3_ck, core_l3_ck, CK_242X),
CLK(NULL, ssi_fck, ssi_ssr_sst_fck, CK_242X),
It would be nice if you could figure out some way to combine or
restructure these changes with the patch 4 changes, to avoid changing
these from omapdss to omap_display then to omap_dss.
I thought, and realized that this is done to make sure functionality's
not broken after each patch; here's the logic.
patch 4 is the first step in re-defining role of core.c - this DSS
file should not handle ALL clocks / regulators, but just some related
to displays, hence the move to device name 'omap_display'. At this
point, since all DSS clock handling is still in the same file, we
changed the controlling device name also to 'omap_display'.
patch 10 then is the second step, when all clock handling is moved to
dss.c, and as a result, device_name for all clocks gets changed to
'omap_dss'; for display regulator supplies [like DVI], still the
controlling device is 'omap_display'.
In any case,
Acked-by: Paul Walmsley p...@pwsan.com
Thanks for the Ack! :)
~Sumit.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 08/17] OMAP2,3: DSS2: Build omap_device for each DSS HWIP
Hi Kevin,
On Sat, Jan 8, 2011 at 5:04 AM, Kevin Hilman khil...@ti.com wrote:
Sumit Semwal sumit.sem...@ti.com writes:
From: Senthilvadivu Guruswamy svad...@ti.com
Looks up the hwmod database for each of the given DSS HW IP and builds
omap_device which inturn does the platform device register for each of DSS
HW IP
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
arch/arm/mach-omap2/display.c | 44
+
arch/arm/plat-omap/include/plat/display.h | 6
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 26d3feb..276b800 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -36,10 +36,54 @@ static struct platform_device omap_display_device = {
},
};
+static struct omap_device_pm_latency omap_dss_latency[] = {
+ [0] = {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
Without any latency numbers or AUTO_ADJUST you're going to have noisy
output from omap_device.
+ },
+};
+
int __init omap_display_init(struct omap_dss_board_info
*board_data)
{
int r = 0;
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+ int i;
+ struct omap_display_platform_data pdata;
+ char *oh_name[] = { dss_dss, /* omap2,3 */
+ dss_dispc, /* omap2,3 */
+ dss_rfbi, /* omap2,3 */
+ dss_venc, /* omap2,3 */
+ dss_dsi1 }; /* omap3 */
Why all the extra whitespace before the strings?
+ char *dev_name[] = { omap_dss, omap_dispc, omap_rfbi,
+ omap_venc, omap_dsi1 };
ditto
+ int oh_count;
+
+ if (cpu_is_omap24xx()) {
+ oh_count = ARRAY_SIZE(oh_name) - 1;
+ /* last hwmod dev in oh_name is not available for omap2 */
+ } else {
+ oh_count = ARRAY_SIZE(oh_name);
+ }
braces not needed
+ pdata.board_data = board_data;
extra whitespace not necessary
+ pdata.board_data-get_last_off_on_transaction_id = NULL;
instead, you should probably zero all of pdata before using it since it
is on the stack
+ for (i = 0; i oh_count; i++) {
+ oh = omap_hwmod_lookup(oh_name[i]);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name[i]);
+ return r;
+ }
+ od = omap_device_build(dev_name[i], -1, oh, pdata,
+ sizeof(struct omap_display_platform_data),
+ omap_dss_latency,
+ ARRAY_SIZE(omap_dss_latency), 0);
+
+ WARN((IS_ERR(od)), Could not build omap_device for %s\n,
+ oh_name[i]);
yet code below will still try and register it?
+ }
omap_display_device.dev.platform_data = board_data;
r = platform_device_register(omap_display_device);
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index 871bbae..23afd6d 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -26,6 +26,7 @@
#include linux/platform_device.h
#include asm/atomic.h
+
stray whitespace change
#define DISPC_IRQ_FRAMEDONE (1 0)
#define DISPC_IRQ_VSYNC (1 1)
#define DISPC_IRQ_EVSYNC_EVEN (1 2)
@@ -224,6 +225,11 @@ struct omap_dss_board_info {
/* Init with the board info */
extern int omap_display_init(struct omap_dss_board_info *board_data);
+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;
Thanks for all your comments; will incorporate in the upcoming version.
Best regards,
~Sumit.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 09/17] OMAP2,3: DSS2: DSS: create platform_driver, move init,exit to driver
Hi Kevin,
On Sat, Jan 8, 2011 at 5:13 AM, Kevin Hilman khil...@ti.com wrote:
Sumit Semwal sumit.sem...@ti.com writes:
From: Senthilvadivu Guruswamy svad...@ti.com
Hwmod adaptation design requires each of the DSS HW IP to be a platform
driver.
So a platform_driver of DSS is created and init exit methods are moved from
core.c
to its driver probe,remove. pdev member has to be maintained by its own
drivers.
DSS platform driver is registered from inside omap_dss_probe, in the order
desired.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
drivers/video/omap2/dss/core.c | 21 +++
drivers/video/omap2/dss/dss.c | 55
++-
drivers/video/omap2/dss/dss.h | 4 +-
3 files changed, 65 insertions(+), 15 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 48d20d8..faca859 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -497,9 +497,9 @@ static inline void dss_uninitialize_debugfs(void)
static int omap_dss_probe(struct platform_device *pdev)
{
struct omap_dss_board_info *pdata = pdev-dev.platform_data;
- int skip_init = 0;
int r;
int i;
+ int skip_init = 0;
looks like unnessary move.
maybe you meant to remove this var since its usage was removed from this
function?
core.pdev = pdev;
@@ -517,15 +517,9 @@ static int omap_dss_probe(struct platform_device *pdev)
core.ctx_id = dss_get_ctx_id();
DSSDBG(initial ctx id %u\n, core.ctx_id);
-#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
- /* DISPC_CONTROL */
- if (omap_readl(0x48050440) 1) /* LCD enabled? */
- skip_init = 1;
-#endif
-
- r = dss_init(skip_init);
+ r = dss_init_platform_driver();
if (r) {
- DSSERR(Failed to initialize DSS\n);
+ DSSERR(Failed to initialize DSS platform driver\n);
goto err_dss;
}
@@ -553,6 +547,11 @@ static int omap_dss_probe(struct platform_device *pdev)
goto err_venc;
}
+#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
+ /* DISPC_CONTROL */
+ if (omap_readl(0x48050440) 1) /* LCD enabled? */
+ skip_init = 1;
+#endif
nope, you just moved it here.
But it's also duplicated in dsshw_probe below. Is that needed?
Yes; these two are needed as both dss_init() (which is replaced with
dss_init_platform_driver() in this patch) and also by sdi_init().
sdi_init() is a software init, so it will not be moved to a
platform_driver. That's why we need the #ifdef.. #endif in both
dss_probe() and dsshw_probe().
if (cpu_is_omap34xx()) {
r = sdi_init(skip_init);
if (r) {
@@ -610,7 +609,7 @@ err_dispc:
err_dpi:
rfbi_exit();
err_rfbi:
- dss_exit();
+ dss_deinit_platform_driver();
s/deinit/uninit/ or uninitial
Sure, will change.
err_dss:
dss_clk_disable_all_no_ctx();
dss_put_clocks();
@@ -636,7 +635,7 @@ static int omap_dss_remove(struct platform_device *pdev)
sdi_exit();
}
- dss_exit();
+ dss_deinit_platform_driver();
/* these should be removed at some point */
c = core.dss_ick-usecount;
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 77c3621..ebb294a 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -59,6 +59,7 @@ struct dss_reg {
dss_write_reg(idx, FLD_MOD(dss_read_reg(idx), val, start, end))
static struct {
+ struct platform_device *pdev;
void __iomem *base;
struct clk *dpll4_m4_ck;
@@ -549,7 +550,7 @@ void dss_set_dac_pwrdn_bgz(bool enable)
REG_FLD_MOD(DSS_CONTROL, enable, 5, 5); /* DAC Power-Down Control */
}
-int dss_init(bool skip_init)
+static int dss_init(bool skip_init)
{
int r;
u32 rev;
@@ -629,7 +630,7 @@ fail0:
return r;
}
-void dss_exit(void)
+static void dss_exit(void)
{
if (cpu_is_omap34xx())
clk_put(dss.dpll4_m4_ck);
@@ -639,3 +640,53 @@ void dss_exit(void)
iounmap(dss.base);
}
+/* DSS HW IP initialisation */
+static int omap_dsshw_probe(struct platform_device *pdev)
+{
+ int r;
+ int skip_init = 0;
+
+ dss.pdev = pdev;
+
+#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
+ /* DISPC_CONTROL */
+ if (omap_readl(0x48050440) 1) /* LCD enabled? */
+ skip_init = 1;
+#endif
+
+ r = dss_init(skip_init);
+ if (r) {
+ DSSERR(Failed to initialize DSS\n);
+ goto err_dss;
+ }
+
+err_dss:
+
+ return r;
+}
+
+static int omap_dsshw_remove(struct platform_device *pdev)
+{
+ dss_exit();
+
+ return 0;
+}
+
+static struct platform_driver omap_dsshw_driver = {
+ .probe = omap_dsshw_probe,
+ .remove = omap_dsshw_remove,
+
Re: [PATCH 0/3] OMAP4: DSS OMAP4 hwmod support
Hi Kevin, On Sat, Jan 8, 2011 at 4:32 AM, Kevin Hilman khil...@ti.com wrote: Sumit Semwal sumit.sem...@ti.com writes: This patch series enables support for OMAP4 DSS, and adds hwmod support for dss, dispc, dsi1, dsi2, hdmi, rfbi and venc hwmods. This series is confusing as the 3 patches here do not do all the things described here. It also doesn't apply to the master branch (e.g. PATCH 3/3 modifies display.c, which doesn't exist until your other series.) First up, apologies for submitting these patches while the dependent patch series is still under discussion - I guess I should've waited till the hwmod patch series is accepted, but I thought mentioning the dependency might be sufficient. will take care in future. Though I don't quite understand why you think that the 3 patches don't do all that is described. The first patch enables building DSS for OMAP4 by updating the Kconfig accordingly. The second patch enables hwmod support for all the dss IP hwmod devices, and the third one enhances the hwmod lookup to lookup OMAP4 devices as well. If you could tell me what is missing or extra, I would correct that and send an updated version. Thanks, and best regards, ~Sumit. Please take care when writing these cover letters to be sure they are accurate, otherwise reviewers/maintainers can't help but be confused about what is going on. Kevin In OMAP4 there are severals IPs that can be reached by differents interconnect paths depending of the access initiator (MPU vs. SDMA). In the case of the DSS, both L3 direct path and L4 CFG path can be used to access all the DSS IPs. dss is also considered as an IP as dispc, rfbi, and named as dss_dss. TODO: This patch doesn't handle the opt clocks via hwmod - there will be a separate patch series which will take opt clock roles from hwmod, populate them in the device structure, so that the driver can ask for relevant opt-clocks. Also TBD is the migration to pm_runtime APIs, which need to be adapted a little for handling DSS-family of clocks completely. Patch Base: === url = git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git branch master Commit id: fa3b4e23ec20cfc944db7cc2b30b0d82c20e4472 Description: cbus: Fix retu_rtc_do_reset + hwmod patches under discussion: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41534.html + patch series: OMAP2PLUS: DSS: Generalize clock names Benoit Cousson (1): OMAP4: hwmod data: add DSS DISPC DSI1,2 RFBI HDMI VENC Mayuresh Janorkar (1): OMAP2PLUS: DSS2: Add OMAP4 support Sumit Semwal (1): OMAP4: DSS2: Add hwmod device names for OMAP4. arch/arm/mach-omap2/display.c | 23 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 588 drivers/video/omap2/dss/Kconfig | 6 +- drivers/video/omap2/omapfb/Kconfig | 6 +- 4 files changed, 609 insertions(+), 14 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 06/17] OMAP2,3: DSS2: Create new file display.c for central dss driver registration.
Tomi, On Fri, Jan 7, 2011 at 7:33 PM, Tomi Valkeinen tomi.valkei...@nokia.com wrote: Hi, On Fri, 2011-01-07 at 16:55 +0530, ext Sumit Semwal wrote: A new file display.c is introduced for display driver init, which adds a function omap_display_init to do the DSS driver registration. This is the first step in moving away registration of DSS from board files into a common place. Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com Signed-off-by: Sumit Semwal sumit.sem...@ti.com --- arch/arm/mach-omap2/Makefile | 2 + arch/arm/mach-omap2/display.c | 57 + arch/arm/plat-omap/include/plat/display.h | 4 ++ 3 files changed, 63 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/display.c diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 4ab82f6..57b89e6 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -237,3 +237,5 @@ obj-y += $(smc91x-m) $(smc91x-y) smsc911x-$(CONFIG_SMSC911X) := gpmc-smsc911x.o obj-y += $(smsc911x-m) $(smsc911x-y) + +obj-y += display.o diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c new file mode 100644 index 000..26d3feb --- /dev/null +++ b/arch/arm/mach-omap2/display.c @@ -0,0 +1,57 @@ +/* + * OMAP2plus display device setup / initialization. + * + * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/ + * Senthilvadivu Guruswamy + * Sumit Semwal + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed as is WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include linux/kernel.h +#include linux/init.h +#include linux/platform_device.h +#include linux/io.h +#include linux/clk.h +#include linux/err.h + +#include plat/display.h +#include plat/omap_hwmod.h +#include plat/omap_device.h + +#ifdef CONFIG_OMAP2_DSS This also needs to be built in when DSS is configured as module. The define above is only valid when DSS is configured as built-in. So you can either check for both CONFIG_OMAP2_DSS and CONFIG_OMAP2_DSS_MODULE here, or, I think a bit more cleanly: - Compile display.c only if CONFIG_OMAP2_DSS[_MODULE] is defined (see the Makefile, look for example how i2c-omap is handled). - Check for CONFIG_OMAP2_DSS[_MODULE] in the header file, and define an empty static inline function for omap_display_init() if DSS is disabled. Yes, thanks. I did it the cleaner way :) - coming up in the next patch series. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 06/17] OMAP2,3: DSS2: Create new file display.c for central dss driver registration.
Hi Kevin, On Sat, Jan 8, 2011 at 2:56 AM, Kevin Hilman khil...@ti.com wrote: Sumit Semwal sumit.sem...@ti.com writes: A new file display.c is introduced for display driver init, which adds a function omap_display_init to do the DSS driver registration. This is the first step in moving away registration of DSS from board files into a common place. Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com Signed-off-by: Sumit Semwal sumit.sem...@ti.com --- arch/arm/mach-omap2/Makefile | 2 + arch/arm/mach-omap2/display.c | 57 + arch/arm/plat-omap/include/plat/display.h | 4 ++ 3 files changed, 63 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/display.c diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 4ab82f6..57b89e6 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -237,3 +237,5 @@ obj-y += $(smc91x-m) $(smc91x-y) smsc911x-$(CONFIG_SMSC911X) := gpmc-smsc911x.o obj-y += $(smsc911x-m) $(smsc911x-y) + +obj-y += display.o diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c new file mode 100644 index 000..26d3feb --- /dev/null +++ b/arch/arm/mach-omap2/display.c @@ -0,0 +1,57 @@ +/* + * OMAP2plus display device setup / initialization. + * + * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/ + * Senthilvadivu Guruswamy + * Sumit Semwal + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed as is WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include linux/kernel.h +#include linux/init.h +#include linux/platform_device.h +#include linux/io.h +#include linux/clk.h +#include linux/err.h + +#include plat/display.h +#include plat/omap_hwmod.h +#include plat/omap_device.h Minor nit: the hwmod and omap_device headers are not needed for this patch. Please add them when needed (PATCH 8) Thanks; yes, - coming up in the next patch version. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 06/17] OMAP2,3: DSS2: Create new file display.c for central dss driver registration.
On Sun, Jan 9, 2011 at 12:29 PM, Semwal, Sumit sumit.sem...@ti.com wrote: Tomi, On Fri, Jan 7, 2011 at 7:33 PM, Tomi Valkeinen tomi.valkei...@nokia.com wrote: Hi, On Fri, 2011-01-07 at 16:55 +0530, ext Sumit Semwal wrote: A new file display.c is introduced for display driver init, which adds a function omap_display_init to do the DSS driver registration. This is the first step in moving away registration of DSS from board files into a common place. Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com Signed-off-by: Sumit Semwal sumit.sem...@ti.com --- arch/arm/mach-omap2/Makefile | 2 + arch/arm/mach-omap2/display.c | 57 + arch/arm/plat-omap/include/plat/display.h | 4 ++ 3 files changed, 63 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/display.c diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 4ab82f6..57b89e6 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -237,3 +237,5 @@ obj-y += $(smc91x-m) $(smc91x-y) smsc911x-$(CONFIG_SMSC911X) := gpmc-smsc911x.o obj-y += $(smsc911x-m) $(smsc911x-y) + +obj-y += display.o diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c new file mode 100644 index 000..26d3feb --- /dev/null +++ b/arch/arm/mach-omap2/display.c @@ -0,0 +1,57 @@ +/* + * OMAP2plus display device setup / initialization. + * + * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/ + * Senthilvadivu Guruswamy + * Sumit Semwal + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed as is WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include linux/kernel.h +#include linux/init.h +#include linux/platform_device.h +#include linux/io.h +#include linux/clk.h +#include linux/err.h + +#include plat/display.h +#include plat/omap_hwmod.h +#include plat/omap_device.h + +#ifdef CONFIG_OMAP2_DSS This also needs to be built in when DSS is configured as module. The define above is only valid when DSS is configured as built-in. So you can either check for both CONFIG_OMAP2_DSS and CONFIG_OMAP2_DSS_MODULE here, or, I think a bit more cleanly: - Compile display.c only if CONFIG_OMAP2_DSS[_MODULE] is defined (see the Makefile, look for example how i2c-omap is handled). - Check for CONFIG_OMAP2_DSS[_MODULE] in the header file, and define an empty static inline function for omap_display_init() if DSS is disabled. Yes, thanks. I did it the cleaner way :) - coming up in the next patch series. Oops - I meant next version. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 06/17] OMAP2,3 DSS2 Move DSS driver register from board file to devices.c
Hi Tomi, On Wed, Jan 5, 2011 at 4:21 PM, Tomi Valkeinen tomi.valkei...@nokia.com wrote: Hi, On Mon, 2011-01-03 at 18:20 +0530, ext Guruswamy Senthilvadivu wrote: From: Senthilvadivu Guruswamy svad...@ti.com omap_display_init function is introduced in devices.c to do the DSS driver registration. So replace platform_device_register or platform_add_devices of DSS with omap_display_init(). This and two previous patches are missing a color in the subject. I'm also ok with Kevin's suggestion to put display code in separate file. There's other stuff to add there also at some point, like changing pinmuxing. Also, I think it would be cleaner to first add the new code to devices.c (or display.c) and display.h in one patch, then in another patch change the board files to use this new display init. Since Senthil is going to be out for some time, I am in the process of updating this patch-set based on Kevin's, Tony's and your comment. I should be able to give you the updated set pretty soon. Best regards, ~Sumit. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 08/17] OMAP2,3: DSS2: Create platform_driver for each DSS HW IP
Hi Tomi, On Wed, Jan 5, 2011 at 4:57 PM, Tomi Valkeinen tomi.valkei...@nokia.com wrote: Hi, On Mon, 2011-01-03 at 18:21 +0530, ext Guruswamy Senthilvadivu wrote: From: Senthilvadivu Guruswamy svad...@ti.com Hwmod adaptation design requires each of the DSS HW IP to be a platform driver. Platform driver of dsshw has to be registered before of dispc, rfbi, dsi1, venc and omapdisplay driver should be after all the HW IPs. Sequence it with arch_initcall and device_initcall_sync. Do you know if there some extra meaning for the _sync initcalls? The name would imply something else that just init ordering. [Sumit]:Looking at include/linux/init.h and some web-references [1] [2] [3], our understanding is that all inits called via device_initcall_sync() would be called later than the ones called by device_initcall() in an SMP environment. [1] points to the patch for enabling all probes on one level to finish before initcall for next level are processed. I don't like using multiple initcall levels in the same driver. It's already quite complicated with omapdss, omapfb and the panel drivers. What were the dependencies here? Could we have just one initcall which would do the registration of platform drivers in the correct order? [Sumit]: With this patchset, dss would have platform drivers for each of the DSS h/w IPs - core would only do panel registration and s/w inits (like dpi and sdi). dispc, dss, rfbi, venc each of these are separate platform drivers which will have their own init(). The idea was to order the inits like this: [bus, then h/w IPs, then s/w blocks]. So, omap_dss_bus_init first = core_initcall() then omap_dss for dss hw ip init = arch_initcall() then any of the other h/w IPs (dsi, rfbi, venc, dispc) in any order = device_initcall(). omap_display device in the end = device_initcall_sync(); this would also call s/w blocks init, and the panel devices. (this should wait for all others to have finished). omapfb is a lateinit call, so will happen after all other dss inits have happened. Does this even work if the DSS is compiled as a module? I have the recollection that a module can only have one initcall, and in this case omapdss would have many. [Sumit]: we haven't tried compiling DSS as module - I guess we will have to create each dss hw IP also as a separate module. About making one common initcall, then I think we would need to have all platform_driver related functions either as global or in one file. is this a better option than having each as a separate module? I guess I will send the updated patch series once we agree on this. [I have incorporated all other comments from Tony, Kevin and you on the other patches]. Best regards, ~Sumit. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html [1]: http://readlist.com/lists/vger.kernel.org/linux-kernel/54/273365.html [2]: http://www.webservertalk.com/archive242-2006-10-1713467.html [3]: http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-01/msg11683.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 07/17] OMAP2,3: DSS2: Build omap_device for each DSS HWIP
Hi Tony,
On Tue, Jan 4, 2011 at 7:26 AM, Tony Lindgren t...@atomide.com wrote:
* Guruswamy Senthilvadivu svad...@ti.com [110103 04:51]:
+ char *omap2_oh_name[] = { dss_dss, dss_dispc, dss_rfbi,
+ dss_venc };
+ char *omap3_oh_name[] = { dss_dss, dss_dispc, dss_rfbi,
+ dss_venc, dss_dsi1 };
+ char *omap2_dev_name[] = { omap_dss, omap_dispc, omap_rfbi,
+ omap_venc };
+ char *omap3_dev_name[] = { omap_dss, omap_dispc, omap_rfbi,
+ omap_venc, omap_dsi1 };
+ char *(*oh_name)[];
+ char *(*dev_name)[];
+ int oh_count;
+
+ if (cpu_is_omap24xx()) {
+ oh_name = omap2_oh_name;
+ dev_name = omap2_dev_name;
+ oh_count = ARRAY_SIZE(omap2_oh_name);
+ } else {
+ oh_name = omap3_oh_name;
+ dev_name = omap3_dev_name;
+ oh_count = ARRAY_SIZE(omap3_oh_name);
+ }
Here it looks like you don't need to repeat the common names
dss_dss, dss_dispc, dss_rfbi. Instead you can have a
common char *omap_oh_name[5] then set oh_count smaller based
on the omap type.
Thanks, yes, that's a good suggestion. Senthil is going to be out for
sometime, so I will update this and send an updated patch series by
tomorrow, after waiting for any more comments.
Best regards,
~Sumit.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 08/17] OMAP2,3: DSS2: Create platform_driver for each DSS HW IP
Hi Kevin,
On Wed, Jan 5, 2011 at 5:37 AM, Kevin Hilman khil...@ti.com wrote:
Guruswamy Senthilvadivu svad...@ti.com writes:
From: Senthilvadivu Guruswamy svad...@ti.com
Hwmod adaptation design requires each of the DSS HW IP to be a platform
driver.
Platform driver of dsshw has to be registered before of dispc, rfbi, dsi1,
venc and omapdisplay driver should be after all the HW IPs. Sequence it with
arch_initcall and device_initcall_sync.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Rather than creating a bunch of empty/dummy driver here to be populated
later, I'd prefer them to be created as needed in the subsequent
patches.
For example, the dispc parts of this patch should be added in PATCH 9
where you populate the functions. The RFBI parts of this patch should
be added in PATCH 12, etc. etc.
Thanks for your comments; since Senthil is going to be out for
sometime, I would make these changes and push as the next version;
will wait a bit for other comments too.
Best regards,
~Sumit.
Kevin
---
drivers/video/omap2/dss/core.c | 2 +-
drivers/video/omap2/dss/dispc.c | 28
drivers/video/omap2/dss/dsi.c | 29 -
drivers/video/omap2/dss/dss.c | 27 +++
drivers/video/omap2/dss/rfbi.c | 28
drivers/video/omap2/dss/venc.c | 28
6 files changed, 140 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 48d20d8..d165434 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -989,7 +989,7 @@ static int __init omap_dss_init2(void)
}
core_initcall(omap_dss_init);
-device_initcall(omap_dss_init2);
+device_initcall_sync(omap_dss_init2);
#endif
MODULE_AUTHOR(Tomi Valkeinen tomi.valkei...@nokia.com);
diff --git a/drivers/video/omap2/dss/dispc.c
b/drivers/video/omap2/dss/dispc.c
index fa40fa5..942dea5 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3167,3 +3167,31 @@ int dispc_setup_plane(enum omap_plane plane,
return r;
}
+
+/* DISPC HW IP initialisation */
+static int omap_dispchw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap_dispchw_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static struct platform_driver omap_dispchw_driver = {
+ .probe = omap_dispchw_probe,
+ .remove = omap_dispchw_remove,
+ .driver = {
+ .name = omap_dispc,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init omap_dispc_init(void)
+{
+ return platform_driver_register(omap_dispchw_driver);
+}
+
+device_initcall(omap_dispc_init);
+
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index aa4f7a5..037d366 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -292,7 +292,6 @@ static inline u32 dsi_read_reg(const struct dsi_reg idx)
return __raw_readl(dsi.base + idx.idx);
}
-
void dsi_save_context(void)
{
}
@@ -3304,3 +3303,31 @@ void dsi_exit(void)
DSSDBG(omap_dsi_exit\n);
}
+/* DSI1 HW IP initialisation */
+static int omap_dsi1hw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap_dsi1hw_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static struct platform_driver omap_dsi1hw_driver = {
+ .probe = omap_dsi1hw_probe,
+ .remove = omap_dsi1hw_remove,
+ .driver = {
+ .name = omap_dsi1,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init omap_dsi1_init(void)
+{
+ return platform_driver_register(omap_dsi1hw_driver);
+}
+
+device_initcall(omap_dsi1_init);
+
+
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 77c3621..6d0bd89 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -639,3 +639,30 @@ void dss_exit(void)
iounmap(dss.base);
}
+/* DSS HW IP initialisation */
+static int omap_dsshw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap_dsshw_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static struct platform_driver omap_dsshw_driver = {
+ .probe = omap_dsshw_probe,
+ .remove = omap_dsshw_remove,
+ .driver = {
+ .name = omap_dss,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init omap_dss_init1(void)
+{
+ return platform_driver_register(omap_dsshw_driver);
+}
+
+arch_initcall(omap_dss_init1);
+
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index bbe6246..a086233 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -1054,3 +1054,31 @@ int
