Re: [GIT PULL 3/9] ARM64: EXYNOS: clk: Clock dependency for ARM64 for v4.5

[Olof Johansson]

Hi,

Sorry for the slow reply, holidays and vacation and all that.

On Wed, Dec 23, 2015 at 07:44:32PM +0900, Krzysztof Kozlowski wrote:
> W dniu 22.12.2015 o 13:46, Olof Johansson pisze:
> > On Wed, Dec 02, 2015 at 10:39:40AM +0900, Krzysztof Kozlowski wrote:
> >> Hi Kukjin,
> >>
> >> Dependency for soc64 changes.
> >>
> >> Best regards,
> >> Krzysztof
> >>
> >>
> >> The following changes since commit 
> >> 8005c49d9aea74d382f474ce11afbbc7d7130bec:
> >>
> >>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
> >>
> >> are available in the git repository at:
> >>
> >>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
> >> tags/samsung-clk-arm64-symbols-4.5
> >>
> >> for you to fetch changes up to 8c2a90ed18a74e8b9cdbba679403faa44d6024fc:
> >>
> >>   clk: samsung: Don't build ARMv8 clock drivers on ARMv7 (2015-11-22 
> >> 19:25:29 +0900)
> > 
> > Hi,
> > 
> > Looks like this lacks ack from any of the clock maintainers.
> 
> It got the ack from Sylwester and Tomasz - Samsung clock maintainers. If
> it is not sufficient... then let's wait with it for v4.6. I am on
> holidays now so I cannot really do anything meaningful with it.

Ok -- even though we have per-driver maintainers, we still look for acks from
the overall subsystem maintainers on these drivers. 

> > Given that EXYNOS_ARM64_COMMON_CLK is not yet introduced, this will cause
> > a breakage in bisectability on some of these platforms as well.
> 
> The patch introduces EXYNOS_ARM64_COMMON_CLK which will be enabled by
> default on our platforms. What kind of breakage do you have in mind?

Ah, I probably missed that.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 6/9] ARM: EXYNOS: clk: Another clock dependency, ARMv7, for v4.5

[Olof Johansson]

On Wed, Dec 23, 2015 at 07:55:11PM +0900, Krzysztof Kozlowski wrote:
> W dniu 22.12.2015 o 13:51, Olof Johansson pisze:
> > On Wed, Dec 02, 2015 at 10:39:43AM +0900, Krzysztof Kozlowski wrote:
> >> Hi Kukjin,
> >>
> >> This is also clock dependency. I put it in separate tag in case clock
> >> folks want to pull it also.
> >>
> >> Best regards,
> >> Krzysztof
> >>
> >>
> >> The following changes since commit 
> >> 8005c49d9aea74d382f474ce11afbbc7d7130bec:
> >>
> >>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
> >>
> >> are available in the git repository at:
> >>
> >>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
> >> tags/samsung-clk-exynos4-4.5
> >>
> >> for you to fetch changes up to 94af7a3c310f5877dc6f756179b92f24f89a9b08:
> >>
> >>   clk: samsung: exynos4: Add SSS gate clock (2015-11-18 22:02:02 +0900)
> > 
> > Again, this should probably go through the clk maintainer (or have an ack).
> > It's just two one-line changes though, so if they're slow to respond we can
> > take it as a fallback. Resend if that's the case.
> > 
> 
> Wait, I am missing something. This contains only one patch which has the
> Stephen's Boyd ack:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/379230.html
> (this is in commit message already)
> 
> What kind of ack do you expect here? Ack for pull-request?

Yeah, looks good. I likely mixed up branch contents when I replied to this one.

I'll merge it into drivers. Still, for patches that only touches clock
subsystem, the default of merging through those subsystem maintainers is
preferred. Complications, of course, are when there's dependencies.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 2/9] ARM: EXYNOS: Exynos SoC/mach specific code for v4.5

[Olof Johansson]

On Wed, Dec 02, 2015 at 10:39:39AM +0900, Krzysztof Kozlowski wrote:
> Hi Kukjin,
> 
> SoC/mach specific code.
> 
> Best regards,
> Krzysztof
> 
> 
> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
> 
>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
> 
> are available in the git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
> tags/samsung-soc-4.5
> 
> for you to fetch changes up to 8438aef01d3560549b3a95d247b3a69311fa6f2d:
> 
>   ARM: EXYNOS: Remove redundant code from regs-pmu.h (2015-11-20 16:00:47 
> +0900)

Thanks, merged into next/soc.


-Olof

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/9] ARM: dts: Add compatible property to "partitions" node

[Olof Johansson]

Hi,

On Mon, Dec 21, 2015 at 11:33:44AM +0100, Geert Uytterhoeven wrote:
>   Hi,
> 
> As of commit e488ca9f8d4f62c2 ("doc: dt: mtd: partitions: add compatible
> property to "partitions" node"), which is in v4.4-rc6, the "partitions"
> subnode of an SPI FLASH device node must have a compatible property. The
> partitions are no longer detected if it is not present.
> 
> However, several DTSes in -next have already been converted to the
> "partitions" subnode without "compatible" property, introduced by
> commits 5cfdedb7b9a0fe38 ("mtd: ofpart: move ofpart partitions to a
> dedicated dt node") and fe2585e9c29a650a ("doc: dt: mtd: support
> partitions in a special 'partitions' subnode"). Hence all of these are
> now broken in -next, and will be broken in upstream during the merge
> window.

So, if I understand this correctly, the partitions format was added for v4.4,
then this non-backwards compatible change was added in -rc6. But, there were
also DT files that had the new-for-v4.4 partitions nodes in them that then
stopped working in -rc6?

That sounds like a regression, so this should be picked up as fixes for v4.4.

Please confirm that I've understood the setup correctly, and I'll apply the
series directly to fixes.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/9] ARM: mvebu: ix4-300d: Add compatible property to "partitions" node

[Olof Johansson]

On Mon, Dec 21, 2015 at 05:48:48PM +0100, Gregory CLEMENT wrote:
> Hi Geert,
>  
>  On lun., d??c. 21 2015, Geert Uytterhoeven  wrote:
> 
> > As of commit e488ca9f8d4f62c2 ("doc: dt: mtd: partitions: add compatible
> > property to "partitions" node"), the "partitions" subnode of an SPI
> > FLASH device node must have a compatible property. The partitions are no
> > longer detected if it is not present.
> >
> > Signed-off-by: Geert Uytterhoeven 
> > Acked-by: Brian Norris 
> 
> Applied on mvebu/dt (with the hope that it is still time to push it to
> arm-soc)

I think we should just take this directly, so feel free to drop it. I'll
followup on 0/9.


-Olof

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 8/9] ARM64: EXYNOS: dts: DeviceTree for ARM64 for v4.5

[Olof Johansson]

On Wed, Dec 02, 2015 at 10:39:45AM +0900, Krzysztof Kozlowski wrote:
> Hi Kukjin,
> 
> Few changes for Espresso board.
> 
> Best regards,
> Krzysztof
> 
> 
> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
> 
>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
> 
> are available in the git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
> tags/samsung-dt64-4.5
> 
> for you to fetch changes up to fb026cb6524744c8bd0f133f4b0d8e2595d04e15:
> 
>   arm64: dts: Add reboot node for exynos7 (2015-11-18 22:47:16 +0900)

Thanks, merged into next/dt64.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 4/9] ARM64: EXYNOS: Soc specific code for v4.5

[Olof Johansson]

On Wed, Dec 02, 2015 at 10:39:41AM +0900, Krzysztof Kozlowski wrote:
> Hi Kukjin,
> 
> ARM64 change touch also defconfig.
> 
> Best regards,
> Krzysztof
> 
> 
> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
> 
>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
> 
> are available in the git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
> tags/samsung-soc64-4.5
> 
> for you to fetch changes up to db44c07a3f0b32815bd1f3e731db9e043e57cf9c:
> 
>   arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS (2015-11-22 
> 19:31:30 +0900)

Given that Arnd started splitting out config64 separately, there's a small
chance we'll get a conflict here. We can deal with that if needed though.

Still, since this branch contains the previous clock branch I can't apply it
as it is. Can you respin without that for now?


-Olof

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 3/9] ARM64: EXYNOS: clk: Clock dependency for ARM64 for v4.5

[Olof Johansson]

On Wed, Dec 02, 2015 at 10:39:40AM +0900, Krzysztof Kozlowski wrote:
> Hi Kukjin,
> 
> Dependency for soc64 changes.
> 
> Best regards,
> Krzysztof
> 
> 
> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
> 
>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
> 
> are available in the git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
> tags/samsung-clk-arm64-symbols-4.5
> 
> for you to fetch changes up to 8c2a90ed18a74e8b9cdbba679403faa44d6024fc:
> 
>   clk: samsung: Don't build ARMv8 clock drivers on ARMv7 (2015-11-22 19:25:29 
> +0900)

Hi,

Looks like this lacks ack from any of the clock maintainers.

Given that EXYNOS_ARM64_COMMON_CLK is not yet introduced, this will cause
a breakage in bisectability on some of these platforms as well.

I'll hold off on this one for a bit.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 5/9] ARM: EXYNOS: Drivers for v4.5

[Olof Johansson]

On Wed, Dec 02, 2015 at 10:39:42AM +0900, Krzysztof Kozlowski wrote:
> Hi Kukjin,
> 
> Pinctrl for v4.5.
> 
> Best regards,
> Krzysztof
> 
> 
> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
> 
>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
> 
> are available in the git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
> tags/samsung-drivers-4.5
> 
> for you to fetch changes up to 023e06dfa6882f500b9c86fd61f0b1913aa07f36:
> 
>   pinctrl: exynos: add exynos5410 SoC specific data (2015-11-16 10:54:43 
> +0900)

Hi,

This should either go in through the pinctrl tree, or have an acked/reviewed-by
one of the pinctrl maintainers.



-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 6/9] ARM: EXYNOS: clk: Another clock dependency, ARMv7, for v4.5

[Olof Johansson]

On Wed, Dec 02, 2015 at 10:39:43AM +0900, Krzysztof Kozlowski wrote:
> Hi Kukjin,
> 
> This is also clock dependency. I put it in separate tag in case clock
> folks want to pull it also.
> 
> Best regards,
> Krzysztof
> 
> 
> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
> 
>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
> 
> are available in the git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
> tags/samsung-clk-exynos4-4.5
> 
> for you to fetch changes up to 94af7a3c310f5877dc6f756179b92f24f89a9b08:
> 
>   clk: samsung: exynos4: Add SSS gate clock (2015-11-18 22:02:02 +0900)

Again, this should probably go through the clk maintainer (or have an ack).
It's just two one-line changes though, so if they're slow to respond we can
take it as a fallback. Resend if that's the case.


-Olof

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 7/9] ARM: EXYNOS: dts: DeviceTree for v4.5

[Olof Johansson]

On Wed, Dec 02, 2015 at 10:39:44AM +0900, Krzysztof Kozlowski wrote:
> Hi Kukjin,
> 
> A lot of stuff here, mostly cleanups. Description in tag.
> 
> Best regards,
> Krzysztof
> 
> 
> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
> 
>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
> 
> are available in the git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
> tags/samsung-dt-4.5
> 
> for you to fetch changes up to 2cf107f1033e0343d45b59d06f16487c8362702f:
> 
>   ARM: dts: Unify G2D device node with other devices on exynos4 (2015-11-30 
> 17:00:43 +0900)
> 
> 
> Samsung DeviceTree updates and improvements for 4.5:
> 1. Pinctrl for Exynos5410.
> 2. eMMC/SDIO minor fixes usage of bindings on Snow and Peach
>Chromebooks.
> 3. Remove FIMD from Odroid XU3-family because on XU3 it cannot be used
>yet and on XU3-Lite and XU4 it is not supported.
> 4. Remove deprecated since June 2013 samsung,exynos5-hdmi.
> 5. Add support for Pseudo Random Generator on Exynos4 (Trats2 for now).
>This depends on new SSS clock.
> 6. Add rotator nodes for Exynos4 and Exynos5.
> 7. Switch DWC3_1 on Odroid XU3 and XU3-Lite to peripheral mode because
>now it cannot be used as OTG.
> 8. Cleanup the G2D usage on Exynos4 and add it to a proper domain
>in case of Exynos4210.
> 9. Put MDMA1 in proper domain on Exynos4210 as well.
> 10. Minor cleanups.

Given the request to get acks for the pinctrl changes, can you respin this
branch without those pieces so we can merge in the rest of it?


Thanks!


-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 9/9] ARM: EXYNOS: Defconfig for v4.5

[Olof Johansson]

On Wed, Dec 02, 2015 at 10:39:46AM +0900, Krzysztof Kozlowski wrote:
> Hi Kukjin,
> 
> This may conflict with other arm-soc updates...
> 
> Best regards,
> Krzysztof
> 
> 
> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
> 
>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
> 
> are available in the git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
> tags/samsung-defconfig-4.5
> 
> for you to fetch changes up to 00a5e81fff2d81c3b1bf45712d3a12c905bc7c66:
> 
>   ARM: exynos_defconfig: Set recommended options for systemd (2015-12-01 
> 08:28:44 +0900)

Merged into next/defconfig.

Thanks!


-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] arm64: dts: uniphier: add PH1-LD10 SoC/board support

[Olof Johansson]

On Sat, Nov 28, 2015 at 02:22:31AM +0900, Masahiro Yamada wrote:
> This is the first ARMv8 SoC from Socionext Inc.
> 
> Signed-off-by: Masahiro Yamada 
> ---

Thanks, applied.


-Olof

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: tegra: Fix suspend hang on Tegra124 Chromebooks

[Olof Johansson]

On Tue, Dec 08, 2015 at 10:26:49AM +, Jon Hunter wrote:
> Enabling CPUFreq support for Tegra124 Chromebooks is causing the Tegra124
> to hang when resuming from suspend.
> 
> When CPUFreq is enabled, the CPU clock is changed from the PLLX clock to
> the DFLL clock during kernel boot. When resuming from suspend the CPU
> clock is temporarily changed back to the PLLX clock before switching back
> to the DFLL. If the DFLL is operating at a much lower frequency than the
> PLLX when we enter suspend, and so the CPU voltage rail is at a voltage
> too low for the CPUs to operate at the PLLX frequency, then the device
> will hang.
> 
> Please note that the PLLX is used in the resume sequence to switch the CPU
> clock from the very slow 32K clock to a faster clock during early resume
> to speed up the resume sequence before the DFLL is resumed.
> 
> Ideally, we should fix this by setting the suspend frequency so that it
> matches the PLLX frequency, however, that would be a bigger change. For
> now simply disable CPUFreq support for Tegra124 Chromebooks to avoid the
> hang when resuming from suspend.
> 
> Fixes: 9a0baee960a7 ("ARM: tegra: Enable CPUFreq support for Tegra124
> Chromebooks")
> 
> Signed-off-by: Jon Hunter 
> ---
> 
> Please note that this fix is required for v4.4

Since I saw this mentioned on IRC, I applied it directly to the arm-soc
fixes branch.


Thanks,

-Olof

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 1/9] ARM: EXYNOS: dts: Syscon dependency for v4.5

[Olof Johansson]

On Wed, Dec 02, 2015 at 10:39:38AM +0900, Krzysztof Kozlowski wrote:
> Hi Kukjin,
> 
> The DT changes are needed before switching to syscon-based reboot
> and power off method.
> 
> Best regards,
> Krzysztof
> 
> 
> 
> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
> 
>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
> 
> are available in the git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
> tags/samsung-dt-syscon-restart-4.5
> 
> for you to fetch changes up to 35135f4b95f03be7ebbf31221ce738f1ec0faa02:
> 
>   ARM: dts: Add syscon-{reboot, poweroff} nodes for exynos5410 (2015-11-20 
> 15:58:44 +0900)

Thanks, merged into next/dt.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5] bus: uniphier-system-bus: add UniPhier System Bus driver

[Olof Johansson]

On Wed, Dec 09, 2015 at 03:52:59PM +0900, Masahiro Yamada wrote:
> The UniPhier System Bus is an external bus that connects on-board
> devices to the UniPhier SoC.  Each bank (chip select) is dynamically
> mapped to the CPU-viewed address base via the bus controller.  The
> bus controller must be configured before any access to the bus.
> 
> This driver parses the "ranges" property of the System Bus node and
> initialized the bus controller.  After the bus becomes ready, devices
> below it are populated.
> 
> Note:
> Each bank can be mapped anywhere in the supported address space;
> there is nothing preventing us from assigning bank 0 on 0x4200,
> 0x4300, or anywhere as long as such region is not used by others.
> So, the "ranges" is just one possible software configuration, which
> does not seem to fit in device tree because device tree is a hardware
> description language.  However, of_translate_address() requires
> "ranges" in every bus node between CPUs and device mapped on the CPU
> address space.  In other words, "ranges" properties must be statically
> defined in device tree.  After some discussion, I decided the dynamic
> address reassignment by the driver is too bothersome.  Instead, the
> device tree should provide a reasonable translation setup that the OS
> can rely on.
> 
> Signed-off-by: Masahiro Yamada 
> Acked-by: Rob Herring 
> Acked-by: Arnd Bergmann 

Thanks, applied to next/drivers.


-Olof

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/7] ARM: at91/dt: sama5d2: add pio controller node

[Olof Johansson]

On Tue, Nov 17, 2015 at 3:06 AM, Linus Walleij <linus.wall...@linaro.org> wrote:
> On Tue, Nov 10, 2015 at 1:30 AM, Olof Johansson <o...@lixom.net> wrote:
>> On Mon, Sep 21, 2015 at 11:24 AM, Linus Walleij
>> <linus.wall...@linaro.org> wrote:
>>> On Wed, Sep 16, 2015 at 8:37 AM, Ludovic Desroches
>>> <ludovic.desroc...@atmel.com> wrote:
>>>
>>>> Add pio4 controller node to enable pinmux and gpio.
>>>>
>>>> Signed-off-by: Ludovic Desroches <ludovic.desroc...@atmel.com>
>>>
>>> Patch applied.
>>
>> Please don't merge DT changes through driver trees unless there's a
>> very specific reason to do so, since it introduces random conflicts.
>
> Sorry :(
>
> Even noted this in the pull request to Torvalds, it was in the bottom
> of my patch stack so had been in -next for ages, I was afraid it
> would create more problem than it solves if I reverted the patch,
> but I guess I should have done so anyways.

Yeah, it's OK -- I spotted that pull request later as well.

It's not a big deal in most specific instances, I'd say. It's just in
aggregate it becomes a bother.

So, just see this as a public reminder since we've seen it creep into
other driver trees a bit more lately. Mistakes will still happen but
try to keep it down. And for those who submit patches, feel free to
point out in the patch that you don't expect the driver/subsystem
maintainer to apply it to help them out.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] devicetree: bindings: Document qcom board compatible format

[Olof Johansson]

Hi,

