Re: [PATCH] arm: platsmp: Allow secondary cpu hotplug with maxcpus=1

[Paul Mundt]

On Wed, Jun 29, 2011 at 11:31:39AM -0700, Stephen Boyd wrote:
 If an ARM system has multiple cpus in the same socket and the
 kernel is booted with maxcpus=1, secondary cpus are possible but
 not present due to how platform_smp_prepare_cpus() is called.
 Fix this by always calling platform_smp_prepare_cpus() as long as
 max_cpus is non-zero (0 means no SMP) to allow platform code to
 decide if any non-boot cpus are present in the system. Since
 all current platform code doesn't support physical hotplug we
 have a situation where possible == present and thus we can
 simply copy the possible map to the present map.
 
 With this patch it's possible to boot an ARM system with
 maxcpus=1 on the command line and then hotplug in secondary cpus
 via sysfs. This is more in line with how x86 works with maxcpus=1
 on the command line.
 
 Signed-off-by: Stephen Boyd sb...@codeaurora.org

Acked-by: Paul Mundt let...@linux-sh.org
--
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: [PATCHv2 20/28] OMAP: DSS2: Use PM runtime HWMOD support

[Paul Mundt]

On Thu, Jun 09, 2011 at 04:56:42PM +0300, Tomi Valkeinen wrote:
 +int dispc_runtime_get(void)
 +{
 + int r;
 +
 + DSSDBG(dispc_runtime_get\n);
 +
 + r = pm_runtime_get_sync(dispc.pdev-dev);
 + WARN_ON(r  0);
 + return r  0 ? r : 0;
 +}
 +
 +void dispc_runtime_put(void)
 +{
 + int r;
 +
 + DSSDBG(dispc_runtime_put\n);
 +
 + r = pm_runtime_put(dispc.pdev-dev);
 + WARN_ON(r  0);
  }
  
This seems a bit odd. Your runtime_get wrapper is explicitly synchronous
while your put wrapper is explicitly asynchronous, although these details
(if intentional) are not at all obvious from the wrapper naming. From
the use in the error paths and so on you will definitely need to be using
pm_runtime_put_sync() at least some of the time.

In the interest of avoiding confusion, I would in general just get rid of
these wrappers and use the pm_runtime calls openly, as you already do for
some of the other parts of the API. The runtime PM framework has pretty
verbose debugging already that goes well beyond what you presently have,
too.

You seem to have adopted this sync/async pattern for all of the users:

 +int dsi_runtime_get(struct platform_device *dsidev)
  {
 - if (enable)
 - dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK);
 - else
 - dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK);
 + int r;
 + struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
 +
 + DSSDBG(dsi_runtime_get\n);
 +
 + r = pm_runtime_get_sync(dsi-pdev-dev);
 + WARN_ON(r  0);
 + return r  0 ? r : 0;
 +}
 +
 +void dsi_runtime_put(struct platform_device *dsidev)
 +{
 + struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
 + int r;
 +
 + DSSDBG(dsi_runtime_put\n);
 +
 + r = pm_runtime_put(dsi-pdev-dev);
 + WARN_ON(r  0);
  }
  
Here.

 -void dss_clk_disable(enum dss_clock clks)
 -{
..
 - dss_clk_disable_no_ctx(clks);
 + r = pm_runtime_get_sync(dss.pdev-dev);
 + WARN_ON(r  0);
 + return r  0 ? r : 0;
  }
  
 -static void dss_clk_enable_all_no_ctx(void)
 +void dss_runtime_put(void)
  {
..
 + r = pm_runtime_put(dss.pdev-dev);
 + WARN_ON(r  0);
  }
  
And here.

 +static int hdmi_runtime_get(void)
 +{
 + int r;
 +
 + DSSDBG(hdmi_runtime_get\n);
 +
 + r = pm_runtime_get_sync(hdmi.pdev-dev);
 + WARN_ON(r  0);
 + return r  0 ? r : 0;
 +}
 +
 +static void hdmi_runtime_put(void)
 +{
 + int r;
 +
 + DSSDBG(hdmi_runtime_put\n);
 +
 + r = pm_runtime_put(hdmi.pdev-dev);
 + WARN_ON(r  0);
 +}
 +
And here.

 -static void rfbi_enable_clocks(bool enable)
 +static int rfbi_runtime_get(void)
  {
 - if (enable)
 - dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK);
 - else
 - dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK);
 + int r;
 +
 + DSSDBG(rfbi_runtime_get\n);
 +
 + r = pm_runtime_get_sync(rfbi.pdev-dev);
 + WARN_ON(r  0);
 + return r  0 ? r : 0;
 +}
 +
 +static void rfbi_runtime_put(void)
 +{
 + int r;
 +
 + DSSDBG(rfbi_runtime_put\n);
 +
 + r = pm_runtime_put(rfbi.pdev-dev);
 + WARN_ON(r  0);
  }
  
And here.

 +static int venc_runtime_get(void)
  {
 - if (enable) {
 - dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK | DSS_CLK_TVFCK);
 - if (dss_has_feature(FEAT_VENC_REQUIRES_TV_DAC_CLK))
 - dss_clk_enable(DSS_CLK_VIDFCK);
 - } else {
 - dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK | DSS_CLK_TVFCK);
 - if (dss_has_feature(FEAT_VENC_REQUIRES_TV_DAC_CLK))
 - dss_clk_disable(DSS_CLK_VIDFCK);
 - }
 + int r;
 +
 + DSSDBG(venc_runtime_get\n);
 +
 + r = pm_runtime_get_sync(venc.pdev-dev);
 + WARN_ON(r  0);
 + return r  0 ? r : 0;
 +}
 +
 +static void venc_runtime_put(void)
 +{
 + int r;
 +
 + DSSDBG(venc_runtime_put\n);
 +
 + r = pm_runtime_put(venc.pdev-dev);
 + WARN_ON(r  0);
  }
  
And here.
--
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: [GIT PULL] OMAP DSS updates for 2.6.40

[Paul Mundt]

On Mon, May 23, 2011 at 02:43:24PM +0300, Tomi Valkeinen wrote:
 Here are the OMAP Display Subsystem updates for 2.6.40.
 
 Most of the patches are OMAP4 related, either fixing the old code to
 allow us to implement new OMAP4 features, or implementing those new
 features. Other bigger changes are ULPS power management feature and
 moving the DSS header file from arch/arm/plat-omap/include to
 include/video.
 
Pulled and pushed out, thanks. There were a couple of conflicts, so you
may want to doublecheck to make sure nothing was inadvertently broken.
--
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: [GIT PULL] OMAP DSS fixes for 39 rc

[Paul Mundt]

On Mon, Apr 18, 2011 at 10:12:41AM +0300, Tomi Valkeinen wrote:
 Here are a few OMAP DSS fixes for the next rc.
 
Pulled and pushed out, thanks.
--
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/RFC 4/6] ARM: move SH-mobile runtime PM to arm/common for sharing with other platforms

[Paul Mundt]

On Wed, Apr 06, 2011 at 05:02:47PM -0700, Kevin Hilman wrote:
 There is really nothing SH-mobile specific about this runtime PM
 implementation.  Any platform wanting to implement runtime PM based on
 simple clock gating can use this implementation.
 
 Signed-off-by: Kevin Hilman khil...@ti.com

