On Tue, Dec 17, 2013 at 11:29:14AM +, Catalin Marinas wrote:
> - What if two hw vendors have different descriptors for the same device?
This one at least is already handled - ACPI ID tables are lists of IDs
just the same as everything else so we can have as many different
bindings for the
On Tue, Dec 17, 2013 at 11:29:14AM +, Catalin Marinas wrote:
- What if two hw vendors have different descriptors for the same device?
This one at least is already handled - ACPI ID tables are lists of IDs
just the same as everything else so we can have as many different
bindings for the
On Thu, Dec 19, 2013 at 02:01:26PM +, Arnd Bergmann wrote:
> On Thursday 19 December 2013, Graeme Gregory wrote:
> > Hopefully the documenation of what real armv8 server architecture will look
> > like will come in the new year. Things like regulators and clocks I do not
> > have answers to
On Thursday 19 December 2013, Graeme Gregory wrote:
> Hopefully the documenation of what real armv8 server architecture will look
> like will come in the new year. Things like regulators and clocks I do not
> have answers to yet as obviously in Intel world these things are hidden
> from view, I do
On Tue, Dec 17, 2013 at 11:29:14AM +, Catalin Marinas wrote:
> Hi Graeme,
>
> On Mon, Dec 16, 2013 at 08:51:33PM +, Graeme Gregory wrote:
> > So the real question now is how do we progress with these ACPI patches?
> > After
> > repeated incorrect accusations of developing behind closed
On Tue, Dec 17, 2013 at 11:29:14AM +, Catalin Marinas wrote:
Hi Graeme,
On Mon, Dec 16, 2013 at 08:51:33PM +, Graeme Gregory wrote:
So the real question now is how do we progress with these ACPI patches?
After
repeated incorrect accusations of developing behind closed doors I am
On Thursday 19 December 2013, Graeme Gregory wrote:
Hopefully the documenation of what real armv8 server architecture will look
like will come in the new year. Things like regulators and clocks I do not
have answers to yet as obviously in Intel world these things are hidden
from view, I do not
On Thu, Dec 19, 2013 at 02:01:26PM +, Arnd Bergmann wrote:
On Thursday 19 December 2013, Graeme Gregory wrote:
Hopefully the documenation of what real armv8 server architecture will look
like will come in the new year. Things like regulators and clocks I do not
have answers to yet as
Hi Graeme,
On Mon, Dec 16, 2013 at 08:51:33PM +, Graeme Gregory wrote:
> So the real question now is how do we progress with these ACPI patches? After
> repeated incorrect accusations of developing behind closed doors I am loath
> to dissapear back into linaro with them for another few
Hi Graeme,
On Mon, Dec 16, 2013 at 08:51:33PM +, Graeme Gregory wrote:
So the real question now is how do we progress with these ACPI patches? After
repeated incorrect accusations of developing behind closed doors I am loath
to dissapear back into linaro with them for another few months.
On Mon, Dec 09, 2013 at 06:01:55PM +, Catalin Marinas wrote:
> On Mon, Dec 09, 2013 at 05:20:22PM +, Arnd Bergmann wrote:
> > On Monday 09 December 2013, Catalin Marinas wrote:
> > > CONFIG_PCI does not exist on arm64 yet (we have some internal patches
> > > but may not be ready to be
On Mon, Dec 09, 2013 at 06:01:55PM +, Catalin Marinas wrote:
On Mon, Dec 09, 2013 at 05:20:22PM +, Arnd Bergmann wrote:
On Monday 09 December 2013, Catalin Marinas wrote:
CONFIG_PCI does not exist on arm64 yet (we have some internal patches
but may not be ready to be posted before
On Wed, Dec 11, 2013 at 04:07:27AM +0100, Arnd Bergmann wrote:
> On Tuesday 10 December 2013, Mark Brown wrote:
> > That's not my experience especially once you get into phone type
> > hardware - there's not much complexity difference when gluing things
> > into the system and the fact that it's
On Wed, Dec 11, 2013 at 04:07:27AM +0100, Arnd Bergmann wrote:
On Tuesday 10 December 2013, Mark Brown wrote:
That's not my experience especially once you get into phone type
hardware - there's not much complexity difference when gluing things
into the system and the fact that it's
On Tuesday 10 December 2013, Mark Brown wrote:
> On Tue, Dec 10, 2013 at 09:00:20PM +0100, Arnd Bergmann wrote:
> > On Tuesday 10 December 2013, Mark Brown wrote:
>
> > > It's not just the SoC, it's also the rest of the board. The patches the
> > > Intel guys are submitting at the minute are
On Tue, Dec 10, 2013 at 09:00:20PM +0100, Arnd Bergmann wrote:
> On Tuesday 10 December 2013, Mark Brown wrote:
> > It's not just the SoC, it's also the rest of the board. The patches the
> > Intel guys are submitting at the minute are mainly for the off-SoC
> > devices at least as far as I
On Tuesday 10 December 2013, Mark Brown wrote:
> On Tue, Dec 10, 2013 at 04:28:52AM +0100, Arnd Bergmann wrote:
> > On Monday 09 December 2013, Matthew Garrett wrote:
>
> > > People are trying to deploy ACPI-based embedded x86, and most of the
> > > ACPI/DT integration discussion seems to have
On Tue, Dec 10, 2013 at 04:28:52AM +0100, Arnd Bergmann wrote:
> On Monday 09 December 2013, Matthew Garrett wrote:
> > People are trying to deploy ACPI-based embedded x86, and most of the
> > ACPI/DT integration discussion seems to have been based on the idea that
> > this is a worthwhile
On Mon, Dec 9, 2013 at 6:06 PM, Matthew Garrett wrote:
> On Mon, Dec 09, 2013 at 05:35:04PM +0100, Arnd Bergmann wrote:
>
>> Exactly. In particular we don't want people to get the wrong idea about
>> where we are heading, so making it possible to use this code on embedded
>> systems for me is a
On Tue, Dec 10, 2013 at 04:28:52AM +0100, Arnd Bergmann wrote:
On Monday 09 December 2013, Matthew Garrett wrote:
People are trying to deploy ACPI-based embedded x86, and most of the
ACPI/DT integration discussion seems to have been based on the idea that
this is a worthwhile thing to
On Tuesday 10 December 2013, Mark Brown wrote:
On Tue, Dec 10, 2013 at 04:28:52AM +0100, Arnd Bergmann wrote:
On Monday 09 December 2013, Matthew Garrett wrote:
People are trying to deploy ACPI-based embedded x86, and most of the
ACPI/DT integration discussion seems to have been based
On Tue, Dec 10, 2013 at 09:00:20PM +0100, Arnd Bergmann wrote:
On Tuesday 10 December 2013, Mark Brown wrote:
It's not just the SoC, it's also the rest of the board. The patches the
Intel guys are submitting at the minute are mainly for the off-SoC
devices at least as far as I noticed.
On Tuesday 10 December 2013, Mark Brown wrote:
On Tue, Dec 10, 2013 at 09:00:20PM +0100, Arnd Bergmann wrote:
On Tuesday 10 December 2013, Mark Brown wrote:
It's not just the SoC, it's also the rest of the board. The patches the
Intel guys are submitting at the minute are mainly for
On Mon, Dec 9, 2013 at 6:06 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
On Mon, Dec 09, 2013 at 05:35:04PM +0100, Arnd Bergmann wrote:
Exactly. In particular we don't want people to get the wrong idea about
where we are heading, so making it possible to use this code on embedded
systems
On Monday 09 December 2013, Matthew Garrett wrote:
>
> On Mon, Dec 09, 2013 at 05:35:04PM +0100, Arnd Bergmann wrote:
>
> > Exactly. In particular we don't want people to get the wrong idea about
> > where we are heading, so making it possible to use this code on embedded
> > systems for me is a
On 2013-12-10 0:55, Catalin Marinas wrote:
> On Mon, Dec 09, 2013 at 04:35:04PM +, Arnd Bergmann wrote:
>> On Monday 09 December 2013, Hanjun Guo wrote:
>>> On 2013-12-9 19:50, Catalin Marinas wrote:
On Mon, Dec 09, 2013 at 04:12:24AM +, Hanjun Guo wrote:
>
> I think the
On 2013-12-10 1:06, Matthew Garrett wrote:
> On Mon, Dec 09, 2013 at 05:35:04PM +0100, Arnd Bergmann wrote:
>
>> Exactly. In particular we don't want people to get the wrong idea about
>> where we are heading, so making it possible to use this code on embedded
>> systems for me is a reason *not*
On Thu, Dec 5, 2013 at 4:04 PM, Arnd Bergmann wrote:
> On Wednesday 04 December 2013, Hanjun Guo wrote:
>> On 2013年12月04日 00:41, Matthew Garrett wrote:
>> > Given the number of #ifdefs you're adding, wouldn't it make more sense
>> > to just add stub functions to include/linux/pci.h?
>>
>> Thanks
On Mon, Dec 09, 2013 at 05:20:22PM +, Arnd Bergmann wrote:
> On Monday 09 December 2013, Catalin Marinas wrote:
> > CONFIG_PCI does not exist on arm64 yet (we have some internal patches
> > but may not be ready to be posted before the holidays; they try to share
> > code with other archs, so
On Monday 09 December 2013, Catalin Marinas wrote:
> CONFIG_PCI does not exist on arm64 yet (we have some internal patches
> but may not be ready to be posted before the holidays; they try to share
> code with other archs, so more discussions before merging). We could add
> CONFIG_PCI and some
On Mon, Dec 09, 2013 at 05:35:04PM +0100, Arnd Bergmann wrote:
> Exactly. In particular we don't want people to get the wrong idea about
> where we are heading, so making it possible to use this code on embedded
> systems for me is a reason *not* to take the patch.
People are trying to deploy
On Mon, Dec 09, 2013 at 04:35:04PM +, Arnd Bergmann wrote:
> On Monday 09 December 2013, Hanjun Guo wrote:
> > On 2013-12-9 19:50, Catalin Marinas wrote:
> > > On Mon, Dec 09, 2013 at 04:12:24AM +, Hanjun Guo wrote:
> > >>
> > >> I think the concern here is that ACPI is only for server
On Monday 09 December 2013, Hanjun Guo wrote:
> On 2013-12-9 19:50, Catalin Marinas wrote:
> > On Mon, Dec 09, 2013 at 04:12:24AM +, Hanjun Guo wrote:
> >>
> >> I think the concern here is that ACPI is only for server platform or not.
> >>
> >> Since ACPI has lots of content related to power
On 2013-12-9 19:50, Catalin Marinas wrote:
> On Mon, Dec 09, 2013 at 04:12:24AM +, Hanjun Guo wrote:
>> On 2013-12-7 1:23, Arnd Bergmann wrote:
>>> On Friday 06 December 2013, Tomasz Nowicki wrote:
On 05.12.2013 23:04, Arnd Bergmann wrote:
> On Wednesday 04 December 2013, Hanjun Guo
On Mon, Dec 09, 2013 at 04:12:24AM +, Hanjun Guo wrote:
> On 2013-12-7 1:23, Arnd Bergmann wrote:
> > On Friday 06 December 2013, Tomasz Nowicki wrote:
> >> On 05.12.2013 23:04, Arnd Bergmann wrote:
> >>> On Wednesday 04 December 2013, Hanjun Guo wrote:
> On 2013年12月04日 00:41, Matthew
On Mon, Dec 09, 2013 at 04:12:24AM +, Hanjun Guo wrote:
On 2013-12-7 1:23, Arnd Bergmann wrote:
On Friday 06 December 2013, Tomasz Nowicki wrote:
On 05.12.2013 23:04, Arnd Bergmann wrote:
On Wednesday 04 December 2013, Hanjun Guo wrote:
On 2013年12月04日 00:41, Matthew Garrett wrote:
On 2013-12-9 19:50, Catalin Marinas wrote:
On Mon, Dec 09, 2013 at 04:12:24AM +, Hanjun Guo wrote:
On 2013-12-7 1:23, Arnd Bergmann wrote:
On Friday 06 December 2013, Tomasz Nowicki wrote:
On 05.12.2013 23:04, Arnd Bergmann wrote:
On Wednesday 04 December 2013, Hanjun Guo wrote:
On
On Monday 09 December 2013, Hanjun Guo wrote:
On 2013-12-9 19:50, Catalin Marinas wrote:
On Mon, Dec 09, 2013 at 04:12:24AM +, Hanjun Guo wrote:
I think the concern here is that ACPI is only for server platform or not.
Since ACPI has lots of content related to power management, I
On Mon, Dec 09, 2013 at 04:35:04PM +, Arnd Bergmann wrote:
On Monday 09 December 2013, Hanjun Guo wrote:
On 2013-12-9 19:50, Catalin Marinas wrote:
On Mon, Dec 09, 2013 at 04:12:24AM +, Hanjun Guo wrote:
I think the concern here is that ACPI is only for server platform or not.
On Mon, Dec 09, 2013 at 05:35:04PM +0100, Arnd Bergmann wrote:
Exactly. In particular we don't want people to get the wrong idea about
where we are heading, so making it possible to use this code on embedded
systems for me is a reason *not* to take the patch.
People are trying to deploy
On Monday 09 December 2013, Catalin Marinas wrote:
CONFIG_PCI does not exist on arm64 yet (we have some internal patches
but may not be ready to be posted before the holidays; they try to share
code with other archs, so more discussions before merging). We could add
CONFIG_PCI and some dummy
On Mon, Dec 09, 2013 at 05:20:22PM +, Arnd Bergmann wrote:
On Monday 09 December 2013, Catalin Marinas wrote:
CONFIG_PCI does not exist on arm64 yet (we have some internal patches
but may not be ready to be posted before the holidays; they try to share
code with other archs, so more
On Thu, Dec 5, 2013 at 4:04 PM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 04 December 2013, Hanjun Guo wrote:
On 2013年12月04日 00:41, Matthew Garrett wrote:
Given the number of #ifdefs you're adding, wouldn't it make more sense
to just add stub functions to include/linux/pci.h?
Thanks
On 2013-12-10 1:06, Matthew Garrett wrote:
On Mon, Dec 09, 2013 at 05:35:04PM +0100, Arnd Bergmann wrote:
Exactly. In particular we don't want people to get the wrong idea about
where we are heading, so making it possible to use this code on embedded
systems for me is a reason *not* to take
On 2013-12-10 0:55, Catalin Marinas wrote:
On Mon, Dec 09, 2013 at 04:35:04PM +, Arnd Bergmann wrote:
On Monday 09 December 2013, Hanjun Guo wrote:
On 2013-12-9 19:50, Catalin Marinas wrote:
On Mon, Dec 09, 2013 at 04:12:24AM +, Hanjun Guo wrote:
I think the concern here is that ACPI
On Monday 09 December 2013, Matthew Garrett wrote:
On Mon, Dec 09, 2013 at 05:35:04PM +0100, Arnd Bergmann wrote:
Exactly. In particular we don't want people to get the wrong idea about
where we are heading, so making it possible to use this code on embedded
systems for me is a reason
On 2013-12-7 1:23, Arnd Bergmann wrote:
> On Friday 06 December 2013, Tomasz Nowicki wrote:
>> On 05.12.2013 23:04, Arnd Bergmann wrote:
>>> On Wednesday 04 December 2013, Hanjun Guo wrote:
On 2013年12月04日 00:41, Matthew Garrett wrote:
> Given the number of #ifdefs you're adding, wouldn't
On 2013-12-7 1:23, Arnd Bergmann wrote:
On Friday 06 December 2013, Tomasz Nowicki wrote:
On 05.12.2013 23:04, Arnd Bergmann wrote:
On Wednesday 04 December 2013, Hanjun Guo wrote:
On 2013年12月04日 00:41, Matthew Garrett wrote:
Given the number of #ifdefs you're adding, wouldn't it make more
On Friday 06 December 2013, Tomasz Nowicki wrote:
> On 05.12.2013 23:04, Arnd Bergmann wrote:
> > On Wednesday 04 December 2013, Hanjun Guo wrote:
> >> On 2013年12月04日 00:41, Matthew Garrett wrote:
> >>> Given the number of #ifdefs you're adding, wouldn't it make more sense
> >>> to just add stub
On 05.12.2013 23:04, Arnd Bergmann wrote:
On Wednesday 04 December 2013, Hanjun Guo wrote:
On 2013年12月04日 00:41, Matthew Garrett wrote:
Given the number of #ifdefs you're adding, wouldn't it make more sense
to just add stub functions to include/linux/pci.h?
Thanks for the suggestion :)
I
On 05.12.2013 23:04, Arnd Bergmann wrote:
On Wednesday 04 December 2013, Hanjun Guo wrote:
On 2013年12月04日 00:41, Matthew Garrett wrote:
Given the number of #ifdefs you're adding, wouldn't it make more sense
to just add stub functions to include/linux/pci.h?
Thanks for the suggestion :)
I
On Friday 06 December 2013, Tomasz Nowicki wrote:
On 05.12.2013 23:04, Arnd Bergmann wrote:
On Wednesday 04 December 2013, Hanjun Guo wrote:
On 2013年12月04日 00:41, Matthew Garrett wrote:
Given the number of #ifdefs you're adding, wouldn't it make more sense
to just add stub functions to
On Wednesday 04 December 2013, Hanjun Guo wrote:
> On 2013年12月04日 00:41, Matthew Garrett wrote:
> > Given the number of #ifdefs you're adding, wouldn't it make more sense
> > to just add stub functions to include/linux/pci.h?
>
> Thanks for the suggestion :)
>
> I can add stub functions in
On Wednesday 04 December 2013, Hanjun Guo wrote:
On 2013年12月04日 00:41, Matthew Garrett wrote:
Given the number of #ifdefs you're adding, wouldn't it make more sense
to just add stub functions to include/linux/pci.h?
Thanks for the suggestion :)
I can add stub functions in
On 2013年12月04日 00:47, One Thousand Gnomes wrote:
diff --git a/drivers/acpi/reboot.c b/drivers/acpi/reboot.c
index a6c77e8b..89a181f 100644
--- a/drivers/acpi/reboot.c
+++ b/drivers/acpi/reboot.c
@@ -3,12 +3,43 @@
#include
#include
+/*
+ * There are some rare cases in the ARM world with
On 2013年12月04日 00:41, Matthew Garrett wrote:
Given the number of #ifdefs you're adding, wouldn't it make more sense
to just add stub functions to include/linux/pci.h?
Thanks for the suggestion :)
I can add stub functions in include/linux/pci.h for raw_pci_read()/
raw_pci_write(), then can
On 2013年12月04日 00:41, Matthew Garrett wrote:
Given the number of #ifdefs you're adding, wouldn't it make more sense
to just add stub functions to include/linux/pci.h?
Thanks for the suggestion :)
I can add stub functions in include/linux/pci.h for raw_pci_read()/
raw_pci_write(), then can
On 2013年12月04日 00:47, One Thousand Gnomes wrote:
diff --git a/drivers/acpi/reboot.c b/drivers/acpi/reboot.c
index a6c77e8b..89a181f 100644
--- a/drivers/acpi/reboot.c
+++ b/drivers/acpi/reboot.c
@@ -3,12 +3,43 @@
#include linux/acpi.h
#include acpi/reboot.h
+/*
+ * There are some rare
> diff --git a/drivers/acpi/reboot.c b/drivers/acpi/reboot.c
> index a6c77e8b..89a181f 100644
> --- a/drivers/acpi/reboot.c
> +++ b/drivers/acpi/reboot.c
> @@ -3,12 +3,43 @@
> #include
> #include
>
> +/*
> + * There are some rare cases in the ARM world with PCI is not one
> + * of the buses
Given the number of #ifdefs you're adding, wouldn't it make more sense
to just add stub functions to include/linux/pci.h?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Not all the ARM64 targets that are using ACPI have PCI, so introduce
some stub functions to make ACPI core run without CONFIG_PCI on ARM64.
Since ACPI on X86 and IA64 depends on PCI, it will not break X86 and
IA64 with this patch.
Signed-off-by: Graeme Gregory
Signed-off-by: Al Stone
Not all the ARM64 targets that are using ACPI have PCI, so introduce
some stub functions to make ACPI core run without CONFIG_PCI on ARM64.
Since ACPI on X86 and IA64 depends on PCI, it will not break X86 and
IA64 with this patch.
Signed-off-by: Graeme Gregory graeme.greg...@linaro.org
Given the number of #ifdefs you're adding, wouldn't it make more sense
to just add stub functions to include/linux/pci.h?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
diff --git a/drivers/acpi/reboot.c b/drivers/acpi/reboot.c
index a6c77e8b..89a181f 100644
--- a/drivers/acpi/reboot.c
+++ b/drivers/acpi/reboot.c
@@ -3,12 +3,43 @@
#include linux/acpi.h
#include acpi/reboot.h
+/*
+ * There are some rare cases in the ARM world with PCI is not one
+
64 matches
Mail list logo
