On Thu, Dec 7, 2017 at 9:16 AM, Xiongfeng Wang
wrote:
> gcc prints the following warning:
> drivers/auxdisplay/img-ascii-lcd.c: In function ‘malta_update’:
> drivers/auxdisplay/img-ascii-lcd.c:109: warning: ‘err’ may be usedun
> initialized in this function
> drivers/auxdisplay/img-ascii-lcd.c: I
On Thursday 28 April 2016 16:00:22 Maxim Kuvyrkov wrote:
> This is a summary of discussions we had on IRC between kernel and toolchain
> engineers regarding support for JITs and 52-bit virtual address space (mostly
> in the context of LuaJIT, but this concerns other JITs too).
>
> The summary is
On Tuesday 09 February 2016 12:28:06 Andy Doan wrote:
> tldr; patches.linaro.org will be upgraded tomorrow, Wednesday the 9th
> around 16:00UTC.
>
Hi Andy,
I just stumbled over some broken links when looking up old patches in
the archive. Specifically, this link https://patches.linaro.org/57380
On Sunday 31 January 2016 04:09:36 Constantine wrote:
> Hello, I couldn't figure out the Erase Block Size of my `Apacer Technology,
> Inc. Handy Steno 2.0/HT203` flash stick.
>
> As I understand, I have to run test as 1024 multiplied by factor of the stick
> capacity, is it? So, I ran tests with
On Friday 30 October 2015 17:27:42 Koen Kooi wrote:
> On 30 October 2015 at 15:33, Arnd Bergmann wrote:
> > On Monday 26 October 2015 10:24:54 Koen Kooi wrote:
> >> The first reports of things breaking are tricking in, OpenWRT
> >> apparently uses binutils-linaro 13.
On Monday 26 October 2015 10:24:54 Koen Kooi wrote:
> The first reports of things breaking are tricking in, OpenWRT
> apparently uses binutils-linaro 13.05 and Fathi mentioned that various
> LAVA health checks are failing now. If you encounter such an issue,
> add the 'archive/' bit to the URL, e.g
On Thursday 11 December 2014 19:27:03 Varad Gautam wrote:
> I'm getting
>
> arch/arm/kernel/efi_phys.S: Assembler messages:
> arch/arm/kernel/efi_phys.S:42: Error: selected processor does not
> support ARM mode `isb'
> arch/arm/kernel/efi_phys.S:50: Error: selected processor does not
> support ARM
On Tuesday 02 December 2014 20:34:59 Shawn Guo wrote:
> On Tue, Dec 02, 2014 at 06:29:52PM +0800, Jisheng Zhang wrote:
> > On Tue, 2 Dec 2014 02:24:03 -0800
> > Arnd Bergmann wrote:
> > > Yes, that's definitely possible. Any idea how the android folks bu
On Tuesday 02 December 2014 18:29:52 Jisheng Zhang wrote:
> On Tue, 2 Dec 2014 02:24:03 -0800
> > On Tuesday 02 December 2014 17:39:21 Jisheng Zhang wrote:
> > >
> > > From my experience in last several years
> > >
> > > 1. the arm-linux-androideabi- toolchain sets some options by default, PIC
>
On Tuesday 02 December 2014 17:39:21 Jisheng Zhang wrote:
>
> On Tue, 2 Dec 2014 01:04:54 -0800
> Shawn Guo wrote:
>
> > + LAKML and more people.
> >
> > On Mon, Dec 01, 2014 at 05:38:38PM +0100, Arnd Bergmann wrote:
> > > On Monday 01 December 2014 16
On Monday 01 December 2014 16:32:21 Shawn Guo wrote:
> Is it a valid or supported use case to build LSK 3.14 kernel with
> android-toolchain? I can build a LSK 3.14 kernel with Linux toolchain
> gcc-linaro-arm-none-eabi-4.9-2014.09, which boots fine on my board.
> When I build the same kernel with
On Monday 03 November 2014 14:48:56 Ivan T. Ivanov wrote:
>
> On Mon, 2014-11-03 at 13:08 +0100, Vincent Guittot wrote:
> > On 3 November 2014 12:32, Arnd Bergmann wrote:
> > > On Monday 03 November 2014 12:06:06 Vincent Guittot wrote:
> > > > On 24 October
On Monday 03 November 2014 12:06:06 Vincent Guittot wrote:
> On 24 October 2014 16:45, Ivan T. Ivanov wrote:
> > ---
> > libdl/dl_syscalls.h | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/libdl/dl_syscalls.h b/libdl/dl_syscalls.h
> > index 8d70056..85dc1e9 100644
> > --- a/li
On Wednesday 29 January 2014 17:40:54 Wookey wrote:
> +++ Arnd Bergmann [2014-01-29 18:14 +0100]:
> > On Wednesday 29 January 2014 16:36:49 Wookey wrote:
> > > Running 32-bit binaries is quite seriously broken until this is fixed. I
> > > presume this currently isn
On Wednesday 29 January 2014 16:36:49 Wookey wrote:
> Running 32-bit binaries is quite seriously broken until this is fixed. I
> presume this currently isn't on anyone's list to fix? I'm not sure who's
> list it should go on.
Are you running with 4KB or 64KB page size in the kernel? IIRC you
canno
Happy New Year everyone!
I'm starting to resume my regular work schedule in Linaro and as the arm-soc
co-maintainer now, after five months of parental leave and a bit of vacation.
I have started following the mailing lists and replying to more work email
a couple of weeks ago, but today is the fir
On Friday 07 June 2013 11:33:33 Manjunath Goudar wrote:
>
> + ohci_setup(hcd);
> s3c2410_start_hc(dev, hcd);
>
> - ohci_hcd_init(hcd_to_ohci(hcd));
> -
I'm not sure about this part: s3c2410_start_hc is where the clock gets
enabled, presumable we are not supposed to touch the
On Friday 07 June 2013 11:33:29 Manjunath Goudar wrote:
> + /*
> + * RemoteWakeupConnected has to be set explicitly before
> + * calling ohci_run. The reset value of RWC is 0.
> + */
Just nitpicking, but you still use the wrong commenting style
occasionally. The '*' charact
On Friday 07 June 2013 11:33:27 Manjunath Goudar wrote:
>
> #if!IS_ENABLED(CONFIG_USB_OHCI_HCD_PCI) && \
> !IS_ENABLED(CONFIG_USB_OHCI_HCD_PLATFORM) && \
> + !IS_ENABLED(CONFIG_USB_OHCI_EXYNOS) && \
> !defined(PLATFORM_DRIVER) &&\
> !defined(OMAP1_PLATFORM_DR
On Friday 31 May 2013 10:12:38 Alan Stern wrote:
> On Thu, 30 May 2013, Arnd Bergmann wrote:
>
> > > I'll try to replicate your result. I don't have my USB audio device
> > > here today, so it will have to wait until tomorrow.
> >
> > Strange enou
On Wednesday 29 May 2013, Alan Stern wrote:
>
> On Wed, 29 May 2013, Arnd Bergmann wrote:
>
> > On Wednesday 29 May 2013 12:21:02 Alan Stern wrote:
> > >
> > > Those error messages are annoying; they don't use dev_err(), so they
> > > don't
On Wednesday 29 May 2013 12:21:02 Alan Stern wrote:
>
> Those error messages are annoying; they don't use dev_err(), so they
> don't include the device and driver names. There's no way to know what
> they refer to. I rather suspect they come from the usbaudio driver.
That makes sense. I have a
On Tuesday 28 May 2013, Manjunath Goudar wrote:
> This series of patches begins the process of splitting ohci-hcd up into
> a core library module and independent pci driver modules.
>
Seems to basically work now, but I'm getting run-time errors after
loading the driver, with patch 1/3 applied:
[
t; - return ret;
> -}
I found that the call to ohci_hcd_init() that is removed here is not getting
added in any other place, which caused a NULL pointer dereference the first
time we actually try to use the driver.
Adding the call back into the new ohci_setup function makes it work again.
Pleas
On Thursday 23 May 2013, Alan Stern wrote:
> > >
> >
> > This section of the driver is gone now since 86510bb248 "USB: OHCI:
> > clarify Kconfig dependencies", so the change is no longer needed.
>
> I don't know what tree you're referring to. That commit is not present
> in Greg's usb-linus or
On Thursday 23 May 2013, Alan Stern wrote:
> On Thu, 23 May 2013, Manjunath Goudar wrote:
> Also, you left out one thing that should still be here. What happened
> to the part about changing
>
> #if !defined(PCI_DRIVER) && \
>
> to
>
> #if !ENABLED(CONFIG_USB_OHCI_HCD_PCI) &&\
On Thursday 23 May 2013, Manjunath Goudar wrote:
> @@ -1275,7 +1266,7 @@ MODULE_LICENSE ("GPL");
> #define PLATFORM_DRIVERohci_platform_driver
> #endif
>
> -#if!defined(PCI_DRIVER) && \
> +#if!defined(PCI_DRIVER) && \
> !defined(PLATFORM_DRIVER) &&\
>
On Tuesday 16 April 2013, Nishanth Menon wrote:
> On 12:50-20130416, Arnd Bergmann wrote:
> > On Tuesday 16 April 2013 12:48:28 Paul Sokolovsky wrote:
> > > > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> > > > index 8d1e2bb..73a99e4 100644
>
On Tuesday 16 April 2013 12:48:28 Paul Sokolovsky wrote:
> > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> > index 8d1e2bb..73a99e4 100644
> > --- a/include/uapi/drm/drm.h
> > +++ b/include/uapi/drm/drm.h
> > @@ -36,7 +36,7 @@
> > #ifndef _DRM_H_
> > #define _DRM_H_
> >
> > -#i
On Monday 31 December 2012, Phillip Norisez wrote:
> Hello.
>
> Are you the Arnd Bergmann that published the article "Optimizing Linux
> with cheap flash drives" in lwm.net on February 18, 2011? If so, I
> would greatly appreciate it if you could answer a question.
Ye
On Monday 31 December 2012, Riku Voipio wrote:
> It's not good enough - the __u64 and friends are used elsewhere in the
> fuse code. However just pulling in linux/types.h as done in out OE
> overlay is good enough:
>
> http://git.linaro.org/gitweb?p=openembedded/meta-aarch64.git;a=blob;f=recipes-s
On Thursday 27 December 2012, Arnd Bergmann wrote:
> 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
> > fr
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
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 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 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 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 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 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 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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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, 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 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 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 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, 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 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, 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, 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 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 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
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 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:
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 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 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, 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
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 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
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 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, 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
>
> 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 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
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 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 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 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 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 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 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 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 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, 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 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 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 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, 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, 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 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 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 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 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, 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 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 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
1 - 100 of 205 matches
Mail list logo