This observation is wholly architecture agnostic, so it's not clear that
keeping it in arch/arm/common is any better. It seems that this would be
better suited for drivers/base/power/ with a generic Kconfig symbol.
--
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/RFC 4/6] ARM: move SH-mobile runtime PM to arm/common for sharing with other platforms

[Paul Mundt]

On Thu, Apr 07, 2011 at 05:38:38PM -0700, Kevin Hilman wrote:
 Rafael J. Wysocki r...@sisk.pl writes:
  On Thursday, April 07, 2011, Kevin Hilman wrote:
  Paul Mundt let...@linux-sh.org writes:
   This observation is wholly architecture agnostic, so it's not clear that
   keeping it in arch/arm/common is any better. It seems that this would be
   better suited for drivers/base/power/ with a generic Kconfig symbol.
  
  Sounds fine to me.
 
  Well, what platforms is the clock framework available on?
 
 Well, the majority of implementations of linux/clk.h are certainly in
 ARM, but I know it's also implemented for SH, and a quick grep shows
 implementations in powerpc, mips and m68k also.
 
We also have CONFIG_HAVE_CLK that can be used as a dependency. In any
event, anything simply focusing on the clock bits can be completely
generic. On SH we still have these things lumped together with hwblk IDs,
but this is something we can likely transition off of with power domains.
--
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 06/13] omap: use list_move() instead of list_del()/list_add() combination

[Paul Mundt]

On Wed, Mar 16, 2011 at 05:13:49PM +0530, Tomi Valkeinen wrote:
 On Tue, 2011-03-15 at 17:53 -0500, Kirill A. Shutemov wrote:
  Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
  Cc: Tomi Valkeinen tomi.valkei...@nokia.com
  Cc: linux-fb...@vger.kernel.org
  Cc: linux-omap@vger.kernel.org
  ---
   drivers/video/omap/blizzard.c |3 +--
   drivers/video/omap/hwa742.c   |3 +--
   2 files changed, 2 insertions(+), 4 deletions(-)
 
 Acked-by: Tomi Valkeinen tomi.valkei...@ti.com

On Wed, Mar 16, 2011 at 12:53:19AM +0200, Kirill A. Shutemov wrote:
 Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
 Cc: Tejun Heo t...@kernel.org
 Cc: linux-fb...@vger.kernel.org
 ---
  drivers/video/vermilion/vermilion.c |3 +--
  1 files changed, 1 insertions(+), 2 deletions(-)
 
Both applied, thanks.
--
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] Input: tca6416-keypad: Change to module_init()

[Paul Mundt]

On Tue, Mar 22, 2011 at 02:28:55PM +, Mark Brown wrote:
 On Tue, Mar 22, 2011 at 11:26:19PM +0900, Magnus Damm wrote:
 
  The tca6416 driver makes use of the I2C bus for chatting
  with the actual hardware device. Without this patch both
  the I2C bus driver and the tca6416 driver are initialized
  at the subsys_initcall() level. This may lead to problems
  with the tca6416 driver being initialized before the I2C
  bus driver.
 
 While this change seems reasonable I'm curious what the problems caused
 by out of order registration are?

I'm also curious as to why link order isn't a sufficient gaurantee like
it is for everyone else?
--
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] Input: tca6416-keypad: Change to module_init()

[Paul Mundt]

On Wed, Mar 23, 2011 at 12:22:05AM +0900, Magnus Damm wrote:
 On Tue, Mar 22, 2011 at 11:33 PM, Paul Mundt let...@linux-sh.org wrote:
  On Tue, Mar 22, 2011 at 02:28:55PM +, Mark Brown wrote:
  On Tue, Mar 22, 2011 at 11:26:19PM +0900, Magnus Damm wrote:
 
   The tca6416 driver makes use of the I2C bus for chatting
   with the actual hardware device. Without this patch both
   the I2C bus driver and the tca6416 driver are initialized
   at the subsys_initcall() level. This may lead to problems
   with the tca6416 driver being initialized before the I2C
   bus driver.
 
  While this change seems reasonable I'm curious what the problems caused
  by out of order registration are?
 
  I'm also curious as to why link order isn't a sufficient gaurantee like
  it is for everyone else?
 
 I believe all other i2c keyboard drivers use module_init().
 
We do not change initcall ordering around unless there is a reason to do
so, as it's assumed that a given initcall has been chosen for a reason.
You have hit upon a bug or at least something timing related causing you
a delay and so have elected to push it down a level. That is of course
fine, but none of that is anywhere in your commit text leaving us to try
and figure out what exactly the point of this exercise is.

Usually because everyone else is doing it and another driver is not,
there's a reason for that driver doing things differently. There are
certainly enough cases where initcall and link ordering is strongly
ordered for a reason that cosmetic/janitorial fixes are best rejected out
of hand.

You had a reason, great. Next time put it in your commit text.
--
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] Input: tca6416-keypad: Change to module_init()

[Paul Mundt]

On Wed, Mar 23, 2011 at 12:43:54AM +0900, Magnus Damm wrote:
 On Wed, Mar 23, 2011 at 12:32 AM, Paul Mundt let...@linux-sh.org wrote:
  On Wed, Mar 23, 2011 at 12:22:05AM +0900, Magnus Damm wrote:
  I believe all other i2c keyboard drivers use module_init().
 
  We do not change initcall ordering around unless there is a reason to do
  so, as it's assumed that a given initcall has been chosen for a reason.
 
 Yes, obviously this driver is special and all other keypad drivers are wrong.
 
I'm not sure why you're purposely trying to be dense. I was explaining
why it's not uncommon to find drivers using subsys_initcall for various
non-obvious reasons and why blindly changing them without valid rationale
generally causes more trouble than it prevents. In the case of a keypad
driver it's unlikely to matter, but someone may still have had a reason
for doing so. Given that your patch is fixing a problem, this is what
should be reflected in your commit text, not some vague hand-waving about
what everyone else is doing or what could hypothetically lead to
problems.

 It would be interesting to hear why subsys_initcall() was put there in
 the first place.
 
In this case I would suspect general indifference or simply copying other
drivers. I2C is a bit of a tricky case with regards to ordering in
general, but at least input devices are relatively straightforward.

 The keypad driver tries to use the I2C bus before the I2C bus driver
 is initialized. Isn't that a pretty good reason to change the initcall
 order?
 
Yes, and that part is also not mentioned anywhere in your commit text.
Starting to see a pattern?

  You had a reason, great. Next time put it in your commit text.
 
 Whatever. Let me know which lines you'd like to add and I'll send a V2.
 
I don't think it's too much to ask that you write a commit text that
actually mentions what problem you are experiencing and fixing. I also
don't know why this needs to be pointed out. One shouldn't have to work
for an explanation of what purpose your patch serves when you're the one
trying to get it merged.
--
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 PATCH] HDMI:Support for EDID parsing in kernel.

[Paul Mundt]

