(big-endian, thumb 1,
hardfloat) that might need an extra multilib variant if we really
want them.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
-4.4+
when building for armv7 and use generic __builtin_cmpxchg() atomics
whenever building with gcc-4.4?
I would assume that most people building a v7 version of qt (especially
linaro) have this compiler anyway.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
ork-around with fdisk that works
>
> "-c=dos -u=cylinders"
>
> so you might run into it too..
>
We really need to fix the boot loaders here. Anything that writes
to SD cards at unaligned sectors is rather broken, better make sure
that setup_sdcards always aligns the st
own
implementation and set
#define adjust_jiffies(val, ci) adjust_jiffies((val), (ci))
to let the core use that instead of the generic UP version.
While we're there, we should probably try to fix drivers that use
loops_per_jiffy,
because that is not what they think it is on SMP.
are
present in the cpu node if and only if the machine works with this driver
(why else would you put them there?).
CPUs are special in the device trees in a number of ways, so I think we
can treat this as a logical extension. This way, you can still make the
generic cpufreq driver a loadable m
row to 3GB instead of limiting them to 2GB
per task. Most applications are fine with 2GB, but some can run out
of address space and die a little sooner. However, those are typically
the ones that really want a 64 bit machine anyway.
Arnd
___
li
standing is correct, we might as well do that now so we can
attach a device_node to a sys_device.
Kay, does this make sense?
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
rm_bus_probe(np, of_anatop_match, dev);
here, using the same match table that you have in the platform_driver.
That will automatically create platform devices for any children of this
device, so you don't have to update the list above when you get new
child drivers.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
now, but
we can keep this in mind if we see a lot of similar drivers in the future.
Thanks,
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
>
> 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
more advanced stuff than what I need
> >> so I'm pretty pleased, any remaining details can surely be ironed out
> >> in-tree.
> >
> > Ack. We really need to get that in now and sort out the details in
> > tree otherwise we will never finish that thing.
> >
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.
> >
> >
er at
> > least two platforms that do DVFS on groups of external I/O devices have
> > ported their clock implementations over to the common clk code.
> >
> > Signed-off-by: Paul Walmsley
> > Cc: Mike Turquette
>
> ACK. This will set some reasonable expectat
any consequences for real users, but it I think it
does for randconfig builds, which we are trying to repair currently.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
> you merge it I won't object but this might be fixing an imaginary
> > problem.
>
> Architectures without common clock support won't build with this option
> enabled (multiple definition of clk_enable etc), so I think this should
> not be user
(commit_signer:4/10=40%)
While I realize that the get_maintainers.pl is not the final word,
you could be the acting cpuidle maintainer for this merge window
and send the pull request.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
h
and
acpi. If he doesn't reply in the next few days and Andrew also isn't
interested in handling these patches, I'd suggest you just send the pull
request to Linus, with Len on Cc and explain that you tried to send
them through him but gave up in the end.
Arnd
___
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
> >
e the common clk framework is new code pulled for 3.4.
>
> Patches are based on v3.4-rc2 and can be pulled from:
> git://git.linaro.org/people/mturquette/linux.git v3.4-rc2-clk-fixes
>
> Please let me know I missed any critical fixes that were posted to the
> list already.
>
on Cc, but private mail is
ok if you require confidentiality), so I can tell you which parts
you need to change in order to get long term maintainability and
get your code merged upstream in a timely manner.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
yle board files, even
for platforms that are not multiplatform capable.
Other opinions?
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
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
k on the points you raised and a few others,
I would like to know where we're heading because it does impact
some decisions like whether we need to make all initcalls in non-DT
board files aware of potentially being run on other platforms.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
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
> >>
five kernels, or three if
> the Orion/Kirkwood stuff gets converted to DT.
I count four if we were to proceed with the initial proposal:
1. ARMv6/v7 multiplatform: omap2plus, mx5/mx6, vexpress, ...
2. ARMv4/v5 multiplatform: versatile, orion5x, kirkwood, , ...
3. iop32x
4. ixp4xx
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
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
now on the server side.
> It's not clear to me how many omap platforms our 'omap' kernel
> actually serves in practice, and similarly for the other 'generic'
> kernels.
>
> Obviously any and all progress in the direction of m
ather
than helping out getting DT support for the machines they are
interested in?
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
nux.ports.arm.kernel/143523
>
> I think the latter is merged already, but I may be wrong.
That work was done for versatile express, which is very different
from versatile, although it shares a few devices like the i2c controller
mentioned in the
ar 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 together first, but leave it up to the individual
subarch maintainers whethe
ilar to Kingston. Lexar seems to be rather good, but again I only
have a very small data set for those.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
ever encountered a
Sandisk "ultra" or "extreme" card that wasn't really good.
Their cheaper class 2 or class 4 cards are much less trustworthy
IMHO because they use TLC memory.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
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/
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
his case, so we can
retry the probe when the interrupt number becomes available.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
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
t;From what I can tell, all the good Samsung cards are marked "Made in
Korea" while all the bad ones are "Made in Taiwan". I would not treat
this as 100% reliable information as those things tend to change over
time, but it's certainly a good indication.
Arnd
__
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
ooking at uses a compile-time configuration symbol
"CONFIG_AB8500_BATTERY_THERM_ON_BATCTRL". This has to get removed
and turned into a run-time option.
The regulator names in the platform data look should probably be taken
from the device tree.
Arnd
o work.
> + */
> +#ifdef CONFIG_AB8500_9100_LI_ION_BATTERY
> +#define BATRES 180
> +#else
> +#define BATRES 300
> +#endif
I think I mentioned before that you need to get rid of the
CONFIG_AB8500_9100_LI_ION_BATTERY symbol. If you have exclusive
compile-time options, it is impossible to build a kern
w part of Linux, so you can simply
download the latest
Linux version (3.5 or a 3.6-rc prerelease version) and use that.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
valid string.
> + thermister-internal-to-battery = <1>;
> + li_ion_9100_battery = <0>;
Boolean properties should be empty when enabled and not present when
disabled. In this example, one would just write
thermister-internal-to-battery;
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
f_probe(&pdev->dev, np, plat_data);
> + if (ret) {
> + devm_kfree(&pdev->dev, plat_data->fg);
> + devm_kfree(&pdev->dev, plat_data);
> + goto free_device_info;
> + }
>
yslog.
Then we should make sure that an appropriate rate limiting is in place,
like the patch below (untested) would do.
Arnd
8<---
ARM: Add rate-limiting to alignment trap printk
Malicious or buggy applications can easily flood syslog by accessing unaligned
data. Better use printk_rat
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
lculates
> + * TBAT = 20015 milidegree Centrigrade
> +*/
> +static const int32_t tbat_lookup[255] = {
> + 183258, 144221, 124334, 111336, 101826, 94397, 88343, 83257,
> + 78889, 75071, 71688, 68656, 65914, 63414, 61120, 59001,
> +
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
27;t need to bother.
Things might be different for coherent low-end CPU cores like Atom
when mmc device become much faster and block access becomes CPU
bound.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
l make sure that we bring
it up at the meeting next month in Cambridge so we can officially
assign someone to do this.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
appropriate since
> DA9053 chip is update of DA9052 and also DA9052 is the umbrella name
> for the whole family.
What about the existing da903x drivers for leds, touchscreen, battery,
regulator and backlight? Are they all completely distinct from the
da905x l
properties of the hardware and is
used by a single source file, move the contents into that source file.
If a header is used by multiple files in one directory, make it a local
header in that directory.
Arnd
___
linaro-dev mailing list
li
; +}
> +module_init(da9052_backlight_init);
As mentioned before, you should only need to register a single driver
for these three devices: Either you name them all the same and just
give the individual devices a different platform_device->id, or
you leave them with different names and add a
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 simil
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
81M/s
2MiB5.43M/s
1MiB3.81M/s
512KiB 2.27M/s
256KiB 1.34M/s
128KiB 860K/s
64KiB 481K/s
32KiB 229K/s
16KiB 117K/s
8KiB57K/s
If the last row is above 1MB/s, the card is fine, if it is below 100K/s, don't
even think
about using it. The explanation for this behavio
addressing mode ('u'), and create the partitions each at
a multiple of 8192 sectors.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
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
that go into 3.1.
If you think that's too adventurous, it's probably good to merge
at least the next/fixes branch. The next/fixes2 branch contains
all the omap bug fixes, because they depend on the omap cleanup
patches.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
ruptible or at least
_killable with the appropriate error handling, and only use noninterruptible
locks in cases where that's not possible.
In the funtions that Shawn pointed out, there is an error return, so it would
be possible to do that, but the callers would need to be audited carefully.
spinlock (which is by definition not interruptible), or vice
versa. I don't know if this is one of them.
I agree that the safest solution here is to just make the mutex
uninterruptible.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
ch sounds harmless at first, but I think
we should say no to this solution whenever it comes up,
so it doesn't have the chance to grow into something evil.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
d be worth
> exploring it next week.
Agreed.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
of Tixy's file system
simulation before we switch. If there are significant performance regressions
over ext3 or if btrfs turns out to be much better than ext4, we should
probably not move to ext4 at this point but rather try to get btrfs fully
supported. My understanding is that there are other
significant impact here, although it's not clear which of
these is best for a flash memory card, since the characteristics of
SD cards are very different from SSD.
The version of btrfs that I'm looking at does not have any optimization
for cheap flash drives, only for SSD.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
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
e performance: While you mostly care about
seeks on hard drives, the most important performance factor on flash memory
cards is garbage collection cycles. There is some correlation between
the two, but also some significant differences.
I guess it would be possible to visualize GC in seekwatch
options (ssd, nossd and
> ssd_spread). They don't show much difference with the untar case.
Ok.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
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
bus like the
> platform_bus or amba_bus or i2c_bus, then they register a
> class device in this case.
>
> The kerneldoc documentation says
> "A bus is a channel between the processor and one or more devices."
>
> This isn't the case here.
>
> Anyhthing
_cpuid_id() >> 20) & 15);
}
seq_printf(m, "CPU part\t: 0x%03x\n",
(read_cpuid_id() >> 4) & 0xfff);
}
seq_printf(m, "CPU revision\t: %d\n", read_cpuid_id() & 15);
...
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
through. My workflow depends on having emails that have me
on Cc end up in my private inbox, while I also want to have the full
thread in the mailing list archive.
Worse, when someone replies to the email on the mailing list, the
server will have dropped part of the Cc list and I never see the
ece of information.
We do try to keep any ABI stable, including /proc/cpuinfo. I would
generally consider it a bug when it breaks.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
e are of course exceptions,
but I would strongly recommend to have the initialization calling up
from the board file into more general functions instead of having all
boards calling the same function which then goes to board specific
code again.
Arnd
__
for - to create
> platform specific struct devices.
Exactly. No driver or (worse) user program should ever need to look at
the top-level compatible property. When you want information about a
localized part of the system (e.g. the ASoC components), you should
look up the inform
members inside are smaller.
It would be a huge pain if a 64 bit ABI had /different/ padding rules
here, like not padding (logical choice by itself, but hurts is here),
or padding everything to 64 bits (maybe not worth porting the kernel to
then).
Arnd
___
for 32 bit compat ioctls,
you don't want to have to handle sub-commands in different ways
but instead have some commands go directly to the native function
while only the ones whose author screwed up go through a compat
conversion.
Arnd
___
linaro-
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
small annoyances not to
have for specific people. While each of the requests sounds reasonable,
I don't think any of them are important enough that we should spend a
lot of time on them, unless one of us is blocked on a specific item.
Arnd
__
to add a proper
documentation for every new node and attribute in Documentation/ABI along
with the code.
> +static struct kobject *clk_kobj;
> +LIST_HEAD(kobj_list);
The list head should be static.
Arnd
___
linaro-dev mailing list
linar
most architectures do
not implement that. We can probably add a set of helpers in asm-generic/
to define them to the default functions, like "#define readl_relaxed(x)
readl(x)", which I think is a good idea anyway.
Arnd
___
linaro-dev
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
clocks will already be
visible in /proc/devicetree when that is enabled and the clocks are
described in the .dts file.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
now,
it would be very nice if we could agree on the guest model to make
sure that it's always possible to run the same kernel in both
(and potentially other future) hypervisors without modifications.
Arnd
___
linaro-dev mailing list
linaro-
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
ectly, the upper
halves of the argument register end up zero-padded, while the callee
expects sign-extension.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
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
> ref:
>power_supply_changed_work(..) ./drivers/power/power_supply_core.c
>
> In this case how to approach through phandle?
>
>
Sorry, I really tried, but I cannot make sense of what you wrote
there. Can you try again and describe in full English se
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
&
...
};
usb-power: power@... {
...
};
main-battery: battery@... {
power-supply = <&ac-power>, <&usb-power};
;
...
};
It's the same information and absolutely equivalent as far as I can t
1 - 100 of 208 matches
Mail list logo
