On Fri, May 6, 2016 at 12:15 PM, Alexander Graf wrote:
>
>
> On 06.05.16 13:03, Grant Likely wrote:
>> On Fri, May 6, 2016 at 2:10 AM, Tom Rini wrote:
>>> On Thu, May 05, 2016 at 10:21:25PM +0200, Alexander Graf wrote:
>>>> So what's the goal here? Ar
On Fri, May 6, 2016 at 2:10 AM, Tom Rini wrote:
> On Thu, May 05, 2016 at 10:21:25PM +0200, Alexander Graf wrote:
>> On 05.05.16 17:21, Grant Likely wrote:
>> > On Thu, May 5, 2016 at 12:45 PM, Marcin Juszkiewicz
>> > wrote:
>> >> Recently my angry post o
On Fri, May 6, 2016 at 2:10 AM, Tom Rini wrote:
> On Thu, May 05, 2016 at 05:30:55PM +0100, Grant Likely wrote:
>> On Thu, May 5, 2016 at 4:59 PM, Mark Brown wrote:
>> > On Thu, May 05, 2016 at 09:01:05PM +0530, Amit Kucheria wrote:
>> >> On Thu, May 5, 2016
On Thu, May 5, 2016 at 5:53 PM, Mark Brown wrote:
> On Thu, May 05, 2016 at 04:21:59PM +0100, Grant Likely wrote:
>
>> I think we have everything we need to work around the location of the
>> FW boot image without breaking the UEFI spec. The biggest problem is
>> making
On Thu, May 5, 2016 at 4:59 PM, Mark Brown wrote:
> On Thu, May 05, 2016 at 09:01:05PM +0530, Amit Kucheria wrote:
>> On Thu, May 5, 2016 at 5:15 PM, Marcin Juszkiewicz
>
>> > Solution for existing SoCs is usually adding 1MB of SPI flash during design
>> > phase of device and store boot loader(s)
On Thu, May 5, 2016 at 12:45 PM, Marcin Juszkiewicz
wrote:
> Recently my angry post on Google+ [1] got so many comments that it was clear
> that it would be better to move to some mailing list with discussion.
>
> As it is about boot loaders and Linaro has engineers from most of SoC vendor
> compa
Hi Varad,
Please join IRC channel #linaro-gsoc if you haven't already. I'm 'gcl'
on that channel. For the AArch64 porting project you should be in
contact with Steve McIntyre. For the UEFI porting project you should
talk to Leif Lindholm (I can be involved with that one too). I've
included both of
On Wed, Feb 20, 2013 at 11:07 AM, Philip Colmer
wrote:
> So we could flip the management of the list on its head, then, and make the
> list wide open but blacklist spammers ... except that you then find yourself
> in a reactive mode. In other words, spam gets onto the list because the list
> is op
On Mon, Jul 22, 2013 at 8:56 PM, Yoder Stuart-B08248
wrote:
> Is there a written spec or description of how a boot program (u-boot, UEFI,
> hypervisor) boots an OS on ARM platforms?
>
> ePAPR-type device trees are used to describe a platform, but what
> about the type of information in sections 5.
On Tue, Jul 23, 2013 at 12:39 PM, Peter Maydell
wrote:
> On 23 July 2013 12:33, Grant Likely wrote:
>> Historically each ARM SoC did its own thing for secondary CPU startup.
>> New platforms are expected to use the PSCI spec (which unfortunately
>> isn't an open docu
quot;mmc3";
> >> + };
> >> +
> >> + mmc4: mmc@4 {
> >> + compatible = "ti,omap4-hsmmc";
> >> + ti,hwmods = "mmc4";
> >> + };
>
On Fri, 24 Feb 2012 10:49:00 -0800, Tony Lindgren wrote:
> * Rajendra Nayak [120223 19:29]:
> > On Friday 24 February 2012 12:27 AM, Tony Lindgren wrote:
> > >>--- a/arch/arm/boot/dts/omap3.dtsi
> > >>+++ b/arch/arm/boot/dts/omap3.dtsi
> > >>@@ -113,5 +113,31 @@
> > >> #s
},
> + {},
> +}
> +MODULE_DEVICE_TABLE(of, omap_mmc_of_match);
> +#endif
> +
> static struct platform_driver omap_hsmmc_driver = {
> .remove = omap_hsmmc_remove,
> .driver = {
> .name = DRIVER_NAME,
> .own
On Mon, Feb 27, 2012 at 6:52 AM, Cousson, Benoit wrote:
> Hi Mark,
>
>
> On 2/27/2012 2:41 PM, Mark Brown wrote:
>>
>> On Mon, Feb 27, 2012 at 06:01:20PM +0530, Rajendra Nayak wrote:
>>
>>> Depending on what order Mark happens to pull them in, I am fine
>>> re-sending adding support for the 2 twl6
On Wed, Jan 18, 2012 at 11:42:28AM +, Mark Brown wrote:
> On Wed, Jan 18, 2012 at 11:39:50AM +, Mark Brown wrote:
>
> > This appears to reintroduce the setting of an exact voltage which I'm
> > sure was fixed in previous versions of the patch.
>
> Erk, sorry - it looks like the device tre
On Tue, Nov 22, 2011 at 11:01 AM, Mike Turquette wrote:
> On Tue, Nov 22, 2011 at 8:37 AM, Grant Likely
> wrote:
>>
>> On Nov 21, 2011 6:43 PM, "Mike Turquette" wrote:
>>>
>>> Introduces kobject support for the common struct clk, exports per-clk
&
On Nov 21, 2011 6:43 PM, "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 Nov 6, 2011 11:25 PM, "Dirk Behme" wrote:
>
> On 06.11.2011 19:42, Grant Likely wrote:
>>
>> On Sun, Nov 6, 2011 at 11:38 AM, Grant Likely
wrote:
>>>
>>> On Sat, Nov 05, 2011 at 07:19:15AM +0100, Dirk Behme wrote:
>>>>
>>>&g
On Sun, Nov 6, 2011 at 11:38 AM, Grant Likely wrote:
> On Sat, Nov 05, 2011 at 07:19:15AM +0100, Dirk Behme wrote:
>> The patch 'arm/dt: Add dtb make rule' adds support to
>> create a .dtb file. But this is never removed afterwards.
>> Remove the generated .dt
hme
> CC: Rob Herring
> CC: Shawn Guo
> CC: Jason Liu
> CC: Grant Likely
Acked-by: Grant Likely
> ---
> arch/arm/boot/Makefile |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
> ind
On Tue, Oct 25, 2011 at 10:05:32AM +0200, Tony Lindgren wrote:
> * Grant Likely [111024 12:31]:
> > On Mon, Oct 24, 2011 at 09:48:19AM +0200, Linus Walleij wrote:
> > > On Mon, Oct 24, 2011 at 9:36 AM, Grant Likely
> > > wrote:
> > > > On Mon, Oct 24,
On Mon, Oct 24, 2011 at 09:48:19AM +0200, Linus Walleij wrote:
> On Mon, Oct 24, 2011 at 9:36 AM, Grant Likely
> wrote:
> > On Mon, Oct 24, 2011 at 09:26:38AM +0200, Linus Walleij wrote:
> (...)
> >> I was more thinking along the lines of one device per GPIO controller,
On Mon, Oct 24, 2011 at 09:26:38AM +0200, Linus Walleij wrote:
> On Sat, Oct 22, 2011 at 7:44 PM, Mike Frysinger wrote:
> > On Tue, Oct 4, 2011 at 16:35, Grant Likely wrote:
> >> On Sat, Oct 01, 2011 at 12:39:21PM +0200, Linus Walleij wrote:
> >>> 2011/9/30 Grant Lik
ucture
> they all need. See the Documentation/pinctrl.txt file that is
> part of this patch for more details.
>
> Cc: Grant Likely
> Cc: Stijn Devriendt
> Cc: Joe Perches
> Cc: Russell King
> Acked-by: Stephen Warren
> Tested-by: Barry Song <21cn...@gmail.com>
On Tue, Oct 04, 2011 at 09:50:02PM +0100, Mark Brown wrote:
> On Tue, Oct 04, 2011 at 12:18:18PM -0600, Grant Likely wrote:
> > #define module_platform_driver(__driver) \
> > int __driver##_init(void) \
> > { \
> > return platform_driver_register(&(__driv
On Sat, Oct 01, 2011 at 12:39:21PM +0200, Linus Walleij wrote:
> 2011/9/30 Grant Likely :
>
> > I'm not convinced that the sysfs approach is
> > actually the right interface here (I'm certainly not a fan of the gpio
> > sysfs i/f), and I'd rather not
ion warnings.
>
> Signed-off-by: Tushar Behera
Acked-by: Grant Likely
> ---
> It has been build tested with s3c2410_defconfig, s3c6400_defconfig,
> s5p64x0_defconfig, s5pc100_defconfig, s5pv210_defconfig and
> exynos4_defconfig.
>
> The patch has been rebased onto
On Mon, Sep 26, 2011 at 10:38:58AM +0100, Mark Brown wrote:
> On Sat, Sep 24, 2011 at 10:08:36PM -0600, Grant Likely wrote:
> > On Thu, Sep 22, 2011 at 03:27:01PM -0700, Mike Turquette wrote:
>
> > > + ret = platform_driver_register(&wm831x_clk_driv
On Mon, Oct 03, 2011 at 09:17:30AM -0500, Rob Herring wrote:
> On 09/22/2011 05:26 PM, Mike Turquette wrote:
> > + /* Query the hardware for parent and initial rate */
> > +
> > + if (clk->ops->get_parent)
> > + /* We don't to lock against prepare/enable here, as
> > +* th
On Fri, Sep 30, 2011 at 9:05 AM, Linus Walleij wrote:
> On Fri, Sep 30, 2011 at 4:07 AM, Grant Likely
> wrote:
>
>> Comments below, some a bit nitpicky, but overall I think it looks
>> good. I haven't dug into it nearly deeply enough though. :-(
>
> Hopefully
On Wed, Sep 28, 2011 at 02:03:39PM +0200, Linus Walleij wrote:
> From: Linus Walleij
>
> This creates a subsystem for handling of pin control devices.
> These are devices that control different aspects of package
> pins.
Comments below, some a bit nitpicky, but overall I think it looks
good. I
On Fri, Sep 16, 2011 at 02:14:09PM +0200, Linus Walleij wrote:
> From: Linus Walleij
>
> This adds a driver for the U300 pinmux portions of the system
> controller "SYSCON". It also serves as an example of how to use
> the pinmux subsystem. This driver also houses the platform data
> for the only
On Thu, Sep 22, 2011 at 03:26:55PM -0700, Mike Turquette wrote:
> Hi all,
>
> The goal of this series is to provide a cross-platform clock framework
> that platforms can use to model their clock trees and perform common
> operations on them. Currently everyone re-invents their own clock tree
> in
On Thu, Sep 22, 2011 at 03:27:01PM -0700, Mike Turquette wrote:
> From: Mark Brown
>
> The WM831x and WM832x series of PMICs contain a flexible clocking
> subsystem intended to provide always on and system core clocks. It
> features:
>
> - A 32.768kHz crystal oscillator which can optionally be
On Thu, Sep 22, 2011 at 03:26:59PM -0700, Mike Turquette wrote:
> From: Jeremy Kerr
>
> Signed-off-by: Jeremy Kerr
> Signed-off-by: Mark Brown
> Signed-off-by: Jamie Iles
> Signed-off-by: Mike Turquette
> ---
> Changes since v1:
> Add copyright header
> Fold in Jamie's patch for set-to-disabl
foo_ops = {
> .enable = clk_foo_enable,
> };
>
> And in the platform initialisation code:
>
> struct clk_foo my_clk_foo;
>
> void init_clocks(void)
> {
> my_clk_foo.enable_reg = ioremap(...);
>
> clk_register(&clk_foo_ops, &my_clk_foo, NULL);
S
cretlab.ca/git/linux-2.6 devicetree/linaro-3.0
Andy Doan (1):
arm/dt: Add basic device tree support for overo
Grant Likely (29):
dt: Add default match table for bus ids
dt: add of_platform_populate() for creating device from the device tree
drivers/amba: create devices from d
On Thu, Jul 21, 2011 at 3:36 PM, Nicolas Pitre wrote:
> On Thu, 21 Jul 2011, Grant Likely wrote:
>
>> You can pull devicetree/next right now. I've still got a few things
>> to do before I get you to pull the dt board support patches. Give me
>> a few more hours
You can pull devicetree/next right now. I've still got a few things
to do before I get you to pull the dt board support patches. Give me
a few more hours.
g.
On Thu, Jul 21, 2011 at 1:29 PM, Nicolas Pitre wrote:
> On Tue, 19 Jul 2011, Grant Likely wrote:
>
>> On Tue, Jul
On Tue, Jul 19, 2011 at 03:22:58PM -0300, Ricardo Salveti wrote:
> On Tue, Jul 19, 2011 at 3:04 PM, Nicolas Pitre
> wrote:
> > On Tue, 19 Jul 2011, John Rigby wrote:
> >
> >> My first request would be for board level device tree support.
> >
> > I think Grant should have that ready soon.
>
> Gra
On Sat, Jul 16, 2011 at 12:06:33PM -0400, Jerry Van Baren wrote:
> On 07/09/2011 04:40 PM, David A. Long wrote:
> >From: David A. Long
> >
> >Add a new "fdt_high" enviroment variable. This can be used to control (or
> >prevent) the
> >relocation of the flattened device tree on boot. It can be used
On Thu, Jul 14, 2011 at 03:12:25PM -0400, David Long wrote:
> On Fri, 2011-07-15 at 03:50 +0900, Grant Likely wrote:
>
>
> > Regardless of this patch, the pandaboard uboot still needs to be
> > fixed. Setting an fdt_high variable is useful for debug, but it is not
> &g
mory beyond about 3/4G (HIGHMEM) during early boot.
>
Regardless of this patch, the pandaboard uboot still needs to be
fixed. Setting an fdt_high variable is useful for debug, but it is not
a fix.
g.
> -dl
>
>
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
C: Mark Brown
Acked-by: Grant Likely
It looks like this needs to be merged via the MFD tree since it
depends on the core da9052 driver patch.
Also, comments below:
> ---
> Changes since v3:
> - Remove da9052 gpio header file
>
> Changes since v2:
> - change of file name
>
On Thu, Jun 30, 2011 at 10:40:44AM -0400, David Long wrote:
> Can someone explain why uboot copies the initrd and device tree data to
> higher memory when we boot panda with a dtb? I'm assuming there's a
> reason, but it seems a problematic thing to do (potentially even without
> >3/4GB SDRAM pre
On Fri, Jun 24, 2011 at 6:27 AM, Thomas Abraham
wrote:
> Hi Grant,
>
> On 24 June 2011 01:38, Grant Likely wrote:
>> Despite the fact that this is exactly what I asked you to write, this
>> ends up being rather ugly. (I originally put in the '*4' to match t
On Wed, Jun 22, 2011 at 10:22 AM, Thomas Abraham
wrote:
>
> I have added the functions as you have suggested and the diff is
> listed below. Could you please review the diff and suggest any changes
> required.
Thanks Thomas. Comments below...
> drivers/of/base.c | 129
>
On Tue, Jun 21, 2011 at 11:31 AM, David Long wrote:
>
> Hi,
>
> WRT to .dtb files: I see sources in the kernel tree but they don't appear to
> be built as part of the kernel build. How are these produced and how can I
> build a modified one for some testing?
Nicolas' linaro-2.6.39 tree has th
ARM: head, zImage: Always Enter the kernel in ARM state (2011-06-20
10:50:54 -0400)
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6 devicetree/linaro-2.6.39
Andy Doan (1):
arm/dt: Add basic device tree support for overo
Grant Likely (18):
arm/dt: A
data_lookup, NULL);
> +}
> +
> +static char const *exynos4_dt_compat[] __initdata = {
> + "samsung,exynos4210",
> + NULL
> +};
> +
> +DT_MACHINE_START(SMDKV310, "Samsung Exynos4 DT")
> + /* Maintainer: Kukjin Kim */
> + .boot_params = S5P_PA_SDRAM + 0x100,
> + .init_irq = exynos4_init_irq,
> + .map_io = exynos4_dt_map_io,
> + .init_machine = exynos4_dt_machine_init,
> + .timer = &exynos4_timer,
> + .dt_compat = exynos4_dt_compat,
> +MACHINE_END
> --
> 1.6.6.rc2
>
>
> ___
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
.name = "s3c-sdhci",
> + .of_match_table = s3c_sdhci_match,
> },
> };
>
> --
> 1.6.6.rc2
>
>
> _______
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
On Mon, Jun 20, 2011 at 5:02 AM, Thomas Abraham
wrote:
> This patch adds the of_match_table to enable s3c2410-wdt driver
> to be probed when watchdog device node is found in the device tree.
>
> Signed-off-by: Thomas Abraham
Acked-by: Grant Likely
You need to send this to Wim a
_property(child, "divisor", &len);
> + if (prop && len)
> + clksrc->divisor = be32_to_cpu(*(u32 *)prop);
> +
> + prop = of_get_property(child, "min_baud", &len);
> + if (prop && len)
,9 @@ struct s3c24xx_uart_info {
>
> unsigned int has_divslot:1;
>
> + /* copy of platform data */
I'd change this to "copy of /configuration/ data" since the data
doesn't necessarily come from the platform_data pointer anymore.
> +
On Tue, Jun 14, 2011 at 8:05 AM, Far McKon wrote:
> Grant,
> I don't see any system for indicating an expandable bus or a pulg in
> module so far? Am I missing something, or does this protocol/layout
> not allow for plug in or expansion modules?
The DT as we're using it now primarily captures the
ial information that may be proprietary,
> privileged or copyrighted under applicable law. If you are not the intended
> recipient, do not read, copy, or forward this email message or any
> attachments. Delete this email message and any attachments immediately.
&g
al model of pinmux?
Other comments below.
>
> Cc: Grant Likely
> Cc: Stephen Warren
> Cc: Joe Perches
> Cc: Russell King
> Signed-off-by: Linus Walleij
> ---
> ChangeLog v2->v3:
> - Renamed subsystem folder to "pinctrl" since we will likely
> want to k
Signed-off-by: Grant Likely
---
Hey all,
This is an early draft of the usage model document for the device
tree, but I wanted to get it out there for feedback, and so that some
of the Linaro engineers could get started on migrating board ports.
g.
Documentation/devicetree/usage-model | 403
On Fri, May 20, 2011 at 10:37:08AM -0300, Christian Robottom Reis wrote:
> On Thu, May 19, 2011 at 12:01:50PM -0600, Grant Likely wrote:
> > >> https://bugs.launchpad.net/linux-linaro/+bug/768680
> > >
> > > Mainline kernels don't change anything with th
Adds support for passing a device tree for booting the u8500 board.
Signed-off-by: Grant Likely
---
Completely untested. Not even compiled. Per, this should be all you
need to change in the kernel to get DT support working on the u8500.
g.
arch/arm/boot/dts/u8500-hrefv60.dts |7
On Thu, May 19, 2011 at 11:55 AM, Paul Walmsley wrote:
> On Thu, 19 May 2011, Grant Likely wrote:
>
>> Would either of you mind looking at this bug report? On the IGEP,
>> when booting with DT is used, something appears to get messed up with
>> initializing the clocks.
aro/+bug/768680
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Thu, May 12, 2011 at 9:47 AM, Nicolas Pitre wrote:
> On Wed, 11 May 2011, Russell King - ARM Linux wrote:
>
>> On Wed, May 11, 2011 at 10:44:49PM +0200, Grant Likely wrote:
>> > Right now it merges cleanly with linux-next and the resulting tree
>> > builds and b
linux-next and the resulting tree
builds and boots at least on qemu. Unless you really object, I'm
going to ask Stephen to add the following branch to the /end/ of the
list of trees for linux-next so it can easily be dropped it if it
causes any problems.
git://git.secretlab.ca/git/linux-2.6
to the removal of lookup_machine_type()
- break out dump of machine_desc table into dump_machine_table()
because the device tree probe code will use it.
- Add for_each_machine_desc() macro
Tested-by: Tony Lindgren
Signed-off-by: Grant Likely
---
arch/arm/include/asm/mach/arch.h |
initrd setup to this patch to make the
series bisectable.
- switched to alloc_bootmem_align() for allocation when
unflattening the device tree. memblock_alloc() was not the
right interface.
Signed-off-by: Jeremy Kerr
Tested-by: Tony Lindgren
Signed-off-by: Grant Likely
allocated buffer.
- Since the dtb will very likely be passed in the first 16k of ram
where the interrupt vectors live, memblock_reserve() is
insufficient to protect the dtb data.
[based on work originally written by Jeremy Kerr ]
Tested-by: Tony Lindgren
Signed-off-by: Grant Likely
The dtb is passed to the kernel via register r2, which is the same
method that is used to pass an atags pointer. This patch modifies
__vet_atags to not clear r2 when it encounters a dtb image.
v2: fixed bugs pointed out by Nicolas Pitre
Tested-by: Tony Lindgren
Signed-off-by: Grant Likely
v6: typo fixes
v5: clarified that dtb should be aligned on a 64 bit boundary in RAM.
v3: added details to Documentation/arm/Booting
Acked-by: Tony Lindgren
Signed-off-by: Grant Likely
---
Documentation/arm/Booting | 33 ++--
Documentation/devicetree/booting
dbg(dev, "Looking up %s-clock from device tree\n", id);
>
> snprintf(prop_name, 32, "%s-clock", id ? id : "bus");
> - prop = of_get_property(dev->of_node, prop_name, &sz);
> + of_node = dev ? dev->of_node : NULL;
> + prop
On Sat, Apr 23, 2011 at 10:30:04PM -0600, Stephen Warren wrote:
> The following workflow:
>
> make dtbs
> make dtbuImage # See my earlier patch which adds this based on
> Jeremy Kerr's patch to add a dtbImage target.
>
> ... seems to require the *.dts file to be in arch/arm/boot/
On Sat, Apr 23, 2011 at 10:30:04PM -0600, Stephen Warren wrote:
> The following workflow:
>
> make dtbs
> make dtbuImage # See my earlier patch which adds this based on
> Jeremy Kerr's patch to add a dtbImage target.
>
> ... seems to require the *.dts file to be in arch/arm/boot/
On Sat, Apr 23, 2011 at 10:30:03PM -0600, Stephen Warren wrote:
> The content of the machine descriptions has be re-organized. Without fixing
> the board-dt.c copy, the system will fail to boot (BUG_ON during timer
> initialization, which happens before printk is operational, leading to a
> silent
On Sat, Apr 23, 2011 at 10:30:02PM -0600, Stephen Warren wrote:
> tegra_common_init was removed by:
> 0cf6230af909a86f81907455eca2a5c9b8f68fe6
> ARM: tegra: Move tegra_common_init to tegra_init_early
>
> Fix the Tegra devicetree support to match.
>
> Signed-off-by: Stephen Warren
Squashed i
viour off a new compatible value for the specific i2c
mux. You just need a node for the i2c mux, and another node for each
child bus. Alternately, the mux could do what you suggest for option
b which might end up being cleaner. *HOWEVER* it is only cleaner if
the common i2c bus population code
On Thu, Apr 21, 2011 at 10:41 AM, Grant Likely
wrote:
> On Thu, Apr 7, 2011 at 8:17 AM, Chris Ball wrote:
>> Hi David,
>>
>> On Thu, Apr 07 2011, David Gilbert wrote:
>>> I'm curious; do we have any interaction with the autotest project
>>> - it seems
On Thu, Apr 7, 2011 at 8:17 AM, Chris Ball wrote:
> Hi David,
>
> On Thu, Apr 07 2011, David Gilbert wrote:
>> I'm curious; do we have any interaction with the autotest project
>> - it seems it's whole point is automated kernel testing,.
>> http://autotest.kernel.org/ and test.kernel.org
>
> test.
boot the kernel.
Make sure stuff shows up in /proc/devicetree/. Also, send me your boot log.
And that's it!
On Mon, Mar 21, 2011 at 3:25 AM, Grant Likely wrote:
> I had great hopes of doing these status reports once a week; but it
> turns out to take more effort to get together t
On Fri, Apr 01, 2011 at 03:49:16PM +0800, Shawn Guo wrote:
> On Thu, Mar 31, 2011 at 10:09:40AM -0600, Grant Likely wrote:
> > On Fri, Mar 25, 2011 at 03:13:58PM +0800, Shawn Guo wrote:
> > > After fec dt support is added, the following compile error will be
> > > seen
On Mon, Apr 4, 2011 at 8:50 AM, Nicolas Pitre wrote:
> On Mon, 4 Apr 2011, Eric Miao wrote:
>
>> >> * And very hardware specific code moved out to a controllable place,
>> >> i.e. something like BIOS
>> >
>> > Sorry, but I must vehemently disagree here. BIOSes are a problem for
>> > Open So
On Sun, Apr 3, 2011 at 11:26 AM, Jaswinder Singh
wrote:
> On 3 April 2011 21:44, Andy Green wrote:
>> On 04/03/2011 05:05 PM, Somebody in the thread at some point said:
>>
>>> Above everything else, I definitely like to see DT get done first,
>>> it's essential for SoC these days.
>>
>> All I am
On Sat, Mar 19, 2011 at 02:24:32AM +0800, Shawn Guo wrote:
> With the platform clock support, the 'struct clk' should have been
> associated with device_node->data. So the use of function
> __of_clk_get_from_provider can be eliminated.
>
> Signed-off-by: Shawn Guo
Not really true since a device
On Sat, Mar 19, 2011 at 02:24:30AM +0800, Shawn Guo wrote:
> This patch is to change the static clock creating and registering to
> the dynamic way, which scans dt clock nodes, associate clk with
> device_node, and then add them to clkdev accordingly.
>
> It's a pretty straight translation from no
On Sat, Mar 19, 2011 at 02:24:29AM +0800, Shawn Guo wrote:
> This pointer to 'struct clk' is added to save the reference to 'clk'
> which is dynamically created per dt clock node, so that clkdev API
> like clk_get can work with dt based device driver.
>
> Signed-off-by: Shawn Guo
> ---
> include
On Thu, Mar 31, 2011 at 11:41 AM, Loïc Minier wrote:
> On Fri, Apr 01, 2011, Shawn Guo wrote:
>> As the .dtb files will be naturally generated in the same kernel
>> folder as kernel image sits, why do not we ship .dtb in the same
>> folder as kernel image /boot?
Version numbers. If two kernel pa
On Thu, Mar 31, 2011 at 10:50 AM, Grant Likely
wrote:
> On Fri, Apr 01, 2011 at 12:36:16AM +0800, Shawn Guo wrote:
>> Hi Grant,
>>
>> On Wed, Mar 30, 2011 at 09:52:15PM -0600, Grant Likely wrote:
>> > On Tue, Mar 29, 2011 at 10:34:12AM +, Liu Hui-R64343 wrote:
&g
On Fri, Apr 01, 2011 at 12:36:16AM +0800, Shawn Guo wrote:
> Hi Grant,
>
> On Wed, Mar 30, 2011 at 09:52:15PM -0600, Grant Likely wrote:
> > On Tue, Mar 29, 2011 at 10:34:12AM +, Liu Hui-R64343 wrote:
> > > Hi, Grant,
> > > The two patches for mx51/mx53 DT s
On Fri, Mar 25, 2011 at 03:13:58PM +0800, Shawn Guo wrote:
> After fec dt support is added, the following compile error will be
> seen when building a pure non-dt kernel.
>
> drivers/net/fec.c: In function ‘fec_probe’:
> drivers/net/fec.c:1383: error: implicit declaration of function
> ‘of_match_
f-by: Shawn Guo
Reviewed-by: Grant Likely
Looks good to me.
> ---
> drivers/mmc/host/sdhci-cns3xxx.c |1 -
> drivers/mmc/host/sdhci-esdhc.c |1 -
> drivers/mmc/host/sdhci-pltfm.h |6 +-
> include/linux/mmc/sdhci-pltfm.h | 29 -
&g
On Fri, Mar 25, 2011 at 04:48:50PM +0800, Shawn Guo wrote:
> This patch is to consolidate SDHCI driver for Freescale eSDHC
> controller found on both MPCxxx and i.MX platforms. It turns
> sdhci-of-esdhc.c and sdhci-esdhc-imx.c into one sdhci-esdhc.c,
> which gets the same pair of .probe and .remov
On Fri, Mar 25, 2011 at 04:48:49PM +0800, Shawn Guo wrote:
> The patch turns the sdhci-of-core common stuff into helper functions
> added into sdhci-pltfm.c, and makes sdhci-of device drviers self
> registered using the same pair of .probe and .remove used by
> sdhci-pltfm device drivers.
>
> As a
On Fri, Mar 25, 2011 at 04:48:48PM +0800, Shawn Guo wrote:
> The patch is to migrate the use of sdhci_of_host and sdhci_of_data
> to sdhci_pltfm_host and sdhci_pltfm_data, so that the former pair can
> be eliminated.
>
> Signed-off-by: Shawn Guo
Reviewed-by: Grant Likely
>
elf and keep all device specific things away from common
> sdhci-pltfm file.
>
> Signed-off-by: Shawn Guo
Looks really good. Relatively minor comments below, but you can add
this to the next version:
Reviewed-by: Grant Likely
Thanks for doing this!
g.
> ---
> drivers/mmc/ho
On Mar 30, 2011 10:23 PM, "Shawn Guo" wrote:
>
> On Fri, Mar 25, 2011 at 04:48:46PM +0800, Shawn Guo wrote:
> > Here are what the patch set does.
> >
> > * Remove .probe and .remove hooks from sdhci-pltfm.c and make it be
> > a pure common helper function providers.
> > * Add .probe and .remove
On Tue, Mar 29, 2011 at 10:34:12AM +, Liu Hui-R64343 wrote:
> Hi, Grant,
> The two patches for mx51/mx53 DT support have the same issue, which
> is the S-O-B will be missed when you git am. Let me know if you want me
> re-send the two patches or you would take care when you am it? Thanks,
I f
On Mon, Mar 28, 2011 at 9:35 AM, Grant Likely wrote:
> On Mon, Mar 28, 2011 at 9:10 AM, Tixy wrote:
>> Just found a device tree bug which corrupts __machine_type.
>> In arch/arm/kernel/devtree.c at end of setup_machine_fdt()
>>
>> - __machine_arch_type = mdesc-&g
On Mon, Mar 28, 2011 at 9:10 AM, Tixy wrote:
> Just found a device tree bug which corrupts __machine_type.
> In arch/arm/kernel/devtree.c at end of setup_machine_fdt()
>
> - __machine_arch_type = mdesc->nr;
> + __machine_arch_type = mdesc_best->nr;
>
> This was stopping some Beagleboard drivers fr
for existing
> bugs in the current tree, and the rebuilt kernel is using patches
> that have and still are being tested by a wider community.
>
> - I didn't forward port a couple series of patches that are available
> in the current Linaro tree and not in mainline yet, in
[cc'ing linaro-dev mailing list; other people will probably have the
same question]
On Mon, Mar 28, 2011 at 4:40 AM, Tixy wrote:
> On Mon, 2011-03-21 at 03:25 -0600, Grant Likely wrote:
>> For each board, I need an engineer to do the following:
>>
> [...]
>
On Sat, Mar 26, 2011 at 9:33 AM, Tixy wrote:
> On Fri, 2011-03-25 at 22:46 -0600, Grant Likely wrote:
> [...]
>> It appears that when U-Boot
>> relocates the .dtb, it either moves it to a location that the kernel
>> cannot read during early boot, or it corrupts it when it
1 - 100 of 182 matches
Mail list logo