On Tue, Mar 22, 2011 at 02:52:59PM -0300, Mauro Carvalho Chehab wrote:
 Em 22-03-2011 14:32, Mythri P K escreveu:
  Adding support for common EDID parsing in kernel.
  
  EDID - Extended display identification data is a data structure provided by
  a digital display to describe its capabilities to a video source, This a 
  standard supported by CEA and VESA.
  
  There are several custom implementations for parsing EDID in kernel, some
  of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally
  parsing of EDID should be done in a library, which is agnostic of the
  framework (V4l2, DRM, FB)  which is using the functionality, just based on 
  the raw EDID pointer with size/segment information.
  
  With other RFC's such as the one below, which tries to standardize HDMI 
  API's
  It would be better to have a common EDID code in one place.It also helps to
  provide better interoperability with variety of TV/Monitor may be even by
  listing out quirks which might get missed with several custom implementation
  of EDID.
  http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401
  
  This patch tries to add functions to parse some portion EDID (detailed 
  timing,
  monitor limits, AV delay information, deep color mode support, Audio and 
  VSDB)
  If we can align on this library approach i can enhance this library to parse
  other blocks and probably we could also add quirks from other implementation
  as well.
  
  Signed-off-by: Mythri P K mythr...@ti.com
  ---
   arch/arm/include/asm/edid.h |  243 ++
   drivers/video/edid.c|  340 
  +++
 
 Hmm... if you want this to be agnostic, the header file should not be inside
 arch/arm, but on some other place, like include/video/.
 
Ironically this adds a drivers/video/edid.c but completely ignores
drivers/video/edid.h which already exists and already contains many of
these definitions.

I like the idea of a generalized library, but it would be nice to see the
existing edid.h evolved and its users updated incrementally.
--
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: [GIT PULL] omap display subsystem changes for 2.6.39

[Paul Mundt]

On Mon, Mar 21, 2011 at 11:51:23AM +0200, Tomi Valkeinen wrote:
 One problem I noticed just now, the committer names seem a bit messed
 up. For example, Archit Taneja has three different style names there. Do
 you think I should rebase and fix them? Not a big job, but it'll mean,
 well, rebasing.
 
No need, this is what .mailmap is for. It seems there are quite a few
variations, I've added entries now for all of:

Archit Taneja arc...@ti.com
Mayuresh Janorkar ma...@ti.com
Mythri P K mythr...@ti.com
Sumit Semwal sumit.sem...@ti.com

which traps all of the offenders in these patches. There seems to be a
general issue of author names and sign-offs using reverse order naming, I
assume because this is some absurd convention used by TI's mail servers.

We can of course continue fixing them up as they pop up, but people
should ideally be aware of the need for consistency before committing
things, too. A bit of name mangling is certainly a lesser evil than
rewriting history, though.

 There's a minor conflict in Overo's board file. I have pushed
 for-paul-merged branch to gitorious, which contains a merge with
 Linus' tree. I'm not sure that is the best way to show how to fix the
 conflict, but hopefully it'll give the idea.
 
Seemed pretty straightforward, I took care of it and made sure that it
still built. I assume Tony or someone will yell loudly if I've
inadvertently broken something :-)

Pulled now. I'll send things off to Linus shortly.
--
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: [GIT PULL] OMAP DSS changes for .38 merge window v2

[Paul Mundt]

On Mon, Jan 10, 2011 at 11:51:02AM +0200, Tomi Valkeinen wrote:
 Here's a new pull request for OMAP display subsystem patches. This one
 is rebased on top of the new omap patches on mainline, and the resulting
 board file conflict has been fixed.
 
 And while rebasing, I squashed the topmost patch, OMAP: DSS2: Fix build
 breaks for rfbi.c and dsi.c, into the respective patches. The patch
 contained only a few trivial compile fixes to errors which mistakenly
 slipped in.
 
Pulled, thanks.
--
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: [GIT PULL] OMAP DSS changes for .38 merge window

[Paul Mundt]

On Fri, Jan 07, 2011 at 02:41:43PM +0200, Tomi Valkeinen wrote:
 Hello Paul,
 
 Here are some OMAP display changes for .38. I hope they are not too
 late, but the holidays messed up my schedules a bit.
 
No, no problem. I usually aim to do two merges per merge window on
average, one at the beginning and one nearer the end. There are often
many patches that have dependencies that are blocked while other trees
merge that get sent off when their dependencies have been met.

 I made two branches, as I'm not sure which is better:
 
 for-paul-38 - This one is the original non-rebased branch. This causes a
 trivial conflict with fbdev/master in drivers/video/omap2/vram.c (SZ_2M
 is the right one), and also it contains a patch (memblock: fix
 memblock_is_region_memory()) which is not yet in mainline, but is in
 Andrew Morton's tree.
 
 for-paul-38-rebased - The above branch rebased on top of v2.6.37, and
 the memblock commit removed.
 
 Which one you prefer? Or is there some other way I should handle this?
 
 I could merge v2.6.37 to my branch, which would remove the conflict, but
 that would still leave the memblock patch. I guess the patch is going in
 soon, but as it's not in my area, I don't feel it's right to get it in
 via my patch set. Alternatively I could wait until the patch is in
 Linus' tree, but that could make it tight to be in time for the merge
 window.
 
Andrew usually patch-bombs near the end of the window, so it's generally
a good idea to have things settled before then. In this case if the patch
is already destined for mainline then I can just pull the rebased branch,
send that out, and then once -mm syncs up everything should be good to go
for -rc1.

Looking at the change in question, it's just a correctness fix and
doesn't impact the API from the driver point of view, so at least there
won't be build damage if they're out of sync for a couple of days
(although it may trigger some nasty surprises for anyone unlucky enough
to bisect in the middle).

In any event, unless you absolutely need the change to be upstream first,
I'll plan to pull the rebase branch. If you need it there earlier we can
probably also just prod Andrew and get that one patch off earlier than
the rest of the -mm bits.
--
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: [GIT PULL] OMAP DSS changes for .38 merge window

[Paul Mundt]

On Fri, Jan 07, 2011 at 03:37:32PM +0200, Tomi Valkeinen wrote:
 On Fri, 2011-01-07 at 22:25 +0900, ext Paul Mundt wrote:
 I guess it's not out-of-the-question to get driver changes in in early
 rcs, but I'd rather get everything pulled during the merge window. Also,
 some of the patches still out there touch OMAP's arch/ files, so they
 are not plain driver changes.
 
As long as all the new and big stuff goes in for -rc1 it's certainly fine
to take care of the rest over the next few rc releases. Things do
invariably break when multiple trees are being merged, so it's to be
expected.

  Looking at the change in question, it's just a correctness fix and
  doesn't impact the API from the driver point of view, so at least there
  won't be build damage if they're out of sync for a couple of days
  (although it may trigger some nasty surprises for anyone unlucky enough
  to bisect in the middle).
  
  In any event, unless you absolutely need the change to be upstream first,
  I'll plan to pull the rebase branch. If you need it there earlier we can
  probably also just prod Andrew and get that one patch off earlier than
  the rest of the -mm bits.
 
 No, the fix is not needed urgently. The memblock fix is only important
 for some rare use cases, which I don't think anyone is currently using
 (allocating video memory from SDRAM at a predefined address).
 
Hmm, I've just fast-forwarded to Linus's current tree and tried to pull
your rebase branch in, but it seems to have a board conflict with the
OMAP tree merge:

