at information
> was (or is now) contained at the top of the file in the comments.
>
This is all fine with me.
Acked-by: Graeme Gregory
Thanks
> Cc: Tony Lindgren
> Cc: Lee Jones
> Cc: Graeme Gregory
> Cc: Jorge Eduardo Candelaria
> Cc: linux-o...@vger.kernel.org
> Signed-o
/Armada70x0/Dsdt.asl#L131
>
> I will appreciate any comments or remarks.
>
Nice work, this looks pretty neat to me, for series.
Reviewed-by: Graeme Gregory
Thanks
Graeme
> Best regards,
> Marcin
>
> Changelog:
> v2 -> v3:
> * 1/7, 2/7
> - Add Rafael's A
On Mon, Jan 08, 2018 at 06:17:06PM +0100, Marcin Wojtas wrote:
> Hi Andrew,
>
>
>
> 2018-01-08 16:42 GMT+01:00 Andrew Lunn :
> > w> I am not familiar with MDIO, but if its similar or a specific
> >> implementation of a serial bus that does sound sane!
> >
>
> Thanks for digging, I will check if
On Mon, Jan 08, 2018 at 03:53:12PM +0100, Andrew Lunn wrote:
> On Mon, Jan 08, 2018 at 02:45:48PM +0000, Graeme Gregory wrote:
> > On Thu, Jan 04, 2018 at 05:20:36PM +0100, Andrew Lunn wrote:
> > > > > I already agreed with 'reg' being awkward in the later email
On Thu, Jan 04, 2018 at 05:20:36PM +0100, Andrew Lunn wrote:
> > > I already agreed with 'reg' being awkward in the later emails.
> > > Wouldn't _ADR be more appropriate to specify PHY address on MDIO bus?
> > >
> > Ah it is an actual address, then yes _ADR is probably more appropriate.
>
> Newbi
On Wed, Jan 03, 2018 at 12:12:06PM +0100, Marcin Wojtas wrote:
> Hi Graeme,
>
> 2018-01-03 12:00 GMT+01:00 Graeme Gregory :
> > On Mon, Dec 18, 2017 at 10:40:31AM +0100, Ard Biesheuvel wrote:
> >> On 18 December 2017 at 10:17, Marcin Wojtas wrote:
> >>
On Sun, Dec 31, 2017 at 08:23:54PM +0100, Andrew Lunn wrote:
> > * Modify way of obtaining interrupts - with ACPI they are resources
> > bound to struct platform_device and it's not possible to obtain
> > them directly from the child node. Hence a formula is used, depending
> > on the port_id
On Mon, Dec 18, 2017 at 10:40:31AM +0100, Ard Biesheuvel wrote:
> On 18 December 2017 at 10:17, Marcin Wojtas wrote:
> > Hi,
> >
> > This patchset introduces ACPI support in mvpp2 and mvmdio drivers.
> > First three patches introduce fwnode helpers for obtaining PHY
> > information from nodes and
On 11 September 2017 at 13:28, Andreas Schwab wrote:
> On Sep 11 2017, Graeme Gregory wrote:
>
>> Considering the SPCR table in question seems mildly insane, you could
>> always unload the SPCR in grub.
>
> How do you "unload the SPCR"? But in any case, consol
On 11 September 2017 at 12:39, Andreas Schwab wrote:
> On Sep 11 2017, Leif Lindholm wrote:
>
>> Are you asking because you want to use a different console in a lab
>> setup or because there are issues with SPCR on your platform?
>
> The console from the SPCR is not the one forwarded by the BMC.
On 4 August 2017 at 23:51, Rafael J. Wysocki wrote:
> On Fri, Aug 4, 2017 at 11:49 PM, Graeme Gregory
> wrote:
>> A couple of patches to build on the SPCR quirks support already upstreamed.
>>
>> 1 - Moonshot m400 cartridge has the same soc but ACPI tables have different
xgene v1/v2 chips are also used on moonshot cartridges that have
different table headers to the ones on Mustang. Extend the quirk
so it also recognises the Moonshot M400 variant too.
Signed-off-by: Graeme Gregory
---
drivers/acpi/spcr.c | 13 ++---
1 file changed, 10 insertions(+), 3
quirk handling to avoid setting a baud rate and therefore using
the UART as configured by firmware.
Signed-off-by: Graeme Gregory
---
drivers/acpi/spcr.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
index 1457ef0
A couple of patches to build on the SPCR quirks support already upstreamed.
1 - Moonshot m400 cartridge has the same soc but ACPI tables have different
HPe specific headers so extend quirk to understand those too.
2 - Relevant vendors do not seem to be working on DBG2/SPCR update for
situation wh
space and configure
> controller registers to select and address the target secondary device.
>
> The quirk will only be applied for X-Gene PCIe MCFG table with
> OEM revison 1, 2, 3 or 4 (PCIe controller v1 and v2 on X-Gene SoCs).
>
> Signed-off-by: Duc Dang
Tested on our Lina
On Sat, Dec 03, 2016 at 05:06:31AM -0500, Jon Masters wrote:
> Hi Duc, all,
>
> (and changing the subject and trimming/adjusting the CC)
>
> On 12/02/2016 02:39 PM, Duc Dang wrote:
> > On Fri, Dec 2, 2016 at 12:11 AM, Jon Masters wrote:
> >> You're welcome.
> >>
> >> (Unrelated) Note that I adde
On Tue, Nov 22, 2016 at 03:05:29PM +, Gabriele Paoloni wrote:
> Hi Tomasz
>
> > -Original Message-
> > From: Tomasz Nowicki [mailto:t...@semihalf.com]
> > Sent: 22 November 2016 13:58
> > To: liudongdong (C); helg...@kernel.org; a...@arndb.de;
> > raf...@kernel.org; lorenzo.pieral...@a
On Fri, Oct 28, 2016 at 04:50:07PM +0100, Lorenzo Pieralisi wrote:
> On Tue, Oct 18, 2016 at 05:04:07PM +0100, Lorenzo Pieralisi wrote:
> > In ARM ACPI systems, IOMMU components are specified through static
> > IORT table entries. In order to create platform devices for the
> > corresponding ARM SM
On Thu, Sep 08, 2016 at 12:34:16PM -0400, Mark Salter wrote:
> On Thu, 2016-09-08 at 12:16 +0100, Will Deacon wrote:
> > On Wed, Sep 07, 2016 at 12:30:19PM +0300, Aleksey Makarov wrote:
> > >
> > >
> > > On 09/05/2016 03:36 PM, Aleksey Makarov wrote:
> > > >
> > > > SBBR mentions SPCR as a manda
On Thu, Sep 08, 2016 at 12:16:55PM +0100, Will Deacon wrote:
> On Wed, Sep 07, 2016 at 12:30:19PM +0300, Aleksey Makarov wrote:
> >
> > On 09/05/2016 03:36 PM, Aleksey Makarov wrote:
> > > SBBR mentions SPCR as a mandatory ACPI table. So enable it for ARM64
> > >
> > > Earlycon should be set up
IDs along with custom pci_ops structure and initialization
> call.
>
> As an example, the last patch presents quirk handling mechanism usage for
> ThunderX PEM driver.
>
Series looks good to me.
Reviewed-by: Graeme Gregory
> v4 -> v5
> - rebase against v4.8-rc1
&g
On Mon, Jun 20, 2016 at 04:19:14PM +0100, Russell King - ARM Linux wrote:
> On Mon, Jun 20, 2016 at 03:26:39PM +0300, Aleksey Makarov wrote:
> >
> > On 06/02/2016 09:02 PM, Aleksey Makarov wrote:
> > >
> > > On 05/20/2016 04:03 PM, Aleksey Makarov wrote:
> >
> > Hi Russell,
> >
> > Can you revi
On Mon, Jul 04, 2016 at 02:53:20PM +0200, Rafael J. Wysocki wrote:
> On Fri, Jul 1, 2016 at 11:04 PM, Rafael J. Wysocki wrote:
> > On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote:
> >> On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:
> >> > On 2016/6/30 21:27, Rafael J. Wysocki w
On Tue, Apr 19, 2016 at 11:41:29AM +0100, G Gregory wrote:
> On 19 April 2016 at 11:26, Tomasz Nowicki wrote:
> > On 15.04.2016 19:06, Tomasz Nowicki wrote:
> >>
> >> Passes 1.x miss PCI enhanced allocation (EA) header for fixed-BARs,
> >> thus these passes should use Cavium-specific config access
sole,
> >> this patchset introduces a new function acpi_console_check().
> >> This function is called when a new uart is registered at serial_core.c
> >> the same way OF code checks for console. If the registered uart is the
> >> console specified by SPCR tabl
On Tue, Apr 05, 2016 at 06:00:31PM -0600, Al Stone wrote:
> On 04/05/2016 02:56 AM, Charles Garcia-Tobin wrote:
> >
> >
> > On 04/04/2016 23:52, "Mark Rutland" wrote:
> >
> >> Hi,
> >>
> >> On Thu, Mar 31, 2016 at 02:44:41PM +0300, Irina Tirdea wrote:
> >>> This is a proposal for adding ACPI su
On 22/03/16 21:45, David Daney wrote:
On 03/22/2016 11:48 AM, Jon Masters wrote:
On 03/08/2016 06:59 PM, David Daney wrote:
From: David Daney
v15:
- Make the distance-map node optional (again), if it is not in
the device tree, default values are used.
- Minor cleanups
On Tue, Mar 08, 2016 at 11:29:30AM +, Julien Grall wrote:
> Fill up the recently introduced gic_kvm_info with the virtual GIC
> information.
>
> Signed-off-by: Julien Grall
> Cc: Thomas Gleixner
> Cc: Jason Cooper
> Cc: Marc Zyngier
>
> ---
> Changes in v3:
> - Add ACPI suppor
On Mon, Feb 22, 2016 at 04:45:17PM +0100, Matthias Brugger wrote:
>
>
> On 22/02/16 14:46, Aleksey Makarov wrote:
> >From: Leif Lindholm
> >
> >In order to support selecting earlycon via either ACPI or DT, move
> >the decision on whether to attempt ACPI configuration into the
> >early_param hand
On Mon, Feb 01, 2016 at 09:01:26AM +, Graeme Gregory wrote:
> On Mon, Jan 25, 2016 at 05:45:22PM +0600, Aleksey Makarov wrote:
> > 'ARM Server Base Boot Requiremets' [1] mention SPCR
> > (Serial Port Console Redirection Table) [2] as a mandatory ACPI table
> > t
On Mon, Jan 25, 2016 at 05:45:22PM +0600, Aleksey Makarov wrote:
> 'ARM Server Base Boot Requiremets' [1] mention SPCR
> (Serial Port Console Redirection Table) [2] as a mandatory ACPI table
> that specifies the configuration of serial console.
>
> Parse this table and check if any registered cons
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():
> >>>
> >>>https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/tty/+/tty-next/drivers/tty/s
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, MULTI_ATTACHED
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 rou
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
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.
>
>
Hi Fu Wei,
Looks ok to me.
Reviewed by: Graeme Gregory
Thanks
On Mon, Nov 09, 2015 at 03:31:19PM +0800, fu@linaro.org wrote:
> From: Fu Wei
>
> This driver bases on linux kernel watchdog framework, and
> use "pretimeout" in the framework. It supports getting ti
Call the amba device creation function in the default enumeration path,
this is the same location platform devices are probed.
Cc: Rafael J. Wysocki
Cc: Len Brown
Cc: Russell King
Signed-off-by: Graeme Gregory
---
drivers/acpi/scan.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion
Cc: Russell King
Signed-off-by: Graeme Gregory
---
drivers/acpi/Makefile| 1 +
drivers/acpi/acpi_amba.c | 157 +++
include/linux/acpi.h | 1 +
3 files changed, 159 insertions(+)
create mode 100644 drivers/acpi/acpi_amba.c
diff --git a
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.
http://comments.gmane.org/gmane.linux.ports.arm.kern
In ACPI this device is only defined in SBSA mode so
if we are probing from ACPI use this mode.
Cc: Rafael J. Wysocki
Cc: Len Brown
Cc: Russell King
Cc: Greg Kroah-Hartman
Signed-off-by: Graeme Gregory
---
drivers/tty/serial/amba-pl011.c | 32 +---
1 file changed
led 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 do
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 fo
On Thu, Aug 06, 2015 at 05:33:10PM -0700, David Daney wrote:
> From: David Daney
>
> 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
> of_get_mac_address(
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
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
can
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
---
drivers/acpi/sysfs.c | 123 +++
1 file
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 w
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
> ---
> drivers/irqchip/irq-gic.c | 17 ++--
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:1
On Thu, Feb 05, 2015 at 12:07:20PM +, Catalin Marinas wrote:
> On Thu, Feb 05, 2015 at 11:14:43AM +0000, 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 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
> > wrote:
> > > On Wed, Feb 04, 2015 at 06:58:14PM +, Mark Salter wrote:
> > >> On Wed, 2015-02-04 at 17:57 +000
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
> >
> > ACPI 5.1 does not currently support S states for ARM64 hardware but
> > ACPI code will call acpi_target_syst
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 A
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 serv
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
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 --
&g
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
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 T&C
> to get access to. Most of don't work for ARM and we'd have to get our own
>
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 :-
> > +
> > +http://www.uefi.org/sites/default/files/resources/_DSD-implementa
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
> >
> > ACPI 5.1 does not currently support S states for ARM64 hardware but
> > ACPI code will call acpi_target_system_state() for dev
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:
> >
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
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
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
> >
> > acpi_wakeup_address is used on x86 as the address bios jumps into
> > when machine wakes up from suspend. As
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 smsc91
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
> >
> > This is a subset of pl011 UART which does not supprt DMA or baud rate
> > changing.
> >
> > It
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:
> >
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, 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 Documentat
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
and all the table
pointers.
Signed-off-by: Al Stone
Signed-off-by: Graeme Gregory
Signed-off-by: Tomasz Nowicki
Signed-off-by: Hanjun Guo
---
arch/arm64/include/asm/acenv.h | 18 ++
arch/arm64/include/asm/acpi.h | 41 ++
arch/arm64/include/asm/cpu.h | 11
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 wrote:
+Relationship with Device Tree
+-
+
+ACPI support in drivers and subsystems for ARMv8 should never be mutually
+excl
On 27/07/2014 03:34, Olof Johansson wrote:
On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo wrote:
From: Graeme Gregory
Add documentation for the guidelines of how to use ACPI
on ARM64.
As the most vocal participant against ACPI being adopted, I would have
appreciated a cc on this patch set
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 A
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
On Tue, Mar 04, 2014 at 06:59:46PM +0800, Grant Likely wrote:
> On Tue, Mar 4, 2014 at 10:28 AM, Randy Dunlap 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-co
On Tue, Mar 04, 2014 at 10:23:16AM +, Catalin Marinas wrote:
> On Tue, Mar 04, 2014 at 02:15:45AM +0000, Graeme Gregory wrote:
> > +ACPI ARM64
>
> That's a pretty broad statement for a single file. Is it core support,
> architected peripherals, SoC?
>
Hi Catalin w
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 wh
Add maintainers for the arm-core file for arm64 ACPI support
Signed-off-by: Graeme Gregory
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index c6d0e93..c770d3a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -259,6 +259,13 @@ F: drivers/pci
On Tue, Dec 17, 2013 at 11:29:14AM +, Catalin Marinas wrote:
> Hi Graeme,
>
> On Mon, Dec 16, 2013 at 08:51:33PM +0000, Graeme Gregory wrote:
> > So the real question now is how do we progress with these ACPI patches?
> > After
> > repeated incorrect accusations
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 poste
; In order to make arm-core.c can both run on ARM and ARM64, introduce
> CONFIG_ACPI_ARM to support it.
>
> Signed-off-by: Graeme Gregory
> Signed-off-by: Al Stone
> Signed-off-by: Hanjun Guo
> ---
> arch/arm64/Kconfig |2 ++
> drivers/acpi/Kconfig
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 co
On Mon, Aug 26, 2013 at 11:32:44AM +0200, Linus Walleij wrote:
> On Sat, Aug 24, 2013 at 2:13 AM, Guenter Roeck 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
> config option
me. Kevin, Graeme, any further comments/ACKs ?
Cheers,
Samuel.
Yes, it looked good to me as well.
Acked-by: Graeme Gregory
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
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
> ---
> drivers/mfd/twl6030-irq.c | 13 +
> 1 file changed, 9 insertions(+), 4 delet
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
Whole series looks good to me.
Acked-by: Graeme Gregory
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 inser
t; Sysfs entries are added to start and read conversion result
> in millivolts for channel if it has calibration data, or
> ADC code(for temperature and test network channels).
>
> The driver is derived from git://git.omapzoom.org/kernel/omap.git
> The original driver's authors
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
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
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
This looks good to me.
Acked-by: Graeme Gregory
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
>
This looks good to me.
Acked-by: Graeme Gregory
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 constr
Looks good to me, I don't actually know the use case for this feature!
Acked-by: Graeme Gregory
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 LD
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
On 17/04/13 10:43, Laxman Dewangan wrote:
> Clear the sleep/warm reset bits when it is not selected through
> regulator platform data. This wil
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
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 fir
1 - 100 of 131 matches
Mail list logo