On Mon, Oct 26, 2015 at 2:25 PM, Stephen Boyd  wrote:
> Some qcom based bootloaders identify the dtb blob based on a set
> of device properties like SoC, platform, PMIC, and revisions of
> those components. In downstream kernels, these values are added
> to the different component dtsi files (i.e. pmic dtsi file, SoC
> dtsi file, board dtsi file, etc.) via qcom specific DT
> properties. The dtb files are parsed by a program called dtbTool
> that picks out these properties and creates a table of contents
> binary blob with the property information and some offsets into
> the concatenation of all the dtbs (termed a QCDT image).
>
> The suggestion is to do this via the board compatible string
> instead, because these qcom specific properties are never used by
> the kernel. Add a document describing the format of the
> compatible string that encodes all this information that's
> currently encoded in the qcom,{msm-id,board-id,pmic-id}
> properties in downstream devicetrees. Future bootloaders may be
> updated to look at the compatible field instead of looking for
> the table of contents image. For non-updateable bootloaders, a
> new dtbTool program will parse the compatible string and generate
> a QCDT image from it.
>
> Signed-off-by: Stephen Boyd 
> ---
>  Documentation/devicetree/bindings/arm/qcom.txt | 86 
> ++
>  1 file changed, 86 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/qcom.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/qcom.txt 
> b/Documentation/devicetree/bindings/arm/qcom.txt
> new file mode 100644
> index ..ed084367182d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/qcom.txt
> @@ -0,0 +1,86 @@
> +QCOM device tree bindings
> +-
> +
> +Some qcom based bootloaders identify the dtb blob based on a set of
> +device properties like SoC, platform, PMIC, and revisions of those 
> components.
> +To support this scheme, we encode this information into the board compatible
> +string.
> +
> +Each board must specify a top-level board compatible string with the 
> following
> +format:
> +
> +   compatible = 
> "qcom,(-)(-)-(/)(-)(-MB)(--panel)(-boot-)(-(-v)){0-4}"
> +
> +where elements in parentheses "()" are optional and elements in brackets "<>"
> +are names of elements. Meaning only the 'SoC' and 'plat_type' elements are
> +required.
> +
> +The 'SoC' element must be one of the following strings:
> +
> +   apq8016
> +   apq8074
> +   apq8084
> +   apq8096
> +   msm8916
> +   msm8974
> +   msm8996
> +
> +The 'plat_type' element must be one of the following strings:
> +
> +   cdp
> +   liquid
> +   dragonboard
> +   mtp sbc
> +
> +
> +The 'soc_version', 'plat_version' and 'pmic_version' elements take the form 
> of
> +v. where the minor number may be omitted when it's zero, i.e.
> +v1.0 is the same as v1. If all versions of the 'plat_version' element's 
> match,
> +then a wildcard '*' should be used, e.g. 'v*'.
> +
> +The 'foundry_id', 'subtype', and 'mb' elements are one or more digits from 0
> +to 9.
> +
> +The 'panel' element must be one of the following strings:
> +
> +   720p
> +   fWVGA
> +   hd
> +   qHD
> +
> +The 'boot' element must be one of the following strings:
> +
> +   emmc_sdc1
> +   ufs
> +
> +The 'pmic' element must be one of the following strings:
> +
> +   pm8841
> +   pm8019
> +   pm8110
> +   pma8084
> +   pmi8962
> +   pmd9635
> +   pm8994
> +   pmi8994
> +   pm8916
> +   pm8004
> +   pm8909
> +
> +The 'pmic' element is specified in order of ascending USID. The PMIC in USID0
> +goes first, and then USID2, USID4, and finally USID6. Up to four PMICs may be
> +specified and no holes in the USID number space are allowed.
> +
> +Examples:
> +
> +   "qcom,msm8916-v1-cdp-pm8916-v2.1"

This is just awkward, but this...

> +
> +A CDP board with an msm8916 SoC, version 1 paired with a pm8916 PMIC of 
> version
> +2.1.
> +
> +   
> "qcom,apq8074-v2.0-2-dragonboard/1-v0.1-512MB-panel-qHD-boot-emmc_sdc1-pm8941-v0.2-pm8909-v2.2-pma8084-v3-pm8110-v1"

...this is just too much. It makes no sense to try to linearly
describe pretty much the whole hardware in the compatible string like
this when the information should be elsewhere in the DT.

If this is how it's done, why bother documenting the rest in device
tree at all? Why not just do a depth-first traversal of the DT and
create a string out of that and make that the compatible while you're
at it?

Consider this NAK:ed.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/7] ARM: at91/dt: sama5d2: add pio controller node

[Olof Johansson]

Hi Linus,

On Mon, Sep 21, 2015 at 11:24 AM, Linus Walleij
 wrote:
> On Wed, Sep 16, 2015 at 8:37 AM, Ludovic Desroches
>  wrote:
>
>> Add pio4 controller node to enable pinmux and gpio.
>>
>> Signed-off-by: Ludovic Desroches 
>
> Patch applied.

Please don't merge DT changes through driver trees unless there's a
very specific reason to do so, since it introduces random conflicts.


Thanks!

-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Olof Johansson]

Hi,

1) This seems to have broken BBB in -next for me, bisected down to this patch.

For bootlog:
http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html

2) Please avoid merging DT/platform code in your driver tree, Vinod,
at least without an ack from the platform maintainer. It can be a a
huge mess if they end up causing conflicts, so we always ask to merge
the DT changes through the platform maintainer (Tony in this case) by
default.


Thanks,

-Olof

On Fri, Oct 16, 2015 at 12:18 AM, Peter Ujfalusi  wrote:
> Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
> enable the DMA even crossbar with ti,am335x-edma-crossbar.
> With the new bindings boards can customize and tweak the DMA channel
> priority to match their needs. With the new binding the memcpy is safe
> to be used since with the old binding it was not possible for a driver
> to know which channel is allowed to be used as non HW triggered channel.
>
> Signed-off-by: Peter Ujfalusi 
> ---
>  arch/arm/boot/dts/am335x-evm.dts|  9 +---
>  arch/arm/boot/dts/am335x-pepper.dts | 11 +
>  arch/arm/boot/dts/am33xx.dtsi   | 96 
> ++---
>  3 files changed, 73 insertions(+), 43 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am335x-evm.dts 
> b/arch/arm/boot/dts/am335x-evm.dts
> index 1942a5c8132d..507980672c32 100644
> --- a/arch/arm/boot/dts/am335x-evm.dts
> +++ b/arch/arm/boot/dts/am335x-evm.dts
> @@ -743,8 +743,8 @@
>   {
> /* these are on the crossbar and are outlined in the
>xbar-event-map element */
> -   dmas = < 12
> -13>;
> +   dmas = <_xbar 12 0 1
> +   _xbar 13 0 2>;
> dma-names = "tx", "rx";
> status = "okay";
> vmmc-supply = <_en_reg>;
> @@ -766,11 +766,6 @@
> };
>  };
>
> - {
> -   ti,edma-xbar-event-map = /bits/ 16 <1 12
> -   2 13>;
> -};
> -
>   {
> status = "okay";
>  };
> diff --git a/arch/arm/boot/dts/am335x-pepper.dts 
> b/arch/arm/boot/dts/am335x-pepper.dts
> index 7106114c7464..39073b921664 100644
> --- a/arch/arm/boot/dts/am335x-pepper.dts
> +++ b/arch/arm/boot/dts/am335x-pepper.dts
> @@ -339,13 +339,6 @@
> ti,non-removable;
>  };
>
> - {
> -   /* Map eDMA MMC2 Events from Crossbar */
> -   ti,edma-xbar-event-map = /bits/ 16 <1 12
> -2 13>;
> -};
> -
> -
>   {
> /* Wifi & Bluetooth on MMC #3 */
> status = "okay";
> @@ -354,8 +347,8 @@
> vmmmc-supply = <_reg>;
> bus-width = <4>;
> ti,non-removable;
> -   dmas = < 12
> -13>;
> +   dmas = <_xbar 12 0 1
> +   _xbar 13 0 2>;
> dma-names = "tx", "rx";
>  };
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index d23e2524d694..6053e75c6e99 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -174,12 +174,54 @@
> };
>
> edma: edma@4900 {
> -   compatible = "ti,edma3";
> -   ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
> -   reg =   <0x4900 0x1>,
> -   <0x44e10f90 0x40>;
> +   compatible = "ti,edma3-tpcc";
> +   ti,hwmods = "tpcc";
> +   reg =   <0x4900 0x1>;
> +   reg-names = "edma3_cc";
> interrupts = <12 13 14>;
> -   #dma-cells = <1>;
> +   interrupt-names = "edma3_ccint", "emda3_mperr",
> + "edma3_ccerrint";
> +   dma-requests = <64>;
> +   #dma-cells = <2>;
> +
> +   ti,tptcs = <_tptc0 7>, <_tptc1 5>,
> +  <_tptc2 0>;
> +
> +   ti,edma-memcpy-channels = /bits/ 16 <20 21>;
> +   };
> +
> +   edma_tptc0: tptc@4980 {
> +   compatible = "ti,edma3-tptc";
> +   ti,hwmods = "tptc0";
> +   reg =   <0x4980 0x10>;
> +   interrupts = <112>;
> +   interrupt-names = "edma3_tcerrint";
> +   };
> +
> +   edma_tptc1: tptc@4990 {
> +   compatible = "ti,edma3-tptc";
> +   ti,hwmods = "tptc1";
> +   reg =   <0x4990 0x10>;
> +   interrupts = <113>;
> +   interrupt-names = "edma3_tcerrint";
> +   };
> +
> +   edma_tptc2: tptc@49a0 {
> +   compatible = "ti,edma3-tptc";
> +   ti,hwmods = "tptc2";
> +   reg =   <0x49a0 0x10>;
> + 

Re: [PATCH v7 0/3] Add Freescale LS1043a device tree

[Olof Johansson]

On Thu, Oct 29, 2015 at 04:12:03PM -0500, Li Yang wrote:
> Hi ARM SoC maintainers,
> 
> After several rounds of review I think the patch series is generally in
> good shape.  Can someone from the ARM maintainers group help to pick
> these patches up?

Ah! I saw your question on IRC and I went out to reply to one of the patches in
the V6 series based on that.

It's very very late in the release cycle, so this is material that should be
queued up for the next release instead. Please send it to us after -rc1 is out
and we'll be happy to queue it up for 4.5.


Thanks!


-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: uniphier: add system-bus-controller nodes

[Olof Johansson]

On Tue, Oct 27, 2015 at 12:21:05PM +0900, Masahiro Yamada wrote:
> The System Bus Controller block has two register regions,
> but having only the second one in a separate node was not nice.
> 
> Replace it with a new node with two register regions in it.
> 
> Signed-off-by: Masahiro Yamada 

Applied even though it's very late.

Based on the contents in the DT, the chips seem to share several identical
blocks at the same addresses. It could be worth trying to consolidate some
of the DT contents in a shared dtsi that contains these blocks.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/3] ARM: uniphier: add outer cache support and rework SMP operations

[Olof Johansson]

On Mon, Oct 26, 2015 at 01:16:50PM +0900, Masahiro Yamada wrote:
> Hi Arnd,
> 
> 
> 2015-10-10 15:59 GMT+09:00 Masahiro Yamada :
> > Hi Arnd,
> >
> >
> > 2015-10-06 15:22 GMT+01:00 Arnd Bergmann :
> >> On Tuesday 06 October 2015 16:20:23 Arnd Bergmann wrote:
> >>> On Friday 18 September 2015 13:37:31 Masahiro Yamada wrote:
> >>> > Hi Olof,
> >>> >
> >>> > Now Linux 4.3-rc1 is out, so I am back to this.
> >>> >
> >>> > 1/3: add outer cache support
> >>> > 2/3: rework SMP operations
> >>> > 3/3: add device tree nodes
> >>> >
> >>> > Because 2/3 highly depends on 1/3, I hope whole of this series
> >>> > is applied through ARM-SOC tree.
> >>>
> >>> Sorry for the long delay here. Is this the latest version of these
> >>> patches?
> >>>
> >>> Did Russell King review the first patch?
> >>> Is he ok with merging this through arm-soc?
> >>>
> >>
> >> I found an answer to the first question, as I see you posted
> >> v5 of the patchset in the meantime.
> >
> >
> > Yes, v5 is my latest version.
> >
> >
> > For the second question, Russell gave me some comments on the 1/3
> > and I answered.
> >
> > He mentioned nothing about merging the whole series thru arm-soc.
> > (At least, he was not opposed to it, I guess)
> >
> 
> Is it difficult to apply this series for the next merge window?
> V5 is the latest.
> No comment, but not applied.
> 
> Is there anything I can do but wait?

Looks like this one has fallen between the cracks, so sorry about that.

I checked in with Russell, and we'll pick this up for now even if it might
need some minor fixups down the road -- it seems good enough to go in.

Applied v5 of all 3 patches, first two to next/soc, last to next/dt.


Thanks, and apologies for the delay,

-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: uniphier: add I2C aliases for ProXstream2 boards

[Olof Johansson]

On Sat, Oct 24, 2015 at 12:25:31PM +0900, Masahiro Yamada wrote:
> Add aliases to fix the I2C indexes like the other UniPhier boards.
> 
> Signed-off-by: Masahiro Yamada 

Thanks, applied!


-Olof

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: dts: fix gpio-keys wakeup-source property

[Olof Johansson]

On Fri, Oct 16, 2015 at 05:01:36PM +0100, Sudeep Holla wrote:
> The keyboard driver for GPIO buttons(gpio-keys) checks for one of the
> two boolean properties to enable gpio buttons as wakeup source:
> 1. "wakeup-source" or
> 2. the legacy "gpio-key,wakeup"
> 
> However juno, ste-snowball and emev2-kzm9d dts file have a undetected
> "wakeup" property to indictate the wakeup source.
> 
> This patch fixes it by making use of "wakeup-source" property.
> 
> Cc: Magnus Damm 
> Acked-by: Simon Horman 
> Reviewed-by: Linus Walleij 
> Signed-off-by: Sudeep Holla 
> ---
>  arch/arm/boot/dts/emev2-kzm9d.dts |  8 
>  arch/arm/boot/dts/ste-snowball.dts| 10 +-
>  arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 12 ++--
>  3 files changed, 15 insertions(+), 15 deletions(-)
> 
> Hi ARM-SoC group,
> 
> Please consider this as a fix for v4.3 if possible.

Applied now, thanks.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] On-demand device probing

[Olof Johansson]

On Sat, Oct 17, 2015 at 8:19 AM, Rob Herring <robh...@kernel.org> wrote:
> On Fri, Oct 16, 2015 at 4:23 PM, Olof Johansson <o...@lixom.net> wrote:
>> Hi,
>>
>> I've bisected boot failures in next-20151016 down to patches in this branch:
>>
>> On Thu, Oct 15, 2015 at 4:42 AM, Tomeu Vizoso
>> <tomeu.viz...@collabora.com> wrote:
>>> Tomeu Vizoso (20):
>>>   driver core: handle -EPROBE_DEFER from bus_type.match()
>>
>> The machine it happened on was OMAP5UEVM:
>>
>> http://arm-soc.lixom.net/bootlogs/next/next-20151016/omap5uevm-arm-omap2plus_defconfig.html
>
> So this one is because the MMC node numbering changed. I don't know
> how to fix that other than with aliases, but that doesn't solve
> backwards compatibility.

Yep, aliases will take care of it in this case. This is where -next
fills a great purpose, we can make sure we get those aliases added in
before the patches go in.

>> But I've also seen it on tegra2, that one bisected down to:
>>
>>>  regulator: core: Probe regulators on demand
>>
>> http://arm-soc.lixom.net/bootlogs/next/next-20151016/seaboard-arm-multi_v7_defconfig.html
>
> This one you need a rootwait I think. The MMC scanning is not
> guaranteed to be done before the rootfs mounting AFAIK. There may be
> other problems, but we can't see them since it panics.

Embarrassing, I almost always do this and I'm surprised this machine
has been this stable without it.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] On-demand device probing

[Olof Johansson]

Hi,

I've bisected boot failures in next-20151016 down to patches in this branch:

On Thu, Oct 15, 2015 at 4:42 AM, Tomeu Vizoso
 wrote:
> Tomeu Vizoso (20):
>   driver core: handle -EPROBE_DEFER from bus_type.match()

The machine it happened on was OMAP5UEVM:

http://arm-soc.lixom.net/bootlogs/next/next-20151016/omap5uevm-arm-omap2plus_defconfig.html

But I've also seen it on tegra2, that one bisected down to:

>  regulator: core: Probe regulators on demand

http://arm-soc.lixom.net/bootlogs/next/next-20151016/seaboard-arm-multi_v7_defconfig.html



-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/4] platform/chrome: Support reading/writing the vboot context

[Olof Johansson]

On Mon, Sep 21, 2015 at 10:38:22AM -0300, Emilio L??pez wrote:
> Some EC implementations include a small nvram space used to store
> verified boot context data. This patch offers a way to expose this
> data to userspace.
> 
> Reviewed-by: Javier Martinez Canillas 
> Signed-off-by: Emilio L??pez 

Applied, thanks!


-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2 RESEND] power: reset: Add syscon reboot/poweroff device nodes for APM X-Gene platform

[Olof Johansson]

Hi,

