On Tue, May 6, 2014 at 8:27 AM, Grant Likely wrote:
> On Mon, 05 May 2014 09:06:14 +0200, Alexander Holler
> wrote:
>> Am 22.11.2013 13:00, schrieb Pantelis Antoniou:
>>
>> > As one that's going to be dealing with this, please don't take the DTS
>> > files from the kernel.
>> >
>> > If you do th
On Mon, 05 May 2014 17:29:47 +0200, Alexander Holler
wrote:
> Am 05.05.2014 16:41, schrieb Arnd Bergmann:
> > On Monday 05 May 2014 09:06:14 Alexander Holler wrote:
> >>
> >> A bit late (I don't follow the ML (or what happens in the ARM world)
> >> closely, but as I've recently read that ARM64 wi
On Mon, 05 May 2014 09:06:14 +0200, Alexander Holler
wrote:
> Am 22.11.2013 13:00, schrieb Pantelis Antoniou:
>
> > As one that's going to be dealing with this, please don't take the DTS
> > files from the kernel.
> >
> > If you do this, I can guarantee that within a year almost no ARM board
>
On Monday 05 May 2014 17:29:47 Alexander Holler wrote:
> Am 05.05.2014 16:41, schrieb Arnd Bergmann:
> > On Monday 05 May 2014 09:06:14 Alexander Holler wrote:
> >>
> >> A bit late (I don't follow the ML (or what happens in the ARM world)
> >> closely, but as I've recently read that ARM64 will go U
Am 05.05.2014 16:41, schrieb Arnd Bergmann:
On Monday 05 May 2014 09:06:14 Alexander Holler wrote:
A bit late (I don't follow the ML (or what happens in the ARM world)
closely, but as I've recently read that ARM64 will go UEFI and ACPI, I
wonder what was the reasoning behind that decision.
Doe
On Monday 05 May 2014 09:06:14 Alexander Holler wrote:
>
> A bit late (I don't follow the ML (or what happens in the ARM world)
> closely, but as I've recently read that ARM64 will go UEFI and ACPI, I
> wonder what was the reasoning behind that decision.
>
> Does anyone really assume we will be
Am 22.11.2013 13:00, schrieb Pantelis Antoniou:
As one that's going to be dealing with this, please don't take the DTS
files from the kernel.
If you do this, I can guarantee that within a year almost no ARM board using DT
will boot a mainline kernel.
The reason is that vendors have enough trou
Hi
On Nov 22, 2013, at 12:43 PM, Catalin Marinas wrote:
> On 21 November 2013 20:47, Grant Likely wrote:
>> On Thu, 21 Nov 2013 19:21:36 +, Russell King - ARM Linux
>> wrote:
>>> On Wed, Nov 20, 2013 at 07:40:57AM +0100, Richard Cochran wrote:
Now, I never saw any proclamation or disc
On 21 November 2013 20:47, Grant Likely wrote:
> On Thu, 21 Nov 2013 19:21:36 +, Russell King - ARM Linux
> wrote:
>> On Wed, Nov 20, 2013 at 07:40:57AM +0100, Richard Cochran wrote:
>> > Now, I never saw any proclamation or discussion about "DT is in flux"
>> > on the arm list. If I had, I
On Thu, 21 Nov 2013 19:21:36 +, Russell King - ARM Linux
wrote:
> On Wed, Nov 20, 2013 at 07:40:57AM +0100, Richard Cochran wrote:
> > Now, I never saw any proclamation or discussion about "DT is in flux"
> > on the arm list. If I had, I surely would have complained, and loudly.
> > AFAICT, t
On Thu, 21 Nov 2013 11:31:10 -0800, Olof Johansson wrote:
> On Thu, Nov 21, 2013 at 11:01 AM, Russell King - ARM Linux
> wrote:
> > On Thu, Nov 21, 2013 at 10:59:41AM -0800, Olof Johansson wrote:
> >> On Thu, Nov 21, 2013 at 10:54 AM, Russell King - ARM Linux
> >> wrote:
> >> > This depends what
On Thu, Nov 21, 2013 at 07:26:02PM +0100, Arnd Bergmann wrote:
> + A number of subsystems that Intel needs to handle on embedded systems
> should really not be described in detail on servers on any architecture
> but instead be handled in AML or SMBIOS (e.g. pinctrl or phy).
Are we 100% sure
On Fri, 15 Nov 2013 23:21:09 +, Russell King - ARM Linux
wrote:
> On Fri, Nov 15, 2013 at 08:56:47PM +0100, Arnd Bergmann wrote:
> > On Friday 15 November 2013, Russell King - ARM Linux wrote:
> > > On Fri, Nov 15, 2013 at 09:52:41AM -0800, Olof Johansson wrote:
> > > > If we knew exactly wha
On Thu, Nov 21, 2013 at 11:01 AM, Russell King - ARM Linux
wrote:
> On Thu, Nov 21, 2013 at 10:59:41AM -0800, Olof Johansson wrote:
>> On Thu, Nov 21, 2013 at 10:54 AM, Russell King - ARM Linux
>> wrote:
>> > This depends what you want from ACPI, and what market ACPI is being
>> > targetted at.
>
On Wed, Nov 20, 2013 at 07:40:57AM +0100, Richard Cochran wrote:
> Now, I never saw any proclamation or discussion about "DT is in flux"
> on the arm list. If I had, I surely would have complained, and loudly.
> AFAICT, this decision was made in rather private circles, but you talk
> as if this was
On Tue, 19 Nov 2013 10:19:59 -0800, Olof Johansson wrote:
> I think we're getting bogged down by the hypothetical AML-in-DT case. We won't
> know if we want/need it until we see what kind of stuff vendors think they
> will
> need to do in AML. On x86 it's mostly used to abstract out per-board
> d
On Thu, Nov 21, 2013 at 10:59:41AM -0800, Olof Johansson wrote:
> On Thu, Nov 21, 2013 at 10:54 AM, Russell King - ARM Linux
> wrote:
> > This depends what you want from ACPI, and what market ACPI is being
> > targetted at.
>
> We're talking ACPI on servers here.
Now read the rest of my email, t
On Thu, Nov 21, 2013 at 10:54 AM, Russell King - ARM Linux
wrote:
> On Thu, Nov 21, 2013 at 09:58:22AM -0800, Olof Johansson wrote:
>> On Thu, Nov 21, 2013 at 04:29:44PM +, Grant Likely wrote:
>> > We are pushing a lot of boundaries and doing things on ACPI that have
>> > never been done befor
On Tue, 19 Nov 2013 11:30:15 +, Mark Rutland wrote:
> On Fri, Nov 15, 2013 at 05:52:41PM +, Olof Johansson wrote: > > On Fri,
> Nov 15, 2013 at 09:57:17AM +, Mark Rutland wrote:
> > > On Fri, Nov 15, 2013 at 01:44:10AM +, Olof Johansson wrote:
> The UEFI spec pulls in portions of
On Thu, Nov 21, 2013 at 09:58:22AM -0800, Olof Johansson wrote:
> On Thu, Nov 21, 2013 at 04:29:44PM +, Grant Likely wrote:
> > We are pushing a lot of boundaries and doing things on ACPI that have
> > never been done before. SPI, GPIOs, Clocks, Regulators, composite
> > devices, key-value prop
On Thu, Nov 21, 2013 at 04:29:44PM +, Grant Likely wrote:
> We are pushing a lot of boundaries and doing things on ACPI that have
> never been done before. SPI, GPIOs, Clocks, Regulators, composite
> devices, key-value properties. All brand new territory, and the Linux
> world is driving a lot
On Thu, Nov 21, 2013 at 04:29:44PM +, Grant Likely wrote:
> On Tue, 19 Nov 2013 11:30:15 +, Mark Rutland wrote:
> > On Fri, Nov 15, 2013 at 05:52:41PM +, Olof Johansson wrote: > > On Fri,
> > Nov 15, 2013 at 09:57:17AM +, Mark Rutland wrote:
> > > > On Fri, Nov 15, 2013 at 01:44:1
On Thu, 21 Nov 2013 17:01:22 +, Matthew Garrett wrote:
> On Thu, Nov 21, 2013 at 04:29:44PM +, Grant Likely wrote:
>
> > Personally, I think the issue of ACPI support should be taken on a
> > patch-by-patch basis. A lot of the things that need to be done are quite
> > discrete and fairly
On Mon, 18 Nov 2013 15:19:01 +, Russell King - ARM Linux
wrote:
> They are using strings which are the same as the DT properties, but
> without the vendor prefix - but yes, to only retrieve things like
> booleans, u32s and such like. They also have support for fixed-rate
> clocks via the clk
On Mon, 18 Nov 2013 16:05:37 +0100, Arnd Bergmann wrote:
> On Saturday 16 November 2013, Russell King - ARM Linux wrote:
> > On Fri, Nov 15, 2013 at 08:56:47PM +0100, Arnd Bergmann wrote:
> > >
> > > For all I know, doing this in ACPI is something that is only now being
> > > discussed as Intel w
On Thursday 21 November 2013, Olof Johansson wrote:
> On Thu, Nov 21, 2013 at 04:29:44PM +, Grant Likely wrote:
>
> > We are pushing a lot of boundaries and doing things on ACPI that have
> > never been done before. SPI, GPIOs, Clocks, Regulators, composite
> > devices, key-value properties. Al
On Thursday 21 November 2013, Grant Likely wrote:
> This too should look transparent to device drivers. DT and ACPI have
> different mechanism for doing cross tree references, but the concept is
> the same. A driver calling something like "platform_get_my_gpio_resource()"
> should do the right thin
On Thu, Nov 21, 2013 at 09:58:22AM -0800, Olof Johansson wrote:
> On Thu, Nov 21, 2013 at 04:29:44PM +, Grant Likely wrote:
> > We are pushing a lot of boundaries and doing things on ACPI that have
> > never been done before. SPI, GPIOs, Clocks, Regulators, composite
> > devices, key-value prop
On Thu, Nov 21, 2013 at 04:29:44PM +, Grant Likely wrote:
> Personally, I think the issue of ACPI support should be taken on a
> patch-by-patch basis. A lot of the things that need to be done are quite
> discrete and fairly well contained. If the patches don't look that way
> then push back on
On Wed, 20 Nov 2013 07:40:57 +0100, Richard Cochran
wrote:
> On Tue, Nov 19, 2013 at 10:48:27AM -0800, Olof Johansson wrote:
> >
> > This is just a tangent and a distraction anyway: You should know by
> > now that we've decided to keep backwards compatibility going forward,
> > so any argument a
On Wed, 20 Nov 2013, Grant Likely wrote:
> On Fri, 15 Nov 2013 09:57:17 +, Mark Rutland wrote:
> > On Fri, Nov 15, 2013 at 01:44:10AM +, Olof Johansson wrote:
> > > The more I start to see early UEFI/ACPI code, the more I am certain
> > > that we want none of that crap in the kernel. It's
On Wed, Nov 20, 2013 at 9:43 AM, Stefano Stabellini
wrote:
> On Wed, 20 Nov 2013, Grant Likely wrote:
>> On Fri, 15 Nov 2013 09:57:17 +, Mark Rutland
>> wrote:
>> > On Fri, Nov 15, 2013 at 01:44:10AM +, Olof Johansson wrote:
>> > > The more I start to see early UEFI/ACPI code, the more I
On Fri, 15 Nov 2013 09:57:17 +, Mark Rutland wrote:
> On Fri, Nov 15, 2013 at 01:44:10AM +, Olof Johansson wrote:
> > The more I start to see early UEFI/ACPI code, the more I am certain
> > that we want none of that crap in the kernel. It's making things
> > considerably messier, while we'
On Tue, Nov 19, 2013 at 10:48:27AM -0800, Olof Johansson wrote:
>
> This is just a tangent and a distraction anyway: You should know by
> now that we've decided to keep backwards compatibility going forward,
> so any argument about why we did it differently before is leading nowhere.
Yes, I know
On Tue, Nov 19, 2013 at 03:21:57PM +, Mark Rutland wrote:
[snip]
> I think that with ACPI systems the data we would have to convert is
> going to be larger and more varied than that. Given we already have code
> in the kernel for handling ACPI, I believe it would be more valuable to
> leverage
[Adding Grant]
On Tue, Nov 19, 2013 at 10:12:17AM +0100, Richard Cochran wrote:
> On Mon, Nov 18, 2013 at 11:13:36AM -0800, Olof Johansson wrote:
> >
> > I know people have been frustrated that they need to keep the DT in sync
> > with
> > the kernel. But we've always been upfront with the requi
On Tue, Nov 19, 2013 at 03:21:57PM +, Mark Rutland wrote:
> On Tue, Nov 19, 2013 at 02:05:33PM +, Arnd Bergmann wrote:
> > On Tuesday 19 November 2013, Mark Rutland wrote:
> > > On Fri, Nov 15, 2013 at 05:52:41PM +, Olof Johansson wrote:
> > > > On Fri, Nov 15, 2013 at 09:57:17AM +,
On Tue, Nov 19, 2013 at 02:38:40PM +, Mark Rutland wrote:
> On Tue, Nov 19, 2013 at 01:56:26PM +, Stefano Stabellini wrote:
> > I would not go as far as requiring that only one is available.
> > Certainly I would mandate that either of them are independently complete
> > and sufficient to
On Tue, Nov 19, 2013 at 11:30:15AM +, Mark Rutland wrote:
> On Fri, Nov 15, 2013 at 05:52:41PM +, Olof Johansson wrote:
> > On Fri, Nov 15, 2013 at 09:57:17AM +, Mark Rutland wrote:
> > > On Fri, Nov 15, 2013 at 01:44:10AM +, Olof Johansson wrote:
> > > > The more I start to see ear
On Tuesday 19 November 2013, Mark Rutland wrote:
> On Tue, Nov 19, 2013 at 02:05:33PM +, Arnd Bergmann wrote:
> > > As mentioned above, I think that the work to do this is going to end up
> > > as a weird ARM-specific legacy feature. We will get something wrong here
> > > in a way that we have
On Tue, Nov 19, 2013 at 02:05:33PM +, Arnd Bergmann wrote:
> On Tuesday 19 November 2013, Mark Rutland wrote:
> > On Fri, Nov 15, 2013 at 05:52:41PM +, Olof Johansson wrote:
> > > On Fri, Nov 15, 2013 at 09:57:17AM +, Mark Rutland wrote:
>
> > > Oh wait, there's people who have been do
On Tue, Nov 19, 2013 at 02:38:40PM +, Mark Rutland wrote:
> > > For that case we will also require a nailed-down boot
> > > protocol that allows for either DTB or ACPI.
> >
> > The latest documentation patch for the "arm/arm64 UEFI boot protocol"
> > implies that UEFI on ARM is already capable
On Tue, Nov 19, 2013 at 01:56:26PM +, Stefano Stabellini wrote:
> On Tue, 19 Nov 2013, Mark Rutland wrote:
> > > We all know DT considerably better to a point where I would recommend
> > > that they flash a DTB in their UEFI firmware instead of go with ACPI. For
> > > simple hardware and basic
On Tuesday 19 November 2013, Mark Rutland wrote:
> On Fri, Nov 15, 2013 at 05:52:41PM +, Olof Johansson wrote:
> > On Fri, Nov 15, 2013 at 09:57:17AM +, Mark Rutland wrote:
> > Oh wait, there's people who have been doing this for years. Microsoft. They
> > should be the ones driving this a
On Tue, 19 Nov 2013, Mark Rutland wrote:
> > We all know DT considerably better to a point where I would recommend
> > that they flash a DTB in their UEFI firmware instead of go with ACPI. For
> > simple hardware and basic devices we've got most bindings sorted out by
> > now, and we've decided on
On Monday 18 November 2013, David Goodenough wrote:
> Would it not be possible to have ACPI read the hardware configuration
> from the DT, and provide whatever services it wants, while also allowing
> the kernel to retain the DT for its hardware config? I suppose the only
> thing that would be nee
On Tue, Nov 19, 2013 at 11:30:15AM +, Mark Rutland wrote:
> I'm not sure it's entirely reasonable to assume that Microsoft will
> swoop in and develop standards that are useful to us or even applicable
> to the vast majority of the systems that are likely to exist.
It's not in their interest t
On Tue, Nov 19, 2013 at 11:35:57AM +, Mark Rutland wrote:
> > The UEFI spec pulls in portions of ACPI. I do not know the full extent
> > of the interaction between the two, but I know that they are not
> > completely decoupled. As you have pointed out we are not experienced
> > with ACPI or UEF
Hi,
> > > That
> > > sounds like an arcane board file equivalent, and is counter to the
> > > entire reason for using UEFI and ACPI -- having a well-defined
> > > (excluding particular driver bindings, and I'm not arguing well-defined
> > > means nice) stable standard that allows the kernel to boo
On Fri, Nov 15, 2013 at 05:52:41PM +, Olof Johansson wrote:
> On Fri, Nov 15, 2013 at 09:57:17AM +, Mark Rutland wrote:
> > On Fri, Nov 15, 2013 at 01:44:10AM +, Olof Johansson wrote:
> > > The more I start to see early UEFI/ACPI code, the more I am certain
> > > that we want none of th
On Mon, Nov 18, 2013 at 11:13:36AM -0800, Olof Johansson wrote:
>
> I know people have been frustrated that they need to keep the DT in sync with
> the kernel. But we've always been upfront with the requirement, and why we've
> been having it. We're now changing this requirement, which should help
Hej,
On Mon, Nov 18, 2013 at 03:29:58PM -0800, Olof Johansson wrote:
> >> The server guys really want UEFI for their boot protocols,
> >> installation managers, etc, etc. That's fine, let them do that, but
> >> that doesn't mean we need to bring the same APIs all the way into the
> >> kernel.
> >
Hej,
On Mon, Nov 18, 2013 at 3:25 PM, Leif Lindholm wrote:
> Hi Olof,
>
> Just in case this thread fails to reach its predicted triple-digits, I
> would like to revisit something you mentioned in this original email
> and then didn't expand on.
>
> On Thu, Nov 14, 2013 at 05:44:10PM -0800, Olof J
Hi Olof,
Just in case this thread fails to reach its predicted triple-digits, I
would like to revisit something you mentioned in this original email
and then didn't expand on.
On Thu, Nov 14, 2013 at 05:44:10PM -0800, Olof Johansson wrote:
> The more I start to see early UEFI/ACPI code, the more
Hi,
On Mon, Nov 18, 2013 at 03:54:56PM -0500, Jon Masters wrote:
> Hi Olof,
>
> On 11/18/2013 02:09 PM, Olof Johansson wrote:
> > Jon,
> >
> > On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote:
> >> Olof, thanks for starting this thread. Mark, thanks for the followup.
> >
> > Your mai
On Mon, 18 Nov 2013 16:10:32 +0100, Arnd Bergmann wrote:
> On Monday 18 November 2013, Mark Brown wrote:
> > On Sun, Nov 17, 2013 at 07:10:51PM +0100, Arnd Bergmann wrote:
> > > On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote:
> >
> > > > Simply using DT would help avoiding the awkwa
On Mon, 18 Nov 2013 11:09:29 -0800, Olof Johansson wrote:
> On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote:
>
> I'm looking at the quality of the initial submissions (very poor and
> confused), the readiness of the kernel in general (none so far),
> the way the involved parties are d
On Mon, Nov 18, 2013 at 12:43 PM, Jon Masters wrote:
> On 11/18/2013 02:25 PM, Olof Johansson wrote:
>> On Mon, Nov 18, 2013 at 12:26:11AM -0500, Jon Masters wrote:
>>> On 11/18/2013 12:19 AM, Jon Masters wrote:
>>>
It's going to be a messy thing to even attempt. Look, I wish we had a
ti
Hi Olof,
On 11/18/2013 02:09 PM, Olof Johansson wrote:
> Jon,
>
> On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote:
>> Olof, thanks for starting this thread. Mark, thanks for the followup.
>
> Your mailer is dropping all ccs to your emails, so I didn't get a copy of this
> in my inbox
On 11/18/2013 02:25 PM, Olof Johansson wrote:
> On Mon, Nov 18, 2013 at 12:26:11AM -0500, Jon Masters wrote:
>> On 11/18/2013 12:19 AM, Jon Masters wrote:
>>
>>> It's going to be a messy thing to even attempt. Look, I wish we had a
>>> time machine and could have done this whole thing years ago, bu
On Mon, Nov 18, 2013 at 12:26:11AM -0500, Jon Masters wrote:
> On 11/18/2013 12:19 AM, Jon Masters wrote:
>
> > It's going to be a messy thing to even attempt. Look, I wish we had a
> > time machine and could have done this whole thing years ago, but I'm not
> > sure it would have gone differently
On Mon, Nov 18, 2013 at 12:33:19PM -0500, Jon Masters wrote:
> On 11/18/2013 03:45 AM, Arnd Bergmann wrote:
> > On Sunday 17 November 2013, Olof Johansson wrote:
>
> >> Yep, and together for review is a critical part. I'm not saying that
> >> the ideal solution is a flashed DTB, but it's better th
[adding back devicetree@vger.kernel.org]
On Mon, Nov 18, 2013 at 03:00:52PM +, Mark Brown wrote:
> On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote:
>
> > has an API enshrined in stone as far as compatibility. Device Tree is
> > wonderful, anyone can make a binding and use it. Or c
Jon,
On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote:
> Olof, thanks for starting this thread. Mark, thanks for the followup.
Your mailer is dropping all ccs to your emails, so I didn't get a copy of this
in my inbox. You might want to check the configuration at your end.
I've added
On Nov 15, 2013, at 12:52 PM, Olof Johansson wrote:
> On Fri, Nov 15, 2013 at 09:57:17AM +, Mark Rutland wrote:
>> On Fri, Nov 15, 2013 at 01:44:10AM +, Olof Johansson wrote:
>>> The more I start to see early UEFI/ACPI code, the more I am certain
>>> that we want none of that crap in the
On Monday 18 November 2013, Russell King - ARM Linux wrote:
> > Can you point to specific patches?
>
> No, because they weren't publically posted, so I don't feel that I can
> say all that much; they were from quite a large company though.
I see.
> > I can't say I'm an expert on this, but everyt
On Mon, Nov 18, 2013 at 04:05:37PM +0100, Arnd Bergmann wrote:
> On Saturday 16 November 2013, Russell King - ARM Linux wrote:
> > On Fri, Nov 15, 2013 at 08:56:47PM +0100, Arnd Bergmann wrote:
> > >
> > > For all I know, doing this in ACPI is something that is only now being
> > > discussed as In
On Monday 18 November 2013, Mark Brown wrote:
> On Sun, Nov 17, 2013 at 07:10:51PM +0100, Arnd Bergmann wrote:
> > On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote:
>
> > > Simply using DT would help avoiding the awkward situation where a driver
> > > of a device only works with one of
On Saturday 16 November 2013, Russell King - ARM Linux wrote:
> On Fri, Nov 15, 2013 at 08:56:47PM +0100, Arnd Bergmann wrote:
> >
> > For all I know, doing this in ACPI is something that is only now being
> > discussed as Intel wants to be able to reuse the existing features from
> > DT enabled d
On Sun, Nov 17, 2013 at 07:10:51PM +0100, Arnd Bergmann wrote:
> On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote:
> > Simply using DT would help avoiding the awkward situation where a driver
> > of a device only works with one of the two description formats and not
> > the other.
> Y
On Sunday 17 November 2013, Olof Johansson wrote:
> On Sun, Nov 17, 2013 at 10:10 AM, Arnd Bergmann wrote:
> > On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote:
> >
> > My point was not that everything would be good if we change the kernel
> > this way, it clearly wouldn't. I think the
On Sun, Nov 17, 2013 at 10:10 AM, Arnd Bergmann wrote:
> On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote:
>> On Fri, 15 Nov 2013, Olof Johansson wrote:
>> > On Fri, Nov 15, 2013 at 12:58 PM, Arnd Bergmann wrote:
>> > > On Friday 15 November 2013, Olof Johansson wrote:
>> > >> So, I'm
On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote:
> On Fri, 15 Nov 2013, Olof Johansson wrote:
> > On Fri, Nov 15, 2013 at 12:58 PM, Arnd Bergmann wrote:
> > > On Friday 15 November 2013, Olof Johansson wrote:
> > >> So, I'm strongly urging that whatever the server guys try to do, it
>
On Fri, 15 Nov 2013, Olof Johansson wrote:
> On Fri, Nov 15, 2013 at 12:58 PM, Arnd Bergmann wrote:
> > On Friday 15 November 2013, Olof Johansson wrote:
> >> So, I'm strongly urging that whatever the server guys try to do, it
> >> will in the end result in the ACPI data being translated into DT
>
On Fri, Nov 15, 2013 at 08:56:47PM +0100, Arnd Bergmann wrote:
> On Friday 15 November 2013, Russell King - ARM Linux wrote:
> > On Fri, Nov 15, 2013 at 09:52:41AM -0800, Olof Johansson wrote:
> > > If we knew exactly what we wanted, it'd be a different story. _We
> > > don't_. We're into year FOUR
On Fri, Nov 15, 2013 at 12:58 PM, Arnd Bergmann wrote:
> On Friday 15 November 2013, Olof Johansson wrote:
>> So, I'm strongly urging that whatever the server guys try to do, it
>> will in the end result in the ACPI data being translated into DT
>> equivalents, such that the kernel only needs to h
On Friday 15 November 2013, Olof Johansson wrote:
> So, I'm strongly urging that whatever the server guys try to do, it
> will in the end result in the ACPI data being translated into DT
> equivalents, such that the kernel only needs to handle data via DT.
I don't think that a translation layer is
On Friday 15 November 2013, Russell King - ARM Linux wrote:
> On Fri, Nov 15, 2013 at 09:52:41AM -0800, Olof Johansson wrote:
> > If we knew exactly what we wanted, it'd be a different story. _We
> > don't_. We're into year FOUR of the device tree conversion and we're just
> > now reaching a point
On Friday 15 November 2013, Jason Gunthorpe wrote:
>
> On Fri, Nov 15, 2013 at 09:57:17AM +, Mark Rutland wrote:
>
> > first-class citizen. We don't need to modify every driver and subsystem
> > to support ACPI, only those necessary to support the minimal set of
> > platforms using ACPI. ACPI
On Fri, Nov 15, 2013 at 10:08 AM, Russell King - ARM Linux
wrote:
> On Fri, Nov 15, 2013 at 09:52:41AM -0800, Olof Johansson wrote:
>> If we knew exactly what we wanted, it'd be a different story. _We
>> don't_. We're into year FOUR of the device tree conversion and we're just
>> now reaching a po
On Fri, Nov 15, 2013 at 09:57:17AM +, Mark Rutland wrote:
> first-class citizen. We don't need to modify every driver and subsystem
> to support ACPI, only those necessary to support the minimal set of
> platforms using ACPI. ACPI is new in the arm space, and we can enforce
> quality standards
On Fri, Nov 15, 2013 at 09:52:41AM -0800, Olof Johansson wrote:
> If we knew exactly what we wanted, it'd be a different story. _We
> don't_. We're into year FOUR of the device tree conversion and we're just
> now reaching a point where we think we know what a good solution looks
> like. The first
On Fri, Nov 15, 2013 at 09:57:17AM +, Mark Rutland wrote:
> On Fri, Nov 15, 2013 at 01:44:10AM +, Olof Johansson wrote:
> > The more I start to see early UEFI/ACPI code, the more I am certain
> > that we want none of that crap in the kernel. It's making things
> > considerably messier, whil
On Fri, Nov 15, 2013 at 01:44:10AM +, Olof Johansson wrote:
> The more I start to see early UEFI/ACPI code, the more I am certain
> that we want none of that crap in the kernel. It's making things
> considerably messier, while we're already very busy trying to convert
> everything over and enab
The more I start to see early UEFI/ACPI code, the more I am certain
that we want none of that crap in the kernel. It's making things
considerably messier, while we're already very busy trying to convert
everything over and enable DT -- we'll be preempting that effort just
to add even more boilerpla
85 matches
Mail list logo