CONFLICT (delete/modify): arch/arm/mach-omap2/board-zoom2.c deleted in HEAD and 
modified in 122ffebf2191529153c079b457e38ca3829eac40. Version 
122ffebf2191529153c079b457e38ca3829eac40 of arch/arm/mach-omap2/board-zoom2.c 
left in tree.

Additionally there's a board-zoom.c conflict that looks like this:

diff --cc arch/arm/mach-omap2/board-zoom.c
index e041c53,1523369..000
--- a/arch/arm/mach-omap2/board-zoom.c
+++ b/arch/arm/mach-omap2/board-zoom.c
@@@ -118,29 -113,17 +118,36 @@@ static const struct ehci_hcd_omap_platf
  
  static void __init omap_zoom_init(void)
  {
 -  omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
 -  zoom_peripherals_init();
 +  if (machine_is_omap_zoom2()) {
 +  omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
 +  } else if (machine_is_omap_zoom3()) {
 +  omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
 +  omap_mux_init_gpio(ZOOM3_EHCI_RESET_GPIO, OMAP_PIN_OUTPUT);
 +  usb_ehci_init(ehci_pdata);
 +  }
 +
board_nand_init(zoom_nand_partitions,
 -   ARRAY_SIZE(zoom_nand_partitions), ZOOM_NAND_CS);
 +  ARRAY_SIZE(zoom_nand_partitions), ZOOM_NAND_CS);
zoom_debugboard_init();
++ HEAD:arch/arm/mach-omap2/board-zoom.c
 +  zoom_peripherals_init();
++===
+   zoom_display_init();
+ 
+   omap_mux_init_gpio(64, OMAP_PIN_OUTPUT);
+   usb_ehci_init(ehci_pdata);
++ 
122ffebf2191529153c079b457e38ca3829eac40:arch/arm/mach-omap2/board-zoom3.c
  }
  
 +MACHINE_START(OMAP_ZOOM2, OMAP Zoom2 board)
 +  .boot_params= 0x8100,
 +  .map_io = omap3_map_io,
 +  .reserve= omap_reserve,
 +  .init_irq   = omap_zoom_init_irq,
 +  .init_machine   = omap_zoom_init,
 +  .timer  = omap_timer,
 +MACHINE_END
 +
  MACHINE_START(OMAP_ZOOM3, OMAP Zoom3 board)
.boot_params= 0x8100,
.map_io = omap3_map_io,
* Unmerged path arch/arm/mach-omap2/board-zoom2.c