On Fri, Aug 28, 2015 at 1:00 PM, Duc Dang dhd...@apm.com wrote:
 On Sun, Jul 26, 2015 at 11:37 AM, Olof Johansson o...@lixom.net wrote:

 On Sat, Jul 25, 2015 at 11:34:42AM -0700, Duc Dang wrote:
  Hi Olof,
 
  We are debating whether we should setup a company server (where we can
  have full control about storage, user permissions, backup, ...) or
  just use github.com to host our X-Gene kernel tree.
 
  Github seems already provide everything we need for a public source
  tree. Per your experience, what is your (and probably other
  maintainers) reference in git hosting server? Is there any
  inconvenience or difficulty for the maintainers to pull/merge code
  from Github versus from a company server?

 Hosting on github is fine with us in general. We do prefer to get
 signed pull requests in particular when they come from other sources
 than kernel.org, mostly because there's another third party involved in
 hosting the repo and by using signed tags there's less room for anyone
 to do bad stuff with the repository without someone noticing.

 If you host on github, please still use native git pull requests and not the
 ones that github provides via the web interface.

 Note however, that given the total volume of patches there's no strong need 
 for
 you to have a public repo just to send code to us -- we're happy applying
 patches at the volumes we're currently looking at. I can imagine other 
 reasons
 for why you would like to have a public repo though.

 Hi Olof,

 I have APM X-Gene git ready on github. According to your response
 above, I need to
 send a signed pull request. I created a PGP key on public server
 (https://pgp.mit.edu/pks/lookup?search=duc+dangop=index) and signed the tag 
 on
 APM X-Gene tree with my key.

 Please let me know if I need anything else before sending the git pull
 request to you.
 My key is not signed by any maintainer yet, would you mind to arrange some
 time next week to meet and help sign my key as well?

Yeah, I can do that, and you can get more signatures at Linaro Connect
in case you're attending.

(let's sort out details off-list).


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] arm/arm64: build all dtbs for CONPILE_TEST

[Olof Johansson]

On Thu, Aug 27, 2015 at 8:56 AM, Rob Herring r...@kernel.org wrote:
 Enable building all dtb files when COMPILE_TEST is enabled. The dtbs are
 not really dependent on a platform being enabled or any other kernel
 config, so for testing coverage it is convenient to build all of the
 dtbs.

 This builds all dts files in the tree, not just targets listed. This
 is simpler for arm64 which has a bunch of sub-dirs.

 Signed-off-by: Rob Herring r...@kernel.org
 Cc: Russell King li...@arm.linux.org.uk
 Cc: Catalin Marinas catalin.mari...@arm.com
 Cc: Will Deacon will.dea...@arm.com
 ---
 I've had this on my todo list for a while. RFC for now as I want to do
 the rest of the arches as well. I was originally thinking a new target
 for this, but thanks to Olof for the COMPILE_TEST suggestion.

 Rob

  arch/arm/boot/dts/Makefile   | 4 
  arch/arm64/boot/dts/Makefile | 6 ++
  2 files changed, 10 insertions(+)

 diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
 index 246473a..4968442a 100644
 --- a/arch/arm/boot/dts/Makefile
 +++ b/arch/arm/boot/dts/Makefile
 @@ -712,5 +712,9 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
  dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
  endif

 +dtstree:= $(srctree)/$(src)
 +
 +dtb-$(CONFIG_COMPILE_TEST) := $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard 
 $(dtstree)/*.dts))
 +
  always := $(dtb-y)
  clean-files:= *.dtb
 diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
 index 38913be..9f19390 100644
 --- a/arch/arm64/boot/dts/Makefile
 +++ b/arch/arm64/boot/dts/Makefile
 @@ -11,3 +11,9 @@ dts-dirs += sprd
  dts-dirs += xilinx

  subdir-y   := $(dts-dirs)
 +
 +dtstree:= $(srctree)/$(src)
 +
 +dtb-$(CONFIG_COMPILE_TEST) := $(patsubst $(dtstree)/%.dts,%.dtb, $(foreach 
 d,$(dts-dirs), $(wildcard $(dtstree)/$(d)/*.dts)))

I think it would be more appropriate to build dtb-n  here instead of
_any_ file ending in dts.

It would be useful to build all files, but it's not the behavior that
COMPILE_TEST usually has.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] ARM: NSP: add minimal Northstar Plus device tree

[Olof Johansson]

Hi,



On Wed, Aug 26, 2015 at 12:32 PM, Scott Branden sbran...@broadcom.com wrote:
 Hi Olof,

 Comments inline.

 On 15-08-25 04:36 PM, Olof Johansson wrote:

 Hi,

 I'm not sure what the strategy behind your cc:ing on this patch set
 is. I only got a couple of them in my inbox, and this one wasn't one
 of them. :)

 On Thu, Aug 20, 2015 at 10:46 AM, Jon Mason jonma...@broadcom.com wrote:

 Add a very minimalistic set of Northstar Plus Device Tree files which
 describes the SoC and the BCM958625 implementation.  The perpherials
 described are:

 ARM Cortex A9 CPU
 2 8250 UARTs
 ARM GIC
 PL310 L2 Cache
 ARM A9 Global timer

 Signed-off-by: Jon Mason jonma...@broadcom.com
 Signed-off-by: Kapil Hali kap...@broadcom.com
 Reviewed-by: Ray Jui r...@broadcom.com
 Reviewed-by: Scott Branden sbran...@broadcom.com


 Seeing reviewed-by already attached to a v1 of a patchset has limited
 value for someone on the outside.



 Reviewed-by is one of those tags that has a value that's mostly
 dependent on who it comes from. By not actually seeing the review and
 the feedback provided (and revisions made), less data is provided to
 tell if it's a valuable review or not.

 should we start using Ack'd instead then for things that were reviewed
 internally?

Best of all is to do more work in public, including sending the acks
on the list.

If you look around, it's relatively unusual that people post pre-acked
or pre-reviewed patches, even corporate contributors.

 Also, if you're posting the code you should probably have your name
 below Kapil's, since you're the one signing off the origin of the
 code. See Documentation/SubmittingPatches.txt for details on what
 S-o-b actually means.


 --- /dev/null
 +++ b/arch/arm/boot/dts/bcm-nsp.dtsi
 @@ -0,0 +1,105 @@
 +/*
 + *  BSD LICENSE
 + *
 + *  Copyright(c) 2015 Broadcom Corporation.  All rights reserved.
 + *
 + *  Redistribution and use in source and binary forms, with or without
 + *  modification, are permitted provided that the following conditions
 + *  are met:
 + *
 + ** Redistributions of source code must retain the above copyright
 + *  notice, this list of conditions and the following disclaimer.
 + ** Redistributions in binary form must reproduce the above
 copyright
 + *  notice, this list of conditions and the following disclaimer in
 + *  the documentation and/or other materials provided with the
 + *  distribution.
 + ** Neither the name of Broadcom Corporation nor the names of its
 + *  contributors may be used to endorse or promote products derived
 + *  from this software without specific prior written permission.
 + *
 + *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 + *  AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 + *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
 FOR
 + *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
 + *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
 INCIDENTAL,
 + *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 + *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
 USE,
 + *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
 ANY
 + *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 + *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
 USE
 + *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 + */


 I'm not sure we've seen BSD-only submissions before. I'll let DT
 maintainers (or Ian) speak up in case this would cause problems.


 Arnd is the one who require new DT content to be BSD licensed.
 We're just following his orders:

 http://lkml.iu.edu/hypermail/linux/kernel/1411.1/01109.html

Yeah, we've been asking for (at least) dual GPL/BSD. This was the
first time I noticed BSD-only which is why I brought it up.

I suspect it is not an issue in reality.

 +
 +#include dt-bindings/interrupt-controller/arm-gic.h
 +#include dt-bindings/interrupt-controller/irq.h
 +
 +#include skeleton.dtsi
 +
 +/ {
 +   compatible = brcm,nsp;
 +   model = Broadcom Northstar Plus SoC;
 +   interrupt-parent = gic;
 +
 +   cpus {
 +   #address-cells = 1;
 +   #size-cells = 0;
 +
 +   cpu@0 {
 +   device_type = cpu;
 +   compatible = arm,cortex-a9;
 +   next-level-cache = L2;
 +   reg = 0x0;
 +   };
 +   };
 +
 +   clocks {
 +   #address-cells = 1;
 +   #size-cells = 1;
 +   ranges;
 +
 +   periph_clk: periph_clk {
 +   compatible = fixed-clock;
 +   #clock-cells = 0;
 +   clock-frequency = 5;
 +   };
 +   };
 +
 +   uart0: serial@18000300 {
 +   compatible = ns16550a;
 +   reg = 0x18000300 0x100

Re: [PATCH 2/5] ARM: NSP: add minimal Northstar Plus device tree

[Olof Johansson]

On Wed, Aug 26, 2015 at 11:40 AM, Jon Mason jonma...@broadcom.com wrote:
 On Tue, Aug 25, 2015 at 04:36:45PM -0700, Olof Johansson wrote:
 Hi,

 I'm not sure what the strategy behind your cc:ing on this patch set
 is. I only got a couple of them in my inbox, and this one wasn't one
 of them. :)

 I sent them to the people listed as maintainers in get_maintainer.pl.
 It didn't seem to include you in all of them, but I thought the
 mailing list would be enough of a catch all.  My apologies.  I'll CC
 everyone listed as a maintainer on all of the patches in the future.

No worries. Just pointing it out since you asked me to look at the
patches and, well, I hadn't received them all. :)

 On Thu, Aug 20, 2015 at 10:46 AM, Jon Mason jonma...@broadcom.com wrote:
  Add a very minimalistic set of Northstar Plus Device Tree files which
  describes the SoC and the BCM958625 implementation.  The perpherials
  described are:
 
  ARM Cortex A9 CPU
  2 8250 UARTs
  ARM GIC
  PL310 L2 Cache
  ARM A9 Global timer
 
  Signed-off-by: Jon Mason jonma...@broadcom.com
  Signed-off-by: Kapil Hali kap...@broadcom.com
  Reviewed-by: Ray Jui r...@broadcom.com
  Reviewed-by: Scott Branden sbran...@broadcom.com

 Seeing reviewed-by already attached to a v1 of a patchset has limited
 value for someone on the outside.

 Reviewed-by is one of those tags that has a value that's mostly
 dependent on who it comes from. By not actually seeing the review and
 the feedback provided (and revisions made), less data is provided to
 tell if it's a valuable review or not.

 Also, if you're posting the code you should probably have your name
 below Kapil's, since you're the one signing off the origin of the
 code. See Documentation/SubmittingPatches.txt for details on what
 S-o-b actually means.

 We worked on it together, but I'll be happy to reorder as you suggest.



  --- /dev/null
  +++ b/arch/arm/boot/dts/bcm-nsp.dtsi
  @@ -0,0 +1,105 @@
  +/*
  + *  BSD LICENSE
  + *
  + *  Copyright(c) 2015 Broadcom Corporation.  All rights reserved.
  + *
  + *  Redistribution and use in source and binary forms, with or without
  + *  modification, are permitted provided that the following conditions
  + *  are met:
  + *
  + ** Redistributions of source code must retain the above copyright
  + *  notice, this list of conditions and the following disclaimer.
  + ** Redistributions in binary form must reproduce the above copyright
  + *  notice, this list of conditions and the following disclaimer in
  + *  the documentation and/or other materials provided with the
  + *  distribution.
  + ** Neither the name of Broadcom Corporation nor the names of its
  + *  contributors may be used to endorse or promote products derived
  + *  from this software without specific prior written permission.
  + *
  + *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
  + *  AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
  + *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
  + *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
  + *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  + *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
  + *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
  + *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
  + *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
  + *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
  + *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  + */

 I'm not sure we've seen BSD-only submissions before. I'll let DT
 maintainers (or Ian) speak up in case this would cause problems.

 I was following the precedent in arch/arm/boot/dts/bcm-cygnus.dtsi.
 If this is preferred to be GPL v2, then I will happily comply.

No, we'd rather have BSD-only than GPL-only, so keeping it as it is
should be OK.

  +   chosen {
  +   stdout-path = serial0:115200n8;
  +   };

 No way to mount a root filesystem yet? How much work remains for that
 to be possible, and what's the plan for that?

 It mounts rootfs.  I am adding the rootfs to the kernel and device
 tree blob via the u-boot mkimage command.  It boots all the way to
 shell without issue.

Sure, any system with memory can use ramdisk for root, that's not what I meant.

Still, based on post from Scott it sounds like NAND support isn't far away.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] ARM: NSP: add minimal Northstar Plus device tree

[Olof Johansson]

Hi,

I'm not sure what the strategy behind your cc:ing on this patch set
is. I only got a couple of them in my inbox, and this one wasn't one
of them. :)

On Thu, Aug 20, 2015 at 10:46 AM, Jon Mason jonma...@broadcom.com wrote:
 Add a very minimalistic set of Northstar Plus Device Tree files which
 describes the SoC and the BCM958625 implementation.  The perpherials
 described are:

 ARM Cortex A9 CPU
 2 8250 UARTs
 ARM GIC
 PL310 L2 Cache
 ARM A9 Global timer

 Signed-off-by: Jon Mason jonma...@broadcom.com
 Signed-off-by: Kapil Hali kap...@broadcom.com
 Reviewed-by: Ray Jui r...@broadcom.com
 Reviewed-by: Scott Branden sbran...@broadcom.com

Seeing reviewed-by already attached to a v1 of a patchset has limited
value for someone on the outside.

Reviewed-by is one of those tags that has a value that's mostly
dependent on who it comes from. By not actually seeing the review and
the feedback provided (and revisions made), less data is provided to
tell if it's a valuable review or not.

Also, if you're posting the code you should probably have your name
below Kapil's, since you're the one signing off the origin of the
code. See Documentation/SubmittingPatches.txt for details on what
S-o-b actually means.


 --- /dev/null
 +++ b/arch/arm/boot/dts/bcm-nsp.dtsi
 @@ -0,0 +1,105 @@
 +/*
 + *  BSD LICENSE
 + *
 + *  Copyright(c) 2015 Broadcom Corporation.  All rights reserved.
 + *
 + *  Redistribution and use in source and binary forms, with or without
 + *  modification, are permitted provided that the following conditions
 + *  are met:
 + *
 + ** Redistributions of source code must retain the above copyright
 + *  notice, this list of conditions and the following disclaimer.
 + ** Redistributions in binary form must reproduce the above copyright
 + *  notice, this list of conditions and the following disclaimer in
 + *  the documentation and/or other materials provided with the
 + *  distribution.
 + ** Neither the name of Broadcom Corporation nor the names of its
 + *  contributors may be used to endorse or promote products derived
 + *  from this software without specific prior written permission.
 + *
 + *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 + *  AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 + *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
 + *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
 + *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 + *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 + *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
 + *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
 + *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 + *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 + *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 + */

I'm not sure we've seen BSD-only submissions before. I'll let DT
maintainers (or Ian) speak up in case this would cause problems.


 +
 +#include dt-bindings/interrupt-controller/arm-gic.h
 +#include dt-bindings/interrupt-controller/irq.h
 +
 +#include skeleton.dtsi
 +
 +/ {
 +   compatible = brcm,nsp;
 +   model = Broadcom Northstar Plus SoC;
 +   interrupt-parent = gic;
 +
 +   cpus {
 +   #address-cells = 1;
 +   #size-cells = 0;
 +
 +   cpu@0 {
 +   device_type = cpu;
 +   compatible = arm,cortex-a9;
 +   next-level-cache = L2;
 +   reg = 0x0;
 +   };
 +   };
 +
 +   clocks {
 +   #address-cells = 1;
 +   #size-cells = 1;
 +   ranges;
 +
 +   periph_clk: periph_clk {
 +   compatible = fixed-clock;
 +   #clock-cells = 0;
 +   clock-frequency = 5;
 +   };
 +   };
 +
 +   uart0: serial@18000300 {
 +   compatible = ns16550a;
 +   reg = 0x18000300 0x100;
 +   interrupts = GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH;
 +   clock-frequency = 62499840;
 +   status = disabled;
 +   };
 +
 +   uart1: serial@18000400 {
 +   compatible = ns16550a;
 +   reg = 0x18000400 0x100;
 +   interrupts = GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH;
 +   clock-frequency = 62499840;
 +   status = disabled;
 +   };
 +
 +   gic: interrupt-controller@19021000 {
 +   compatible = arm,cortex-a9-gic;
 +   #interrupt-cells = 3;
 +   #address-cells = 0;
 +   interrupt-controller;
 +   reg = 0x19021000 0x1000,
 + 0x19020100 0x100;
 +   };
 +
 +   L2: l2-cache {
 +   compatible = arm,pl310-cache;
 + 

Re: [PATCH 0/3] ARM: uniphier: add outer cache support and rework SMP operations

[Olof Johansson]

Hi,

On Sun, Aug 23, 2015 at 7:18 PM, Masahiro Yamada
yamada.masah...@socionext.com wrote:
 1/3: add outer cache support
 2/3: rework SMP operations
 3/3: add device tree nodes

Timing of this is unfortunate, please resend after 4.3-rc1 is out and
we can queue it up.

 Because 2/3 highly depends on 1/3, I hope whole of this series
 is applied to ARM-SOC tree.

Review or acked-by from Russell would be appreciated in that case.

 Olof,
 From this series, I am using ARM: uniphier: rather than ARM: UniPhier:
 for the subject prefixes because I noticed you often rephased so when you
 applied my patches.
 Are sub-arch names in lower cases preferable in subject prefixes?

If you look at git log --no-merges --oneline arch/arm/mach-* you'll
see that most platforms use either all-caps or all-lowercase.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5] dtb: Create a common home for cross-architecture dtsi files.

[Olof Johansson]

Hi,

On Mon, Aug 24, 2015 at 1:58 PM, Rob Herring robherri...@gmail.com wrote:
 On Sun, Aug 23, 2015 at 6:52 PM, Olof Johansson o...@lixom.net wrote:
 On Sun, Aug 23, 2015 at 4:42 PM, Rob Herring robherri...@gmail.com wrote:
 On Sun, Aug 23, 2015 at 6:13 PM, Olof Johansson o...@lixom.net wrote:
 On Fri, Aug 14, 2015 at 2:21 PM, Rob Herring robherri...@gmail.com wrote:
 +arm-soc

 On Tue, Aug 11, 2015 at 5:07 AM, Ian Campbell ian.campb...@citrix.com 
 wrote:
 On Mon, 2015-08-03 at 17:06 +0100, Ian Campbell wrote:
 Commit 9ccd608070b6 (arm64: dts: add device tree for ARM SMM-A53x2 on
 LogicTile Express 20MG) added a new dts file to arch/arm64 which
 included ../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi, i.e. a
 .dtsi supplied by arch/arm.

 Unfortunately this causes some issues for the split device tree
 repository[0], since things get moved around there. In that context
 the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
 while the include is at src/arm/vexpress-v2m-rs1.dtsi.

 Hi Grant,

 Do you think there is any chance of getting this into 4.2-rc$NEXT or 
 shall
 we wait until 4.3? I'm assuming this should go via the DT tree, but maybe
 it should go via an ARM tree?

 I was assuming this would go thru the arm-soc tree which is why I
 acked it. It is getting a bit late for 4.2 at this point, but I guess
 the standalone tree remains broken for these platforms until this is
 done. Probably not such a big deal in grand scheme of things.

 I'm cc:d in the far tail of a thread, so I'll just comment here
 instead of further up:

 I'm not a fan at all of creating kernel/dts/arch/*, at least if
 there's expected to be contents in there.

 We don't have include/linux/asm-arch/ in the common tree either.
 Let's not create that for dts.

 I'd really like to move ALL dts files from arch/*. There's nothing
 really tied to the architecture. They may happen to use some bindings
 that only apply to an architecture, but fundamentally they don't
 depend on the arch. Also, I'd like to be able to do make all-dtbs
 and build every dtb in the tree.

 The main benefit of keeping it per architecture and platform is that
 it partitions the maintainer and review space a bit.

 Except we have a fire hose and a bunch of dripping faucets.

 Right now it's not possible to do even per-arch all-dtbs since only
 the currently configured platforms will get their dtbs compiled.

 I know. It's been on my todo list for a while. Having that per arch at
 least would be an improvement. Having it arch independent would mean I
 don't even need a cross-compiler (probably).

Yeah, seems like something that should work quite well in the scope of
Ian's tree if nothing else.

Maybe we should build both dtb-y and dtb-n when COMPILE_TEST is set? :)

 That said, I'm not crazy enough to propose this re-org in the kernel
 tree, but would like to do that if/when we moved dts files out of the
 kernel.

 I believe this is currently still quite firmly in the if stage. :(

 There's some renewed discussion around it recently, but still no one
 to step up and do it.

And I believe there are still major concerns from platform maintainers
that it will make development much more complicated.

 So, while I'm all for a prefix-based sharing of DTSI files, I don't
 want them to go in a common kernel/dts directory.

 Besides sharing some snippets between arm and arm64, what else is
 expected to need to go into such a shared location today?

 Overlays. You easily have the same sharing of common boards. There are
 also usecases of overlays on architectures that don't generally use DT
 (x86).

 Ok, overlays might make sense if they can be made to work generically
 enough and not be tied to expectations of the base board platform.

 That's the goal at least.

 Still, even then I don't see dts as a core kernel feature (kernel/*),
 lib/* might make more sense. And I don't want to see things like
 vexpress stuff in there.

 How's it any different than vexpress board stuff under drivers/.

I'm not sure how to interpret this argument. We don't have vexpress
board stuff under kernel/boards/, so we shouldn't have the
corresponding DT contents under kernel/dts.

 The original suggestion was under include/dt-bindings/. Not sure if
 you saw or like that?

We don't store driver code in include/, so I don't see why we should
store machine descriptions there.

Something like lib/ seems more appropriate. Or drivers/..., but I
suspect that could cause further confusion on the expected separation
of binding/hardware description and the consuming drivers.

 We could also see sharing between PPC and ARM on FSL networking parts,
 but I've not heard if they actually have that problem.

 Yeah, there could potentially be some sharing between MIPS and
 ARM{,64} too, but I don't know if we'll actually see it done.

 Yep, hard to say.

 Rob
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo

Re: [PATCH 0/3] ARM: uniphier: add outer cache support and rework SMP operations

[Olof Johansson]

On Mon, Aug 24, 2015 at 6:50 PM, Masahiro Yamada
yamada.masah...@socionext.com wrote:
 Hi Olof,


 2015-08-25 6:47 GMT+09:00 Olof Johansson o...@lixom.net:
 Hi,

 On Sun, Aug 23, 2015 at 7:18 PM, Masahiro Yamada
 yamada.masah...@socionext.com wrote:
 1/3: add outer cache support
 2/3: rework SMP operations
 3/3: add device tree nodes

 Timing of this is unfortunate, please resend after 4.3-rc1 is out and
 we can queue it up.

 Given that rc8 is out and the merge window has been delayed,
 is it still too late for 4.3-rc1?

Yes.

 Because 2/3 highly depends on 1/3, I hope whole of this series
 is applied to ARM-SOC tree.

 Review or acked-by from Russell would be appreciated in that case.

 Olof,
 From this series, I am using ARM: uniphier: rather than ARM: UniPhier:
 for the subject prefixes because I noticed you often rephased so when you
 applied my patches.
 Are sub-arch names in lower cases preferable in subject prefixes?

 If you look at git log --no-merges --oneline arch/arm/mach-* you'll
 see that most platforms use either all-caps or all-lowercase.

 I see.

 But, we use UniPhier (with only U and P capitalized) in our official
 documents.

That's OK, others surely capitalize their platform names too in
documentation. Some of them even have funkier capitalization than
that, such as SPEAr.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5] dtb: Create a common home for cross-architecture dtsi files.

[Olof Johansson]

On Sun, Aug 23, 2015 at 4:42 PM, Rob Herring robherri...@gmail.com wrote:
 On Sun, Aug 23, 2015 at 6:13 PM, Olof Johansson o...@lixom.net wrote:
 On Fri, Aug 14, 2015 at 2:21 PM, Rob Herring robherri...@gmail.com wrote:
 +arm-soc

 On Tue, Aug 11, 2015 at 5:07 AM, Ian Campbell ian.campb...@citrix.com 
 wrote:
 On Mon, 2015-08-03 at 17:06 +0100, Ian Campbell wrote:
 Commit 9ccd608070b6 (arm64: dts: add device tree for ARM SMM-A53x2 on
 LogicTile Express 20MG) added a new dts file to arch/arm64 which
 included ../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi, i.e. a
 .dtsi supplied by arch/arm.

 Unfortunately this causes some issues for the split device tree
 repository[0], since things get moved around there. In that context
 the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
 while the include is at src/arm/vexpress-v2m-rs1.dtsi.

 Hi Grant,

 Do you think there is any chance of getting this into 4.2-rc$NEXT or shall
 we wait until 4.3? I'm assuming this should go via the DT tree, but maybe
 it should go via an ARM tree?

 I was assuming this would go thru the arm-soc tree which is why I
 acked it. It is getting a bit late for 4.2 at this point, but I guess
 the standalone tree remains broken for these platforms until this is
 done. Probably not such a big deal in grand scheme of things.

 I'm cc:d in the far tail of a thread, so I'll just comment here
 instead of further up:

 I'm not a fan at all of creating kernel/dts/arch/*, at least if
 there's expected to be contents in there.

 We don't have include/linux/asm-arch/ in the common tree either.
 Let's not create that for dts.

 I'd really like to move ALL dts files from arch/*. There's nothing
 really tied to the architecture. They may happen to use some bindings
 that only apply to an architecture, but fundamentally they don't
 depend on the arch. Also, I'd like to be able to do make all-dtbs
 and build every dtb in the tree.

The main benefit of keeping it per architecture and platform is that
it partitions the maintainer and review space a bit.

Right now it's not possible to do even per-arch all-dtbs since only
the currently configured platforms will get their dtbs compiled.

 That said, I'm not crazy enough to propose this re-org in the kernel
 tree, but would like to do that if/when we moved dts files out of the
 kernel.

I believe this is currently still quite firmly in the if stage. :(

 So, while I'm all for a prefix-based sharing of DTSI files, I don't
 want them to go in a common kernel/dts directory.

 Besides sharing some snippets between arm and arm64, what else is
 expected to need to go into such a shared location today?

 Overlays. You easily have the same sharing of common boards. There are
 also usecases of overlays on architectures that don't generally use DT
 (x86).

Ok, overlays might make sense if they can be made to work generically
enough and not be tied to expectations of the base board platform.

Still, even then I don't see dts as a core kernel feature (kernel/*),
lib/* might make more sense. And I don't want to see things like
vexpress stuff in there.

 We could also see sharing between PPC and ARM on FSL networking parts,
 but I've not heard if they actually have that problem.

Yeah, there could potentially be some sharing between MIPS and
ARM{,64} too, but I don't know if we'll actually see it done.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5] dtb: Create a common home for cross-architecture dtsi files.

[Olof Johansson]

On Fri, Aug 14, 2015 at 2:21 PM, Rob Herring robherri...@gmail.com wrote:
 +arm-soc

 On Tue, Aug 11, 2015 at 5:07 AM, Ian Campbell ian.campb...@citrix.com wrote:
 On Mon, 2015-08-03 at 17:06 +0100, Ian Campbell wrote:
 Commit 9ccd608070b6 (arm64: dts: add device tree for ARM SMM-A53x2 on
 LogicTile Express 20MG) added a new dts file to arch/arm64 which
 included ../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi, i.e. a
 .dtsi supplied by arch/arm.

 Unfortunately this causes some issues for the split device tree
 repository[0], since things get moved around there. In that context
 the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
 while the include is at src/arm/vexpress-v2m-rs1.dtsi.

 Hi Grant,

 Do you think there is any chance of getting this into 4.2-rc$NEXT or shall
 we wait until 4.3? I'm assuming this should go via the DT tree, but maybe
 it should go via an ARM tree?

 I was assuming this would go thru the arm-soc tree which is why I
 acked it. It is getting a bit late for 4.2 at this point, but I guess
 the standalone tree remains broken for these platforms until this is
 done. Probably not such a big deal in grand scheme of things.

I'm cc:d in the far tail of a thread, so I'll just comment here
instead of further up:

I'm not a fan at all of creating kernel/dts/arch/*, at least if
there's expected to be contents in there.

We don't have include/linux/asm-arch/ in the common tree either.
Let's not create that for dts.

So, while I'm all for a prefix-based sharing of DTSI files, I don't
want them to go in a common kernel/dts directory.

Besides sharing some snippets between arm and arm64, what else is
expected to need to go into such a shared location today?


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: dts: UniPhier: fix PPI interrupt CPU mask of timer nodes

[Olof Johansson]

On Wed, Aug 19, 2015 at 02:49:26PM +0900, Masahiro Yamada wrote:
 This SoC is integrated with 4 Cortex-A9 cores.  The GIC bindings
 document says that the bits[15:8] of the 3rd cell of the interrupts
 property represents PPI interrupt CPU mask.  Because the timer
 interrupts are wired to all of the 4 cores, bits[15:8] should be set
 to 0xf.
 
 Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com
 ---
 
 Changes in v2:
   - Fix git-description

Thanks, applied.


-Olof

--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] ARM: dts: UniPhier: add ProXstream2 and PH1-LD6b SoC/board support

[Olof Johansson]

On Wed, Aug 12, 2015 at 3:14 PM, Masahiro Yamada
yamada.masah...@socionext.com wrote:
 Hi Olof,


 2015-08-11 22:07 GMT+09:00 Olof Johansson o...@lixom.net:
 Hi,

 On Tue, Aug 04, 2015 at 08:21:04PM +0900, Masahiro Yamada wrote:
 Initial version of DTSI for ProXstream2 and PH1-LD6b and DTS for
 PH1-LD6b reference board.

 Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com
 ---

  arch/arm/boot/dts/Makefile  |   3 +-
  arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts | 105 +++
  arch/arm/boot/dts/uniphier-ph1-ld6b.dtsi|  67 +++
  arch/arm/boot/dts/uniphier-proxstream2.dtsi | 273 
 
  4 files changed, 447 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
  create mode 100644 arch/arm/boot/dts/uniphier-ph1-ld6b.dtsi
  create mode 100644 arch/arm/boot/dts/uniphier-proxstream2.dtsi

 diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
 index 246473a..6eb3f2f 100644
 --- a/arch/arm/boot/dts/Makefile
 +++ b/arch/arm/boot/dts/Makefile
 @@ -645,7 +645,8 @@ dtb-$(CONFIG_ARCH_UNIPHIER) += \
   uniphier-ph1-sld3-ref.dtb \
   uniphier-ph1-ld4-ref.dtb \
   uniphier-ph1-pro4-ref.dtb \
 - uniphier-ph1-sld8-ref.dtb
 + uniphier-ph1-sld8-ref.dtb \
 + uniphier-ph1-ld6b-ref.dtb

 Please always add entries here sorted, don't just append. I've fixed it
 up for you this time.



 Please do not do that (without my ack).

I'm not going to go get your ack for something as trivial as this. We
do make sure subplatform maintainers are in the loop and get to review
code that touches their platform, but in this case this was a shared
makefile and there were no functional changes.

 It was already sorted from old SoC to new SoC.

 Sorting chronologically (in other words, in the order of chip ID)
 makes more sense than sorting alphabetically.

No, it doesn't. All entries in these files should be sorted
alphabetically. Sometimes we miss out on it, but it's the goal.

If you sort chronologically it's impossible for anyone but people
intimately familiar with UniPhier's product history to add any new
entries in the right location. Also, since it's likely that newer
chips will be introduced over time, new entries are likely to just be
appends instead of inserted at more varied locations in the files.

Append-only additions are more likely to have add/add conflicts, which
is why we're preferring alphabetical sort order in the first place.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/4] Device Tree updates of UniPhier SoCs for Linux 4.3

[Olof Johansson]

On Wed, Aug 12, 2015 at 10:39:47PM +0900, Masahiro Yamada wrote:
 2015-08-11 22:20 GMT+09:00 Olof Johansson o...@lixom.net:
  On Thu, Aug 06, 2015 at 07:37:44PM +0900, Masahiro Yamada wrote:
  Hi Olof and Arnd,
 
  Here are a little more updates for device trees for UniPhier SoCs.
 
  Please consider applying this series to your ARM-SOC tree.
 
  Thanks!
 
  Hi,
 
  Please always comment on when the previous when you respin. I didn't
  see this thread until after I had applied v1.
 
  I've taken 2/4 directly now, since it's the only difference.
 
 
 Instead, build fails between commit a5e921b4771 and 63ef577d9
 because 2/4 is a pre-requisite patch for 3/4 and /4/4.
 
 
 Maybe I should have sent a pull-request instead of patches.

The most important thing you should have done is followed up on the bad
patch series. Sending this as a pull request wouldn't have saved you if
you had just sent a second pull request without withdrawing the first one.

Sending patches and pull requests make little different for us for a new
platform with only a few patches per release. We still need to review
your code before we merge it. Actually, doing it as patches is sometimes
a bit easier since we can touch up trivial things instead of asking you
to redo the pull request.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] Device Tree updates of UniPhier SoCs for Linux 4.3

[Olof Johansson]

On Tue, Aug 04, 2015 at 08:21:01PM +0900, Masahiro Yamada wrote:
 Hi Olof and Arnd,
 
 
 Here are a little more updates for device trees for UniPhier SoCs.
 
 Please consider applying this series to your ARM-SOC tree.
 
 Thanks!
 
 
 
 Masahiro Yamada (3):
   ARM: dts: UniPhier: add I2C controller device nodes
   ARM: dts: UniPhier: add PH1-Pro5 SoC support
   ARM: dts: UniPhier: add ProXstream2 and PH1-LD6b SoC/board support

Thanks, applied all 3 to next/dt with minor tweaks to the subject line.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] ARM: dts: UniPhier: add ProXstream2 and PH1-LD6b SoC/board support

[Olof Johansson]

Hi,

On Tue, Aug 04, 2015 at 08:21:04PM +0900, Masahiro Yamada wrote:
 Initial version of DTSI for ProXstream2 and PH1-LD6b and DTS for
 PH1-LD6b reference board.
 
 Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com
 ---
 
  arch/arm/boot/dts/Makefile  |   3 +-
  arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts | 105 +++
  arch/arm/boot/dts/uniphier-ph1-ld6b.dtsi|  67 +++
  arch/arm/boot/dts/uniphier-proxstream2.dtsi | 273 
 
  4 files changed, 447 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
  create mode 100644 arch/arm/boot/dts/uniphier-ph1-ld6b.dtsi
  create mode 100644 arch/arm/boot/dts/uniphier-proxstream2.dtsi
 
 diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
 index 246473a..6eb3f2f 100644
 --- a/arch/arm/boot/dts/Makefile
 +++ b/arch/arm/boot/dts/Makefile
 @@ -645,7 +645,8 @@ dtb-$(CONFIG_ARCH_UNIPHIER) += \
   uniphier-ph1-sld3-ref.dtb \
   uniphier-ph1-ld4-ref.dtb \
   uniphier-ph1-pro4-ref.dtb \
 - uniphier-ph1-sld8-ref.dtb
 + uniphier-ph1-sld8-ref.dtb \
 + uniphier-ph1-ld6b-ref.dtb

Please always add entries here sorted, don't just append. I've fixed it
up for you this time.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/4] Device Tree updates of UniPhier SoCs for Linux 4.3

[Olof Johansson]

On Thu, Aug 06, 2015 at 07:37:44PM +0900, Masahiro Yamada wrote:
 Hi Olof and Arnd,
 
 Here are a little more updates for device trees for UniPhier SoCs.
 
 Please consider applying this series to your ARM-SOC tree.
 
 Thanks!

Hi,

Please always comment on when the previous when you respin. I didn't
see this thread until after I had applied v1.

I've taken 2/4 directly now, since it's the only difference.


Thanks!


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ARM: dts: keystone: fix dt bindings to use post div register for mainpll

[Olof Johansson]

On Fri, Jul 31, 2015 at 08:30:03AM -0700, santosh shilimkar wrote:
 Olof,
 
 As discussed patch 1/2 is already made it via clock tree. Please
 pick the subject fix for your upcoming fixes pull request.
 
 On 5/29/2015 9:04 AM, Murali Karicheri wrote:
 All of the keystone devices have a separate register to hold post
 divider value for main pll clock. Currently the fixed-postdiv
 value used for k2hk/l/e SoCs works by sheer luck as u-boot happens to
 use a value of 2 for this. Now that we have fixed this in the pll
 clock driver change the dt bindings for the same.
 
 Signed-off-by: Murali Karicheri m-kariche...@ti.com
 ---
 Acked-by: Santosh Shilimkar ssant...@kernel.org
 
 

Thanks, applied.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] ARM: UniPhier: update DTS and MAINTAINERS

[Olof Johansson]

On Sat, Jul 25, 2015 at 04:23:21PM +0900, Masahiro Yamada wrote:
 Hi Arnd and Olof,
 
 The pinctrl drivers for UniPhier SoCs were accepted by Linus Walleij
 into the linux-pinctrl subsystem.
 
 Here is a small series I'd like you to merge into the ARM-SOC subsystem
 to use my pinctrl drivers.
 

Thanks, applied 1 and 2 to next/dt, the third I added to next/soc.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2 RESEND] power: reset: Add syscon reboot/poweroff device nodes for APM X-Gene platform

[Olof Johansson]

On Sat, Jul 25, 2015 at 11:34:42AM -0700, Duc Dang wrote:
 Hi Olof,
 
 We are debating whether we should setup a company server (where we can
 have full control about storage, user permissions, backup, ...) or
 just use github.com to host our X-Gene kernel tree.
 
 Github seems already provide everything we need for a public source
 tree. Per your experience, what is your (and probably other
 maintainers) reference in git hosting server? Is there any
 inconvenience or difficulty for the maintainers to pull/merge code
 from Github versus from a company server?

Hosting on github is fine with us in general. We do prefer to get
signed pull requests in particular when they come from other sources
than kernel.org, mostly because there's another third party involved in
hosting the repo and by using signed tags there's less room for anyone
to do bad stuff with the repository without someone noticing.

If you host on github, please still use native git pull requests and not the
ones that github provides via the web interface.

Note however, that given the total volume of patches there's no strong need for
you to have a public repo just to send code to us -- we're happy applying
patches at the volumes we're currently looking at. I can imagine other reasons
for why you would like to have a public repo though.


Thanks,

-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2 RESEND] power: reset: Add syscon reboot/poweroff device nodes for APM X-Gene platform

[Olof Johansson]

Hi,


On Wed, Jul 22, 2015 at 10:46 AM, Loc Ho l...@apm.com wrote:
 Hi Olof,

 This patch set adds syscon reboot/poweroff device nodes to support reboot 
 and
 poweroff features on X-Gene platform.

 Tai Nguyen (2):
   power: reset: Add syscon reboot device node for APM X-Gene platform
   power: reset: Add syscon poweroff device node for APM X-Gene Mustang 
 platform

  arch/arm64/boot/dts/apm/apm-mustang.dts |   12 
  arch/arm64/boot/dts/apm/apm-storm.dtsi  |   12 
  2 files changed, 24 insertions(+)

 Hi,

 It's unclear to me what you want to happen to these patches. They are
 sent to a long list of to-recipients, one of which is a...@kernel.org. In
 general, specify the person you want to take action on the patch in to
 with the rest on cc.

 Is there an owner for all DT node files? Is that Catalina as he is
 owner for ARM64 arch folder?

The ARM64 DT changes get merged through arm-soc, i.e. they get sent to
a...@kernel.org by the platform maintainers and picked up by us from
there (Arnd, Kevin or myself).

 We generally ask that patches first go to the subarch maintainers,
 and they in turn send it on to us (either through a pull request or
 by sending the patches to be applied). In the case of X-Gene, there is
 no general platform maintainer so we keep getting patches from various
 engineers at APM and it's unclear to us what your intentions are.

 I'd prefer to see one (to start with) person in charge of these (i.e. one
 maintainer from the APM side). Please add that person to the MAINTAINERS
 file as well.

 Are you suggesting that we have one person to start an GIT with
 kernel.org to keep all these misc ack'ed patches for X-Gene (APM) that
 don't seems to have an maintainer/home. Then request an pull by you?

Pull requests are convenient for us, but if it's just a patch or two,
sending them directly in email is fine as well.

What I want to avoid is a large number of people sending us patches
directly, which is why we ask for platform maintainers to coordinate
and aggregate patches to send on to us. That way we have one person
down the chain that we knows how we want the code delivered, and that
can do a round of reviews before we get it.


Thanks!


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2 RESEND] power: reset: Add syscon reboot/poweroff device nodes for APM X-Gene platform

[Olof Johansson]

On Wed, Jul 22, 2015 at 11:10 AM, Loc Ho l...@apm.com wrote:
 Hi Olof,,


 This patch set adds syscon reboot/poweroff device nodes to support reboot 
 and
 poweroff features on X-Gene platform.

 Tai Nguyen (2):
   power: reset: Add syscon reboot device node for APM X-Gene platform
   power: reset: Add syscon poweroff device node for APM X-Gene Mustang 
 platform

  arch/arm64/boot/dts/apm/apm-mustang.dts |   12 
  arch/arm64/boot/dts/apm/apm-storm.dtsi  |   12 
  2 files changed, 24 insertions(+)

 Hi,

 It's unclear to me what you want to happen to these patches. They are
 sent to a long list of to-recipients, one of which is a...@kernel.org. In
 general, specify the person you want to take action on the patch in to
 with the rest on cc.

 Is there an owner for all DT node files? Is that Catalina as he is
 owner for ARM64 arch folder?

 The ARM64 DT changes get merged through arm-soc, i.e. they get sent to
 a...@kernel.org by the platform maintainers and picked up by us from
 there (Arnd, Kevin or myself).

 We generally ask that patches first go to the subarch maintainers,
 and they in turn send it on to us (either through a pull request or
 by sending the patches to be applied). In the case of X-Gene, there is
 no general platform maintainer so we keep getting patches from various
 engineers at APM and it's unclear to us what your intentions are.

 I'd prefer to see one (to start with) person in charge of these (i.e. one
 maintainer from the APM side). Please add that person to the MAINTAINERS
 file as well.

 Are you suggesting that we have one person to start an GIT with
 kernel.org to keep all these misc ack'ed patches for X-Gene (APM) that
 don't seems to have an maintainer/home. Then request an pull by you?

 Pull requests are convenient for us, but if it's just a patch or two,
 sending them directly in email is fine as well.

 If there is an chance in pulling this power off/reset patches for
 4.2-rc4, can you pull in as patches? Otherwise, we will go the GIT
 pull request.

We can definitely pick them up and queue them for 4.3 (see below). We
normally want the bulk of patches before -rc4/5, but we take smaller
updates closer to the merge window as well.

 What I want to avoid is a large number of people sending us patches
 directly, which is why we ask for platform maintainers to coordinate
 and aggregate patches to send on to us. That way we have one person
 down the chain that we knows how we want the code delivered, and that
 can do a round of reviews before we get it.

 We will get an GIT setup up for this and Duc Dang will contact you for
 pull request when ready.

Ok, sounds good. If you have people in the bay area that need PGP keys
signed for this, I'd be happy to help.

As far as the current DT patches, there's been several sent by
different people. Please aggregate them into one patch series and send
that (as git send-email is fine) to us to queue for 4.3.


Thanks!


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: Add STM32429i-EVAL board support

[Olof Johansson]

Hi,

On Sun, Jul 12, 2015 at 2:39 AM, Maxime Coquelin
mcoquelin.st...@gmail.com wrote:

 +/ {
 +   model = STMicroelectronics STM32429i-EVAL board;
 +   compatible = st,stm32429i-eval, st,stm32f429;
 +
 +   chosen {
 +   bootargs = console=ttyS0,115200 root=/dev/ram 
 rdinit=/linuxrc;
 +   linux,stdout-path = usart1;

You should use stdout-path here instead, and with that you'll no
longer need the console arg in the bootargs.

See: https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/2] Add support for PL172 memory-controller

[Olof Johansson]

On Mon, Jul 13, 2015 at 11:20:10PM +0200, Joachim Eastwood wrote:
 This patch set adds a memory driver and documentation for the ARM
 PL172. This driver  makes it possible to configure the static
 memory chip selects on the ARM PL172 MultiPort Memory Controller
 from a set of properties in DT. Configuration of dynamic memory
 (SDRAM) is not supported and is left to the boot loader. The
 intended usage is to setup timing and configuration for static
 memory devices like NAND and NOR Flash before they are probed by
 a driver. Pretty much what like all the other memory drivers do.
 
 As drivers/memory doesn't seem to have a maintainer of it's own
 I hope this patch set can go through the armsoc-drivers branch.
 
 The previous version of the patch set didn't recive recivce much
 feedback and the cover letter can be found here:
 http://marc.info/?l=devicetreem=143024189625522w=2
 
 DT bindings for PL172 is based on the bindings for the TI AEMIF
 memory controller. PL172 can be found on a number of NXP devices
 like the LPC18xx family.
 
 Tested on Embedded Artists' LPC4357 Developer's Kit with NOR Flash
 (SST39VF320) and 74LCV16374 (gpio-74x164) on MPMC.
 
 Changes since v1:
  - Add proper commit messages
  - Misc clean ups
 
 Joachim Eastwood (2):
   memory: add ARM PL172 MultiPort Memory Controller driver
   doc: dt: add documentation for pl172 memory bindings

Thanks, I've applied both patches to next/drivers.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm64: dts: sprd: adding ETM entries to Spreadtrum SC9836

[Olof Johansson]

On Wed, Jul 15, 2015 at 03:05:48PM +0800, Chunyan Zhang wrote:
 Since ETMv4 driver has been merged, this patch adds ETM nodes for SC9836,
 and four funnel input ports to connect with ETM output ports.
 
 Signed-off-by: Chunyan Zhang zhang.chun...@linaro.org

Thanks, applied.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: cros-ec-keyboard: Add support for some Japanese keys

[Olof Johansson]

On Tue, May 05, 2015 at 11:10:42AM -0700, Doug Anderson wrote:
 Chris,
 
 Since there's no clear architecture here, I'd bet Olof would be the
 one to take this.  I added him to this email, but he might request
 that you resend the patch with him in the To: line.
 
 Other than that:
 
 Reviewed-by: Doug Anderson diand...@chromium.org

Very belatedly applied for 4.2 fixes.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2 RESEND] power: reset: Add syscon reboot/poweroff device nodes for APM X-Gene platform

[Olof Johansson]

On Tue, Jun 02, 2015 at 12:19:05PM -0700, Tai Nguyen wrote:
 This patch set adds syscon reboot/poweroff device nodes to support reboot and
 poweroff features on X-Gene platform. 
 
 Tai Nguyen (2):
   power: reset: Add syscon reboot device node for APM X-Gene platform
   power: reset: Add syscon poweroff device node for APM X-Gene Mustang 
 platform
 
  arch/arm64/boot/dts/apm/apm-mustang.dts |   12 
  arch/arm64/boot/dts/apm/apm-storm.dtsi  |   12 
  2 files changed, 24 insertions(+)

Hi,

It's unclear to me what you want to happen to these patches. They are
sent to a long list of to-recipients, one of which is a...@kernel.org. In
general, specify the person you want to take action on the patch in to
with the rest on cc.

We generally ask that patches first go to the subarch maintainers,
and they in turn send it on to us (either through a pull request or
by sending the patches to be applied). In the case of X-Gene, there is
no general platform maintainer so we keep getting patches from various
engineers at APM and it's unclear to us what your intentions are.

I'd prefer to see one (to start with) person in charge of these (i.e. one
maintainer from the APM side). Please add that person to the MAINTAINERS
file as well.


Thanks!

-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v0] arm64: dts: Add APM X-Gene standby GPIO controller DTS entries

[Olof Johansson]

On Thu, Jun 04, 2015 at 02:19:04PM +0700, Y Vo wrote:
 Add standby domain gpio controller for APM X-Gene SoC platform.
 
 Signed-off-by: Y Vo y...@apm.com

Hi,

What does patch v0 mean here? Is this just an RFC for comments or do
you want us to apply it?

Again, same comments as I made on another patch from APM developers
today: You all send patches to us without coordination. Please find one
maintainer of the common pieces and have him/her coordinate or at least
ack these patches so we have one submaintainer to deal with instead of
the whole team. (Over time that can of course be expanded to several
people, but it's easiest to start with a single person).


Thanks,

-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/3] ARM: add UART and EHCI support for UniPhier DTS and enable them.

[Olof Johansson]

On Fri, Jul 10, 2015 at 01:53:57PM +0900, Masahiro Yamada wrote:
 The basic support for UniPhier SoC family (arch/arm/mach-uniphier)
 was mainlined at Linux 4.2-rc1.
 I am now tackling some drivers to support them in the mainline.
 
 I've got UART and EHCI done, so I'd like to enable them from
 the ARM-SOC subsystem.
 
 
 Changes in v2:
   - Add chip-specific compatible strings socionext,uniphier-ehci
 

Applied 1-3 to next/dt and next/defconfig. Thanks!


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 6/8] mfd: cros_ec: Support multiple EC in a system

[Olof Johansson]

On Fri, Jun 05, 2015 at 11:17:30AM +0100, Lee Jones wrote:
 On Thu, 04 Jun 2015, Javier Martinez Canillas wrote:
 
  From: Gwendal Grignou gwen...@chromium.org
  
  Chromebooks can have more than one Embedded Controller so the
  cros_ec device id has to be incremented for each EC registered.
  
  Add a new structure to represent multiple EC as different char
  devices (e.g: /dev/cros_ec, /dev/cros_pd). It connects to
  cros_ec_device and allows sysfs inferface for cros_pd.
  
  Also reduce number of allocated objects, make chromeos sysfs
  class object a static and add refcounting to prevent object
  deletion while command is in progress.
  
  Signed-off-by: Gwendal Grignou gwen...@chromium.org
  Reviewed-by: Dmitry Torokhov d...@chromium.org
  Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
  Tested-by: Heiko Stuebner he...@sntech.de
  ---
  
  Changes since v5:
   - Don't allow to change the device name from DT. Suggested by Lee Jones.
   - Expand error messages in case of mfd_add_devices() failure.
 Suggested by Lee Jones.
  
  Changes since v4:
   - Use cros-ec-name DT property instead of devname. Suggested by Lee Jones.
   - Pass PLATFORM_DEVID_AUTO directly to mfd_add_devices().
 Suggested by Lee Jones.
   - Add Heiko Stuebner tested-by tag.
   - Fix get_version by passing the cmd_offset to EC_CMD_GET_VERSION.
  
  Changes since v3:
   - Add defines for the EC and PD index constants.
   - Remove cros_ec_dev_register() and declare the mfd_cells as static 
  structs.
 Suggested by Lee Jones.
   - Add a new line before the return statement in cros_ec_dev_register().
 Suggested by Lee Jones.
  
  Changes since v2: None
  
  Changes since v1:
- Squash patch that adds support to represent EC's as different
  char devices (e.g: /dev/cros_ec, /dev/cros_pd):
  https://chromium-review.googlesource.com/#/c/217297/
  Suggested by Gwendal Grignou
- Use cros_ec instead of cros-ec in the subject line to be consistent.
  Suggested by Gwendal Grignou
  ---
   drivers/input/keyboard/cros_ec_keyb.c  |   2 +-
   drivers/mfd/cros_ec.c  |  52 ++--
   drivers/mfd/cros_ec_i2c.c  |   1 -
   drivers/mfd/cros_ec_spi.c  |   1 -
   drivers/platform/chrome/cros_ec_dev.c  | 130 
  -
   drivers/platform/chrome/cros_ec_dev.h  |   7 --
   drivers/platform/chrome/cros_ec_lightbar.c |  75 +
   drivers/platform/chrome/cros_ec_lpc.c  |   1 -
   drivers/platform/chrome/cros_ec_sysfs.c|  48 +--
   include/linux/mfd/cros_ec.h|  44 --
   10 files changed, 234 insertions(+), 127 deletions(-)
 
 For my own reference:
   Acked-by: Lee Jones lee.jo...@linaro.org
 
 Let me know when you have all the appropriate Acks and I'll apply the
 set.

Whole series:

Acked-by: Olof Johansson o...@lixom.net

I'm OK with this going through the mfd tree, since there's nothing queued up
for chrome-platform that this would conflict with.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm64: dts: Add Qualcomm APQ8016 SBC evaluation board dts

[Olof Johansson]

On Mon, Mar 23, 2015 at 05:51:05PM -0500, Kumar Gala wrote:
 Add initial device tree support for Qualcomm APQ8016 SBC Evaluation board.
 This board is also referred to as the DragonBoard 410c.
 
 Signed-off-by: Kumar Gala ga...@codeaurora.org

Hi,

Patch applied but see comment below.

 ---
  arch/arm64/boot/dts/qcom/Makefile |  2 +-
  arch/arm64/boot/dts/qcom/apq8016-sbc.dts  | 22 +
  arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 33 
 +++
  3 files changed, 56 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm64/boot/dts/qcom/apq8016-sbc.dts
  create mode 100644 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
 
 diff --git a/arch/arm64/boot/dts/qcom/Makefile 
 b/arch/arm64/boot/dts/qcom/Makefile
 index 360ec4c..8e94af6 100644
 --- a/arch/arm64/boot/dts/qcom/Makefile
 +++ b/arch/arm64/boot/dts/qcom/Makefile
 @@ -1,4 +1,4 @@
 -dtb-$(CONFIG_ARCH_QCOM)  += msm8916-mtp.dtb
 +dtb-$(CONFIG_ARCH_QCOM)  += apq8016-sbc.dtb msm8916-mtp.dtb
  
  always   := $(dtb-y)
  subdir-y := $(dts-dirs)
 diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dts 
 b/arch/arm64/boot/dts/qcom/apq8016-sbc.dts
 new file mode 100644
 index 000..3c563e7
 --- /dev/null
 +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dts
 @@ -0,0 +1,22 @@
 +/*
 + * Copyright (c) 2015, The Linux Foundation. All rights reserved.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 and
 + * only version 2 as published by the Free Software Foundation.
 + *
 + * This program 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.
 + */

Your 32-bit DTS:es lack copyright headers alltogether, and this is GPLv2 only.
Given the movement to use dual GPL/X11 on DTS contents, it might be a good idea
to kick off that process with your legal team if you haven't already. Please
follow up with copyright revisions as appropriate, on both 32 and 64-bit.


-Olof

--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm64: dts: Add Qualcomm APQ8016 SBC evaluation board dts

[Olof Johansson]

On Fri, Apr 03, 2015 at 11:12:17AM -0700, Olof Johansson wrote:
 On Mon, Mar 23, 2015 at 05:51:05PM -0500, Kumar Gala wrote:
  Add initial device tree support for Qualcomm APQ8016 SBC Evaluation board.
  This board is also referred to as the DragonBoard 410c.
  
  Signed-off-by: Kumar Gala ga...@codeaurora.org
 
 Hi,
 
 Patch applied but see comment below.

You both sent us the patch and a pull request with this patch in
it. Please only send patches to a...@kernel.org that you intend for us
to apply.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm64: dts: Add Qualcomm APQ8016 SBC evaluation board dts

[Olof Johansson]

On Fri, Apr 03, 2015 at 11:14:01AM -0700, Olof Johansson wrote:
 On Fri, Apr 03, 2015 at 11:12:17AM -0700, Olof Johansson wrote:
  On Mon, Mar 23, 2015 at 05:51:05PM -0500, Kumar Gala wrote:
   Add initial device tree support for Qualcomm APQ8016 SBC Evaluation board.
   This board is also referred to as the DragonBoard 410c.
   
   Signed-off-by: Kumar Gala ga...@codeaurora.org
  
  Hi,
  
  Patch applied but see comment below.
 
 You both sent us the patch and a pull request with this patch in
 it. Please only send patches to a...@kernel.org that you intend for us
 to apply.

Uh, need more coffee, please ignore. I got confused since your patch didn't
apply cleanly due to the dts/qcom directory creation.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd

[Olof Johansson]

Hi,

I understand this is bikeshedding to some extent, but I'd also like to
avoid needless variation in binding formats:

On Tue, Mar 3, 2015 at 1:32 AM, Linus Walleij linus.wall...@linaro.org wrote:

 +
 +foo@1000 {
 +   compatible = syscon, simple-mfd;
 +   reg = 0x01 0x1000;
 +
 +   led@08.0 {

This doesn't seem to be a typo, you're using a period in the unit
address. I've never seen that done before, usually commas are used
instead.

Was there a reason for going with period?


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] coresight: adding basic support for Spreadtrum SC9836

[Olof Johansson]

On Wed, Mar 25, 2015 at 08:52:11PM +0800, Chunyan Zhang wrote:
 Support only for ETF, FUNNEL, STM are included currently.
 Support for ETM, TPIU and the replicator linked to it are not included in
 this version patch.
 
 Signed-off-by: Chunyan Zhang zhang.chun...@linaro.org
 ---
 Change for v2:
  - Corrected the TMC whose space is wrongly used as ETB in v1.
  - Removed coresight-default-sink from the DT.
 ---

Appled but with subject:

arm64: dts: sprd: adding coresight entries to Spreadtrum SC9836 



-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm64: dts: Add Qualcomm APQ8016 SBC evaluation board dts

[Olof Johansson]

On Fri, Apr 3, 2015 at 12:13 PM, Kumar Gala ga...@codeaurora.org wrote:

 On Apr 3, 2015, at 1:18 PM, Olof Johansson o...@lixom.net wrote:

 On Fri, Apr 03, 2015 at 11:14:01AM -0700, Olof Johansson wrote:
 On Fri, Apr 03, 2015 at 11:12:17AM -0700, Olof Johansson wrote:
 On Mon, Mar 23, 2015 at 05:51:05PM -0500, Kumar Gala wrote:
 Add initial device tree support for Qualcomm APQ8016 SBC Evaluation board.
 This board is also referred to as the DragonBoard 410c.

 Signed-off-by: Kumar Gala ga...@codeaurora.org

 Hi,

 Patch applied but see comment below.

 You both sent us the patch and a pull request with this patch in
 it. Please only send patches to a...@kernel.org that you intend for us
 to apply.

 Uh, need more coffee, please ignore. I got confused since your patch didn't
 apply cleanly due to the dts/qcom directory creation.


 -Olof

 Ok, but this should be part of the 'qcom-dt-for-4.1’ so hopefully you will 
 end up pulling all of that in as well

If you pick up a patch that you have sent us, please reply to that
email with a redaction so we don't waste time dealing with it.
Especially if some time has passed.

I'll get to your dt branch this afternoon.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 20/20] ARM: configs: enable Marvell Armada 39x in multi_v7_defconfig

[Olof Johansson]

On Tue, Mar 03, 2015 at 03:41:15PM +0100, Thomas Petazzoni wrote:
 Following the introduction of the Marvell Armada 39x support, let's
 enable this support by default in multi_v7_defconfig.
 
 Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
 Cc: a...@kernel.org

Thanks, applied.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Support for Fujitsu MB86S7X SoCs

[Olof Johansson]

Hi Vincent,

On Wed, Mar 18, 2015 at 02:44:30PM +0900, Vincent Yang wrote:
 Hi Arnd and Olof,
 
 Please consider pulling in these patches for series of Fujitsu SoC
 based around variations of 2xCA7+2xCA15 big.LITTLE architecture.
 
 The MHU driver is already queued in Mailbox tree.
 
 Thanks,
 
 The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:
 
   Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)
 
 are available in the git repository at:
 
   git://git.linaro.org/landing-teams/working/fujitsu/integration.git
 s7x-arch-pull
 
 for you to fetch changes up to 9cf417fee0bbea9296791fa9a15ab289307bb26a:
 
   ARM: MB86S7x: Add configs (2015-03-17 11:22:40 +0530)

Please use signed tags when you send pull requests (and ideally, please get
your GPG key signed by people at the next Linaro Connect or other event where
you will get in contact with other kernel developers).

I started looking at this patch set, and it's adding global include file
contents for things that should only exist under the drivers/soc/ directory,
i.e. internal driver defines, etc -- it shouldn't be exposed to the kernel as
a whole.

I'll find the individual patches where they were posted and comment on those
directly.

As far as applying the code -- initial platforms like these usually go in
through different branches so applying them directly makes sense for us. Once
you're up and rolling as a maintainer you'll get a hang of what we want to see
grouped in the different branches and pull requests will be easier to handle.


Thanks,

-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Support for Fujitsu MB86S7X SoCs

[Olof Johansson]

On Tue, Mar 31, 2015 at 08:32:01AM +0530, Jassi Brar wrote:
 On 18 March 2015 at 11:14, Vincent Yang vincent.cw.y...@gmail.com wrote:
  Hi Arnd and Olof,
 
  Please consider pulling in these patches for series of Fujitsu SoC
  based around variations of 2xCA7+2xCA15 big.LITTLE architecture.
 
  The MHU driver is already queued in Mailbox tree.
 
  Thanks,
 
  The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:
 
Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)
 
  are available in the git repository at:
 
git://git.linaro.org/landing-teams/working/fujitsu/integration.git
  s7x-arch-pull
 
  for you to fetch changes up to 9cf417fee0bbea9296791fa9a15ab289307bb26a:
 
ARM: MB86S7x: Add configs (2015-03-17 11:22:40 +0530)
 
  
  Jassi Brar (6):
ARM: Add platform support for Fujitsu MB86S7X SoCs
ARM: MB86S7X: Add MCPM support
clk: Add clock driver for mb86s7x
dt: mb86s7x: add dt files for MB86S7x evbs
of: add Fujitsu vendor prefix
ARM: MB86S7x: Add configs
 
 Hi Arnd, Hi Olof,
A polite reminder on the pull request. Or do we miss doing something?

Hi,

No, we've just been backlogged and slow to respond.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V6] kbuild: dtbs_install: new make target

[Olof Johansson]

On Sat, Mar 28, 2015 at 8:58 AM, Jason Cooper ja...@lakedaemon.net wrote:
 Russell,

 On Sat, Mar 28, 2015 at 01:23:20PM +, Russell King - ARM Linux wrote:
 Okay, I'm digging up an old version of this patch - v7 was merged but
 I find *nowhere* where that version was posted to people involved in
 this discussion.

 fwiw, I just went through my archive of patch submissions:

 $ ls ~/projects/linux/dtbs_install/
 v2  v3  v4  v5  v6
 $

 I never wrote a v7.  :-(  Regardless,

It was posted by Grant, and posted to LKML, devicetree@ and
linux-kbuild. The patch was directly cc:d to Jason, Michal Marek,
Russell and Rob Herring.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pinctrl: dt: at91: new binding

[Olof Johansson]

On Tue, Mar 17, 2015 at 5:07 AM, Linus Walleij linus.wall...@linaro.org wrote:
 On Thu, Feb 26, 2015 at 10:34 AM, Jean-Christophe PLAGNIOL-VILLARD
 plagn...@jcrosoft.com wrote:

 +For each peripheral/bank we will descibe in a u32 if a pin can be
 +configured in it by putting 1 to the pin bit (1  pin)

 This seems to be describing driver intrinsics in the device tree, like
 how the hardware is routed on the inside and what it can do.

 IMO that is driver territory, the driver should know these limitations
 and protest if you try to do something illegal.

 Anyway as the AT91 maintainers seem to disagree I will allow some
 more time for discussion before merging the patch.

 I can't really have one AT91 maintainer NACKing another, it doesn't
 matter that this is a separate driver, in my book the MAINTAINERS
 entry for AT91 as a whole overrides that so can you please find an
 agreement on how to handle this or I will stall the patch until
 you're in agreement.

Nicolas has been the de-facto maintainer of AT91 for quite a while
now, even though more of them are listed on the maintainers entry. It
would be inappropriate to merge something that he disagreed with on
that platform.

 ARM SoC maintainers input would be welcomed.

It seems appropriate to ask the at91 folks to come back with a
solution that everybody is OK with, and until then hold off merging
this.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id

[Olof Johansson]

On Tue, Mar 10, 2015 at 10:13 AM, Kumar Gala ga...@codeaurora.org wrote:

 On Mar 9, 2015, at 7:11 AM, Arnd Bergmann a...@arndb.de wrote:

 On Friday 06 March 2015 14:37:52 Kumar Gala wrote:
 On Mar 6, 2015, at 1:15 PM, Olof Johansson o...@lixom.net wrote:

 On Fri, Mar 6, 2015 at 8:08 AM, Kumar Gala ga...@codeaurora.org wrote:

 On Mar 5, 2015, at 7:59 PM, Olof Johansson o...@lixom.net wrote:

 On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala ga...@codeaurora.org wrote:

 On Mar 5, 2015, at 1:42 PM, Kevin Hilman khil...@kernel.org wrote:

 Kumar Gala ga...@codeaurora.org writes:

 The top level qcom,msm-id and qcom,board-id are utilized by 
 bootloaders
 on Qualcomm MSM platforms to determine which device tree should be
 utilized and passed to the kernel.

 Cc: devicetree@vger.kernel.org
 Signed-off-by: Kumar Gala ga...@codeaurora.org

 Is this the special magic that allows qcom bootloaders to take a kernel
 plus multiple DTBs and figure out which DTB to pass?

 Kevin

 yes

 That's a bummer.

 Luckily, the solution for upstream is still quite simple: Provide only
 one devicetree, and it'll be used, right?

 We can provide only one, we still need the IDs in the DT.

 How are the DTS provided? Concatenated with the kernel, or in a
 wrapped data format? Or in a separate partition from the kernel?

 Its a wrapped data format that is than concatenated with the kernel if I 
 remember correctly.

 Then you should be able to create a tool that can write this concatenated
 format and insert these properties from a table that matches the boot
 loader, right?

   Arnd

 Are you suggesting the tool insert the properties in the DT?  I’m not sure I 
 understand what the point of doing that would be.

To insert platform-local properties that mean nothing outside of the
firmware packaging of the device trees, which is the case here?

I think the idea of having the installer script inserting them is
quite reasonable in this case.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id

[Olof Johansson]

On Fri, Mar 6, 2015 at 8:08 AM, Kumar Gala ga...@codeaurora.org wrote:

 On Mar 5, 2015, at 7:59 PM, Olof Johansson o...@lixom.net wrote:

 On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala ga...@codeaurora.org wrote:

 On Mar 5, 2015, at 1:42 PM, Kevin Hilman khil...@kernel.org wrote:

 Kumar Gala ga...@codeaurora.org writes:

 The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
 on Qualcomm MSM platforms to determine which device tree should be
 utilized and passed to the kernel.

 Cc: devicetree@vger.kernel.org
 Signed-off-by: Kumar Gala ga...@codeaurora.org

 Is this the special magic that allows qcom bootloaders to take a kernel
 plus multiple DTBs and figure out which DTB to pass?

 Kevin

 yes

 That's a bummer.

 Luckily, the solution for upstream is still quite simple: Provide only
 one devicetree, and it'll be used, right?

 We can provide only one, we still need the IDs in the DT.

How are the DTS provided? Concatenated with the kernel, or in a
wrapped data format? Or in a separate partition from the kernel?


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id

[Olof Johansson]

On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala ga...@codeaurora.org wrote:

 On Mar 5, 2015, at 1:42 PM, Kevin Hilman khil...@kernel.org wrote:

 Kumar Gala ga...@codeaurora.org writes:

 The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
 on Qualcomm MSM platforms to determine which device tree should be
 utilized and passed to the kernel.

 Cc: devicetree@vger.kernel.org
 Signed-off-by: Kumar Gala ga...@codeaurora.org

 Is this the special magic that allows qcom bootloaders to take a kernel
 plus multiple DTBs and figure out which DTB to pass?

 Kevin

 yes

That's a bummer.

Luckily, the solution for upstream is still quite simple: Provide only
one devicetree, and it'll be used, right?


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] drivers/core/of: Add symlink to device-tree from devices with an OF node

[Olof Johansson]

On Sun, Feb 15, 2015 at 7:59 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
 So I've been annoyed lately with having a bunch of devices such as i2c
 eeproms (for use by VPDs, server world !) and other bits and pieces that
 I want to be able to identify from userspace, and possibly provide
 additional data about from FW.

 Basically, it boils down to correlating the sysfs device with the OF
 tree device node, so that user space can use device-tree info such as
 additional location or label (or whatever else we can come up with)
 properties to identify a given device, or get some attributes of use
 about it, etc...

 Now, so far, we've done that in some subsystem in a fairly ad-hoc basis
 using devspec properties. For example, PCI creates them if it can
 correlate the probed device with a DT node. Some powerpc specific busses
 do that too.

 However, i2c doesn't and it would be nice to have something more generic
 since technically any device can have a corresponding device tree node
 these days.

 This patch achieves this by adding an of_node symlink to devices that
 have a non-NULL dev-of_node pointer.

 Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org

Concept:

Acked-by: Olof Johansson o...@lixom.net

We've come across similar needs on product, and always had to do some
less-than-optimal alternate solution. This seems like a good idea to
me.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: dw_mmc: fix bug that cause mmc_test failture

[Olof Johansson]

Hi Addy,

On Mon, Jan 26, 2015 at 4:04 AM, Addy Ke addy...@rock-chips.com wrote:
 The STOP command can terminate a data transfer between a memory card and
 mmc controller.

 As show in Synopsys DesignWare Cores Mobile Stroage Host Databook:
 Data timeout and Data end-bit error will terminate further data transfer
 by mmc controller. So we should not send abort command to terminate a
 data transfer again if we got DRTO and EBE interrupt.

 After this patch, all mmc_test cases can pass on RK3288-Pink2 board.

 Signed-off-by: Addy Ke addy...@rock-chips.com

The drawback of having so many people on your to: list on a patch is
that it's unclear who you want to review and merge it. Sometimes less
is more.

In this case, it seems appropriate to have Ulf do so. Ulf, ping? This
seems like a reasonable patch for 3.20 given that it fixes undesired
behavior.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] arm64,hi6220: Enable Hisilicon Hi6220 SoC

