Re: [PATCH] omapdrm: use alloc_ordered_workqueue() instead of UNBOUND w/ max_active = 1
On Wed, Aug 22, 2012 at 6:49 PM, Tejun Heo t...@kernel.org wrote: This is an equivalent conversion and will ease scheduled removal of WQ_NON_REENTRANT. Only compile tested. Signed-off-by: Tejun Heo t...@kernel.org I've tested it Signed-off-by: Rob Clark r...@ti.com --- drivers/staging/omapdrm/omap_drv.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/omapdrm/omap_drv.c b/drivers/staging/omapdrm/omap_drv.c index 4beab94..672cb3a 100644 --- a/drivers/staging/omapdrm/omap_drv.c +++ b/drivers/staging/omapdrm/omap_drv.c @@ -571,8 +571,7 @@ static int dev_load(struct drm_device *dev, unsigned long flags) dev-dev_private = priv; - priv-wq = alloc_workqueue(omapdrm, - WQ_UNBOUND | WQ_NON_REENTRANT, 1); + priv-wq = alloc_ordered_workqueue(omapdrm, 0); INIT_LIST_HEAD(priv-obj_list); -- 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] ASoC: snd_soc_jack for HDMI audio: does it make sense?
On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote: Hello! I have been working on prototypes for the ASoC OMAP HDMI audio driver to propagate events from the HDMI output (e.g., display getting enabled/disabled/suspended). This for the users of the driver to react to such events. For instance, if the display is disabled or disconected, audio could be stopped, rerouted or whatever other decision the user makes. This is needed because, if, for instance, the HDMI IP goes off, audio will stall and the audio users will only see a playback write error (DMA or IRQ trouble?) In my prototypes I have used snd_soc_jack for this purpose and I have some questions: *I see snd_soc_jack is used mostly for headsets and microphones with actual external mechanical connections. Strictly, in my case I propagate events originated by the OMAP display driver (changes in the power state), and not from external events. Some of these events are generated from an actual HDMI cable connection/disconnection, though. *Maybe the event should be propagated by omapdss/omapdrm/drm and the entity in charge of the audio policy should listen those events instead. *I do see SND_JACK_VIDEOOUT and SND_JACK_AVOUT types so maybe it is feasible for an audio driver to report events from an AV output. I was wondering about how much sense does it make to you guys use a snd_soc_jack in this case? How does DRM handle audio? I made a quick grep, but I see the drm drivers only enabling the audio in the HW, nothing else. I confess to not knowing too much about audio/alsa, but what does audio driver need from hdmi? Just hotplug events? From a quick look, it seems most of what the existing drm drivers are doing is detecting if the display supports audio, and then turning on/off the hw.. (and some infoframe stuff in some cases). Does ASoC support 'hotplug' of audio devices? If so, maybe it makes some sense to have some support in drm core. At least all the edid parsing stuff to determine if the display supports audio should be generic and not driver specific. BR, -R If there's a common generic way to handle this, we should obviously use that. But if we need to choose between doing something custom or doing it in omapdrm driver, I think we should go for drm the only solution and forget about audio with omapfb. 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] omap2+: add drm device
On Thu, May 24, 2012 at 12:01 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hi,
On Wed, 2012-05-23 at 15:08 -0500, Andy Gross wrote:
Register OMAP DRM/KMS platform device. DMM is split into a
separate device using hwmod.
Signed-off-by: Andy Gross andy.gr...@ti.com
snip
+static int __init omap_init_drm(void)
+{
+ struct omap_hwmod *oh = NULL;
+ struct platform_device *pdev;
+
+ /* lookup and populate the DMM information, if present - OMAP4+ */
+ oh = omap_hwmod_lookup(dmm);
+
+ if (oh) {
+ pdev = omap_device_build(oh-name, -1, oh, NULL, 0, NULL, 0,
+ false);
+ WARN(IS_ERR(pdev), Could not build omap_device for %s\n,
+ oh-name);
+ }
+
+ return platform_device_register(omap_drm_device);
+
+}
I still don't like fixing the tiler to drm. I would like to have basic
tiler support in omapfb also, but with this approach I'll need to
duplicate the code. And even if we disregard omapfb, wouldn't it be
architecturally better to have the tiler as a separate independent
library/driver?
Not easily, at least not if we want to manage to use tiler/dmm in a
more dynamic way, or to enable some additional features which are
still on the roadmap (like reprogramming dmm synchronized w/ scanout,
or some things which are coming if future hw generations). We need
one place to keep track of which buffers are potentially evictable to
make room for mapping a new buffer. And if you look at the tricks
that go on with mmap'ing tiled buffers to userspace, you *really*
don't want to duplicate that in N different drivers.
Fortunately with dmabuf there is not really a need for N different
drivers to need to use tiler/dmm directly. The dmabuf mechanism
provides what they need to import GEM buffers from omapdrm. That may
not really help omapfb because fbdev doesn't have a concept of
importing buffers. But OTOH this is unnecessary, because drm provides
an fbdev interface for legacy apps. The best thing I'd recommend is,
if you miss some features of omapfb in the drm fbdev implementation,
is to send some patches to add this missing features.
+struct omap_drm_platform_data {
+ struct omap_kms_platform_data *kms_pdata;
+};
This one is missing struct omap_dmm_platform_data *dmm_pdata, so you
didn't just move the struct. Is that on purpose?
the dmm pdata is no longer needed because we get what we need from
hwmod via platform_get_resource()
BR,
-R
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
