linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Timur Tabi <timur@codeaurora.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	Ganesh Mahendran <opensource.ganesh@gmail.com>,
	Will Deacon <will.deacon@arm.com>,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	rrichter@cavium.com, tchalamarla@cavium.com, apinski@cavium.com,
	Shanker Donthineni <shankerd@codeaurora.org>
Subject: Re: [PATCH] Revert "arm64: Increase the max granular size"
Date: Thu, 17 Mar 2016 09:49:51 -0500	[thread overview]
Message-ID: <56EAC40F.1080504@codeaurora.org> (raw)
In-Reply-To: <20160317142716.GC11623@e104818-lin.cambridge.arm.com>

Catalin Marinas wrote:
>> >Yes, that's exactly it.  Ours is an ACPI system, and so we have to have our
>> >own defconfig for now.  We're holding off on pushing our own defconfig
>> >changes (enabling drivers, etc) until ACPI is enabled in
>> >arch/arm64/configs/defconfig.

> Is there anything that prevents you from providing a dtb/dts for this
> SoC?

We don't have a boot loader capable of passing a device tree to the 
kernel.  It's an ARM Server chip.  It doesn't do device tree.  It's 100% 
ACPI.  We boot with UEFI that configures the system and generates ACPI 
tables.

I just want to make this crystal clear, because it comes up every now 
and then.  The QDF2432 is an ACPI-only SOC with no device tree support 
whatsoever.  Zero.  Zip.  Nada.  It's not an option.

Keep in mind that on an ACPI system like ours, the boot loader (UEFI in 
our case) configures the system extensively.  It does a lot of things 
that the kernel would normally do on a device tree system.  For example, 
pin control is handled completely by UEFI.  The kernel does not set the 
pin muxes or GPIO directions.  That means we don't support dynamic pin 
muxing.  Before the kernel is booted, the GPIO pins are fixed.

We're not going to create an entire device tree from scratch for this 
chip, and then make the extensive modifications necessary to our boot 
loader for parsing and modifying that device tree.  That would take 
months of work, and it would be all throw-away code.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.

  reply	other threads:[~2016-03-17 14:50 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-16  9:32 [PATCH] Revert "arm64: Increase the max granular size" Ganesh Mahendran
2016-03-16 10:07 ` Will Deacon
2016-03-16 13:06   ` Timur Tabi
2016-03-16 14:03     ` Mark Rutland
2016-03-16 14:35       ` Will Deacon
2016-03-16 14:54         ` Mark Rutland
2016-03-16 14:18     ` Catalin Marinas
2016-03-16 15:26       ` Timur Tabi
2016-03-17 14:27         ` Catalin Marinas
2016-03-17 14:49           ` Timur Tabi [this message]
2016-03-17 15:37             ` Catalin Marinas
2016-03-17 16:03               ` Marc Zyngier
2016-03-17 18:07           ` Andrew Pinski
2016-03-17 18:34             ` Timur Tabi
2016-03-17 18:37             ` Catalin Marinas
2016-03-18 21:05 ` Chalamarla, Tirumalesh
2016-03-21  1:56   ` Ganesh Mahendran
2016-03-21 17:14   ` Catalin Marinas
2016-03-21 17:23     ` Will Deacon
2016-03-21 17:33       ` Catalin Marinas
2016-03-21 17:39         ` Chalamarla, Tirumalesh
     [not found]     ` <CAPub14-sFgx=oCHzJPb9h9b_V0rbn5UAMDNJ-yTkjhz38JPqMQ@mail.gmail.com>
     [not found]       ` <10fef112-37f1-0a1b-b5af-435acd032f01@codeaurora.org>
2017-04-06  7:22         ` Imran Khan
2017-04-06 15:58           ` Catalin Marinas
2017-04-07  2:06             ` Ganesh Mahendran
2017-04-07  8:59               ` Catalin Marinas
2017-04-12  5:13               ` Imran Khan
2017-04-12 14:00                 ` Chalamarla, Tirumalesh
2017-04-17  7:35                   ` Imran Khan
2017-04-17 10:38                     ` Sunil Kovvuri
2017-04-18 14:48                       ` Catalin Marinas
2017-04-18 17:05                         ` Sunil Kovvuri
2017-04-19 12:01                           ` Catalin Marinas
2017-04-19 13:11                             ` Sunil Kovvuri
2017-04-25  6:42                               ` Ding Tianhong
2017-04-18 18:21                     ` Chalamarla, Tirumalesh
2017-04-11  4:40             ` Jon Masters

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56EAC40F.1080504@codeaurora.org \
    --to=timur@codeaurora.org \
    --cc=apinski@cavium.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=opensource.ganesh@gmail.com \
    --cc=rrichter@cavium.com \
    --cc=shankerd@codeaurora.org \
    --cc=stable@vger.kernel.org \
    --cc=tchalamarla@cavium.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).