[Olof Johansson]

On Thu, Feb 5, 2015 at 8:21 PM, Brent Wang wangbint...@gmail.com wrote:
 Hello Olof and Tyler,

 2015-02-06 7:52 GMT+08:00 Tyler Baker tyler.ba...@linaro.org:

 On 5 February 2015 at 11:02, Olof Johansson o...@lixom.net wrote:
  On Thu, Feb 5, 2015 at 10:46 AM, Tyler Baker tyler.ba...@linaro.org
  wrote:
  Hi Bintian,
 
  On 5 February 2015 at 01:24, Bintian Wang bintian.w...@huawei.com
  wrote:
  Hello,
 
  Hi6220 is one mobile solution of Hisilicon, this patchset contains
  initial support for Hi6220 SoC and HiKey development board, which
  is based on ARM Cortex A53 architecture. Initial support is minimal
  and includes just the arch configuration, clock driver, device tree
  configuration.
 
  Many peripheral drivers will be submitted later.
 
  Any comments will be appreciated!
 
  Thanks,
 
  Bintian Wang (3):
arm64: Enable Hisilicon ARMv8 SoC family in Kconfig and defconfig
clk: hi6220: Clock driver support for Hisilicon hi6220 SoC
arm64: dts: Add dts files for Hisilicon Hi6220 SoC
 
  Thanks for posting these! I've applied this series on top of
  next-20150204, however there was some fuzz that needed to be cleaned
  up on 3/3 [1]. I've confirmed the platform is booting to a basic user
  space without issue.
 
  From ramdisk only, right?

 Correct, ramdisk only.

  Given the timing of the posting of this
  patch set, I'm not going to merge it for 3.20. Hopefully for 3.21
  there will be some more peripheral support as well -- at least some
  sort of storage device.

 Seem fair to me. I also hope to see more patches posted shortly.

 Yes, the mmc and sd drivers will be submitted soon, should they be included
 in this patchset?  I have thought submitting this patch first for review, if
 there
 is no problem for this patchset and then submit other drivers, you know,
 other
 drivers will depend on this patchset.


