Re: [PATCH] omap2+: add drm device
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?
+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?
Tomi
signature.asc
Description: This is a digitally signed message part
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
Re: MFD USB host: prevents CORE retention in idle
On Thu, May 24, 2012 at 5:55 AM, Kevin Hilman khil...@ti.com wrote: On 05/23/2012 05:01 PM, Kevin Hilman wrote: Hi Keshava, Using current l-o master, I noticed that CORE was not hitting retention in idle on my 3530/Overo. CORE hits retention on suspend just fine. Debugging this, I found that usbtll_fck was still enabled during idle, thus preventing CORE from hitting retention. To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config) and was then started seeing CORE hit retention in idle again. I have nothing plugged into the USB host port on this board, so I would've expected that runtime PM would've kicked in and shutdown this clock. Any ideas what's going on here? Is this expected behavior? If it helps, attached is a bootlog after enabling debug for mfd/omap-usb-host.c as well. Notice there's a couple of clock-related warnings from this driver as well. Not sure if they're relevant: usbhs_omap: alias fck already exists usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22 these clocks were specific to omap4 and it should not cause any problem to omap3 boards. I will try to reproduce this on 3430 sdp to explore further. With debug enabled, I see the runtime resume during init followed by the runtime suspend. [ 0.936248] usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22 [ 0.944152] usbhs_omap usbhs_omap: starting TI HSUSB Controller [ 0.944335] usbhs_omap usbhs_omap: usbhs_runtime_resume [ 0.944641] usbhs_omap usbhs_omap: OMAP UHH_REVISION 0x10 [ 0.944641] usbhs_omap usbhs_omap: OMAP3 ES version ES2.1 [ 0.944671] usbhs_omap usbhs_omap: UHH setup done,ry uhh_hostconfig=8000121d [ 0.947082] usbhs_omap usbhs_omap: usbhs_runtime_suspend However, later in the boot I see a runtime_resume and never see another suspend. That seems to be the root cause of CORE not hitting retention. From the boot log: [ 2.018707] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 2.025787] ehci_hcd: block sizes: qh 64 qtd 96 itd 160 sitd 96 [ 2.026306] ehci-omap ehci-omap.0: failed to get ehci port1 regulator [ 2.026519] usbhs_omap usbhs_omap: usbhs_runtime_resume [ 3.030639] ehci-omap ehci-omap.0: phy reset operation timed out [ 3.030700] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0 cc=1 pcc=3 ordered ports=3 [ 3.030731] ehci-omap ehci-omap.0: reset hcc_params 0016 thresh 1 uframes 256/512/1024 park [ 3.030761] ehci-omap ehci-omap.0: reset command 0080b02 park=3 ithresh=8 period=1024 Reset HALT [ 3.030792] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller Since the only get/puts I see are in omap_usbhs_init(), I'm not sure how this driver is being runtime resumed. Presumably it's due to how the rest of the USB stack works, which I'm not at all familiar with. Hopefully, the above is enough to debug the problem, Thanks, 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] omap2+: add drm device
On Thu, 2012-05-24 at 00:27 -0600, Clark, Rob wrote:
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.
So why can't all that code be in a tiler library/driver?
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.
Well, at least currently omapfb and omapdrm work quite differently, if
I've understood right. Can we make a full omapfb layer on top of
omapdrm? With multiple framebuffers mapped to one or more overlays,
support for all the ioctls, etc?
I guess we'd still need to have omapfb driver to keep the module
parameters and behavior the same. Can omapdrm be used from inside the
kernel by another driver?
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] omap2+: add drm device
On Thu, 2012-05-24 at 10:05 +0300, Tomi Valkeinen wrote:
On Thu, 2012-05-24 at 00:27 -0600, Clark, Rob wrote:
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.
So why can't all that code be in a tiler library/driver?
And I think we've discussed about this before, so sorry if I'm repeating
myself. I just find it odd that we are not able to create a nice
separate lib/driver for the tiler, which is a separate piece of HW that
multiple drivers might want to use.
Tomi
signature.asc
Description: This is a digitally signed message part
RE: [PATCH-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data
Hi On Wed, 23 May 2012, Hiremath, Vaibhav wrote: I believe register read/write to IP block is depends on only interface Clocks? Atleast in case of OMAP3, it was like that, right?? No, on OMAP3, most modules need both the interface clock enabled, and at least one of their functional clocks. For modules with multiple functional clocks like the OMAP3 USBHOST, we had to use trial and error to determine which functional clock was the main clock, since it wasn't documented. If we got it wrong, then register accesses to the module would result in an abort. The AM33xx/OMAP4 behavior should be a little easier in this regard, though, since the MODULEMODE bits should just control everything for a given module, and that should be handled by the hwmod code. Nevertheless it is still good to specify a main_clk so we know how fast the module's registers are clocked and to locate the module in the power management hierarchy. Another issues is, I came across situation where, two modules fall into different clock domains but their functional clock is happened to be coming from same source/dpll-divider. So in order to satisfy clkdm match between them, I have kept nodes without enable_regs. Could you please provide an example? So currently, I have mentioned same entry in both the places (especially for Peripherals/modules). I am planning to remove ocp_if/clk entry data for all modules.. Hmmm, could you explain this further? what if, module only has interface clock? Should it be present as main_clk or ocp_if.clk or both?? Example would be, TPCC, TPTC, smartreflex, etc... Well it definitely should be present as the ocp_if.clk. I personally think it would be good to list the same clock as the hwmod's main_clk too, but it's currently not strictly necessary. There are some examples in the omap_hwmod_44xx_data.c file, like omap44xx_mailbox_hwmod. - 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 0/2] OMAPDSS: write-through caching support for omapfb
On Tue, 2012-05-22 at 22:54 +0300, Siarhei Siamashka wrote: This is a very simple few-liner patchset, which allows to optionally enable write-through caching for OMAP DSS framebuffer. The problem with the current writecombine cacheability attribute is that it only speeds up writes. Uncached reads are slow, even though the use of NEON mitigates this problem a bit. Traditionally, xf86-video-fbdev DDX is using shadow framebuffer in the system memory. Which contains a copy of the framebuffer data for the purpose of providing fast read access to it when needed. Framebuffer read access is required not so often, but it still gets used for scrolling and moving windows around in Xorg server. And the users perceive their linux desktop as rather sluggish when these operations are not fast enough. In the case of ARM hardware, framebuffer is typically physically located in the main memory. And the processors still support write-through cacheability attribute. According to ARM ARM, the writes done to write-through cached memory inside the level of cache are visible to all observers outside the level of cache without the need of explicit cache maintenance (same rule as for non-cached memory). So write-through cache is a perfect choice when only CPU is allowed to modify the data in the framebuffer and everyone else (screen refresh DMA) is only reading it. That is, assuming that write-through cached memory provides good performance and there are no quirks. As the framebuffer reads become fast, the need for shadow framebuffer disappears. I ran my own fb perf test on omap3 overo board (perf test in https://gitorious.org/linux-omap-dss2/omapfb-tests) : vram_cache=n: sequential_horiz_singlepixel_read: 25198080 pix, 4955475 us, 5084897 pix/s sequential_horiz_singlepixel_write: 434634240 pix, 4081146 us, 106498086 pix/s sequential_vert_singlepixel_read: 20106240 pix, 4970611 us, 4045023 pix/s sequential_vert_singlepixel_write: 98572800 pix, 4985748 us, 19770915 pix/s sequential_line_read: 40734720 pix, 4977906 us, 8183103 pix/s sequential_line_write: 1058580480 pix, 5024628 us, 210678378 pix/s nonsequential_singlepixel_write: 17625600 pix, 4992828 us, 3530183 pix/s nonsequential_singlepixel_read: 9661440 pix, 4952973 us, 1950634 pix/s vram_cache=y: sequential_horiz_singlepixel_read: 270389760 pix, 4994154 us, 54141253 pix/s sequential_horiz_singlepixel_write: 473149440 pix, 3932801 us, 120308512 pix/s sequential_vert_singlepixel_read: 18147840 pix, 4976226 us, 3646908 pix/s sequential_vert_singlepixel_write: 100661760 pix, 4993164 us, 20159914 pix/s sequential_line_read: 285143040 pix, 4917267 us, 57988114 pix/s sequential_line_write: 876710400 pix, 5012146 us, 174917171 pix/s nonsequential_singlepixel_write: 17625600 pix, 4977967 us, 3540722 pix/s nonsequential_singlepixel_read: 9661440 pix, 4944885 us, 1953825 pix/s These also show quite a bit of improvement in some read cases. Interestingly some of the write cases are also faster. Reading pixels vertically is slower with vram_cache. I guess this is because the cache causes some overhead, and we always miss the cache so the caching is just wasted time. I would've also presumed the difference in sequential_line_write would be bigger. write-through is effectively no-cache for writes, right? If the user of the fb just writes to the fb and vram_cache=y, it means that the cache is filled with pixel data that is never used, thus lowering the performance of all other programs? I have to say I don't know much of the cpu caches, but the read speed improvements are very big, so I think this is definitely interesting patch. So if you get the first patch accepted I see no problem with adding this to omapfb as an optional feature. However, vram_cache is not a very good name for the option. vram_writethrough, or something? Did you test this with VRFB (omap3) or TILER (omap4)? I wonder how those are affected. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH] ARM: OMAP: PM: Lock clocks list while generating summary
On Fri, 18 May 2012, Nishanth Menon wrote: From: Todd Poynor toddpoy...@google.com commit a53025724052b2b1edbc982a4a248784638f563d (OMAP: Add debugfs node to show the summary of all clocks) Introduced clock summary, however, we are interested in seeing snapshot of the clock state, not in dynamically changing clock configurations as the data provided by clock summary will then be useless for debugging configuration issues. So, hold the common lock when dumping the clock summary. Cc: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org [n...@ti.com: added commit message] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Todd Poynor toddpoy...@google.com Thanks, queued for 3.5-rc. - 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] ARM: OMAP3+: dpll: optimize noncore dpll locking logic
Hi Nishanth
On Fri, 18 May 2012, Nishanth Menon wrote:
From: Vikram Pandita vikram.pand...@ti.com
If the dpll is already locked, code can be optimized
to return much earlier than doing redundent set of lock mode
and wait on idlest.
Cc: Tony Lindgren t...@atomide.com
Cc: Jon Hunter jon-hun...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Mike Turquette mturque...@ti.com
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Did you intend to add your Signed-off-by: to this patch?
Also, just FYI, no need to add the Cc: lines for the mailing lists in the
bottom of the patch description.
- Paul
---
arch/arm/mach-omap2/dpll3xxx.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index fc56745..3cfd7c4 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -135,11 +135,20 @@ static u16 _omap3_dpll_compute_freqsel(struct clk *clk,
u8 n)
*/
static int _omap3_noncore_dpll_lock(struct clk *clk)
{
+ const struct dpll_data *dd;
u8 ai;
- int r;
+ u8 state = 1;
+ int r = 0;
pr_debug(clock: locking DPLL %s\n, clk-name);
+ dd = clk-dpll_data;
+ state = __ffs(dd-idlest_mask);
+
+ /* Check if already locked */
+ if ((__raw_readl(dd-idlest_reg) dd-idlest_mask) == state)
+ goto done;
+
ai = omap3_dpll_autoidle_read(clk);
omap3_dpll_deny_idle(clk);
@@ -151,6 +160,7 @@ static int _omap3_noncore_dpll_lock(struct clk *clk)
if (ai)
omap3_dpll_allow_idle(clk);
+done:
return r;
}
--
1.7.9.5
- 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] omap2+: add drm device
On Thu, May 24, 2012 at 1:05 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Thu, 2012-05-24 at 00:27 -0600, Clark, Rob wrote:
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.
So why can't all that code be in a tiler library/driver?
Possibly the placement stuff could be in a library.. the
mmap/faulting stuff I think would be harder to split. With it split
out in a separate lib, it becomes logistically a bit more of a
headache to change APIs, etc. Basically it just makes more work and
is unnecessary.
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.
Well, at least currently omapfb and omapdrm work quite differently, if
I've understood right. Can we make a full omapfb layer on top of
omapdrm? With multiple framebuffers mapped to one or more overlays,
support for all the ioctls, etc?
Well, there is still room to add your own fb_ioctl() fxn, so I guess
in principle it should be possible to add whatever custom ioctls are
required.
Typically you have a single fbdev device for a single drm device,
although I suppose nothing prevents creating more. I'd probably want
to encourage users more towards using KMS directly for multi-display
cases because you have a lot more options/flexibility that way.
I guess we'd still need to have omapfb driver to keep the module
parameters and behavior the same. Can omapdrm be used from inside the
kernel by another driver?
Hmm, I'm not quite sure what you have in mind, but it sounds a bit
hacky.. I'd guess if you need 100% backwards compatibility even down
to kernel cmdline / module params, then you probably want to use
omapfb. But there isn't really need to add new features to omapfb in
that case.
Off the top of my head, I guess that 80-90% compatibility would
probably be reasonable to add to omapdrm's fbdev.. and that the last
10-20% would be too hacky/invasive to justify adding to omapdrm.
BR,
-R
Tomi
___
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: [PATCH] omap2+: add drm device
On Thu, May 24, 2012 at 1:21 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Thu, 2012-05-24 at 10:05 +0300, Tomi Valkeinen wrote:
On Thu, 2012-05-24 at 00:27 -0600, Clark, Rob wrote:
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.
So why can't all that code be in a tiler library/driver?
And I think we've discussed about this before, so sorry if I'm repeating
myself. I just find it odd that we are not able to create a nice
separate lib/driver for the tiler, which is a separate piece of HW that
multiple drivers might want to use.
but other drivers *can* use tiler, thanks to dmabuf.. I have omap4iss
v4l2 camera working w/ tiler buffers on my pandaboard, for example.
Maybe fbdev is an exception to the rule because it has no way for
userspace to pass it a buffer to use. But on the other hand it is a
legacy API so I'm not sure if it is worth loosing too much sleep over
that.
BR,
-R
Tomi
___
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
[PATCH] Fix OMAP4 boot regression
Fix a boot regression in existing kernels causing:
genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq XXX
caused by 1c6c6952 (genirq: Reject bogus threaded irq requests).
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
--
drivers/mmc/host/omap_hsmmc.c |2 +-
drivers/rtc/rtc-twl.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d76fc82..84016cb 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1962,7 +1962,7 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
ret = request_threaded_irq(mmc_slot(host).card_detect_irq,
NULL,
omap_hsmmc_detect,
- IRQF_TRIGGER_RISING |
IRQF_TRIGGER_FALLING,
+ IRQF_TRIGGER_RISING |
IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
mmc_hostname(mmc), host);
if (ret) {
dev_dbg(mmc_dev(host-mmc),
diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
index 258abea..c5d06fe 100644
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers/rtc/rtc-twl.c
@@ -510,7 +510,7 @@ static int __devinit twl_rtc_probe(struct platform_device
*pdev)
}
ret = request_threaded_irq(irq, NULL, twl_rtc_interrupt,
- IRQF_TRIGGER_RISING,
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT,
dev_name(rtc-dev), rtc);
if (ret 0) {
dev_err(pdev-dev, IRQ is not free.\n);
--
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] remoteproc: block premature rproc booting
On 5/22/2012 4:51 AM, Ohad Ben-Cohen wrote: When an rproc instance is registered, remoteproc asynchronously loads its firmware in order to tell which vdevs it supports. Later on those vdevs are registered, and when probed, their drivers usually trigger powering on of the remote processor. OTOH, non-standard scenarios might involve early invocation of rproc_boot even before the asynchronous fw loading has completed. We're not sure we really want to support those scenarios, but right now we do (e.g. via rproc_get_by_name), so let's simply fix this race by blocking those premature rproc_boot() flows until the async fw loading is completed. Reported-and-tested-by: Sjur Brandeland sjur.brandel...@stericsson.com Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- drivers/remoteproc/remoteproc_core.c | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c index 40e2b2d..464ea4f 100644 --- a/drivers/remoteproc/remoteproc_core.c +++ b/drivers/remoteproc/remoteproc_core.c @@ -1141,6 +1141,18 @@ int rproc_boot(struct rproc *rproc) dev = rproc-dev; + /* + * if asynchronoush fw loading is underway, wait up to 65 secs + * (just a bit more than the firmware request's timeout) + */ + ret = wait_for_completion_interruptible_timeout( + rproc-firmware_loading_complete, + msecs_to_jiffies(65000)); The request_firmware timeout is defaulted to 60 seconds but not necessarily 60 if the user has changed the timeout in sysfs. Why does this need to be a timeout at all? Presumably request_firmware_nowait() in rproc_register() will timeout and complete the firmware_loading_complete completion variable. Would it suffice to have some new rproc-state like RPROC_UNKNOWN that we set in rproc_register() before adding it to the list of rprocs? If we find the firmware then we set it to RPROC_READY or RPROC_REGISTERED? Then we wait_for_completion() and check the state, failing if it's still in the unknown state. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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] Fix OMAP4 boot regression
On Thu, May 24, 2012 at 2:34 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Fix a boot regression in existing kernels causing: genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq XXX caused by 1c6c6952 (genirq: Reject bogus threaded irq requests). Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk -- drivers/mmc/host/omap_hsmmc.c | 2 +- Thanks Russell. The omap_hsmmc part of the change was already posted [1] and queued up in mmc-next. Regards, Venkat. [1] http://www.spinics.net/lists/linux-omap/msg70496.html drivers/rtc/rtc-twl.c | 2 +- 2 files changed, 2 insertions(+), 2 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
Re: [PATCH] omap2+: add drm device
On Thu, 2012-05-24 at 02:35 -0600, Rob Clark wrote:
On Thu, May 24, 2012 at 1:05 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Thu, 2012-05-24 at 00:27 -0600, Clark, Rob wrote:
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.
So why can't all that code be in a tiler library/driver?
Possibly the placement stuff could be in a library.. the
mmap/faulting stuff I think would be harder to split. With it split
out in a separate lib, it becomes logistically a bit more of a
headache to change APIs, etc. Basically it just makes more work and
is unnecessary.
Unnecessary for you, but maybe not for those who want to use omapfb.
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.
Well, at least currently omapfb and omapdrm work quite differently, if
I've understood right. Can we make a full omapfb layer on top of
omapdrm? With multiple framebuffers mapped to one or more overlays,
support for all the ioctls, etc?
Well, there is still room to add your own fb_ioctl() fxn, so I guess
in principle it should be possible to add whatever custom ioctls are
required.
Typically you have a single fbdev device for a single drm device,
although I suppose nothing prevents creating more. I'd probably want
to encourage users more towards using KMS directly for multi-display
cases because you have a lot more options/flexibility that way.
Sure, but we can't force people to use omapdrm instead of omapfb. And
omapfb is not going to disappear. So obviously we should recommend using
omapdrm, but on the other hand, I don't see any problem in adding new
features to omapfb if they are easily implemented (using, for example, a
separate tiler driver).
I guess we'd still need to have omapfb driver to keep the module
parameters and behavior the same. Can omapdrm be used from inside the
kernel by another driver?
Hmm, I'm not quite sure what you have in mind, but it sounds a bit
hacky.. I'd guess if you need 100% backwards compatibility even down
to kernel cmdline / module params, then you probably want to use
omapfb. But there isn't really need to add new features to omapfb in
that case.
I was thinking of making omapfb use omapdrm, instead of omapdss. I mean,
not planning to do that, just wondering if that would be possible.
Off the top of my head, I guess that 80-90% compatibility would
probably be reasonable to add to omapdrm's fbdev.. and that the last
10-20% would be too hacky/invasive to justify adding to omapdrm.
I think it should be 99.9% - 100% or nothing. If it's only 80-90%
compatible, then it's not compatible =).
Tomi
signature.asc
Description: This is a digitally signed message part
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
On Wed, 2012-05-16 at 12:09 +0200, Cousson, Benoit wrote: Hi Tomi, On 5/16/2012 11:08 AM, Tomi Valkeinen wrote: Disabling DPLL3 autoidle fixes the problem. Disabling DPLL4 autoidle doesn't affect the problem. The issues your are facing seems to be the well known DSS low power refresh mode we've been trying to use since OMAP2 :-). Hmm, so are you saying no one has managed to get fifomerge and autoidle working reliably? If so, no point for me to even try it =). If so, I wonder which is better to have: fifomerge or autoidle... I also suspect that this could be just a plain DSS bug. The default FIFO low/high thresholds are 960/1023 bytes (i.e. DSS starts refilling the FIFO when there are 960 or less bytes in the fifo, and stops at 1023. The fifo is 1024 bytes). The values are calculated with fifo_size - burst_size and fifo_size - 1. We are now using FIFO merge features, which combines multiple fifos into one when possible, making the fifo size 1024*3 = 3072. Using the same low threshold and increasing the high threshold to 960/3071 works fine. Changing the high threshold to 3008 causes underflows. Increasing the low threshold to ~1600 makes DSS work again. That's weird, in theory what should matter is only the diff between the high and low. Well the low value should be as high as possible as well to support the wakeup latency. Yep. That makes me think there's some kind of problem with DSS accessing the memory with particular fifo thresholds. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH] ARM: OMAP3+: dpll: optimize noncore dpll locking logic
On Thu, May 24, 2012 at 2:49 AM, Paul Walmsley p...@pwsan.com wrote: Hi Nishanth On Fri, 18 May 2012, Nishanth Menon wrote: From: Vikram Pandita vikram.pand...@ti.com If the dpll is already locked, code can be optimized to return much earlier than doing redundent set of lock mode and wait on idlest. Cc: Tony Lindgren t...@atomide.com Cc: Jon Hunter jon-hun...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Mike Turquette mturque...@ti.com Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Signed-off-by: Vikram Pandita vikram.pand...@ti.com Did you intend to add your Signed-off-by: to this patch? Other than forwarding the patch over(since it seems to have slipped through the fingers of folks monitoring the product trees), I have had no other contributions to the patch. Also, just FYI, no need to add the Cc: lines for the mailing lists in the bottom of the patch description. Thanks. point taken. will take care of that in future patches. Regards, Nishanth Menon -- 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 1:01 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
+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?
Good point. I can clean that up.
Andy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3+: dpll: optimize noncore dpll locking logic
On Thu, 24 May 2012, Menon, Nishanth wrote: On Thu, May 24, 2012 at 2:49 AM, Paul Walmsley p...@pwsan.com wrote: On Fri, 18 May 2012, Nishanth Menon wrote: From: Vikram Pandita vikram.pand...@ti.com If the dpll is already locked, code can be optimized to return much earlier than doing redundent set of lock mode and wait on idlest. Cc: Tony Lindgren t...@atomide.com Cc: Jon Hunter jon-hun...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Mike Turquette mturque...@ti.com Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Signed-off-by: Vikram Pandita vikram.pand...@ti.com Did you intend to add your Signed-off-by: to this patch? Other than forwarding the patch over(since it seems to have slipped through the fingers of folks monitoring the product trees), I have had no other contributions to the patch. Okay. As I understand it, the maintainers above me would like Signed-off-by:s from the entire submission patch, even if there are no contributions to the patch itself. So please let me know if it's okay for me to add your S-o-b. - 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] ARM: OMAP3+: dpll: optimize noncore dpll locking logic
On Thu, May 24, 2012 at 9:57 AM, Paul Walmsley p...@pwsan.com wrote: Okay. As I understand it, the maintainers above me would like Signed-off-by:s from the entire submission patch, even if there are no contributions to the patch itself. So please let me know if it's okay for me to add your S-o-b. Thanks. ok with me :) Regards, Nishanth Menon -- 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 7:13 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Thu, 2012-05-24 at 02:44 -0600, Rob Clark wrote: but other drivers *can* use tiler, thanks to dmabuf.. I have omap4iss v4l2 camera working w/ tiler buffers on my pandaboard, for example. Maybe fbdev is an exception to the rule because it has no way for userspace to pass it a buffer to use. But on the other hand it is a legacy API so I'm not sure if it is worth loosing too much sleep over that. I'm not that familiar with dmabuf, but are you saying it's not possible for a kernel driver to request the buffers? They _must_ come from the userspace? Anyway, even if it would be possible, if the tiler is a part of omapdrm we need omapdrm to get and use the tiler buffers. And we can't have omapdrm running when using omapfb, because they both use omapdss. And that is a good point. The DSS is kind of a sticking point to anyone having to enable DRM to get Tiler. However, omapfb doesn't currently utilize DMM/Tiler features. Can't we defer generalizing until there is a requirement for it? Andy -- 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, 2012-05-24 at 10:09 -0500, Gross, Andy wrote: On Thu, May 24, 2012 at 7:13 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Thu, 2012-05-24 at 02:44 -0600, Rob Clark wrote: but other drivers *can* use tiler, thanks to dmabuf.. I have omap4iss v4l2 camera working w/ tiler buffers on my pandaboard, for example. Maybe fbdev is an exception to the rule because it has no way for userspace to pass it a buffer to use. But on the other hand it is a legacy API so I'm not sure if it is worth loosing too much sleep over that. I'm not that familiar with dmabuf, but are you saying it's not possible for a kernel driver to request the buffers? They _must_ come from the userspace? Anyway, even if it would be possible, if the tiler is a part of omapdrm we need omapdrm to get and use the tiler buffers. And we can't have omapdrm running when using omapfb, because they both use omapdss. And that is a good point. The DSS is kind of a sticking point to anyone having to enable DRM to get Tiler. However, omapfb doesn't currently utilize DMM/Tiler features. Can't we defer generalizing until there is a requirement for it? Sure. I just brought it up because it'd be nice and it'd be better architecturally. However, as I said, I'm not familiar with the related problems, so I take your word that it's not simple =). Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/2] OMAP: mailbox initial device tree support
On 5/2/2012 7:42 AM, Bedia, Vaibhav wrote: Hi Omar, On Tue, May 01, 2012 at 23:17:38, Omar Ramirez Luna wrote: To allow mailbox driver to function with device tree. Tested in OMAP4 and OMAP3. OMAP2 untested. I think the mailbox code needs a cleanup similar to what you had proposed earlier [1] before the device tree support is added. We probably need to decide whether the number of mailbox sub-modules should be part of hwmod attribute or come from device tree. IMO the static allocation of the mailboxes is better suited in the device-tree data. Ideally yes, but that assumes we are supporting only DT boot method, which is still not the case today. That being said, the driver might still be able to leverage DT if available already. This can be done later as well. Omar, That's up to you. 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
Re: [PATCH 2/2] arm/dts: OMAP2+: Add mailbox nodes
On 5/1/2012 7:47 PM, Omar Ramirez Luna wrote:
Add nodes for mailbox DT, to interface with hwmods.
Signed-off-by: Omar Ramirez Lunaomar.l...@linaro.org
Acked-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/boot/dts/omap2.dtsi |5 +
arch/arm/boot/dts/omap3.dtsi |5 +
arch/arm/boot/dts/omap4.dtsi |5 +
3 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index f2ab4ea..2175cc3 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -46,6 +46,11 @@
#interrupt-cells =1;
};
+ mailbox: mailbox@48094000 {
+ compatible = ti,omap2-mailbox;
+ ti,hwmods = mailbox;
+ };
+
uart1: serial@4806a000 {
compatible = ti,omap2-uart;
ti,hwmods = uart1;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index c612135..540f6d6 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -69,6 +69,11 @@
reg =0x4820 0x1000;
};
+ mailbox: mailbox@48094000 {
+ compatible = ti,omap3-mailbox;
+ ti,hwmods = mailbox;
+ };
+
uart1: serial@4806a000 {
compatible = ti,omap3-uart;
ti,hwmods = uart1;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 3d35559..84f27dd 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -104,6 +104,11 @@
0x48240100 0x0100;
};
+ mailbox: mailbox@4a0f4000 {
+ compatible = ti,omap4-mailbox;
+ ti,hwmods = mailbox;
+ };
+
uart1: serial@4806a000 {
compatible = ti,omap4-uart;
ti,hwmods = uart1;
--
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.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
On Wed, 16 May 2012, Tomi Valkeinen wrote: JFYI, I also tested changing DISPC's SYSCONFIG:CLOCKACTIVITY, which, to me, sounds a bit related to dpll autoidle. By default it's 0, interface and functional clocks can be switched off. I tested the three other values, but none of them had any effect. As I understand it (which could very well be mistaken), the CLOCKACTIVITY bits are only useful in situations where we'd like to allow the interconnect to idle, but keep the functional clock of the IP block (or subsystem) running. Right now, we control an IP block's interface clock and functional clock together, so CLOCKACTIVITY should probably always be 0. But for drivers that want to do more fine-grained clock control, or if we create some notion of an autonomous IP block in our integration layer for devices that can function without its interconnect, it might be worth exploring whether it is worthwhile to change those bits. - 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
[PATCH] staging: omapdrm: Fix error paths during dmm init
Failures during the dmm probe can cause the kernel to crash. Moved
the spinlock to a global and moved list initializations immediately
after the allocation of the dmm private structure.
Signed-off-by: Andy Gross andy.gr...@ti.com
---
drivers/staging/omapdrm/omap_dmm_priv.h |1 -
drivers/staging/omapdrm/omap_dmm_tiler.c | 44 -
2 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_dmm_priv.h
b/drivers/staging/omapdrm/omap_dmm_priv.h
index 2f529ab..08b22e9 100644
--- a/drivers/staging/omapdrm/omap_dmm_priv.h
+++ b/drivers/staging/omapdrm/omap_dmm_priv.h
@@ -181,7 +181,6 @@ struct dmm {
/* allocation list and lock */
struct list_head alloc_head;
- spinlock_t list_lock;
};
#endif
diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c
b/drivers/staging/omapdrm/omap_dmm_tiler.c
index 1ecb6a7..3bc715d 100644
--- a/drivers/staging/omapdrm/omap_dmm_tiler.c
+++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
@@ -40,6 +40,9 @@
static struct tcm *containers[TILFMT_NFORMATS];
static struct dmm *omap_dmm;
+/* global spinlock for protecting lists */
+static DEFINE_SPINLOCK(list_lock);
+
/* Geometry table */
#define GEOM(xshift, yshift, bytes_per_pixel) { \
.x_shft = (xshift), \
@@ -147,13 +150,13 @@ static struct dmm_txn *dmm_txn_init(struct dmm *dmm,
struct tcm *tcm)
down(dmm-engine_sem);
/* grab an idle engine */
- spin_lock(dmm-list_lock);
+ spin_lock(list_lock);
if (!list_empty(dmm-idle_head)) {
engine = list_entry(dmm-idle_head.next, struct refill_engine,
idle_node);
list_del(engine-idle_node);
}
- spin_unlock(dmm-list_lock);
+ spin_unlock(list_lock);
BUG_ON(!engine);
@@ -256,9 +259,9 @@ static int dmm_txn_commit(struct dmm_txn *txn, bool wait)
}
cleanup:
- spin_lock(dmm-list_lock);
+ spin_lock(list_lock);
list_add(engine-idle_node, dmm-idle_head);
- spin_unlock(dmm-list_lock);
+ spin_unlock(list_lock);
up(omap_dmm-engine_sem);
return ret;
@@ -351,9 +354,9 @@ struct tiler_block *tiler_reserve_2d(enum tiler_fmt fmt,
uint16_t w,
}
/* add to allocation list */
- spin_lock(omap_dmm-list_lock);
+ spin_lock(list_lock);
list_add(block-alloc_node, omap_dmm-alloc_head);
- spin_unlock(omap_dmm-list_lock);
+ spin_unlock(list_lock);
return block;
}
@@ -374,9 +377,9 @@ struct tiler_block *tiler_reserve_1d(size_t size)
return 0;
}
- spin_lock(omap_dmm-list_lock);
+ spin_lock(list_lock);
list_add(block-alloc_node, omap_dmm-alloc_head);
- spin_unlock(omap_dmm-list_lock);
+ spin_unlock(list_lock);
return block;
}
@@ -389,9 +392,9 @@ int tiler_release(struct tiler_block *block)
if (block-area.tcm)
dev_err(omap_dmm-dev, failed to release block\n);
- spin_lock(omap_dmm-list_lock);
+ spin_lock(list_lock);
list_del(block-alloc_node);
- spin_unlock(omap_dmm-list_lock);
+ spin_unlock(list_lock);
kfree(block);
return ret;
@@ -479,13 +482,13 @@ static int omap_dmm_remove(struct platform_device *dev)
if (omap_dmm) {
/* free all area regions */
- spin_lock(omap_dmm-list_lock);
+ spin_lock(list_lock);
list_for_each_entry_safe(block, _block, omap_dmm-alloc_head,
alloc_node) {
list_del(block-alloc_node);
kfree(block);
}
- spin_unlock(omap_dmm-list_lock);
+ spin_unlock(list_lock);
for (i = 0; i omap_dmm-num_lut; i++)
if (omap_dmm-tcm omap_dmm-tcm[i])
@@ -503,7 +506,7 @@ static int omap_dmm_remove(struct platform_device *dev)
vfree(omap_dmm-lut);
- if (omap_dmm-irq != -1)
+ if (omap_dmm-irq 0)
free_irq(omap_dmm-irq, omap_dmm);
iounmap(omap_dmm-base);
@@ -527,6 +530,10 @@ static int omap_dmm_probe(struct platform_device *dev)
goto fail;
}
+ /* initialize lists */
+ INIT_LIST_HEAD(omap_dmm-alloc_head);
+ INIT_LIST_HEAD(omap_dmm-idle_head);
+
/* lookup hwmod data - base address and irq */
mem = platform_get_resource(dev, IORESOURCE_MEM, 0);
if (!mem) {
@@ -629,7 +636,6 @@ static int omap_dmm_probe(struct platform_device *dev)
}
sema_init(omap_dmm-engine_sem, omap_dmm-num_engines);
- INIT_LIST_HEAD(omap_dmm-idle_head);
for (i = 0; i omap_dmm-num_engines; i++) {
omap_dmm-engines[i].id = i;
omap_dmm-engines[i].dmm = omap_dmm;
@@ -672,9 +678,6 @@ static int
[PATCH] staging: omapdrm: fix crash when freeing bad fb
During unload, don't cleanup the framebuffer if it is not valid.
Signed-off-by: Andy Gross andy.gr...@ti.com
---
drivers/staging/omapdrm/omap_fbdev.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_fbdev.c
b/drivers/staging/omapdrm/omap_fbdev.c
index 11acd4c..8c6ed3b 100644
--- a/drivers/staging/omapdrm/omap_fbdev.c
+++ b/drivers/staging/omapdrm/omap_fbdev.c
@@ -208,7 +208,8 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
*/
ret = omap_gem_get_paddr(fbdev-bo, paddr, true);
if (ret) {
- dev_err(dev-dev, could not map (paddr)!\n);
+ dev_err(dev-dev,
+ could not map (paddr)! Skipping framebuffer alloc\n);
ret = -ENOMEM;
goto fail;
}
@@ -388,8 +389,11 @@ void omap_fbdev_free(struct drm_device *dev)
fbi = helper-fbdev;
- unregister_framebuffer(fbi);
- framebuffer_release(fbi);
+ /* only cleanup framebuffer if it is present */
+ if (fbi) {
+ unregister_framebuffer(fbi);
+ framebuffer_release(fbi);
+ }
drm_fb_helper_fini(helper);
--
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
Re: MFD USB host: prevents CORE retention in idle
Munegowda, Keshava keshava_mgo...@ti.com writes:
On Thu, May 24, 2012 at 5:55 AM, Kevin Hilman khil...@ti.com wrote:
On 05/23/2012 05:01 PM, Kevin Hilman wrote:
Hi Keshava,
Using current l-o master, I noticed that CORE was not hitting retention
in idle on my 3530/Overo. CORE hits retention on suspend just fine.
Debugging this, I found that usbtll_fck was still enabled during idle,
thus preventing CORE from hitting retention.
To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config) and
was then started seeing CORE hit retention in idle again.
I have nothing plugged into the USB host port on this board, so I
would've expected that runtime PM would've kicked in and shutdown this
clock.
Any ideas what's going on here? Is this expected behavior?
If it helps, attached is a bootlog after enabling debug for
mfd/omap-usb-host.c as well. Notice there's a couple of clock-related
warnings from this driver as well. Not sure if they're relevant:
usbhs_omap: alias fck already exists
usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22
these clocks were specific to omap4 and it should not cause any
problem to omap3 boards.
OK, they seem unrelated to this CORE retention problem, but the warnings
should still be understood and fixed.
I will try to reproduce this on 3430 sdp to explore further.
Thanks for looking. Note that I only saw this problem on my 3530
platforms (Overo, OMAP3EVM.) My 3430/n900 doesn't support USBHS host
AFAICT, so didn't test there.
FYI, in order to hit core retention, there's another bug in mainline
where the counter_32k IP also prevents retention. You'll need the hack
below[1] (on top of l-o master) to workaround this problem (real patch
with description will be coming soon.)
Also, you'll likely need the UART mux patch from Govindraj[2]. Without
this, UARTs in CORE may have runtime PM disabled, and thus also prevent
CORE from hitting retention.
Kevin
[1]
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 840929b..42eb39d 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -292,6 +292,7 @@ static int __init omap2_sync32k_clocksource_init(void)
__func__, ret);
return ret;
}
+ omap_hwmod_set_slave_idlemode(oh, SIDLE_FORCE);
ret = omap_init_clocksource_32k(vbase);
if (ret) {
[2] http://marc.info/?l=linux-omapm=133672962809100w=2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
J, KEERTHY j-keer...@ti.com writes: On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY j-keer...@ti.com wrote: On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman khil...@ti.com wrote: Rafael, Keerthy j-keer...@ti.com writes: From: J Keerthy j-keer...@ti.com AVS(Adaptive Voltage Scaling) is a power management technique which controls the operating voltage of a device in order to optimize (i.e. reduce) its power consumption. The voltage is adapted depending on static factors (chip manufacturing process) and dynamic factors (temperature depending performance). The TI AVS solution is named Smartreflex. To that end, create the AVS driver in drivers/power/avs and move the OMAP SmartReflex code to the new directory. The class driver is still retained in the mach-omap2 directory. How should we handle this for upstream? It does a bunch of cleanup under arch/arm then does the move to drivers/power the end. To avoid conflicts with other OMAP core changes, I would suggest we take this through the OMAP tree. With your ack, I'd be glad to take it. Hello Rafael, A gentle ping on this series. Hi Greg, This series has Kevin's comments incorporated. Kevin, Can i have your Ack for this series? Well, as mentioned above, I'm waiting for Rafael's ack, then I will merge it. Because of all the arch/arm/mach-omap2/* changes, I would like to merge this via the OMAP tree to avoid conflicts with other stuff we have changing in arch/arm/mach-omap2/* 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
usage of sparse or other trick for improved type safety
Hi Tony, I am hoping to solicit an opinion from you for OMAP frameworks in general. In some recent review there was some debate about how it was good practice to form parameters in a way which didn't get misused. Nishanth was having some experience where end users doing custom ports made some hard to find mistakes. I was wondering if it is useful to create a standard or it's a waste of time. The knee-jerk reaction to comment is to consider annotations for driver users of api's, then inside the framework trust internals to do the right thing. Complexity divide between a driver and some frameworks might be similar to user-vs-kernel. I think example in this case was IVA and other external subsystems commonly got away using stale definitions when managing their own power domains. Example seemed a little pedantic but it is true that this has broken several times through migrations. At customer fan out it causes a lot of effort which could have been avoided. Just last week someone was trying to caste away an iomem annotation from external driver based on warning. For me warning was a good thing and forced discussion. I do recall you pushing what ARM and Linux tress did in this area back into OMAP years back. Question is if it's worth internalizing more for our ever growing frameworks. Thanks, Richard W. -- 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 error paths during dmm init
On Thu, May 24, 2012 at 10:43 AM, Andy Gross andy.gr...@ti.com wrote:
Failures during the dmm probe can cause the kernel to crash. Moved
the spinlock to a global and moved list initializations immediately
after the allocation of the dmm private structure.
Signed-off-by: Andy Gross andy.gr...@ti.com
Reviewed-by: Rob Clark rob.cl...@linaro.org
---
drivers/staging/omapdrm/omap_dmm_priv.h | 1 -
drivers/staging/omapdrm/omap_dmm_tiler.c | 44 -
2 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_dmm_priv.h
b/drivers/staging/omapdrm/omap_dmm_priv.h
index 2f529ab..08b22e9 100644
--- a/drivers/staging/omapdrm/omap_dmm_priv.h
+++ b/drivers/staging/omapdrm/omap_dmm_priv.h
@@ -181,7 +181,6 @@ struct dmm {
/* allocation list and lock */
struct list_head alloc_head;
- spinlock_t list_lock;
};
#endif
diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c
b/drivers/staging/omapdrm/omap_dmm_tiler.c
index 1ecb6a7..3bc715d 100644
--- a/drivers/staging/omapdrm/omap_dmm_tiler.c
+++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
@@ -40,6 +40,9 @@
static struct tcm *containers[TILFMT_NFORMATS];
static struct dmm *omap_dmm;
+/* global spinlock for protecting lists */
+static DEFINE_SPINLOCK(list_lock);
+
/* Geometry table */
#define GEOM(xshift, yshift, bytes_per_pixel) { \
.x_shft = (xshift), \
@@ -147,13 +150,13 @@ static struct dmm_txn *dmm_txn_init(struct dmm *dmm,
struct tcm *tcm)
down(dmm-engine_sem);
/* grab an idle engine */
- spin_lock(dmm-list_lock);
+ spin_lock(list_lock);
if (!list_empty(dmm-idle_head)) {
engine = list_entry(dmm-idle_head.next, struct refill_engine,
idle_node);
list_del(engine-idle_node);
}
- spin_unlock(dmm-list_lock);
+ spin_unlock(list_lock);
BUG_ON(!engine);
@@ -256,9 +259,9 @@ static int dmm_txn_commit(struct dmm_txn *txn, bool wait)
}
cleanup:
- spin_lock(dmm-list_lock);
+ spin_lock(list_lock);
list_add(engine-idle_node, dmm-idle_head);
- spin_unlock(dmm-list_lock);
+ spin_unlock(list_lock);
up(omap_dmm-engine_sem);
return ret;
@@ -351,9 +354,9 @@ struct tiler_block *tiler_reserve_2d(enum tiler_fmt fmt,
uint16_t w,
}
/* add to allocation list */
- spin_lock(omap_dmm-list_lock);
+ spin_lock(list_lock);
list_add(block-alloc_node, omap_dmm-alloc_head);
- spin_unlock(omap_dmm-list_lock);
+ spin_unlock(list_lock);
return block;
}
@@ -374,9 +377,9 @@ struct tiler_block *tiler_reserve_1d(size_t size)
return 0;
}
- spin_lock(omap_dmm-list_lock);
+ spin_lock(list_lock);
list_add(block-alloc_node, omap_dmm-alloc_head);
- spin_unlock(omap_dmm-list_lock);
+ spin_unlock(list_lock);
return block;
}
@@ -389,9 +392,9 @@ int tiler_release(struct tiler_block *block)
if (block-area.tcm)
dev_err(omap_dmm-dev, failed to release block\n);
- spin_lock(omap_dmm-list_lock);
+ spin_lock(list_lock);
list_del(block-alloc_node);
- spin_unlock(omap_dmm-list_lock);
+ spin_unlock(list_lock);
kfree(block);
return ret;
@@ -479,13 +482,13 @@ static int omap_dmm_remove(struct platform_device *dev)
if (omap_dmm) {
/* free all area regions */
- spin_lock(omap_dmm-list_lock);
+ spin_lock(list_lock);
list_for_each_entry_safe(block, _block, omap_dmm-alloc_head,
alloc_node) {
list_del(block-alloc_node);
kfree(block);
}
- spin_unlock(omap_dmm-list_lock);
+ spin_unlock(list_lock);
for (i = 0; i omap_dmm-num_lut; i++)
if (omap_dmm-tcm omap_dmm-tcm[i])
@@ -503,7 +506,7 @@ static int omap_dmm_remove(struct platform_device *dev)
vfree(omap_dmm-lut);
- if (omap_dmm-irq != -1)
+ if (omap_dmm-irq 0)
free_irq(omap_dmm-irq, omap_dmm);
iounmap(omap_dmm-base);
@@ -527,6 +530,10 @@ static int omap_dmm_probe(struct platform_device *dev)
goto fail;
}
+ /* initialize lists */
+ INIT_LIST_HEAD(omap_dmm-alloc_head);
+ INIT_LIST_HEAD(omap_dmm-idle_head);
+
/* lookup hwmod data - base address and irq */
mem = platform_get_resource(dev, IORESOURCE_MEM, 0);
if (!mem) {
@@ -629,7 +636,6 @@ static int omap_dmm_probe(struct platform_device *dev)
}
sema_init(omap_dmm-engine_sem, omap_dmm-num_engines);
- INIT_LIST_HEAD(omap_dmm-idle_head);
for (i = 0;
Re: [PATCH] staging: omapdrm: fix crash when freeing bad fb
On Thu, May 24, 2012 at 10:44 AM, Andy Gross andy.gr...@ti.com wrote:
During unload, don't cleanup the framebuffer if it is not valid.
Signed-off-by: Andy Gross andy.gr...@ti.com
Reviewed-by: Rob Clark rob.cl...@linaro.org
---
drivers/staging/omapdrm/omap_fbdev.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_fbdev.c
b/drivers/staging/omapdrm/omap_fbdev.c
index 11acd4c..8c6ed3b 100644
--- a/drivers/staging/omapdrm/omap_fbdev.c
+++ b/drivers/staging/omapdrm/omap_fbdev.c
@@ -208,7 +208,8 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
*/
ret = omap_gem_get_paddr(fbdev-bo, paddr, true);
if (ret) {
- dev_err(dev-dev, could not map (paddr)!\n);
+ dev_err(dev-dev,
+ could not map (paddr)! Skipping framebuffer
alloc\n);
ret = -ENOMEM;
goto fail;
}
@@ -388,8 +389,11 @@ void omap_fbdev_free(struct drm_device *dev)
fbi = helper-fbdev;
- unregister_framebuffer(fbi);
- framebuffer_release(fbi);
+ /* only cleanup framebuffer if it is present */
+ if (fbi) {
+ unregister_framebuffer(fbi);
+ framebuffer_release(fbi);
+ }
drm_fb_helper_fini(helper);
--
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
--
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 crash when freeing bad fb
On Thu, May 24, 2012 at 10:44 AM, Andy Gross andy.gr...@ti.com wrote:
During unload, don't cleanup the framebuffer if it is not valid.
Signed-off-by: Andy Gross andy.gr...@ti.com
Reviewed-by: Rob Clark rob.cl...@linaro.org
---
drivers/staging/omapdrm/omap_fbdev.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_fbdev.c
b/drivers/staging/omapdrm/omap_fbdev.c
index 11acd4c..8c6ed3b 100644
--- a/drivers/staging/omapdrm/omap_fbdev.c
+++ b/drivers/staging/omapdrm/omap_fbdev.c
@@ -208,7 +208,8 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
*/
ret = omap_gem_get_paddr(fbdev-bo, paddr, true);
if (ret) {
- dev_err(dev-dev, could not map (paddr)!\n);
+ dev_err(dev-dev,
+ could not map (paddr)! Skipping framebuffer
alloc\n);
ret = -ENOMEM;
goto fail;
}
@@ -388,8 +389,11 @@ void omap_fbdev_free(struct drm_device *dev)
fbi = helper-fbdev;
- unregister_framebuffer(fbi);
- framebuffer_release(fbi);
+ /* only cleanup framebuffer if it is present */
+ if (fbi) {
+ unregister_framebuffer(fbi);
+ framebuffer_release(fbi);
+ }
drm_fb_helper_fini(helper);
--
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
--
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 0/4] omap legacy full speed usb cleanup for v3.6
On Mon, 21 May 2012, Tony Lindgren wrote: This series removes the old legacy fulls speed support for omap2 as it's pretty much only used for omap1 only. For omap2, only n8x0 seems to have active development, and that has the external high speed tusb chip instead. Just FYI, full speed host USB exists on OMAP4. It's in section 23.13 of the TRM and we have a hwmod for it. No idea if anyone is actually using it. - 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] OMAP4+: hwmod: fix issue causing IPs not going back to Smart-Standby
On Fri, 20 Apr 2012, Djamil Elaidi wrote: If an IP is configured in Smart-Standby-Wakeup, when disabling wakeup feature the IP will not go back to Smart-Standby, but will remain in Smart-Standby-Wakeup. Signed-off-by: Djamil Elaidi d-ela...@ti.com Thanks, queued for 3.5-rc fixes. - 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] remoteproc: block premature rproc booting
Hi Stephen, On Thu, May 24, 2012 at 12:15 PM, Stephen Boyd sb...@codeaurora.org wrote: The request_firmware timeout is defaulted to 60 seconds but not necessarily 60 if the user has changed the timeout in sysfs. .. Why does this need to be a timeout at all? Presumably request_firmware_nowait() in rproc_register() will timeout and complete the firmware_loading_complete completion variable. Very good points, thanks for pointing them out! Would it suffice to have some new rproc-state like RPROC_UNKNOWN that we set in rproc_register() before adding it to the list of rprocs? If we find the firmware then we set it to RPROC_READY or RPROC_REGISTERED? Then we wait_for_completion() and check the state, failing if it's still in the unknown state. That makes me think - what if we'll add the rproc to the list only after we find the firmware? This way we avoid this race completely. Speaking of which, I was wondering whether you guys have some free cycles to try remoteproc out. The main reason we kept the get/put interface was to make it easier for you guys to adopt it, but I've been re-thinking lately whether we really want that interface. It's a problematic interface with non-negligible maintenance burden, and the code will be greatly simplified without it. Even if you guys won't be adopting virtio (of any other virtio-over-smd variant) - do you think you'll be able to adopt a similar model with which remoteproc registers, according to the fw capabilities, the relevant devices which then get bound to the relevant higher-level drivers (virtio drivers, smd drivers, etc..) ? That way these devices can point to the rproc context and we don't need any get_by_name interface. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data
On Thu, May 24, 2012 at 13:01:11, Paul Walmsley wrote: Hi On Wed, 23 May 2012, Hiremath, Vaibhav wrote: I believe register read/write to IP block is depends on only interface Clocks? Atleast in case of OMAP3, it was like that, right?? No, on OMAP3, most modules need both the interface clock enabled, and at least one of their functional clocks. For modules with multiple functional clocks like the OMAP3 USBHOST, we had to use trial and error to determine which functional clock was the main clock, since it wasn't documented. If we got it wrong, then register accesses to the module would result in an abort. Ok, thanks for the clarification. The AM33xx/OMAP4 behavior should be a little easier in this regard, though, since the MODULEMODE bits should just control everything for a given module, and that should be handled by the hwmod code. Nevertheless it is still good to specify a main_clk so we know how fast the module's registers are clocked and to locate the module in the power management hierarchy. Another issues is, I came across situation where, two modules fall into different clock domains but their functional clock is happened to be coming from same source/dpll-divider. So in order to satisfy clkdm match between them, I have kept nodes without enable_regs. Could you please provide an example? In case of AM33xx, clock architecture is, sysclk1 - L4_wakeup - wakeup domain modules sysclk1 - L4 HS - L4 HS domain modules sysclk1 - L4 LS - L4 LS domain modules and so on... Now with leaf node cleanup, we are moving upward in the clocktree, more close to dpll output, and is the issue related to clockdomain. So currently, I have mentioned same entry in both the places (especially for Peripherals/modules). I am planning to remove ocp_if/clk entry data for all modules.. Hmmm, could you explain this further? what if, module only has interface clock? Should it be present as main_clk or ocp_if.clk or both?? Example would be, TPCC, TPTC, smartreflex, etc... Well it definitely should be present as the ocp_if.clk. I personally think it would be good to list the same clock as the hwmod's main_clk too, but it's currently not strictly necessary. There are some examples in the omap_hwmod_44xx_data.c file, like omap44xx_mailbox_hwmod. omap44xx_mailbox_hwmod doesn't have main_clk exported in the hwmod_data, so I think I should also follow same thing, right? The cleaned clocktree (without common-clock fw) and hwmod code is ready, I just need to rebase against Kevin's hwmod cpu_is_xxx cleanup series (was pending in last version). This shouldn't impact anything to above clocktree and hwmod patch. You can access the code at - https://github.com/hvaibhav/am335x-linux am335x-upstream-staging Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data
On Thu, 24 May 2012, Hiremath, Vaibhav wrote: On Thu, May 24, 2012 at 13:01:11, Paul Walmsley wrote: On Wed, 23 May 2012, Hiremath, Vaibhav wrote: I came across situation where, two modules fall into different clock domains but their functional clock is happened to be coming from same source/dpll-divider. So in order to satisfy clkdm match between them, I have kept nodes without enable_regs. Could you please provide an example? In case of AM33xx, clock architecture is, sysclk1 - L4_wakeup - wakeup domain modules sysclk1 - L4 HS - L4 HS domain modules sysclk1 - L4 LS - L4 LS domain modules and so on... Now with leaf node cleanup, we are moving upward in the clocktree, more close to dpll output, and is the issue related to clockdomain. I don't really understand. Perhaps you could provide an example from one of the modules? Are you saying that you have a module that should be in a different clockdomain than the clockdomain of the module's main functional clock? So currently, I have mentioned same entry in both the places (especially for Peripherals/modules). I am planning to remove ocp_if/clk entry data for all modules.. Hmmm, could you explain this further? what if, module only has interface clock? Should it be present as main_clk or ocp_if.clk or both?? Example would be, TPCC, TPTC, smartreflex, etc... Well it definitely should be present as the ocp_if.clk. I personally think it would be good to list the same clock as the hwmod's main_clk too, but it's currently not strictly necessary. There are some examples in the omap_hwmod_44xx_data.c file, like omap44xx_mailbox_hwmod. omap44xx_mailbox_hwmod doesn't have main_clk exported in the hwmod_data, so I think I should also follow same thing, right? Well please start with specifying the main_clk for all IP blocks. It is potentially ambiguous not to specify it, so unless there is some problem with specifying it, I'd prefer to have them. You can access the code at - https://github.com/hvaibhav/am335x-linux am335x-upstream-staging I'll wait until it's posted to the lists. - 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: MFD USB host: prevents CORE retention in idle
Kevin Hilman khil...@ti.com writes: Munegowda, Keshava keshava_mgo...@ti.com writes: On Thu, May 24, 2012 at 5:55 AM, Kevin Hilman khil...@ti.com wrote: On 05/23/2012 05:01 PM, Kevin Hilman wrote: Hi Keshava, Using current l-o master, I noticed that CORE was not hitting retention in idle on my 3530/Overo. CORE hits retention on suspend just fine. Debugging this, I found that usbtll_fck was still enabled during idle, thus preventing CORE from hitting retention. To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config) and was then started seeing CORE hit retention in idle again. I have nothing plugged into the USB host port on this board, so I would've expected that runtime PM would've kicked in and shutdown this clock. Any ideas what's going on here? Is this expected behavior? If it helps, attached is a bootlog after enabling debug for mfd/omap-usb-host.c as well. Notice there's a couple of clock-related warnings from this driver as well. Not sure if they're relevant: usbhs_omap: alias fck already exists usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22 these clocks were specific to omap4 and it should not cause any problem to omap3 boards. OK, they seem unrelated to this CORE retention problem, but the warnings should still be understood and fixed. I will try to reproduce this on 3430 sdp to explore further. Thanks for looking. Note that I only saw this problem on my 3530 platforms (Overo, OMAP3EVM.) My 3430/n900 doesn't support USBHS host AFAICT, so didn't test there. After realizing that the same IP should exist on 3430/n900, I copied some board file support for USBHS host from overo into the n900 board file in order to test on 3430/n900. Problem exists on n900 too. 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: [linux-pm] [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
Menon, Nishanth n...@ti.com writes: On Wed, May 9, 2012 at 1:29 PM, Kevin Hilman khil...@ti.com wrote: Woodruff, Richard r-woodru...@ti.com writes: From: Hilman, Kevin Sent: Tuesday, May 08, 2012 5:17 PM A basic OMAP AVS driver has been in mainline for a long time, yet we have not seen support submitted for all of these features. 1.5/3.5 is a feature. And I'm still waiting for it to be submitted upstream. ABB is requirement for a production useable driver. Higher speed rated OMAP4 and all OMAP5 added these to be useable. ditto Yes this is effort. Point of mentioning is to raise awareness of need. I'm well aware of the need. Yet to be added feature has different meaning than functional gap. And both need to be submitted upstream. SR 1.5: http://marc.info/?l=linux-omapm=129933897910785w=2 ABB: http://marc.info/?l=linux-omapm=130939399209099w=2 I am not sure what you mean need to be submitted upstream? You're right. I should've said re-submitted and merged. Both have been submitted (and reviewed) but no follow up submissions after review, and thus they're still out of tree. Just tired of seeing things perpetually change without considering even how to handle features that are mandatory for SoC even with code posted upstream to show exactly what it takes.. I'm sorry, but this is not perpetual change. This driver has been upstream in its current (admittedly feature-limited) form for a long time, the only thing changing in $SUBJECT series is the location of the driver. Why all the fuss about the missing features now? I think you do mean merged upstream in this context. Correct. Frameworks always have limitations. The way they get extended/expanded etc. is by the submission/review/merging of support for new features/requirements. The process for that is the same as any feature in any part of the kernel. Evolution, not intelligent design[1]. All of that being said, I'm not sure why this thread was hijacked for this debate in the first place. The point of $SUBJECT series is simply to move and *existing* framework from arch/arm out to drivers. The only changes done are cleanups to make this move possible. I for one would welcome extending this framework to ensure it supports all the SoC features. I just don't want those features to be a prerequisite for this move from arch/arm to drivers. Please, let's get this moved to drivers, and then add support for the missing features. Thanks, Kevin [1] http://kerneltrap.org/Linux/Kernel_Evolution -- 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.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
cc Jean Hello Tomi, On Wed, 16 May 2012, Tomi Valkeinen wrote: I also suspect that this could be just a plain DSS bug. The default FIFO low/high thresholds are 960/1023 bytes (i.e. DSS starts refilling the FIFO when there are 960 or less bytes in the fifo, and stops at 1023. The fifo is 1024 bytes). The values are calculated with fifo_size - burst_size and fifo_size - 1. We are now using FIFO merge features, which combines multiple fifos into one when possible, making the fifo size 1024*3 = 3072. Using the same low threshold and increasing the high threshold to 960/3071 works fine. Changing the high threshold to 3008 causes underflows. Increasing the low threshold to ~1600 makes DSS work again. Just a few thoughts. In terms of the high threshold, it seems really strange to me that changing the high threshold would make such a difference. Naïvely, I'd assume that you'd want to set it as high as possible? I suppose in cases where the interconnect is congested, setting it lower might allow lower latency for other interconnect users, but I'd hope we don't have to worry much about that. So it doesn't seem to me that there would be any advantage to setting it lower than the maximum. Probably the low threshold is the more important parameter, from a PM perspective. If you know the FIFO's drain rate and the low threshold, it should be possible to calculate the maximum latency that the FIFO can tolerate to avoid an underflow. This could be used to specify a device PM QoS constraint to prevent the interconnect latency from exceeding that value. I'd guess the calculations would be something like this -- (I hope you can correct my relative ignorance of the DSS in the following estimates): Looking at mach-omap2/board-rx51-video.c, let's suppose that the FIFO drain rate would be 864 x 480 x 32 bits/second. Since the FIFO width is 32 bits, that's 864 x 480 = 414 780 FIFO entries/second, or (1 000 000 µs/s / 414 780 FIFO entries/s) = ~2.411 µs/FIFO entry. So if you need a low FIFO threshold at 960 entries, you could call the device PM QoS functions to set a wakeup latency constraint for the interconnect would be nothing greater than this: (2.411 µs/FIFO entry * 960 FIFO entries) = 2 314.96 µs (The reality is that it would need to be something less than this, to account for the time needed for the GFX DMA transfer to start supplying data, etc.) The ultimate goal, with Jean's device PM QoS patches, is that these constraints could change the DPLL autoidle settings or powerdomain states to ensure the constraint was met. He's got a page here: http://omappedia.org/wiki/Power_Management_Device_Latencies_Measurement (Unfortunately it's not clear what the DPLL autoidle modes and voltage scaling bits are set to for many of the estimates, and we also know that there are many software optimizations possible for our idle path.) We're still working on getting the OMAP device PM QoS patches merged, but the Linux core support is there, so you should be able to patch your drivers to use them -- see for example dev_pm_qos_add_request(). ... Similarly, for the low-power refresh case, if you know the GFX FIFO drain rate and the various latencies, it should be possible to estimate the minimum low threshold value needed in order to avoid a FIFO underflow. (By various latencies, I mean the DPLL relock latency, the GFX DMA latency between initiating a transfer and receiving the first result data, etc. Some of these latencies may be difficult to estimate accurately. But if the major sources of variation can be identified, such as DPLL relock time or GFX DMA FIFO refill time, I'd hope we can just use trial and error to find some worst-case constant for the rest.) The goal in this ase would be to allow DPLL3 to stay unlocked for as long as possible, to save energy. This would imply finding the lowest possible FIFO low threshold that doesn't generate underflows. Using the lowest possible low threshold should leave as much room as possible in the FIFO for data, and thus maximize the amount of time that DPLL3 can stay unlocked after the high threshold is reached. Since the DPLL relock latency figures are known from the TRM section 4.7.6.7 Latencies, we can estimate the DPLL's contribution to the low threshold setting. The DPLL relock latency depends on the DPLL's input rate and some DPLL settings, so it can vary. (We probably need a function for the interconnect device that can estimate the worst-case wakeup latency for the DSS to use, based on the rest of the system settings.) Let's reuse the 2.411 µs/FIFO entry estimate from above. For convenience, let's suppose that the DPLL relock latency from DPLL-OFF is 1.5 ms = 1500 µs. So we know that the number of FIFO slots needed simply to endure the DPLL relock process is CEIL(1500 µs/relock / 2.411 µs/FIFO entry) = CEIL(622.14 ...) = 623 FIFO entries/relock This of course doesn't