It looks like there has been some consolidation work based on the last commit,
but I'll leave it to you to decide how to handle.
--
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: [RESEND #2] [PATCH v2] LEDS: Add output invertion option to backlight trigger

[Paul Mundt]

(Trying an alternate address for Richard, and adding Andrew to Cc..)

On Thu, Dec 09, 2010 at 02:41:50PM +0100, Janusz Krzysztofik wrote:
 This patch extends the LED backlight tirgger driver with an option that 
 allows 
 for inverting the trigger output polarity.
 
 With the invertion option provided, I (ab)use the backlight trigger for 
 driving a LED that indicates LCD display blank condtition on my Amstrad Delta 
 videophone. Since the machine has no dedicated power LED, it was not possible 
 to distinguish if the display was blanked, or the machine was turned off, 
 without touching it.
 
 The invert sysfs control is patterned after a similiar function of the GPIO 
 trigger driver.
 
 Created and tested against linux-2.6.36-rc5 on Amstrad Delta.
 Retested on linux-2.6.37-rc4.
 
 Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
 Cc: Richard Purdie rpur...@rpsys.net
 ---
 
 Resent because I still can't see any response received, while yet another 
 merge window is going to pass away soon.
 
 Applies cleanly on top of 2.6.37-rc4, so no need for yet another refresh. 
 Only 
 tried to clean up the commit message slightly - maybe my English is not good 
 enough to bother with, if not the code?
 
 v1 - v2 changes:
 - improve some conditional expressions to be more readable; thanks to Ralph 
   Corderoy (from e3-hacking) and Lars-Peter Clausen for their suggestions,
 - refresh against linux-2.6.36-rc5.
 
  drivers/leds/ledtrig-backlight.c |   60 
 ---
  1 file changed, 56 insertions(+), 4 deletions(-)
 
 diff -upr linux-2.6.36-rc5.orig/drivers/leds/ledtrig-backlight.c 
 linux-2.6.36-rc5/drivers/leds/ledtrig-backlight.c
 --- linux-2.6.36-rc5.orig/drivers/leds/ledtrig-backlight.c2010-09-24 
 15:35:13.0 +0200
 +++ linux-2.6.36-rc5/drivers/leds/ledtrig-backlight.c 2010-10-03 
 15:59:49.0 +0200
 @@ -26,6 +26,7 @@ struct bl_trig_notifier {
   int brightness;
   int old_status;
   struct notifier_block notifier;
 + unsigned invert;
  };
  
  static int fb_notifier_callback(struct notifier_block *p,
 @@ -36,23 +37,63 @@ static int fb_notifier_callback(struct n
   struct led_classdev *led = n-led;
   struct fb_event *fb_event = data;
   int *blank = fb_event-data;
 + int new_status = *blank ? BLANK : UNBLANK;
  
   switch (event) {
   case FB_EVENT_BLANK :
 - if (*blank  n-old_status == UNBLANK) {
 + if (new_status == n-old_status)
 + break;
 +
 + if ((n-old_status == UNBLANK) ^ n-invert) {
   n-brightness = led-brightness;
   led_set_brightness(led, LED_OFF);
 - n-old_status = BLANK;
 - } else if (!*blank  n-old_status == BLANK) {
 + } else {
   led_set_brightness(led, n-brightness);
 - n-old_status = UNBLANK;
   }
 +
 + n-old_status = new_status;
 +
   break;
   }
  
   return 0;
  }
  
 +static ssize_t bl_trig_invert_show(struct device *dev,
 + struct device_attribute *attr, char *buf)
 +{
 + struct led_classdev *led = dev_get_drvdata(dev);
 + struct bl_trig_notifier *n = led-trigger_data;
 +
 + return sprintf(buf, %s\n, n-invert ? yes : no);
 +}
 +
 +static ssize_t bl_trig_invert_store(struct device *dev,
 + struct device_attribute *attr, const char *buf, size_t num)
 +{
 + struct led_classdev *led = dev_get_drvdata(dev);
 + struct bl_trig_notifier *n = led-trigger_data;
 + unsigned invert;
 + int ret;
 +
 + ret = sscanf(buf, %u, invert);
 + if (ret  1) {
 + dev_err(dev, invalid value\n);
 + return -EINVAL;
 + }
 +
 + n-invert = !!invert;
 +
 + /* After inverting, we need to update the LED. */
 + if ((n-old_status == BLANK) ^ n-invert)
 + led_set_brightness(led, LED_OFF);
 + else
 + led_set_brightness(led, n-brightness);
 +
 + return num;
 +}
 +static DEVICE_ATTR(invert, 0644, bl_trig_invert_show, bl_trig_invert_store);
 +
  static void bl_trig_activate(struct led_classdev *led)
  {
   int ret;
 @@ -66,6 +107,10 @@ static void bl_trig_activate(struct led_
   return;
   }
  
 + ret = device_create_file(led-dev, dev_attr_invert);
 + if (ret)
 + goto err_invert;
 +
   n-led = led;
   n-brightness = led-brightness;
   n-old_status = UNBLANK;
 @@ -74,6 +119,12 @@ static void bl_trig_activate(struct led_
   ret = fb_register_client(n-notifier);
   if (ret)
   dev_err(led-dev, unable to register backlight trigger\n);
 +
 + return;
 +
 +err_invert:
 + led-trigger_data = NULL;
 + kfree(n);
  }
  
  static void bl_trig_deactivate(struct led_classdev *led)
 @@ -82,6 +133,7 @@ static void bl_trig_deactivate(struct le
   (struct bl_trig_notifier *) led-trigger_data;
  
   if 

Re: [GIT PULL] OMAP DSS fixes for next rc

[Paul Mundt]

On Wed, Dec 15, 2010 at 05:20:08PM +0200, Tomi Valkeinen wrote:
 Hi Paul,
 
 Two OMAP DSS fixes for the next rc.
 
Pulled and pushed out, thanks. I'll send these out for -rc7.
--
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: Mainline OMAP3 breakage (and other OMAP?)

[Paul Mundt]

On Thu, Dec 02, 2010 at 02:32:08PM -0800, Tony Lindgren wrote:
 * Russell King - ARM Linux li...@arm.linux.org.uk [101202 14:06]:
  On Thu, Dec 02, 2010 at 01:58:38PM -0800, Tony Lindgren wrote:
   * Russell King - ARM Linux li...@arm.linux.org.uk [101202 13:04]:
This has been around since October:

drivers/video/omap2/vram.c: In function 
???omap_vram_reserve_sdram_memblock???:
drivers/video/omap2/vram.c:573: error: ???MEMBLOCK_REAL_LIMIT??? 
undeclared (first use in this function)
drivers/video/omap2/vram.c:573: error: (Each undeclared identifier is 
reported only once
drivers/video/omap2/vram.c:573: error: for each function it appears in.)

This requires a trivial one-liner compile fix:

diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
index fed2a72..a8973f0 100644
--- a/drivers/video/omap2/vram.c
+++ b/drivers/video/omap2/vram.c
@@ -570,7 +570,7 @@ void __init omap_vram_reserve_sdram_memblock(void)
return;
}
} else {
-   paddr = memblock_alloc_base(size, PAGE_SIZE, 
MEMBLOCK_REAL_LIMIT);
+   paddr = memblock_alloc(size, PAGE_SIZE);
}
 
omap_vram_add_region(paddr, size);

which restores the old behaviour before the X86 memblock changes went
in.  Yes, there may be other changes due to the ioremap stuff, but
that's really no excuse for not fixing the compile error itself.
   
   Great. Adding fbdev and Tomi to Cc.
   
   Acked-by: Tony Lindgren t...@atomide.com
  
  http://marc.info/?l=linux-omapw=2r=1s=MEMBLOCK_REAL_LIMIT%20vramq=b
  
  There have been patches posted throughout November to fix this, but
  the problem is they're not making it to mainline.  It needs chasing
  until someone does the right thing and sends one variant of the above
  patch, rather than just leaving it until the ioremap fixes hit
  mainline during the next merge window.
 
 Yes this should go in during the -rc for sure.
 
 I suggest you merge this but let's wait a bit and check if Tomi
 already has a similar fix queued for the -rc series.
 
This has been fixed since -rc2.
--
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:DSS: possible bug in WAITFOR_VSYNC ioctl

[Paul Mundt]

On Fri, Nov 26, 2010 at 02:55:39PM +0200, Ville Syrj?l? wrote:
 On Fri, Nov 26, 2010 at 05:38:11PM +0530, ext Hiremath, Vaibhav wrote:
  With this finding, in case of OMAP3 we have to use OMAPFB_WAITFORGO
  (breaking standard applications).
 
 Applications using the standard fbdev API won't work with manual update
 displays anyway. You need omapfb specific code to handle it so having
 another small difference is not a big deal.
 
 In DirectFB the that's trivial since there's already a simple omap
 gfxdriver where you could override the default flip functionality with
 WAITFORGO based stuff.
 
 Or, as I said, you could add another standard ioctl and fix up userspace
 to use it where appropriate and if the kernel driver supports it.
 
It seems like the WAITFORGO semantics could be layered on top of drivers
using deferred I/O pretty easily, but the question is whether this is
something that userspace plans to make general use of or not. If the only
user of it in userspace code is OMAP-specific, then there's probably not
a lot of point in moving it over to be generic, but if there are
sufficient cases where userspace cares about this information independent
of WAITFORVSYNC for manual update displays, then we can certainly look at
moving it over for those cases.
--
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:DSS: possible bug in WAITFOR_VSYNC ioctl

[Paul Mundt]

On Tue, Nov 30, 2010 at 03:34:40PM +0900, Paul Mundt wrote:
 On Fri, Nov 26, 2010 at 02:55:39PM +0200, Ville Syrj?l? wrote:
  On Fri, Nov 26, 2010 at 05:38:11PM +0530, ext Hiremath, Vaibhav wrote:
   With this finding, in case of OMAP3 we have to use OMAPFB_WAITFORGO
   (breaking standard applications).
  
  Applications using the standard fbdev API won't work with manual update
  displays anyway. You need omapfb specific code to handle it so having
  another small difference is not a big deal.
  
  In DirectFB the that's trivial since there's already a simple omap
  gfxdriver where you could override the default flip functionality with
  WAITFORGO based stuff.
  
  Or, as I said, you could add another standard ioctl and fix up userspace
  to use it where appropriate and if the kernel driver supports it.
  
 It seems like the WAITFORGO semantics could be layered on top of drivers
 using deferred I/O pretty easily, but the question is whether this is
 something that userspace plans to make general use of or not. If the only
 user of it in userspace code is OMAP-specific, then there's probably not
 a lot of point in moving it over to be generic, but if there are
 sufficient cases where userspace cares about this information independent
 of WAITFORVSYNC for manual update displays, then we can certainly look at
 moving it over for those cases.

Also, WAITFORGO is a pretty abysmal name. It seems like what you want is
a WAITFORHWSYNC or something similar.
--
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] OMAP3: DSS: Kconfig changes to enable display options on OMAP3

[Paul Mundt]

On Thu, Nov 18, 2010 at 08:44:14AM -0800, Tony Lindgren wrote:
 * Paul Mundt let...@linux-sh.org [101117 22:09]:
  Unless you can say with certainty that all OMAP3 boards are going to want
  DSS enabled or modular by default, it's almost always better to just
  leave it up to the defconfigs.
 
 I wish we could just do default m if ARCH_OMAP2PLUS_TYPICAL..
 But meanwhile setting it as a module in omap2plus_defconfig does
 the trick though like you say.
 
Something like this should be quite doable if the Kconfig fragments work
is ever completed. If this is something that interests you you may wish
to give it a bit of a nudge :-)
--
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] OMAP3: DSS: Kconfig changes to enable display options on OMAP3

[Paul Mundt]