The drivers should ideally not depend on the SoC patchset -- the
driver can go in independently. The DTS updates to specify the
hardware should go in through arm-soc even if the driver itself (and
the binding document update) should go in through the driver subsystem
instead.


So, you can choose if you want to post everything as a long series,
and cc different maintainers on the various parts of the series -- or
you can post each driver or subsystem as a patchset on its own and let
that get merged through respective maintainer. The latter is most
common these days.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] arm64,hi6220: Enable Hisilicon Hi6220 SoC

[Olof Johansson]

On Thu, Feb 5, 2015 at 10:46 AM, Tyler Baker tyler.ba...@linaro.org wrote:
 Hi Bintian,

 On 5 February 2015 at 01:24, Bintian Wang bintian.w...@huawei.com wrote:
 Hello,

 Hi6220 is one mobile solution of Hisilicon, this patchset contains
 initial support for Hi6220 SoC and HiKey development board, which
 is based on ARM Cortex A53 architecture. Initial support is minimal
 and includes just the arch configuration, clock driver, device tree
 configuration.

 Many peripheral drivers will be submitted later.

 Any comments will be appreciated!

 Thanks,

 Bintian Wang (3):
   arm64: Enable Hisilicon ARMv8 SoC family in Kconfig and defconfig
   clk: hi6220: Clock driver support for Hisilicon hi6220 SoC
   arm64: dts: Add dts files for Hisilicon Hi6220 SoC

 Thanks for posting these! I've applied this series on top of
 next-20150204, however there was some fuzz that needed to be cleaned
 up on 3/3 [1]. I've confirmed the platform is booting to a basic user
 space without issue.

