On 3/29/2011 10:31 PM, Tony Lindgren wrote:
* Santosh Shilimkarsantosh.shilim...@ti.com [110328 22:47]:
From: Tony Lindgren [mailto:t...@atomide.com]
Do you really need to initialize all of this that early?
Yes. It's a interrupt controller extension and needs to work
together with GIC.
Hi,
On Mon, Mar 28, 2011 at 9:57 PM, Kevin Hilman khil...@ti.com wrote:
Vishwa, Shweta,
Vishwanath Sripathy vishwanath...@ti.com writes:
[...]
I am testing Smartreflex on your Branch 'pm-wip/voltdm'. There seems
an issue with reading VP registers.
For OMAP3 and OMAP4 reading debugfs
On 3/29/2011 10:50 PM, Omar Ramirez Luna wrote:
If an error occurs in the L3 on any other initiator than MPU,
the interrupt goes unhandled given that the 'base' register
was calculated with the initialized err_source value (which
coincidentally points to MPU) and not with the actual source
of
On 3/29/2011 10:50 PM, Omar Ramirez Luna wrote:
Add missing free_irq and remove an empty goto label.
Safe to assume that if we reached the end point of execution
without errors, then return value is 0, so replacing instead
another goto.
Signed-off-by: Omar Ramirez Lunaomar.rami...@ti.com
---
+
static struct platform_device rx51_charger_device = {
- .name = isp1704_charger,
+ .name = isp1704_charger,
I don’t understand what difference between above two lines?
Is your mail client causing this? Or get send-mail doing this?
+ .dev= {
+
Hi,
-Original Message-
From: ext Keshava Munegowda [mailto:keshava_mgo...@ti.com]
Sent: 30. maaliskuuta 2011 9:39
To: Jokiniemi Kalle (Nokia-MS/Tampere); linux-...@vger.kernel.org;
cbouatmai...@gmail.com
Cc: Felipe Balbi; Krogerus Heikki (Nokia-MS/Helsinki);
-Original Message-
From: kalle.jokini...@nokia.com [mailto:kalle.jokini...@nokia.com]
Sent: Wednesday, March 30, 2011 12:12 PM
To: keshava_mgo...@ti.com; linux-...@vger.kernel.org;
cbouatmai...@gmail.com
Cc: ba...@ti.com; heikki.kroge...@nokia.com; sshtyl...@mvista.com;
Omar,
On 3/29/2011 10:50 PM, Omar Ramirez Luna wrote:
Based on the comments received for the first patch:
OMAP3: l3: fix for irq 10: nobody cared message[1],
and quick skimming through the code.
Although there are still parenthesis that are not needed
because of operator precedence, they were
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
Hi,
-Original Message-
From: ext Keshava Munegowda [mailto:keshava_mgo...@ti.com]
snip
+
static struct platform_device rx51_charger_device = {
- .name = isp1704_charger,
^space here
+ .name = isp1704_charger,
On Tue, 2011-03-29 at 14:56 +0530, Archit Taneja wrote:
Panel Taal is a DSI panel connected to the DSI1 lanes on 4430sdp and Blaze.
Add omap_dss_device struct for Panel Taal in the 4430sdp board file. This
represents the primary lcd device on 4430sdp board and Blaze board. The
following things
Tony,
On 3/29/2011 3:51 AM, Tony Lindgren wrote:
Hi all,
This series continues the work to only initialize minimal omap code
in init_early and to cut down dependencies to code that should be
initialized later. It also cleans up the omap2+ timer init code to prepare
things for the later
Hi Laurent and Omar,
Laurent Pinchart wrote:
On Friday 25 March 2011 20:37:55 Ramirez Luna, Omar wrote:
On Fri, Mar 25, 2011 at 10:13 AM, Sakari Ailus
sakari.ai...@maxwell.research.nokia.com wrote:
Hi,
This patchset is aimed to fix a problem in arch_iommu implementation
references. When
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
Hi Sakari,
On Wednesday 30 March 2011 10:16:56 Sakari Ailus wrote:
Laurent Pinchart wrote:
On Friday 25 March 2011 20:37:55 Ramirez Luna, Omar wrote:
On Fri, Mar 25, 2011 at 10:13 AM, Sakari Ailus wrote:
Hi,
This patchset is aimed to fix a problem in arch_iommu implementation
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
Hello.
On 29.03.2011 9:52, kalle.jokini...@nokia.com wrote:
diff --git a/include/linux/power/isp1704_charger.h
b/include/linux/power/isp1704_charger.h
new file mode 100644
index 000..68096a6
--- /dev/null
+++
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
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
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
Laurent Pinchart wrote:
Hi Sakari,
Hi Laurent,
On Wednesday 30 March 2011 10:16:56 Sakari Ailus wrote:
Laurent Pinchart wrote:
On Friday 25 March 2011 20:37:55 Ramirez Luna, Omar wrote:
On Fri, Mar 25, 2011 at 10:13 AM, Sakari Ailus wrote:
Hi,
This patchset is aimed to fix a problem in
On Wednesday 30 March 2011 15:50:37 Sakari Ailus wrote:
Laurent Pinchart wrote:
Hi Sakari,
Hi Laurent,
On Wednesday 30 March 2011 10:16:56 Sakari Ailus wrote:
Laurent Pinchart wrote:
On Friday 25 March 2011 20:37:55 Ramirez Luna, Omar wrote:
On Fri, Mar 25, 2011 at 10:13 AM, Sakari
Hi Shweta,
Gulati, Shweta shweta.gul...@ti.com writes:
[...]
I did a quick debug on this and found that the root cause of the issue is
in usage of ffs (because of this, i2c slave address was configured wrongly
in vc).
Basically ffs returns the position of the first (least significant) bit
From: Jean Pihet j-pi...@ti.com
Created arch/arm/plat-omap/omap-pm-constraints.c file from
arch/arm/plat-omap/omap-pm-noop.c and the associated Kconfig option
OMAP_PM_CONSTRAINTS.
Based on the original patch from Vishwanath,
cf. https://patchwork.kernel.org/patch/327312/
Cc: Vishwanath BS
From: Jean Pihet j-pi...@ti.com
When a wake-up latency constraint is requested or removed the omap device
layer dispatches the updated strongest constraint value to the
corresponding power domain.
The power domains get the next power state programmed directly in the
registers via
From: Jean Pihet j-pi...@ti.com
Figures are added to the power domains structs.
Note: the figures are preliminary figures. More accurate measurements
are needed. Also the conditions of measurements shall be investigated
and described.
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency
From: Jean Pihet j-pi...@ti.com
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
From: Jean Pihet j-pi...@ti.com
The code at omap device level manages the constraints: storage,
tracking of requesters and dispatching to the low level
code (e.g. powerdomain for the wake-up latency constraints).
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
on MPU,
From: Jean Pihet j-pi...@ti.com
Implement the wake-up latency constraints using an internal
unified function _set_dev_constraint at OMAP PM level,
which calls the corresponding function at omap device level.
The actual constraints management code is at the omap device level.
Note: the bus
From: Jean Pihet j-pi...@ti.com
Defined values in the enum:
- OMAP_PM_CONSTRAINT_WKUP_LAT
- OMAP_PM_CONSTRAINT_THROUGHPUT
More classes can be added later if needed.
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
on MPU, CORE and PER.
Signed-off-by: Jean Pihet
Tony Lindgren t...@atomide.com writes:
* Aaro Koskinen aaro.koski...@nokia.com [110316 10:10]:
Somehow I figured this out, the patch arm: mach-omap2: omap_l3_smx:
fix irq handler setup fixes the hang for me (and of course I still need
to comment out timer 12).
FYI, looks like we've
From: Jean Pihet j-pi...@ti.com
Implement OMAP PM layer omap_pm_set_max_dev_wakeup_lat API by
creating a unified API which calls omap_device_set_dev_constraint
for all classes of constraints (devices wake-up latency, devices
throughput...).
The implementation of the constraints framework is at
From: Jean Pihet j-pi...@ti.com
The powerdomains next states are initialized in pwrdms_setup as a
late_initcall. Because the wake-up constraint can be requested
early in the boot sequence, the power domains next states can be
overwritten by pwrdms_setup.
This patch fixes it by initializing the
On Wed, Mar 30, 2011 at 4:56 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
On Wednesday 30 March 2011 15:50:37 Sakari Ailus wrote:
Laurent Pinchart wrote:
Hi Sakari,
Hi Laurent,
On Wednesday 30 March 2011 10:16:56 Sakari Ailus wrote:
Laurent Pinchart wrote:
On Friday
On Friday 18 March 2011, Russell King - ARM Linux wrote:
I do get the impression that you're extremely unhappy with the way ARM
stuff works, and I've no real idea how to solve that. I think much of
it is down to perception rather than anything tangible.
Maybe the only solution is for ARM to
* Santosh Shilimkar santosh.shilim...@ti.com [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
* Santosh santosh.shilim...@ti.com [110329 23:13]:
On 3/29/2011 10:31 PM, Tony Lindgren wrote:
* Santosh Shilimkarsantosh.shilim...@ti.com [110328 22:47]:
From: Tony Lindgren [mailto:t...@atomide.com]
Do you really need to initialize all of this that early?
Yes. It's a interrupt
* Hema Kalliguddi hem...@ti.com [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
On Wed, Mar 30, 2011 at 10:06 AM, Arnd Bergmann a...@arndb.de wrote:
I'm still new to the ARM world, but I think one real problem is the way
that all platforms have their own trees with a very flat hierarchy --
a lot of people directly ask Linus to pull their trees, and the main
way to sort
On Wed, 30 Mar 2011, Linus Torvalds wrote:
ARM right now i a nightmare, and most of it is because ARM hardware
manufacturers are morons.
If in your mind competitors == morons then you might be right.
But the way the ARM tree is then laid out
has made that even more painful, and the decision
On Wed, 30 Mar 2011, Linus Torvalds wrote:
On Wed, Mar 30, 2011 at 10:06 AM, Arnd Bergmann a...@arndb.de wrote:
I'm still new to the ARM world, but I think one real problem is the way
that all platforms have their own trees with a very flat hierarchy --
a lot of people directly ask Linus
On Wed, Mar 30, 2011 at 1:41 PM, Nicolas Pitre n...@fluxnic.net wrote:
If in your mind competitors == morons then you might be right.
There's a difference between competition and do things differently
just to be difficult.
Trying to rely on bootloaders doing things right is like saying that
On Wed, Mar 30, 2011 at 07:06:41PM +0200, Arnd Bergmann wrote:
On Friday 18 March 2011, Russell King - ARM Linux wrote:
I do get the impression that you're extremely unhappy with the way ARM
stuff works, and I've no real idea how to solve that. I think much of
it is down to perception
* Linus Torvalds torva...@linux-foundation.org [110330 12:19]:
On Wed, Mar 30, 2011 at 10:06 AM, Arnd Bergmann a...@arndb.de wrote:
I'm still new to the ARM world, but I think one real problem is the way
that all platforms have their own trees with a very flat hierarchy --
a lot of people
* Thomas Gleixner t...@linutronix.de [110330 14:07]:
So one person will be not enough, that needs to be a whole team of
experienced people in the very near future to deal with the massive
tsunami of crap which is targeted at mainline. If we fail to set that
up, then we run into a very ugly
* Nicolas Pitre n...@fluxnic.net [110330 13:39]:
Trying to rely on bootloaders doing things right is like saying that x86
should always rely on the BIOS doing things right. We have this chance
in the OMAP case to have a manufacturer who is smart enough to document
all those things so
* Russell King - ARM Linux li...@arm.linux.org.uk [110330 14:05]:
On Wed, Mar 30, 2011 at 07:06:41PM +0200, Arnd Bergmann wrote:
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
On Wed, 30 Mar 2011, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [110330 14:07]:
So one person will be not enough, that needs to be a whole team of
experienced people in the very near future to deal with the massive
tsunami of crap which is targeted at mainline. If we fail
On Wed, Mar 30, 2011 at 2:44 PM, Tony Lindgren t...@atomide.com wrote:
That's ridiculous. It's entirely due to the whole f*cked-up arm ecosystem.
Yeh there's no BIOS and there are no scannable busses.. Which leads
to huge amount of data patches that show up in the diffstat.
Yes. And due to
On Wed, Mar 30, 2011 at 02:54:35PM -0700, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [110330 14:07]:
So one person will be not enough, that needs to be a whole team of
experienced people in the very near future to deal with the massive
tsunami of crap which is targeted at
* Linus Torvalds torva...@linux-foundation.org [110330 15:18]:
On Wed, Mar 30, 2011 at 2:44 PM, Tony Lindgren t...@atomide.com wrote:
But for ARM, I suspect even ACPI would actually be an improvement.
Because on ARM, the crazy non-platform hw people already happened, and
took over the insane
* Thomas Gleixner t...@linutronix.de [110330 15:22]:
On Wed, 30 Mar 2011, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [110330 14:07]:
So one person will be not enough, that needs to be a whole team of
experienced people in the very near future to deal with the massive
* Paul E. McKenney paul...@linux.vnet.ibm.com [110330 15:35]:
On Wed, Mar 30, 2011 at 02:54:35PM -0700, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [110330 14:07]:
So one person will be not enough, that needs to be a whole team of
experienced people in the very near
On Wed, 30 Mar 2011, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [110330 15:22]:
On Wed, 30 Mar 2011, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [110330 14:07]:
So one person will be not enough, that needs to be a whole team of
experienced people
On Wed, Mar 30, 2011 at 03:47:52PM -0700, Tony Lindgren wrote:
* Paul E. McKenney paul...@linux.vnet.ibm.com [110330 15:35]:
On Wed, Mar 30, 2011 at 02:54:35PM -0700, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [110330 14:07]:
So one person will be not enough, that
On Wed, 30 Mar 2011, Tony Lindgren wrote:
* Paul E. McKenney paul...@linux.vnet.ibm.com [110330 15:35]:
On Wed, Mar 30, 2011 at 02:54:35PM -0700, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [110330 14:07]:
So one person will be not enough, that needs to be a whole
* Thomas Gleixner t...@linutronix.de [110330 16:11]:
On Wed, 30 Mar 2011, Tony Lindgren wrote:
* Paul E. McKenney paul...@linux.vnet.ibm.com [110330 15:35]:
On Wed, Mar 30, 2011 at 02:54:35PM -0700, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [110330 14:07]:
So
On Wed, 30 Mar 2011, Linus Torvalds wrote:
On Wed, Mar 30, 2011 at 1:41 PM, Nicolas Pitre n...@fluxnic.net wrote:
If in your mind competitors == morons then you might be right.
There's a difference between competition and do things differently
just to be difficult.
Absolutely. We've
On Wed, Mar 30, 2011 at 07:31:59PM -0400, Nicolas Pitre wrote:
Sure, but important noise nevertheless. As long as the noise is
confined to a limited set of .c files I'm happy. OTOH I have very
little hope for a separate project that would only deal with that noise.
That will simply never
On Wed, Mar 30, 2011 at 12:21:32PM -0700, Linus Torvalds wrote:
Look at the dirstat for arch/ in just the current merge window
(cut-off at 5% just to not get too much):
[torvalds@i5 linux]$ git diff -C --dirstat=5 --cumulative v2.6.38.. arch
14.0% arch/arm/mach-omap2/
5.8%
* Russell King - ARM Linux li...@arm.linux.org.uk [110330 16:57]:
On Wed, Mar 30, 2011 at 07:31:59PM -0400, Nicolas Pitre wrote:
Still, because ARM is just a CPU architecture, those SOC vendors will
always have something new to differenciate themselves from the other SOC
vendors. And
Eliminate need for global variables for the various PRM module offsets by
making them part of the VP/VC common structures
Eventually, these will likely be moved again, or more likely removed
when VP/VC code is isolated, but for now just getting rid of them as
global variabes so that the voltage
Start cleaning up the voltage layer to have a voltage domain layer
that resembles the structure of the existing clock and power domain
layers. To that end:
- move the 'struct voltagedomain' out of 'struct omap_vdd_info' to
become the primary data structure.
- convert any functions taking a
The prm_irqst_reg is not part of the VP. Move it up into the common
voltage domain struct.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/voltage.c | 15 +++
arch/arm/mach-omap2/voltage.h |1 +
This voltage domain (a.k.a. VDD1) contains both the MPU and the IVA, so
rename appropriately.
Also fixup any users of the mpu name to use mpu_iva
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c|4 ++--
arch/arm/mach-omap2/omap_twl.c
Add a 'bool scalable' flag to the struct powerdomain and set it for
the scalable domains on OMAP3 and OMAP4.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/voltage.c |3 +++
arch/arm/mach-omap2/voltage.h |2 ++
Add wakeup voltage domain so that the wakeup powerdomain can have an
associated powerdomain. Note that the scalable flat is not set for
the this voltagedomain, so it will not be fully initialized like
scalable voltage domains.
Signed-off-by: Kevin Hilman khil...@ti.com
---
Each powerdomain is associated with a voltage domain. Add an entry to
struct powerdomain where the enclosing voltagedomain can be
referenced.
Modeled after similar relationship between clockdomains and powerdomains.
Signed-off-by: Kevin Hilman khil...@ti.com
---
Create basic voltagedomains for OMAP2 and associate OMAP2 powerdomains
with the newly created voltage domains.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +-
arch/arm/mach-omap2/io.c |2 +
Add voltage domain name to indicate which voltagedomain each
powerdomain is in.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c |2 ++
arch/arm/mach-omap2/powerdomains3xxx_data.c | 16
2 files changed, 18 insertions(+),
From: Benoit Cousson b-cous...@ti.com
Add voltage domain name to indicate which voltagedomain each
powerdomain is in.
The fixed voltage domain like ldo_wakeup for emu and wkup power
domain is added too.
Update the TI copyright date to 2011.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc:
When a powerdomain is registered, lookup the voltage domain by name
and keep a pointer to the containing voltagedomain in the powerdomain
structure.
Modeled after similar method between powerdomain and clockdomain layers.
Signed-off-by: Kevin Hilman khil...@ti.com
---
When a powerdomain is registered and it has an associated voltage domain,
add the powerdomain to the voltagedomain using voltdm_add_pwrdm().
Also add voltagedomain iterator helper functions to iterate over all
registered voltagedomains and all powerdomains associated with a
voltagedomain.
As part of the voltage layer cleanup, split out VC specific code into
a dedicated VC layer. This patch primarily just moves VC code from
voltage.c into vc.c, and adds prototypes to vc.h.
No functional changes.
For readability, each function was given a local 'vc' pointer:
struct
This patch is primarily a move of VP specific code from voltage.c into
its own code in vp.c and adds prototypes to vp.h
No functional changes, except debugfs...
VP debugfs moved to 'vp' subdir of debugfs/voltage/ and 'vp_'
prefixes removed from all debugfs filenames.
Signed-off-by: Kevin Hilman
The VC layer can support PMICs with separate voltage and command
registers by putting the different registers in the PRM_VC_SMPS_VOL_RA
and PRCM_VC_SMPS_CMD_RA registers respectively.
The PMIC data must supply at least a voltage register address
(volt_reg_addr). The command register address
Move the VC instance struct from omap_vdd_info into struct voltagedomain.
While moving, perform some misc. renames for readability.
No functional changes.
Summary of renames:
- rename omap_vc_instance to omap_vc_channel, since there is only
one instance of the VC IP and this actually
Nico:
On Wed, Mar 30, 2011 at 6:31 PM, Nicolas Pitre n...@fluxnic.net wrote:
But X86 is peanuts. Really.
Finally, a voice of reason!
On ARM there is simply not such thing as a single machine design to
clone, and a closed source test bench to design for.
... and there almost certainly
On Wed, 30 Mar 2011, Nicolas Pitre wrote:
On Wed, 30 Mar 2011, Linus Torvalds wrote:
On Wed, Mar 30, 2011 at 1:41 PM, Nicolas Pitre n...@fluxnic.net wrote:
Trying to rely on bootloaders doing things right is like saying that x86
should always rely on the BIOS doing things right.
No. Not
On Wed, Mar 30, 2011 at 5:15 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
In this merge window, I deleted at least 6000 lines from arch/arm, and
by quoting diffstat percentages, you're using that against the ARM
community. Why did I bother (that's not a question).
Umm. The
Linus:
On Wed, Mar 30, 2011 at 7:55 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
124022 total arch/sh
124418 total arch/sparc
181997 total arch/m68k
246717 total arch/mips
254785 total arch/x86
370912 total arch/powerpc
732732 total arch/arm
I'm not sure this metric is
On Wed, Mar 30, 2011 at 6:15 PM, Bill Gatliff b...@billgatliff.com 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
Linus:
On Wed, Mar 30, 2011 at 8:37 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
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.
You should go talk with ARM about it, I'm sure
On Wed, Mar 30, 2011 at 6:44 PM, Bill Gatliff b...@billgatliff.com wrote:
In the meantime, we have to live with the chips that exist and the
ones coming down the pipe. Until ARM and all their licensees start
consulting us on such matters, we'll just have to find a way to deal
with what we're
Linus:
On Wed, Mar 30, 2011 at 8:56 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
(a) we don't have to be stupid and think it's a good design and an
opportunity like you do.
The complexity that is the current state of the ARM ecosystem presents
the opportunity to find a way to
On Wed, 30 Mar 2011, da...@lang.hm wrote:
On Wed, 30 Mar 2011, Nicolas Pitre wrote:
Furthermore, this does create pain. you have to make things in sync
between the kernel and the mini-kernel (let's call it bootloader). In
practice the bootloader is always maintained separately from the
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
On Wed, Mar 30, 2011 at 7:20 PM, Bill Gatliff b...@billgatliff.com wrote:
If it isn't opportunity, then you must be arguing that we shouldn't
add any new ARM SoC support to the kernel. Is that what you are
saying?
What I'm saying is that we should not be adding ANY MINDLESS BOARD
DRIVERS for
On Wed, 30 Mar 2011, Linus Torvalds wrote:
Umm. The actual stats are still:
1349 files changed, 62230 insertions(+), 33993 deletions(-)
which is sad. And the end result speaks for itself: this is lines per
architecture:
...
124022 total arch/sh
124418 total arch/sparc
On Thu, 31 Mar 2011, Dave Airlie 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
On Wed, 30 Mar 2011, Nicolas Pitre wrote:
On Wed, 30 Mar 2011, da...@lang.hm wrote:
On Wed, 30 Mar 2011, Nicolas Pitre wrote:
this means that you need to have some group doing the equivalent of assigning
device numbers for the different devices (and in this case going just a little
On Thu, Mar 31, 2011 at 01:31, Nicolas Pitre n...@fluxnic.net wrote:
On Wed, 30 Mar 2011, Linus Torvalds wrote:
The long-term situation should be that you should be able to have ONE
binary kernel just work. That's where we are on x86. Really.
But X86 is peanuts. Really. There was one
92 matches
Mail list logo