On Wed, Nov 17, 2010 at 02:28:11PM +0200, Tomi Valkeinen wrote:
 On Tue, 2010-11-16 at 21:10 +0100, ext Tony Lindgren wrote:
  Sure a module would be even better. My point is that the selection of
  all the features should be enabled by default and the board options come
  from platform_data.
 
 Ok, let's build DSS  all panel drivers as modules by default.
 
 Somehow I've gotten the impression from linux ml that enabling features
 by default is bad. But perhaps it's more about intervening features than
 normal drivers.
 
The general rule is to avoid default enabling unless you really need it,
but it still remains optional (which is why it's not being selected,
instead). Some, like gpiolib, have come up with WANT/NEED options for the
platform code to select in order to work out the desired behaviour, and
you may benefit from a similar approach for your subsystem if it's really
that integral for some parts.

The flip side of course is that if you expect your users to primarily be
using the defconfigs provided, you can simply leave it default disabled
in the Kconfig and set the options you want in the defconfigs.

Unless you can say with certainty that all OMAP3 boards are going to want
DSS enabled or modular by default, it's almost always better to just
leave it up to the defconfigs.
--
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/3] OMAP: VRAM: improve VRAM error prints

[Paul Mundt]

On Wed, Nov 10, 2010 at 02:04:14PM +0200, Tomi Valkeinen wrote:
 On Wed, 2010-11-10 at 12:51 +0100, ext Paul Mundt wrote:
  On Wed, Nov 10, 2010 at 11:45:18AM +0200, Tomi Valkeinen wrote:
   Improve the error prints to give more information about the offending
   address  size.
   
   Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com
  
  1-3 queued for .37, thanks.
 
 They were just for review =).
 
 If it's ok to you, I'll pick all OMAP display related patches to my
 tree, and send you a pull request when I think they are ready.
 
I wasn't sure what your intentions were, but that's of course fine, too!

Please keep an eye on the -rc timing however, so we don't end up with
bigger things piling up in the later -rc stages and then have to start
cherry-picking the urgent bits.

 But for these three patches it's ok if you already queued them: they are
 quite high priority, as the OMAP framebuffer doesn't work at all without
 the second patch.
 
Right. I looked through the OMAP list archives for some context on these
first and since the second one was at least a build fix I assumed you
wanted to get them merged sooner rather than later.
--
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/3] OMAP: VRAM: improve VRAM error prints

[Paul Mundt]

On Wed, Nov 10, 2010 at 11:45:18AM +0200, Tomi Valkeinen wrote:
 Improve the error prints to give more information about the offending
 address  size.
 
 Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com

1-3 queued for .37, thanks.
--
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 1/3] mm: iommu: An API to unify IOMMU, CPU and device memory management

[Paul Mundt]

On Thu, Jul 01, 2010 at 12:16:18AM -0700, Zach Pfeffer wrote:
 Thank you for the corrections. I'm correcting them now. Some responses:
 
 Randy Dunlap wrote:
  +struct vcm *vcm_create(size_t start_addr, size_t len);
  
  Seems odd to use size_t for start_addr.
 
 I used size_t because I wanted to allow the start_addr the same range
 as len. Is there a better type to use? I see 'unsigned long' used
 throughout the mm code. Perhaps that's better for both the start_addr
 and len.
 
phys_addr_t or resource_size_t.
--
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 0/8] Suspend block api (version 8)

[Paul Mundt]

On Thu, May 27, 2010 at 06:06:43PM +0200, Thomas Gleixner wrote:
 On Thu, 27 May 2010, Alan Stern wrote:
  And to answer Thomas's question: The whole reason for having in-kernel 
  suspend blockers is so that userspace can tell the system to suspend 
  without losing wakeup events.
  
  Suppose a key is pressed just as a user program writes mem to
  /sys/power/state.  The keyboard driver handles the keystroke and queues
  an input event.  Then the system suspends and doesn't wake up until
  some other event occurs -- even though the keypress was an important
  one and it should have prevented the system from suspending.
  
  With in-kernel suspend blockers and opportunistic suspend, this 
  scenario is prevented.  That is their raison-d'etre.
 
 I tend to disagree. You are still looking at suspend as some extra
 esoteric mechanism. We should stop doing this and look at suspend (to
 RAM) as an additional deep idle state, which is well defined in terms
 of power savings and wakeup latency. That's what I think opportunistic
 suspend is all about. Now if you look at our current idle states in
 x86 the incoming keystroke is never lost. 
 
For systems with runtime PM and deep idle states in cpuidle suspend is
already fairly opportunistic. If sleep states (including suspend to RAM
and CPU off) are factored in to cpuidle then it's very easy to get in to
situations where everything simply shuts off automatically, which can be
problematic if a platform doesn't expose any external wakeup sources.

Platforms still need to be able to establish some heuristics, whether
this is via blocking certain state transitions or simply defining a
maximum acceptable suspend depth irrespective of latency (at least we
presently don't have a clean interface for preventing entry in to
impossible to recover from idle states outside of latency hints via PM
QoS, or at least not one that I'm aware of).

On the other hand, while this isn't that difficult for the UP case it
does pose more problems for the SMP case. Presently the suspend paths
(suspend-to-RAM/hibernate/kexec jump) all deal with disabling and
enabling of non-boot CPUs via CPU hotplug explicitly, which will clear
them from the online CPU map. We would have to rework the semantics a bit
if cpuidle were also permitted to opportunistically offline CPUs.
--
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 v3] ARM: mach-shmobile: add framebuffer support for ap4evb

[Paul Mundt]

On Sun, May 23, 2010 at 04:04:03PM +0200, Guennadi Liakhovetski wrote:
 ap4evb uses an LCD, connected to the SoC over the MIPI bus. This patch adds
 platform data to configure this display and a static clock activation.
 
 Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
 Tested-by: Damian Hobson-Garcia dhobs...@igel.co.jp

Please just repost the entire series with the updates.
--
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/4] fbdev: add a MIPI DSI header

[Paul Mundt]

On Wed, May 19, 2010 at 05:27:32PM +0300, Ville Syrj?l? wrote:
 On Wed, May 19, 2010 at 10:21:48AM +0200, Valkeinen Tomi (Nokia-D/Helsinki) 
 wrote:
  I think a simple solution would be to just use defines, and have
  functions that take the command as u8. That's what the OMAP DSI driver
  does. If you have better ideas, please share =).
 
 I find enums easier on the eye than defines. Less irrelevant junk on
 each line. There's no reason you can't pass enum values as u8. But in
 that case giving the enum a name doesn't really make sense.
 
enums are cleaner for these cases, but you also have the case where the
enum type itself is variable size depending on the ABI being used. If
the type in question isn't being packed in to a user-visible data
structure then this will never matter, but it does help to be a bit
careful here regardless. Many people were bitten by this in the ARM
OABI - EABI conversion, while other architectures generally managed to
get it right from the onset.
--
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: [PATCHv4 1/4] procfs: Introduce socinfo under /proc

[Paul Mundt]