From ramdisk only, right? Given the timing of the posting of this
patch set, I'm not going to merge it for 3.20. Hopefully for 3.21
there will be some more peripheral support as well -- at least some
sort of storage device.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/2] ARM: digicolor: select syscon and timer

[Olof Johansson]

On Thu, Jan 29, 2015 at 12:04:11AM +0200, Baruch Siach wrote:
 The digicolor interrupt controller driver now needs syscon.
 
 Also, as per clocksource maintainer request, we now have a separate config
 symbol, CONFIG_DIGICOLOR_TIMER, for the digicolor timer.
 
 Signed-off-by: Baruch Siach bar...@tkos.co.il

Thanks, applied 1-2.

-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/4] ARM: digicolor: add minimal device tree description

[Olof Johansson]

Hi,

On Wed, Jan 14, 2015 at 10:40:32AM +0200, Baruch Siach wrote:
 cx92755.dtsi describes CX92755 on chip peripherals. conexant_equinox.dts
 describes the Equinox evaluation board for the CX92755 SoC.
 
 Acked-by: Arnd Bergmann a...@arndb.de
 Signed-off-by: Baruch Siach bar...@tkos.co.il
 ---
  arch/arm/boot/dts/Makefile |   1 +
  arch/arm/boot/dts/conexant_equinox.dts |  74 +++
  arch/arm/boot/dts/cx92755.dtsi | 107 
 +
  3 files changed, 182 insertions(+)
  create mode 100644 arch/arm/boot/dts/conexant_equinox.dts
  create mode 100644 arch/arm/boot/dts/cx92755.dtsi
 
 diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
 index 91bd5bd62857..fbeb65eaddda 100644
 --- a/arch/arm/boot/dts/Makefile
 +++ b/arch/arm/boot/dts/Makefile
 @@ -75,6 +75,7 @@ dtb-$(CONFIG_ARCH_BRCMSTB) += \
   bcm7445-bcm97445svmb.dtb
  dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
   da850-evm.dtb
 +dtb-$(CONFIG_ARCH_DIGICOLOR) += conexant_equinox.dtb
  dtb-$(CONFIG_ARCH_EFM32) += efm32gg-dk3750.dtb
  dtb-$(CONFIG_ARCH_EXYNOS) += exynos3250-monk.dtb \
   exynos3250-rinato.dtb \
 diff --git a/arch/arm/boot/dts/conexant_equinox.dts 
 b/arch/arm/boot/dts/conexant_equinox.dts
 new file mode 100644
 index ..f33bf5635d47
 --- /dev/null
 +++ b/arch/arm/boot/dts/conexant_equinox.dts

To segment the namespace a bit, we ask that you prefix your dts files with the
platform. What would be a suitable prefix here? conexant? digicolor?


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/4] ARM: digicolor: add low level debug support

[Olof Johansson]

On Wed, Jan 14, 2015 at 10:40:31AM +0200, Baruch Siach wrote:
 Use the USART peripheral as UART for low level debug. Only the UA0 port is
 currently supported.
 
 Acked-by: Arnd Bergmann a...@arndb.de
 Signed-off-by: Baruch Siach bar...@tkos.co.il
 ---
  arch/arm/Kconfig.debug | 12 ++--
  arch/arm/include/debug/digicolor.S | 35 +++
  2 files changed, 45 insertions(+), 2 deletions(-)
  create mode 100644 arch/arm/include/debug/digicolor.S

Applied, thanks.

-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/4] ARM: devicetree: document supported Conexant Digicolor SoC

[Olof Johansson]

On Wed, Jan 14, 2015 at 10:40:33AM +0200, Baruch Siach wrote:
 Of the Digicolor SoCs series only CX92755 is currently supported.
 
 Acked-by: Arnd Bergmann a...@arndb.de
 Signed-off-by: Baruch Siach bar...@tkos.co.il
 ---
  Documentation/devicetree/bindings/arm/digicolor.txt | 6 ++
  1 file changed, 6 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/arm/digicolor.txt
 
 diff --git a/Documentation/devicetree/bindings/arm/digicolor.txt 
 b/Documentation/devicetree/bindings/arm/digicolor.txt
 new file mode 100644
 index ..658553f40b23
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/arm/digicolor.txt
 @@ -0,0 +1,6 @@
 +Conexant Digicolor Platforms Device Tree Bindings
 +
 +Each device tree must specify which Conexant Digicolor SoC it uses.
 +Must be the following compatible string:
 +
 +  cnxt,cx92755

Applied, thanks.

-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/4] ARM: initial support for Conexant Digicolor CX92755 SoC

[Olof Johansson]

On Wed, Jan 14, 2015 at 10:40:30AM +0200, Baruch Siach wrote:
 Add initial support for the Conexant CX92755 SoC. The CX92755 is one of the
 Digicolor series of SoCs, all sharing many of the same peripherals. The code
 was tested on the CX92755 evaluation kit, AKA Equinox.
 
 Acked-by: Arnd Bergmann a...@arndb.de
 Signed-off-by: Baruch Siach bar...@tkos.co.il
 ---
  arch/arm/Kconfig|  2 ++
  arch/arm/mach-digicolor/Kconfig |  5 +
  arch/arm/mach-digicolor/Makefile|  1 +
  arch/arm/mach-digicolor/digicolor.c | 18 ++
  4 files changed, 26 insertions(+)
  create mode 100644 arch/arm/mach-digicolor/Kconfig
  create mode 100644 arch/arm/mach-digicolor/Makefile
  create mode 100644 arch/arm/mach-digicolor/digicolor.c

Applied, thanks.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/4] ARM: Conexant Digicolor CX92755 SoC support

[Olof Johansson]

On Sun, Jan 25, 2015 at 08:08:55PM +0200, Baruch Siach wrote:
 Hi ARM SoC maintainers,
 
 On Wed, Jan 14, 2015 at 10:40:29AM +0200, Baruch Siach wrote:
  This series adds initial support for the Conexant CX92755 SoC. The CX92755 
  is
  one of the Digicolor series of SoCs, all sharing many of the same 
  peripherals.
  The code was tested on the CX92755 evaluation kit, AKA Equinox.
  
  Uses attempting to try this code will most likely also want the UART/console
  driver available from https://patchwork.kernel.org/patch/5515861/.
 
 Any chance of having this series merged for 3.20? Arnd has acked this already.

Yep, just had a small comment on naming for the third patch, the rest have been
applied now.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm64: dts: add baud rate to Juno stdout-path

[Olof Johansson]

On Thu, Jan 22, 2015 at 11:21:32AM +, Robin Murphy wrote:
 Without explicit command-line parameters, the Juno UART ends up running
 at 57600 baud in the kernel, which is at odds with the 115200 baud used
 by the rest of the firmware. Since commit 7914a7c5651a5161 now lets us
 fix this by specifying default options in stdout-path, do so.
 
 Acked-by: Mark Rutland mark.rutl...@arm.com
 Signed-off-by: Robin Murphy robin.mur...@arm.com


Thanks, applied as a fix for 3.19.

-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] ARM: tegra: Move out nyan-generic parts out from the nyan-big DT

[Olof Johansson]

On Tue, Jan 6, 2015 at 9:30 AM, Andrew Bresticker abres...@google.com wrote:
 On Tue, Jan 6, 2015 at 5:06 AM, Thierry Reding thierry.red...@gmail.com 
 wrote:


 Back when we merged the nyan-big DTS there was some discussion and it
 was concluded that the devices are very similar, with the panel being
 one notable exception. So I think that this belongs in the nyan-big
 DTS and you need to add a similar property to the nyan-blaze DTS with
 the compatible for the panel used in the design. And you might need
 to add an entry for the panel in the panel-simple driver, too.

 That's correct.  There are also variants of big and blaze with 1080p
 panels, so those will definitely need their own panel nodes as well.

 Other than that,

 Acked-by: Andrew Bresticker abres...@chromium.org

Shame on both of you for not pruning the patch when replying -- the
emails go too long for gmail to show them by default. :) :P

And yeah, this split looks reasonable to me (with the panel comment fixed)

Feel free to carry:

Acked-by: Olof Johansson o...@lixom.net
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: rk3288: add arm,cpu-registers-not-fw-configured

[Olof Johansson]

On Tue, Nov 25, 2014 at 10:54:00AM -0800, Sonny Rao wrote:
 This will enable use of physical arch timers on rk3288, where each
 core comes out of reset with a different virtual offset.  Using
 physical timers will help with SMP booting on coreboot and older
 u-boot and should also allow suspend-resume and cpu-hotplug to work on
 all firmwares.
 
 Firmware which does initialize the cpu registers properly at boot and
 cpu-hotplug can remove this property from the device tree.
 
 Signed-off-by: Sonny Rao sonny...@chromium.org
 ---
  arch/arm/boot/dts/rk3288.dtsi | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
 index 0f50d5d..c861f52 100644
 --- a/arch/arm/boot/dts/rk3288.dtsi
 +++ b/arch/arm/boot/dts/rk3288.dtsi
 @@ -139,6 +139,7 @@
  
   timer {
   compatible = arm,armv7-timer;
 + arm,cpu-registers-not-fw-configured;
   interrupts = GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | 
 IRQ_TYPE_LEVEL_HIGH),
GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | 
 IRQ_TYPE_LEVEL_HIGH),
GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | 
 IRQ_TYPE_LEVEL_HIGH),

Applied, thanks.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 0/5] Add Spreadtrum Sharkl64 Platform support

[Olof Johansson]

On Thu, Dec 04, 2014 at 07:34:15PM +0800, Chunyan Zhang wrote:
 Spreadtrum is a rapid growing chip vendor providing smart phone total 
 solutions.
 
 Sharkl64 Platform is nominated as a SoC infrastructure that supports 4G/3G/2G
 standards based on ARMv8 multiple core architecture.Now we have only one
 SoC(SC9836) based on this Platform in developing.
 
 This patchset adds Sharkl64 support in arm64 device tree and the serial driver
 of SC9836-UART.
 
 This patchset also has patches which address sprd prefix and DT compatible
 strings for nodes which appear un-documented.
 
 This version code was tesed both on Fast Mode and sc9836-fpga board.
 We use the latest boot-wrapper-aarch64 as the bootloader.

Hi,

