Good catch, thanks I totally forgot about the range bit in that function.
Acked-by: Graeme Gregory g...@slimlogic.co.uk
On 17/07/12 04:29, Axel Lin wrote:
The logic of calculating selector in palmas_map_voltage_smps() does not match
the logic to list voltage in palmas_list_voltage_smps().
We
On 18/07/12 04:30, Axel Lin wrote:
This patch fixes below issues when choosing selector:
1. Current code returns negative selector if min_uV 90 which is wrong.
For example, it is possible to satisfy the request with selector = 1 if
the requested min_uV is 85.
Isnt this
This looks good to me with one proviso!
SYSEN1/2 are not necessarily for regulators as given by the name, they
are more for use indicating to other chips that power is now
available/stable.
But it will not break things to have them exposed in regulator API so I
shall leave this to Mark.
Graeme
This is good with me, I originally had it like this and I cannot
remember why I convinced myself not to do it this way.
Acked-by: Graeme Gregory g...@slimlogic.co.uk
On 17/04/13 10:43, Laxman Dewangan wrote:
Clear the sleep/warm reset bits when it is not selected through
regulator platform
Looks good to me, I don't actually know the use case for this feature!
Acked-by: Graeme Gregory g...@slimlogic.co.uk
On 17/04/13 10:43, Laxman Dewangan wrote:
LDO8 of Palma device like tps65913 support the tracking mode
on which LDO8 track the SMPS45 voltage when SMPS45 is ON
and use the LDO8
This looks good to me.
Acked-by: Graeme Gregory g...@slimlogic.co.uk
On 18/04/13 14:02, Laxman Dewangan wrote:
Currently Palma regulator driver support the ramp delay
through rail specific platform data.
As regulator framework support the configuration of ramp
delay through regulator
This looks good to me.
Acked-by: Graeme Gregory g...@slimlogic.co.uk
On 18/04/13 14:02, Laxman Dewangan wrote:
The Palma device like TPS65913 have the mode mask which is also
used for enable/disable the rails. The mode bits are defined as
00: OFF
01: AUTO
10: ECO
11
On 05/04/13 17:30, Samuel Ortiz wrote:
Hi Ian,
On Fri, Mar 22, 2013 at 02:55:10PM +, Ian Lartey wrote:
This patchset adds to the support for the Palmas series of PMIC chips.
Some of the patches have previously been submitted individually.
The DT bindings doc has been added first due to
I discussed this with Grant Likely and we came to the same conclusion
that this was the only way to fix the issue. But his concern was
because dummys have a probe/remove of their own this might cause issues
in some cases. His opinion was to do this the probe/remove of the dummys
should also be
On 22/03/13 13:36, Ian Lartey wrote:
The Palmas familly of chips has LED support. This is not always muxed
to output pins so depending on the setting of the mux this driver
will create the appropriate LED class devices.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
Signed-off-by: Ian
On 26/03/13 06:03, Kishon Vijay Abraham I wrote:
Hi,
On Monday 25 March 2013 03:16 PM, Laxman Dewangan wrote:
On Monday 25 March 2013 03:02 PM, Kishon Vijay Abraham I wrote:
From: Graeme Gregory g...@slimlogic.co.uk
This is the driver for the OTG transceiver built into the Palmas
chip
On 26/03/13 09:12, Laxman Dewangan wrote:
On Tuesday 26 March 2013 02:31 PM, Graeme Gregory wrote:
On 26/03/13 06:03, Kishon Vijay Abraham I wrote:
+static int palmas_usb_read(struct palmas *palmas, unsigned int reg,
+ unsigned int *dest)
+{
+ unsigned int addr
On 26/03/13 09:34, Laxman Dewangan wrote:
On Tuesday 26 March 2013 02:57 PM, Graeme Gregory wrote:
On 26/03/13 09:12, Laxman Dewangan wrote:
On Tuesday 26 March 2013 02:31 PM, Graeme Gregory wrote:
But still you are using the PALMAS macro here and indirectly it is
tied up
On 26/03/13 16:22, Stephen Warren wrote:
On 03/26/2013 03:27 AM, Graeme Gregory wrote:
...
If we are tightly coupling as above then using platform_irq is an extra
inefficiency. You both have to populate this then parse it afterwards.
Why not just use the regmap helper? Ill admit this code
On 26/03/13 20:23, Stephen Warren wrote:
On 03/26/2013 10:57 AM, Graeme Gregory wrote:
On 26/03/13 16:22, Stephen Warren wrote:
On 03/26/2013 03:27 AM, Graeme Gregory wrote:
...
If we are tightly coupling as above then using platform_irq is an extra
inefficiency. You both have to populate
Thanks for catching that typo
Acked-by: Graeme Gregory g...@slimlogic.co.uk
On 12/03/13 15:40, Axel Lin wrote:
It does not make sense to assign return value of of_property_read_u32() to
pdata-reg_init[idx]-warm_reset. Use of_property_read_bool() to read
ti,warm-reset DT property instead which
On 26/02/13 14:01, Laxman Dewangan wrote:
On Tuesday 26 February 2013 06:46 PM, Ian Lartey wrote:
is_palmas_charger checks for the presence of charging
functionality in the device
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
Signed-off-by: Ian Lartey i...@slimlogic.co.uk
On 27/02/13 14:08, Laxman Dewangan wrote:
If driver is getting registered through DT then it look for
population of platform data which is not possible if platform
completely support the DT.
No it doesnt!
In this case, if device is registered through DT then just ignore
platform data
On 27/02/13 14:10, Laxman Dewangan wrote:
When device is registered through the DT then regulators node
exist in the parent device node of regulator driver. Hence passing
parent device node for parsing DT in place of self-device node
which is typically NULL.
Signed-off-by: Laxman Dewangan
On 27/02/13 14:26, Laxman Dewangan wrote:
On Wednesday 27 February 2013 07:51 PM, Graeme Gregory wrote:
On 27/02/13 14:08, Laxman Dewangan wrote:
If driver is getting registered through DT then it look for
population of platform data which is not possible if platform
completely support the DT
On 28/02/13 08:52, Laxman Dewangan wrote:
On Thursday 28 February 2013 12:02 AM, Stephen Warren wrote:
On 02/17/2013 10:11 PM, J Keerthy wrote:
+- interrupt-parent : The parent interrupt controller.
+
+Optional node:
+- Child nodes contain in the palmas. The palmas family is made of
several
On 28/02/13 10:27, Laxman Dewangan wrote:
On Thursday 28 February 2013 03:28 PM, Graeme Gregory wrote:
On 28/02/13 08:52, Laxman Dewangan wrote:
On Thursday 28 February 2013 12:02 AM, Stephen Warren wrote:
On 02/17/2013 10:11 PM, J Keerthy wrote:
+- interrupt-parent : The parent interrupt
On 28/02/13 10:57, Graeme Gregory wrote:
On 28/02/13 10:27, Laxman Dewangan wrote:
On Thursday 28 February 2013 03:28 PM, Graeme Gregory wrote:
On 28/02/13 08:52, Laxman Dewangan wrote:
On Thursday 28 February 2013 12:02 AM, Stephen Warren wrote:
On 02/17/2013 10:11 PM, J Keerthy wrote
On 02/03/13 11:35, Mark Brown wrote:
On Fri, Mar 01, 2013 at 12:34:40PM -0700, Stephen Warren wrote:
Is Palmas a family of chips rather than a single chip then? That
implies that the DT would need two compatible values, e.g.:
Yes.
compatible = ti,12345, ti,palmas;
... where 12345 is the
On 18/02/13 05:14, J Keerthy wrote:
Removing duplicate assignment in the existing code.
Signed-off-by: J Keerthy j-keer...@ti.com
---
drivers/regulator/palmas-regulator.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/regulator/palmas-regulator.c
On 19/09/12 16:30, Samuel Ortiz wrote:
Hi Graeme,
On Tue, Aug 28, 2012 at 01:47:34PM +0200, Graeme Gregory wrote:
This series does a couple of small improvements to the palmas mfd and
regulator drivers. It does a little re-organisation of the header file
to better implement DT in regulator
I have an interesting issue with the combination of i2c dummy devices,
regmap-irq and domains.
I have been adding device tree support to the palmas mfd driver.
The palmas device has 3 i2c addresses it responds to so it has one
normal i2c device and 2 dummy devices to claim the 2nd/3rd addresses
On 28/08/12 20:11, Mark Brown wrote:
On Tue, Aug 28, 2012 at 01:47:36PM +0200, Graeme Gregory wrote:
Swith the palmas to linear domain in all cases so in future DT and non
DT cases will work the same.
With this change we can not use regmap_get_virq internally so no need
to supply IRQ
Thanks Mark,
Series looks good to me and works for the palmas. I can now add the
bypass support without the side hack I currently have to do it.
Reviewed-by: Graeme Gregory g...@slimlogic.co.uk
On 28/08/12 06:31, Mark Brown wrote:
Many regulators support a bypass mode where they simply switch
This series does a couple of small improvements to the palmas mfd and
regulator drivers. It does a little re-organisation of the header file
to better implement DT in regulator driver and then add DT handling.
Graeme
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
Swith the palmas to linear domain in all cases so in future DT and non
DT cases will work the same.
With this change we can not use regmap_get_virq internally so no need
to supply IRQ resources to children so remove those definitions.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
Add device tree handling to the palmas MFD. This takes the values
that can be set from platform data from the device tree nodes instead.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
---
drivers/mfd/palmas.c | 52 ++
1 file changed, 52
Add DT support to palmas regulator. This involved a little change to
the platform data structure. Regulator information can now come from
platform data or DT.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/regulator/palmas
Improve the error exit path so that we correctly de-allocate resources
that have been allocated upto the point where error occurs.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
---
drivers/mfd/palmas.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git
In order to better fit DT parsing in of regulator definitions re-arrange
the platform data struct slightly which requires the definitions of
the regulator IDs earlier in the include file.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
---
include/linux/mfd/palmas.h | 60
Add the platform data and data structures for children that shall be
added by a future set of commits.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
---
drivers/mfd/palmas.c | 13
include/linux/mfd/palmas.h | 172
2 files changed
On 19/07/12 10:04, Kim, Milo wrote:
* Interrupt-masked vs Interrupt-enabled
Commonly the interrupt register is masked when the bit of IRQ register is set.
But in some device like TI LP8788, the interrupt is enabled when the bit is 1.
This patch supports the interrupt-enabled type.
On Mon, Aug 26, 2013 at 11:32:44AM +0200, Linus Walleij wrote:
On Sat, Aug 24, 2013 at 2:13 AM, Guenter Roeck li...@roeck-us.net wrote:
Did the group conclude that the idea of FDT augmenting ACPI is not feasible
?
I don't think anyone really knows. For example: how to specify a few
?
Cheers,
Samuel.
Yes, it looked good to me as well.
Acked-by: Graeme Gregory g...@slimlogic.co.uk
G
--
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/majordomo-info.html
On 15/07/13 14:30, Kozaruk, Oleksandr wrote:
Hello Jonathan,
Thanks for the review.
Couple of things:
1) It looks from the driver that a lot of the channels are not measuring
voltages but rather temperature or currents etc. If so then their
types in the channel mask should be
On Mon, Sep 16, 2013 at 05:38:12PM +0300, Mika Westerberg wrote:
On Mon, Sep 16, 2013 at 11:12:49AM +0100, Mark Brown wrote:
That's definitely an ACPI specific (probably x86 specific ACPI?)
requirement not a generic one, on some systems it would increase power
consumption since the
-core.c can both run on ARM and ARM64, introduce
CONFIG_ACPI_ARM to support it.
Signed-off-by: Graeme Gregory graeme.greg...@linaro.org
Signed-off-by: Al Stone al.st...@linaro.org
Signed-off-by: Hanjun Guo hanjun@linaro.org
---
arch/arm64/Kconfig |2 ++
drivers/acpi/Kconfig
Hi,
Grant Likely suggested that I send this patch to formally volunteer
Hanjun and myself to be the maintainers for the new arm64 acpi support.
We have been working on the arm64 port of ACPI and the patches have
now reached a few reviews but there has been some questions asked by
the community
Add maintainers for the arm-core file for arm64 ACPI support
Signed-off-by: Graeme Gregory graeme.greg...@linaro.org
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index c6d0e93..c770d3a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -259,6
On Tue, Mar 04, 2014 at 10:23:16AM +, Catalin Marinas wrote:
On Tue, Mar 04, 2014 at 02:15:45AM +, Graeme Gregory wrote:
+ACPI ARM64
That's a pretty broad statement for a single file. Is it core support,
architected peripherals, SoC?
Hi Catalin would changing the title to ACPI
On Tue, Mar 04, 2014 at 06:59:46PM +0800, Grant Likely wrote:
On Tue, Mar 4, 2014 at 10:28 AM, Randy Dunlap rdun...@infradead.org wrote:
On 03/03/2014 06:21 PM, Joe Perches wrote:
On Tue, 2014-03-04 at 10:15 +0800, Graeme Gregory wrote:
Add maintainers for the arm-core file for arm64 ACPI
On 07/05/13 10:47, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 07 May 2013 01:28 PM, Mark Brown wrote:
On Tue, May 07, 2013 at 10:42:53AM +0530, Kishon Vijay Abraham I wrote:
On Monday 06 May 2013 08:10 PM, Mark Brown wrote:
On Mon, May 06, 2013 at 06:47:04PM +0530, Kishon Vijay Abraham I
On Thu, Jun 13, 2013 at 01:21:01PM +0300, Oleksandr Kozaruk wrote:
On 06/07/2013 05:44 PM, g...@slimlogic.co.uk wrote:
On 2013-06-07 15:36, Mark Brown wrote:
On Fri, Jun 07, 2013 at 01:53:10PM +0300, Oleksandr Kozaruk wrote:
From: Graeme Gregory g...@slimlogic.co.uk
The TWL6025 was never
On Tue, May 14, 2013 at 02:48:53PM +0530, Kishon Vijay Abraham I wrote:
On Tuesday 07 May 2013 04:15 PM, Mark Brown wrote:
On Tue, May 07, 2013 at 03:17:08PM +0530, Kishon Vijay Abraham I wrote:
On Tuesday 07 May 2013 01:28 PM, Mark Brown wrote:
The platform can provide it's own vbus control
Whole series looks good to me.
Acked-by: Graeme Gregory g...@slimlogic.co.uk
On Tue, Jul 09, 2013 at 06:34:20PM +0530, Laxman Dewangan wrote:
This patch series does following:
- Remove unused member from extcon palmas structure.
- Fix to support of detecting cable properly with multiple
On 23/07/13 17:07, Grygorii Strashko wrote:
Add a missed check for errors when TWL IRQs are masked
initially on probe and report an error in case of failure.
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/mfd/twl6030-irq.c | 13 +
1 file changed, 9
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
(for temperature and test network channels).
The driver is derived from git://git.omapzoom.org/kernel/omap.git
The original driver's authors and contributors are Balaji T K,
Graeme Gregory, Ambresh K, Girish S Ghongdemath.
The changes to the original driver:
- device tree adaptation;
- drop
On Fri, Jun 27, 2014 at 11:07:48AM +0200, Arnd Bergmann wrote:
On Friday 27 June 2014 11:49:29 Hanjun Guo wrote:
+
+static int __init parse_acpi(char *arg)
+{
+ if (!arg)
+ return -EINVAL;
+
+ /* acpi=off disables both ACPI table parsing and interpreter */
On 30/06/2014 17:24, Catalin Marinas wrote:
On Fri, Jun 27, 2014 at 04:49:28AM +0100, Hanjun Guo wrote:
drivers/acpi/Makefile |2 +
drivers/acpi/plat/Makefile |1 +
drivers/acpi/plat/arm-core.c | 110
Do you ever plan to add
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 27/07/2014 03:34, Olof Johansson wrote:
On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo hanjun@linaro.org wrote:
From: Graeme Gregory graeme.greg...@linaro.org
Add documentation for the guidelines of how to use ACPI
on ARM64.
As the most vocal participant against ACPI being adopted, I
On 28/07/2014 10:07, Arnd Bergmann wrote:
On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo hanjun@linaro.org wrote:
+Relationship with Device Tree
+-
+
+ACPI support in drivers and subsystems for ARMv8 should
here to get the RSDP and all the table
pointers.
Signed-off-by: Al Stone al.st...@linaro.org
Signed-off-by: Graeme Gregory graeme.greg...@linaro.org
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
Signed-off-by: Hanjun Guo hanjun@linaro.org
---
arch/arm64/include/asm/acenv.h | 18
On 28/07/2014 17:14, Andre Przywara wrote:
On 28/07/14 16:23, Arnd Bergmann wrote:
On Monday 28 July 2014 15:20:06 Andre Przywara wrote:
On 28/07/14 11:46, Arnd Bergmann wrote:
On Monday 28 July 2014 10:23:57 Graeme Gregory wrote:
The PL011 UART is the use-case I keep hitting, that IP
On Mon, Aug 18, 2014 at 07:08:59PM +0200, Alexander Spyridakis wrote:
Yes, I think so. If you meet any problem , please let us know, and we will
update the wiki.
Should I assume that UEFI is mandatory (alternative being the aarch64
bootwrapper), as described in
On Fri, Sep 12, 2014 at 03:51:02PM +0100, Catalin Marinas wrote:
On Fri, Sep 12, 2014 at 03:00:03PM +0100, Hanjun Guo wrote:
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -23,7 +23,11 @@ acpi-y += nvs.o
# Power management related files
acpi-y
On Fri, Sep 12, 2014 at 04:49:03PM +0100, Catalin Marinas wrote:
On Fri, Sep 12, 2014 at 04:18:51PM +0100, Graeme Gregory wrote:
On Fri, Sep 12, 2014 at 03:51:02PM +0100, Catalin Marinas wrote:
On Fri, Sep 12, 2014 at 03:00:03PM +0100, Hanjun Guo wrote:
--- a/drivers/acpi/Makefile
On Fri, Sep 12, 2014 at 03:43:36PM -0400, Jon Masters wrote:
On 09/12/2014 10:00 AM, Hanjun Guo wrote:
From: Graeme Gregory graeme.greg...@linaro.org
ACPI 5.1 does not currently support S states for ARM64 hardware but
ACPI code will call acpi_target_system_state() for device power
On Tue, Sep 09, 2014 at 05:35:29PM +0100, Catalin Marinas wrote:
On Mon, Sep 01, 2014 at 03:57:41PM +0100, Hanjun Guo wrote:
From: Graeme Gregory graeme.greg...@linaro.org
acpi_wakeup_address is used on x86 as the address bios jumps into
when machine wakes up from suspend. As arm64 does
On Thu, Sep 11, 2014 at 04:57:24PM +0100, Sudeep Holla wrote:
On 11/09/14 16:37, Catalin Marinas wrote:
On Thu, Sep 11, 2014 at 02:29:34PM +0100, Grant Likely wrote:
Regarding the requests to refactor ACPICA to work better for ARM. I
completely agree that it should be done, but I do not
On Mon, Sep 01, 2014 at 05:17:51PM +0200, Arnd Bergmann wrote:
On Monday 01 September 2014 23:06:00 Hanjun Guo wrote:
+#ifdef CONFIG_ACPI
+/* Configure some sensible defaults for ACPI mode */
+static int smsc911x_probe_config_acpi(struct smsc911x_platform_config
*config,
+
On Mon, Sep 01, 2014 at 05:53:33PM +0100, Catalin Marinas wrote:
On Mon, Sep 01, 2014 at 04:28:54PM +0100, Graeme Gregory wrote:
On Mon, Sep 01, 2014 at 05:17:51PM +0200, Arnd Bergmann wrote:
On Monday 01 September 2014 23:06:00 Hanjun Guo wrote:
+#ifdef CONFIG_ACPI
+/* Configure
On Mon, Sep 01, 2014 at 06:12:48PM +0100, Catalin Marinas wrote:
On Mon, Sep 01, 2014 at 04:06:01PM +0100, Hanjun Guo wrote:
From: Graeme Gregory graeme.greg...@linaro.org
This is a subset of pl011 UART which does not supprt DMA or baud rate
changing.
It is specified in the Server
On Mon, Sep 01, 2014 at 07:11:44PM +0200, Arnd Bergmann wrote:
On Monday 01 September 2014 18:04:47 Catalin Marinas wrote:
On Mon, Sep 01, 2014 at 04:06:00PM +0100, Hanjun Guo wrote:
+#ifdef CONFIG_ACPI
+/* Configure some sensible defaults for ACPI mode */
+static int
On Wed, Sep 17, 2014 at 02:44:10AM +0100, Matthew Garrett wrote:
On Fri, Sep 12, 2014 at 10:00:16PM +0800, Hanjun Guo wrote:
+Common _DSD bindings should be submitted to ASWG to be included in the
+document :-
+
On Wed, Sep 17, 2014 at 11:40:29AM +0100, One Thousand Gnomes wrote:
Firstly provide some useful information about the hardware. It's no good
wavng your arms at a document that requires agreeing to a giant ARM TC
to get access to. Most of don't work for ARM and we'd have to get our own
On Thu, Sep 18, 2014 at 01:22:10AM +0200, Arnd Bergmann wrote:
On Wednesday 17 September 2014, Graeme Gregory wrote:
It sounds like from the discussions in other threads that ARM64 should
be following x86 and re-using DT bindings here. In which case there is
not need to submit things
On Wed, Dec 31, 2014 at 04:34:46PM +0800, Hanjun Guo wrote:
On 2014年12月31日 04:13, ashw...@codeaurora.org wrote:
Hi Hanjun,
Overall the document looks good to us. Some minor clarifications below.
-- Forwarded message --
From: Graeme Gregory graeme.greg...@linaro.org
Add
On Mon, Feb 02, 2015 at 01:40:33PM +, Leif Lindholm wrote:
On Mon, Feb 02, 2015 at 08:45:36PM +0800, Hanjun Guo wrote:
When system supporting both DT and ACPI but firmware providing
no dtb, we can use this linux,uefi-stub-generated-dtb property
to let kernel know that we can try ACPI
On Mon, Feb 02, 2015 at 11:18:24PM +0100, Rafael J. Wysocki wrote:
On Monday, February 02, 2015 08:45:33 PM Hanjun Guo wrote:
From: Graeme Gregory graeme.greg...@linaro.org
ACPI 5.1 does not currently support S states for ARM64 hardware but
ACPI code will call acpi_target_system_state
On Thu, Feb 05, 2015 at 12:07:20PM +, Catalin Marinas wrote:
On Thu, Feb 05, 2015 at 11:14:43AM +, Graeme Gregory wrote:
On Thu, Feb 05, 2015 at 10:59:45AM +, Catalin Marinas wrote:
On Thu, Feb 05, 2015 at 10:47:23AM +, Ard Biesheuvel wrote:
On 5 February 2015 at 10:41
On Thu, Feb 05, 2015 at 10:59:45AM +, Catalin Marinas wrote:
On Thu, Feb 05, 2015 at 10:47:23AM +, Ard Biesheuvel wrote:
On 5 February 2015 at 10:41, Catalin Marinas catalin.mari...@arm.com
wrote:
On Wed, Feb 04, 2015 at 06:58:14PM +, Mark Salter wrote:
On Wed, 2015-02-04
On Wed, Jan 21, 2015 at 03:42:43PM +, Catalin Marinas wrote:
On Wed, Jan 21, 2015 at 03:29:52PM +, Jon Masters wrote:
On 01/21/2015 10:23 AM, Catalin Marinas wrote:
I have some questions for the ACPI and EFI folk:
1. When booting with ACPI, are the EFI run-time services
On Sun, Jan 18, 2015 at 02:46:35PM +0800, Hanjun Guo wrote:
On 2015年01月18日 14:31, Jon Masters wrote:
Hi Folks,
Sorry for top posting from bed. The mainstream servers will all likely do
PCIe but there are several that may not. They should not be excluded. That
said,
if we booted a
On Tue, Jun 30, 2015 at 01:17:14PM +0100, Marc Zyngier wrote:
On 30/06/15 12:50, Hanjun Guo wrote:
Hi Marc,
On 06/29/2015 04:39 PM, Marc Zyngier wrote:
On 27/06/15 04:52, Hanjun Guo wrote:
On 06/24/2015 01:38 AM, Lorenzo Pieralisi wrote:
On Tue, Jun 23, 2015 at 04:11:38PM +0100,
Added the match table and pointers for ACPI probing to the driver.
This uses the same identifier for virt devices as being used for qemu
ARM64 ACPI support.
http://git.linaro.org/people/shannon.zhao/qemu.git/commit/d0bf1955a3ecbab4b51d46f8c5dda02b7e14a17e
Signed-off-by: Graeme Gregory
On Thu, Aug 06, 2015 at 05:33:10PM -0700, David Daney wrote:
From: David Daney david.da...@cavium.com
Find out which PHYs belong to which BGX instance in the ACPI way.
Set the MAC address of the device as provided by ACPI tables. This is
similar to the implementation for devicetree in
On some architectures /dev/mem is being removed. For debug/analysis
tools like FWTS/acpidump we therefore need to expose the ACPI root
tables in sysfs like the other tables.
Signed-off-by: Graeme Gregory graeme.greg...@linaro.org
---
drivers/acpi/sysfs.c | 123
Hi,
I thought I would send this patch as an RFC. It is something I did when
another linaro engineer was modifying acpica-tools to not require /dev/mem.
It exports the 3 tables that are not currenly exported in sysfs.
Currently I do not think there is any user of this because acpica-tools can
On Tue, Jul 21, 2015 at 11:08:00AM +0100, Marc Zyngier wrote:
Now that the basic ACPI GSI code is irq domain aware, make sure
that the ACPI support in the GIC doesn't pointlessly deviate from
the DT path.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
drivers/irqchip/irq-gic.c
On Tue, Jul 21, 2015 at 11:07:55AM +0100, Marc Zyngier wrote:
The irqdomain code is not entierely really ACPI friendly, as it has
some built-in knowledge of the device-tree. Nothing too harmful, but
enough to scare the ARM ACPI developpers which end up with their own
version of the square
Hi Fu Wei,
Looks ok to me.
Reviewed by: Graeme Gregory <graeme.greg...@linaro.org>
Thanks
On Mon, Nov 09, 2015 at 03:31:19PM +0800, fu@linaro.org wrote:
> From: Fu Wei <fu@linaro.org>
>
> This driver bases on linux kernel watchdog framework, and
> use "
On Wed, Jul 29, 2015 at 09:17:08PM +0300, Michael S. Tsirkin wrote:
On Tue, Jul 28, 2015 at 10:44:02AM +0100, Graeme Gregory wrote:
Added the match table and pointers for ACPI probing to the driver.
This uses the same identifier for virt devices as being used for qemu
ARM64 ACPI support
ompiled for x86 and ia64 with no
> known failures.
>
> Changes for v3:
>-- Reviewed-and-tested-by from Sudeep Holla for arm64 parts
>-- Clearer language in error messages (Graeme Gregory, Timur Tabi)
>-- Double checked that inserting call to bad_madt_entry() into the
>
On Wed, Sep 09, 2015 at 03:09:47PM -0600, Al Stone wrote:
> The existing BAD_MADT_ENTRY macro only checks that the size of the data
> structure for an MADT subtable matches the length entry in the subtable.
> This is, unfortunately, not reliable. Nor, as it turns out, does it have
> anything to
Call the amba device creation function in the default enumeration path,
this is the same location platform devices are probed.
Cc: Rafael J. Wysocki <r...@rjwysocki.net>
Cc: Len Brown <l...@kernel.org>
Cc: Russell King <li...@arm.linux.org.uk>
Signed-off-by: Graeme Gr
As discussed when Shannon Zhao sent a patch to add platform_device support
to pl061 driver. Russel and other maintainers prefered that ACPI learned
how to create AMBA devices rather than converting/adding platform_device
support to AMBA drivers.
In ACPI this device is only defined in SBSA mode so
if we are probing from ACPI use this mode.
Cc: Rafael J. Wysocki <r...@rjwysocki.net>
Cc: Len Brown <l...@kernel.org>
Cc: Russell King <li...@arm.linux.org.uk>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Signe
t;r...@rjwysocki.net>
Cc: Len Brown <l...@kernel.org>
Cc: Russell King <li...@arm.linux.org.uk>
Signed-off-by: Graeme Gregory <graeme.greg...@linaro.org>
---
drivers/acpi/Makefile| 1 +
drivers/acpi/acpi_amba.c | 157 +++
include/linux/acp
On Thu, Dec 03, 2015 at 09:54:43AM +0800, yankejian wrote:
> Add support for getting the PHY devices on an MDIO bus by ACPI.
> Currently many of the ethernet drivers are open coding a solution
> for reading data out of ACPI to find the correct PHY device.
> This patch implements a set of common
On Fri, Dec 04, 2015 at 11:24:20AM +0800, Wang Hongcheng wrote:
> AMD pl330 is a UART DMA device, it shares one ACPI item with UART. So
> a platform device and an acpi device will be created according to
> AMD0020 ACPI dev. And its mem base address must have an offset. As a
> result,
On Tue, Jan 05, 2016 at 10:23:08AM -0600, Timur Tabi wrote:
> G Gregory wrote:
> >>>I'm confused by this patch. We already have code like this in
> >>>tty-next, in the form of sbsa_uart_probe():
> >>>
>
On Tue, Dec 01, 2015 at 03:16:53AM +0100, Rafael J. Wysocki wrote:
> On Wednesday, September 30, 2015 11:38:49 AM Graeme Gregory wrote:
> > Call the amba device creation function in the default enumeration path,
> > this is the same location platform devices are probed.
>
On Tue, Dec 01, 2015 at 03:21:47AM +0100, Rafael J. Wysocki wrote:
> On Wednesday, September 30, 2015 11:38:50 AM Graeme Gregory wrote:
> > In ACPI this device is only defined in SBSA mode so
> > if we are probing from ACPI use this mode.
> >
> > Cc: Rafael J. Wysocki
1 - 100 of 262 matches
Mail list logo
