RE: [PATCH 1/2 v2] usb: otg: OMAP4430: Fixing the omap4430_phy_init function
Hi, >-Original Message- >From: Tony Lindgren [mailto:t...@atomide.com] >Sent: Thursday, March 31, 2011 12:17 AM >To: Hema Kalliguddi >Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Felipe Balbi >Subject: Re: [PATCH 1/2 v2] usb: otg: OMAP4430: Fixing the >omap4430_phy_init function > >* Hema Kalliguddi [110328 23:11]: >> Hi, >> >> >-Original Message- >> >From: Tony Lindgren [mailto:t...@atomide.com] >> >Sent: Tuesday, March 29, 2011 2:50 AM >> >To: Hema HK >> >Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org >> >Subject: Re: [PATCH 1/2 v2] usb: otg: OMAP4430: Fixing the >> >omap4430_phy_init function >> > >> >* Hema HK [110324 04:36]: >> >> omap4430_phy_init() function can be called with no device pointer, >> >> to powerdown the PHY during board init when USB is disabled. >> >> Fix the function accordingly. >> > >> >This should no longer be needed after merge commit >> >0df0914d414a504b975f3cc66ace0c16ef55b7f3. >> >> I did not get how the above commit help to fix it. > >Ah it's not there. Well IMHO omap4430_phy_init(dev) should >not get called before dev is initialized in usb_musb_init. > >So it should get called only after the get_device(dev) call. Right. I think this was merge issue. When USB is enabled, it should be ideally called only after the device build. But this patch required for the case when USB is not not enabled, there will not be a device built at all. But need to powerdown the PHY. Regards, Hema > >Regards, > >Tony > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Wed, 30 Mar 2011, da...@lang.hm wrote: > On Wed, 30 Mar 2011, Nicolas Pitre wrote: > > > As long as SOC vendors keep producing wildly different architectures > > besides the core CPU we'll have this problem. Denying the reality won't > > make that problem go away either. And device tree won't stop those > > vendor from still trying to do things differently (better?) because they > > are not constrained by having to ensure this single proprietary software > > stack still boot. > > the thing that you are not convincing us of is that all these different SoCs > are so wildly different architectures. You can have a look at the code. It is all there. And the different GPIO controllers are just the tip of the iceberg. But by all means if you actually find a way to abstract most differences between those SOCs then please say so. Many people tried already. Maybe they weren't smart enough. > back in the early days of the PCs, different systems from different vendors > had different bus types, peripherals at different addresses, etc. that didn't > make all of those vendors systems different architectures, instead those > things were varients of the x86 architecture. Most of them didn't survive. That really helps. > with ARM you do have a couple different architectures (arm5 vs arm7 for > example), That's the easy part. Well not necessarily that easy, but RMK did a damn good job of it and looking at the result you may think that was easy. > but what you are hearing people say is that > > arm7+IPblock1+IPblock2 > arm7+IPblock1+IPblock3> > arm7+IPblock2+IPblock3> > > are not three different architectures, they are one architecture with > different devices attached. > > what's more, you seem to be saying that > > arm7+IPblock1 > > and > > arm7+IPblock1 > > are different architectures if the wiring between the arm core and IPblock1 > are different (they are different 'boards' or different chip models, possibly > from different manufacturers) That's again the easy part. If that was all that simple we would be all happy campers. > I see the variations here as a good thing, just like having a huge number of > pluggable cards in a PC was a good thing (even though it made it hard to have > an OS that supports every card out there) What we have here is more like a large number of PCs, each one with a different set of cards. The different SOCs are like PCs, and the cards are those set of peripherals to be found in those SOCs. But it is not just about peripherals, and system level things like timers and interrupt controllers. It is also about the huge complexity put into the hardware for power management. you will find different clocks/PLLs, power domains and regulators, and that has to be intermixed with various sleep states, wake sources and conditions, etc. And no ressemblance is to be found between different vendors for those pm features unfortunately. Even with a common high level abstraction (which abstraction is still being worked on) you will still need the backend code to interface with the hardware. Maybe someday the optimal (or even just good enough) power management hardware infrastructure will be found and everybody will standardize on that. But we're apparently not there yet. > in the case of the PC, systems that were too different died off, systems that > could have their differences abstracted into different drivers prospered. Maybe that will happen eventually. In the mean time they are rather all successful despite the major hardware discrepancies because the kernel is Open Source and it is relatively easy for each vendor to hack the kernel until it works on their own hardware. User space is largely unaffected so the kernel becomes the actual abstraction. > I am _not_ saying that all arm systems need to standardize on one interrupt > controller, I wish they had. > I am saying that the kernel support for ARM needs to be able to > _easily_ be told that this chip has interrupt chip type 24 connected this way, > and interrupt chip type 87 connected that way, without needing to create a new > architecture. But then we have the next SOC coming up with yet another IRQ controller built into it. So yet more code is required to deal with it. Amongst the 15 ARM vendors or so, no IRQ controller is the same. > If the kernel is compiled with the appropriate drivers, it > should even be able to be done without needing to recompile the kernel. Obviously. And that's not a problem. The problem is to actually support all the different hardware blocks. Hence the volume of code out there. If you do configure your kernel for one specific target which has a specific SOC implying a specific IRQ, timer, GPIO, clock, power, memory and peripheral bus, then you'll end up using relatively few lines of code from the arch/arm/ directory. If instead you want support for a SOC from another vendor, then you'll need a different set of source code similar to the
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, 31 Mar 2011, Geert Uytterhoeven wrote: > On Thu, Mar 31, 2011 at 01:31, Nicolas Pitre wrote: > > On ARM there is simply not such thing as a single machine design to > > clone, and a closed source test bench to design for. > > There are other architectures that didn't start from a single root platform, > but still support multi-platform kernels. Sure, so does ARM with some restrictions. Nicolas -- 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: OMAP4 DSS clock setup
On Wed, 2011-03-30 at 15:21 +0200, Cousson, Benoit wrote: > On 3/30/2011 2:58 PM, Valkeinen, Tomi wrote: > > Anyway. To get things working for rc2 (DSS currently crashes due to not > > enabling dss_clk) we need to either: > > 1) Change the clock aliases as above > > Changing the clock alias for my point of view is like hacking the HW > definition to fit your need. Even if this is temporary, I do not like > that approach. > > > 2) Add something like Sumit's patch (attached) to handle dss_clk. While > > the patch is not that complex, it feels rather hacky. > > Yes, I'd rather hack that issue internally, because this is something > you should fix as soon as you switch to PM runtime. > > > What's your opinion? > > Definitively #2. Ok, let's go with that. I don't like it but hopefully pm_runtime will clear the mess from dss driver. Thanks for your time explaining the clock setup to me =) 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: [GIT PULL] omap changes for v2.6.39 merge window
* Nicolas Pitre wrote: > On Wed, 30 Mar 2011, da...@lang.hm wrote: > > > back in the early days of the PCs, different systems from different vendors > > had different bus types, peripherals at different addresses, etc. that > > didn't > > make all of those vendors systems different architectures, instead those > > things were varients of the x86 architecture. > > Most of them didn't survive. That really helps. That's not the point, 99% of the current ARM boards will not 'survive' either, 10-20 years down the road. I think you missed David's main point: life inevitably went on and few of the old x86 hardware 'survived' physically, but past hardware versions have not littered the kernel source with half a million lines of source code in the process ... Having strong, effective platform abstractions inside the kernel really helps even if the hardware space itself is inevitably fragmented: both powerpc and x86 has shown that. Until you realize and appreciate that you really have not understood the problem i think. Thanks, Ingo -- 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 changes for v2.6.39 merge window
On Wed, Mar 30, 2011 at 10:05:41PM -0700, da...@lang.hm wrote: > with ARM you do have a couple different architectures (arm5 vs arm7 for > example), but what you are hearing people say is that > > arm7+IPblock1+IPblock2 > arm7+IPblock1+IPblock3> > arm7+IPblock2+IPblock3> > > are not three different architectures, they are one architecture with > different devices attached. Wrong. Let's take an example. If you have an OMAP SoC with ARMv7 + GIC + OMAP timer, and another SoC (eg, MSM) with GIC + their own timer, then the common code will be used to support ARMv7 on both SoCs. The common GIC support code will be used to talk to the GIC interrupt controller. The OMAP timer code will be used to handle the OMAP timer, and the MSM timer code will be used to handle the MSM timer. We're not crazy. We don't have N sets of code implementing support for the GIC interrupt controller. Same happens for the VIC code - we have common code supporting VIC implementations across the different SoCs which have a VIC. But the GIC is a totally different beast to the VIC. The GIC is SMP capable and has two software interfaces - the CPU local part and the CPU global part. The VIC doesn't have any of that as it is UP only. They function entirely differently. How can you have some common code to support both of those? > what's more, you seem to be saying that > > arm7+IPblock1 > > and > > arm7+IPblock1 > > are different architectures if the wiring between the arm core and > IPblock1 are different (they are different 'boards' or different chip > models, possibly from different manufacturers) Over the years which I was overseeing platform support I tried to ensure as much sharing of code across different platforms. I no longer oversee platform specific stuff, and so its entirely possible that several SoCs have the same IP block but their own code to drive it. That's where Thomas is right - we need a team of people to provide review of that to catch it and get it consolidated. Such a team would need funding. Where does that funding come from? I've no idea. This review issue is something which I've been on about for the last ten years, and it hasn't really got much better during that time. We also need the various SoC designers and ARM architecture people to realise that what the hardware situation is rediculous; I have commented about this lack of standardisation to ARM in past years. ARM have had a standard set of peripherals for ten years, but the SoC people haven't really taken them up - and when they do, they seem to always introduce their own tweaks, sometimes with no way to detect those tweaks. So far, I've avoided merging code to change the way the driver support works for those peripherals to allow the platform level code to describe those differences because I don't like it. It sounds like I should continue to avoid merging it and, hopefully, it'll just go away. -- 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 00/10] omap init_early changes for irq and timer init
On 3/30/2011 11:52 PM, Tony Lindgren wrote:
* Santosh Shilimkar [110330 00:53]:
After going through entire series again, it looks very
good clean-up and right step towards moving rest of
the timer to drivers/ directory.
I also realized that the discussion we had before this series was
because of miss-understating about the 'wakeu_up' timer
terminology. After this series I see that you were mentioning
about the pm debug timer where as I was taling about
clock-event wakeups from CPUidle point of view.
Well this patcheset keeps the current behaviour, except for
the PM debug hack to program gpt1.
This is the problem what I see.
What it does not have is the code to dedicate gpt1 for PM
code, which can be done later once all the other dmtimer
changes are done.
Which not possible to do unless you plan to hack generic
timer framework or waste additional timer hardware for
this.
So the earlier discussion is still a separate issue from the
PM debug hack removed in this series. I'll post some patches
later on for that.
No that discussion become relevant with this series now.
I still have few concerns about this series.
1)We have removed the flexibility if choosing the timer from
from board files and hard-coded them in platform timer
header.
Well it's not removed, you can still select the timer setup
by setting .timer entry in the board-*.c file.
So for example, we have omap3_timer and omap3_beagle_timer
for the beagle rev a& b based boards.
This is exactly my point. This is the board specific data which
is now getting moved to generic headers.
Below board related hard-coding in platform files looks more
hacky and the interface done by Pual still has a merits of
its own.
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -34,7 +34,12 @@
struct sys_timer;
extern void omap_map_common_io(void);
-extern struct sys_timer omap_timer;
+extern struct sys_timer omap1_timer;
+extern struct sys_timer omap242x_timer;
+extern struct sys_timer omap243x_timer;
+extern struct sys_timer omap3_timer;
+extern struct sys_timer omap3_beagle_timer;
+extern struct sys_timer omap4_timer;
extern bool omap_32k_timer_init(void);
extern int __init omap_init_clocksource_32k(void);
extern unsigned long long notrace omap_32k_sched_clock(void);
Hmm the only reason for omap3_beagle_timer naming is the
hardware bug in rev a& b beagle boards.
+/*
+ * Beagle based designs typically have an issue with gptimer1. Also note
+ * that GPTIMER12 can only use the secure 32KiHz clock source.
+ */
static void __init omap3_beagle_timer_init(void)
{
omap_dm_timer_init();
- omap2_gp_clockevent_init();
+ omap2_gp_clockevent_init(OMAP3_BEAGLE_TIMER, OMAP3_CLKEV_SOURCE);
omap2_gp_clocksource_init();
}
Got any better name in mind for that timer?
For removing the old interface, I don't see any reason to
select timer combinations on omap3 other than omap3_timer
and omap3_beagle_timer.
If there's need, any new valid sane combinations can be esily
added, although I seriously doubt that we'll need more for
omap3.
May be I am wrong but the point is about the merit of the
solution even if there are only couple of board files where
we use that interface.
It much cleaner and simpler to say timerid=X, from board
file rather than creating a "struct sys_timer" instance
and putting that in timer code.
2) In patch [6/10], you have removed wakeup timer debug
capability with comment "Later on we can reserve gptimer1
for PM code only and have similar functionality".
I don't know how this will work on OMAP. GPTIMER1 is the
only timer which is in always on power domain and wakeup
OMAP from deeper power states like CORE OSWR, CORE OFF,
DEVICE OFF.
Right, that's why the PM code should manage it for the wake-up
events. For the clockevent and clocksource we just want to
use something fast for the runtime.
Then when we hit idle, we can just let PM code program gpt1
for the wake-up event.
We do implement these C-state in CPUidle as well and hence
the clock-event is expected to be of wakeup-capable.
Hence GPTIMER1 is already reserved for clock-event.
The PM code can easily deal with gpt1 by either calling
next_timer_interrupt, or just by cloning the clockevent
timer value. But again, that's a separate patch series
to come..
The wakeup timer used was only in suspend scenario's
and that point of time the timer system is already
suspended. So during that even if TIMER1 is re-used
for wakeup (which is the case), I don't see any issue.
The reason is that for performance and latency reasons
we want to use localtimers for runtime on omap4+, and
need only gpt1 for PM wake-up.
This is already the case with or without this series.
The gpt1 using 32KiHz source clock is a very slow clock
to reprogram as it's on the external bus.
Even its slow, to make CPUIDLE work in low power modes and
you need this clock-event as well. This is where the
gener
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, Mar 31, 2011 at 10:06:34AM +0200, Ingo Molnar wrote: > Having strong, effective platform abstractions inside the kernel really helps > even if the hardware space itself is inevitably fragmented: both powerpc and > x86 has shown that. Until you realize and appreciate that you really have not > understood the problem i think. No, I think it is the other way around. Folk like me and Nicolas over the last ten years have put considerable amounts of effort into trying to keep the ARM support code as clean and maintainable as possible. That is true of the common ARM stuff, but there's no way we can do this for all SoC support - there aren't the hours in the day to provide such a wide oversight. That's why we have SoC maintainers, and the SoC maintainers have the responsibility to sort out their own sub-trees. -- 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: [pm-core][PATCH v3 02/21] OMAP4: Use WARN_ON() instead of BUG_ON() with graceful exit
On 3/29/2011 2:23 AM, Tony Lindgren wrote: * Santosh Shilimkar [110328 02:20]: OMAP L2X0 and GIC initialisation code uses BUG_ON() for the ioremap() failure scenarios. Use WARN_ON() instead and allow graceful function exits. This was suggsted by Kevin Hilman during OMAP4 PM code review. Signed-off-by: Santosh Shilimkar Cc: Kevin Hilman --- arch/arm/mach-omap2/omap4-common.c |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c index 559d227..8f9b97d 100644 --- a/arch/arm/mach-omap2/omap4-common.c +++ b/arch/arm/mach-omap2/omap4-common.c @@ -36,11 +36,13 @@ void __init gic_init_irq(void) /* Static mapping, never released */ gic_dist_base_addr = ioremap(OMAP44XX_GIC_DIST_BASE, SZ_4K); - BUG_ON(!gic_dist_base_addr); + if (WARN_ON(!gic_dist_base_addr)) + return; /* Static mapping, never released */ gic_cpu_base = ioremap(OMAP44XX_GIC_CPU_BASE, SZ_512); - BUG_ON(!gic_cpu_base); + if (WARN_ON(!gic_cpu_base)) + return; omap_wakeupgen_init(); @@ -68,7 +70,8 @@ static int __init omap_l2_cache_init(void) /* Static mapping, never released */ l2cache_base = ioremap(OMAP44XX_L2CACHE_BASE, SZ_4K); - BUG_ON(!l2cache_base); + if (WARN_ON(!l2cache_base)) + return -ENODEV; /* * 16-way associativity, parity disabled Hmm to me it seems that if any of these we don't want to continue. L2 cache is no problem and kernel can boot without L2 cache support. I agree with you on interrupt controller init though. Will drop the interrupt related checks from this patch. Kevin, Are you ok with it ? Regards Santosh -- 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: OMAP4 DSS clock setup
Hi Archit, On 3/31/2011 8:42 AM, Taneja, Archit wrote: On Wednesday 30 March 2011 06:51 PM, Cousson, Benoit wrote: On 3/30/2011 2:58 PM, Valkeinen, Tomi wrote: On Wed, 2011-03-30 at 14:12 +0200, Cousson, Benoit wrote: On 3/30/2011 1:03 PM, Valkeinen, Tomi wrote: On Wed, 2011-03-30 at 11:32 +0200, Cousson, Benoit wrote: Hi Tomi, On 3/30/2011 8:48 AM, Valkeinen, Tomi wrote: Hi Benoit, Paul, I've been discussing with Sumit and Archit to understand how the DSS clocks are set up on OMAP4. I think I now have some idea how things work, but I'm still at loss why things are the way they are. So, if I look at OMAP4 TRM, Figure 10-4 DSS Clock Tree, there are two clocks in PRCM block that are relevant to this discussion: DSS_L3_ICLK and DSS_FCLK. To my understanding DSS_L3_ICLK is not really controllable, but it is affected by MODULEMODE bit. Then we have two relevant clocks defined in clock44xx_data.c: dss_fck and dss_dss_clk. dss_fck controls the MODULEMODE bit, and dss_dss_clk is the TRM's DSS_FCLK. Was that correct? Yes. For the moment, but this is not the final state. If so, from DSS driver's perspective, the dss_fck sounds very much like an interface clock (it's always needed when DSS is used) and dss_dss_clk sounds very much like functional clock (it's always needed, except if DSI PLL is used for DSS functional clock). dss_dss_fck is one of the possible functional clocks, hence the optional attribute. You can run the DSS only for sys_clk is you want. We can? I remember this was possible on OMAP2, but I can't seem to find it on OMAP4 TRM... Ah right, you mean sys_clk goes to DSI PLL, and the output from DSI PLL can be used as functional clock? Yes, you're right, maybe we can still use the sys_clk directly with a parallel QVGA LCD like on OMAP2:-) We _always_ need DSS_FCLK to get DSS up and running, and to configure DSI PLL if we want to get the clocks from there. So it's not quite that optional. But it's true that we can turn it off later. Just wanted to clarify the issue for myself and summarise: hwmod and pm runtime ensures that the MODULEMODE bits are set, and technically, that should be enough for a module to get up and running. But because of the strange design of DSS HW, we need an additional clock (DSS_CLK at bootup, could be something else later on) to access DSS registers. So we need to enable dss_dss_fclk in our driver in the beginning itself to access a register, hence Sumit's patch is needed. The strange thing is that if dss_dss_fclk is off(OMAP4430_OPTFCLKEN_DSSCLK bit is 0) it doesn't mean that the clock is surely OFF. Its only OFF when the DPLL per m5x2 divider allows HW auto-gating of the clock. Hehe, welcome to the PRCM world :-) So OPTCLKEN_DSSCLK is in a way a dummy bit which when set, ensures that the M5 divider doesn't auto gate. So it isn't exactly a enable/disable bit. It is the case for most clocks in the system. You know when it is enabled, but it will be disabled only when the clock domain or in that case the parent clock will do HW auto gating. In this case there is no intermediate gating because the DSS_CLK is the only user of the M5 HW divider output, so gating only the parent is enough. In our tree(2.6.38-rc series), HW auto gating bit was disabled for m5x2 divider, and hence, it never mattered to us if OPTCLKEN_DSSCLK was enabled or disabled. We went on happily without bothering about this opt clock. When things got merged in mainline, the HW auto gating for m5x2 came into picture(HSDIVIDER_CLKOUT2_GATE_CTRL in CM_DIV_M5_DPLL_PER), and then suddenly dss_dss_fclk became super crucial, and a register access depended on it. This was the main reason of the confusion I guess. That make sense now, in theory, all these HS divider should be autogated by default, it was not the case previously because we were still in a non-PM optimize mode. That's why you have to control the clock at your level to ensure that the HW will not gate the parent clock. 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: [GIT PULL] omap changes for v2.6.39 merge window
> Absolutely. On Intel, it is (still) Windows the reference. If Windows > doesn't boot on your motherboard you have a problem. So motherboard > vendors won't make crazy incompatible things. They are constrained to OLPC, Moorestown ? > fix their hardware because they just cannot alter Windows to suit their > hardware differences. That really helps keeping actual differences to a > minimum and only to things that are not fundamental. So Windows really > helped making a uniform hardware platform on X86. That and the fact the Microsoft driver validation has driven a lot of standardisation along the "we could write a driver and go through WHQL and ... and ..." or we could just use a standard interface. Thing is though - the x86 platform does change, modern PC systems are very different to old ones (different IRQ controllers, different power management, different processor features, different bus interfaces, different firmware, ...) but someone bothered to make these *discoverable*. If I boot a Linux kernel on an AMD K6 I'm running with an 8259 interrupt controller, 8254/5 supporting I/O, a PC style keyboard controller, graphics via PCI or maybe AGP using memory on the card mostly, a one command at a time ATA interface based on WD1010 registers, APM based firmware that implements an extended version of the PC BIOS. If I boot it on a current PC I'm booting on a multiprocessor system with different timers, totally different IRQ controllers, different keyboard controllers (USB), PCI Express, an IOMMU, NCQ SATA, ACPI, graphics running in shared host memory able to give/take pages from the host, extra instructions, etc etc And the same kernel boots just fine on both just fine. -- 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 0/9] Miscellaneous OMAP DSS patches
Some miscellaneous DSS patches. Quite minor fixes/cleanups, except "Remove implicit display update on unblank" which does have some functional impact. Jani Nikula (2): OMAP: DSS2: Add method for querying display dimensions from DSS drivers OMAP: DSS2: OMAPFB: Remove implicit display update on unblank Tomi Valkeinen (7): OMAP: DSS2: move dss device clock configuration OMAP: DSS2: remove non-working msleep(40) workaround OMAP: DSS2: make 50ms bug-fix sleep optional OMAP: DSS2: VENC: make 20ms venc bug-fix sleep optional OMAP: DSS2: VENC: Remove sleeps at venc enable/disable OMAP: DSS2: OMAPFB: Handle errors when initializing panel OMAP: DSS2: VENC: Add missing start/stop_device calls arch/arm/mach-omap2/board-4430sdp.c | 14 +++-- arch/arm/plat-omap/include/plat/display.h | 30 +--- drivers/video/omap2/dss/Kconfig | 23 ++ drivers/video/omap2/dss/dsi.c | 14 ++-- drivers/video/omap2/dss/dss.c |5 ++ drivers/video/omap2/dss/overlay.c | 19 +++-- drivers/video/omap2/dss/venc.c| 21 -- drivers/video/omap2/omapfb/omapfb-ioctl.c | 12 +++- drivers/video/omap2/omapfb/omapfb-main.c | 105 +++-- 9 files changed, 168 insertions(+), 75 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
[PATCH 1/9] OMAP: DSS2: move dss device clock configuration
Clock configuration was defined inside dssdev.phy.dsi struct. The clock
config doesn't really belong there, and so it's moved to dssdev.clock
struct.
Now the explicit clock configuration could also be used for other
interfaces than DSI, although there's no support for it currently.
Signed-off-by: Tomi Valkeinen
---
arch/arm/mach-omap2/board-4430sdp.c | 14 +-
arch/arm/plat-omap/include/plat/display.h | 28
drivers/video/omap2/dss/dsi.c | 14 +++---
3 files changed, 32 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 05288c9..626b16b 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -766,17 +766,21 @@ static struct omap_dss_device sdp4430_lcd_device = {
.data1_pol = 0,
.data2_lane = 3,
.data2_pol = 0,
- .div= {
+ },
+
+ .clocks = {
+ .dispc = {
+ .lck_div= 1,/* Logic Clock = 172.8 MHz */
+ .pck_div= 5,/* Pixel Clock = 34.56 MHz */
+ },
+
+ .dsi = {
.regn = 16, /* Fint = 2.4 MHz */
.regm = 180, /* DDR Clock = 216 MHz */
.regm_dispc = 5,/* PLL1_CLK1 = 172.8 MHz */
.regm_dsi = 5,/* PLL1_CLK2 = 172.8 MHz */
.lp_clk_div = 10, /* LP Clock = 8.64 MHz */
-
- .lck_div= 1,/* Logic Clock = 172.8 MHz */
- .pck_div= 5,/* Pixel Clock = 34.56 MHz */
-
},
},
.channel= OMAP_DSS_CHANNEL_LCD,
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index 5e04ddc..e10cfe2 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -401,18 +401,6 @@ struct omap_dss_device {
u8 data2_lane;
u8 data2_pol;
- struct {
- u16 regn;
- u16 regm;
- u16 regm_dispc;
- u16 regm_dsi;
-
- u16 lp_clk_div;
-
- u16 lck_div;
- u16 pck_div;
- } div;
-
bool ext_te;
u8 ext_te_gpio;
} dsi;
@@ -424,6 +412,22 @@ struct omap_dss_device {
} phy;
struct {
+ struct {
+ u16 lck_div;
+ u16 pck_div;
+ } dispc;
+
+ struct {
+ u16 regn;
+ u16 regm;
+ u16 regm_dispc;
+ u16 regm_dsi;
+
+ u16 lp_clk_div;
+ } dsi;
+ } clocks;
+
+ struct {
struct omap_video_timings timings;
int acbi; /* ac-bias pin transitions per interrupt */
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 23d9bbe..7304c87 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1026,7 +1026,7 @@ static int dsi_set_lp_clk_divisor(struct omap_dss_device
*dssdev)
unsigned lp_clk_div;
unsigned long lp_clk;
- lp_clk_div = dssdev->phy.dsi.div.lp_clk_div;
+ lp_clk_div = dssdev->clocks.dsi.lp_clk_div;
if (lp_clk_div == 0 || lp_clk_div > dsi.lpdiv_max)
return -EINVAL;
@@ -3388,10 +3388,10 @@ static int dsi_configure_dsi_clocks(struct
omap_dss_device *dssdev)
/* we always use DSS_CLK_SYSCK as input clock */
cinfo.use_sys_clk = true;
- cinfo.regn = dssdev->phy.dsi.div.regn;
- cinfo.regm = dssdev->phy.dsi.div.regm;
- cinfo.regm_dispc = dssdev->phy.dsi.div.regm_dispc;
- cinfo.regm_dsi = dssdev->phy.dsi.div.regm_dsi;
+ cinfo.regn = dssdev->clocks.dsi.regn;
+ cinfo.regm = dssdev->clocks.dsi.regm;
+ cinfo.regm_dispc = dssdev->clocks.dsi.regm_dispc;
+ cinfo.regm_dsi = dssdev->clocks.dsi.regm_dsi;
r = dsi_calc_clock_rates(dssdev, &cinfo);
if (r) {
DSSERR("Failed to calc dsi clocks\n");
@@ -3415,8 +3415,8 @@ static int dsi_configure_dispc_clocks(struct
omap_dss_device *dssdev)
fck = dsi_get_pll_hsdiv_dispc_rate();
- dispc_cinfo.lck_div = dssdev->phy.dsi.div.lck_div;
- dispc_cinfo.pck_div = dssdev->phy.dsi.div.pck_div;
+ dispc_cinfo.lck_div = dssdev->clocks.dispc.lck_div;
+ dispc_cinfo.pck_div = dssdev->clocks.dispc.pck_div;
r = dispc_calc_clock_rates(fc
[PATCH 2/9] OMAP: DSS2: remove non-working msleep(40) workaround
The sleep workaround for the problem described in the comment doesn't really work. This patch removes the workaround, and improves the comment about the bug, and proposes an userspace workaround. omap_dss_set_manager() is called 6 times when loading omapdss and omapfb, which means that 40ms * 6 = 240ms was spent sleeping when booting up. Signed-off-by: Tomi Valkeinen --- drivers/video/omap2/dss/overlay.c | 19 --- 1 files changed, 12 insertions(+), 7 deletions(-) diff --git a/drivers/video/omap2/dss/overlay.c b/drivers/video/omap2/dss/overlay.c index f1aca6d..fcde51b 100644 --- a/drivers/video/omap2/dss/overlay.c +++ b/drivers/video/omap2/dss/overlay.c @@ -491,13 +491,18 @@ static int omap_dss_set_manager(struct omap_overlay *ovl, ovl->manager = mgr; dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK); - /* XXX: on manual update display, in auto update mode, a bug happens -* here. When an overlay is first enabled on LCD, then it's disabled, -* and the manager is changed to TV, we sometimes get SYNC_LOST_DIGIT -* errors. Waiting before changing the channel_out fixes it. I'm -* guessing that the overlay is still somehow being used for the LCD, -* but I don't understand how or why. */ - msleep(40); + /* XXX: When there is an overlay on a DSI manual update display, and +* the overlay is first disabled, then moved to tv, and enabled, we +* seem to get SYNC_LOST_DIGIT error. +* +* Waiting doesn't seem to help, but updating the manual update display +* after disabling the overlay seems to fix this. This hints that the +* overlay is perhaps somehow tied to the LCD output until the output +* is updated. +* +* Userspace workaround for this is to update the LCD after disabling +* the overlay, but before moving the overlay to TV. +*/ dispc_set_channel_out(ovl->id, mgr->id); dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK); -- 1.7.1 -- 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 3/9] OMAP: DSS2: make 50ms bug-fix sleep optional
For some unknown reason we may get SYNC_LOST errors from the display subsystem at initialization time if we don't sleep before resetting the DSS. See the source (dss.c) for more comments. However, 50ms is quite long time to sleep, and with some configurations the SYNC_LOST may never happen, so this patch creates a Kconfig option to disable the sleep. Signed-off-by: Tomi Valkeinen --- drivers/video/omap2/dss/Kconfig | 11 +++ drivers/video/omap2/dss/dss.c |5 + 2 files changed, 16 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig index bfc5da0..458cfe1 100644 --- a/drivers/video/omap2/dss/Kconfig +++ b/drivers/video/omap2/dss/Kconfig @@ -125,4 +125,15 @@ config OMAP2_DSS_MIN_FCK_PER_PCK Max FCK is 173MHz, so this doesn't work if your PCK is very high. +config OMAP2_DSS_SLEEP_BEFORE_RESET + bool "Sleep 50ms before DSS reset" + default y + help + For some unknown reason we may get SYNC_LOST errors from the display + subsystem at initialization time if we don't sleep before resetting + the DSS. See the source (dss.c) for more comments. + + However, 50ms is quite long time to sleep, and with some + configurations the SYNC_LOST may never happen, so the sleep can + be disabled here. endif diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c index 3f1fee6..688947f 100644 --- a/drivers/video/omap2/dss/dss.c +++ b/drivers/video/omap2/dss/dss.c @@ -659,13 +659,18 @@ static int dss_init(void) * the kernel resets it */ omap_writel(omap_readl(0x48050440) & ~0x3, 0x48050440); +#ifdef CONFIG_OMAP2_DSS_SLEEP_BEFORE_RESET /* We need to wait here a bit, otherwise we sometimes start to * get synclost errors, and after that only power cycle will * restore DSS functionality. I have no idea why this happens. * And we have to wait _before_ resetting the DSS, but after * enabling clocks. +* +* This bug was at least present on OMAP3430. It's unknown +* if it happens on OMAP2 or OMAP3630. */ msleep(50); +#endif _omap_dss_reset(); -- 1.7.1 -- 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 4/9] OMAP: DSS2: VENC: make 20ms venc bug-fix sleep optional
There's a 20ms sleep after VENC reset. It's unknown what bug this circumvents and on what platforms. Add a Kconfig option to disable the sleep. Signed-off-by: Tomi Valkeinen --- drivers/video/omap2/dss/Kconfig | 12 drivers/video/omap2/dss/venc.c |3 +++ 2 files changed, 15 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig index 458cfe1..5b45c0c 100644 --- a/drivers/video/omap2/dss/Kconfig +++ b/drivers/video/omap2/dss/Kconfig @@ -136,4 +136,16 @@ config OMAP2_DSS_SLEEP_BEFORE_RESET However, 50ms is quite long time to sleep, and with some configurations the SYNC_LOST may never happen, so the sleep can be disabled here. + +config OMAP2_DSS_SLEEP_AFTER_VENC_RESET + bool "Sleep 20ms after VENC reset" + default y + help + There is a 20ms sleep after VENC reset which seemed to fix the + reset. The reason for the bug is unclear, and it's also unclear + on what platforms this happens. + + This option enables the sleep, and is enabled by default. You can + disable the sleep if it doesn't cause problems on your platform. + endif diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c index 8e35a5b..8c7af90 100644 --- a/drivers/video/omap2/dss/venc.c +++ b/drivers/video/omap2/dss/venc.c @@ -373,8 +373,11 @@ static void venc_reset(void) } } +#ifdef CONFIG_OMAP2_DSS_SLEEP_AFTER_VENC_RESET /* the magical sleep that makes things work */ + /* XXX more info? What bug this circumvents? */ msleep(20); +#endif } static void venc_enable_clocks(int enable) -- 1.7.1 -- 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 5/9] OMAP: DSS2: VENC: Remove sleeps at venc enable/disable
VENC code had 50ms sleep after enabling the output and 100ms sleep after disabling the output. I don't see any reason for these sleeps. Signed-off-by: Tomi Valkeinen --- drivers/video/omap2/dss/venc.c |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c index 8c7af90..fe18800 100644 --- a/drivers/video/omap2/dss/venc.c +++ b/drivers/video/omap2/dss/venc.c @@ -487,9 +487,6 @@ static int venc_panel_enable(struct omap_dss_device *dssdev) dssdev->state = OMAP_DSS_DISPLAY_ACTIVE; - /* wait couple of vsyncs until enabling the LCD */ - msleep(50); - err1: mutex_unlock(&venc.venc_lock); @@ -513,9 +510,6 @@ static void venc_panel_disable(struct omap_dss_device *dssdev) venc_power_off(dssdev); - /* wait at least 5 vsyncs after disabling the LCD */ - msleep(100); - dssdev->state = OMAP_DSS_DISPLAY_DISABLED; end: mutex_unlock(&venc.venc_lock); -- 1.7.1 -- 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 7/9] OMAP: DSS2: OMAPFB: Handle errors when initializing panel
Errors from the panel driver were ignored during panel initialization.
Handle the errors and fail accordingly.
Also move the display initialization to a separate function to make it
cleaner.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/omapfb/omapfb-main.c | 80 ++
1 files changed, 59 insertions(+), 21 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 163fb8b..1b89e28 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2193,6 +2193,61 @@ static int omapfb_parse_def_modes(struct omapfb2_device
*fbdev)
return r;
}
+static int omapfb_init_display(struct omapfb2_device *fbdev,
+ struct omap_dss_device *dssdev)
+{
+ struct omap_dss_driver *dssdrv = dssdev->driver;
+ int r;
+
+ r = dssdrv->enable(dssdev);
+ if (r) {
+ dev_warn(fbdev->dev, "Failed to enable display '%s'\n",
+ dssdev->name);
+ return r;
+ }
+
+ if (dssdev->caps & OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE) {
+ u16 w, h;
+ if (dssdrv->enable_te) {
+ r = dssdrv->enable_te(dssdev, 1);
+ if (r) {
+ dev_err(fbdev->dev, "Failed to set TE\n");
+ return r;
+ }
+ }
+
+ if (dssdrv->set_update_mode) {
+ r = dssdrv->set_update_mode(dssdev,
+ OMAP_DSS_UPDATE_MANUAL);
+ if (r) {
+ dev_err(fbdev->dev,
+ "Failed to set update mode\n");
+ return r;
+ }
+ }
+
+ dssdrv->get_resolution(dssdev, &w, &h);
+ r = dssdrv->update(dssdev, 0, 0, w, h);
+ if (r) {
+ dev_err(fbdev->dev,
+ "Failed to update display\n");
+ return r;
+ }
+ } else {
+ if (dssdrv->set_update_mode) {
+ r = dssdrv->set_update_mode(dssdev,
+ OMAP_DSS_UPDATE_AUTO);
+ if (r) {
+ dev_err(fbdev->dev,
+ "Failed to set update mode\n");
+ return r;
+ }
+ }
+ }
+
+ return 0;
+}
+
static int omapfb_probe(struct platform_device *pdev)
{
struct omapfb2_device *fbdev = NULL;
@@ -2292,30 +2347,13 @@ static int omapfb_probe(struct platform_device *pdev)
}
if (def_display) {
- struct omap_dss_driver *dssdrv = def_display->driver;
-
- r = def_display->driver->enable(def_display);
+ r = omapfb_init_display(fbdev, def_display);
if (r) {
- dev_warn(fbdev->dev, "Failed to enable display '%s'\n",
- def_display->name);
+ dev_err(fbdev->dev,
+ "failed to initialize default "
+ "display\n");
goto cleanup;
}
-
- if (def_display->caps & OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE) {
- u16 w, h;
- if (dssdrv->enable_te)
- dssdrv->enable_te(def_display, 1);
- if (dssdrv->set_update_mode)
- dssdrv->set_update_mode(def_display,
- OMAP_DSS_UPDATE_MANUAL);
-
- dssdrv->get_resolution(def_display, &w, &h);
- def_display->driver->update(def_display, 0, 0, w, h);
- } else {
- if (dssdrv->set_update_mode)
- dssdrv->set_update_mode(def_display,
- OMAP_DSS_UPDATE_AUTO);
- }
}
DBG("create sysfs for fbs\n");
--
1.7.1
--
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 8/9] OMAP: DSS2: OMAPFB: Remove implicit display update on unblank
From: Jani Nikula
Currently omapfb does an implicit display update (for manual update
displays) on unblank.
There is no guarantee that the framebuffer contains a valid image when
unblank is called. When using manual update displays it is the
responsibility of the user space to update the display, and so it should
be in this case also.
This patch removes the implicit display update on unblank.
Signed-off-by: Jani Nikula
[tomi.valkei...@ti.com: improved description]
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/omapfb/omapfb-main.c | 13 -
1 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 1b89e28..1f9cb3a 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1271,7 +1271,6 @@ static int omapfb_blank(int blank, struct fb_info *fbi)
struct omapfb_info *ofbi = FB2OFB(fbi);
struct omapfb2_device *fbdev = ofbi->fbdev;
struct omap_dss_device *display = fb2display(fbi);
- int do_update = 0;
int r = 0;
if (!display)
@@ -1287,11 +1286,6 @@ static int omapfb_blank(int blank, struct fb_info *fbi)
if (display->driver->resume)
r = display->driver->resume(display);
- if (r == 0 && display->driver->get_update_mode &&
- display->driver->get_update_mode(display) ==
- OMAP_DSS_UPDATE_MANUAL)
- do_update = 1;
-
break;
case FB_BLANK_NORMAL:
@@ -1315,13 +1309,6 @@ static int omapfb_blank(int blank, struct fb_info *fbi)
exit:
omapfb_unlock(fbdev);
- if (r == 0 && do_update && display->driver->update) {
- u16 w, h;
- display->driver->get_resolution(display, &w, &h);
-
- r = display->driver->update(display, 0, 0, w, h);
- }
-
return r;
}
--
1.7.1
--
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 9/9] OMAP: DSS2: VENC: Add missing start/stop_device calls
VENC code was missing omap_dss_start/stop_device calls. This didn't
cause any problems as VENC could not be compiled as a module, but
nevertheless it's better to add the calls.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/venc.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index fe18800..b845c56 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -476,6 +476,12 @@ static int venc_panel_enable(struct omap_dss_device
*dssdev)
mutex_lock(&venc.venc_lock);
+ r = omap_dss_start_device(dssdev);
+ if (r) {
+ DSSERR("failed to start device\n");
+ goto err0;
+ }
+
if (dssdev->state != OMAP_DSS_DISPLAY_DISABLED) {
r = -EINVAL;
goto err1;
@@ -487,7 +493,11 @@ static int venc_panel_enable(struct omap_dss_device
*dssdev)
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
+ mutex_unlock(&venc.venc_lock);
+ return 0;
err1:
+ omap_dss_stop_device(dssdev);
+err0:
mutex_unlock(&venc.venc_lock);
return r;
@@ -511,6 +521,8 @@ static void venc_panel_disable(struct omap_dss_device
*dssdev)
venc_power_off(dssdev);
dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
+
+ omap_dss_stop_device(dssdev);
end:
mutex_unlock(&venc.venc_lock);
}
--
1.7.1
--
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 6/9] OMAP: DSS2: Add method for querying display dimensions from DSS drivers
From: Jani Nikula
Add get_dimensions() to struct omap_dss_driver. Use the call, if supported
by the driver, in OMAPFB.
Signed-off-by: Jani Nikula
Signed-off-by: Tomi Valkeinen
---
arch/arm/plat-omap/include/plat/display.h |2 ++
drivers/video/omap2/omapfb/omapfb-ioctl.c | 12 ++--
drivers/video/omap2/omapfb/omapfb-main.c | 12 ++--
3 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index e10cfe2..f6e4b87 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -507,6 +507,8 @@ struct omap_dss_driver {
void (*get_resolution)(struct omap_dss_device *dssdev,
u16 *xres, u16 *yres);
+ void (*get_dimensions)(struct omap_dss_device *dssdev,
+ u32 *width, u32 *height);
int (*get_recommended_bpp)(struct omap_dss_device *dssdev);
int (*check_timings)(struct omap_dss_device *dssdev,
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c
b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 6f43545..b4636b1 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -895,8 +895,16 @@ int omapfb_ioctl(struct fb_info *fbi, unsigned int cmd,
unsigned long arg)
p.display_info.xres = xres;
p.display_info.yres = yres;
- p.display_info.width = 0;
- p.display_info.height = 0;
+
+ if (display->driver->get_dimensions) {
+ u32 w, h;
+ display->driver->get_dimensions(display, &w, &h);
+ p.display_info.width = w;
+ p.display_info.height = h;
+ } else {
+ p.display_info.width = 0;
+ p.display_info.height = 0;
+ }
if (copy_to_user((void __user *)arg, &p.display_info,
sizeof(p.display_info)))
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 505ec66..163fb8b 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -702,8 +702,16 @@ int check_fb_var(struct fb_info *fbi, struct
fb_var_screeninfo *var)
var->xres, var->yres,
var->xres_virtual, var->yres_virtual);
- var->height = -1;
- var->width = -1;
+ if (display && display->driver->get_dimensions) {
+ u32 w, h;
+ display->driver->get_dimensions(display, &w, &h);
+ var->width = DIV_ROUND_CLOSEST(w, 1000);
+ var->height = DIV_ROUND_CLOSEST(h, 1000);
+ } else {
+ var->height = -1;
+ var->width = -1;
+ }
+
var->grayscale = 0;
if (display && display->driver->get_timings) {
--
1.7.1
--
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 changes for v2.6.39 merge window
B1;2401;0cOn Thu, 31 Mar 2011, Nicolas Pitre wrote: > On Wed, 30 Mar 2011, Linus Torvalds wrote: > > And ARM fanbois can say "oh, but arm is special" all they want, but > > they need to realize that the lack of common platform for ARM is a > > real major issue. It's not a "feature", and I'm sorry, but anybody who > > calls x86 "peanuts" is a moron and should be ashamed of himself. > > Instead of trying to feel superior, those people should feel like > > pariah. > > Oh come on. You just provided actual numbers above showing that ARM is > simply fscked up (your words) compared to X86. I would be curious to > know what people like tglx who did significant work on both > architectures actually think of X86 relative to ARM when it comes to > kernel maintenance. To be honest both suck in their own way. The only reason why x86 is slightly less horrible is the fact that it's better architectured at the hardware level. But I see the same mess coming in with all those wonderful Atom based SoCs on the horizon, which are nothing else than any other random ARM SoC, just that they glue an x86 core into the same cheepo random IP peripherals conglomerate. In fact some of those chip have been ARM powered before they got an x86 injected. And worse: the Intel folks went there and wrote a new driver for an IP block which had already an "ARM associated" driver. So I say that it is not only an ARM problem, it's a general problem that people do not realize that the IP cores are reused all over the place and across architectures. I'm pretty sure after I went through all the irq code recently that lots of those ARM SoCs from vendors across the board could share a lot of driver code if someone would actually sit down and analyse the situation. Right now we have nobody who has the time and the stomach to go through this and at the same time prevent that more copied crappola is hitting the tree. I'm sure that device tree is part of the solution, but that only helps if we find a way to prevent duplicate drivers in the first place. Thanks, tglx -- 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 changes for v2.6.39 merge window
* Russell King - ARM Linux wrote: > On Thu, Mar 31, 2011 at 10:06:34AM +0200, Ingo Molnar wrote: > > Having strong, effective platform abstractions inside the kernel really > > helps > > even if the hardware space itself is inevitably fragmented: both powerpc > > and > > x86 has shown that. Until you realize and appreciate that you really have > > not > > understood the problem i think. > > No, I think it is the other way around. Folk like me and Nicolas over the > last ten years have put considerable amounts of effort into trying to keep > the ARM support code as clean and maintainable as possible. Absolutely no argument about that, whenever i have read core ARM code it was always a pleasure. You guys are doing a fine job there. What i argued with was what Nicolas said: > > > back in the early days of the PCs, different systems from different > > > vendors had different bus types, peripherals at different addresses, > > > etc. that didn't make all of those vendors systems different > > > architectures, instead those things were varients of the x86 > > > architecture. > > > > Most of them didn't survive. That really helps. It does not matter whether hardware survives or not - most pieces of hardware do not survive. What matters is whether the inevitable hardware-churn is allowed to litter the kernel tree with unmaintainable pieces of crap. You even mention that it's not maintainable to you: > That is true of the common ARM stuff, but there's no way we can do this for > all SoC support - there aren't the hours in the day to provide such a wide > oversight. [...] The problem is the solution: > That's why we have SoC maintainers, and the SoC maintainers have the > responsibility to sort out their own sub-trees. ... which sets the wolves to mind the sheep, so to say. Self-oversight never worked very well (unless you believe in perpetual bank bailouts). So Linus and Thomas (with the genirq hat on) are pushing back, because both of them feel affected negatively by crap. "All is fine" or "it's just natural" do not seem like the right answers to those concerns. Thanks, Ingo -- 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 changes for v2.6.39 merge window
Hi, On Thu, Mar 31, 2011 at 09:09:54AM +0100, Russell King - ARM Linux wrote: > > what's more, you seem to be saying that > > > > arm7+IPblock1 > > > > and > > > > arm7+IPblock1 > > > > are different architectures if the wiring between the arm core and > > IPblock1 are different (they are different 'boards' or different chip > > models, possibly from different manufacturers) This is utter BS, see e.g. that the same MUSB driver is re-used on OMAP, on an external discrete chip TUSB6010, on DaVinci, on Blackfin, on UX500, etc. The exact same driver is re-used on all those situations with a little platform glue layer. We can't live without that small glue layer for each different platform though and they sum up to 2600+ lines of code (all different platform glues). It's a pain to keep the core code generic enough so that it's useful on all those cases, specially because between OMAP and AM35x, even the register file that particular IP block is different. Still, we have people working to keep the IP block drivers generic enough to be re-used on several situations. > Over the years which I was overseeing platform support I tried to ensure > as much sharing of code across different platforms. I no longer oversee > platform specific stuff, and so its entirely possible that several SoCs > have the same IP block but their own code to drive it. > > That's where Thomas is right - we need a team of people to provide > review of that to catch it and get it consolidated. Such a team would > need funding. Where does that funding come from? I've no idea. Fully agree with you Russell. > We also need the various SoC designers and ARM architecture people to > realise that what the hardware situation is rediculous; I have commented > about this lack of standardisation to ARM in past years. ARM have had > a standard set of peripherals for ten years, but the SoC people haven't > really taken them up - and when they do, they seem to always introduce > their own tweaks, sometimes with no way to detect those tweaks. For sure that's happening, but should we prevent ARM vendors to add their tweaks ? Like Nicolas said, that's fuel to innovation. -- balbi -- 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 changes for v2.6.39 merge window
On Thu, Mar 31, 2011 at 10:54:40AM +0100, Alan Cox wrote: > If I boot it on a current PC I'm booting on a multiprocessor system with > different timers, totally different IRQ controllers, different keyboard > controllers (USB), PCI Express, an IOMMU, NCQ SATA, ACPI, graphics > running in shared host memory able to give/take pages from the host, > extra instructions, etc etc > > And the same kernel boots just fine on both just fine. We've been there for a long time with ARM. Right from the start I had a single kernel image which booted over a range of ARM CPUs and platforms. As far as ARM CPU architectures go, today we can have a single kernel image which covers ARMv3 to ARMv5, and a separate kernel image which covers ARMv6 to ARMv7 including SMP and UP variants. The thing which currently stops ARMv3 to ARMv7 all together is the different page table layouts, the ASID tagging, the exclusive load/store support for cmpxchg and other atomic operations, etc. I wouldn't want to try to patch out the exclusive load/store operations with some kind of function call to one of the generic implementations in asm-generic as that gets you into ABI problems with GCC - it'd mean having to tell GCC that various registers are clobbered all over the place. With page tables, we can use the old format for ARMv5 with ARMv6 and later, but that means we lose stuff like NX support to prevent instruction prefetches hitting devices, which is of course a problem if you have read-sensitive registers such as FIFOs there. Can an x86 kernel with PAE support run on an x86 without PAE support? The differences between ARMv5 and ARMv6 are much like PAE. Outside of the CPU architecture, things become a lot more complicated. The biggest one up until this merge window was that there is no fixed address for system RAM, which makes stuff like virt_to_phys() rather horrible to deal with - which in turn makes setting up and walking page tables a nightmare. We've just solved that issue with run-time patching of the kernel code to replace the add/sub instructions with ones with the appropriate offset, so we're a step closer to unifying everything into one single kernel image. This work alone produced this diffstat: 87 files changed, 450 insertions(+), 190 deletions(-) so it actually resulted in a net increase in the amount of code to be maintained rather than reducing it. That's hardly surprising as what that replaced was just a bunch of #define's for PHYS_OFFSET with some complex assembly code to do run-time patching of instructions. The barriers against a single kernel image are being worked on, and it's actually one of the things which Linaro is actively tasked to achieve. One thing which I've been working on over the last six months is to unify some of the ARM platforms which I use for testing the kernel on, and I'd like to see one kernel image booting on all of those. 65 files changed, 1168 insertions(+), 1752 deletions(-) Given this thread, I've lost the motivation to continue with it because it's just going to cause more 'pointless churn' and end up annoying Linus even more. And I'm not going to be merging anything into my tree for the time being. I know there's no way for me to continue without being moaned at by someone. So I'm just going to take the easy option at the moment and do precisely nothing in terms of queueing patches until something gets resolved one way or the other. I'm not even going to review any patches because I currently see it as a total waste of time - I've no idea whether they'll stand any chance what so ever of making it into mainline. What's the way out of this? I've no idea. Can ARM continue being part of the mainline kernel? I've no idea. Will we be ripping out all the ARM platform code from the mainline kernel? I've no idea. I am now completely demotivated. -- 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 changes for v2.6.39 merge window
On Wed, 2011-03-30 at 23:10 +0200, Thomas Gleixner wrote: > The only problem is to find a person, who is willing to do that, has > enough experience, broad shoulders and a strong accepted voice. Not to > talk about finding someone who is willing to pay a large enough > compensation for pain and suffering. If I understand correctly, this is exactly what Linaro would need to do. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] OMAP2+: omap_hwmod: manage the omap_devices the wake-up latency constraints
Hello.
On 30-03-2011 19:19, jean.pi...@newoldbits.com wrote:
From: Jean Pihet
Hwmod is queried from the omap device layer to manage the power domains
wake-up latency constraints. Hwmod retrieves the correct power domain
and if it exists it calls the corresponding power domain function.
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
on MPU, CORE and PER.
Signed-off-by: Jean Pihet
[...]
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e034294..62de888 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
[...]
@@ -2322,11 +2323,34 @@ ohsps_unlock:
return ret;
}
+/*
+ * omap_hwmod_set_wkup_constraint- set/release a wake-up latency constraint
+ *
+ * @oh: struct omap_hwmod* to which the target device belongs to.
+ * @cookie: identifier of the constraints list for @oh.
+ * @min_latency: the minimum allowed wake-up latency for @oh.
+ *
+ * Returns 0 upon success.
+ */
+int omap_hwmod_set_wkup_lat_constraint(struct omap_hwmod *oh,
+ void *cookie, long min_latency)
+{
+ struct powerdomain *pwrdm = omap_hwmod_get_pwrdm(oh);
+
+ if (!PTR_ERR(pwrdm)) {
What's the point of calling PTR_ERR() at all, if just '!pwrdm' will give
the same result?
WBR, Sergei
--
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 changes for v2.6.39 merge window
Hi, On Wed, Mar 30, 2011 at 08:24:30PM -0700, Linus Torvalds wrote: > So let's take a really simple example of this kind of crap. > > Do this: > > git ls-files arch/arm/ | grep gpio > > and cry. That's 145 files in the arm directory that are some kind of > crazy gpio support. Most likely those are remanescent from times when we didn't have gpiolib. It's not long ago (about 2 years) that David Brownell (rip, my friend) introduced it to the kernel. So those should be converted to gpiolib and moved to drivers/gpio/ but it doesn't mean we don't need that piece of code. With different register layout, register offsets, register sizes, etc, it would be way uglier to combine all those into one big hacky driver. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] OMAP2+: omap_hwmod: manage the omap_devices the wake-up latency constraints
On Wed, Mar 30, 2011 at 05:19:20PM +0200, jean.pi...@newoldbits.com wrote:
> +/*
> + * omap_hwmod_set_wkup_constraint- set/release a wake-up latency constraint
> + *
> + * @oh: struct omap_hwmod* to which the target device belongs to.
> + * @cookie: identifier of the constraints list for @oh.
> + * @min_latency: the minimum allowed wake-up latency for @oh.
> + *
> + * Returns 0 upon success.
> + */
> +int omap_hwmod_set_wkup_lat_constraint(struct omap_hwmod *oh,
> +void *cookie, long min_latency)
> +{
> + struct powerdomain *pwrdm = omap_hwmod_get_pwrdm(oh);
> +
> + if (!PTR_ERR(pwrdm)) {
> + pr_err("%s: Error: could not find powerdomain "
> +"for %s\n", __func__, oh->name);
> + return -EINVAL;
> + }
If omap_hwmod_get_pwrdm() returns errors encoded into pointers, then:
if (IS_ERR(pwrdm)) {
...
return PTR_ERR(pwrdm);
}
If it doesn't, then:
if (!pwrdm) {
...
return -EINVAL;
}
Note that PTR_ERR returns true for both valid error codes and valid
pointers. Use the interface correctly and don't take shortcuts. They
don't work.
--
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 changes for v2.6.39 merge window
On Thu, 31 Mar 2011, Russell King - ARM Linux wrote: > On Thu, Mar 31, 2011 at 10:06:34AM +0200, Ingo Molnar wrote: > > Having strong, effective platform abstractions inside the kernel really > > helps > > even if the hardware space itself is inevitably fragmented: both powerpc > > and > > x86 has shown that. Until you realize and appreciate that you really have > > not > > understood the problem i think. > > No, I think it is the other way around. Folk like me and Nicolas over > the last ten years have put considerable amounts of effort into trying > to keep the ARM support code as clean and maintainable as possible. > > That is true of the common ARM stuff, but there's no way we can do this > for all SoC support - there aren't the hours in the day to provide such That's what I said. You and Nicholas wont scale. > a wide oversight. That's why we have SoC maintainers, and the SoC > maintainers have the responsibility to sort out their own sub-trees. But the current SoC maintainer model does not work either. The SoC maintainers care about their sandbox and have exactly zero incentive to look at the overall picture, e.g reuse of code for the same IP blocks, better abstraction mechanisms etc. Therefor you need a team of experienced kernel developers which are NOT associated with a particular vendor who are able to tame that SoC crowd and work closely with you and Nicholas to keep stuff in sync. Thanks, tglx -- 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] omap: rx51: Platform support for lp5523 led chip
Signed-off-by: Ameya Palande
Signed-off-by: Mathias Nyman
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 81 ++
1 files changed, 81 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index bbcb677..488916d 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include <../drivers/staging/iio/light/tsl2563.h>
@@ -51,6 +52,7 @@
#define RX51_WL1251_IRQ_GPIO 42
#define RX51_FMTX_RESET_GPIO 163
#define RX51_FMTX_IRQ 53
+#define RX51_LP5523_CHIP_EN_GPIO 41
/* list all spi devices here */
enum {
@@ -67,6 +69,79 @@ static struct tsl2563_platform_data
rx51_tsl2563_platform_data = {
};
#endif
+#if defined(CONFIG_LEDS_LP5523) || defined(CONFIG_LEDS_LP5523_MODULE)
+static struct lp5523_led_config rx51_lp5523_led_config[] = {
+ {
+ .chan_nr= 0,
+ .led_current= 50,
+ }, {
+ .chan_nr= 1,
+ .led_current= 50,
+ }, {
+ .chan_nr= 2,
+ .led_current= 50,
+ }, {
+ .chan_nr= 3,
+ .led_current= 50,
+ }, {
+ .chan_nr= 4,
+ .led_current= 50,
+ }, {
+ .chan_nr= 5,
+ .led_current= 50,
+ }, {
+ .chan_nr= 6,
+ .led_current= 50,
+ }, {
+ .chan_nr= 7,
+ .led_current= 50,
+ }, {
+ .chan_nr= 8,
+ .led_current= 50,
+ }
+};
+
+static int rx51_lp5523_setup(void)
+{
+ int err;
+
+ err = gpio_request(RX51_LP5523_CHIP_EN_GPIO, "lp5523_enable");
+ if (err < 0) {
+ pr_err("Unable to get lp5523_enable GPIO\n");
+ return err;
+ }
+
+ err = gpio_direction_output(RX51_LP5523_CHIP_EN_GPIO, 1);
+ if (err < 0) {
+ pr_err("Failed to change direction for %d GPIO\n",
+ RX51_LP5523_CHIP_EN_GPIO);
+ }
+ return err;
+}
+
+static void rx51_lp5523_release(void)
+{
+ gpio_free(RX51_LP5523_CHIP_EN_GPIO);
+}
+
+static void rx51_lp5523_enable(bool state)
+{
+ if (state)
+ gpio_set_value(RX51_LP5523_CHIP_EN_GPIO, 1);
+ else
+ gpio_set_value(RX51_LP5523_CHIP_EN_GPIO, 0);
+}
+
+static struct lp5523_platform_data rx51_lp5523_platform_data = {
+ .led_config = rx51_lp5523_led_config,
+ .num_channels = ARRAY_SIZE(rx51_lp5523_led_config),
+ .clock_mode = LP5523_CLOCK_AUTO,
+ .setup_resources= rx51_lp5523_setup,
+ .release_resources = rx51_lp5523_release,
+ .enable = rx51_lp5523_enable,
+};
+#endif
+
static struct omap2_mcspi_device_config wl1251_mcspi_config = {
.turbo_mode = 0,
.single_channel = 1,
@@ -816,6 +891,12 @@ static struct i2c_board_info __initdata
rx51_peripherals_i2c_board_info_2[] = {
.platform_data = &rx51_tsl2563_platform_data,
},
#endif
+#if defined(CONFIG_LEDS_LP5523) || defined(CONFIG_LEDS_LP5523_MODULE)
+ {
+ I2C_BOARD_INFO("lp5523", 0x32),
+ .platform_data = &rx51_lp5523_platform_data,
+ },
+#endif
{
I2C_BOARD_INFO("tpa6130a2", 0x60),
.platform_data = &rx51_tpa6130a2_data,
--
1.7.1
--
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: RX-51: Platform support for lp5523
Hi Tony, On 03/29/2011 10:33 PM, ext Tony Lindgren wrote: * Sebastian Reichel [110329 11:13]: On Tue, Mar 29, 2011 at 10:36:47AM -0700, Tony Lindgren wrote: * Sebastian Reichel [110329 10:26]: Is there any reason, that the rx51 platform code does not support the lp5523 chip? The chip driver itself is in the mainline kernel since 2.6.37-rc2. Got a patch for that? As always, patches related to blinking leds have a special high priority here! :) Ameya Palande has written one, which is available at [0]. I added him to CC, so that he can comment on mainline inclusion. OK. Ameya, can you please post it for review for this list with linux-arm-kernel list Cc'd? Done! Here is the patch: http://marc.info/?l=linux-omap&m=130157389724187&w=2 Cheers, Ameya. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: rx51: Platform support for lp5523 led chip
Hi,
On Thu, Mar 31, 2011 at 03:17:57PM +0300, Ameya Palande wrote:
> +static int rx51_lp5523_setup(void)
> +{
> + int err;
> +
> + err = gpio_request(RX51_LP5523_CHIP_EN_GPIO, "lp5523_enable");
> + if (err < 0) {
> + pr_err("Unable to get lp5523_enable GPIO\n");
> + return err;
> + }
> +
> + err = gpio_direction_output(RX51_LP5523_CHIP_EN_GPIO, 1);
> + if (err < 0) {
> + pr_err("Failed to change direction for %d GPIO\n",
> + RX51_LP5523_CHIP_EN_GPIO);
> + }
you can combine these two into
gpio_request_one(RX51_LP5523_CHIP_EN_GPIO, GPIOF_DIR_OUT,
"lp5523_enable");
> + return err;
> +}
> +
> +static void rx51_lp5523_release(void)
> +{
> + gpio_free(RX51_LP5523_CHIP_EN_GPIO);
> +}
> +
> +static void rx51_lp5523_enable(bool state)
> +{
> + if (state)
> + gpio_set_value(RX51_LP5523_CHIP_EN_GPIO, 1);
> + else
> + gpio_set_value(RX51_LP5523_CHIP_EN_GPIO, 0);
how about:
gpio_set_value(RX51_LP5523_CHIP_EN_GPIO, !!state); ??
you drop a useless branch.
> +}
> +
> +static struct lp5523_platform_data rx51_lp5523_platform_data = {
should this be const ??
> + .led_config = rx51_lp5523_led_config,
> + .num_channels = ARRAY_SIZE(rx51_lp5523_led_config),
> + .clock_mode = LP5523_CLOCK_AUTO,
> + .setup_resources= rx51_lp5523_setup,
> + .release_resources = rx51_lp5523_release,
^ trailing whitespace
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: rx51: Platform support for lp5523 led chip
Hi,
On Thu, 31 Mar 2011, Ameya Palande wrote:
+static int rx51_lp5523_setup(void)
+{
+ int err;
+
+ err = gpio_request(RX51_LP5523_CHIP_EN_GPIO, "lp5523_enable");
+ if (err < 0) {
+ pr_err("Unable to get lp5523_enable GPIO\n");
+ return err;
+ }
+
+ err = gpio_direction_output(RX51_LP5523_CHIP_EN_GPIO, 1);
+ if (err < 0) {
+ pr_err("Failed to change direction for %d GPIO\n",
+ RX51_LP5523_CHIP_EN_GPIO);
The error branch is missing gpio_free(). You can fix that by replacing
these with just a single gpio_request_one() call.
+ }
+ return err;
+}
+
+static void rx51_lp5523_release(void)
+{
+ gpio_free(RX51_LP5523_CHIP_EN_GPIO);
+}
+
+static void rx51_lp5523_enable(bool state)
+{
+ if (state)
+ gpio_set_value(RX51_LP5523_CHIP_EN_GPIO, 1);
+ else
+ gpio_set_value(RX51_LP5523_CHIP_EN_GPIO, 0);
+}
+
+static struct lp5523_platform_data rx51_lp5523_platform_data = {
+ .led_config = rx51_lp5523_led_config,
+ .num_channels = ARRAY_SIZE(rx51_lp5523_led_config),
+ .clock_mode = LP5523_CLOCK_AUTO,
+ .setup_resources= rx51_lp5523_setup,
+ .release_resources = rx51_lp5523_release,
+ .enable = rx51_lp5523_enable,
+};
+#endif
+
static struct omap2_mcspi_device_config wl1251_mcspi_config = {
.turbo_mode = 0,
.single_channel = 1,
@@ -816,6 +891,12 @@ static struct i2c_board_info __initdata
rx51_peripherals_i2c_board_info_2[] = {
.platform_data = &rx51_tsl2563_platform_data,
},
#endif
+#if defined(CONFIG_LEDS_LP5523) || defined(CONFIG_LEDS_LP5523_MODULE)
+ {
+ I2C_BOARD_INFO("lp5523", 0x32),
+ .platform_data = &rx51_lp5523_platform_data,
+ },
+#endif
{
I2C_BOARD_INFO("tpa6130a2", 0x60),
.platform_data = &rx51_tpa6130a2_data,
--
1.7.1
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 changes for v2.6.39 merge window
On 11:50 Thu 31 Mar , Russell King - ARM Linux wrote: > On Thu, Mar 31, 2011 at 10:54:40AM +0100, Alan Cox wrote: > > If I boot it on a current PC I'm booting on a multiprocessor system with > > different timers, totally different IRQ controllers, different keyboard > > controllers (USB), PCI Express, an IOMMU, NCQ SATA, ACPI, graphics > > running in shared host memory able to give/take pages from the host, > > extra instructions, etc etc > > > > And the same kernel boots just fine on both just fine. > > We've been there for a long time with ARM. Right from the start I had > a single kernel image which booted over a range of ARM CPUs and > platforms. > > As far as ARM CPU architectures go, today we can have a single kernel > image which covers ARMv3 to ARMv5, and a separate kernel image which > covers ARMv6 to ARMv7 including SMP and UP variants. The thing which > currently stops ARMv3 to ARMv7 all together is the different page table > layouts, the ASID tagging, the exclusive load/store support for cmpxchg > and other atomic operations, etc. As we can see a lots of people work on this, to now do not add thousand of boards but try to have only a few Personnaly I do it on at91 as example and will continue to try to have one board in the kernel with board information pass via Barebox, when it's possible. I think it's a common effort doen by the ARM Community and this will imply a lots of changesets. The work done by Linaro with the device tree will help a lot to simplify the pass of the information from the boot loader to the kernel. But we can already do it today. Best Regards, J. -- 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 changes for v2.6.39 merge window
On Thu, 2011-03-31 at 11:50 +0100, Russell King - ARM Linux wrote: > Given this thread, I've lost the motivation to continue with it because > it's just going to cause more 'pointless churn' and end up annoying > Linus even more. I don't think the criticism was directed at the core ARM code that you maintain (Ingo and others even praised it). I also don't think that you stopping maintaining it would help in any way with this situation. We probably shouldn't take criticism personally. Linus has some points which the ARM community is aware of already since there is ongoing work for consolidating the platform code (recent v2p patches, SMP-on-UP, FDT and probably more will come) only that this won't happen overnight. If you stop merging any of these, there's definitely no way out (other than doing the work separately for the next two years and replacing the arch/arm in a single pull request). -- Catalin -- 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
[RFC PATCH] ARM: GIC: Convert GIC library to use the IO relaxed operations
The GIC register accesses today make use of readl()/writel()
which prove to be very expensive when used along with mandatory
barriers. This mandatory barriers also introduces an un-necessary
and expensive l2x0_sync() operation. On Cortex-A9 MP cores, GIC
IO accesses from CPU are direct and doesn't go through L2X0 write
buffer.
Also since a DSB does not guarantee that the device state has
been changed, a read back from the device is introduced wherever
necessary.
Signed-off-by: Santosh Shilimkar
Cc: Catalin Marinas
Cc: Will Deacon
---
Tested on OMAP4430 SDP.
arch/arm/common/gic.c | 57
1 files changed, 33 insertions(+), 24 deletions(-)
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index f70ec7d..e013f65 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -89,7 +89,9 @@ static void gic_ack_irq(struct irq_data *d)
spin_lock(&irq_controller_lock);
if (gic_arch_extn.irq_ack)
gic_arch_extn.irq_ack(d);
- writel(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
+ writel_relaxed(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
+ barrier();
+ readl_relaxed(gic_cpu_base(d) + GIC_CPU_EOI);
spin_unlock(&irq_controller_lock);
}
@@ -98,7 +100,9 @@ static void gic_mask_irq(struct irq_data *d)
u32 mask = 1 << (d->irq % 32);
spin_lock(&irq_controller_lock);
- writel(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) /
32) * 4);
+ writel_relaxed(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR +
(gic_irq(d) / 32) * 4);
+ barrier();
+ readl_relaxed(gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) /
32) * 4);
if (gic_arch_extn.irq_mask)
gic_arch_extn.irq_mask(d);
spin_unlock(&irq_controller_lock);
@@ -111,7 +115,9 @@ static void gic_unmask_irq(struct irq_data *d)
spin_lock(&irq_controller_lock);
if (gic_arch_extn.irq_unmask)
gic_arch_extn.irq_unmask(d);
- writel(mask, gic_dist_base(d) + GIC_DIST_ENABLE_SET + (gic_irq(d) / 32)
* 4);
+ writel_relaxed(mask, gic_dist_base(d) + GIC_DIST_ENABLE_SET +
(gic_irq(d) / 32) * 4);
+ barrier();
+ readl_relaxed(gic_dist_base(d) + GIC_DIST_ENABLE_SET + (gic_irq(d) /
32) * 4);
spin_unlock(&irq_controller_lock);
}
@@ -138,7 +144,7 @@ static int gic_set_type(struct irq_data *d, unsigned int
type)
if (gic_arch_extn.irq_set_type)
gic_arch_extn.irq_set_type(d, type);
- val = readl(base + GIC_DIST_CONFIG + confoff);
+ val = readl_relaxed(base + GIC_DIST_CONFIG + confoff);
if (type == IRQ_TYPE_LEVEL_HIGH)
val &= ~confmask;
else if (type == IRQ_TYPE_EDGE_RISING)
@@ -148,15 +154,15 @@ static int gic_set_type(struct irq_data *d, unsigned int
type)
* As recommended by the spec, disable the interrupt before changing
* the configuration
*/
- if (readl(base + GIC_DIST_ENABLE_SET + enableoff) & enablemask) {
- writel(enablemask, base + GIC_DIST_ENABLE_CLEAR + enableoff);
+ if (readl_relaxed(base + GIC_DIST_ENABLE_SET + enableoff) & enablemask)
{
+ writel_relaxed(enablemask, base + GIC_DIST_ENABLE_CLEAR +
enableoff);
enabled = true;
}
- writel(val, base + GIC_DIST_CONFIG + confoff);
+ writel_relaxed(val, base + GIC_DIST_CONFIG + confoff);
if (enabled)
- writel(enablemask, base + GIC_DIST_ENABLE_SET + enableoff);
+ writel_relaxed(enablemask, base + GIC_DIST_ENABLE_SET +
enableoff);
spin_unlock(&irq_controller_lock);
@@ -188,8 +194,9 @@ static int gic_set_affinity(struct irq_data *d, const
struct cpumask *mask_val,
spin_lock(&irq_controller_lock);
d->node = cpu;
- val = readl(reg) & ~mask;
- writel(val | bit, reg);
+ val = readl_relaxed(reg) & ~mask;
+ barrier();
+ writel_relaxed(val | bit, reg);
spin_unlock(&irq_controller_lock);
return 0;
@@ -222,7 +229,7 @@ static void gic_handle_cascade_irq(unsigned int irq, struct
irq_desc *desc)
chip->irq_ack(&desc->irq_data);
spin_lock(&irq_controller_lock);
- status = readl(chip_data->cpu_base + GIC_CPU_INTACK);
+ status = readl_relaxed(chip_data->cpu_base + GIC_CPU_INTACK);
spin_unlock(&irq_controller_lock);
gic_irq = (status & 0x3ff);
@@ -272,13 +279,13 @@ static void __init gic_dist_init(struct gic_chip_data
*gic,
cpumask |= cpumask << 8;
cpumask |= cpumask << 16;
- writel(0, base + GIC_DIST_CTRL);
+ writel_relaxed(0, base + GIC_DIST_CTRL);
/*
* Find out how many interrupts are supported.
* The GIC only supports up to 1020 interrupt sources.
*/
- gic_irqs = readl(base + GIC_DIST_CTR) & 0x1f;
+ gic_irqs = readl_relaxed(base + GIC_DIST_CTR) & 0x1f;
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, Mar 31, 2011 at 01:38:21PM +0100, Catalin Marinas wrote: > On Thu, 2011-03-31 at 11:50 +0100, Russell King - ARM Linux wrote: > > Given this thread, I've lost the motivation to continue with it because > > it's just going to cause more 'pointless churn' and end up annoying > > Linus even more. > > I don't think the criticism was directed at the core ARM code that you > maintain (Ingo and others even praised it). I also don't think that you > stopping maintaining it would help in any way with this situation. > > We probably shouldn't take criticism personally. Linus has some points > which the ARM community is aware of already since there is ongoing work > for consolidating the platform code (recent v2p patches, SMP-on-UP, FDT > and probably more will come) only that this won't happen overnight. If > you stop merging any of these, there's definitely no way out (other than > doing the work separately for the next two years and replacing the > arch/arm in a single pull request). But are we going to be allowed to continue this effort without being constantly blamed for "pointless churn" all the time? I don't think so, so it may well be better to give up with pushing stuff into mainline for two years, and then do a massive re-merge as a single major "replace everything". I don't like the idea, but I don't see much alternative. And since Linus' whinge about ARM defconfigs, I really *hate* merging anything with *any* defconfig changes in - as a result, I don't particularly want to deal with ARM defconfig changes anymore. I'm sure they'll make Linus explode about it again in the near future. That's why this time around, I kept them in a separate branch in case Linus refused to pull them. And again, as a result of this thread I've given up for the time being on the idea of continuing to consolidate the ARM Integrator/Versatile/ Realview/Versatile Express code. I just don't see the point of wasting time trying to consolidate stuff if it's just going to be used against us in terms of diffstat percentages and churn complaints. Just look at the removal of AAEC2000, LH7A40x and 2000 lines from the mach-types file removed 6000 lines, which in itself is about the number of lines of change submitted during the last merge window for any one non-ARM architecture. At this point in time with this complaint, I've absolutely no idea why I bothered to do that. I should've left it well alone and then the diffstat percentage would've been smaller. After all, it's "pointless churn". Yes, I'm severely hacked off and fed up with this. Whatever we do will ultimately be used against us in one way or another. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: hwmod: add syss reset done flags to omap2, omap3 hwmods
> Thanks Benoit. You are right. > > The TRM Section '18.3.1.3.2 Software Reset' explains the steps for > softresetting I2C. The steps are below: > > 1. Ensure that the module is disabled (clear the I2Ci.I2C_CON[15] I2C_EN > bit to 0). > 2. Set the I2Ci.I2C_SYSC[1] SRST bit to 1. > 3. Enable the module by setting I2Ci.I2C_CON[15] I2C_EN bit to 1. > 4. Check the I2Ci.I2C_SYSS[0] RDONE bit until it is set to 1 to indicate > the software reset is complete. Hi paul, I have been able to implement the function. It took a while because, even after implementing the above sequence, i was seeing the I2C wasn't resetting. The issue turned out that i was doing '32 bit data access' which was corrupting the i2c register contents. I missed the TRM section where it tells, "i2c registers are limited to 8-bit or 16-bit access". Special thanks to balaji.t.k for helping me debug this and pointing this was the issue. On correcting this, the function worked cleanly and i2c was reset. I ll send out the patch tomorrow. br , - avinash > > > > > Thanks Benoît. > > > > So then, Avinash, you might need to create a custom hwmod class > > reset function for the I2C block (viz., struct omap_hwmod_class.reset) > > OK Paul. I'll add the I2C_CON register and follow the above sequence as > suggested in the TRM in the custom I2C reset function. > -- 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 changes for v2.6.39 merge window
On Thu, Mar 31, 2011 at 12:41:52PM +0200, Ingo Molnar wrote: > * Russell King - ARM Linux wrote: > > On Thu, Mar 31, 2011 at 10:06:34AM +0200, Ingo Molnar wrote: > > > Having strong, effective platform abstractions inside the kernel really > > > helps > > > even if the hardware space itself is inevitably fragmented: both powerpc > > > and > > > x86 has shown that. Until you realize and appreciate that you really have > > > not > > > understood the problem i think. > > > > No, I think it is the other way around. Folk like me and Nicolas over the > > last ten years have put considerable amounts of effort into trying to keep > > the ARM support code as clean and maintainable as possible. > > Absolutely no argument about that, whenever i have read core ARM code it was > always a pleasure. You guys are doing a fine job there. Thanks for your vote of confidence. It's really appreciated. -- 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
[PATCHv2] omap: rx51: Platform support for lp5523 led chip
Signed-off-by: Ameya Palande
Signed-off-by: Mathias Nyman
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 74 ++
1 files changed, 74 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index bbcb677..ed289d1 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include <../drivers/staging/iio/light/tsl2563.h>
@@ -51,6 +52,7 @@
#define RX51_WL1251_IRQ_GPIO 42
#define RX51_FMTX_RESET_GPIO 163
#define RX51_FMTX_IRQ 53
+#define RX51_LP5523_CHIP_EN_GPIO 41
/* list all spi devices here */
enum {
@@ -67,6 +69,72 @@ static struct tsl2563_platform_data
rx51_tsl2563_platform_data = {
};
#endif
+#if defined(CONFIG_LEDS_LP5523) || defined(CONFIG_LEDS_LP5523_MODULE)
+static struct lp5523_led_config rx51_lp5523_led_config[] = {
+ {
+ .chan_nr= 0,
+ .led_current= 50,
+ }, {
+ .chan_nr= 1,
+ .led_current= 50,
+ }, {
+ .chan_nr= 2,
+ .led_current= 50,
+ }, {
+ .chan_nr= 3,
+ .led_current= 50,
+ }, {
+ .chan_nr= 4,
+ .led_current= 50,
+ }, {
+ .chan_nr= 5,
+ .led_current= 50,
+ }, {
+ .chan_nr= 6,
+ .led_current= 50,
+ }, {
+ .chan_nr= 7,
+ .led_current= 50,
+ }, {
+ .chan_nr= 8,
+ .led_current= 50,
+ }
+};
+
+static int rx51_lp5523_setup(void)
+{
+ int err;
+
+ err = gpio_request_one(RX51_LP5523_CHIP_EN_GPIO, GPIOF_DIR_OUT,
+ "lp5523_enable");
+ if (err < 0) {
+ pr_err("Unable to get lp5523_enable GPIO\n");
+ return err;
+ }
+
+ return err;
+}
+
+static void rx51_lp5523_release(void)
+{
+ gpio_free(RX51_LP5523_CHIP_EN_GPIO);
+}
+
+static void rx51_lp5523_enable(bool state)
+{
+ gpio_set_value(RX51_LP5523_CHIP_EN_GPIO, !!state);
+}
+
+static struct lp5523_platform_data rx51_lp5523_platform_data = {
+ .led_config = rx51_lp5523_led_config,
+ .num_channels = ARRAY_SIZE(rx51_lp5523_led_config),
+ .clock_mode = LP5523_CLOCK_AUTO,
+ .setup_resources= rx51_lp5523_setup,
+ .release_resources = rx51_lp5523_release,
+ .enable = rx51_lp5523_enable,
+};
+#endif
+
static struct omap2_mcspi_device_config wl1251_mcspi_config = {
.turbo_mode = 0,
.single_channel = 1,
@@ -816,6 +884,12 @@ static struct i2c_board_info __initdata
rx51_peripherals_i2c_board_info_2[] = {
.platform_data = &rx51_tsl2563_platform_data,
},
#endif
+#if defined(CONFIG_LEDS_LP5523) || defined(CONFIG_LEDS_LP5523_MODULE)
+ {
+ I2C_BOARD_INFO("lp5523", 0x32),
+ .platform_data = &rx51_lp5523_platform_data,
+ },
+#endif
{
I2C_BOARD_INFO("tpa6130a2", 0x60),
.platform_data = &rx51_tpa6130a2_data,
--
1.7.1
--
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 changes for v2.6.39 merge window
On Wed, 30 Mar 2011, Linus Torvalds wrote: > On Wed, Mar 30, 2011 at 6:15 PM, Bill Gatliff wrote: > > > > I'm not sure this metric is completely fair to ARM. If you want to > > level the field, I think you have to divide each result by the number > > of SoC's > > But that's the problem with ARM. Hardware companies that do one-off > stuff, with no sense of compatibility. > > And calling it an "opportunity" is just stupid. > > There's nothing good about causing extra work just because ARM hasn't > had the sense to standardize on one (or a couple) of interrupt > controllers etc. Well, ARM is not the only one there, it's the top one, but mips and power are not less crazy. Here are the top five architectures counted in number of irq_chip implementations. arch/arm 139 arch/mips75 arch/powerpc 44 arch/alpha 21 arch/x86 15 Thanks, tglx
Re: [PATCHv2] omap: rx51: Platform support for lp5523 led chip
On Thu, 31 Mar 2011 16:38:12 +0300
Ameya Palande wrote:
> Signed-off-by: Ameya Palande
> Signed-off-by: Mathias Nyman
> ---
> arch/arm/mach-omap2/board-rx51-peripherals.c | 74
> ++
> 1 files changed, 74 insertions(+), 0 deletions(-)
>
Nice keyboard and rgb led blinking:
while true; do ls /sys/class/leds/lp5523\:channel?/brightness |xargs -I
{} bash -c 'echo $((RANDOM % 255)) > {}'; done
Tested-by: Jarkko Nikula
--
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 changes for v2.6.39 merge window
On Thursday 31 March 2011, Artem Bityutskiy wrote: > On Wed, 2011-03-30 at 23:10 +0200, Thomas Gleixner wrote: > > The only problem is to find a person, who is willing to do that, has > > enough experience, broad shoulders and a strong accepted voice. Not to > > talk about finding someone who is willing to pay a large enough > > compensation for pain and suffering. > > If I understand correctly, this is exactly what Linaro would need to do. Absolutely. Getting the work done that each of the SoC vendors needs but none of them would do on their own is the main reason why Linaro is there, so if we can agree what needs to be done, I'm sure we can find someone to do it. Arnd -- 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 changes for v2.6.39 merge window
On Thu, 31 Mar 2011, Russell King - ARM Linux wrote: > And I'm not going to be merging anything into my tree for the time being. > I know there's no way for me to continue without being moaned at by someone. > So I'm just going to take the easy option at the moment and do precisely > nothing in terms of queueing patches until something gets resolved one way > or the other. I'm not even going to review any patches because I currently > see it as a total waste of time - I've no idea whether they'll stand any > chance what so ever of making it into mainline. > > What's the way out of this? I've no idea. Can ARM continue being part > of the mainline kernel? I've no idea. Will we be ripping out all the > ARM platform code from the mainline kernel? I've no idea. Moving arm out of mainline would be a complete disaster. > I am now completely demotivated. I can understand that, but I have to say again, that you do a pretty damned good job on keeping the ARM core code clean and I always enjoy working with you when infrastructure I'm working on needs to deal with ARM requirements. We disagree from time to time, but I don't remember a single incident where we could not resolve that on a technical base. It's not your fault, that you can't clone yourself 10 times to deal with the subarch flood. It's also not your fault that the subarch maintainers tend not to look over the brim of their SoC sandbox and figure out how to solve the big picture. So no, ARM needs to stay and the ARM crowd needs to find competent people who babysit the SoC crowd and work with you to get the big picture straight. Something like this should have been done _before_ the wave of ARM spilling out of every other silicon shop became tsunami sized. But not doing it at all will not solve anything. Thanks, tglx -- 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] ARM: GIC: Convert GIC library to use the IO relaxed operations
On Thu, 2011-03-31 at 13:55 +0100, Santosh Shilimkar wrote: > diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c > index f70ec7d..e013f65 100644 > --- a/arch/arm/common/gic.c > +++ b/arch/arm/common/gic.c > @@ -89,7 +89,9 @@ static void gic_ack_irq(struct irq_data *d) > spin_lock(&irq_controller_lock); > if (gic_arch_extn.irq_ack) > gic_arch_extn.irq_ack(d); > - writel(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI); > + writel_relaxed(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI); > + barrier(); > + readl_relaxed(gic_cpu_base(d) + GIC_CPU_EOI); We don't need the explicit barrier(), I don't think the compiler would reorder the writel/readl_relaxed calls. The same for all places where you added barrier(). Do we need the acknowledge to be confirmed via a readl? > spin_unlock(&irq_controller_lock); > } > > @@ -98,7 +100,9 @@ static void gic_mask_irq(struct irq_data *d) > u32 mask = 1 << (d->irq % 32); > > spin_lock(&irq_controller_lock); > - writel(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) / > 32) * 4); > + writel_relaxed(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + > (gic_irq(d) / 32) * 4); > + barrier(); > + readl_relaxed(gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) > / 32) * 4); > if (gic_arch_extn.irq_mask) > gic_arch_extn.irq_mask(d); > spin_unlock(&irq_controller_lock); Here we need a readl back in case the calling code enables the interrupts at the CPU level (that's probably the only place where we need a read back?). > @@ -111,7 +115,9 @@ static void gic_unmask_irq(struct irq_data *d) > spin_lock(&irq_controller_lock); > if (gic_arch_extn.irq_unmask) > gic_arch_extn.irq_unmask(d); > - writel(mask, gic_dist_base(d) + GIC_DIST_ENABLE_SET + (gic_irq(d) / > 32) * 4); > + writel_relaxed(mask, gic_dist_base(d) + GIC_DIST_ENABLE_SET + > (gic_irq(d) / 32) * 4); > + barrier(); > + readl_relaxed(gic_dist_base(d) + GIC_DIST_ENABLE_SET + (gic_irq(d) / > 32) * 4); > spin_unlock(&irq_controller_lock); > } We don't need a read back, just let it unmask the interrupt at some point in the future. > @@ -392,6 +399,8 @@ void gic_raise_softirq(const struct cpumask *mask, > unsigned int irq) > unsigned long map = *cpus_addr(*mask); > > /* this always happens on GIC0 */ > - writel(map << 16 | irq, gic_data[0].dist_base + GIC_DIST_SOFTINT); > + writel_relaxed(map << 16 | irq, gic_data[0].dist_base + > GIC_DIST_SOFTINT); > + barrier(); > + readl_relaxed(gic_data[0].dist_base + GIC_DIST_SOFTINT); > } We don't need the readl. -- Catalin -- 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: [pm-core][PATCH v3 02/21] OMAP4: Use WARN_ON() instead of BUG_ON() with graceful exit
Santosh Shilimkar writes: > On 3/29/2011 2:23 AM, Tony Lindgren wrote: >> * Santosh Shilimkar [110328 02:20]: >>> OMAP L2X0 and GIC initialisation code uses BUG_ON() for the >>> ioremap() failure scenarios. >>> >>> Use WARN_ON() instead and allow graceful function exits. >>> >>> This was suggsted by Kevin Hilman during >>> OMAP4 PM code review. >>> >>> Signed-off-by: Santosh Shilimkar >>> Cc: Kevin Hilman >>> --- >>> arch/arm/mach-omap2/omap4-common.c |9 ++--- >>> 1 files changed, 6 insertions(+), 3 deletions(-) >>> >>> diff --git a/arch/arm/mach-omap2/omap4-common.c >>> b/arch/arm/mach-omap2/omap4-common.c >>> index 559d227..8f9b97d 100644 >>> --- a/arch/arm/mach-omap2/omap4-common.c >>> +++ b/arch/arm/mach-omap2/omap4-common.c >>> @@ -36,11 +36,13 @@ void __init gic_init_irq(void) >>> >>> /* Static mapping, never released */ >>> gic_dist_base_addr = ioremap(OMAP44XX_GIC_DIST_BASE, SZ_4K); >>> - BUG_ON(!gic_dist_base_addr); >>> + if (WARN_ON(!gic_dist_base_addr)) >>> + return; >>> >>> /* Static mapping, never released */ >>> gic_cpu_base = ioremap(OMAP44XX_GIC_CPU_BASE, SZ_512); >>> - BUG_ON(!gic_cpu_base); >>> + if (WARN_ON(!gic_cpu_base)) >>> + return; >>> >>> omap_wakeupgen_init(); >>> >>> @@ -68,7 +70,8 @@ static int __init omap_l2_cache_init(void) >>> >>> /* Static mapping, never released */ >>> l2cache_base = ioremap(OMAP44XX_L2CACHE_BASE, SZ_4K); >>> - BUG_ON(!l2cache_base); >>> + if (WARN_ON(!l2cache_base)) >>> + return -ENODEV; >>> >>> /* >>> * 16-way associativity, parity disabled >> >> Hmm to me it seems that if any of these we don't want to >> continue. >> > L2 cache is no problem and kernel can boot without L2 cache > support. I agree with you on interrupt controller init though. > > Will drop the interrupt related checks from this patch. > > Kevin, Are you ok with it ? In general, BUG should only be used when the kernel really can not possibly continue[1]. I suppose inability to map the GIC falls into that category. Kevin [1] from asm-generic/bug.h: /* * Don't use BUG() or BUG_ON() unless there's really no way out; one * example might be detecting data structure corruption in the middle * of an operation that can't be backed out of. If the (sub)system * can somehow continue operating, perhaps with reduced functionality, * it's probably not BUG-worthy. * * If you're tempted to BUG(), think again: is completely giving up * really the *only* solution? There are usually better options, where * users don't need to reboot ASAP and can mostly shut down cleanly. */ -- 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] arm: omap2: enable smc instruction for sleep34xx
This fixes broken build when using gcc 4.5. Signed-off-by: Oskar Andero --- arch/arm/mach-omap2/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index a45cd64..512b152 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -68,7 +68,7 @@ obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o AFLAGS_sleep24xx.o :=-Wa,-march=armv6 -AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a +AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec) ifeq ($(CONFIG_PM_VERBOSE),y) CFLAGS_pm_bus.o+= -DDEBUG -- 1.7.3.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: [RFC PATCH] ARM: GIC: Convert GIC library to use the IO relaxed operations
On 3/31/2011 7:33 PM, Catalin Marinas wrote: On Thu, 2011-03-31 at 13:55 +0100, Santosh Shilimkar wrote: diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c index f70ec7d..e013f65 100644 --- a/arch/arm/common/gic.c +++ b/arch/arm/common/gic.c @@ -89,7 +89,9 @@ static void gic_ack_irq(struct irq_data *d) spin_lock(&irq_controller_lock); if (gic_arch_extn.irq_ack) gic_arch_extn.irq_ack(d); - writel(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI); + writel_relaxed(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI); + barrier(); + readl_relaxed(gic_cpu_base(d) + GIC_CPU_EOI); We don't need the explicit barrier(), I don't think the compiler would reorder the writel/readl_relaxed calls. The same for all places where you added barrier(). Ok. I added it to just avoid any compiler re-ordering. Do we need the acknowledge to be confirmed via a readl? I was not sure here. Though we should ensure that the write has reached to CPU interface. spin_unlock(&irq_controller_lock); } @@ -98,7 +100,9 @@ static void gic_mask_irq(struct irq_data *d) u32 mask = 1<< (d->irq % 32); spin_lock(&irq_controller_lock); - writel(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) / 32) * 4); + writel_relaxed(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) / 32) * 4); + barrier(); + readl_relaxed(gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) / 32) * 4); if (gic_arch_extn.irq_mask) gic_arch_extn.irq_mask(d); spin_unlock(&irq_controller_lock); Here we need a readl back in case the calling code enables the interrupts at the CPU level (that's probably the only place where we need a read back?). Ok. @@ -111,7 +115,9 @@ static void gic_unmask_irq(struct irq_data *d) spin_lock(&irq_controller_lock); if (gic_arch_extn.irq_unmask) gic_arch_extn.irq_unmask(d); - writel(mask, gic_dist_base(d) + GIC_DIST_ENABLE_SET + (gic_irq(d) / 32) * 4); + writel_relaxed(mask, gic_dist_base(d) + GIC_DIST_ENABLE_SET + (gic_irq(d) / 32) * 4); + barrier(); + readl_relaxed(gic_dist_base(d) + GIC_DIST_ENABLE_SET + (gic_irq(d) / 32) * 4); spin_unlock(&irq_controller_lock); } We don't need a read back, just let it unmask the interrupt at some point in the future. Ok. Will drop this read back then. @@ -392,6 +399,8 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq) unsigned long map = *cpus_addr(*mask); /* this always happens on GIC0 */ - writel(map<< 16 | irq, gic_data[0].dist_base + GIC_DIST_SOFTINT); + writel_relaxed(map<< 16 | irq, gic_data[0].dist_base + GIC_DIST_SOFTINT); + barrier(); + readl_relaxed(gic_data[0].dist_base + GIC_DIST_SOFTINT); } We don't need the readl. And this one too. -- 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] omap: rx51: Platform support for lp5523 led chip
Hi,
On Thu, Mar 31, 2011 at 04:38:12PM +0300, Ameya Palande wrote:
> +static int rx51_lp5523_setup(void)
> +{
> + int err;
> +
> + err = gpio_request_one(RX51_LP5523_CHIP_EN_GPIO, GPIOF_DIR_OUT,
> + "lp5523_enable");
> + if (err < 0) {
> + pr_err("Unable to get lp5523_enable GPIO\n");
> + return err;
> + }
> +
> + return err;
isn't enough to return gpio_request_one(RX51_LP5523_CHIP_EN_GPIO,
GPIOF_DIR_OUT, "lp5523_enable"); ??
--
balbi
--
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: [pm-core][PATCH v3 02/21] OMAP4: Use WARN_ON() instead of BUG_ON() with graceful exit
On 3/31/2011 7:34 PM, Kevin Hilman wrote: Santosh Shilimkar writes: On 3/29/2011 2:23 AM, Tony Lindgren wrote: * Santosh Shilimkar [110328 02:20]: [...] L2 cache is no problem and kernel can boot without L2 cache support. I agree with you on interrupt controller init though. Will drop the interrupt related checks from this patch. Kevin, Are you ok with it ? In general, BUG should only be used when the kernel really can not possibly continue[1]. I suppose inability to map the GIC falls into that category. Thanks. Will drop GIC ones. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: hwmod: add syss reset done flags to omap2, omap3 hwmods
> > > [0.208892] omap_hwmod: i2c1: softreset failed (waited 1 usec)
> > > [0.223114] omap_hwmod: i2c2: softreset failed (waited 1 usec)
> > > [0.237335] omap_hwmod: i2c3: softreset failed (waited 1 usec)
> > > [0.251525] omap_hwmod: gpio2: softreset failed (waited 1 usec)
> > > [0.265594] omap_hwmod: gpio3: softreset failed (waited 1 usec)
> > > [0.279693] omap_hwmod: gpio4: softreset failed (waited 1 usec)
> > > [0.293762] omap_hwmod: gpio5: softreset failed (waited 1 usec)
> > > [0.307861] omap_hwmod: gpio6: softreset failed (waited 1 usec)
Hi Paul,
I tested this on one more board and still got these softreset warnings.
So this wasn't a board specific issue and debugged into what is causing
these.
The problem is the FCLK isn't enabled for these gpios(2..6) while
resetting. So the GPIO's are not resetting properly. Once i enable FCLK
for them and then set the SYSCONFIG.SOFTRESET, then they are resetting
and it is reflected in RESETDONE bit.
That being said, I was looking for accessing gpio2_fck in the
gpio2_hwmod. But i find the structure as below,
static struct omap_hwmod omap3xxx_gpio2_hwmod = {
.name = "gpio2",
.mpu_irqs = omap3xxx_gpio2_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap3xxx_gpio2_irqs),
.main_clk = "gpio2_ick",
Is there any reason, why 'iclk' is set as the 'main_clk' and not 'fclk'.
Also 'fclk' is structured as 'gpio2_dbck' and made as an optional clock.
I wasn't very sure, why the name 'dbck'?
> >
> > Just FYI, I don't see the gpio softreset failures on my boards here.
Most likely you aren't seeing this in N800 and beagle because the
bootloader may be enabling the clocks.
I am sorry if the above question seems silly. I am fairly new to this
frameworks and hence the question :-). Please clarify.
br ,
- avinash
--
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 changes for v2.6.39 merge window
Thomas Gleixner writes: > But the current SoC maintainer model does not work either. The SoC > maintainers care about their sandbox and have exactly zero incentive > to look at the overall picture, e.g reuse of code for the same IP > blocks, better abstraction mechanisms etc. zero incentive? that's a bit strong, IMO. That may be true for some SoCs, it's not really fair as a sweeping statement. Some SoCs families (like OMAP) have huge amount of diversity even within the SoC family, so better abstractions and generic infrastrucure improvements are an obvious win, even staying within the SoC. There are several examples of SoC maintainers looking at the overall picture and contributing to better abstractions and common infrastructure code. One is USB as Felipe already pointed out where the same USB OTG IP block (with vendor tweaks of course) is used across several completely different SoCs with common infrastructure code. Another example that I'm more familiar with is power management. In OMAP land, we have been been very supportive and active in generic infrastructure improvements (like runtime PM.) In fact runtime PM was born partially because one of the other ARM SoC maintainers (Magnus Damm, SH-mobile) proposed the idea as he was implementing PM for that SoC family. We have been actively contributing to the runtime PM infrastructure with both code, testing, converting our drivers over to using runtime PM. and contributing back fixes and enhancements as we find problems or limitations. In addition, personally, I have spent the last year evangelizing the importance of using common frameworks like runtime PM to the embedded community via talks at the Embedded Linux Conference (ELC, US and Europe.) Especially as IP blocks are reused across SoC families, abstractions like runtime PM are the only way to keep the SoC specifics of PM out of the common driver. Yes, ARM SoC maintainers have to make up some ground. But compare this to just a couple years ago where the common complaint was "why aren't embedded SoC people contributing code to mainline", and you'll see we have come a long way. Kevin Maintainer of parts of the ARM kernel: - TI Davinci SoC family - TI OMAP Power Management infrastructure -- 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 changes for v2.6.39 merge window
Russell: On Thu, Mar 31, 2011 at 8:01 AM, Russell King - ARM Linux wrote: > > And since Linus' whinge about ARM defconfigs, I really *hate* merging > anything with *any* defconfig changes in - as a result, I don't > particularly want to deal with ARM defconfig changes anymore. I think the defconfigs are as important as the code itself! Sure there is a lot of churn in them--- just let git deal with it and move on. The defconfigs and board code provide critical reference models for new platform developers. If these models aren't right, then you end up providing bad references that get replicated over and over again. It multiplies the problem we're trying to solve. > Just look at the removal of AAEC2000, LH7A40x and 2000 lines from the > mach-types file removed 6000 lines, which in itself is about the number > of lines of change submitted during the last merge window for any one > non-ARM architecture. At this point in time with this complaint, I've > absolutely no idea why I bothered to do that. I should've left it well > alone and then the diffstat percentage would've been smaller. After > all, it's "pointless churn". I think you did it because it was the Right Thing To Do. Even positive change can be painful at times. The majority is exceedingly grateful for the effort you make. b.g. -- Bill Gatliff b...@billgatliff.com -- 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: Code for v2.6.39 merge window frozen, patches archived
Hi, On Wed, 30 Mar 2011, Kevin Hilman wrote: Tony Lindgren writes: FYI, looks like we've started hitting some booter -l kernel size limit in addition to booter -f size limit.. Now kernels built with omap2plus_defconfig won't boot on n900 any longer. I guess you are seeing it just hanging at "Uncompressing Linux... done, booting the kernel."? I guess the way around that is to install the u-boot loader package. Alternatively CONFIG_KERNEL_LZMA=y will get the kernel zImage size back within size limits that will boot on n900. Hmm, I'm a bit puzzled. For me, .38 works but .39-rc1 does not, and I can't see any "special" limit exceeded. Also LZMA is broken: Uncompressing Linux... LZMA data is corrupt -- System halted I did some bisecting, and with the following commit reverted -rc1 works: commit d239b1dc093d551046a909920b5310c1d1e308c1 Author: Nicolas Pitre Date: Mon Feb 21 04:57:38 2011 +0100 ARM: 6746/1: remove the 4x expansion presumption while decompressing the kernel With the revert, also bigger gzipped kernel works. A. -- 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 changes for v2.6.39 merge window
On Thu, 31 Mar 2011, Kevin Hilman wrote: > Thomas Gleixner writes: > > > But the current SoC maintainer model does not work either. The SoC > > maintainers care about their sandbox and have exactly zero incentive > > to look at the overall picture, e.g reuse of code for the same IP > > blocks, better abstraction mechanisms etc. > > zero incentive? that's a bit strong, IMO. > > That may be true for some SoCs, it's not really fair as a sweeping > statement. Fair enough, but it's the perception in general. > Conference (ELC, US and Europe.) Especially as IP blocks are reused > across SoC families, abstractions like runtime PM are the only way to > keep the SoC specifics of PM out of the common driver. Right, I know that these things happen, but at the same time the sheer amount of stuff flowing in makes it hard that these infrastructure stuff really works out. And we are only at the beginning of the big shuffle "code in to mainline" game. After cleaning up the whole irq stuff across the tree I can tell you, that the mess is non-linear growing with the number of instances. You can see the patterns which are: - copy and paste - introduce different bugs - add more abuse That's what I'm really concerned about. > Yes, ARM SoC maintainers have to make up some ground. But compare this > to just a couple years ago where the common complaint was "why aren't > embedded SoC people contributing code to mainline", and you'll see we > have come a long way. Well, code comes in, which is progress. But we need to figure out how to deal with the increasingly growing flood before we drown in it. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: hwmod: add syss reset done flags to omap2, omap3 hwmods
"Avinash.H.M." writes:
>> > > [0.208892] omap_hwmod: i2c1: softreset failed (waited 1 usec)
>> > > [0.223114] omap_hwmod: i2c2: softreset failed (waited 1 usec)
>> > > [0.237335] omap_hwmod: i2c3: softreset failed (waited 1 usec)
>> > > [0.251525] omap_hwmod: gpio2: softreset failed (waited 1 usec)
>> > > [0.265594] omap_hwmod: gpio3: softreset failed (waited 1 usec)
>> > > [0.279693] omap_hwmod: gpio4: softreset failed (waited 1 usec)
>> > > [0.293762] omap_hwmod: gpio5: softreset failed (waited 1 usec)
>> > > [0.307861] omap_hwmod: gpio6: softreset failed (waited 1 usec)
>
> Hi Paul,
>
> I tested this on one more board and still got these softreset warnings.
> So this wasn't a board specific issue and debugged into what is causing
> these.
>
> The problem is the FCLK isn't enabled for these gpios(2..6) while
> resetting. So the GPIO's are not resetting properly. Once i enable FCLK
> for them and then set the SYSCONFIG.SOFTRESET, then they are resetting
> and it is reflected in RESETDONE bit.
What do you mean by fclk here. GPIO doesn't have an fclk. The
interface clock provides the functional clock, and the optional debounce
clock (dbclk) is needed only when GPIO debounce is enabled.
I suggest you look at the "integration" sub chapter of the TRM for the
GPIO module.
> That being said, I was looking for accessing gpio2_fck in the
> gpio2_hwmod. But i find the structure as below,
>
> static struct omap_hwmod omap3xxx_gpio2_hwmod = {
> .name = "gpio2",
> .mpu_irqs = omap3xxx_gpio2_irqs,
> .mpu_irqs_cnt = ARRAY_SIZE(omap3xxx_gpio2_irqs),
> .main_clk = "gpio2_ick",
>
> Is there any reason, why 'iclk' is set as the 'main_clk' and not 'fclk'.
There are no GPIO fclks.
> Also 'fclk' is structured as 'gpio2_dbck' and made as an optional
> clock. I wasn't very sure, why the name 'dbck'?
dbck == debounce clock
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: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, Mar 31, 2011 at 05:01:40PM +0200, Thomas Gleixner wrote: > On Thu, 31 Mar 2011, Kevin Hilman wrote: > > > Thomas Gleixner writes: > > > > > But the current SoC maintainer model does not work either. The SoC > > > maintainers care about their sandbox and have exactly zero incentive > > > to look at the overall picture, e.g reuse of code for the same IP > > > blocks, better abstraction mechanisms etc. > > > > zero incentive? that's a bit strong, IMO. > > > > That may be true for some SoCs, it's not really fair as a sweeping > > statement. > > Fair enough, but it's the perception in general. > > > Conference (ELC, US and Europe.) Especially as IP blocks are reused > > across SoC families, abstractions like runtime PM are the only way to > > keep the SoC specifics of PM out of the common driver. > > Right, I know that these things happen, but at the same time the sheer > amount of stuff flowing in makes it hard that these infrastructure > stuff really works out. And we are only at the beginning of the big > shuffle "code in to mainline" game. > > After cleaning up the whole irq stuff across the tree I can tell you, > that the mess is non-linear growing with the number of instances. > > You can see the patterns which are: > - copy and paste > - introduce different bugs > - add more abuse > > That's what I'm really concerned about. > > > Yes, ARM SoC maintainers have to make up some ground. But compare this > > to just a couple years ago where the common complaint was "why aren't > > embedded SoC people contributing code to mainline", and you'll see we > > have come a long way. > > Well, code comes in, which is progress. But we need to figure out how > to deal with the increasingly growing flood before we drown in it. How about we declare the remainder of this cycle and the next merge window as being only for bug and regression fixes, and consolidation of stuff like the IRQ controller and GPIO controller code for the next merge window? -- 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 changes for v2.6.39 merge window
On Thursday 31 March 2011, Kevin Hilman wrote: > Some SoCs families (like OMAP) have huge amount of diversity even within > the SoC family, so better abstractions and generic infrastrucure > improvements are an obvious win, even staying within the SoC. But that's the point. The incentive is there for managing the infrastructure within the SoC, but not across SoCs. Allow me to use OMAP as a bad example while pointing out that it's really one of the best supported platforms we currently have, while the others are usually much worse in terms of working with the community (or at least they are behind on the learning curve but getting there): * OMAP2 introduced the hwmod concept as an attempt to reduce duplication between board code, but the code was done on the mach-omap2 level instead of finding a way to make it work across SOC vendors, or using an existing solution. * The IOMMU code in omap2 duplicates the API we have in the common kernel, with slight differences, instead of using the existing code, making it impossible to share a driver between SOC families. * The ti-st code duplicates parts of the bluetooth layer (apparently that is getting fixed soon). * The DSS display drivers introduce new infrastructure include new bus types that have the complexity to make them completely generic, but in practice can only work on OMAP, and are clearly not written with cross-vendor abstractions in mind. Arnd -- 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] omap: rx51: Platform support for lp5523 led chip
Hi Felipe,
On 03/31/2011 05:26 PM, ext Felipe Balbi wrote:
Hi,
On Thu, Mar 31, 2011 at 04:38:12PM +0300, Ameya Palande wrote:
+static int rx51_lp5523_setup(void)
+{
+ int err;
+
+ err = gpio_request_one(RX51_LP5523_CHIP_EN_GPIO, GPIOF_DIR_OUT,
+ "lp5523_enable");
+ if (err< 0) {
+ pr_err("Unable to get lp5523_enable GPIO\n");
+ return err;
+ }
+
+ return err;
isn't enough to return gpio_request_one(RX51_LP5523_CHIP_EN_GPIO,
GPIOF_DIR_OUT, "lp5523_enable"); ??
But then we won't know the failure reason for lp5523_probe()
I would prefer printing an error!
Cheers,
Ameya.
--
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] omap: rx51: Platform support for lp5523 led chip
On Thu, Mar 31, 2011 at 06:30:32PM +0300, Ameya Palande wrote:
> Hi Felipe,
>
> On 03/31/2011 05:26 PM, ext Felipe Balbi wrote:
> >Hi,
> >
> >On Thu, Mar 31, 2011 at 04:38:12PM +0300, Ameya Palande wrote:
> >>+static int rx51_lp5523_setup(void)
> >>+{
> >>+ int err;
> >>+
> >>+ err = gpio_request_one(RX51_LP5523_CHIP_EN_GPIO, GPIOF_DIR_OUT,
> >>+ "lp5523_enable");
> >>+ if (err< 0) {
> >>+ pr_err("Unable to get lp5523_enable GPIO\n");
> >>+ return err;
> >>+ }
> >>+
> >>+ return err;
> >
> >isn't enough to return gpio_request_one(RX51_LP5523_CHIP_EN_GPIO,
> >GPIOF_DIR_OUT, "lp5523_enable"); ??
>
> But then we won't know the failure reason for lp5523_probe()
> I would prefer printing an error!
see that both gpio_request() and gpio_direction_output() have debugging
prints for error cases ;-)
--
balbi
--
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 changes for v2.6.39 merge window
On Thu, 31 Mar 2011, Russell King - ARM Linux wrote: On Thu, Mar 31, 2011 at 05:01:40PM +0200, Thomas Gleixner wrote: On Thu, 31 Mar 2011, Kevin Hilman wrote: Thomas Gleixner writes: Yes, ARM SoC maintainers have to make up some ground. But compare this to just a couple years ago where the common complaint was "why aren't embedded SoC people contributing code to mainline", and you'll see we have come a long way. Well, code comes in, which is progress. But we need to figure out how to deal with the increasingly growing flood before we drown in it. How about we declare the remainder of this cycle and the next merge window as being only for bug and regression fixes, and consolidation of stuff like the IRQ controller and GPIO controller code for the next merge window? well, now that -rc1 has been released, the remainder of this cycleis already only bug and regression fixes. declaring the next merge window as the same may or may not help, depending on if it pushes people to do more consolodations work or just delay submitting the work they are doing. David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: hwmod: add syss reset done flags to omap2, omap3 hwmods
> > The problem is the FCLK isn't enabled for these gpios(2..6) while > > resetting. So the GPIO's are not resetting properly. Once i enable FCLK > > for them and then set the SYSCONFIG.SOFTRESET, then they are resetting > > and it is reflected in RESETDONE bit. > > What do you mean by fclk here. GPIO doesn't have an fclk. The > interface clock provides the functional clock, and the optional debounce > clock (dbclk) is needed only when GPIO debounce is enabled. > > I suggest you look at the "integration" sub chapter of the TRM for the > GPIO module. Hi Kevin , I looked at this section. Now i am clear about the code. I meant fclk as functional clocks which is described by register CM_FCLKEN_PER, bit 12 to bit 17. These bits are described as they control 'GPIO x functional clock'. Looking at the GPIO chapter, i understood that this is same as the gpio dbck. This was confirmed by section 'PER Power Domain Clock Controls' where he says CM_FCLKEN_PER[12-17] control PER_32K_ALWON_FCLK which is routed as GPIOx_DBCLK. [...] > > There are no GPIO fclks. > > > Also 'fclk' is structured as 'gpio2_dbck' and made as an optional > > clock. I wasn't very sure, why the name 'dbck'? > > dbck == debounce clock I got it. Thanks for the clarification. Looks like without this clock, GPIO module isn't resetting even on writing to SYSCONFIG register. Should we provide a seperate reset function for gpio, like the way it was suggested for i2c ? br , - Avinash > > 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] omap: hwmod: add syss reset done flags to omap2, omap3 hwmods
On 3/31/2011 5:51 PM, Mahadeva, Avinash wrote: The problem is the FCLK isn't enabled for these gpios(2..6) while resetting. So the GPIO's are not resetting properly. Once i enable FCLK for them and then set the SYSCONFIG.SOFTRESET, then they are resetting and it is reflected in RESETDONE bit. What do you mean by fclk here. GPIO doesn't have an fclk. The interface clock provides the functional clock, and the optional debounce clock (dbclk) is needed only when GPIO debounce is enabled. I suggest you look at the "integration" sub chapter of the TRM for the GPIO module. Hi Kevin , I looked at this section. Now i am clear about the code. I meant fclk as functional clocks which is described by register CM_FCLKEN_PER, bit 12 to bit 17. These bits are described as they control 'GPIO x functional clock'. Looking at the GPIO chapter, i understood that this is same as the gpio dbck. This was confirmed by section 'PER Power Domain Clock Controls' where he says CM_FCLKEN_PER[12-17] control PER_32K_ALWON_FCLK which is routed as GPIOx_DBCLK. [...] There are no GPIO fclks. Also 'fclk' is structured as 'gpio2_dbck' and made as an optional clock. I wasn't very sure, why the name 'dbck'? dbck == debounce clock I got it. Thanks for the clarification. Looks like without this clock, GPIO module isn't resetting even on writing to SYSCONFIG register. Should we provide a seperate reset function for gpio, like the way it was suggested for i2c ? No need for that, it is already working like that on OMAP4. We have a nice flag that handle that clock during reset. .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET, 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: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, 31 Mar 2011, Russell King - ARM Linux wrote: On Thu, Mar 31, 2011 at 10:06:34AM +0200, Ingo Molnar wrote: Having strong, effective platform abstractions inside the kernel really helps even if the hardware space itself is inevitably fragmented: both powerpc and x86 has shown that. Until you realize and appreciate that you really have not understood the problem i think. No, I think it is the other way around. Folk like me and Nicolas over the last ten years have put considerable amounts of effort into trying to keep the ARM support code as clean and maintainable as possible. In this case I owe you and Nicolas an apology. I think that part of the issue is that when Linus points out a problem, the response isn't "we agree and are working on it, here's what we are doing", instead it seems to be mostly "there is no problem, this is just because there is so much variation in ARM" Linus does look at the code he pulls, if he is pulling changesets that are described as consolodations and cleanups, he won't be whining about code churn. but if he is just pulling chnagesets that are described as "addsupport for board X" or "modify defconfig defaults" he is going to complain. it's not the total amount of code, and it's not even the total amount of change to the code that's the issue. It's that the changes are conflicting with each other (due to things like central config tables that multiple people are updating in different ways) and the same files getting modified frequently, many times in ways that don't seem to have a clear direction (defconfigs for example) David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: hwmod: add syss reset done flags to omap2, omap3 hwmods
> >Looks like without this clock, GPIO module isn't resetting even on > >writing to SYSCONFIG register. Should we provide a seperate reset > >function for gpio, like the way it was suggested for i2c ? > > No need for that, it is already working like that on OMAP4. > We have a nice flag that handle that clock during reset. > > .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET, Thanks benoit. I'll use this flag and try resetting GPIO module. br , - avinash > > Regards, > Benoit > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, Mar 31, 2011 at 09:03:28AM -0700, da...@lang.hm wrote: > In this case I owe you and Nicolas an apology. Thanks. > it's not the total amount of code, and it's not even the total amount of > change to the code that's the issue. I think you're not entirely correct - have a look at Linus' message where there's a comparison of the size of arch/arm with other architectures, and you'll find that it is partly about size of source code. -- 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 changes for v2.6.39 merge window
On Thu, 31 Mar 2011, Arnd Bergmann wrote:
> On Thursday 31 March 2011, Kevin Hilman wrote:
> > Some SoCs families (like OMAP) have huge amount of diversity even within
> > the SoC family, so better abstractions and generic infrastrucure
> > improvements are an obvious win, even staying within the SoC.
>
> But that's the point. The incentive is there for managing the infrastructure
> within the SoC, but not across SoCs. Allow me to use OMAP as a bad example
> while pointing out that it's really one of the best supported platforms
> we currently have, while the others are usually much worse in terms of
> working with the community (or at least they are behind on the learning
> curve but getting there):
>
> * OMAP2 introduced the hwmod concept as an attempt to reduce duplication
> between board code, but the code was done on the mach-omap2 level
> instead of finding a way to make it work across SOC vendors, or using
> an existing solution.
>
> * The IOMMU code in omap2 duplicates the API we have in the common kernel,
> with slight differences, instead of using the existing code, making it
> impossible to share a driver between SOC families.
>
> * The ti-st code duplicates parts of the bluetooth layer (apparently
> that is getting fixed soon).
>
> * The DSS display drivers introduce new infrastructure include new bus
> types that have the complexity to make them completely generic, but
> in practice can only work on OMAP, and are clearly not written with
> cross-vendor abstractions in mind.
Right, but the problem starts in way simpler areas like irq chips and
gpio stuff, where lots of the IP cores are similar and trivial enough
to be shared across many SoC families.
Even the OMAP "consolidated" code is silly:
static void _set_gpio_dataout(struct gpio_bank *bank, int gpio, int enable)
{
void __iomem *reg = bank->base;
u32 l = 0;
switch (bank->method) {
#ifdef CONFIG_ARCH_OMAP1
case METHOD_MPUIO:
reg += OMAP_MPUIO_OUTPUT / bank->stride;
l = __raw_readl(reg);
if (enable)
l |= 1 << gpio;
else
l &= ~(1 << gpio);
break;
#endif
#ifdef CONFIG_ARCH_OMAP15XX
case METHOD_GPIO_1510:
reg += OMAP1510_GPIO_DATA_OUTPUT;
l = __raw_readl(reg);
if (enable)
l |= 1 << gpio;
else
l &= ~(1 << gpio);
break;
#endif
#ifdef CONFIG_ARCH_OMAP16XX
case METHOD_GPIO_1610:
if (enable)
reg += OMAP1610_GPIO_SET_DATAOUT;
else
reg += OMAP1610_GPIO_CLEAR_DATAOUT;
l = 1 << gpio;
break;
#endif
#if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
case METHOD_GPIO_7XX:
reg += OMAP7XX_GPIO_DATA_OUTPUT;
l = __raw_readl(reg);
if (enable)
l |= 1 << gpio;
else
l &= ~(1 << gpio);
break;
#endif
#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
case METHOD_GPIO_24XX:
if (enable)
reg += OMAP24XX_GPIO_SETDATAOUT;
else
reg += OMAP24XX_GPIO_CLEARDATAOUT;
l = 1 << gpio;
break;
#endif
#ifdef CONFIG_ARCH_OMAP4
case METHOD_GPIO_44XX:
if (enable)
reg += OMAP4_GPIO_SETDATAOUT;
else
reg += OMAP4_GPIO_CLEARDATAOUT;
l = 1 << gpio;
break;
#endif
default:
WARN_ON(1);
return;
}
__raw_writel(l, reg);
}
So we have 2 types of sections:
#1
data = read_reg();
if (enable)
data |= bit;
else
data &= ~bit;
write_reg(data);
#2
if (enable)
write_enable_reg(bit);
else
write_disable_reg(bit);
But the code above has 6 cases in the switch because nobody abstracted
it out consequently. Not to talk about the ifdef mess.
So now look at tons of other gpio implementations all over the DOZENS
of ARM plat-/mach- space and guess what.
Most have either type #1 or type #2 just slightly different copied,
less or better abstracted and I'm pretty damned sure, that you could
consolidate all that stuff into a handful or even less drivers which
provide the code across the board.
Same for irq chips. Most of these gpio things have callbacks which do:
irq_xxx(struct irq_data *d)
{
gpio = irq_data_get_irq_chip_data(d);
irq = d->irq - gpio->base_irq;
reg = convert_to_reg(gpio, irq);
mask = convert_to_mask(gpio);
write(reg, mask);
}
I saw all those incarnations lately and you can boil them down to a
handful or less as
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, Mar 31, 2011 at 9:45 AM, Russell King - ARM Linux wrote: > > I think you're not entirely correct - have a look at Linus' message where > there's a comparison of the size of arch/arm with other architectures, and > you'll find that it is partly about size of source code. It definitely is partly about code size, although I tend to use it as an easy illustration of the issues rather than anything deeper than that. The code size is a symptom of the problem. The deeper problem is the crazy arm hardware infrastructure. We can't do much about that, but it does mean that I _do_ think we need to take approaches that aren't necessary when that deeper problem doesn't exist. For example, I don't think it's problematic that we have various drivers that do their own gpio thing. Why? Because those things are generally part of a bigger chip/driver that is discoverable, and they don't tend to proliferate in various crazy random amounts - nor do they tend to impact anything else. Nor does it look like that is going to explode in the future any more than any normal driver work is exploding. Or look at the irq controllers we have on most other architectures. x86 has several of them too, and it's annoying. But it's "several", not "hundreds", and again, it's not exploding or looking like it will be a major pain to support. I doubt Thomas enjoyed having to work with the legacy controllers, but I also doubt he had huge problems on the x86 side. What does that mean? _I_ think it means that ARM platform managers need to worry about things that other platform managers don't necessarily need to worry about as much. Things that works for others will _not_ work for ARM, because the platforms don't have the same kind of sticking power. Other architectures just don't have the same kinds of issues, so they don't need to worry about them. An right now just from the kinds of pulls I do, I see all these ARM platform maintainers doing their own thing, and adding new platforms all the time (with a _very_ occasional removal of some old platform support just because it was a prototype that never went anywhere at all). What I'm _not_ seeing is a lot of cross-platform maintenance or sense of people trying to reign things in and look for solutions to the proliferation of random stupid and mindless platform code. Even _within_ platforms, I see conflicts like the crazy clock files - and between platforms I don't see any conflicts for the simple reason that people are just duplicating crap and adding more and more of these mindless things. "A new platform? Let's just create a new directory, fill it with all the same template crud, and then tweak the code to match". It's simple, but it's not maintainable. So it's not the size PER SE. But the size is a damn easy first-order "we have a problem" sign. ARM is clearly an important architecture, but that doesn't excuse the crazy bloating. x86 had this too - the whole mindless duplication of x86-64. It got merged. It required cleanups, it required effort, it required time. And it required some abstractions. x86 never had much of a _platform_ duplication, and the different platforms that did exist were so clearly secondary that they never rated any first-class code: they always knew that they were a second-class citizen and had to work within the framework of trying to hook into the main PC platform code. Power did a lot of platform unification, despite having much less of a problem than ARM to begin with. The "less of a problem" made it easier to do, but also less critical. And I don't think it's realistic to convert all ARM platforms in one go, and nobody should even plan anything like that. But I _do_ think that some of the major platforms (like omap) should seriously just say "we can't continue doing this", and look at converting at least everything they do to something like devicetree (NOT some omap-specific infrastructure!) rather than lots of explicit code. Done right, that hopefully then shows other platforms how to do the same, and get the ball rolling. Linus -- 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 changes for v2.6.39 merge window
On Thu, 31 Mar 2011, Russell King - ARM Linux wrote: On Thu, Mar 31, 2011 at 10:54:40AM +0100, Alan Cox wrote: If I boot it on a current PC I'm booting on a multiprocessor system with different timers, totally different IRQ controllers, different keyboard controllers (USB), PCI Express, an IOMMU, NCQ SATA, ACPI, graphics running in shared host memory able to give/take pages from the host, extra instructions, etc etc And the same kernel boots just fine on both just fine. We've been there for a long time with ARM. Right from the start I had a single kernel image which booted over a range of ARM CPUs and platforms. As far as ARM CPU architectures go, today we can have a single kernel image which covers ARMv3 to ARMv5, and a separate kernel image which covers ARMv6 to ARMv7 including SMP and UP variants. The thing which currently stops ARMv3 to ARMv7 all together is the different page table layouts, the ASID tagging, the exclusive load/store support for cmpxchg and other atomic operations, etc. I don't think the push is to get a single kernel image that boots absolutly everywhere. having separate ARM5 and ARM7 kernels doesn't seem to be a big deal to anyone. Outside of the CPU architecture, things become a lot more complicated. exactly, and this is where there is an issue. The biggest one up until this merge window was that there is no fixed address for system RAM, which makes stuff like virt_to_phys() rather horrible to deal with - which in turn makes setting up and walking page tables a nightmare. We've just solved that issue with run-time patching of the kernel code to replace the add/sub instructions with ones with the appropriate offset, so we're a step closer to unifying everything into one single kernel image. This work alone produced this diffstat: 87 files changed, 450 insertions(+), 190 deletions(-) so it actually resulted in a net increase in the amount of code to be maintained rather than reducing it. That's hardly surprising as what that replaced was just a bunch of #define's for PHYS_OFFSET with some complex assembly code to do run-time patching of instructions. but I don't think this sort of work is what anyone is complaining about. Given this thread, I've lost the motivation to continue with it because it's just going to cause more 'pointless churn' and end up annoying Linus even more. it sounds like you are part of the solution, not part of the problem. the biggest problem is the general response from 'the ARM community' when these sorts of issues are raised claiming that there is no problem. you seem to be very aware of the problem and are working to fix it. that is a very different situaion. David Lang -- 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 00/10] omap init_early changes for irq and timer init
* Santosh Shilimkar [110331 01:14]: > On 3/30/2011 11:52 PM, Tony Lindgren wrote: > > >What it does not have is the code to dedicate gpt1 for PM > >code, which can be done later once all the other dmtimer > >changes are done. > > > Which not possible to do unless you plan to hack generic > timer framework or waste additional timer hardware for > this. Well an extra timer hardware would only be needed on omap2 & 3. But hey, if it makes sense to do or not to do is a different set of patches. At least we now have an option to play with it. > >For removing the old interface, I don't see any reason to > >select timer combinations on omap3 other than omap3_timer > >and omap3_beagle_timer. > > > >If there's need, any new valid sane combinations can be esily > >added, although I seriously doubt that we'll need more for > >omap3. > > > May be I am wrong but the point is about the merit of the > solution even if there are only couple of board files where > we use that interface. > > It much cleaner and simpler to say timerid=X, from board > file rather than creating a "struct sys_timer" instance > and putting that in timer code. Well the timerid=X adds yet another interface and more calls from board-*.c to the common code. And it requires more changes if beagle boards want to use the system clock as the source clock instead of the 32KiHZ source. Maybe let's call the omap3_beagle_timer omap3_secure_timer instead? That should solve your issue of having the board name show up in the generic code, no? > >>At least I don't see other solution than using GPT1 > >>for wakeup. > > > >Right, there's no other way to wake except gpt1 or wake-up > >enabled gpio lines. But we don't need to use gpt1 during > >runtime at all. > > > This is not entirely correct and I think this is the point > where we are not on same page. During runtime, gpt1 clock > event is not used for tick generation but it's kept > programmed because low power state switch via > get triggered any time and on any CPU. Well ideally we would not program it during runtime at all because it's slow to program. I don't think that can be currently done with the sys_timer. > This is the same problem as X86 APIC timer + HPET > switching and I worked with Thomas G and Russell > to get this working on ARM platforms using generic > timer framework. No hacking is needed in PM code > for this. Except we should improve things eventually where we don't need to program the slow external timer during runtime if we have local timers. Hmm maybe I'm wrong and you got that working already? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, 31 Mar 2011, da...@lang.hm wrote: > I think that part of the issue is that when Linus points out a problem, the > response isn't "we agree and are working on it, here's what we are doing", > instead it seems to be mostly "there is no problem, this is just because there > is so much variation in ARM" The problem is two-fold: 1) - "ARM hardware manufacturers are morons"... - ARM vendors "do things differently just to be difficult"... - "the crazy arm fragmentation"... Translate this into whatever ways you like. The fact is that ARM is quite popular as a CPU core but there is very little in terms of standardization around that CPU core. *OBVIOUSLY* this is a problem. But there is _nothing_ we can do about that besides the current moaning and the hope that those vendors will hear us and stop trying to be different from their competitors. Apparently that won't happen in the near future, so we can either sit on our arses proclaiming repeatedly that this is a problem until those hardware vendors put their acts together, or we find ways to deal with it somehow. 2) Because of (1) we do end up being floded by SOC specific support code with an unprecedented scale. Here's the stat: $ git diff --shortstat v2.6.38..v2.6.39-rc1 arch/arm/ 1319 files changed, 61303 insertions(+), 33780 deletions(-) $ git diff --shortstat v2.6.38..v2.6.39-rc1 arch/x86/ 241 files changed, 6508 insertions(+), 4326 deletions(-) That's ten (10) times more lines added in the ARM directory than in the X86 directory. Is this a sudden burst or a tendency? $ git diff --shortstat v2.6.37..v2.6.38 arch/arm/ 1257 files changed, 72412 insertions(+), 29361 deletions(-) $ git diff --shortstat v2.6.37..v2.6.38 arch/x86/ 216 files changed, 10021 insertions(+), 5016 deletions(-) $ git diff --shortstat v2.6.36..v2.6.37 arch/arm/ 1314 files changed, 55072 insertions(+), 17620 deletions(-) $ git diff --shortstat v2.6.36..v2.6.37 arch/x86/ 299 files changed, 16130 insertions(+), 12800 deletions(-) $ git diff --shortstat v2.6.35..v2.6.36 arch/arm 1041 files changed, 53428 insertions(+), 25722 deletions(-) $ git diff --shortstat v2.6.35..v2.6.36 arch/x86/ 231 files changed, 7216 insertions(+), 8028 deletions(-) So that appears to be quite "normal" to see ARM vendors together producing many times the level of activities compared to X86. So... Is there missed opportunity for better code reuse here? Most probably. Is all that code the result of misabstracted and duplicated code? Certainly not. Let's just presume that half of that code is genuine crap and the other half is simply the result of new hardware for which there is no existing model to fit it in. Even then, do we have 5 times the reviewer bandwidth to properly review all that code compared to X86? Absolutely not, not even close. If prominent people looking at this from the side line continue bashing at those who are both feet in the mud trying to contain the flood rather than actually helping then nothing will change. Instead this only creates despair and the splashed people may simply decide to throw in the towel, at which point things will collapse for real. In reality, the system has been going as it is for quite a while and with more or less the same level of intensity. And the fact is that _users_ of the ARM kernel are not complaining. Things are far from being perfect, but so far things have been "good enough" for the majority of the people involved, and improvements are constantly being worked on with the men power available. Nicolas -- 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 changes for v2.6.39 merge window
Op 31 mrt 2011, om 19:22 heeft da...@lang.hm het volgende geschreven: > On Thu, 31 Mar 2011, Russell King - ARM Linux wrote: > >> On Thu, Mar 31, 2011 at 10:54:40AM +0100, Alan Cox wrote: >>> If I boot it on a current PC I'm booting on a multiprocessor system with >>> different timers, totally different IRQ controllers, different keyboard >>> controllers (USB), PCI Express, an IOMMU, NCQ SATA, ACPI, graphics >>> running in shared host memory able to give/take pages from the host, >>> extra instructions, etc etc >>> >>> And the same kernel boots just fine on both just fine. >> >> We've been there for a long time with ARM. Right from the start I had >> a single kernel image which booted over a range of ARM CPUs and >> platforms. >> >> As far as ARM CPU architectures go, today we can have a single kernel >> image which covers ARMv3 to ARMv5, and a separate kernel image which >> covers ARMv6 to ARMv7 including SMP and UP variants. The thing which >> currently stops ARMv3 to ARMv7 all together is the different page table >> layouts, the ASID tagging, the exclusive load/store support for cmpxchg >> and other atomic operations, etc. > > I don't think the push is to get a single kernel image that boots absolutly > everywhere. having separate ARM5 and ARM7 kernels doesn't seem to be a big > deal to anyone. You mean ARMv5 and ARMv7, right? ARM5 and ARM7 are completely different things. The short, but inaccurate version: ARM9 -> ARMv4t, ARMv5te* ARM11 -> ARMv6* CORTEX-A* -> ARMv7a regards, Koen-- 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 changes for v2.6.39 merge window
Hello, Am 31.03.2011 10:09, schrieb Russell King - ARM Linux: We also need the various SoC designers and ARM architecture people to realise that what the hardware situation is rediculous; I have commented about this lack of standardisation to ARM in past years. ARM have had a standard set of peripherals for ten years, but the SoC people haven't really taken them up - and when they do, they seem to always introduce their own tweaks, sometimes with no way to detect those tweaks. As a user of several ARM boards I fully agree. I've come to the conclusion that if device tree or something similiar won't come up, which offers a vendor independent description of the hardware, the ARM market (at least with Linux as an OS) won't function. It's already almost impossible to update an old vendor kernel to a mainline kernel version without having schematics. Up to now this isn't a big problem because most ARM-HW people are playing with are developer boards, but thats already changing and more and more stuff will come without schematics. And without the help of something like the x86 BIOS (or DT for ARM) you are just lost using an ARM-HW where you don't have the schematics, when you don't want to use the vendor provided kernel sources (for which you almost never get e.g. any security fixes). Finding all the small knobs to turn out of vendor provided kernel sources is a pain and just a waste of time you almost never can't finish before the HW in question got obsolete. Just my 2¢ on that topic from a somewhat user point of view from one who isn't really involved that much in kernel development. At least I find such a rant from Linus from time to time a good thing. Sometimes it helps if someone speaks out loud whats wrong. And if Linus wouldn't be that one, who else would be courageous enough to do that? I wouldn't (and I can't, I have to thank all kernel developers for their hard work). Regards, Alexander -- 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 changes for v2.6.39 merge window
> And since Linus' whinge about ARM defconfigs, I really *hate* merging > anything with *any* defconfig changes in - as a result, I don't > particularly want to deal with ARM defconfig changes anymore. I thought we solved this with the introduction of "make savedefconfig" that created much much smaller defconfig. At least the defconfigs should be down in the noise level in the diffstats. We can always argue about the usefullness of the 100+ defconfigs, that is still unreadable. But at least they no longer dominate the diffs (if people remember to use "make savedefconfig". Sam -- 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 changes for v2.6.39 merge window
On Thu, Mar 31, 2011 at 08:12:54PM +0200, Sam Ravnborg wrote: > > And since Linus' whinge about ARM defconfigs, I really *hate* merging > > anything with *any* defconfig changes in - as a result, I don't > > particularly want to deal with ARM defconfig changes anymore. > > I thought we solved this with the introduction of "make savedefconfig" > that created much much smaller defconfig. Did we solve it to Linus' satisfaction, or did we solve it sufficiently to avoid the immediate threat of them all being removed and we still have work to do? I've no idea. Personally, I'd still like to see less of them but without significantly impacting the usefulness of automated built tooks like Simtec's kautobuild. -- 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 changes for v2.6.39 merge window
On Thu, 31 Mar 2011, Thomas Gleixner wrote: > Start off with such a trivial, but immense effective cleanup and see > what it helps to share code even accross SoC vendors. They all glue > together random IP blocks from the market and there are not soo many > sources which are relevant. This makes sense in all aspects: > > 1) less and better code > 2) faster setup for new SoCs > 3) shared benefit for all vendors If this was always true. Someone commented on the fact that the IP block providing USB on OMAP is shared with a couple other platforms. But about 2600 lines of pure glue is still necessary around the common driver to make it work for everyone. I'm not saying that separate drivers are called for here, simply that hardware people _will_ screw it up, especially when they are hooking it up to a non-standard SOC-specific bus. Another example: there used to be many different IP blocks providing MMC/SD/SDIO support that people were adding to their SOCs. Each SOC would have its own reinvention of the wheel but they were all different but simple wheels, and drivers for them were obvious and straight forward. Then came the SDHCI "standard". At first few implementation existed so the sdhci driver was, too, rather straight forward. But hardware manufacturers thought (rightfully) that this would be a good idea to use that standard instead of using their custom simple wheel. And so they did, releasing new SOC revision with the old wheel replaced by a square implementation of the sdhci one. Today the sdhci driver is literally bastardized by all the quirks needed to work around all the different and creative bugs or even standard misinterpretation of the standard out there in the field. And in many cases the sdhci version is even _less_ functional than the custom and already supported implementation it replaced. And what would the hardware guys tell you? That software is cheap. Nicolas -- 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 changes for v2.6.39 merge window
On Thu, 31 Mar 2011 19:17:51 +0100 Russell King - ARM Linux wrote: > On Thu, Mar 31, 2011 at 08:12:54PM +0200, Sam Ravnborg wrote: > > > And since Linus' whinge about ARM defconfigs, I really *hate* merging > > > anything with *any* defconfig changes in - as a result, I don't > > > particularly want to deal with ARM defconfig changes anymore. > > > > I thought we solved this with the introduction of "make savedefconfig" > > that created much much smaller defconfig. > > Did we solve it to Linus' satisfaction, or did we solve it sufficiently > to avoid the immediate threat of them all being removed and we still have > work to do? I've no idea. > > Personally, I'd still like to see less of them but without significantly > impacting the usefulness of automated built tooks like Simtec's > kautobuild. Might be neat if kbuild could wget config files automatically from a known location. Bonus points if it properly detected the right one to grab in the first place... -- Jesse Barnes, Intel Open Source Technology Center -- 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 changes for v2.6.39 merge window
On Thu, 31 Mar 2011, Nicolas Pitre wrote: > On Thu, 31 Mar 2011, da...@lang.hm wrote: > > > I think that part of the issue is that when Linus points out a problem, the > > response isn't "we agree and are working on it, here's what we are doing", > > instead it seems to be mostly "there is no problem, this is just because > > there > > is so much variation in ARM" > > If prominent people looking at this from the side line continue bashing > at those who are both feet in the mud trying to contain the flood rather > than actually helping then nothing will change. Instead this only > creates despair and the splashed people may simply decide to throw in > the towel, at which point things will collapse for real. In reality, > the system has been going as it is for quite a while and with more or > less the same level of intensity. And the fact is that _users_ of the > ARM kernel are not complaining. Things are far from being perfect, but > so far things have been "good enough" for the majority of the people > involved, and improvements are constantly being worked on with the men > power available. And that's the whole point why I was ranting in the first place. I know that there are clever folks working on the solution, but it's entirely clear to me, that they are simply not enough compared to the massive inbound flood. So neither you nor Russell can cope with it, you simply do not scale. That's why I suggested that the ARM community needs to push competent man power into this. You say the concept of subarch maintainers is working quite well. That depends on the definition of working. It works in terms of users can use it, but it does not work from a maintainability POV. Nobody wants to bash on those who are working on it, but IMNSHO the current way is running into an utter nightmare even w/o you and Russell throwing in the towel. I went through quite a few iterations of large scale cleanups, so I know how you feel. Thanks, tglx -- 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 changes for v2.6.39 merge window
On Thu, 31 Mar 2011, Nicolas Pitre wrote: > On Thu, 31 Mar 2011, Thomas Gleixner wrote: > > > Start off with such a trivial, but immense effective cleanup and see > > what it helps to share code even accross SoC vendors. They all glue > > together random IP blocks from the market and there are not soo many > > sources which are relevant. This makes sense in all aspects: > > > > 1) less and better code > > 2) faster setup for new SoCs > > 3) shared benefit for all vendors > > If this was always true. Someone commented on the fact that the IP > block providing USB on OMAP is shared with a couple other platforms. > But about 2600 lines of pure glue is still necessary around the common > driver to make it work for everyone. I'm not saying that separate > drivers are called for here, simply that hardware people _will_ screw it > up, especially when they are hooking it up to a non-standard > SOC-specific bus. Right. That's a problem, but we should not ignore the places where reusing stuff is easy possible. And making good examples out of it. And it really _IS_ worth the trouble. Look at the git log of drivers/spi/pxa2xx* . We could have slapped the other "x86" driver into spi, but that does not make any sense from a software engineering and maintainability POV. And it would have been more work in the end to cleanup the separate driver than isolating the existing one and reuse it. This is a sustainability issue. And we need to become more clever about identifying the places where we can abstract stuff into shared drivers and infrastructure when we want to sustain Linux for another few decades. > And what would the hardware guys tell you? That software is cheap. If you can prove with simple examples that using existing software removes 6 month of useless reinventing the wheel and another 6 month of testing plus the fight with the kernel folks, then eventually they start to listen as you can express this in $$$. Thanks, tglx -- 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 changes for v2.6.39 merge window
On Thu, Mar 31, 2011 at 10:56 AM, Nicolas Pitre wrote: > > So... Is there missed opportunity for better code reuse here? Most > probably. Is all that code the result of misabstracted and duplicated > code? Certainly not. Let's just presume that half of that code is > genuine crap and the other half is simply the result of new hardware for > which there is no existing model to fit it in. Even then, do we have 5 > times the reviewer bandwidth to properly review all that code compared > to X86? Absolutely not, not even close. That's an odd assumption. And it's followed by a total red herring that doesn't even make any sense. And then your conclusion seems to be that ARM could never have the same quality anyway, because of the whole lack of review issue is fundamental. And from there you seem to go on to think that there are no major problems, and things are "good enough"! > If prominent people looking at this from the side line continue bashing > at those who are both feet in the mud trying to contain the flood rather > than actually helping then nothing will change. The reason nothing seems to be changing is that you don't seem to think it's even WORTH fixing. I really don't understand your arguments. They seem to boil down to the same thing that always happens in the embedded world, and why most of the hardware and software is crap: people don't think further than their own small project. It's why embedded OS's have always been crap, and it's why Linux is becomign so important to ARM - exactly because the embedded world (both software and hardware) always just look at their own issue, and say "hey, this is working for me right now, so I won't bother to try to solve the bigger issues, because it's not worth my time". To hammer that in: > ... And the fact is that _users_ of the > ARM kernel are not complaining. Things are far from being perfect, but > so far things have been "good enough" for the majority of the people > involved, and improvements are constantly being worked on with the men > power available. You really don't seem to care about how Thomas was complaining about the whole maintenance issue. As he was trying to clean up irq handling, the pure flow of more crap just made it hard to ever catch up. THAT is the kind of maintenance problem where I go "This is a big problem". But for some individual board user or the code-monkey who creates yet another board description, this isn't a problem. Because he's looking at a single kernel and a single board at a time, and seldom cares about anything else. But guess what? That really _is_ a problem. And it's likely to be a bigger problem in the future. Look at how we're actually starting to see vendors who are making ARM into more of a real platform, rather than a succession of one-off embedded boards, and think about what that actually will entail. I'm talking about things like ASUS getting their feet wet making netbooks with ARM. Things like that have been promised for the last several years now, and so far it's been a total failure. And it's going to CONTINUE to be a failure, unless the ARM platform mess can be sorted out. Why? Think of the Ubuntu's etc of the world. If you can't make half-way generic install images, you can't have a reasonably generic distribution. And if you don't have that, then what happens to your developer situation? Most sane people won't touch it with a ten-foot pole, because the bother is simply not worth their time. So the current embedded mindset of "hey, it's working for all these individual people" is just broken. It's broken for multiple reasons. It's broken because it makes it much harder to do top-level maintenance (but the low-level guys don't care), and it's broken because it results in insane fragmentation where it basically is never an option to support anything but one - or a couple - particular device. The ARM -core- situation is simple, and those high-level people can (and do) say that they'll just support ARM7 and screw all the other cores. But the platform problem is real. And it does need some solution, because continuing to just do the same thing really does mean that some new things simply cannot be done. And the fact that it's been "good enough" in the past when every single board was always just a one-off and had nothing to do with other boards does _not_ mean that it's going to continue to be good enough. So the _good_ news is that all the high-end ARM's are largely consolidating anyway, and when we're talking Cortex-A9 class hardware, there generally aren't millions of SoC's. And I'm hoping the hardware people are actually aware of this (presumably because their customers are starting to push back against pointless hw churn too) and clearly some manufacturers are trying to -create- platforms like OMAP that try to have lots of shared characteristics (and then screw up a lot of the details, but whatever). But I still do think that on the software side, people need to stop doing th
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, 31 Mar 2011, Linus Torvalds wrote: > What I'm _not_ seeing is a lot of cross-platform maintenance or sense > of people trying to reign things in and look for solutions to the > proliferation of random stupid and mindless platform code. I do that, Russell does that, Catalin does that, Tony does that, and maybe less than a handful of other important people I'm not listing (sorry). But clearly we are far far from being enough people doing that kind of work. And the fact is that the volume of ARM platform code is steadily being produced at a rate far surpassing X86, and even higher than all the other architectures put together. Linaro is trying to help here, but Linaro cannot conjure the needed experience and knowledge for that kind of work with a magic wand. So we need help! If core kernel people could get off their X86 stool and get down in the ARM mud to help sort out this mess that would be really nice (thanks tglx). Until then all that the few of us can do is to contain the flood and hope for the best, and so far things being as they are have still worked surprisingly well in practice for users. If compensation is a concern then I think Linaro might be able to arrange something. And we can't count on vendor people doing this work. They are all busy porting the kernel to their next SOC version so they can win the next big Android hardware design, and doing so with our kernel quality standards is already quite a struggle for them. What is going on at the moment is some effort to introduce DT support to ARM. The core support is there, but that is useless until platform code is moved to it, and corresponding work is put into bootloaders, etc. That is progressing... slowly. Also there is some work to be able to build a kernel supporting more than one SOC family at once. Of course there is no practical use for a single kernel binary that boots on all existing boards, but moving towards such a goal has beneficial side effects such as good consolidation when possible. But we also need some slack wrt number of lines changed. An increased consolidation effort will create more churn not less, at least for a while. The OMAP clock merge conflict was the result of some cleanup which will make further consolidation easier. Nicolas -- 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 changes for v2.6.39 merge window
On Thu, Mar 31, 2011 at 12:25 PM, Nicolas Pitre wrote: > > So we need help! If core kernel people could get off their X86 stool > and get down in the ARM mud to help sort out this mess that would be > really nice (thanks tglx). Until then all that the few of us can do is > to contain the flood and hope for the best, and so far things being as > they are have still worked surprisingly well in practice for users. If > compensation is a concern then I think Linaro might be able to arrange > something. The thing is, maintainers don't scale. The only way to get quality code is to try to improve the quality from the "leaf nodes", because otherwise you'll always end up playing catch-up. You'll get new bad code faster than you can clean it up. I've told people this before, and I'll tell it again: when I flame submaintainers, they should try to push the pain down. I'm not really asking those submaintainers to clean up all the stuff they are getting: I'm basically asking people to say "no", or at least push back a lot, and argue with the people who send you code. Tell them what you don't like about the code, and tell them that you can't take it any more. > And we can't count on vendor people doing this work. They are all busy > porting the kernel to their next SOC version so they can win the next > big Android hardware design, and doing so with our kernel quality > standards is already quite a struggle for them. This really isn't the argument. The argument should be that if they want their code up-stream, they need to do a good job. If they don't, why should you take it at all? > What is going on at the moment is some effort to introduce DT support to > ARM. The core support is there, but that is useless until platform code > is moved to it, and corresponding work is put into bootloaders, etc. > That is progressing... slowly. How about not moving platform code TO it, but at least saying that you won't accept new platform code that doesn't use it? When somebody sends you a new platform, just say "no" if it's another copy-paste job or another "add yet another #ifdef or conditional to a messy driver". > But we also need some slack wrt number of lines changed. An increased > consolidation effort will create more churn not less, at least for a > while. The OMAP clock merge conflict was the result of some cleanup > which will make further consolidation easier. Umm. The whole "number of lines of code" thing has become a total red herring. THAT IS NOT WHY I STARTED TO COMPLAIN! The reason I point out the number of lines of code is because it's one of the more obvious _symptoms_ of the problem. But trust me, if you start doing a better job at platform code, I won't be complaining when I get lots of deleted code, or when I start getting devicetree descriptions instead of new drivers. So "number of lines of code" and "massive churn" is a problem, but look at how I'm not complaining about the drivers/ subdirectory, which is still the bulk of all lines in the kernel by far. I may complain about particular subsystems in drivers (gpu..) for other reasons, but it's not "lines of code" per se. In the case of ARM, the reason I point out the size of the arch/arm is because it's illustrative of just how _different_ ARM is from the other architectures. And those differences are pretty much all about the board/platform issues. Linus -- 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: Question regarding suspend/resume
On 03/15/2011 04:11 PM, Kevin Hilman wrote:
> Peter Barada writes:
>
>> Is there any reference how to decode the output of
>> /debug/pm_debug/count? I'm trying to figure out when I resume why it
>> says the core_pwrdm didn't enter the target state, and I'm assuming
>> because a clock used is not disabled in the suspend path, but as fars
>> as I can tell there's no output in the pm_debug code that tells which
>> clocks in a power domain are active at the time of a suspend.
> You're right.
>
> What you need the patch in my pm-wip/debug branch from my pm tree[1].
> With that patch, it takes a snapshot of the PRCM registers just before
> and after suspend.
>
> When you come back from suspend, view the register snapshot just before
> suspend:
>
> # cat /debug/pm_debug/register/1
>
> and the register snapshot just after
>
> # cat /debug/pm_debug/register/2
>
> the snapshot just before suspend is useful for debugging problems like
> yours, and the snapshot just after can be useful for debugging wakeups.
>
> Feel free to post the register dump if you want some help deciphering
> it. If you do, please post more details on what kernel you're using as
> well as the bootloader etc.
Kevin,
Thanks for helping me to understand things.
The kernel I'm using is TI's OMAPPSP_03.00.01.06 2.6.32 kernel [1] with their
u-boot [2] and x-loader[3], modified to run on Logic's DM3730 board(s) (as we
use the Micron mt29c4g48mazapakq-5 POP). I've added to this kernel a stripped
board file (stripped from board-omap3evm.c) that supplies enough to bring up
the mmc and serial ports - platform code registers other devices. Its built
with omap3_evm_defconfig with the addition of my MACH_DM3730_SOM_LV/TORPEDO
machine description (which causes my board-dm3730logic.c minimal board file to
be compiled in):
/*
* linux/arch/arm/mach-omap2/board-dm3730logic.c
*
* Copyright (C) 2011 Logic Product Development
*
* Modified from mach-omap2/board-omap3evm.c
*
* Initial code: Syed Mohammed Khasim
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include "mux.h"
#include "sdram-micron-mt29c4g48mazapakq-5.h"
#include "mmc-twl4030.h"
#include "pm.h"
#include "prm-regbits-34xx.h"
#include "omap3-opp.h"
static struct twl4030_hsmmc_info mmc[] = {
{
.mmc= 1,
.wires= 4,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
},
{}/* Terminator */
};
static struct regulator_consumer_supply dm3730logic_vmmc1_supply = {
.supply= "vmmc",
};
static int dm3730logic_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
twl4030_mmc_init(mmc);
/* link regulator to MMC adapter */
dm3730logic_vmmc1_supply.dev = mmc[0].dev;
return 0;
}
static struct twl4030_gpio_platform_data dm3730logic_gpio_data = {
.gpio_base= OMAP_MAX_GPIO_LINES,
.irq_base= TWL4030_GPIO_IRQ_BASE,
.irq_end= TWL4030_GPIO_IRQ_END,
.use_leds= true,
.setup= dm3730logic_twl_gpio_setup,
};
/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
static struct regulator_init_data dm3730logic_vmmc1 = {
.constraints = {
.min_uV= 185,
.max_uV= 315,
.valid_modes_mask= REGULATOR_MODE_NORMAL
| REGULATOR_MODE_STANDBY,
.valid_ops_mask= REGULATOR_CHANGE_VOLTAGE
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies= 1,
.consumer_supplies= &dm3730logic_vmmc1_supply,
};
static struct twl4030_platform_data dm3730logic_twldata = {
.irq_base= TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
.gpio= &dm3730logic_gpio_data,
/* platform_data for children goes here */
.vmmc1= &dm3730logic_vmmc1,
};
static struct i2c_board_info __initdata dm3730logic_i2c_boardinfo[] = {
{
I2C_BOARD_INFO("twl4030", 0x48),
.flags = I2C_CLIENT_WAKE,
.irq = INT_34XX_SYS_NIRQ,
.platform_data = &dm3730logic_twldata,
},
};
static int __init dm3730logic_i2c_init(void)
{
omap_register_i2c_bus(1, 2600, dm3730logic_i2c_boardinfo,
ARRAY_SIZE(dm3730logic_i2c_boardinfo));
return 0;
}
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#endif
static struct omap_board_config_kernel dm3730logic_config[] __initdata = {
};
static struct omap_opp * _omap37x_mpu_rate_table= omap37x_mpu_rate_table;
static struct omap_opp * _omap37x_dsp_rate_table= omap37x_ds
Re: [GIT PULL] omap changes for v2.6.39 merge window
Arnd Bergmann writes: > On Thursday 31 March 2011, Kevin Hilman wrote: >> Some SoCs families (like OMAP) have huge amount of diversity even within >> the SoC family, so better abstractions and generic infrastrucure >> improvements are an obvious win, even staying within the SoC. > > But that's the point. The incentive is there for managing the infrastructure > within the SoC, but not across SoCs. OK, but the rest of my thread went on to describe how at least a few ARM SoC maintainers are actually actively working infrastructure that is cross SoC, like runtime PM. It might start because of an abstraction within an SoC family like supporting both SH and SH-mobile, or OMAP[12345], but it does sometimes result in not only cross-SoC code but cross-platform frameworks. Admiteddly, the percentage of ARM SoC developers actively working on these common, cross-platform infrastructure layers is rather small, but at least it is non-zero. :) > Allow me to use OMAP as a bad example while pointing out that it's > really one of the best supported platforms we currently have, while > the others are usually much worse in terms of working with the > community (or at least they are behind on the learning curve but > getting there): > > * OMAP2 introduced the hwmod concept as an attempt to reduce duplication > between board code, but the code was done on the mach-omap2 level > instead of finding a way to make it work across SOC vendors, or using > an existing solution. Well, before deciding whether something like hwmod should be a cross-SoC abstraction, it's important to be clear about what level of abstraction is needed, or practical for a given feature. For power management, we already have (and use) existing abstractions for the drivers. The clock framework, system PM and runtime PM framework are all existing abstraction layers for drivers. Remember that power management is one of those areas that ARM SoC vendors like to "differentiate" on, so the hardware is vastly different between ARM vendors. Having worked on embedded Linux power management for a while now, I currently do not think any cross-SoC abstractions below the clock framework or runtime PM are worth it. I'm certainly willing to be pursuaded otherwise, but currently don't see the usefulness. With that as background, hwmod was never inteded as something to be cross-SoC. If you look at the data that's in an omap_hwmod, it's entirely OMAP hardware specific, and mostly focused on power management hardware details, register descriptions, feature capabilities etc. This allows the OMAP PM core code to be generalized and work across all SoCs in the OMAP family. But again, it was intended for OMAP PM core code. At that level, there really isn't much to share with other SoCs since the PM hardware for the various SoC vendors is so "differentiated" (a.k.a fsck'd up in extremely different ways.) 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: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, Mar 31, 2011 at 1:05 PM, Linus Torvalds wrote: > > Umm. The whole "number of lines of code" thing has become a total red herring. > > THAT IS NOT WHY I STARTED TO COMPLAIN! > > The reason I point out the number of lines of code is because it's one > of the more obvious _symptoms_ of the problem. > > But trust me, if you start doing a better job at platform code, I > won't be complaining when I get lots of deleted code, or when I start > getting devicetree descriptions instead of new drivers. So if you don't like lines of code, how about just "number of files touched". This is Thomas this merge window. Remember: he's traditionally doing timers and interrupts and stuff. Do: git log --author=tglx v2.6.38.. --oneline --numstat | cut -f3- | grep -v ' ' | cut -d/ -f1-2 | sort | uniq -c | sort -n | tail and see another example of arm standing out (ok, so "kernel/irq" also stands out in this case, but you'd kind of _expect_ that, when the whole series is about irq controllers, wouldn't you?) And no, mips doesn't look so hot either. Anyway, the point is, there are many ways to show the whole "arm is a maintenance problem" issue. Don't get too hung up about number of lines changed. It's just the simplest kind of thing where the tools give answers very quickly without the above kinds of games. Btw, the reason why the subject line on this rant is what it is, is that during this merge window, arm was also one of the more annoying to merge. And NO, that does NOT mean that I want you guys to merge things behind my back just to hide the problem. I'm just saying that it's another facet of this whole issue. Not that I can't do merges, but that ARM simply ends up having these issues that others don't. Linus -- 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: Question regarding suspend/resume
Hi Peter, Peter Barada writes: [...] > Thanks for helping me to understand things. > > The kernel I'm using is TI's OMAPPSP_03.00.01.06 2.6.32 kernel [1] > with their u-boot [2] and x-loader[3], modified to run on Logic's > DM3730 board(s) (as we use the Micron mt29c4g48mazapakq-5 POP). I'm afraid somone who supports that older TI kernel will have to help you out. If you can reproduce on a current kernel, I'd be glad to help but I'm currently not able (well, not willing is more accurate) to try and figure out what's going on based on an older kernel with who knows how many out-of-tree patches/hacks piled on. What I can say based on the register dump you shared is that there is no obvious driver issue going on where a clock was left on by a driver. More than likely what is going on is that the booloader is using a device (e.g. USB, MMC) but is leaving it in a state such that that IP block cannot idle, so the CORE powerdomain then does not fully idle. In older kernels like this one, the linux drivers did not fully reset the hardware so bootloaders could cause problems like this (the u-boot on beagle has had several problems like this.) As a first whack at things, I would focus on USB OTG and MMC, as I've seen problem with both on other platforms, like Beagle. You need to ensure that both the these modules are fully reset either by the bootloader when it's done using them, or by the kernel in the early boot process. Current kernels now do the latter. Sorry I can't be of more help, 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 05/10] omap2+: Use dmtimer macros for clockevent
Tony Lindgren writes:
> This patch makes timer-gp.c to use only a subset of dmtimer
> functions without the need to initialize dmtimer code early.
>
> Note that omap_dmtimer_init_one can eventually be moved to
> omap2+ specific dmtimer.c.
>
> Also note that now with the inline functions, timer_set_next_event
> becomes more efficient in the lines of assembly code.
>
> Signed-off-by: Tony Lindgren
In looking closer at this patch, I have a few questions.
[...]
> @@ -75,7 +97,8 @@ static struct irqaction omap2_gp_timer_irq = {
> static int omap2_gp_timer_set_next_event(unsigned long cycles,
>struct clock_event_device *evt)
> {
> - omap_dm_timer_set_load_start(gptimer, 0, 0x - cycles);
> + __omap_dm_timer_load_start(clkev.io_base, OMAP_TIMER_CTRL_ST,
> + 0x - cycles, 1);
>
> return 0;
The creation of macros is causing some readability concern, at least for
me...
In creating the macro versions of some of the functions, the macro
version actually has different behavior which makes reading the code a
little confusing.
I just noticed that the macro version of _load_start() doesn't actually
do the "start", so you added the OMAP_TIMER_CTRL_ST when calling it.
To do this, the macro version takes a 'ctrl' argument where as the
"real" version only takes the autoreload argument.
If you're going to keep the same function name (but just add the __
prefix, I would expect that the functionality of the function doesn't
change.
If the functionality of the macro is different from the "real" function,
it should probably just be given a different name. In this case,
probably dropping the _start suffix is probably enough.
> }
> @@ -85,13 +108,13 @@ static void omap2_gp_timer_set_mode(enum
> clock_event_mode mode,
> {
> u32 period;
>
> - omap_dm_timer_stop(gptimer);
> + omap_dm_timer_stop(&clkev);
>
> switch (mode) {
> case CLOCK_EVT_MODE_PERIODIC:
> - period = clk_get_rate(omap_dm_timer_get_fclk(gptimer)) / HZ;
> + period = clkev.rate / HZ;
> period -= 1;
> - omap_dm_timer_set_load_start(gptimer, 1, 0x - period);
> + omap_dm_timer_set_load_start(&clkev, 1, 0x - period);
Hmm, you're using the driver function here not the macro. Is that
intended?
Why not use the macro version here with OMAP_TIMER_CTRL_AR |
OMAP_TIMER_CTRL_ST.
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: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, 31 Mar 2011, Nicolas Pitre wrote: > On Thu, 31 Mar 2011, Linus Torvalds wrote: > > What I'm _not_ seeing is a lot of cross-platform maintenance or sense > > of people trying to reign things in and look for solutions to the > > proliferation of random stupid and mindless platform code. > > I do that, Russell does that, Catalin does that, Tony does that, and > maybe less than a handful of other important people I'm not listing > (sorry). But clearly we are far far from being enough people doing that > kind of work. And the fact is that the volume of ARM platform code is > steadily being produced at a rate far surpassing X86, and even higher > than all the other architectures put together. Linaro is trying to help > here, but Linaro cannot conjure the needed experience and knowledge for > that kind of work with a magic wand. > > So we need help! If core kernel people could get off their X86 stool > and get down in the ARM mud to help sort out this mess that would be > really nice (thanks tglx). Until then all that the few of us can do is The main help we can give (aside of actually looking at code and concepts) is to feed back the experience we have with massive cleanups and which mechanisms work and which not and - at least I can speak for myself - to stand at your side when it comes to pushing that through. One thing what really helps to force people to get their act together is that you as maintainers identify trouble spots which are easily addressable. Then put those spots on your list and require people who want to submit new features in that area to cleanup the mess first and then put their new feature thing on top. We successfully used this to get the unification work after the mechanical i386/x86_64 merger done. It requires a lot of stubborness, but it reduces the work burden of the maintainers a lot. Once you have the easy spots addressed, that could be device tree stuff, gpio, irq_chips for the beginning and see how it works out, then go steps further. The important point here is from my POV that you put down the requirements with no wiggle room and just ignore the "oh it could be done better" whining. Either people come up with a patch which solves the whole issue better or they just will cope. But when you have consolidated stuff then you can and need to look from a high level perspective and refine the infrastructure. I really regret in hindsight, that I did not enforce the cleanup of the irq layer way earlier and that I did not see the abuse of it early enough. At some point I realized that being polite is the wrong solution, so I forced myself to push this cleanup through. That's an experience which I don't wish anybody else to make. Especially because as long as the oldstyle stuff works oldstyle crap comes in faster than you can fix it. See commit 9ad198c. And it's a massive effort to do something which results in: Total patches: 414 Total files touched: 702 Total insertions: 6805 Total deletions: 8632 Lines added -1827 And that massive effort is just because you cannot break stuff after the fact in a massive scale. The whole thing introduced a mere 6 patches fixup fallout which were applied one day after rc1. It could have been avoided, but So yes, we can and will help with advise, a certain amount of review (especially on the concept level) and giving you all the support you need to fight that trough. Thanks, tglx -- 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 05/10] omap2+: Use dmtimer macros for clockevent
* Kevin Hilman [110331 14:32]:
> Tony Lindgren writes:
>
> > This patch makes timer-gp.c to use only a subset of dmtimer
> > functions without the need to initialize dmtimer code early.
> >
> > Note that omap_dmtimer_init_one can eventually be moved to
> > omap2+ specific dmtimer.c.
> >
> > Also note that now with the inline functions, timer_set_next_event
> > becomes more efficient in the lines of assembly code.
> >
> > Signed-off-by: Tony Lindgren
>
> In looking closer at this patch, I have a few questions.
>
> [...]
>
> > @@ -75,7 +97,8 @@ static struct irqaction omap2_gp_timer_irq = {
> > static int omap2_gp_timer_set_next_event(unsigned long cycles,
> > struct clock_event_device *evt)
> > {
> > - omap_dm_timer_set_load_start(gptimer, 0, 0x - cycles);
> > + __omap_dm_timer_load_start(clkev.io_base, OMAP_TIMER_CTRL_ST,
> > + 0x - cycles, 1);
> >
> > return 0;
>
> The creation of macros is causing some readability concern, at least for
> me...
>
> In creating the macro versions of some of the functions, the macro
> version actually has different behavior which makes reading the code a
> little confusing.
>
> I just noticed that the macro version of _load_start() doesn't actually
> do the "start", so you added the OMAP_TIMER_CTRL_ST when calling it.
> To do this, the macro version takes a 'ctrl' argument where as the
> "real" version only takes the autoreload argument.
>
> If you're going to keep the same function name (but just add the __
> prefix, I would expect that the functionality of the function doesn't
> change.
>
> If the functionality of the macro is different from the "real" function,
> it should probably just be given a different name. In this case,
> probably dropping the _start suffix is probably enough.
OK good point.
> > }
> > @@ -85,13 +108,13 @@ static void omap2_gp_timer_set_mode(enum
> > clock_event_mode mode,
> > {
> > u32 period;
> >
> > - omap_dm_timer_stop(gptimer);
> > + omap_dm_timer_stop(&clkev);
> >
> > switch (mode) {
> > case CLOCK_EVT_MODE_PERIODIC:
> > - period = clk_get_rate(omap_dm_timer_get_fclk(gptimer)) / HZ;
> > + period = clkev.rate / HZ;
> > period -= 1;
> > - omap_dm_timer_set_load_start(gptimer, 1, 0x - period);
> > + omap_dm_timer_set_load_start(&clkev, 1, 0x - period);
>
> Hmm, you're using the driver function here not the macro. Is that
> intended?
>
> Why not use the macro version here with OMAP_TIMER_CTRL_AR |
> OMAP_TIMER_CTRL_ST.
Hmm I guess I tried to change as little as possible here when I noticed
that there's some weirdness with the autoreload mode in the original
omap_dm_timer_set_load_start function that requires writing twice in
the autoreload case. Looks like that's not needed for the one-shot case.
Anyways, you're right, this should not be using the driver function to move
the rest of the timers to be under drivers/ eventually. Will post an
updated version after taking another look at the dmtimer hwmod series.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] OMAP: l3: fixes and cleanup
On Wed, Mar 30, 2011 at 1:45 AM, Santosh Shilimkar wrote: >> OMAP3: l3: fix for "irq 10: nobody cared" message >> OMAP3: l3: fix omap3_l3_probe error path >> OMAP3: l3: minor cleanup for error message, parenthesis and extra >> lines >> OMAP4: l3: fix omap4_l3_probe error path >> OMAP4: l3: minor cleanup for parenthesis and extra spaces >> > Thanks for the cleanup. I have reviewed the series and it looks > good to me. > I would suggest to fold similar changes like, > - PATCH 2/5 and PATCH 4/5 into one patch > - PATCH 3/5 and PATCH 5/5 into one patch > > With this update you can add my ack for this series Ok, will do, thanks for the comments. Regards, Omar -- 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/10] omap2+: Remove gptimer_wakekup for now
Tony Lindgren writes:
> This removes the support for setting the wake-up timer for debugging.
>
> Later on we can reserve gptimer1 for PM code only and have similar
> functionality.
>
> Signed-off-by: Tony Lindgren
While we work on an alternative, rather than completely remove this
functionality, below is a very small patch (replaces $SUBJECT patch)
that will keep the current wakeup-from-suspend timer for PM debug
working.
Note that GPT1 fs not just used for wakeups from suspend. GPT1 needs to
also be the clockevent (at least during idle) so that next-timer
interrupts during idle are also programmed for GPT1.
Here is what I see as a possible "real" solution. Let's see if we're on
the same page.
- GPT1 reserved for "special" PM wakeup
- GPT2 used as high-resolution clockevent (using sys_clk, but stops during idle)
- GPT3 (or counter_32k) used as clocksource depending on Kconfig
Whenever we're going idle (or suspend), we have to effectively switch
the clockevent from GPT2 to GPT1. I assume this is what you have in
mind as well.
We'll need to dig into the clockevent (and tick broadcast) code to get
this to work on UP. On SMP, the C3STOP flag is used to signify that at
clockevent will stop during specific power states, so an alternate
clockevent is used, but IIUC, this doesn't currently work the same on
UP. I think Santosh has looked into this more recently than I have.
Santosh, if you have any recent status on this, could you share? I'll
gladly work on the clockevent layer if necessary for this.
Tony, in the mean time, can you use something like the patch below
instead of $SUBJECT patch? At least we won't loose functionality while
working on this feature.
Kevin
>From e7affbb60e292b507ee1259b6a47f1e30b7fc071 Mon Sep 17 00:00:00 2001
From: Kevin Hilman
Date: Thu, 31 Mar 2011 14:49:27 -0700
Subject: [PATCH] OMAP2+: PM debug: update suspend wakeup timer for DM timer
changes
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/pm-debug.c |4 ++--
arch/arm/mach-omap2/timer-gp.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index a5a83b3..eccf117 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -171,8 +171,8 @@ void omap2_pm_wakeup_on_timer(u32 seconds, u32 milliseconds)
tick_rate = clk_get_rate(omap_dm_timer_get_fclk(gptimer_wakeup));
cycles = tick_rate * seconds + tick_rate * milliseconds / 1000;
- omap_dm_timer_stop(gptimer_wakeup);
- omap_dm_timer_set_load_start(gptimer_wakeup, 0, 0x - cycles);
+ __omap_dm_timer_load_start(gptimer_wakeup->io_base, OMAP_TIMER_CTRL_ST,
+ 0x - cycles, 1);
pr_info("PM: Resume timer in %u.%03u secs"
" (%d ticks at %d ticks/sec.)\n",
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
index c21e99f..52100b2 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -76,7 +76,7 @@ static struct omap_dm_timer *gptimer;
static struct clock_event_device clockevent_gpt;
static u8 __initdata gptimer_id = 1;
static u8 __initdata inited;
-struct omap_dm_timer *gptimer_wakeup;
+struct omap_dm_timer *gptimer_wakeup = &clkev;
static irqreturn_t omap2_gp_timer_interrupt(int irq, void *dev_id)
{
--
1.7.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: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, 31 Mar 2011, Linus Torvalds wrote: > On Thu, Mar 31, 2011 at 12:25 PM, Nicolas Pitre wrote: > > > > So we need help! If core kernel people could get off their X86 stool > > and get down in the ARM mud to help sort out this mess that would be > > really nice (thanks tglx). Until then all that the few of us can do is > > to contain the flood and hope for the best, and so far things being as > > they are have still worked surprisingly well in practice for users. If > > compensation is a concern then I think Linaro might be able to arrange > > something. > > The thing is, maintainers don't scale. True. My remark about core kernel people still stands though. > The only way to get quality code is to try to improve the quality from > the "leaf nodes", because otherwise you'll always end up playing > catch-up. You'll get new bad code faster than you can clean it up. Leaf nodes on ARM are people coming from corporate background with the old school software development methodologies. They do it as a _job_ first and foremost. They only work on Linux because that's what their boss assigned them to. Don't get me wrong: that doesn't mean they are bad people. Simply that they are not into it for the public recognition (or flaming) from their peers. Once their code works they lose interest and move on. That mindset is extremely hard to change and take time, on a scale of years. Much more time than required to produce the code needed to support that new SOC out of the pipeline. There are notable exceptions obviously. But this is still a scalability problem in itself. So we need men-in-the-middle attacks. > I've told people this before, and I'll tell it again: when I flame > submaintainers, they should try to push the pain down. I'm not really > asking those submaintainers to clean up all the stuff they are > getting: I'm basically asking people to say "no", or at least push > back a lot, and argue with the people who send you code. Tell them > what you don't like about the code, and tell them that you can't take > it any more. I wish we could be sufficient people to be able to determine what we actually don't like about the code. There is simply not enough core kernel people with the required visibility doing such work in ARM land. That's the fundamental problem. The fact that the most successful "real" ARM devices running Linux out there still aren't supported in mainline doesn't help building a community of enthusiasts around it either. > > And we can't count on vendor people doing this work. They are all busy > > porting the kernel to their next SOC version so they can win the next > > big Android hardware design, and doing so with our kernel quality > > standards is already quite a struggle for them. > > This really isn't the argument. The argument should be that if they > want their code up-stream, they need to do a good job. If they don't, > why should you take it at all? Embedded vendors did keep their code out of the kernel before. We've been hammering them about upstreaming their code for years. Now they are striking back with too much code for our review capacity. So problematic code gets merged without anyone noticing because it compiles and does work, until someone comes along with a wide scale API cleanup and stumble on it. The alternative is to only accept fully reviewed code, but to scale with the numbers we've all seen, 60% of the reviewers should be looking at ARM code and that's not happening. We've been there before, like two years ago or so. Pressure builds up at the maintainer gate as the backlog grows and key people get burned out, then the system collapses. No one wants to go back there. > > What is going on at the moment is some effort to introduce DT support to > > ARM. The core support is there, but that is useless until platform code > > is moved to it, and corresponding work is put into bootloaders, etc. > > That is progressing... slowly. > > How about not moving platform code TO it, but at least saying that you > won't accept new platform code that doesn't use it? When somebody > sends you a new platform, just say "no" if it's another copy-paste job > or another "add yet another #ifdef or conditional to a messy driver". DT has to prove itself on ARM with a few existing platforms before we can open the flood gate towards it. If something is wrong with DT support it is best to fix only the core stuff without also having to fix all users and possibly all bootloaders, etc. That work is progressing slowly because there are more people praising DT than people doing the actual work. Nicolas
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, Mar 31, 2011 at 06:49:11PM -0400, Nicolas Pitre wrote: > On Thu, 31 Mar 2011, Linus Torvalds wrote: > > The only way to get quality code is to try to improve the quality from > > the "leaf nodes", because otherwise you'll always end up playing > > catch-up. You'll get new bad code faster than you can clean it up. > > Leaf nodes on ARM are people coming from corporate background with the > old school software development methodologies. They do it as a _job_ > first and foremost. They only work on Linux because that's what their > boss assigned them to. Don't get me wrong: that doesn't mean they are > bad people. Simply that they are not into it for the public recognition > (or flaming) from their peers. Once their code works they lose interest > and move on. That mindset is extremely hard to change and take time, on > a scale of years. Much more time than required to produce the code > needed to support that new SOC out of the pipeline. There are notable > exceptions obviously. But this is still a scalability problem in > itself. So we need men-in-the-middle attacks. It's also often the case that the leaf maintainers are themselves overloaded with work, especially those who don't have much code in tree already or who have advanced power management features in their devices that they're trying to support (which tend to be the area that requires most work as they're system wide in impact). > > This really isn't the argument. The argument should be that if they > > want their code up-stream, they need to do a good job. If they don't, > > why should you take it at all? > Embedded vendors did keep their code out of the kernel before. We've > been hammering them about upstreaming their code for years. Now they > are striking back with too much code for our review capacity. So > problematic code gets merged without anyone noticing because it compiles > and does work, until someone comes along with a wide scale API cleanup > and stumble on it. Plus the fact that even if the code isn't of the quality we'd ideally like you do tend to get *some* quality improvement from pushing things into mainline simply by virtue of 1000 foot review and it's much more likely that random people will come along and contribute improvements to mainline than to vendor BSPs. Speaking as someone who works over many different embedded CPUs (not just ARM) I'm generally thankful when I'm working with mainline code, even if it's not the mainline code I might dream of. There are some great out of tree BSPs but there's also others. -- 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 changes for v2.6.39 merge window
On Wed, Mar 30, 2011 at 03:14:10PM -0700, Tony Lindgren wrote: > * Russell King - ARM Linux [110330 14:05]: > > And I have got to the point of just not giving a damn. I can't change > > the ARM community (I've tried over the years to get more active review > > of platform changes and failed - and had it pointed out by folk like > > Alan Cox, that such a system is impossible due to lack of motivation > > by, eg, an OMAP person to review a Samsung change.) > I think this is happening more and more as we have more ARM generic > and Linux generic code. Plus you've now got some non-trivial code for off-SoC devices which means you've got a growing number of people who do actively work over many SoCs. -- 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 changes for v2.6.39 merge window
On Thu, Mar 31, 2011 at 12:56:33AM +0200, Thomas Gleixner wrote: > On Wed, 30 Mar 2011, Tony Lindgren wrote: > > * Thomas Gleixner [110330 15:22]: > > > On Wed, 30 Mar 2011, Tony Lindgren wrote: > > > > One thing that will help here and distribute the load is to move > > > > more things under drivers/ as then we have more maintainers looking > > > > at the code. > > > Guess what's that going to solve? Nothing, nada. > > > Really, you move the problem to people who are not prepared to deal > > > with the wave either. So what's the gain? > > I guess my point is that with creating more common frameworks people > > will be using common code. Some examples that come to mind are clock > > framework, gpiolib, dma engine, runtime PM and so on. > For all that to happen you need a really experienced team with a > strong team lead to fight that through and go through the existing > horror while dealing with the incoming flood at the same time. My experience is that it's not that bad doing this providing you can convince people to actually show their code to the relevant subsystem maintainers and they have time to look at the code. The first step is reasonably tractable since it's a fairly basic level of review and as a subsystem maintainer you're well enough motivated to at least ensure that people aren't breaking the abstractions enough to cause problems for anyone but the people directly working with the drivers. -- 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 changes for v2.6.39 merge window
On Thu, Mar 31 2011, Nicolas Pitre wrote: > Leaf nodes on ARM are people coming from corporate background with the > old school software development methodologies. They do it as a _job_ > first and foremost. They only work on Linux because that's what their > boss assigned them to. Don't get me wrong: that doesn't mean they are > bad people. Simply that they are not into it for the public recognition > (or flaming) from their peers. Once their code works they lose interest > and move on. That mindset is extremely hard to change and take time, on > a scale of years. Much more time than required to produce the code > needed to support that new SOC out of the pipeline. There are notable > exceptions obviously. But this is still a scalability problem in > itself. So we need men-in-the-middle attacks. An additional mindset that is difficult to work with in this environment is that the corporate development methodology has a focus on schedules and deliverables. Even people who would otherwise like to contribute will have pressure to get something done. Many think of "submit to mainline" is kind of a last step in a development process, instead of even a goal to accomplish. When we push back, there is a good chance they just won't bother, not because they don't want to do it, but because it doesn't fit a schedule, and there is already something else for them to work on. So what's the right answer here. Practically, someone just sent out a fairly complete DMA driver for a new MSM device. Naturally, this hardware is nothing like anyone else's DMA, but the driver itself pretty much independent from other kernel APIs. It isn't even similar to the existing DMA driver in the MSM. With it are patches to ifdef-up various drivers to use the appropriate DMA. The DMA code, by itself, seems reasonably well written (with some cleanup and such needed), but it makes everything that uses it messy. In this particular case, DMA engine will probably need some work to either incorporate the unique capabilities of this hardware, or at least allow them to be used. The author probably won't be able to do this on their own. I could pull the driver into the tree, and now we have yet another driver with yet another API. If I push back, realistically, it will probably end up out-of-tree, along with everything that depends on it. Up until now, it seems that attitude has been that it is better to be in-tree than out of tree, but are we getting too much stuff to continue that? Today, most of the MSM code lives out of tree. The QuIC tree for MSM (currently based off of 2.6.35): git diff --stat v2.6.35..HEAD | tail -1 3432 files changed, 1144473 insertions(+), 17315 deletions(-) git diff --stat v2.6.35..HEAD arch/arm/mach-msm | tail -1 595 files changed, 286054 insertions(+), 1928 deletions(-) There's a large amount of work just to get the code up to kernel standards (the coding style has been fairly well enforced), and there is constant development for new hardware. Thanks, David Brown -- 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
[PATCH 0/5] regulator: twl: make 6030 regulators useable
TWL6030 regulator dynamic operations such as those on vaux2 and vaux3 were reported to be broken on platforms such as pandaboard(OMAP4). Digging deeper into the code, found that 6030 regulator support requires quiet a bit of fixes to make it useable. Major change w.r.t TWL4030 has been the introduction of CFG_STATE register in TWL6030 which is needed to be used for regulator control compared to messages which were used in TWL4030. This could have been the real root cause of the issue fixed in: commit 8b8e2ef328c3378c74fb4347f66df8e58feeaf46 Author: David Anders Date: Fri Mar 18 16:53:20 2011 -0700 OMAP4: PandaBoard: remove unused power regulators the pandaboard does not use the VUSIM or VAUX1 power regulators on the TWL6030 and are left floating. if the VUSIM and VAUX1 power regulators are initilized, noise on the unloaded regulators generates an overcurrent interrupt causing the system to power down. this patch removes the initialization of the unused power regulators of VUSIM and VAUX1. Normally just having the regulator resources in board file should'nt have caused them to have been enabled in the first place - they should have been enabled only when regulator_enable is invoked and disabled in regulator_disable. These unfortunately, are'nt working at the moment and the series fixes the same. This series also allows the regulator framework to actually be able to use the regulator in lower power "SUSPEND" state which if properly used could reduce power consumption in usecases. Based on: 2.6.39-rc1 tag Saquib Herman (5): regulator: twl: fix twl6030 enable/disable regulator: twl: remap has no meaning for 6030 regulator: twl: fix twl6030 regulator is_enabled regulator: twl: add twl6030 get_status regulator: twl: add twl6030 set_mode drivers/regulator/twl-regulator.c | 209 - 1 files changed, 159 insertions(+), 50 deletions(-) Tested on: PandaBoard(OMAP4430 with TWL6030) Testing patch: http://pastebin.mozilla.org/1195106 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
[PATCH 1/5] regulator: twl: fix twl6030 enable/disable
From: Saquib Herman
TWL6030 requires an additional register write to CFG_STATE register
to explicitly state that the regulator is in a certain state. Merely
associating the regulator with the group is not enough. Add the
required register field definitions and fix the handling for
TWL6030 enable/disable.
Signed-off-by: Nishanth Menon
Signed-off-by: Saquib Herman
---
drivers/regulator/twl-regulator.c | 31 ++-
1 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index 6a29285..3e9060c 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -76,6 +76,11 @@ struct twlreg_info {
#define VREG_BC_PROC 3
#define VREG_BC_CLK_RST4
+/* TWL6030 LDO register values for CFG_STATE */
+#define TWL6030_CFG_STATE_OFF 0x00
+#define TWL6030_CFG_STATE_ON 0x01
+#define TWL6030_CFG_STATE_GRP_SHIFT5
+
static inline int
twlreg_read(struct twlreg_info *info, unsigned slave_subgp, unsigned offset)
{
@@ -149,6 +154,11 @@ static int twlreg_enable(struct regulator_dev *rdev)
ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_GRP, grp);
+ if (!ret && twl_class_is_6030())
+ ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_STATE,
+ grp << TWL6030_CFG_STATE_GRP_SHIFT |
+ TWL6030_CFG_STATE_ON);
+
udelay(info->delay);
return ret;
@@ -158,17 +168,36 @@ static int twlreg_disable(struct regulator_dev *rdev)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
int grp;
+ int ret;
grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
if (grp < 0)
return grp;
+ /* For 6030, set the off state for all grps enabled */
+ if (twl_class_is_6030()) {
+ ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_STATE,
+ (grp & (P1_GRP_6030 | P2_GRP_6030 | P3_GRP_6030)) <<
+ TWL6030_CFG_STATE_GRP_SHIFT |
+ TWL6030_CFG_STATE_OFF);
+ if (ret)
+ return ret;
+ }
+
if (twl_class_is_4030())
grp &= ~(P1_GRP_4030 | P2_GRP_4030 | P3_GRP_4030);
else
grp &= ~(P1_GRP_6030 | P2_GRP_6030 | P3_GRP_6030);
- return twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_GRP, grp);
+ ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_GRP, grp);
+
+ /* Next, associate cleared grp in state register */
+ if (!ret && twl_class_is_6030())
+ ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_STATE,
+ grp << TWL6030_CFG_STATE_GRP_SHIFT |
+ TWL6030_CFG_STATE_OFF);
+
+ return ret;
}
static int twlreg_get_status(struct regulator_dev *rdev)
--
1.7.1
--
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 2/5] regulator: twl: remap has no meaning for 6030
From: Saquib Herman
TWL6030 does not have remap register. The current implementation
causes value of remap to be written to state register, accidentally
causing the regulators which are probed to be switched on as well.
This is wrong as regulators should be controllable based on calls
to enable/disable for TWL regulator framework. Further, the values
initialized make no sense as well. We hence remove this from the
initalizers and also write to remap register only if the TWL
is 4030.
Signed-off-by: Nishanth Menon
Signed-off-by: Saquib Herman
---
drivers/regulator/twl-regulator.c | 37 +
1 files changed, 17 insertions(+), 20 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index 3e9060c..2e88865 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -517,10 +517,9 @@ static struct regulator_ops twl6030_fixed_resource = {
remap_conf) \
TWL_FIXED_LDO(label, offset, mVolts, num, turnon_delay, \
remap_conf, TWL4030)
-#define TWL6030_FIXED_LDO(label, offset, mVolts, num, turnon_delay, \
- remap_conf) \
+#define TWL6030_FIXED_LDO(label, offset, mVolts, num, turnon_delay) \
TWL_FIXED_LDO(label, offset, mVolts, num, turnon_delay, \
- remap_conf, TWL6030)
+ 0x0, TWL6030)
#define TWL4030_ADJUSTABLE_LDO(label, offset, num, turnon_delay, remap_conf) {
\
.base = offset, \
@@ -539,13 +538,11 @@ static struct regulator_ops twl6030_fixed_resource = {
}, \
}
-#define TWL6030_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts, num, \
- remap_conf) { \
+#define TWL6030_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts, num) { \
.base = offset, \
.id = num, \
.min_mV = min_mVolts, \
.max_mV = max_mVolts, \
- .remap = remap_conf, \
.desc = { \
.name = #label, \
.id = TWL6030_REG_##label, \
@@ -574,11 +571,10 @@ static struct regulator_ops twl6030_fixed_resource = {
}, \
}
-#define TWL6030_FIXED_RESOURCE(label, offset, num, turnon_delay, remap_conf) {
\
+#define TWL6030_FIXED_RESOURCE(label, offset, num, turnon_delay) { \
.base = offset, \
.id = num, \
.delay = turnon_delay, \
- .remap = remap_conf, \
.desc = { \
.name = #label, \
.id = TWL6030_REG_##label, \
@@ -618,17 +614,17 @@ static struct twlreg_info twl_regs[] = {
/* 6030 REG with base as PMC Slave Misc : 0x0030 */
/* Turnon-delay and remap configuration values for 6030 are not
verified since the specification is not public */
- TWL6030_ADJUSTABLE_LDO(VAUX1_6030, 0x54, 1000, 3300, 1, 0x21),
- TWL6030_ADJUSTABLE_LDO(VAUX2_6030, 0x58, 1000, 3300, 2, 0x21),
- TWL6030_ADJUSTABLE_LDO(VAUX3_6030, 0x5c, 1000, 3300, 3, 0x21),
- TWL6030_ADJUSTABLE_LDO(VMMC, 0x68, 1000, 3300, 4, 0x21),
- TWL6030_ADJUSTABLE_LDO(VPP, 0x6c, 1000, 3300, 5, 0x21),
- TWL6030_ADJUSTABLE_LDO(VUSIM, 0x74, 1000, 3300, 7, 0x21),
- TWL6030_FIXED_LDO(VANA, 0x50, 2100, 15, 0, 0x21),
- TWL6030_FIXED_LDO(VCXIO, 0x60, 1800, 16, 0, 0x21),
- TWL6030_FIXED_LDO(VDAC, 0x64, 1800, 17, 0, 0x21),
- TWL6030_FIXED_LDO(VUSB, 0x70, 3300, 18, 0, 0x21),
- TWL6030_FIXED_RESOURCE(CLK32KG, 0x8C, 48, 0, 0x21),
+ TWL6030_ADJUSTABLE_LDO(VAUX1_6030, 0x54, 1000, 3300, 1),
+ TWL6030_ADJUSTABLE_LDO(VAUX2_6030, 0x58, 1000, 3300, 2),
+ TWL6030_ADJUSTABLE_LDO(VAUX3_6030, 0x5c, 1000, 3300, 3),
+ TWL6030_ADJUSTABLE_LDO(VMMC, 0x68, 1000, 3300, 4),
+ TWL6030_ADJUSTABLE_LDO(VPP, 0x6c, 1000, 3300, 5),
+ TWL6030_ADJUSTABLE_LDO(VUSIM, 0x74, 1000, 3300, 7),
+ TWL6030_FIXED_LDO(VANA, 0x50, 2100, 15, 0),
+ TWL6030_FIXED_LDO(VCXIO, 0x60, 1800, 16, 0),
+ TWL6030_FIXED_LDO(VDAC, 0x64, 1800, 17, 0),
+ TWL6030_FIXED_LDO(VUSB, 0x70, 3300, 18, 0),
+ TWL6030_FIXED_RESOURCE(CLK32KG, 0x8C, 48, 0),
};
static int __devinit twlreg_probe(struct platform_device *pdev)
@@ -682,7 +678,8 @@ static int __devinit twlreg_probe(struct platform_device
*pdev)
}
platform_set_drvdata(pdev, rdev);
- twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_REMAP,
+ if (twl_class_is_4030())
+ twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_REMAP,
info->remap);
/* NOTE: many regulators support short-circuit IRQs (presentable
--
1.7.1
--
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