We only got 3 of the 5 patches of this version (1, 2 and 4). Can you
resend the dts patch to us (I'm guessing the serial one will go through Greg).


Thanks,

-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] clocksource: arch_timer: Allow the device tree to specify uninitialized timer registers

[Olof Johansson]

On Wed, Oct 08, 2014 at 12:33:47AM -0700, Sonny Rao wrote:
 From: Doug Anderson diand...@chromium.org
 
 Some 32-bit (ARMv7) systems are architected like this:
 
 * The firmware doesn't know and doesn't care about hypervisor mode and
   we don't want to add the complexity of hypervisor there.
 
 * The firmware isn't involved in SMP bringup or resume.
 
 * The ARCH timer come up with an uninitialized offset (CNTVOFF)
   between the virtual and physical counters.  Each core gets a
   different random offset.
 
 * The device boots in Secure SVC mode.
 
 * Nothing has touched the reset value of CNTHCTL.PL1PCEN or
   CNTHCTL.PL1PCTEN (both default to 1 at reset)
 
 On systems like the above, it doesn't make sense to use the virtual
 counter.  There's nobody managing the offset and each time a core goes
 down and comes back up it will get reinitialized to some other random
 value.
 
 This adds an optional property which can inform the kernel of this
 situation, and firmware is free to remove the property if it is going
 to initialize the CNTVOFF registers when each CPU comes out of reset.
 
 Currently, the best course of action in this case is to use the
 physical timer, which is why it is important that CNTHCTL hasn't been
 changed from its reset value and it's a reasonable assumption given
 that the firmware has never entered HYP mode.
 
 Note that it's been said that on ARMv8 systems the firmware and
 kernel really can't be architected as described above.  That means
 using the physical timer like this really only makes sense for ARMv7
 systems.
 
 Signed-off-by: Doug Anderson diand...@chromium.org
 Signed-off-by: Sonny Rao sonny...@chromium.org
 Reviewed-by: Mark Rutland mark.rutl...@arm.com
 ---
 Changes in v2:
 - Add #ifdef CONFIG_ARM as per Will Deacon
 
 Changes in v3:
 - change property name to arm,cntvoff-not-fw-configured and specify
   that the value of CNTHCTL.PL1PC(T)EN must still be the reset value
   of 1 as per Mark Rutland
 
 Changes in v4:
 - change property name to arm,cpu-registers-not-fw-configured and
   specify that all cpu registers must have architected reset values
   per Mark Rutland
 - change from #ifdef CONFIG_ARM to if (IS_ENABLED(CONFIG_ARM)) per
   Arnd Bergmann


Applied to next/drivers (and next/dt for rk3288 dependency). Thanks, all!


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Broadcom Cygnus SoC defconfig changes

[Olof Johansson]

On Tue, Nov 11, 2014 at 10:29 PM, Florian Fainelli f.faine...@gmail.com wrote:
 2014-11-08 16:13 GMT-08:00 Olof Johansson o...@lixom.net:
 On Thu, Oct 30, 2014 at 12:50:09PM -0700, Florian Fainelli wrote:
 The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1:

   Linux 3.18-rc1 (2014-10-19 18:08:38 -0700)

 are available in the git repository at:

   http://github.com/brcm/linux.git tags/arm-soc/for-3.18/cygnus-defconfig-v9

 for you to fetch changes up to aa0204801143ee2d47e9e8dd5f39c5613b4b:

   ARM: multi_v7_defconfig: Enable Broadcom Cygnus (2014-10-30 11:01:35 
 -0700)

 Hi Florian,

 Apologies for the delay in dealing with this pull request.

 
 This patchset contains initial support for Broadcom's Cygnus SoC based on 
 our
 iProc architecture. Initial support is minimal and includes just the mach
 platform code, clock driver, and a basic device tree configuration. 
 Peripheral
 drivers will be submitted soon, as will device tree configurations for other
 Cygnus board variants.

 These are the defconfig parts of the changes

 
 Jonathan Richardson (1):
   ARM: cygnus defconfig : Initial defconfig for Broadcom Cygnus SoC

 Ray Jui (1):
   ARM: multi_v7_defconfig: Enable Broadcom Cygnus

 Scott Branden (1):
   ARM: bcm_defconfig/multi_v7_defconfig: remove one level of menu from 
 Kconfig

  arch/arm/configs/bcm_cygnus_defconfig | 237 
 ++
  arch/arm/configs/bcm_defconfig|   3 +-
  arch/arm/configs/multi_v7_defconfig   |  21 ++-

 Please send multi_v7_defconfig updates as a patch instead of including in
 a merge request. We ask for this because it's a file that many maintainers
 touch and it's easy that we get lots of conflicts otherwise.

 As far as the bcm_cygnus_defconfig: Since new platforms are multiplatform
 enabled by default, we normally only prefer to have one defconfig per vendor.
 We've made exceptions in cases where the families are very different, but in
 general one defconfig per vendor should be sufficient.

 I.e. please enable the cygnus options in bcm_defconfig instead of adding a 
 new
 one.

 Alright, so just to make sure I get this right:

 - there are two patches from Scott and Ray which enable Cygnus in
 mutli_v7_defconfig that I should send a separate patches
 - adding Cygnus to bcm_defconfig can be part of a separate pull request

Yep!


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] arm64: Add Juno SoC device tree.

[Olof Johansson]

Hi,

Nice to see this posted! Thanks for doing so.

On Mon, Nov 10, 2014 at 3:27 AM, Liviu Dudau liviu.du...@arm.com wrote:
 Signed-off-by: Liviu Dudau liviu.du...@arm.com

Care to give a brief patch description?

 ---
  arch/arm64/boot/dts/Makefile |   2 +-
  arch/arm64/boot/dts/juno.dts | 374 
 +++
  2 files changed, 375 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm64/boot/dts/juno.dts

 diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
 index f8001a6..0100eca 100644
 --- a/arch/arm64/boot/dts/Makefile
 +++ b/arch/arm64/boot/dts/Makefile
 @@ -1,5 +1,5 @@
  dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb
 -dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
 +dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb juno.dtb

We've applied the series that creates subdirectories per vendor, so
this won't apply. Care to respin on top of our next/cleanup branch?

  dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb

  targets += dtbs
 diff --git a/arch/arm64/boot/dts/juno.dts b/arch/arm64/boot/dts/juno.dts
 new file mode 100644
 index 000..7f998de
 --- /dev/null
 +++ b/arch/arm64/boot/dts/juno.dts
 @@ -0,0 +1,374 @@
 +/*
 + * ARM Ltd. Juno Plaform
 + *
 + */
 +
 +/dts-v1/;
 +
 +#include dt-bindings/interrupt-controller/arm-gic.h
 +
 +/ {
 +   model = Juno;

This could probably be a bit more descriptive.

 +   compatible = arm,juno, arm,vexpress;
 +   interrupt-parent = gic;
 +   #address-cells = 2;
 +   #size-cells = 2;
 +
 +   aliases {
 +   serial0 = soc_uart0;
 +   };
 +
 +   cpus {
 +   #address-cells = 2;
 +   #size-cells = 0;
 +
 +   A53_0:cpu@100 {
 +   compatible = arm,cortex-a53,arm,armv8;
 +   reg = 0x0 0x100;
 +   device_type = cpu;
 +   enable-method = psci;
 +   };
 +
 +   A53_1:cpu@101 {
 +   compatible = arm,cortex-a53,arm,armv8;
 +   reg = 0x0 0x101;
 +   device_type = cpu;
 +   enable-method = psci;
 +   };
 +
 +   A53_2:cpu@102 {
 +   compatible = arm,cortex-a53,arm,armv8;
 +   reg = 0x0 0x102;
 +   device_type = cpu;
 +   enable-method = psci;
 +   };
 +
 +   A53_3:cpu@103 {
 +   compatible = arm,cortex-a53,arm,armv8;
 +   reg = 0x0 0x103;
 +   device_type = cpu;
 +   enable-method = psci;
 +   };
 +
 +   A57_0:cpu@0 {
 +   compatible = arm,cortex-a57,arm,armv8;
 +   reg = 0x0 0x0;
 +   device_type = cpu;
 +   enable-method = psci;
 +   };
 +
 +   A57_1:cpu@1 {
 +   compatible = arm,cortex-a57,arm,armv8;
 +   reg = 0x0 0x1;
 +   device_type = cpu;
 +   enable-method = psci;
 +   };

These cpus are not ordered by reg, they probably should be (i.e. 57s
before 53s).

 +   };
 +
 +   memory@8000 {
 +   device_type = memory;
 +   /* last 16MB of the first memory area is reserved for secure 
 world use by firmware */
 +   reg = 0x 0x8000 0x0 0x7f00,
 + 0x0008 0x8000 0x1 0x8000;
 +   };
 +
 +   gic: interrupt-controller@2c001000 {
 +   compatible = arm,gic-400, arm,cortex-a15-gic;
 +   reg = 0x0 0x2c01 0 0x1000,
 + 0x0 0x2c02f000 0 0x2000,
 + 0x0 0x2c04f000 0 0x2000,
 + 0x0 0x2c06f000 0 0x2000;
 +   #address-cells = 0;
 +   #interrupt-cells = 3;
 +   interrupt-controller;
 +   interrupts = GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(6) | 
 IRQ_TYPE_LEVEL_HIGH);
 +   };
 +
 +   timer {
 +   compatible = arm,armv8-timer;
 +   interrupts = GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(6) | 
 IRQ_TYPE_EDGE_RISING),
 +GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(6) | 
 IRQ_TYPE_EDGE_RISING),
 +GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(6) | 
 IRQ_TYPE_EDGE_RISING),
 +GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(6) | 
 IRQ_TYPE_EDGE_RISING);
 +   };
 +
 +   pmu {
 +   compatible = arm,armv8-pmuv3;
 +   interrupts = GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH,
 +GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH,
 +GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH,
 +GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH,
 +GIC_SPI 02 IRQ_TYPE_LEVEL_HIGH,
 +  

Re: [PATCH v9 4/8] ARM: dts: Enable Broadcom Cygnus SoC

[Olof Johansson]

On Mon, Nov 10, 2014 at 2:50 AM, Paul Bolle pebo...@tiscali.nl wrote:
 On Tue, 2014-10-28 at 16:15 -0700, Scott Branden wrote:
 DT files to enable cygnus consisting on reference designs
 and cygnus core configuration.

 Reviewed-by: Ray Jui r...@broadcom.com
 Reviewed-by: Arun Parameswaran apara...@broadcom.com
 Tested-by: Jonathan Richardson jonat...@broadcom.com
 Reviewed-by: JD (Jiandong) Zheng jdzh...@broadcom.com
 Signed-off-by: Scott Branden sbran...@broadcom.com

 This landed in today's linux-next (ie, next-21041110) as commit
 8872fc22c267 (ARM: dts: Enable Broadcom Cygnus SoC).

  arch/arm/boot/dts/Makefile  |4 ++
  arch/arm/boot/dts/bcm-cygnus-clock.dtsi |   73 ++
  arch/arm/boot/dts/bcm-cygnus.dtsi   |  100 
 +++
  arch/arm/boot/dts/bcm911360_entphn.dts  |   32 ++
  arch/arm/boot/dts/bcm911360k.dts|   32 ++
  arch/arm/boot/dts/bcm958300k.dts|   32 ++
  6 files changed, 273 insertions(+)
  create mode 100644 arch/arm/boot/dts/bcm-cygnus-clock.dtsi
  create mode 100644 arch/arm/boot/dts/bcm-cygnus.dtsi
  create mode 100644 arch/arm/boot/dts/bcm911360_entphn.dts
  create mode 100644 arch/arm/boot/dts/bcm911360k.dts
  create mode 100644 arch/arm/boot/dts/bcm958300k.dts

 diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
 index 38c89ca..4b3a590 100644
 --- a/arch/arm/boot/dts/Makefile
 +++ b/arch/arm/boot/dts/Makefile
 @@ -54,6 +54,10 @@ dtb-$(CONFIG_ARCH_AT91)+= at91-sama5d4ek.dtb
  dtb-$(CONFIG_ARCH_ATLAS6) += atlas6-evb.dtb
  dtb-$(CONFIG_ARCH_AXXIA) += axm5516-amarillo.dtb
  dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
 +dtb-$(CONFIG_ARCH_BCM_CYGNUS) += \
 + bcm911360_entphn.dtb \
 + bcm911360k.dtb \
 + bcm958300k.dtb
  dtb-$(CONFIG_ARCH_BCM_5301X) += bcm4708-netgear-r6250.dtb
  dtb-$(CONFIG_ARCH_BCM_63XX) += bcm963138dvt.dtb
  dtb-$(CONFIG_ARCH_BCM_MOBILE) += bcm28155-ap.dtb \

 Without patch 1/8 (ARM: cygnus: Initial support for Broadcom Cygnus
 SoC) CONFIG_ARCH_BCM_CYGNUS will not be set. I guess patch 1/8 will be
 added to linux-next one of these days. Is that correct?

Yes.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Broadcom Cygnus SoC Device Tree changes

[Olof Johansson]

On Sat, Nov 8, 2014 at 4:25 PM, Olof Johansson o...@lixom.net wrote:
 Hi Florian,

 On Thu, Oct 30, 2014 at 12:50:10PM -0700, Florian Fainelli wrote:
 The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1:

   Linux 3.18-rc1 (2014-10-19 18:08:38 -0700)

 are available in the git repository at:

   http://github.com/brcm/linux.git tags/arm-soc/for-3.18/cygnus-dts-v9

 for you to fetch changes up to 8872fc22c2670cde338ab92be4a8e9ebad8e53e6:

   ARM: dts: Enable Broadcom Cygnus SoC (2014-10-30 11:05:55 -0700)

 
 This patchset contains initial support for Broadcom's Cygnus SoC based on our
 iProc architecture. Initial support is minimal and includes just the mach
 platform code, clock driver, and a basic device tree configuration. 
 Peripheral
 drivers will be submitted soon, as will device tree configurations for other
 Cygnus board variants.

 These are the Device Tree changes

 
 Jonathan Richardson (1):
   dt-bindings: Document Broadcom Cygnus SoC and clocks

 Scott Branden (1):
   ARM: dts: Enable Broadcom Cygnus SoC

 I just posted a set of comments on this original patch that I noticed
 when reviewing it while merging. Please send a fresh pull request when
 they're addressed.

 Also, about your tag texts: There's no need to have the first paragraph
 boiler on all of them, I'd rather appreciate a sentence or two about
 what the DTS'es are in this case (i.e. one dtsi for the family and three
 different boards based on it), etc. You'll get a hang of it over time. :)


Seems like I accidentally merged this branch. I've dropped it again in
anticipation of a new pull request.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: serial: of-serial: fetch line number from DT

[Olof Johansson]