On Mon, May 10, 2010 at 05:22:48PM +0300, Eduardo Valentin wrote:
 On Mon, May 10, 2010 at 01:13:00PM +0200, ext Paul Mundt wrote:
  You'll still need the show function, but all of the rest of this is just
  duplicating what single_open() already does. If the socinfo string is
  static you may also want to rework this a bit so you can just stash the
  string in the proc_dir_entry private data. Combine this with something
  like kstrdup() and you'll save yourself a bit of stack while you're at
  it.
 
 While still here, about cleaning this, so, let me see if I got your point.
 Basically, the file under fs/proc/socinfo.c whould do the thing with 
 single_open 
 single_release, as you stated. But then there is the .show and its data.
 One idea would then be to have a function:
 
 int register_socinfo_show(int (*show)(struct seq_file *, void *), void *data);
 
 Which would be exported to other parts of the kernel (something placed under
 include/linux/socinfo.h for instance). Then the soc core code
 (like arch/arm/mach-omap[1,2]) would then register its local show function 
 and pass its data.
 
 This way I think we can avoid the exports inside .c files (as in this patch)
 and also pass the static char * needed during the show.
 
 What do you think?
 
Yes, you'll need something like that. kstrdup() also does an allocation,
but you're only going to be registering once and are unlikely to ever
unregister (particular since you have this configured as a bool) so that
doesn't really matter. On the other hand if the string itself is static
you can just pass that in with a static initializer, or have some sort of
opaque socinfo data structure that contains the strings you care about.
You'll always be able to get back at the pointer through the
proc_dir_entry private data.
--
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: [PATCHv4 1/4] procfs: Introduce socinfo under /proc

[Paul Mundt]

On Mon, May 10, 2010 at 03:55:49PM +0300, Eduardo Valentin wrote:
 On Mon, May 10, 2010 at 02:39:02PM +0200, ext Paul Mundt wrote:
  Note that in the cpuinfo case there is often special handling for the
  single (or boot CPU) case, such as printing out a descriptor for the
  machine type and so on. You might be better off just extending cpuinfo
  rather than introducing another /proc abstraction, presumably your
  socinfo string will be fixed regardless of whether it's SMP or not.
 
 Yeah, I wouldn't expect it to change if it SMP or not. It should be fixed.
 Previous version of this change was actually extending ARM cpuinfo. The 
 previous
 thread starts here:
 http://marc.info/?l=linux-omapm=127304890312365w=2
 
 But, the point of moving that to specific file was that soc info is not 
 really cpu info.
 
It's up to you of course, but adding an extra file because of SoC/CPU
ambiguity seems pretty ugly. Almost all architectures already include
machine type descriptors in their cpuinfo output (as ARM does also) and
if you can justify that then certainly adding in some SoC-specific bits
isn't exactly much of a stretch.

These days you should have a pretty strong justification for adding new
procfs files, and this is certainly not one of them.
--
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] mtd: make onenand/generic.c more generic

[Paul Mundt]

On Fri, Aug 07, 2009 at 02:28:01PM +0900, Magnus Damm wrote:
 On Wed, Aug 5, 2009 at 1:41 PM, Magnus Dammmagnus.d...@gmail.com wrote:
  On Tue, Aug 4, 2009 at 6:20 PM, Magnus Dammmagnus.d...@gmail.com wrote:
  From: Magnus Damm d...@igel.co.jp
 
  This patch removes the ARM dependency from the generic onenand
  platform device driver. This change makes the driver useful for
  other architectures as well. Needed for the SuperH kfr2r09 board.
 
  On Wed, Aug 5, 2009 at 1:24 PM, Kyungmin Parkkmp...@infradead.org wrote:
  Good idea add the onenand_platform_data, but dont' agree the renaming
  the onenand-flash.
  Other boards are use it even though it's not released it
 
  I suspected so. But this is the only reason why changed the name. =)
 
  If we don't change the name then the platform device will be attached
  to the platform driver as usual, but the old platform data structure
  will use a different binary format compated to what the driver
  expects.
 
  Changing the driver name makes sure that the old device disappears and
  that people can move over to the new name and at the same time update
  the platform data to the new format.
 
  Others are good.
 
  Thanks.
 
  I can post an updated version where I keep the driver name unchanged
  if you prefer that. But I'm pretty sure out-of-tree drivers will break
  with NULL pointer accesses or similar if we update the platform data
  format without changing the name. I don't think you want that. =)
 
 Any update on this?
 
You have failed at reading your email:

http://lists.infradead.org/pipermail/linux-mtd/2009-August/026805.html
http://lists.infradead.org/pipermail/linux-mtd/2009-August/026809.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: lowmemory android driver not needed?

[Paul Mundt]

On Wed, Jan 21, 2009 at 11:50:48AM +0900, KOSAKI Motohiro wrote:
 I should rewrite memory notification patchset from scratch.
 the new version will construct on memcg infrastrcture.
 
 Why?
 
 last year, I received many feedback from lkml folks and my article reader.
 (I monthly write kernel patch introduction article to japanese web
  magazine and receive some feedback periodically)
 
 I learned many people want flexibility notification.
 (per workload, per user, et al)
 eg. nokia lowmem driver have exception process defined by uid.
 
 at top of last year, I thought memcg don't provide good infrastructure.
 the first version memcg is just pretty funny joke. if its config turn on,
 memory workload performance decrease ~30% although the user don't use 
 memcg at runtime. then nobody use it.
 but recently, KAMEZAWA hiroyuki (and Li zefan, Daisuke Nishimura et al)
 dramatically improvement memcg performance. 
 now, memcg overhead become less than 1%. 
 
 Then, I think any memory accounting activity should use this infrastructure.
 That's my homework.
 
Building on top of the memory cgroup makes sense given that it has a
lot more knowledge of the actual state in different contexts compared to
something like security_vm_enough_memory()/__vm_enough_memory().

Despite that, a notification layer on top of cgroups in general might be
worth thinking about, particularly since each controller may want to use
notifications for different things. It is conceivable that people will
also want different types of notifications from the memory controller
beyond a simple lowmem notifier.

The LSM lowmem module itself used multiple notification levels to tune
application behaviour for instance, though obviously this is something
that is highly workload dependent.
--
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: lowmemory android driver not needed?

[Paul Mundt]

On Thu, Jan 15, 2009 at 03:44:04PM -0800, Greg KH wrote:
 On Thu, Jan 15, 2009 at 07:02:48PM +0530, Trilok Soni wrote:
  And there is one more lowmem driver developed by Nokia for Nokia 8xx
  tablets it seems. CCed Tony Lindgren,  Juha and Viktor.
  
  http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blob;f=security/lowmem.c;h=ae78a530af39703e335ad769f1e6f097f63ec6dd;hb=HEAD
 
 As we can't stack LSMs, using the lsm interface for a simple memory
 driver seems pretty wasteful :)
 
The heuristics and tunables are more what ended up being useful with this
module, which could trivially be abstracted out. The focus of the lowmem
module was mostly giving userspace an opportunity to change its behaviour,
and to try to save critical state. I don't know how well this would map
to the Android use cases, though.
--
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

musb bogosity

[Paul Mundt]

The musb code currently kills the SH randconfig build (and this will hose
any platform that also selects HAVE_CLK -- a PPC or AVR32 randconfig
would have also hit this eventually), as can be seen here:

http://kisskb.ellerman.id.au/kisskb/buildresult/41095/

