On Saturday 17 December 2011 16:00:03 Richard Zhao wrote:
> On Fri, Dec 16, 2011 at 08:32:35AM -0600, Rob Herring wrote:
> > On 12/16/2011 04:30 AM, Richard Zhao wrote:
> > > It support single core and multi-core ARM SoCs. But it assume
> > > all cores share the same frequency and voltage.
> > >
>
On Tuesday 20 December 2011, Richard Zhao wrote:
> > +Generic cpufreq driver
> > +
> > +Required properties in /cpus/cpu@0:
> > +- compatible : "generic-cpufreq"
> > >>>
> > >>> I'm not convinced this is the best way to do this. By requiring a
> > >>> generic-cpufreq compatibl
On Tuesday 20 December 2011, Andy Green wrote:
> but your suggestion is more elegant. I'm unsure of the ramifications of
> the 2G / 2G scheme so I'll give it a try later.
WFIW, the main reason why people don't want the 2G/2G split is to allow
user space application to grow to 3GB instead of limi
On Wednesday 21 December 2011, Richard Zhao wrote:
> On Wed, Dec 21, 2011 at 09:20:46AM +0800, Richard Zhao wrote:
> > > > > You also need to define how the core supplies get looked up.
> > >
> > > > It's pure software. platform uses this driver have to define "cpu"
> > > > consumer.
> > >
> >
On Thursday 15 March 2012, Ying-Chun Liu (PaulLiu) wrote:
> From: "Ying-Chun Liu (PaulLiu)"
>
> Anatop is a mfd chip embedded in Freescale i.MX6Q SoC.
> Anatop provides regulators and thermal.
> This driver handles the address space and the operation of the mfd device.
Hi Paul,
This looks like
On Thursday 15 March 2012, Mark Brown wrote:
> There were some other mutterings about using regmap for memory mapped
> devices, mostly from the point of view of building framework features
> like this on top of it. regmap currently makes some assumptions that
> the I/O is going to be slow so appro
>
> Signed-off-by: Ying-Chun Liu (PaulLiu)
> Acked-by: Shawn Guo
Reviewed-by: Arnd Bergmann
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Friday 16 March 2012, Amit Kucheria wrote:
> On Fri, Mar 16, 2012 at 12:29 PM, Thomas Gleixner wrote:
> > On Fri, 16 Mar 2012, Linus Walleij wrote:
> >
> >> On Fri, Mar 16, 2012 at 7:11 AM, Mike Turquette
> >> wrote:
> >>
> >> > Provide documentation for the common clk structures and APIs. T
On Friday 16 March 2012, Arnd Bergmann wrote:
> >
> > Can we shoe-horn this thing into 3.4 (it is a bit late, i know) so
> > that platform ports can gather speed? Several people are waiting for a
> > somewhat stable version before starting their ports.
> >
> >
On Friday 16 March 2012, Turquette, Mike wrote:
> On Fri, Mar 16, 2012 at 3:21 PM, Paul Walmsley wrote:
> > From: Paul Walmsley
> > Date: Fri, 16 Mar 2012 16:06:30 -0600
> > Subject: [PATCH] clk: mark the common clk code as EXPERIMENTAL for now
> >
> > Mark the common clk code as depending on CON
On Saturday 17 March 2012, Turquette, Mike wrote:
> > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> > index 2eaf17e..a0a83de 100644
> > --- a/drivers/clk/Kconfig
> > +++ b/drivers/clk/Kconfig
> > @@ -12,7 +12,7 @@ config HAVE_MACH_CLKDEV
> >
> > menuconfig COMMON_CLK
> > - bool "C
visible.
I've applied this patch now.
Arnd
commit c173033d154e9792b1b5059783b802f82536d48f
Author: Arnd Bergmann
Date: Sat Mar 17 21:10:51 2012 +
clk: make CONFIG_COMMON_CLK invisible
All platforms that use the common clk infrastructure should select
COMMON_CLK from platform code, an
On Tuesday 20 March 2012, Kevin Hilman wrote:
> Maybe it's time that drivers/cpuidle gets a maintainer. With lots of
> discussions of scheduler changes that affect load estimation, I suspect
> we're all going to have a bit of CPUidle work to do in the
> not-so-distant future.
Hmm, according to th
On Tuesday 20 March 2012, Robert Lee wrote:
> This patch series moves various functionality duplicated in platform
> cpuidle drivers to the core cpuidle driver. Also, the platform irq
> disabling was removed as it appears that all calls into
> cpuidle_call_idle will have already called local_irq_
On Tuesday 20 March 2012, Paul Walmsley wrote:
> Hello Arnd,
>
> On Sat, 17 Mar 2012, Arnd Bergmann wrote:
>
> > I think it's rather pointless, because the option is not going to
> > be user selectable but will get selected by the platform unless I'm
> >
On Thursday 12 April 2012, Mike Turquette wrote:
> This series collects many of the fixes posted for the recently merged
> common clock framework as well as some general clean-up. Most of the
> code classifies as a clean-up moreso than a bug fix; hopefully this is
> not a problem since the common
On Wednesday 04 April 2012, Chris Simmonds wrote:
>
> On 04/04/12 11:53, Amit Kucheria wrote:
> > On Wed, Apr 4, 2012 at 1:31 PM, Chris Simmonds
> > wrote:
> >> Hello,
> >>
> >> I am working on behalf of an SoC vendor and I am trying to work out which
> >> (if any) of the many git trees at http:
Hi everyone,
I've been discussing multiplatform kernels with a few people recently,
and we will have a lot of discussion sessions about this at Linaro
Connect in Hong Kong.
One question that came up repeatedly is whether we should support all
possible board files for each platform in a multiplatf
On Thursday 03 May 2012, Russell King - ARM Linux wrote:
> On Thu, May 03, 2012 at 01:50:35PM +0000, Arnd Bergmann wrote:
> > My feeling is that we should just mandate DT booting for multiplatform
> > kernels, because it significantly reduces the combinatorial space
> > at c
On Thursday 03 May 2012, Russell King - ARM Linux wrote:
> I'm basing my comments off mach-zynq.
It's a different question because mach-zynq is already DT-only, but we
can also discuss this for a bit.
> How about we take the following steps towards it?
>
> 1. create arch/arm/include/mach/ which
On Friday 04 May 2012, Arnaud Patard wrote:
> > On Thu, May 03, 2012 at 01:50:35PM +, Arnd Bergmann wrote:
> >> My feeling is that we should just mandate DT booting for multiplatform
> >> kernels, because it significantly reduces the combinatorial space
> >>
On Friday 04 May 2012, Russell King - ARM Linux wrote:
>
> On Fri, May 04, 2012 at 03:20:57PM +0100, Wookey wrote:
> > Debian tries very hard not to support anything in the kernel that
> > upstream don't support in the kernel because otherwise it's way too
> > much work. The current list of suppli
On Friday 04 May 2012, Rob Herring wrote:
> On 05/04/2012 07:20 AM, Arnd Bergmann wrote:
> > On Thursday 03 May 2012, Russell King - ARM Linux wrote:
> > My plan is to have multiplatform kernels in parallel with what we have now,
> > so we can avoid breaking working machin
On Friday 04 May 2012, Wookey wrote:
> > This is very important because distros are obviously the primary consumer
> > of multiplatform builds (aside from build testing). The goal should very
> > much be to reduce the number of distinct kernels that folks like debian,
> > fedora or cyanogenmod have
On Thursday 03 May 2012, Sascha Hauer wrote:
> I don't think that enforcing DT only in multiplatform kernels will speed
> up porting to DT. As a platform maintainer I am interested in building
> multiplatform Kernels, but our customers are mostly uninterested in
> this. They probably disable other
On Friday 04 May 2012, Christian Robottom Reis wrote:
> Isn't there work by Pawel that adds support for more of the Versatile
> platform? My quick searching finds at least:
>
> http://comments.gmane.org/gmane.linux.drivers.i2c/10143
> http://comments.gmane.org/gmane.linux.ports.arm.kernel/
On Saturday 05 May 2012, Sascha Hauer wrote:
> They should not if they are not interested in these boards, but why
> shouldn't I be able to enable these 25 boards plus a few atmel or pxa
> boards?
>
> When there are technical reasons to limit a multiplatform Kernel to DT
> only, then fine, lets do
On Tuesday 08 May 2012, James Tunnicliffe wrote:
>
> https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey
> is being kept up to date, but at a glance has no reliability comments.
> I have 4 Transcend class 10 32GB cards that rocket along, but one has
> stopped letting me write ima
On Tuesday 08 May 2012, Michael Hudson-Doyle wrote:
> On Tue, 8 May 2012 16:30:05 +0300, Riku Voipio wrote:
> >
> > I think following any SD card brand for quality is a losing
> > proposition. Every brand sources chips wherever they cheapest get, and
> > thus what is inside the package changes fr
On Tuesday 08 May 2012, Turquette, Mike wrote:
> Arnd,
>
> Please pull the following changes since commit
> 66f75a5d028beaf67c931435fdc3e7823125730c:
>
> Linux 3.4-rc4 (2012-04-21 14:47:52 -0700)
>
> are available in the git repository at:
> git://git.linaro.org/people/mturquette/linux.git c
On Saturday 05 May 2012, Arnd Bergmann wrote:
> From the statements made so far, I can see no clear policy that we can
> apply to everyone. My take on this is that for any work I spend on
> multiplatform kernel, I concentrate on the DT-based board files and
> get them to work togethe
On Thursday 24 May 2012, John Stultz wrote:
> On 05/23/2012 05:05 PM, John Stultz wrote:
> > Hey Arnd,
> > So it looks like something has gone awry in the 3.5 pull with
> > Panda's mmc functionality. Trying to boot the current 3.5-rc tree,
> > the boot fails after not finding the root device
On Thursday 24 May 2012, John Stultz wrote:
> Yep. Good call, that's the one! Reverting it works for me.
> Thanks for catching that. After a few hours of bisecting I had gone a
> bit braindead. :)
>
> Playing around with the patch, it looks like its the irq assignment
> thats causing problems
On Wednesday 09 May 2012, Arnd Bergmann wrote:
> On Tuesday 08 May 2012, Michael Hudson-Doyle wrote:
> We also know that Samsung has caught up recently and is now making
> excellent controllers even for their "essential" series cards --
> these behave much better than any
On Monday 04 June 2012, David Brown wrote:
> On Mon, Jun 04, 2012 at 03:36:55PM +0000, Arnd Bergmann wrote:
>
> > I can always need more samples. If anyone has Samsung cards at hand, could
> > you
> > send the output of "tail -n 100 /sys/block/mmcblk0/device/*
&g
On Thursday 07 June 2012, David Brown wrote:
> On Wed, Jun 06, 2012 at 07:11:37AM +0000, Arnd Bergmann wrote:
>
> > If you don't need the data on your card, could you run these
> > commands on yours:
> >
> > for i in 2 3 30 31 ; do
> > sudo flashbe
On Monday 11 June 2012, David Brown wrote:
> 4MB variant:
> == 2 ==
> 4MiB4.05M/s
> 2MiB6.13M/s
> 1MiB6.19M/s
> 512KiB 6.14M/s
> 256KiB 5.27M/s
> 128KiB 4.59M/s
> 64KiB 6M/s
> 32KiB 5.04M/s
> 16KiB 490K/s
> == 3 ==
> 4MiB5.06M/s
> 2MiB3.93M/s
> 1MiB1.
On Wednesday 13 June 2012, Jassi Brar wrote:
>
> On 6 June 2012 12:41, Arnd Bergmann wrote:
> >
> > for i in 2 3 30 31 ; do
> >sudo flashbench --open-au --open-au-nr=30 --erasesize=$[512 * 1024] \
> >/dev/mmcblk0 --offset=$[24*1024*102
On Wednesday 06 June 2012, Arnd Bergmann wrote:
(this was David's bad card)
> >
> > MMBTR16GUBCA-ME
> > | CYJ485GA 144
> > Made in TAIWAN
> >
> > but I might have an error there (it is tiny).
>
> Hmm, it had not occurred to me to compare the
On Monday 02 July 2012, Lee Jones wrote:
> On 02/07/12 11:38, Rajanikanth HV wrote:
> > how will you accommodate new battery types information then?
>
> Add them to the driver too?
>
> From what I can see, the structs in board-mop500-bm.c are more of a
> capability thing than saying "this is wh
On Tuesday 10 July 2012, Rajanikanth H.V wrote:
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt
> @@ -0,0 +1,54 @@
> +AB8500 Battery Termperature Monitor Driver
> +
> +AB8500 is a mixed signal multimedia and power management
> +device comprising: power and e
On Thursday 23 August 2012, pioioi wrote:
> I am a graduated school student majoring in computer science in Korea and I
> am interested in UFS.
>
> According to the announcement of JEDEC Mobile memory Forum, UFS Linux driver
> is developed by LINARO
> and it is already available.
>
> I am won
On Monday 10 September 2012, Rajanikanth HV wrote:
> +
> +supplied-to:
> + This is a logical binding w.r.t power supply event change
> + across energy-management-module drivers where in the
> + runtime battery properties are shared along with uevent
> + notification.
> +
On Monday 10 September 2012, Rajanikanth HV wrote:
> +Required Properties:
> +- compatible = "stericsson,ab8500-fg"
> +
> +supplied-to:
> + This is a logical binding w.r.t power supply event change
> + across energy-management-module drivers where in the
> + runtime battery properties
elimited for the warning to prevent this while also
allowing us to see the important output.
Signed-off-by: Arnd Bergmann
diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
index 724ba3b..462b98d 100644
--- a/arch/arm/mm/alignment.c
+++ b/arch/arm/mm/alignment.c
@@ -873,9 +873,9
On Friday 17 June 2011, Nicolas Pitre wrote:
> On Fri, 17 Jun 2011, Arnd Bergmann wrote:
> > On Friday 17 June 2011 14:10:11 Dave Martin wrote:
> >
> > > As part of the general effort to make open source on ARM better, I think
> > > it would be great if we can di
On Tuesday 28 June 2011, ashishj3 wrote:
> The DA9052 is a highly integrated PMIC subsystem with supply domain
> flexibility
> to support wide range of high performance application.
>
> It provides voltage regulators, GPIO controller, Touch Screen, RTC, Battery
> control and other functionality.
ctual mmc_request
> function is called. In the DMA case pre_req() may do dma_map_sg() and prepare
> the dma descriptor and post_req runs the dma_unmap_sg.
I think this looks good enough to merge into the linux-mmc tree, the code is
clean and the benefits are clear.
Acked-by: Arnd Bergmann
One lo
On Thursday 30 June 2011, Russell King - ARM Linux wrote:
> We've been here before - with PCMCIA's card insertion code, where you
> have to go through a sequence of events (insert, power up, reset, etc).
> The PCMCIA code used to have a collection of small functions to do
> each step, one chained a
On Saturday 02 July 2011 14:29:38 Russell King - ARM Linux wrote:
> One other thing to be considered here is whether this idea should be
> limited to just MMC or whether it should be extended further, to
> move the DMA mapping stuff out of the hot path for other block devices
> too.
>
> There are
On Tuesday 05 July 2011, Ashish Jangam wrote:
> DA9053 chip submission was done by Linaro and now they have agreed that
> we will be only responsible for DA9053 submission too so now we can
> skip the posted DA9053 patch.
Ok.
> Regarding file naming convention da9052 seems to be appropriate since
On Tuesday 05 July 2011, ashishj3 wrote:
> DA9052 PMIC has 16 bit GPIO bus for peripheral control.
>
> This patch add support for the GPIO pins on the DA9052.
>
> Signed-off-by: David Dajun Chen
> Signed-off-by: Ashish Jangam
> CC: Mark Brown
> ---
> Changes since v2
> - change of file name
>
On Tuesday 28 June 2011, ashishj3 wrote:
> +static struct platform_driver da9052_wled1_driver = {
> + .probe = da9052_backlight_probe,
> + .remove = da9052_backlight_remove,
> + .driver = {
> + .name = "da9052-WLED1",
> + .owner = THIS_MODULE,
> +
On Tuesday 05 July 2011, David Dajun Chen wrote:
> Hi Arnd,
>
> Da903x driver was developed for da9034/5 pmic family devices, which are
> totally
> different from the da9052 family.
Ok, I've looked at some of the drivers now and I see what you mean.
While there is some similarity in the drivers,
ther functionality.
>
> Signed-off-by: David Dajun Chen
> Signed-off-by: Ashish Jangam
Reviewed-by: Arnd Bergmann
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Wednesday 06 July 2011, ashishj3 wrote:
> l.
>
> This patch add support for the GPIO pins on the DA9052.
>
> Signed-off-by: David Dajun Chen
> Signed-off-by: Ashish Jangam
> CC: Arnd Bergmann
> CC: Mark Brown
A.
>
> This patch allows to control intensity of the individual WLEDs bank through
> DA9052 PMIC.
>
> Signed-off-by: David Dajun Chen
> Signed-off-by: Ashish Jangam
> CC: Arnd Bergmann
Acked-by: Arnd Bergmann
___
linaro-dev mailing
On Friday 08 July 2011 00:37:35 AJ ONeal wrote:
> Confirmed: the combination of a linaro-2.6.39 kernel with a transcend 8gb
> card results in flakey boots.
> linaro-2.6.39 kernel is affected
> transcend cards are affected
> oe-2.6.36 kernel is not affected
> sandisk 8gb cards are not affected (67
Some more points:
On Friday 08 July 2011 00:37:35 AJ ONeal wrote:
> On Wed, Jun 29, 2011 at 11:48 AM, AJ ONeal wrote:
> I have a few inter-related issues:
> Why would one kernel boot a card that another kernel can't?
Possibly the controller is set up in a slightly different way, resulting
in ba
On Monday 11 July 2011 08:57:46 Ashish Jangam wrote:
> > -Original Message-
> > From: Arnd Bergmann [mailto:a...@arndb.de]
> > Sent: Tuesday, July 05, 2011 8:25 PM
> > To: Ashish Jangam
> > Cc: Mark Brown; sa...@openedhand.com; linux-ker...@vger.ker
On Tuesday 19 July 2011 04:57:05 Nicolas Pitre wrote:
> Yes, it is the big 3.0 coming to a Linaro server near you !
>
> The Linux v3.0 based Linaro kernel branch is now available from:
>
> http://git.linaro.org/gitweb?p=kernel/linux-linaro-3.0.git;a=summary
>
> http://git.linaro.org/git/kern
On Thursday 21 July 2011 16:47:48 Mark Brown wrote:
> On Thu, Jul 21, 2011 at 11:46:32PM +0800, Shawn Guo wrote:
> > On Tue, Jul 05, 2011 at 08:07:00PM +0530, ashishj3 wrote:
>
> > > + mutex_lock_interruptible(&da9052->io_lock);
>
> > Compile warning as below.
>
> > "warning: ignoring return v
On Friday 22 July 2011, Mark Brown wrote:
> We went round this analysis already with the underlying I2C drivers
> (which also end up needing to take mutexes and so on) - it really does
> work out better to just make the I/O noninterruptible, the I/O is fast
> enough to not really be worth interrupt
On Thursday 28 July 2011 14:44:17 Nicolas Pitre wrote:
> >
> > We could even embed the printch() function body into the DT if we
> > wanted to make the kernel's job even simpler. Realistic implementations
> > of this function are tiny, so this shouldn't be too cumbersome.
> > That really seems an
On Friday 29 July 2011 10:09:46 Dave Martin wrote:
>
> That sounds sensible to me; I was just throwing ideas about, really.
Yes, and it was good that you brought it up. It's not obvious at
all why we shouldn't put code into the device tree and I'm sure
people will have the same idea in the future
On Friday 12 August 2011 21:12:54 Fathi Boudra wrote:
>
> At the last release meeting, the switch to ext4 by default has been mentioned.
> My understanding is that we reach an agreement on the switch to ext4
> [1] but it still
> not clear if it will happen this month.
>
> To make it happen, it wi
On Wednesday 17 August 2011, James Tunnicliffe wrote:
> > m s
> > ext4 3:30
> > ext3 8:30
> > ext2 5:00
> > btrfs 13:40
> > nilfs 10:40
> > logfs 10:00
> >
> > this is using default mount options for file system but with noatime.
> >
> > These timings also bear out prelim
On Wednesday 17 August 2011, Tixy wrote:
> On Wed, 2011-08-17 at 13:11 +0200, Arnd Bergmann wrote:
> > On Wednesday 17 August 2011, James Tunnicliffe wrote:
> > > One thing I noticed during Ubuntu boot on my Panda was that the mount
> > > process would say that it dete
On Wednesday 17 August 2011, Yasushi SHOJI wrote:
> >
> > The version of btrfs that I'm looking at does not have any optimization
> > for cheap flash drives, only for SSD.
>
> does anyone checked on seekwatcher[1], a visualizing tool Chris Mason
> has wrote. I'm pretty sure that Chris would like
On Thursday 18 August 2011, Tixy wrote:
> Mystery solved...
>
> I didn't have btrfs-tools (nor nilfs nor logfs) installed. My test
> script didn't notice that mkfs failed because I was piping the output
> through tee, (which, being the end of the pipeline, always gave a
> success result).
>
> Thi
On Thursday 18 August 2011, Tixy wrote:
> On Thu, 2011-08-18 at 14:28 +0200, Arnd Bergmann wrote:
> > On Thursday 18 August 2011, Tixy wrote:
> > > I couldn't test logfs because, whilst mkfs worked, the mount command (or
> > > the kernel?) doesn't seem to sup
On Friday 19 August 2011, Linus Walleij wrote:
> On Fri, Aug 19, 2011 at 12:48 PM, Jamie Iles wrote:
>
> >> +static struct class pinctrl_class = {
> >> + .name = "pinctrl",
> >> + .dev_release = pinctrl_dev_release,
> >> + .dev_attrs = pinctrl_dev_attrs,
> >> +};
> >
> > Greg K-H has
On Thursday 01 September 2011, Andrew Stubbs wrote:
> Hi all,
>
> I'm currently trying to get GCC to auto-detect what CPU to optimize for
> by finding out what CPU it's actually running on (the user would only
> have to pass -mcpu=native). It does this simply by reading /proc/cpuinfo.
>
> The p
On Thursday 01 September 2011, John Stultz wrote:
> On Thu, 2011-09-01 at 10:45 +0100, Jon Medhurst (Tixy) wrote:
> > On Wed, 2011-08-31 at 21:05 -0700, John Stultz wrote:
> > > It seems the linaro-dev list isn't configed to avoid mailing folks who
> > > are already recipients of the email.
> >
>
On Wednesday 07 September 2011 10:32:27 Dave Martin wrote:
> Note that the hwcaps info in /proc/cpuinfo is generated from the same
> hwcaps word exposed via auxv so, for now, the information is identical.
>
> I would normally rate parsing /proc/cpuinfo as being a bad idea, but
> /proc/cpuinfo is p
On Thursday 08 September 2011 20:05:48 Mans Rullgard wrote:
> >
> > Can't we do by having omap_init_audio() in arch/arm/mach-omap2/devices.c
> > generate a platform device of name depending upon machine_is_* ?
>
> I had the same thought, but I couldn't find a suitable string anywhere.
> Are you su
On Friday 09 September 2011, Russell King - ARM Linux wrote:
> That's just twisted and utterly insane - adding more code for precisely
> zero benefit what so ever. Think about it - the device tree is already
> creating platform devices for entries in the device tree file. What's
> the point of ha
On Sunday 18 September 2011 15:24:37 Rob Clark wrote:
> I don't suppose there are any guidelines from ARM about compatibility
> between 32bit userspace and 64bit kernel on some hypothetical future
> version of the ARM architecture? Some hints about what to do or not
> do could perhaps save some io
On Monday 19 September 2011, Rob Clark wrote:
> > * If you use structures, try very hard to avoid pointers in them,
> > it messes up all sorts of tools.
> >
> > * If you use structures, make all members naturally aligned, and pad
> > the size of the structures to a multiple of the maximum member
On Monday 19 September 2011 10:43:00 Rob Clark wrote:
> On Mon, Sep 19, 2011 at 10:39 AM, Will Deacon wrote:
> > Arnd,
> >
> > On Mon, Sep 19, 2011 at 08:15:45AM +0100, Arnd Bergmann wrote:
> >> Assuming that we can prevent any funny stuff from going into such an A
On Monday 19 September 2011 19:36:27 Arnd Bergmann wrote:
> >
> > Hmm, so then since you can build the kernel w/ OABI compatibility, it
> > seems like structs should always have padding fields to force them to
> > be a multiple of 32bits...
>
> It depends on whethe
On Monday 26 September 2011, Robert Schwebel wrote:
> On Thu, Aug 18, 2011 at 02:28:07PM +0200, Arnd Bergmann wrote:
> > ext4 has optimizations for flash media in it and btrfs is better by
> > design.
>
> Do you have a pointer to more info about what kind of optimizations f
On Friday 07 October 2011, Christian Robottom Reis wrote:
>
> http://lwn.net/Articles/462076/
>
> How many of these are relevant to ARM platforms (including Android), and
> what would feature on an ARM Plumber's Wish List?
They all apply to ARM but I see these more as small annoyances not to
On Tuesday 22 November 2011, Mike Turquette wrote:
> Introduces kobject support for the common struct clk, exports per-clk
> data via read-only callbacks and models the clk tree topology in sysfs.
>
> Also adds support for generating the clk tree in clk_init and migrating
> nodes when input source
On Tuesday 22 November 2011, Mike Turquette wrote:
> +static void clk_hw_gate_set_bit(struct clk *clk)
> +{
> + struct clk_hw_gate *gate = to_clk_hw_gate(clk);
> + u32 reg;
> +
> + reg = __raw_readl(gate->reg);
> + reg |= BIT(gate->bit_idx);
> + __raw_writel(reg, gate-
On Tuesday 22 November 2011, Mark Salter wrote:
>
> On Tue, 2011-11-22 at 13:11 +, Arnd Bergmann wrote:
> > On Tuesday 22 November 2011, Mike Turquette wrote:
> > > +static void clk_hw_gate_set_bit(struct clk *clk)
> > > +{
> > > + struct
On Tuesday 22 November 2011 12:19:51 Grant Likely wrote:
> On Tue, Nov 22, 2011 at 11:01 AM, Mike Turquette
> wrote:
>
> > Others have requested to have knobs made available for actually
> > performing clk_enable/clk_disable and even clk_set_rate from
> > userspace. I hate this idea and won't im
On Tuesday 29 November 2011, Stefano Stabellini wrote:
> Hi all,
> a few weeks ago I (and a few others) started hacking on a
> proof-of-concept hypervisor port to Cortex-A15 which uses and requires
> ARMv7 virtualization extensions. The intention of this work was to find
> out how to best support A
On Wednesday 30 November 2011, Stefano Stabellini wrote:
> On Tue, 29 Nov 2011, Arnd Bergmann wrote:
> > On Tuesday 29 November 2011, Stefano Stabellini wrote:
> >
> > Do you have a pointer to the kernel sources for the Linux guest?
>
> We have very few changes to the
On Wednesday 30 November 2011, Ian Campbell wrote:
> On Wed, 2011-11-30 at 13:03 +0000, Arnd Bergmann wrote:
> > On Wednesday 30 November 2011, Stefano Stabellini wrote:
> > This is the same choice people have made for KVM, but it's not
> > necessarily the best
On Wednesday 30 November 2011, Ian Campbell wrote:
> On Wed, 2011-11-30 at 14:32 +0000, Arnd Bergmann wrote:
> > On Wednesday 30 November 2011, Ian Campbell wrote:
> > What I suggested to the KVM developers is to start out with the
> > vexpress platform, but then generalize
On Thursday 01 December 2011, Catalin Marinas wrote:
> Given the way register banking is done on AArch64, issuing an HVC on a
> 32-bit guest OS doesn't require translation on a 64-bit hypervisor. We
> have a similar implementation at the SVC level (for 32-bit user apps on
> a 64-bit kernel), the on
On Thursday 01 December 2011, Catalin Marinas wrote:
> On Thu, Dec 01, 2011 at 03:42:19PM +0000, Arnd Bergmann wrote:
> > On Thursday 01 December 2011, Catalin Marinas wrote:
> > How do you deal with signed integer arguments passed into SVC or HVC from
> > a caller
On Tuesday 11 September 2012, Rajanikanth HV wrote:
> >> +Supplied-to:
> >> + This shall be power supply class dependency where in the
> runtime battery
> >> + properties will be shared across fuel guage and charging
> algorithm driver.
> >
> > I probably don't understand enough of this, bu
On Wednesday 12 September 2012, Rajanikanth HV wrote:
> On Tuesday 11 September 2012 04:52 PM, Arnd Bergmann wrote:
> > On Tuesday 11 September 2012, Rajanikanth HV wrote:
> Consider: USB charging:
> __
>| |
&g
On Thursday 13 September 2012, Rajanikanth HV wrote:
> On Wednesday 12 September 2012 09:06 PM, Arnd Bergmann wrote:> >
> > If this is true, I don't understand what makes the 'supplied-to'
> > properties you list in the device tree binding board specific. Are
&
On Friday 14 September 2012, Anton Vorontsov wrote:
> Power supply subsystem's supplied_to describes not just how driver
> should notify other devices, supplied_to is more generic stuff, in terms
> that it describes power supply hierarchy. It's like a directed graph,
> e.g.:
>
>supplied_to
On Friday 14 September 2012, Sachin Kamat wrote:
> Hi Andrey,
>
> On 12 September 2012 17:56, Andrey Konovalov
> wrote:
> > Greetings,
> >
> > The linux-linaro-core-tracking (llct) tree has been moved to v3.6-rc5 base.
> > All the topics existed in the 12.08 version of llct have been carried over
On Monday 17 September 2012, Stefano Stabellini wrote:
> I am also attaching to this email the dts'es that I am currently using
> for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
> vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
> Linux by Xen, while vexpress-vi
On Wednesday 19 December 2012, Riku Voipio wrote:
> Hi,
>
> The following code fails to build with OE Aarch64 toolchain with
> current kernel headers. While ugly, the code is a reduced testcase
> from fuse build failure (
> https://bugs.launchpad.net/linaro-oe/+bug/1087757 ) and the same fuse
> co
1 - 100 of 205 matches
Mail list logo