On Mon, Nov 10, 2014 at 1:38 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 11/10/2014 02:34 PM, Olof Johansson wrote:

 Greg,

 This commit:

 commit 1bd8324535ec1ff44aef55c0e40b9e7d56b310fb
 Author: Lucas Stach d...@lynxeye.de
 Date:   Mon Nov 3 23:16:54 2014 +0100

  serial: of-serial: fetch line number from DT

 ...

 Broke a whole lot of tegra boards in last night's -next here. In
 particular, I've been looking at tegra20-seaboard, which now doesn't
 boot with console any more.

 http://arm-soc.lixom.net/bootlogs/next/next-20141110/

 Unfortunately, tegra has for a long time been specifying the aliases
 as a fixed 1:1 mapping, but most environments rely on ttyS0 being the
 first _activated_ serial port. That's obviously going to break things
 here. :(

 ...

 Stephen: I suppose the best way to handle this on tegra is to specify
 the aliases per-board instead of in the soc dtsi today.


 IIRC, there was a deliberate request to name the Tegra UARTs after the SoC
 ports rather than board ports, so that it'd be obvious to people which port
 was which. I'm not sure if we can change the aliases in the Tegra DTs now
 that people may have got used to them?

I think that's a great idea in general, but they've been this way now
for 4 years and it'll mean everyone changing bootargs and console
configurations (where to spawn getty) everywhere. :(


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Broadcom Cygnus SoC defconfig changes

[Olof Johansson]

On Sun, Nov 9, 2014 at 9:36 PM, Scott Branden sbran...@broadcom.com wrote:
 On 14-11-09 11:24 AM, Florian Fainelli wrote:

 On 11/08/14 21:45, Scott Branden wrote:

 Hi Olof,

 Thanks for the comments.  Please see my questions inline before we
 determine what needs to be done for the defconfig patchset.

 On 14-11-08 04:13 PM, Olof Johansson wrote:

 On Thu, Oct 30, 2014 at 12:50:09PM -0700, Florian Fainelli wrote:

 The following changes since commit
 f114040e3ea6e07372334ade75d1ee0775c355e1:

 Linux 3.18-rc1 (2014-10-19 18:08:38 -0700)

 are available in the git repository at:

 http://github.com/brcm/linux.git
 tags/arm-soc/for-3.18/cygnus-defconfig-v9

 for you to fetch changes up to
 aa0204801143ee2d47e9e8dd5f39c5613b4b:

 ARM: multi_v7_defconfig: Enable Broadcom Cygnus (2014-10-30
 11:01:35 -0700)


 Hi Florian,

 Apologies for the delay in dealing with this pull request.

 
 This patchset contains initial support for Broadcom's Cygnus SoC
 based on our
 iProc architecture. Initial support is minimal and includes just the
 mach
 platform code, clock driver, and a basic device tree configuration.
 Peripheral
 drivers will be submitted soon, as will device tree configurations
 for other
 Cygnus board variants.

 These are the defconfig parts of the changes

 
 Jonathan Richardson (1):
 ARM: cygnus defconfig : Initial defconfig for Broadcom Cygnus
 SoC

 Ray Jui (1):
 ARM: multi_v7_defconfig: Enable Broadcom Cygnus

 Scott Branden (1):
 ARM: bcm_defconfig/multi_v7_defconfig: remove one level of
 menu from Kconfig

arch/arm/configs/bcm_cygnus_defconfig | 237
 ++
arch/arm/configs/bcm_defconfig|   3 +-
arch/arm/configs/multi_v7_defconfig   |  21 ++-


 Please send multi_v7_defconfig updates as a patch instead of including
 in
 a merge request. We ask for this because it's a file that many
 maintainers
 touch and it's easy that we get lots of conflicts otherwise.

 OK, easy to do.  Are there other files that we need to be aware of that
 have these different requirements to merge as well?


 As far as the bcm_cygnus_defconfig: Since new platforms are
 multiplatform
 enabled by default, we normally only prefer to have one defconfig per
 vendor.
 We've made exceptions in cases where the families are very different,
 but in
 general one defconfig per vendor should be sufficient.

 I.e. please enable the cygnus options in bcm_defconfig instead of
 adding a new
 one.


 Hi Olof, we can do this.  But this makes bcm_defconfig unusable for us
 in a product and is not a simple configuration to start from for our
 customers.  bcm_defconfig is a different SoC family based around the
 Kona architecture. bcm_defconfig won't be what we build and test on
 Cygnus at all.  There is a script in scripts/kconfig/mergeconfig.pl that
 allows you to merge config files together if you wish to have a kernel
 support multiple SoCs.  I see the same problem with multi_v7_defconfig
 but even worse.  It isn't a configuration we will ever use.  Its only
 purpose seems to be to enable our drivers in the that build just in case
 somebody else happens to break something in the build.


 The defconfigs shipped in the mainline kernel only serve the purpose of
 building as many drivers/subsystems as possible and making sure they
 work well together from a general distribution perspective like
 Debian/Ubuntu/OE... That does not mean this is your configuration
 template for a downstream kernel with only a specific set of SoCs to
 support.


 As it stands, multi_v7_defconfig boots noticably slower than
 bcm_cygnus_defconfig.  And, the kernel is larger than we want.  And, the
 kconfigs are more complicated than we need for our boards.  I also
 notice some of the other SoCs families enabled automatically turn on a
 lot of features we don't want on.


 Right, you are also very likely to see code blow away that has been
 enabled as part of the multi_v7_defconfig, but actually assumes that it
 will only run on a a particular family of SoCs, of course, all of this
 is good to fix to improve the multiplatform kernel, but does not
 necessarily impact you directly.


 Perhaps most of the multi_v7_defconfig merge issue you are facing could
 be solved if you used the mergconfig.pl script to merge multiple
 defconfigs together?

 What we wish to do is have a config file that only supports the Cygnus
 family of SoCs.  This allows others to easily see what applies to Cygnus
 without being confused by other configurations.  And, if somebody wishes
 to use scripts/kconfig/mergeconfig.pl to merge different SoC support
 together they are free to do so.

 So, we can do as you ask to get this upstreamed.  But it really serves
 little purpose for us other than verifying things build.

 Where do we upstream the defconfig that we actually use

Re: [GIT PULL] Broadcom Cygnus SoC defconfig changes

[Olof Johansson]

On Thu, Oct 30, 2014 at 12:50:09PM -0700, Florian Fainelli wrote:
 The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1:
 
   Linux 3.18-rc1 (2014-10-19 18:08:38 -0700)
 
 are available in the git repository at:
 
   http://github.com/brcm/linux.git tags/arm-soc/for-3.18/cygnus-defconfig-v9
 
 for you to fetch changes up to aa0204801143ee2d47e9e8dd5f39c5613b4b:
 
   ARM: multi_v7_defconfig: Enable Broadcom Cygnus (2014-10-30 11:01:35 -0700)

Hi Florian,

Apologies for the delay in dealing with this pull request.

 
 This patchset contains initial support for Broadcom's Cygnus SoC based on our
 iProc architecture. Initial support is minimal and includes just the mach
 platform code, clock driver, and a basic device tree configuration. Peripheral
 drivers will be submitted soon, as will device tree configurations for other
 Cygnus board variants.
 
 These are the defconfig parts of the changes
 
 
 Jonathan Richardson (1):
   ARM: cygnus defconfig : Initial defconfig for Broadcom Cygnus SoC
 
 Ray Jui (1):
   ARM: multi_v7_defconfig: Enable Broadcom Cygnus
 
 Scott Branden (1):
   ARM: bcm_defconfig/multi_v7_defconfig: remove one level of menu from 
 Kconfig
 
  arch/arm/configs/bcm_cygnus_defconfig | 237 
 ++
  arch/arm/configs/bcm_defconfig|   3 +-
  arch/arm/configs/multi_v7_defconfig   |  21 ++-

Please send multi_v7_defconfig updates as a patch instead of including in
a merge request. We ask for this because it's a file that many maintainers
touch and it's easy that we get lots of conflicts otherwise.

As far as the bcm_cygnus_defconfig: Since new platforms are multiplatform
enabled by default, we normally only prefer to have one defconfig per vendor.
We've made exceptions in cases where the families are very different, but in
general one defconfig per vendor should be sufficient.

I.e. please enable the cygnus options in bcm_defconfig instead of adding a new
one.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 4/8] ARM: dts: Enable Broadcom Cygnus SoC

[Olof Johansson]

Hi,

A bunch of small comments below, should be quick to fix.

On Tue, Oct 28, 2014 at 12:53 PM, Scott Branden sbran...@broadcom.com wrote:
 DT files to enable cygnus consisting on reference designs
 and cygnus core configuration.

 Reviewed-by: Ray Jui r...@broadcom.com
 Reviewed-by: Arun Parameswaran apara...@broadcom.com
 Tested-by: Jonathan Richardson jonat...@broadcom.com
 Reviewed-by: JD (Jiandong) Zheng jdzh...@broadcom.com
 Signed-off-by: Scott Branden sbran...@broadcom.com
 ---
  arch/arm/boot/dts/Makefile  |4 ++
  arch/arm/boot/dts/bcm-cygnus-clock.dtsi |   73 ++
  arch/arm/boot/dts/bcm-cygnus.dtsi   |  100 
 +++
  arch/arm/boot/dts/bcm911360_entphn.dts  |   32 ++
  arch/arm/boot/dts/bcm911360k.dts|   32 ++
  arch/arm/boot/dts/bcm958300k.dts|   32 ++
  6 files changed, 273 insertions(+)
  create mode 100644 arch/arm/boot/dts/bcm-cygnus-clock.dtsi
  create mode 100644 arch/arm/boot/dts/bcm-cygnus.dtsi
  create mode 100644 arch/arm/boot/dts/bcm911360_entphn.dts
  create mode 100644 arch/arm/boot/dts/bcm911360k.dts
  create mode 100644 arch/arm/boot/dts/bcm958300k.dts

 diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
 index 38c89ca..4b3a590 100644
 --- a/arch/arm/boot/dts/Makefile
 +++ b/arch/arm/boot/dts/Makefile
 @@ -54,6 +54,10 @@ dtb-$(CONFIG_ARCH_AT91)  += at91-sama5d4ek.dtb
  dtb-$(CONFIG_ARCH_ATLAS6) += atlas6-evb.dtb
  dtb-$(CONFIG_ARCH_AXXIA) += axm5516-amarillo.dtb
  dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
 +dtb-$(CONFIG_ARCH_BCM_CYGNUS) += \
 +   bcm911360_entphn.dtb \
 +   bcm911360k.dtb \
 +   bcm958300k.dtb
  dtb-$(CONFIG_ARCH_BCM_5301X) += bcm4708-netgear-r6250.dtb
  dtb-$(CONFIG_ARCH_BCM_63XX) += bcm963138dvt.dtb
  dtb-$(CONFIG_ARCH_BCM_MOBILE) += bcm28155-ap.dtb \

Please add new entries in alphabetical/alphanumerical order. Also,
first entry is commonly added on the first line


 diff --git a/arch/arm/boot/dts/bcm-cygnus-clock.dtsi 
 b/arch/arm/boot/dts/bcm-cygnus-clock.dtsi
 new file mode 100644
 index 000..d06172b
 --- /dev/null
 +++ b/arch/arm/boot/dts/bcm-cygnus-clock.dtsi
 @@ -0,0 +1,73 @@
 +/*
 + * Copyright 2014 Broadcom Corporation.  All rights reserved.
 + *
 + * Unless you and Broadcom execute a separate written software license
 + * agreement governing use of this software, this software is licensed to you
 + * under the terms of the GNU General Public License as
 + * published by the Free Software Foundation version 2.
 + *
 + * This program is distributed as is WITHOUT ANY WARRANTY of any
 + * kind, whether express or implied; without even the implied warranty
 + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.

We ask for new DT contents to be added with dual BSD/GPL license, to
allow for reuse of the DT data structures in other projects as well.
There's currently a lot of activity going on relicensing the current
files so I recommend sorting it out before they are added if you can.

 + */
 +
 +clocks {
 +   #address-cells = 1;
 +   #size-cells = 1;
 +   ranges;
 +
 +   osc: oscillator {
 +   compatible = fixed-clock;
 +   #clock-cells = 1;
 +   clock-frequency = 2500;
 +   };
 +
 +   apb_clk: apb_clk {
 +   compatible = fixed-clock;
 +   #clock-cells = 0;
 +   clock-frequency = 10;
 +   };
 +
 +   periph_clk: periph_clk {
 +   compatible = fixed-clock;
 +   #clock-cells = 0;
 +   clock-frequency = 5;
 +   };
 +
 +   sdio_clk: lcpll_ch2 {
 +   compatible = fixed-clock;
 +   #clock-cells = 0;
 +   clock-frequency = 2;
 +   };
 +
 +   axi81_clk: axi81_clk {
 +   compatible = fixed-clock;
 +   #clock-cells = 0;
 +   clock-frequency = 1;
 +   };
 +
 +   keypad_clk: keypad_clk {
 +   compatible = fixed-clock;
 +   #clock-cells = 0;
 +   clock-frequency = 31806;
 +   };
 +
 +   adc_clk: adc_clk {
 +   compatible = fixed-clock;
 +   #clock-cells = 0;
 +   clock-frequency = 1562500;
 +   };
 +
 +   pwm_clk: pwm_clk {
 +   compatible = fixed-clock;
 +   #clock-cells = 0;
 +   clock-frequency = 100;
 +   };
 +
 +   lcd_clk: mipipll_ch1 {
 +   compatible = fixed-clock;
 +   #clock-cells = 0;
 +   clock-frequency = 1;
 +   };
 +};
 diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
 b/arch/arm/boot/dts/bcm-cygnus.dtsi
 new file mode 100644
 index 000..9c650ab
 --- /dev/null
 +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
 @@ -0,0 +1,100 @@
 +/*
 + * Copyright 2014 Broadcom Corporation.  All rights reserved.
 + *
 + * 

Re: [GIT PULL] Broadcom Cygnus SoC Device Tree changes

[Olof Johansson]

Hi Florian,

On Thu, Oct 30, 2014 at 12:50:10PM -0700, Florian Fainelli wrote:
 The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1:
 
   Linux 3.18-rc1 (2014-10-19 18:08:38 -0700)
 
 are available in the git repository at:
 
   http://github.com/brcm/linux.git tags/arm-soc/for-3.18/cygnus-dts-v9
 
 for you to fetch changes up to 8872fc22c2670cde338ab92be4a8e9ebad8e53e6:
 
   ARM: dts: Enable Broadcom Cygnus SoC (2014-10-30 11:05:55 -0700)
 
 
 This patchset contains initial support for Broadcom's Cygnus SoC based on our
 iProc architecture. Initial support is minimal and includes just the mach
 platform code, clock driver, and a basic device tree configuration. Peripheral
 drivers will be submitted soon, as will device tree configurations for other
 Cygnus board variants.
 
 These are the Device Tree changes
 
 
 Jonathan Richardson (1):
   dt-bindings: Document Broadcom Cygnus SoC and clocks
 
 Scott Branden (1):
   ARM: dts: Enable Broadcom Cygnus SoC

I just posted a set of comments on this original patch that I noticed
when reviewing it while merging. Please send a fresh pull request when
they're addressed.

Also, about your tag texts: There's no need to have the first paragraph
boiler on all of them, I'd rather appreciate a sentence or two about
what the DTS'es are in this case (i.e. one dtsi for the family and three
different boards based on it), etc. You'll get a hang of it over time. :)


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Broadcom Cygnus SoC platforms changes

[Olof Johansson]

On Thu, Oct 30, 2014 at 12:50:12PM -0700, Florian Fainelli wrote:
 The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1:
 
   Linux 3.18-rc1 (2014-10-19 18:08:38 -0700)
 
 are available in the git repository at:
 
   http://github.com/brcm/linux.git tags/arm-soc/for-3.18/cygnus-platform-v9
 
 for you to fetch changes up to 038aae04d36eff71e0b30a1c3057ec0a05bf9390:
 
   ARM: mach-bcm: ARCH_BCM_MOBILE: remove one level of menu from Kconfig 
 (2014-10-30 11:39:51 -0700)
 
 
 This patchset contains initial support for Broadcom's Cygnus SoC based on our
 iProc architecture. Initial support is minimal and includes just the mach
 platform code, clock driver, and a basic device tree configuration. Peripheral
 drivers will be submitted soon, as will device tree configurations for other
 Cygnus board variants.
 
 These are the platform changes

Hi,

Merged into next/soc. Thanks!


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Broadcom Cygnus SoC platforms changes

[Olof Johansson]

On Sat, Nov 08, 2014 at 04:28:46PM -0800, Olof Johansson wrote:
 On Thu, Oct 30, 2014 at 12:50:12PM -0700, Florian Fainelli wrote:
  The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1:
  
Linux 3.18-rc1 (2014-10-19 18:08:38 -0700)
  
  are available in the git repository at:
  
http://github.com/brcm/linux.git tags/arm-soc/for-3.18/cygnus-platform-v9
  
  for you to fetch changes up to 038aae04d36eff71e0b30a1c3057ec0a05bf9390:
  
ARM: mach-bcm: ARCH_BCM_MOBILE: remove one level of menu from Kconfig 
  (2014-10-30 11:39:51 -0700)
  
  
  This patchset contains initial support for Broadcom's Cygnus SoC based on 
  our
  iProc architecture. Initial support is minimal and includes just the mach
  platform code, clock driver, and a basic device tree configuration. 
  Peripheral
  drivers will be submitted soon, as will device tree configurations for other
  Cygnus board variants.
  
  These are the platform changes
 
 Hi,
 
 Merged into next/soc. Thanks!

Actually, I noticed on the other branch (the maintainers one) that you
haven't signed off on any patches you've applied (you're the committer,
but there's no Signed-off-by line from you). So I dropped this branch
again, please fix that up and send fresh pull requests.

When you do that, you can also fold in the maintainers patch in the platform
branch.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: zynq: Enable PL clocks for Parallella

[Olof Johansson]

On Fri, Nov 07, 2014 at 07:44:16AM +0100, Michal Simek wrote:
 On 11/06/2014 06:22 PM, Andreas Färber wrote:
  The Parallella board comes with a U-Boot bootloader that loads one of
  two predefined FPGA bitstreams before booting the kernel. Both define an
  AXI interface to the on-board Epiphany processor.
  
  Enable clocks FCLK0..FCLK3 for the Programmable Logic by default.
  
  Otherwise accessing, e.g., the ESYSRESET register freezes the board,
  as seen with the Epiphany SDK tools e-reset and e-hw-rev, using /dev/mem.
  
  Cc: sta...@vger.kernel.org # 3.17.x
  Signed-off-by: Andreas Färber afaer...@suse.de
  ---
   Michal/Olof, please consider this trivial patch as a fix for 3.18.
 
 Acked-by: Michal Simek michal.si...@xilinx.com
 
 Olof, Arnd: Can you please pick this directly?

Done, applied to fixes.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 4/8] ARM: dts: Enable Broadcom Cygnus SoC

[Olof Johansson]

On Sat, Nov 8, 2014 at 10:13 PM, Scott Branden sbran...@broadcom.com wrote:
 On 14-11-08 04:22 PM, Olof Johansson wrote:

 Hi,

 A bunch of small comments below, should be quick to fix.

 On Tue, Oct 28, 2014 at 12:53 PM, Scott Branden sbran...@broadcom.com
 wrote:

 DT files to enable cygnus consisting on reference designs
 and cygnus core configuration.

 Reviewed-by: Ray Jui r...@broadcom.com
 Reviewed-by: Arun Parameswaran apara...@broadcom.com
 Tested-by: Jonathan Richardson jonat...@broadcom.com
 Reviewed-by: JD (Jiandong) Zheng jdzh...@broadcom.com
 Signed-off-by: Scott Branden sbran...@broadcom.com
 ---
   arch/arm/boot/dts/Makefile  |4 ++
   arch/arm/boot/dts/bcm-cygnus-clock.dtsi |   73 ++
   arch/arm/boot/dts/bcm-cygnus.dtsi   |  100
 +++
   arch/arm/boot/dts/bcm911360_entphn.dts  |   32 ++
   arch/arm/boot/dts/bcm911360k.dts|   32 ++
   arch/arm/boot/dts/bcm958300k.dts|   32 ++
   6 files changed, 273 insertions(+)
   create mode 100644 arch/arm/boot/dts/bcm-cygnus-clock.dtsi
   create mode 100644 arch/arm/boot/dts/bcm-cygnus.dtsi
   create mode 100644 arch/arm/boot/dts/bcm911360_entphn.dts
   create mode 100644 arch/arm/boot/dts/bcm911360k.dts
   create mode 100644 arch/arm/boot/dts/bcm958300k.dts

 diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
 index 38c89ca..4b3a590 100644
 --- a/arch/arm/boot/dts/Makefile
 +++ b/arch/arm/boot/dts/Makefile
 @@ -54,6 +54,10 @@ dtb-$(CONFIG_ARCH_AT91)  += at91-sama5d4ek.dtb
   dtb-$(CONFIG_ARCH_ATLAS6) += atlas6-evb.dtb
   dtb-$(CONFIG_ARCH_AXXIA) += axm5516-amarillo.dtb
   dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
 +dtb-$(CONFIG_ARCH_BCM_CYGNUS) += \
 +   bcm911360_entphn.dtb \
 +   bcm911360k.dtb \
 +   bcm958300k.dtb
   dtb-$(CONFIG_ARCH_BCM_5301X) += bcm4708-netgear-r6250.dtb
   dtb-$(CONFIG_ARCH_BCM_63XX) += bcm963138dvt.dtb
   dtb-$(CONFIG_ARCH_BCM_MOBILE) += bcm28155-ap.dtb \


 Please add new entries in alphabetical/alphanumerical order. Also,
 first entry is commonly added on the first line


 diff --git a/arch/arm/boot/dts/bcm-cygnus-clock.dtsi
 b/arch/arm/boot/dts/bcm-cygnus-clock.dtsi
 new file mode 100644
 index 000..d06172b
 --- /dev/null
 +++ b/arch/arm/boot/dts/bcm-cygnus-clock.dtsi
 @@ -0,0 +1,73 @@
 +/*
 + * Copyright 2014 Broadcom Corporation.  All rights reserved.
 + *
 + * Unless you and Broadcom execute a separate written software license
 + * agreement governing use of this software, this software is licensed
 to you
 + * under the terms of the GNU General Public License as
 + * published by the Free Software Foundation version 2.
 + *
 + * This program is distributed as is WITHOUT ANY WARRANTY of any
 + * kind, whether express or implied; without even the implied warranty
 + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.


 We ask for new DT contents to be added with dual BSD/GPL license, to
 allow for reuse of the DT data structures in other projects as well.
 There's currently a lot of activity going on relicensing the current
 files so I recommend sorting it out before they are added if you can.


 This may take more time than you think.  I am going to have to go through
 legal to get such a license created. Also, why would you need dual license?
 If it is BSD that should serve both purposes?

I haven't followed the discussion close enough to know if there's been
discussion about single-license BSD vs dual BSD/GPL.

At the very least, please start the process of getting it changed.

Also, I see now that this isn't even a clean GPL v2, given Unless you
and Broadcom... language. I see the bnx2x driver had that in the
past, but none of the Kona contributions did. I strongly suggest
sticking to the normal copyrights here and not making things more
complicated than they have to.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] dts, kbuild: Implement support for dtb vendor subdirs

[Olof Johansson]

On Tue, Oct 21, 2014 at 08:15:04PM +0200, Robert Richter wrote:
 Arnd,
 
 On 05.09.14 08:48:06, Robert Richter wrote:
  From: Robert Richter rrich...@cavium.com
  
  For arm64 we want to put dts files into vendor's subdirectories from
  the beginning. This patch set implements this. As this is a generic
  kbuild implementation, vendor subdirs will be also available for
  arch/arm and other architectures. The subdirectory tree is also
  reflected in the install path.
  
  A new makefile variable dts-dirs is introduced to point to dts
  subdirs. This variable is used by kbuild for building and installation
  of dtb files.
  
  A dts Makefile looks now as follows:
  
  
  dtb-$(CONFIG_...) += some_file_1.dtb
  dtb-$(CONFIG_...) += some_file_2.dtb
  
  dts-dirs  += dir_vendor_a
  dts-dirs  += dir_vendor_b
  
  # come always afterwards:
  always := $(dtb-y)
  subdir-y   := $(dts-dirs)
  clean-files:= *.dtb
  
  
  This patches also introduces the dtbs_install make target for
  arm64. Install rules are moved to Makefile.dtbinst using the same
  style and calling convention like for modinst and fwinst.
  
  Robert Richter (6):
dts, arm64: Add dtbs_install make target
dts, kbuild: Factor out dtbs install rules to Makefile.dtbinst
dts, arm/arm64: Remove dtbs build rules in sub-makes
dts, kbuild: Implement support for dtb vendor subdirs
dts, arm64: Move dts files to vendor subdirs
dts, arm: Remove $(MACHINE) variable from dtbs make recipes
 
 please pull this series for inclusion into v3.19 from:
 
  git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git 
 dts-subdirs-for-arm-soc-v3.19
 
 I have updated and rebased the patches to v3.18-rc1. No changes except
 conflict resolution of patch 5/6.

Pulled, and I added the description from 0/6 as the merge text -- feel free to
add it to the tag if you do something like this in the future.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html