This initial failure comes from the fact that musb handily uses special
I/O routines that it handily wraps, after having failed at grepping for
other users. Why this driver isn't using ioread/writeXX_rep() is beyond
me, as that's the portable interface we have for doing precisely this
sort of thing, without this bizarre PIO/MMIO wrapper munging that isn't
even going to work on most platforms.

With that ifdef in place, it's on to the next integral build failure:

drivers/usb/musb/musb_core.c: In function 'fifo_setup':
drivers/usb/musb/musb_core.c:1122: error: 'MUSB_C_RAM_BITS' undeclared (first 
use in this function)
drivers/usb/musb/musb_core.c:1122: error: (Each undeclared identifier is 
reported only once
drivers/usb/musb/musb_core.c:1122: error: for each function it appears in.)
drivers/usb/musb/musb_core.c: In function 'ep_config_from_table':
drivers/usb/musb/musb_core.c:1246: error: 'MUSB_C_RAM_BITS' undeclared (first 
use in this function)
drivers/usb/musb/musb_core.c: In function 'musb_remove':
drivers/usb/musb/musb_core.c:2131: warning: unused variable 'ctrl_base'
make[1]: *** [drivers/usb/musb/musb_core.o] Error 1
make: *** [drivers/usb/musb/musb_core.o] Error 2

...

$ git grep MUSB_C_RAM_BITS drivers/usb/musb
drivers/usb/musb/musb_core.c:#define DYN_FIFO_SIZE (1(MUSB_C_RAM_BITS+2))
drivers/usb/musb/tusb6010.h:#define MUSB_C_RAM_BITS 12

...

the comment above MUSB_C_RAM_BITS seems to suggest that it's entirely dependent
on the chip, so moving it in to musb_core.c wouldn't be terribly productive. 
Which
leaves us in a situation where the core is dependent on arbitrary driver
definitions, while the driver itself is obviously only dependent on the core.
Has anyone actually tested this with TUSB6010 support disabled?

A quick grep suggests that blackfin is also going to get bitten by this, so
simply tossing a depends on (ARM  BROKEN) in wouldn't help matters either.

---

diff --git a/drivers/usb/musb/musb_io.h b/drivers/usb/musb/musb_io.h
index 6bbedae..d0f812a 100644
--- a/drivers/usb/musb/musb_io.h
+++ b/drivers/usb/musb/musb_io.h
@@ -37,7 +37,7 @@
 
 #include linux/io.h
 
-#ifndefCONFIG_ARM
+#if !defined(CONFIG_ARM)  !defined(CONFIG_SUPERH)
 static inline void readsl(const void __iomem *addr, void *buf, int len)
{ insl((unsigned long)addr, buf, len); }
 static inline void readsw(const void __iomem *addr, void *buf, int len)


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: musb bogosity

[Paul Mundt]

On Fri, Aug 08, 2008 at 12:04:45PM +0300, Felipe Balbi wrote:
 On Fri, Aug 08, 2008 at 11:32:45AM +0300, Felipe Balbi wrote:
   other users. Why this driver isn't using ioread/writeXX_rep() is beyond
 
 I'll try to fix io routines asap. From your next mail I could see that
 it's really bogus :-p
 
   drivers/usb/musb/musb_core.c: In function 'fifo_setup':
   drivers/usb/musb/musb_core.c:1122: error: 'MUSB_C_RAM_BITS' undeclared 
   (first use in this function)
   drivers/usb/musb/musb_core.c:1122: error: (Each undeclared identifier is 
   reported only once
   drivers/usb/musb/musb_core.c:1122: error: for each function it appears 
   in.)
   drivers/usb/musb/musb_core.c: In function 'ep_config_from_table':
   drivers/usb/musb/musb_core.c:1246: error: 'MUSB_C_RAM_BITS' undeclared 
   (first use in this function)
   drivers/usb/musb/musb_core.c: In function 'musb_remove':
   drivers/usb/musb/musb_core.c:2131: warning: unused variable 'ctrl_base'
   make[1]: *** [drivers/usb/musb/musb_core.o] Error 1
   make: *** [drivers/usb/musb/musb_core.o] Error 2
 
 Below is the patch that fixes it.
 
 I don't have sh cross-compilers, so if you could try it out and be sure
 it works, I'd be glad.
 
Yes, that fixes that problem at least, thanks.

Now the I/O bits are the only outstanding issue, as I still need the
CONFIG_SUPERH test in musb_io.h to get around conflicting definitions.

Presently ARM and SH are the only ones that define the readsl() variants
anyways, so stubbing in an extra ifdef there is fine as a temporary
measure, but it's not a long-term solution. The only reason SH defines
them at all is because we ran in to this exact same problem the last time
an ARM driver tried passing itself off as generic ;-)

  cut here 
 
 From 0bbc416e8170c4169608f7496b8d67be3828d76b Mon Sep 17 00:00:00 2001
 From: Felipe Balbi [EMAIL PROTECTED]
 Date: Fri, 8 Aug 2008 11:39:41 +0300
 Subject: [PATCH] usb: musb: pass configuration specifics via pdata
 
 Use platform_data to pass musb configuration-specific
 details to musb driver.
 
 This patch will prevent that other platforms selecting
 HAVE_CLK and enabling musb won't break tree building.
 
 The other parts of it will come when linux-omap merge
 up more omap2/3 board-files.
 
 Signed-off-by: Felipe Balbi [EMAIL PROTECTED]

Acked-by: Paul Mundt [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] IRQ: simplify OMAP2 mask_irq/unmask_irq code

[Paul Mundt]

On Tue, May 20, 2008 at 06:12:04PM -0600, Paul Walmsley wrote:
 On Wed, 21 May 2008, Kyungmin Park wrote:
  On Wed, May 21, 2008 at 3:21 AM, Paul Walmsley [EMAIL PROTECTED] wrote:
  
static void omap_mask_irq(unsigned int irq)
{
   -   int offset = (irq  5)  5;
   +   int offset = irq  (~(IRQ_BITS_PER_REG - 1));
  
   -   if (irq = 64)
   -   irq %= 64;
   -   else if (irq = 32)
   -   irq %= 32;
   +   irq %= IRQ_BITS_PER_REG;
  
  Is it the right conversion?
  If the irq is greater then 32 and less then or equal to  64 it's
  result is different.
  E.g, If irq is 63 then original irq is 63, but new code is 31
 
 Hmm, in that condition, the result looks the same to me: irq % 32, either 
 way?
 
 More practically, if you look at what it does with that irq variable 
 afterwards, it seems to be a bug if irq is ever greater than 31:
 
 intc_bank_write_reg(1  irq, irq_banks[0], INTC_MIR_CLEAR0 + 
 offset);
 
 I think the only case where the new code would work differently than the 
 previous code is if irq  95.  But that would be a bug, since the shift 
 value would then be  32, for a 32-bit register.
 
  And if this code is right, how about to use mask instead of modulo op?
  irq = (IRQ_BITS_PER_REG - 1);
 
 Hehe, very good point, that would probably save even more cycles!  If you 
 agree with the above, perhaps I can convert the code to use that also, 
 and add your Signed-off-by also?
 
Kyungmin's idea looks good to me. If you roll the two together, feel free
to add my Acked-by also.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html