* [PATCH 0/6] ARM: sun5i: chip: Misc improvements
From: Maxime Ripard @ 2016-10-21 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65L=Cf1EWgZ1YPyFA_g7aiqAGwNkC-e0vs3OM8BJ2OEbA@mail.gmail.com>
On Fri, Oct 21, 2016 at 11:02:23AM +0800, Chen-Yu Tsai wrote:
> On Mon, Oct 17, 2016 at 7:48 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi,
> >
> > This is a bunch of patches I gathered for the CHIP, that enables a few
> > things, like the WiFi regulators (and its associated power sequence), a few
> > optional buses, etc.
Applied all with your Acked-by
> FYI this series makes more sense if you mention the Pocket CHIP DT overlays.
Not really, most of these patches are for the CHIP itself. The Pocket
CHIP, just like all the other DIPs so far, uses the LCD pins, but
that's pretty much the only DIP-specific patch there.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161021/81295753/attachment.sig>
^ permalink raw reply
* [PATCH 2/3] ARM: convert to generated system call tables
From: Russell King - ARM Linux @ 2016-10-21 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4337157.Eff9E2riVH@wuerfel>
On Fri, Oct 21, 2016 at 05:18:30PM +0200, Arnd Bergmann wrote:
> On Friday, October 21, 2016 2:37:08 PM CEST Russell King - ARM Linux wrote:
> > On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
>
> > > If we hit this case, why not just use the wrapper on both EABI
> > > and OABI for simplicity? It's not like we care a lot about
> > > micro-optimizing OABI any more.
> >
> > I'd still like to retain the ability to only add to EABI in the future.
>
> Do you mean to add an EABI specific workaround for a specific syscall
> if necessary, or to stop adding OABI syscalls altogether?
To stop adding OABI syscalls altogether. I'm sure that there will
come a point (if it hasn't already) that glibc no longer supports
OABI, and at that point it probably becomes rather silly to keep
adding OABI syscalls.
> > > That brings up an interesting issue: it would be nice to use the
> > > same input file for arch/arm/ and the compat mode of arch/arm64,
> > > like x86 does. If we handle both oabi and arm64-compat in the same
> > > file, we end up with a superset of what x86 does, and we could
> > > use a single script again, and generate all four tables for
> > > ARM (native OABI, OABI-on-EABI, native EABI, EABI-on-arm64).
> >
> > OABI-compat != ARM64-EABI-compat though. They're two completely
> > different things.
>
> For the purpose of generating the tables, I don't see much
> difference: we either use the fourth column only in native
> mode, or we use the fifth column to override values from
> the fourth one when emulating the ABI on the "other" kernel.
The table generation method can be shared, but I've no idea about the
feasibility of sharing the table between ARM64 and ARM - I don't know
enough about ARM64 to know whether things like an "long" argument to
a syscall (which would be 64-bit on ARM64) would be or would not be a
problem if called from a 32-bit user application.
I've zero knowledge of the whole 32-bit application on 64-bit CPUs
thing, so it's pointless trying to discuss this aspect with me. Even
for x86, all I care there is that it works, I've no knowledge of how
it works.
> That's similar to x86, 32-bit syscalls use the traditional numbers
> with an optionally different entry point for compat mode, while
> 64-bit syscalls use a somewhat reduced table that now has support
> for both native 64-bit and "x32" mode. x86-64 and x32 share a
> syscall table but not the unistd.h list, all three generated
> from syscall_64.tbl.
What's the point of the x32 mode?
> ARM64 has a separate list of syscalls for compat mode in
> arch/arm64/include/asm/unistd32.h, this list has the same format
> as include/asm-generic/uapi/unistd.h and must be updated manually
> to match the arch/arm/ table today.
Looking through it, sort-of. It could have re-used the numbering
from the arch/arm include file, but because ARM64 wanted to be an
entirely separate architecture, it duplicates a lot from 32-bit ARM.
I pointed that out at the time, and was shouted down (which is why
today I have absolutely nothing to do with ARM64, and as a result
have very little knowledge about ARM64 - I lost interest in it as
a result of the responses I got to my comments.)
So... if you don't mind, this isn't an issue I care one iota about.
In order for something to work like what you're alluding to, ARM64
would have to ferret around in arch/arm to pull out the bits it
wants, and I see zero reason for that to be acceptable on either
side of the ARM64 vs ARM divide - it will make my job harder because
I'm then into the position where I need acks from ARM64 people to
change ARM code, and that doesn't interest me at all. I'm not going
to put myself into a position where I'm at the mercy of ARM64 folk.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v4 01/23] reset: Add renesas,rst DT bindings
From: Philipp Zabel @ 2016-10-21 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477055857-17936-2-git-send-email-geert+renesas@glider.be>
Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
> Add DT bindings for the Renesas R-Car Reset Controller (R-Car Gen1
> RESET/WDT and R-Car Gen2/Gen3 and RZ/G RST).
>
> As the features provided by the hardware module differ a lot across the
> various SoC families and members, only SoC-specific compatible values
> are defined.
>
> For now we use the RST only for providing access to the state of the
> mode pins, which is needed by the clock driver.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Magnus Damm <damm+renesas@opensource.se>
> Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> v4:
> - Add Acked-by,
> - Fix comma and period in list,
> - Add RZ/G1M and RZ/G1E,
>
> v3:
> - Clarify current usage,
> - Use "renesas,<soctype>-rst" instead of "renesas,rst-<soctype>",
> - Drop "syscon" compatible value,
> - Add R-Car M3-W,
> - Add R-Car Gen1,
>
> v2:
> - Add Acked-by.
> ---
> .../devicetree/bindings/reset/renesas,rst.txt | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/renesas,rst.txt
>
> diff --git a/Documentation/devicetree/bindings/reset/renesas,rst.txt b/Documentation/devicetree/bindings/reset/renesas,rst.txt
> new file mode 100644
> index 0000000000000000..fe5e0f37b3c93579
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/renesas,rst.txt
> @@ -0,0 +1,37 @@
> +DT bindings for the Renesas R-Car and RZ/G Reset Controllers
> +
> +The R-Car and RZ/G Reset Controllers provide reset control, and implement the
> +following functions:
> + - Latching of the levels on mode pins when PRESET# is negated,
> + - Mode monitoring register,
> + - Reset control of peripheral devices (on R-Car Gen1),
> + - Watchdog timer (on R-Car Gen1),
> + - Register-based reset control and boot address registers for the various CPU
> + cores (on R-Car Gen2 and Gen3, and on RZ/G).
> +
> +
> +Required properties:
> + - compatible: Should be
> + - "renesas,<soctype>-reset-wdt" for R-Car Gen1,
> + - "renesas,<soctype>-rst" for R-Car Gen2 and Gen3, and RZ/G
> + Examples with soctypes are:
> + - "renesas,r8a7743-rst" (RZ/G1M)
> + - "renesas,r8a7745-rst" (RZ/G1E)
> + - "renesas,r8a7778-reset-wdt" (R-Car M1A)
> + - "renesas,r8a7779-reset-wdt" (R-Car H1)
> + - "renesas,r8a7790-rst" (R-Car H2)
> + - "renesas,r8a7791-rst" (R-Car M2-W)
> + - "renesas,r8a7792-rst" (R-Car V2H
> + - "renesas,r8a7793-rst" (R-Car M2-N)
> + - "renesas,r8a7794-rst" (R-Car E2)
> + - "renesas,r8a7795-rst" (R-Car H3)
> + - "renesas,r8a7796-rst" (R-Car M3-W)
> + - reg: Address start and address range for the device.
> +
> +
> +Example:
> +
> + rst: reset-controller at e6160000 {
> + compatible = "renesas,r8a7795-rst";
> + reg = <0 0xe6160000 0 0x0200>;
> + };
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
regards
Philipp
^ permalink raw reply
* [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state
From: Philipp Zabel @ 2016-10-21 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477064730.2508.24.camel@pengutronix.de>
Am Freitag, den 21.10.2016, 17:45 +0200 schrieb Philipp Zabel:
> A. Hi Geert,
>
> Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
> > Hi Philipp, Mike, Stephen, Simon, Magnus,
> > (see questions *** below!)
> >
> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> > state of the mode pins either by a call from the platform code, or
> > directly by using a hardcoded register access. This is a bit messy, and
> > creates a dependency between driver and platform code.
> >
> > This patch series converts the various Renesas R-Car clock drivers
> > and support code from reading the mode pin states using a hardcoded
> > register access to using a new minimalistic R-Car RST driver.
> >
> > All R-Car clock drivers will rely on the presence in DT of a device node
> > for the RST module. Backwards compatibility with old DTBs is retained
> > only for R-Car Gen2, which has fallback code using its own private copy
> > of rcar_gen2_read_mode_pins().
>
> I think you should add a binding doc even though the DT bindings are
> still trivial.
Disregard that, I literally sent this mail and a second later noticed
patch 1 for the first time.
regards
Philipp
^ permalink raw reply
* [RFC PATCH 08/13] dwmac-meson8b: add support for phy selection
From: Andrew Lunn @ 2016-10-21 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477060838-14164-9-git-send-email-narmstrong@baylibre.com>
On Fri, Oct 21, 2016 at 04:40:33PM +0200, Neil Armstrong wrote:
> The Meson GXL dwmac Glue Layer also provides switching between an external PHY
> and an internal RMII 10/100 PHY.
> Add a way to setup the correct PHY switching from a device tree attribute.
Hi Neil
Can this be made automatic?
The internal PHY appears to be on address 8. Can there also be an
external PHY on address 8? Could you follow the phy-handle link to the
phy node, check the address, and if it is 8, configure for an internal
PHY?
Andrew
^ permalink raw reply
* [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state
From: Philipp Zabel @ 2016-10-21 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477055857-17936-1-git-send-email-geert+renesas@glider.be>
A. Hi Geert,
Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
> Hi Philipp, Mike, Stephen, Simon, Magnus,
> (see questions *** below!)
>
> Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> state of the mode pins either by a call from the platform code, or
> directly by using a hardcoded register access. This is a bit messy, and
> creates a dependency between driver and platform code.
>
> This patch series converts the various Renesas R-Car clock drivers
> and support code from reading the mode pin states using a hardcoded
> register access to using a new minimalistic R-Car RST driver.
>
> All R-Car clock drivers will rely on the presence in DT of a device node
> for the RST module. Backwards compatibility with old DTBs is retained
> only for R-Car Gen2, which has fallback code using its own private copy
> of rcar_gen2_read_mode_pins().
I think you should add a binding doc even though the DT bindings are
still trivial.
> After this, there is still one remaining user of
> rcar_gen2_read_mode_pins() left in platform code. A patch series to
> remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
>
> This series consists of 5 parts:
> A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
> driver,
> B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
> files,
> C. Patches 12-17 convert the clock drivers to call into the new R-Car
> RST driver,
> D. Patches 18-20 remove passing mode pin state to the clock drivers
> from the platform code,
> E. Patches 21-23 remove dead code from the clock drivers.
>
> As is usually the case with moving functionality from platform code to
> DT, there are lots of hard dependencies:
> - The DT updates in Part B can be merged as soon as the DT bindings in
> Part A have been approved,
> - The clock driver updates in Part C depend functionally on the driver
> code in Part A, and on the DT updates in Part B,
> - The board code cleanups in Part D depend on the clock driver updates
> in Part C,
> - The block driver cleanups in part E depend on the board code
> cleanups in part D.
>
> Hence to maintain the required lockstep between SoC driver, clock
> drivers, shmobile platform code, and shmobile DT, I propose to queue up
> all patches in a single branch against v4.9-rc1, and send pull requests
> to both Mike/Stephen (clock) and Simon (rest).
>
> ***
>
> - Philip: While this is a driver for a reset-controller, currently it
> doesn't provide any reset-controller functionality. Hence I added it
> to drivers/soc/renesas/. Is that OK for you?
Absolutely, as long as the driver isn't even a reset controller
provider, this is the right place.
regards
Philipp
^ permalink raw reply
* [PATCH] PCI: layerscape: Fix kernel panic on accessing NULL pointer
From: Bjorn Helgaas @ 2016-10-21 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476740647-11155-1-git-send-email-leoyang.li@nxp.com>
On Mon, Oct 17, 2016 at 04:44:06PM -0500, Li Yang wrote:
> Commit fefe6733e added reference to the pcie->drvdata before it is
> initialized which causes a kernel panic. Fix the problem by
> initializing the pcie->drvdata earlier before it is used.
>
> Reported-by: Stuart Yoder <stuart.yoder@nxp.com>
> Signed-off-by: Li Yang <leoyang.li@nxp.com>
I applied Marc Zyngier's identical patch to for-linus for v4.9. I don't
know which was posted first, but I saw Marc's first. Sorry I didn't at
least credit you when I applied it.
> ---
> drivers/pci/host/pci-layerscape.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/host/pci-layerscape.c b/drivers/pci/host/pci-layerscape.c
> index 2cb7315..958187f 100644
> --- a/drivers/pci/host/pci-layerscape.c
> +++ b/drivers/pci/host/pci-layerscape.c
> @@ -245,6 +245,7 @@ static int __init ls_pcie_probe(struct platform_device *pdev)
> if (!pcie)
> return -ENOMEM;
>
> + pcie->drvdata = match->data;
> pp = &pcie->pp;
> pp->dev = dev;
> pp->ops = pcie->drvdata->ops;
> @@ -256,7 +257,6 @@ static int __init ls_pcie_probe(struct platform_device *pdev)
> return PTR_ERR(pcie->pp.dbi_base);
> }
>
> - pcie->drvdata = match->data;
> pcie->lut = pcie->pp.dbi_base + pcie->drvdata->lut_offset;
>
> if (!ls_pcie_is_bridge(pcie))
> --
> 1.9.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/4] ARM: boot: mxs: Add On-Chip RAM
From: Stefan Wahren @ 2016-10-21 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e472fb62-00d2-359d-2126-ce2727fe3bed@i2se.com>
Am 21.10.2016 um 17:24 schrieb Stefan Wahren:
> Am 21.10.2016 um 17:03 schrieb Shawn Guo:
>> On Fri, Oct 21, 2016 at 04:05:59PM +0200, Stefan Wahren wrote:
>>> Am 21.10.2016 um 15:53 schrieb Shawn Guo:
>>>> On Tue, Sep 13, 2016 at 05:51:02PM +0000, Stefan Wahren wrote:
>>>>> The i.MX23 / i.MX28 have a small amount of On-Chip RAM which is also necessary
>>>>> for suspend to RAM and standby mode. But before we need to remove the fake reg
>>>>> properties of all internal bus nodes as discussed in this thread [1].
>>>>>
>>>>> This patch series requires Fabio Estevam's recent series "ARM: dts: imx23:
>>>>> Remove skeleton.dtsi inclusion" [2].
>>>>>
>>>>> [1] - https://marc.info/?l=devicetree&m=146139948426520&w=2
>>>> The page cannot be reached. I would like to understand the
>>>> background for this change.
>>> Strange, because i don't have any problems while clicking on the URL.
>>>
>>> It's an older discussion on the devicetree / kernel newbie mailing list
>>> with subject "strange dtc errors after adding sram node". Arnd suggested
>>> in the discussion to remove the reg property from the ahb node.
>>>
>>> Please try this one: http://www.spinics.net/lists/newbies/msg57652.html
>> If you go through 'Table 4-1. Address Map for i.MX28' of MCIMX28RM, you
>> should be able to find there are 3 AHB buses: ahb at 0, ahb at 80080000 and
>> ahb at c0000000. The ocram goes to ahb at 0. The following change should be
>> the right one for ocram addition.
> Correct me if i'm wrong, but there is only one AHB bus and only the
> connected peripheral devices like ocram or USB controller have a memory
> mapped start address not the bus itself.
Please forget about that. According to the reference manual there are 3
AHB bus layers.
>
>> diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
>> index 0ad893bf5f43..8e5718df06b2 100644
>> --- a/arch/arm/boot/dts/imx28.dtsi
>> +++ b/arch/arm/boot/dts/imx28.dtsi
>> @@ -47,6 +47,19 @@
>> };
>> };
>>
>> + ahb at 0 {
>> + compatible = "simple-bus";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + reg = <0x0 0x80000000>;
>> + ranges;
>> +
>> + ocram: sram at 0 {
>> + compatible = "mmio-sram";
>> + reg = <0x0 0x20000>;
>> + };
>> + };
>> +
>> apb at 80000000 {
>> compatible = "simple-bus";
>> #address-cells = <1>;
>>
>
--
Software-Entwickler / software developer
I2SE GmbH Tel: +49 (0) 341 355667-00
Friedrich-Ebert-Str. 61 Fax: +49 (0) 341 355667-02
04109 Leipzig
Germany
Web: http://www.i2se.com/ Mail: info at i2se.com
VAT No.: DE 811528334
Amtsgericht Leipzig HRB 23784
Gesch?ftsf?hrer/CEO: Carsten Ziermann
*** Diese E-Mail ist allein f?r den bezeichneten Adressaten bestimmt. Sie kann rechtlich vertrauliche Informationen enthalten. Wenn Sie diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte unverz?glich den Absender per E-Mail und l?schen Sie diese E-Mail von Ihrem Computer, ohne Kopien anzufertigen.
Vielen Dank. ***
*** This email is for the exclusive use of the addressee. It may contain legally privileged information. If you have received this message in error, please notify the sender by email immediately and delete the message from your computer without making any copies.
Thank you. ***
^ permalink raw reply
* [PATCH] dt-bindings: video: exynos7-decon: Remove obsolete samsung,power-domain property
From: Javier Martinez Canillas @ 2016-10-21 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7e80b5ee-41a9-8c35-ff0d-e1b8b7a4e429@samsung.com>
On 10/21/2016 11:36 AM, Sylwester Nawrocki wrote:
> On 10/21/2016 04:05 PM, Krzysztof Kozlowski wrote:
>> The samsung,power-domain property is obsolete since commit 0da658704136
>> ("ARM: dts: convert to generic power domain bindings for exynos DT").
>> Replace it with generic one.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [RFC] ARM: dts: exynos: Remove exynos4415.dtsi
From: Javier Martinez Canillas @ 2016-10-21 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c8576159-347c-42df-6a8d-8620ba4be8a1@samsung.com>
On 10/21/2016 11:33 AM, Sylwester Nawrocki wrote:
> On 10/21/2016 04:15 PM, Krzysztof Kozlowski wrote:
>> There are no boards in mainline using exynos4415.dtsi. This is DTS
>> was not tested for long. I am also not aware of any popular out-of-tree
>> boards using this (except consumer devices released by Samsung but those
>> cannot use mainline).
>>
>> Keeping Exynos4415 costs some useless effort so remove it.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> It seems a sane thing to do, I don't know of any active platform that
> uses Exynos4415.
>
> Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH 0/4] ARM: boot: mxs: Add On-Chip RAM
From: Stefan Wahren @ 2016-10-21 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021150336.GJ30578@tiger>
Am 21.10.2016 um 17:03 schrieb Shawn Guo:
> On Fri, Oct 21, 2016 at 04:05:59PM +0200, Stefan Wahren wrote:
>> Am 21.10.2016 um 15:53 schrieb Shawn Guo:
>>> On Tue, Sep 13, 2016 at 05:51:02PM +0000, Stefan Wahren wrote:
>>>> The i.MX23 / i.MX28 have a small amount of On-Chip RAM which is also necessary
>>>> for suspend to RAM and standby mode. But before we need to remove the fake reg
>>>> properties of all internal bus nodes as discussed in this thread [1].
>>>>
>>>> This patch series requires Fabio Estevam's recent series "ARM: dts: imx23:
>>>> Remove skeleton.dtsi inclusion" [2].
>>>>
>>>> [1] - https://marc.info/?l=devicetree&m=146139948426520&w=2
>>> The page cannot be reached. I would like to understand the
>>> background for this change.
>> Strange, because i don't have any problems while clicking on the URL.
>>
>> It's an older discussion on the devicetree / kernel newbie mailing list
>> with subject "strange dtc errors after adding sram node". Arnd suggested
>> in the discussion to remove the reg property from the ahb node.
>>
>> Please try this one: http://www.spinics.net/lists/newbies/msg57652.html
> If you go through 'Table 4-1. Address Map for i.MX28' of MCIMX28RM, you
> should be able to find there are 3 AHB buses: ahb at 0, ahb at 80080000 and
> ahb at c0000000. The ocram goes to ahb at 0. The following change should be
> the right one for ocram addition.
Correct me if i'm wrong, but there is only one AHB bus and only the
connected peripheral devices like ocram or USB controller have a memory
mapped start address not the bus itself.
>
> diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
> index 0ad893bf5f43..8e5718df06b2 100644
> --- a/arch/arm/boot/dts/imx28.dtsi
> +++ b/arch/arm/boot/dts/imx28.dtsi
> @@ -47,6 +47,19 @@
> };
> };
>
> + ahb at 0 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x0 0x80000000>;
> + ranges;
> +
> + ocram: sram at 0 {
> + compatible = "mmio-sram";
> + reg = <0x0 0x20000>;
> + };
> + };
> +
> apb at 80000000 {
> compatible = "simple-bus";
> #address-cells = <1>;
>
^ permalink raw reply
* [PATCH v3 8/8] PM / doc: Update device documentation for devices in IRQ safe PM domains
From: Lina Iyer @ 2016-10-21 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0hP9QNSqU053keCgY-LEGAyOiOT_vuUK71Oa6i3f7pycg@mail.gmail.com>
On Fri, Oct 21 2016 at 07:07 -0600, Rafael J. Wysocki wrote:
>On Fri, Oct 14, 2016 at 7:47 PM, Lina Iyer <lina.iyer@linaro.org> wrote:
>> Update documentation to reflect the changes made to support IRQ safe PM
>> domains.
>>
>> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>> Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
>> ---
>> Documentation/power/devices.txt | 9 ++++++++-
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
>> index 8ba6625..0401b53 100644
>> --- a/Documentation/power/devices.txt
>> +++ b/Documentation/power/devices.txt
>> @@ -607,7 +607,14 @@ individually. Instead, a set of devices sharing a power resource can be put
>> into a low-power state together at the same time by turning off the shared
>> power resource. Of course, they also need to be put into the full-power state
>> together, by turning the shared power resource on. A set of devices with this
>> -property is often referred to as a power domain.
>> +property is often referred to as a power domain. A power domain may also be
>> +nested inside another power domain.
>> +
>> +Devices and PM domains may be defined as IRQ-safe, if they can be powered
>> +on/off even when the IRQs are disabled. An IRQ-safe device in a domain will
>> +disallow power management on the domain, unless the domain is also defined as
>> +IRQ-safe. The restriction this framework imposes on the parent domain of an
>> +IRQ-safe domain is that it must also be defined as IRQ-safe.
>
>I would put this paragraph below, before the last paragraph in the section.
>
OK.
>Also I suppose that a domain should only be defined as "IRQ-safe" if
>all of the devices in it are "IRQ-safe" (or there will be problems at
>least in principle). If that is the case, it should be stated clearly
>in the paragraph you are adding as well.
>
Will add.
Thanks,
Lina
^ permalink raw reply
* [PATCH] drm: convert DT component matching to component_match_add_release()
From: Russell King - ARM Linux @ 2016-10-21 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOw6vbJ64JOugR2b3R87pFRDGDVs9HM3uZJM2z1-jHyhPf6WOA@mail.gmail.com>
On Thu, Oct 20, 2016 at 07:15:56PM -0400, Sean Paul wrote:
> On Thu, Oct 20, 2016 at 5:50 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > On Thu, Oct 20, 2016 at 04:39:04PM -0400, Sean Paul wrote:
> >> On Wed, Oct 19, 2016 at 6:28 AM, Russell King
> >> <rmk+kernel@armlinux.org.uk> wrote:
> >> > Convert DT component matching to use component_match_add_release().
> >> >
> >> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> >> > ---
> >> > Can we please get this patch from May merged into the drm-misc or
> >> > whatever trees so that we don't end up with conflicts? I've no idea
> >> > who looks after drm-misc, as they have _still_ failed to add
> >> > themselves to MAINTAINERS.
> >>
> >> I think Daniel explained pretty clearly why this wasn't happening in
> >> the previous thread.
> >>
> >> Next time you send a v2, can you please mark it as such and include a
> >> "Changes in v2" section?
> >
> > Why - nothing's changed other than a rebase onto 4.9-rc1. This isn't
> > a "I've changed it in XYZ way, so here's a new copy".
>
>
> Changes in v2: None
>
> Is still useful since:
> a) the diffstat is different from v1, which necessitates me going
> through both versions to see what's changed from the previous reviews
> (only to find out myself that it's been rebased and a function has
> changed names)
Sorry, but I don't track in any fine detail what the changes are
between patches when I bring them forward: I have far too many patches
to do that (I have 300 right now) and I never know whether they're
going to result in a pull request or not. It means finding some way
to manually attach a change log to each patch I send out, which will
be very time consuming. I'd rather not send patches out than jump
through hoops like that, especially when the reason is that the
previous version was ignored.
> b) in June, you said you were going to roll a new version with the
> common OF bits extracted. it's nice to know at the outset that this
> has/hasn't happened
Now if you were following the rest of it, rather than just random parts
that suited you, you'd have noticed that I posted the new version, but
that caused more issues, so I publically said I was reverting back to
the original version.
> Also, prefacing the subject with [PATCH v2] or [PATCH RESEND] lets me
> know there is prior history with the change. Reading the previous
> version is helpful to see what reviewer's concerns were, and whether
> they've been addressed.
Yea, I'm very bad at changing the subject line in that way, and I'm
getting worse at it. Sorry, I try my best, but I can't do better than
that.
>
>
> > It's being
> > posted in the hope that someone will finally either comment on it or
> > merge the damn thing, rather than ignoring it was done when it was
> > last posted.
> >
> >> > drivers/gpu/drm/arm/hdlcd_drv.c | 3 ++-
> >> > drivers/gpu/drm/arm/malidp_drv.c | 4 +++-
> >> > drivers/gpu/drm/armada/armada_drv.c | 2 +-
> >> > drivers/gpu/drm/drm_of.c | 28 +++++++++++++++++++++++--
> >> > drivers/gpu/drm/etnaviv/etnaviv_drv.c | 5 +++--
> >> > drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 7 ++++---
> >> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 +++-
> >> > drivers/gpu/drm/msm/msm_drv.c | 12 ++++++-----
> >> > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++++--
> >> > drivers/gpu/drm/sti/sti_drv.c | 5 +++--
> >> > drivers/gpu/drm/sun4i/sun4i_drv.c | 3 ++-
> >> > drivers/gpu/drm/tilcdc/tilcdc_external.c | 4 +++-
> >> > include/drm/drm_of.h | 12 +++++++++++
> >> > 13 files changed, 73 insertions(+), 22 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> >> > index fb6a418ce6be..6477d1a65266 100644
> >> > --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> >> > +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> >> > @@ -453,7 +453,8 @@ static int hdlcd_probe(struct platform_device *pdev)
> >> > return -EAGAIN;
> >> > }
> >> >
> >> > - component_match_add(&pdev->dev, &match, compare_dev, port);
> >> > + drm_of_component_match_add(&pdev->dev, &match, compare_dev, port);
> >> > + of_node_put(port);
> >>
> >> There's no mention in your commit message about fixing these node leaks.
> >
> > Isn't that kind-of the whole point of this patch?
> >
>
> Not according to the commit msg, it isn't.
>
> You could have just done the of_node_put adds/relocations without
> wrapping component_match_add_release.
No, adding the of_node_put() there without the other changes means that
the OF layer can drop the "port" device node, kfree() it, and reallocate
it as a different device node - which means that we can end up matching
some random other device rather than the intended one. Hence, it is
_fundamentally_ a part of this patch and isn't an independent change.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 2/3] ARM: convert to generated system call tables
From: Arnd Bergmann @ 2016-10-21 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021133708.GA1041@n2100.armlinux.org.uk>
On Friday, October 21, 2016 2:37:08 PM CEST Russell King - ARM Linux wrote:
> On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> > If we hit this case, why not just use the wrapper on both EABI
> > and OABI for simplicity? It's not like we care a lot about
> > micro-optimizing OABI any more.
>
> I'd still like to retain the ability to only add to EABI in the future.
Do you mean to add an EABI specific workaround for a specific syscall
if necessary, or to stop adding OABI syscalls altogether?
For the first one, the way that the asm-generic unistd.h handles this is
to have a range of syscall numbers reserved for architecture specific
additions. I was planning to do the same here and have a number of
reserved numbers after the last architecture specific call before
the start of the newly added generic numbers.
> > (or alternatively, add "#define sync_file_range2 arm_sync_file_range"
> > to uapi/asm/unistd.h).
>
> Well, I think you have a mis-merge somewhere, beacuse uapi/asm/unistd.h
> does have:
>
> #define __NR_sync_file_range2 __NR_arm_sync_file_range
>
> in it, which triggers this in scripts/checksyscalls.sh:
That was it, I had merged in my y2038 syscall series for testing and
accidentally dropped that line while rebasing the newly added
syscalls.
> > That brings up an interesting issue: it would be nice to use the
> > same input file for arch/arm/ and the compat mode of arch/arm64,
> > like x86 does. If we handle both oabi and arm64-compat in the same
> > file, we end up with a superset of what x86 does, and we could
> > use a single script again, and generate all four tables for
> > ARM (native OABI, OABI-on-EABI, native EABI, EABI-on-arm64).
>
> OABI-compat != ARM64-EABI-compat though. They're two completely
> different things.
For the purpose of generating the tables, I don't see much
difference: we either use the fourth column only in native
mode, or we use the fifth column to override values from
the fourth one when emulating the ABI on the "other" kernel.
> Moreover, the syscall numbers ARM64 uses natively are completely
> different from the syscall numbers 32-bit ARM uses, either for EABI
> or OABI. So I really don't see this working.
That's similar to x86, 32-bit syscalls use the traditional numbers
with an optionally different entry point for compat mode, while
64-bit syscalls use a somewhat reduced table that now has support
for both native 64-bit and "x32" mode. x86-64 and x32 share a
syscall table but not the unistd.h list, all three generated
from syscall_64.tbl.
> I've no idea how ARM64 deals with 32-bit binaries, so I can't comment
> on how it deals with those syscalls, sorry.
ARM64 has a separate list of syscalls for compat mode in
arch/arm64/include/asm/unistd32.h, this list has the same format
as include/asm-generic/uapi/unistd.h and must be updated manually
to match the arch/arm/ table today.
ARM64 will also likely gain native (A64 instruction set) ILP32
support soon, which will use the same numbers as the 64-bit
mode but point to the compat syscalls. This is similar to
how ARM OABI emulation works.
> > Another related case in asm-generic, which defines three tables:
> > native 32-bit, native 64-bit and compat 32-bit. This one not only
> > needs to have three different function pointers (e.g. sys_fcntl64,
> > sys_fcntl and compat_sys_fcntl64) but also different macros (e.g.
> > __NR_fcntl64 and __NR_fcntl).
> >
> > Anything wrong with this approach:?
> >
> > /* ARM */
> > 221 oabi fcntl64 sys_fcntl64 sys_oabi_fcntl64
> > 221 eabi fcntl64 sys_fcntl64 compat_sys_fcntl64
> >
> > /* asm-generic */
> > 25 32 fcntl64 sys_fcntl64 compat_sys_fcntl64
> > 25 64 fcntl sys_fcntl
>
> Don't know, sorry. I know virtually nothing about the differences
> between the 64-bit and 32-bit ABIs, so I can't comment on anything
> to do with the compat_* interfaces.
The only important factor here is that the first three columns are used
to generate unistd.h, which is the same for both native and emulated
mode, while the last two columns are used to generate two sets of
syscall tables using the same numbers. This is a common requirement
for OABI mode (native or emulated), EABI (on 32-bit or 64-bit kernels)
and the generic ABI (native 32-bit or emulated 32-bit).
The 64-bit unistd.h is differs only in those syscalls that got replaced
with when loff_t support was added:
#define __NR_fcntl __NR3264_fcntl
#define __NR_statfs __NR3264_statfs
#define __NR_fstatfs __NR3264_fstatfs
#define __NR_truncate __NR3264_truncate
#define __NR_ftruncate __NR3264_ftruncate
#define __NR_lseek __NR3264_lseek
#define __NR_sendfile __NR3264_sendfile
#define __NR_newfstatat __NR3264_fstatat
#define __NR_fstat __NR3264_fstat
#define __NR_mmap __NR3264_mmap
#define __NR_fadvise64 __NR3264_fadvise64
#define __NR_stat __NR3264_stat
#define __NR_lstat __NR3264_lstat
64-bit architectures still use __NR_fcntl, while 32-bit architectures
use __NR_fcntl64 etc.
> > > The syscallnr.sh script kind-of looks like a candidate, but it has
> > > ARM arch specifics to it (knowing that the number of system calls
> > > needs to fit within the 8-bit value plus 4-bit shift constant
> > > representation of ARM ALU instructions.) Maybe a generic version
> > > without that knowledge would work, provided architectures can
> > > override it.
> >
> > syscallnr.sh isn't used on x86, and probably won't be needed on
> > most (or all) others, right?
>
> Why not - the point of syscallnr.sh is to remove the need to manually
> update the __NR_syscalls definition, which is a generic kernel thing.
> Unless other architectures just define a fixed-size table with plenty
> of extra space, they'd need to adjust __NR_syscalls when adding new
> calls.
Ah, makes sense. I see that x86 does this in
arch/x86/kernel/asm-offsets_64.c in a way that would also work on
other architectures, but being able to share a single script across
all architectures would also help avoid duplicating that code.
Arnd
^ permalink raw reply
* [PATCH v2 1/4] cpufreq: pxa: use generic platdev driver for device-tree
From: Robert Jarzmik @ 2016-10-21 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020033435.GD11766@vireshk-i7>
Viresh Kumar <viresh.kumar@linaro.org> writes:
> On 19-10-16, 22:06, Robert Jarzmik wrote:
>> Viresh Kumar <viresh.kumar@linaro.org> writes:
>>
>> >> >> + { .compatible = "marvell,pxa250", },
>> >> >> + { .compatible = "marvell,pxa270", },
>> >> >>
>> >> >> { .compatible = "samsung,exynos3250", },
>> >> >> { .compatible = "samsung,exynos4210", },
>> >> >
>> >> > Isn't there a race between cpufreq-dt and the platform driver to
>> >> > register first ?
>> >> Ah, could you be more specific about the race you're talking of ?
>> >>
>> >> My understanding was that cpufreq-dt-platdev does create the device, and
>> >> cpufreq-dt is a driver for it, so there is no race but a direct relationship
>> >> AFAIU.
>> >
>> > I mean that both the driver may try to register to the cpufreq core if
>> > they are both compiled in a single image.
>> Euh I still don't follow you. The only driver that can register to the cpufreq
>> core is cpufreq-dt.
>
> I was wondering on what will happen if both cpufreq-dt and your pxa2xx-cpufreq
> driver are present in the same kernel image. In that case the init routines of
> both of them will try to call cpufreq_register_driver().
Right.
In my case, cpufreq-dt comes first, and wins.
pxa_cpu_init() calls cpufreq_register_driver() and returns -EEXIST.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH 3/3] MAINTAINERS: oxnas: Add new files definitions
From: Neil Armstrong @ 2016-10-21 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021151037.20112-1-narmstrong@baylibre.com>
Fix the dts files maintained by the OXNAS platform, add a new board.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1cd38a7..29d8853 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1478,8 +1478,9 @@ L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
L: linux-oxnas at lists.tuxfamily.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-oxnas/
-F: arch/arm/boot/dts/oxnas*
+F: arch/arm/boot/dts/ox8*.dtsi
F: arch/arm/boot/dts/wd-mbwe.dts
+F: arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
N: oxnas
ARM/Mediatek RTC DRIVER
--
2.7.0
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: OX810: Update with dt-bindings includes
From: Neil Armstrong @ 2016-10-21 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021151037.20112-1-narmstrong@baylibre.com>
Add OX810SE dt-bindings includes files for clocks and resets, replace
resets numbers by human readable defines.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm/boot/dts/ox810se.dtsi | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/ox810se.dtsi b/arch/arm/boot/dts/ox810se.dtsi
index ce13705..46aa6db 100644
--- a/arch/arm/boot/dts/ox810se.dtsi
+++ b/arch/arm/boot/dts/ox810se.dtsi
@@ -7,6 +7,8 @@
*/
/include/ "skeleton.dtsi"
+#include <dt-bindings/clock/oxsemi,ox810se.h>
+#include <dt-bindings/reset/oxsemi,ox810se.h>
/ {
compatible = "oxsemi,ox810se";
@@ -242,7 +244,7 @@
current-speed = <115200>;
no-loopback-test;
status = "disabled";
- resets = <&reset 17>;
+ resets = <&reset RESET_UART1>;
};
uart1: serial at 300000 {
@@ -256,7 +258,7 @@
current-speed = <115200>;
no-loopback-test;
status = "disabled";
- resets = <&reset 18>;
+ resets = <&reset RESET_UART2>;
};
uart2: serial at 900000 {
@@ -270,7 +272,7 @@
current-speed = <115200>;
no-loopback-test;
status = "disabled";
- resets = <&reset 22>;
+ resets = <&reset RESET_UART3>;
};
uart3: serial at a00000 {
@@ -284,7 +286,7 @@
current-speed = <115200>;
no-loopback-test;
status = "disabled";
- resets = <&reset 23>;
+ resets = <&reset RESET_UART4>;
};
};
--
2.7.0
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: Add support for OX820 and Pogoplug V3
From: Neil Armstrong @ 2016-10-21 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021151037.20112-1-narmstrong@baylibre.com>
Add device tree for the Oxford Seminconductor OX820 SoC and the
Cloud Engines PogoPlug v3 board.
Add the SoC and board compatible strings to oxnas bindings.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/arm/oxnas.txt | 5 +
arch/arm/boot/dts/Makefile | 3 +-
.../boot/dts/cloudengines-pogoplug-series-3.dts | 94 +++++++
arch/arm/boot/dts/ox820.dtsi | 298 +++++++++++++++++++++
4 files changed, 399 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
create mode 100644 arch/arm/boot/dts/ox820.dtsi
diff --git a/Documentation/devicetree/bindings/arm/oxnas.txt b/Documentation/devicetree/bindings/arm/oxnas.txt
index b9e4971..ac64e60 100644
--- a/Documentation/devicetree/bindings/arm/oxnas.txt
+++ b/Documentation/devicetree/bindings/arm/oxnas.txt
@@ -5,5 +5,10 @@ Boards with the OX810SE SoC shall have the following properties:
Required root node property:
compatible: "oxsemi,ox810se"
+Boards with the OX820 SoC shall have the following properties:
+ Required root node property:
+ compatible: "oxsemi,ox820"
+
Board compatible values:
- "wd,mbwe" (OX810SE)
+ - "cloudengines,pogoplugv3" (OX820)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..3b0c74f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -604,7 +604,8 @@ dtb-$(CONFIG_ARCH_ORION5X) += \
dtb-$(CONFIG_ARCH_PRIMA2) += \
prima2-evb.dtb
dtb-$(CONFIG_ARCH_OXNAS) += \
- wd-mbwe.dtb
+ wd-mbwe.dtb \
+ cloudengines-pogoplug-series-3.dtb
dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8060-dragonboard.dtb \
qcom-apq8064-arrow-sd-600eval.dtb \
diff --git a/arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts b/arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
new file mode 100644
index 0000000..bfde32e
--- /dev/null
+++ b/arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
@@ -0,0 +1,94 @@
+/*
+ * cloudengines-pogoplug-series-3.dtsi - Device tree file for Cloud Engines PogoPlug Series 3
+ *
+ * Copyright (C) 2016 Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/dts-v1/;
+#include "ox820.dtsi"
+
+/ {
+ model = "Cloud Engines PogoPlug Series 3";
+
+ compatible = "cloudengines,pogoplugv3", "oxsemi,ox820";
+
+ chosen {
+ bootargs = "earlyprintk";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ /* 128Mbytes DDR */
+ reg = <0x60000000 0x8000000>;
+ };
+
+ aliases {
+ serial0 = &uart0;
+ gpio0 = &gpio0;
+ gpio1 = &gpio1;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ blue {
+ label = "pogoplug:blue";
+ gpios = <&gpio0 2 0>;
+ default-state = "keep";
+ };
+
+ orange {
+ label = "pogoplug:orange";
+ gpios = <&gpio1 16 1>;
+ default-state = "keep";
+ };
+
+ green {
+ label = "pogoplug:green";
+ gpios = <&gpio1 17 1>;
+ default-state = "keep";
+ };
+ };
+};
+
+&uart0 {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart0>;
+};
+
+&nandc {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_nand>;
+
+ nand at 0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ nand-ecc-mode = "soft";
+ nand-ecc-algo = "hamming";
+
+ partition at 0 {
+ label = "boot";
+ reg = <0x00000000 0x00e00000>;
+ read-only;
+ };
+
+ partition at e00000 {
+ label = "ubi";
+ reg = <0x00e00000 0x07200000>;
+ };
+ };
+};
+
+ða {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_etha_mdio>;
+};
diff --git a/arch/arm/boot/dts/ox820.dtsi b/arch/arm/boot/dts/ox820.dtsi
new file mode 100644
index 0000000..4592075
--- /dev/null
+++ b/arch/arm/boot/dts/ox820.dtsi
@@ -0,0 +1,298 @@
+/*
+ * ox820.dtsi - Device tree file for Oxford Semiconductor OX820 SoC
+ *
+ * Copyright (C) 2016 Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/include/ "skeleton.dtsi"
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/oxsemi,ox820.h>
+#include <dt-bindings/reset/oxsemi,ox820.h>
+
+/ {
+ compatible = "oxsemi,ox820";
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ enable-method = "oxsemi,ox820-smp";
+
+ cpu at 0 {
+ device_type = "cpu";
+ compatible = "arm,arm11mpcore";
+ clocks = <&armclk>;
+ reg = <0>;
+ };
+
+ cpu at 1 {
+ device_type = "cpu";
+ compatible = "arm,arm11mpcore";
+ clocks = <&armclk>;
+ reg = <1>;
+ };
+ };
+
+ memory {
+ /* Max 512MB @ 0x60000000 */
+ reg = <0x60000000 0x20000000>;
+ };
+
+ clocks {
+ osc: oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+
+ gmacclk: gmacclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <125000000>;
+ };
+
+ sysclk: sysclk {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clock-div = <4>;
+ clock-mult = <1>;
+ clocks = <&osc>;
+ };
+
+ plla: plla {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <850000000>;
+ };
+
+ armclk: armclk {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clock-div = <2>;
+ clock-mult = <1>;
+ clocks = <&plla>;
+ };
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges;
+ interrupt-parent = <&gic>;
+
+ nandc: nand-controller at 41000000 {
+ compatible = "oxsemi,ox820-nand";
+ reg = <0x41000000 0x100000>;
+ clocks = <&stdclk CLK_820_NAND>;
+ resets = <&reset RESET_NAND>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ etha: ethernet at 40400000 {
+ compatible = "oxsemi,ox820-dwmac", "snps,dwmac";
+ reg = <0x40400000 0x2000>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq", "eth_wake_irq";
+ mac-address = [000000000000]; /* Filled in by U-Boot */
+ phy-mode = "rgmii";
+
+ clocks = <&stdclk CLK_820_ETHA>, <&gmacclk>;
+ clock-names = "gmac", "stmmaceth";
+ resets = <&reset RESET_MAC>;
+
+ /* Regmap for sys registers */
+ oxsemi,sys-ctrl = <&sys>;
+
+ status = "disabled";
+ };
+
+ apb-bridge at 44000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges = <0 0x44000000 0x1000000>;
+
+ pinctrl: pinctrl {
+ compatible = "oxsemi,ox820-pinctrl";
+
+ /* Regmap for sys registers */
+ oxsemi,sys-ctrl = <&sys>;
+
+ pinctrl_uart0: uart0 {
+ uart0 {
+ pins = "gpio30", "gpio31";
+ function = "fct5";
+ };
+ };
+
+ pinctrl_uart0_modem: uart0_modem {
+ uart0_modem_a {
+ pins = "gpio24", "gpio24", "gpio26", "gpio27";
+ function = "fct4";
+ };
+ uart0_modem_b {
+ pins = "gpio28", "gpio29";
+ function = "fct5";
+ };
+ };
+
+ pinctrl_uart1: uart1 {
+ uart1 {
+ pins = "gpio7", "gpio8";
+ function = "fct4";
+ };
+ };
+
+ pinctrl_uart1_modem: uart1_modem {
+ uart1_modem {
+ pins = "gpio5", "gpio6", "gpio40", "gpio41", "gpio42", "gpio43";
+ function = "fct4";
+ };
+ };
+
+ pinctrl_etha_mdio: etha_mdio {
+ etha_mdio {
+ pins = "gpio3", "gpio4";
+ function = "fct1";
+ };
+ };
+
+ pinctrl_nand: nand {
+ nand {
+ pins = "gpio12", "gpio13", "gpio14", "gpio15",
+ "gpio16", "gpio17", "gpio18", "gpio19",
+ "gpio20", "gpio21", "gpio22", "gpio23",
+ "gpio24";
+ function = "fct1";
+ };
+ };
+ };
+
+ gpio0: gpio at 000000 {
+ compatible = "oxsemi,ox820-gpio";
+ reg = <0x000000 0x100000>;
+ interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ngpios = <32>;
+ oxsemi,gpio-bank = <0>;
+ gpio-ranges = <&pinctrl 0 0 32>;
+ };
+
+ gpio1: gpio at 100000 {
+ compatible = "oxsemi,ox820-gpio";
+ reg = <0x100000 0x100000>;
+ interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ngpios = <18>;
+ oxsemi,gpio-bank = <1>;
+ gpio-ranges = <&pinctrl 0 32 18>;
+ };
+
+ uart0: serial at 200000 {
+ compatible = "ns16550a";
+ reg = <0x200000 0x100000>;
+ interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <0>;
+ fifo-size = <16>;
+ reg-io-width = <1>;
+ current-speed = <115200>;
+ no-loopback-test;
+ status = "disabled";
+ clocks = <&sysclk>;
+ resets = <&reset RESET_UART1>;
+ };
+
+ uart1: serial at 300000 {
+ compatible = "ns16550a";
+ reg = <0x200000 0x100000>;
+ interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <0>;
+ fifo-size = <16>;
+ reg-io-width = <1>;
+ current-speed = <115200>;
+ no-loopback-test;
+ status = "disabled";
+ clocks = <&sysclk>;
+ resets = <&reset RESET_UART2>;
+ };
+
+ rps at 400000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges = <0 0x400000 0x100000>;
+
+ intc: interrupt-controller at 0 {
+ compatible = "oxsemi,ox820-rps-irq", "oxsemi,ox810se-rps-irq";
+ interrupt-controller;
+ reg = <0 0x200>;
+ interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+ #interrupt-cells = <1>;
+ valid-mask = <0xFFFFFFFF>;
+ clear-mask = <0>;
+ };
+
+ timer0: timer at 200 {
+ compatible = "oxsemi,ox820-rps-timer";
+ reg = <0x200 0x40>;
+ clocks = <&sysclk>;
+ interrupt-parent = <&intc>;
+ interrupts = <4>;
+ };
+ };
+
+ sys: sys-ctrl at e00000 {
+ compatible = "oxsemi,ox820-sys-ctrl", "syscon", "simple-mfd";
+ reg = <0xe00000 0x200000>;
+
+ reset: reset-controller {
+ compatible = "oxsemi,ox820-reset", "oxsemi,ox810se-reset";
+ #reset-cells = <1>;
+ };
+
+ stdclk: stdclk {
+ compatible = "oxsemi,ox820-stdclk", "oxsemi,ox810se-stdclk";
+ #clock-cells = <1>;
+ };
+ };
+ };
+
+ apb-bridge at 47000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges = <0 0x47000000 0x1000000>;
+
+ scu: scu at 0 {
+ compatible = "arm,arm11mp-scu";
+ reg = <0x0 0x100>;
+ };
+
+ local-timer at 600 {
+ compatible = "arm,arm11mp-twd-timer";
+ reg = <0x600 0x20>;
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_RAW(3)|IRQ_TYPE_LEVEL_HIGH)>;
+ clocks = <&armclk>;
+ };
+
+ gic: gic at 1000 {
+ compatible = "arm,arm11mp-gic";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0x1000 0x1000>,
+ <0x100 0x500>;
+ };
+ };
+ };
+};
--
2.7.0
^ permalink raw reply related
* [PATCH 0/3] ARM: dts: oxnas: Update support for OX820 and use dt-bindings
From: Neil Armstrong @ 2016-10-21 15:10 UTC (permalink / raw)
To: linux-arm-kernel
This patchset updates the ARM DTS for the Oxnas platform by :
- Add support for the Oxford Semicondutor OX820 and the PogoPlug V3
- Update the OX810SE to use the dt-bindings includes files introduced in [1] and [2]
- Fix the MAINTAINERS entry and add the PogoPlug V3 file maintainance
This patchset depends on dt-bindings include headers posted at [1] and [2],
that were accepted/merged in the subsystem trees.
How could I manage this dependency for 4.10 ?
[1] https://listengine.tuxfamily.org/lists.tuxfamily.org/linux-oxnas/2016/10/msg00008.html
[2] https://listengine.tuxfamily.org/lists.tuxfamily.org/linux-oxnas/2016/10/msg00007.html
Neil Armstrong (3):
ARM: dts: Add support for OX820 and Pogoplug V3
ARM: dts: OX810: Update with dt-bindings includes
MAINTAINERS: oxnas: Add new files definitions
Documentation/devicetree/bindings/arm/oxnas.txt | 5 +
MAINTAINERS | 3 +-
arch/arm/boot/dts/Makefile | 3 +-
.../boot/dts/cloudengines-pogoplug-series-3.dts | 94 +++++++
arch/arm/boot/dts/ox810se.dtsi | 10 +-
arch/arm/boot/dts/ox820.dtsi | 298 +++++++++++++++++++++
6 files changed, 407 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
create mode 100644 arch/arm/boot/dts/ox820.dtsi
--
2.7.0
^ permalink raw reply
* [PATCH v4 2/2] ARM: dts: imx6ul: Add DTS for liteBoard
From: Marcin Niestroj @ 2016-10-21 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021150717.27573-1-m.niestroj@grinn-global.com>
liteBoard is a development board which uses liteSOM as its base.
Hardware specification:
* liteSOM (i.MX6UL, DRAM, eMMC)
* Ethernet PHY (id 0)
* USB host (usb_otg1)
* MicroSD slot (uSDHC1)
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Changes v3 -> v4:
* Put usb otg regulator directly under root, use hyphens in node name
(suggested by Shawn)
* Rename node name: usb_otg1_vbus -> usb-otg1-vbus
Changes v2 -> v3: none
Changes v1 -> v2:
* Use dual license
* Fix typo "defaullt" -> "default"
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6ul-liteboard.dts | 147 +++++++++++++++++++++++++++++++++
2 files changed, 148 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-liteboard.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..c1ce5f4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -420,6 +420,7 @@ dtb-$(CONFIG_SOC_IMX6SX) += \
dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-14x14-evk.dtb \
imx6ul-geam-kit.dtb \
+ imx6ul-liteboard.dtb \
imx6ul-pico-hobbit.dtb \
imx6ul-tx6ul-0010.dtb \
imx6ul-tx6ul-0011.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-liteboard.dts b/arch/arm/boot/dts/imx6ul-liteboard.dts
new file mode 100644
index 0000000..6e04cb9
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-liteboard.dts
@@ -0,0 +1,147 @@
+/*
+ * Copyright 2016 Grinn
+ *
+ * Author: Marcin Niestroj <m.niestroj@grinn-global.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6ul-litesom.dtsi"
+
+/ {
+ model = "Grinn i.MX6UL liteBoard";
+ compatible = "grinn,imx6ul-liteboard", "grinn,imx6ul-litesom",
+ "fsl,imx6ul";
+
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ reg_usb_otg1_vbus: regulator-usb-otg1-vbus {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb_otg1_vbus>;
+ regulator-name = "usb_otg1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio2 8 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&iomuxc {
+ pinctrl_enet1: enet1grp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO07__ENET1_MDC 0x1b0b0
+ MX6UL_PAD_GPIO1_IO06__ENET1_MDIO 0x1b0b0
+ MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0
+ MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0
+ MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0
+ MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0
+ MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0
+ MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0
+ MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0
+ MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
+ MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX 0x1b0b1
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART1_RTS_B__GPIO1_IO19 0x17059
+ MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x17059
+ MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x10071
+ MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x17059
+ MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x17059
+ MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x17059
+ MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x17059
+ >;
+ };
+
+ pinctrl_usb_otg1_vbus: usb-otg1-vbus {
+ fsl,pins = <
+ MX6UL_PAD_ENET2_RX_DATA0__GPIO2_IO08 0x79
+ >;
+ };
+};
+
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet1>;
+ phy-mode = "rmii";
+ phy-handle = <ðphy0>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy at 0 {
+ reg = <0>;
+ };
+ };
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&usbotg1 {
+ vbus-supply = <®_usb_otg1_vbus>;
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ cd-gpios = <&gpio1 19 GPIO_ACTIVE_LOW>;
+ no-1-8-v;
+ keep-power-in-suspend;
+ wakeup-source;
+ status = "okay";
+};
--
2.10.0
^ permalink raw reply related
* [PATCH v4 1/2] ARM: dts: imx6ul: Add DTS for liteSOM module
From: Marcin Niestroj @ 2016-10-21 15:07 UTC (permalink / raw)
To: linux-arm-kernel
This is a SOM (System on Module), so it will be part of another boards.
Hence, this is a "dtsi" file that will be included from another device
tree files.
Hardware specification:
* Freescale i.MX6UL SoC
* up to 512 MB RAM
* eMMC on uSDHC2
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Changes v3 -> v4: none
Changes v2 -> v3:
* Remove cpu0 supplies (arm-supply, soc-supply), as they were already
set in imx6ul.dtsi file (reported by S?bastien Szymanski)
Changes v1 -> v2:
* Use dual license
arch/arm/boot/dts/imx6ul-litesom.dtsi | 82 +++++++++++++++++++++++++++++++++++
1 file changed, 82 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-litesom.dtsi
diff --git a/arch/arm/boot/dts/imx6ul-litesom.dtsi b/arch/arm/boot/dts/imx6ul-litesom.dtsi
new file mode 100644
index 0000000..461292d
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-litesom.dtsi
@@ -0,0 +1,82 @@
+/*
+ * Copyright 2016 Grinn
+ *
+ * Author: Marcin Niestroj <m.niestroj@grinn-global.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "imx6ul.dtsi"
+
+/ {
+ model = "Grinn i.MX6UL liteSOM";
+ compatible = "grinn,imx6ul-litesom", "fsl,imx6ul";
+
+ memory {
+ reg = <0x80000000 0x20000000>;
+ };
+};
+
+&iomuxc {
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x10069
+ MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x17059
+ MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x17059
+ MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x17059
+ MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x17059
+ MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x17059
+ MX6UL_PAD_NAND_DATA04__USDHC2_DATA4 0x17059
+ MX6UL_PAD_NAND_DATA05__USDHC2_DATA5 0x17059
+ MX6UL_PAD_NAND_DATA06__USDHC2_DATA6 0x17059
+ MX6UL_PAD_NAND_DATA07__USDHC2_DATA7 0x17059
+ MX6UL_PAD_NAND_ALE__USDHC2_RESET_B 0x17059
+ >;
+ };
+};
+
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ no-1-8-v;
+ non-removable;
+ keep-power-in-suspend;
+ wakeup-source;
+ bus-width = <8>;
+ status = "okay";
+};
--
2.10.0
^ permalink raw reply related
* [PATCH 0/4] ARM: boot: mxs: Add On-Chip RAM
From: Shawn Guo @ 2016-10-21 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9bf7c925-bdc2-d0b8-9886-70d46383d1e0@i2se.com>
On Fri, Oct 21, 2016 at 04:05:59PM +0200, Stefan Wahren wrote:
> Am 21.10.2016 um 15:53 schrieb Shawn Guo:
> > On Tue, Sep 13, 2016 at 05:51:02PM +0000, Stefan Wahren wrote:
> >> The i.MX23 / i.MX28 have a small amount of On-Chip RAM which is also necessary
> >> for suspend to RAM and standby mode. But before we need to remove the fake reg
> >> properties of all internal bus nodes as discussed in this thread [1].
> >>
> >> This patch series requires Fabio Estevam's recent series "ARM: dts: imx23:
> >> Remove skeleton.dtsi inclusion" [2].
> >>
> >> [1] - https://marc.info/?l=devicetree&m=146139948426520&w=2
> > The page cannot be reached. I would like to understand the
> > background for this change.
>
> Strange, because i don't have any problems while clicking on the URL.
>
> It's an older discussion on the devicetree / kernel newbie mailing list
> with subject "strange dtc errors after adding sram node". Arnd suggested
> in the discussion to remove the reg property from the ahb node.
>
> Please try this one: http://www.spinics.net/lists/newbies/msg57652.html
If you go through 'Table 4-1. Address Map for i.MX28' of MCIMX28RM, you
should be able to find there are 3 AHB buses: ahb at 0, ahb at 80080000 and
ahb at c0000000. The ocram goes to ahb at 0. The following change should be
the right one for ocram addition.
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 0ad893bf5f43..8e5718df06b2 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -47,6 +47,19 @@
};
};
+ ahb at 0 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x0 0x80000000>;
+ ranges;
+
+ ocram: sram at 0 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x20000>;
+ };
+ };
+
apb at 80000000 {
compatible = "simple-bus";
#address-cells = <1>;
^ permalink raw reply related
* [PATCH] drm/virtio: kconfig: Fixup white space.
From: Sean Paul @ 2016-10-21 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475913318-12275-1-git-send-email-peter.griffin@linaro.org>
On Sat, Oct 8, 2016 at 3:55 AM, Peter Griffin <peter.griffin@linaro.org> wrote:
> Use tabs instead of spaces.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Acked-by: Lee Jones <lee.jones@linaro.org>
Applied to drm-misc, thanks
> ---
> drivers/gpu/drm/virtio/Kconfig | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
> index e1afc3d..81d1807 100644
> --- a/drivers/gpu/drm/virtio/Kconfig
> +++ b/drivers/gpu/drm/virtio/Kconfig
> @@ -1,10 +1,10 @@
> config DRM_VIRTIO_GPU
> tristate "Virtio GPU driver"
> depends on DRM && VIRTIO
> - select DRM_KMS_HELPER
> - select DRM_TTM
> + select DRM_KMS_HELPER
> + select DRM_TTM
> help
> This is the virtual GPU driver for virtio. It can be used with
> - QEMU based VMMs (like KVM or Xen).
> + QEMU based VMMs (like KVM or Xen).
>
> If unsure say M.
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH 10/10] arm64: split thread_info from task stack
From: James Morse @ 2016-10-21 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476904234-9511-11-git-send-email-mark.rutland@arm.com>
Hi Mark,
This looks great, we should definitely do this.
There are a few things missing from entry.S below:
On 19/10/16 20:10, Mark Rutland wrote:
> This patch moves arm64's struct thread_info from the task stack into
> task_struct. This protects thread_info from corruption in the case of
> stack overflows, and makes its address harder to determine if stack
> addresses are leaked, making a number of attacks more difficult. Precise
> detection and handling of overflow is left for subsequent patches.
>
> Largely, this involves changing code to store the task_struct in sp_el0,
> and acquire the thread_info from the task struct (which is the opposite
> way around to the current code). Both secondary entry and idle are
> updated to stash the sp and task pointer separately.
>
> Userspace clobbers sp_el0, and we can no longer restore this from the
> stack. Instead, the current task is cached in a per-cpu variable that we
> can safely access from early assembly as interrupts are disabled (and we
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/Kbuild | 1 -
> arch/arm64/include/asm/current.h | 22 ++++++++++++++++++++++
> arch/arm64/include/asm/smp.h | 1 +
> arch/arm64/include/asm/thread_info.h | 24 ------------------------
> arch/arm64/kernel/asm-offsets.c | 1 +
> arch/arm64/kernel/entry.S | 4 ++--
4? That was too easy...
> arch/arm64/kernel/head.S | 11 ++++++-----
> arch/arm64/kernel/process.c | 13 +++++++++++++
> arch/arm64/kernel/smp.c | 2 ++
> 10 files changed, 48 insertions(+), 32 deletions(-)
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index 2d4c83b..e781391 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -123,6 +123,7 @@
> * Set sp_el0 to current thread_info.
> */
> .if \el == 0
> + ldr_this_cpu tsk, __entry_task, x21
> msr sp_el0, tsk
> .endif
>
> @@ -674,8 +675,7 @@ ENTRY(cpu_switch_to)
> ldp x29, x9, [x8], #16
> ldr lr, [x8]
> mov sp, x9
> - and x9, x9, #~(THREAD_SIZE - 1)
> - msr sp_el0, x9
> + msr sp_el0, x1
> ret
> ENDPROC(cpu_switch_to)
>
So now tsk is current instead of current_thread_info(), but we still access it
with TI_* offsets:
entry.S:102
> /* Save the task's original addr_limit and set USER_DS (TASK_SIZE_64) */
> ldr x20, [tsk, #TI_ADDR_LIMIT]
> str x20, [sp, #S_ORIG_ADDR_LIMIT]
> mov x20, #TASK_SIZE_64
> str x20, [tsk, #TI_ADDR_LIMIT]
entry.S:143
> /* Restore the task's original addr_limit. */
> ldr x20, [sp, #S_ORIG_ADDR_LIMIT]
> str x20, [tsk, #TI_ADDR_LIMIT]
The 're-entered irq stack' check is going to need re-thinking:
entry.S:195
> /*
> * Compare sp with the current thread_info, if the top
> * ~(THREAD_SIZE - 1) bits match, we are on a task stack, and
> * should switch to the irq stack.
> */
> and x25, x19, #~(THREAD_SIZE - 1)
> cmp x25, tsk
> b.ne 9998f
It was done like this as the irq stack isn't naturally aligned, so this check
implicitly assumes tsk is on the stack. I will try and come up with an alternative.
And there are a few other things like this:
entry.S:431
> ldr w24, [tsk, #TI_PREEMPT] // get preempt count
> cbnz w24, 1f // preempt count != 0
> ldr x0, [tsk, #TI_FLAGS] // get flags
> tbz x0, #TIF_NEED_RESCHED, 1f // needs rescheduling?
> bl el1_preempt
(It may be worth renaming the register alias 'tsk' as it isn't really a
struct_task. This would catch any missed users at build time, including
any patches in flight...)
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 2f39036..ddce61b 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -45,6 +45,7 @@
> #include <linux/personality.h>
> #include <linux/notifier.h>
> #include <trace/events/power.h>
> +#include <linux/percpu.h>
>
> #include <asm/alternative.h>
> #include <asm/compat.h>
> @@ -312,6 +313,17 @@ static void uao_thread_switch(struct task_struct *next)
> }
>
> /*
> + * We store our current task in sp_el0, which is clobbered by userspace. Keep a
> + * shadow copy so that we can restore this upon entry from userspace.
> + */
> +DEFINE_PER_CPU(struct task_struct *, __entry_task) = &init_task;
> +
> +static void entry_task_switch(struct task_struct *next)
> +{
> + __this_cpu_write(__entry_task, next);
> +}
> +
> +/*
> * Thread switching.
> */
> struct task_struct *__switch_to(struct task_struct *prev,
> @@ -323,6 +335,7 @@ struct task_struct *__switch_to(struct task_struct *prev,
> tls_thread_switch(next);
> hw_breakpoint_thread_switch(next);
> contextidr_thread_switch(next);
> + entry_task_switch(next);
> uao_thread_switch(next);
>
> /*
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 2679722..cde25f4 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -149,6 +149,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
> * We need to tell the secondary core where to find its stack and the
> * page tables.
> */
> + secondary_data.task = idle;
> secondary_data.stack = task_stack_page(idle) + THREAD_START_SP;
> update_cpu_boot_status(CPU_MMU_OFF);
> __flush_dcache_area(&secondary_data, sizeof(secondary_data));
> @@ -173,6 +174,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
> pr_err("CPU%u: failed to boot: %d\n", cpu, ret);
> }
>
> + secondary_data.task = NULL;
> secondary_data.stack = NULL;
> status = READ_ONCE(secondary_data.status);
> if (ret && status) {
>
Nit-territory: Something we should remember is that __entry_task isn't written
on secondary startup, so its stale (CPU0s idle task) until the first
__switch_to(). This isn't a problem as its only read on entry from EL0.
Thanks,
James
^ permalink raw reply
* [RFC,v1,2/2] vfio/iommu-type1: set only stage 2 translation
From: Robin Murphy @ 2016-10-21 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021082703.4890c419@t450s.home>
On 21/10/16 15:27, Alex Williamson wrote:
> On Fri, 21 Oct 2016 12:39:24 +0800
> Rick Song <songwenjun@huawei.com> wrote:
>
>> Normally, VFIO should use only stage 2 translation of
>> iommu, to create the address mapping. If nesting translation
>> is disabled from VFIO core, enable iommu domain only stage 2
>> attribute, otherwise, enable iommu domain nesting attribute.
>>
>> Signed-off-by: Rick Song <songwenjun@huawei.com>
>> ---
>> drivers/vfio/vfio_iommu_type1.c | 15 ++++++++++++---
>> 1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
>> index 2ba1942..c0265fe 100644
>> --- a/drivers/vfio/vfio_iommu_type1.c
>> +++ b/drivers/vfio/vfio_iommu_type1.c
>> @@ -741,7 +741,7 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
>> struct vfio_group *group, *g;
>> struct vfio_domain *domain, *d;
>> struct bus_type *bus = NULL;
>> - int ret;
>> + int attr, ret;
>>
>> mutex_lock(&iommu->lock);
>>
>> @@ -775,13 +775,22 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
>> goto out_free;
>> }
>>
>> + /*
>> + * Set iommu nesting domain attribute if nesting translation
>> + * is enabled from iommu vfio, otherwise set iommu only stage
>> + * 2 domain attribute.
>> + */
>> + attr = 1;
>> if (iommu->nesting) {
>> - int attr = 1;
>> -
>> ret = iommu_domain_set_attr(domain->domain, DOMAIN_ATTR_NESTING,
>> &attr);
>> if (ret)
>> goto out_domain;
>> + } else {
>> + ret = iommu_domain_set_attr(domain->domain, DOMAIN_ATTR_S2,
>> + &attr);
>> + if (ret)
>> + goto out_domain;
>> }
>
> This attribute is not relevant to the majority of current users, why
> would we assume that we need to call it for all non-nesting cases? Why
> do we need to set the attribute at all, what benefit does it provide?
> If this is the normal case for an IOMMU API domain, why is there an
> option for it at all? Maybe this should be the default and S1
> (whatever that means) should be the alternate option. Thanks,
Indeed, it should be fairly straightforward to make
arm_smmu_domain_finalise() prefer stage 1/stage 2 based on domain->type
in the case that both stages are implemented. That would be preferable
to changing core VFIO code for something that really is SMMU-specific.
To echo Alex, though, what's the motivation for this? Could it be
addressed by simply implementing a force_stage parameter like the SMMUv2
driver has?
Robin.
>
> Alex
>
>>
>> ret = iommu_attach_group(domain->domain, iommu_group);
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox