So, like, Arnd Bergmann said:
> On Tuesday 14 April 2015 10:36:15 Rob Herring wrote:
> >
> > >4) Identifying additional people who should attend the device tree
> > > track.
> >
> > Arnd Bergmann
> > Matt Porter
> > Jon Loeliger
> > G
So, like, Chris Packham said:
> Hi,
>
> This probably should come via git://git.jdl.com/software/dtc.git however
> this appears to be inaccessible at the moment. Is this still the
> canonical source for the device tree compiler and libfdt or has it been
> moved? How much deviation from the canonic
> >>
> >> Drivers don't provide that information (dependencies) in any usable way.
> >> And
> >> as you said yourself, it's already contained in phandles. So what we are
> >> discussing here about? The proposal to use phandles for that is already on
> >> the table since several month. ;)
> >>
> >>
>
>
> > I believe some of the issues that need to be resolved are:
> >
> > 1) What constitutes a dependency?
> > 2) How is that dependency expressed?
> > 3) How do we add missing dependencies?
> > 4) Backward compatability problems.
> >
> > There are other questions, of course. I
>
> Anyway, instead of going back and forth between "deferred probe is good"
> and "deferred probe is bad", how about we do something useful now and
> concentrate on how to make use of the information we have in DT with the
> goal to reduce the number of cases where deferred probing is required?
Folks,
I have a few questions about an interrupt controller IP block
that I would like to support in an ARM SoC port.
My IP block provides software-assignable interrupts. That
is, I have a large pool of interrupt sources, and a large pool
of interrupt bits in the controller, but they are not phy
> diff --git a/arch/arm/include/asm/mach/arch.h
> b/arch/arm/include/asm/mach/arch.h
> index 060a75e..ddaebcd 100644
> --- a/arch/arm/include/asm/mach/arch.h
> +++ b/arch/arm/include/asm/mach/arch.h
> @@ -46,7 +46,8 @@ struct machine_desc {
> enum reboot_modereboot_mode;/* defa
>
> My own selfish desire is to easily separate emails for DT bindings and
> DT core code. I suppose I could do that with a suffix on my email address.
And I've had the reverse problem: Sorting out the DTC
and libfdt patches from the noise. :-)
jdl
--
To unsubscribe from this list: send the li
> > Is there a schema out there in the wild that exemplifies what you mean?
>
> Not really. The format of schemas is currently in design stage. I'm
> currently rethinking some details of what I have in my mind. Give me some
> more time and I will post an RFC to the ML with all that written down
>
> > Perhaps it is time to also place the official repo
> > of the Device Tree Compiler on git,kernel.org as well?
>
> Sounds good to me.
>
> Now that I'm no longer at IBM, and don't have the associated
> complications with their Legal department, I'd rather like to resume
> having direct commi
> On Sat, Jul 20, 2013 at 5:19 AM, Grant Likely wrote
> :
>
> > Device tree bindings require a lot more attention than they used to.
> > We've got a group of volunteers willing to take over maintaining
> > bindings. This patch adds them to the MAINTAINERS file.
> >
> > This group still needs to w
> From: Stephen Warren
>
> Previously, the #line parsing regex ended with ({WS}+[0-9]+)?. The {WS}
> could match line-break characters. If the #line directive did not contain
> the optional flags field at the end, this could cause any integer data on
> the next line to be consumed as part of the
> >
> > Line 374 is the "IDSEL 0x16..." line here:
> > interrupt-map = <
> > /* IRQ mapping for pci slots and ALI M1533
> > ...
> > * management core also isn't used.
> >
> Err,
>
> I can rework and resubmit to remove the comment, but the test doesn't =
> fail:
>
> > $ make check | grep 'MyBoardName.*-t s.*compatible'
> > fdtget-runtest.sh MyBoardName MyBoardFamilyName -t s
> > label01.dts.fdtget.test.dtb / compatible: PASS
> >
>
> As of today's pull.
My b
> Device tree can store multiple strings in a single property.
> We didn't handle that case properly.
>
> Signed-off-by: Pantelis Antoniou
Applied.
Thanks,
jdl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More m
> The method used did not account for multi-part strings.
>
> Signed-off-by: Pantelis Antoniou
Applied.
Plese consider a follow-up patch to address David's concerns.
Thanks,
jdl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vg
> Hi David
>
> =CE=91=CF=80=CF=8C =CF=84=CE=BF iPhone =CE=BC=CE=BF=CF=85
>
> 6 =CE=99=CE=B1=CE=BD 2013, 5:58, =CE=BF/=CE=B7 David Gibson opbear.id.au> =CE=AD=CE=B3=CF=81=CE=B1=CF=88=CE=B5:
>
> > On Fri, Jan 04, 2013 at 09:16:08PM +0200, Pantelis Antoniou wrote:
> >> After fixing the is_printabl
>
> What more do you think needs discussion re: dtc+cpp?
How not to abuse the ever-loving shit out of it? :-)
jdl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majord
>
> Seems dtc doesn't really have a maintainer.
Picking nits, let's be clear on that phraseology:
Seems dtc doesn't really have a maintainer
within the kernel repository.
Over in git.jdl.com land, there is a well established
maintainer for the upstream DTC.
> Probably makes more sense
e filename being compiled.
> * Many additions to the libfdt API.
>
> Signed-off-by: Stephen Warren
For what it might be worth:
Acked-by: Jon Loeliger
jdl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel
> From: Stephen Warren
>
> I'll post a patch to update the in-kernel dtc to the upstream dtc as
> soon as one final dtc patch has been applied, and this series will then
> depend on that patch.
And that patch, I think, has just been applied to the
upstream DTC repo at git.jdl.com:
commit 3
So, like, the other day Kumar Gala mumbled:
> If we add to an empty lmb region with a non-zero base we will not coalesce
> the number of regions done to one. This causes problems on ppc32 for the
s/done/down
> memory region as its assumed to only have one region.
>
> We can fix this be easily s
Sam Ravnborg wrote:
What impact do the have on boards in arch/ppc being able to build?
Byt the way what are the plans for powerpc?
We have:
arch/ppc
arch/ppc64
arch/powerpc
It was my understanding that arch/powerpc was supposed
to be the future unified powerpc architecture but it
does not even
David Woodhouse wrote:
On Fri, 2007-10-26 at 05:57 -0400, Robin Getz wrote:
Is this section still used on PPC, or can the entire support for
extratext be removed?
I think it can die.
Agreed. For history, see this:
http://ozlabs.org/pipermail/linuxppc-dev/2005-September/019734.html
and
> Adds support of IRDA transceiver residing on PowerQUICC processors and
> enabling such on mpc885ads reference board. The driver is implemented
> using of_device concept, hereby implies arch/powerpc support
> of the target.
>
> Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
> diff --git a/ar
> > - [EMAIL PROTECTED] {
> > - linux,phandle = ;
> > + pci_pic:[EMAIL PROTECTED] {
>
> I'd like to establish a convention of putting a space after the : and
> using capitals for labels unless there's a strong reason not to in a
> particular case. It makes them easi
26 matches
Mail list logo
