* Re: [PATCH] ARM: dts: cygnus: Add HWRNG node
From: Clément Péron @ 2018-06-06 17:06 UTC (permalink / raw)
To: Florian Fainelli
Cc: scott.branden, devicetree, Rob Herring, Mark Rutland,
Russell King, Ray Jui, Scott Branden, Jon Mason,
BCM Kernel Feedback, linux-arm-kernel, linux-kernel,
Clément Peron
In-Reply-To: <c7990001-00e6-d828-bafd-3d472fcfee20@gmail.com>
Hi Scott, Florian,
On Wed, 6 Jun 2018 at 18:47, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> On 06/06/201 8 09:03 AM, Scott Branden wrote:
> > Hi Clement,
> >
> >
> > On 18-06-06 02:34 AM, Clément Péron wrote:
> >> From: Clément Peron <clement.peron@devialet.com>
> >>
> >> There is a HWRNG in Broadcom Cygnus SoC, so enable it.
> >>
> >> Signed-off-by: Clément Peron <clement.peron@devialet.com>
> > Thanks for upstreaming some missing Cygnus components.
> >
> > But, the problem is the tarball release from Broadcom you are extracting
> > these changes from does not contain git history; so, you are missing the
> > original authors and signed-off's.
> > I checked our internal git repository and for this commit the author is:
> > Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
> >
> > Please adjust author and signed-off appropriately. If there are other
> > changes you are extracting from the source tarballs you have please
> > contact me so we can construct patch appropriately.
>
> If you want the original author's Signed-off-by to be preserved, why
> don't you extract it from your internal git tree and submit the patch on
> Mohamed's behalf?
>
> AFAICT what Clement is doing here is permissible given the Linux
> developer certificate of origin though I am not a lawyer of course.
> --
> Florian
Totally not my goal to steal the author and agree to keep track of the
original author
as soon as it's possible. I didn't though it was important for this
patch as the same
code is available in the dt-bindings documentation.
Actually there are still some buggy components like DSA (Arun proposed
a patch this morning)
the PWM (config and delay aren't correct) and I2C. These are mainlined
but can't be used
and need a minimal effort to correctly work on Cygnus.
Also there are some important components like USB Phy or Mailbox that
were proposed and
almost made it, but just need a small modification to be accepted.
My idea was just to submit small patches that are trivial to review.
In order to avoid keeping
lots of patches in our kernel and also have something functional when
building a mainline kernel.
Regards,
Clement
^ permalink raw reply
* Re: [PATCH] ARM: dts: cygnus: Add HWRNG node
From: Scott Branden @ 2018-06-06 17:14 UTC (permalink / raw)
To: Florian Fainelli, Clément Péron, devicetree
Cc: Rob Herring, Mark Rutland, Russell King, Ray Jui, Scott Branden,
Jon Mason, bcm-kernel-feedback-list, linux-arm-kernel,
linux-kernel, Clément Peron
In-Reply-To: <c7990001-00e6-d828-bafd-3d472fcfee20@gmail.com>
On 18-06-06 09:47 AM, Florian Fainelli wrote:
> On 06/06/2018 09:03 AM, Scott Branden wrote:
>> Hi Clement,
>>
>>
>> On 18-06-06 02:34 AM, Clément Péron wrote:
>>> From: Clément Peron <clement.peron@devialet.com>
>>>
>>> There is a HWRNG in Broadcom Cygnus SoC, so enable it.
>>>
>>> Signed-off-by: Clément Peron <clement.peron@devialet.com>
>> Thanks for upstreaming some missing Cygnus components.
>>
>> But, the problem is the tarball release from Broadcom you are extracting
>> these changes from does not contain git history; so, you are missing the
>> original authors and signed-off's.
>> I checked our internal git repository and for this commit the author is:
>> Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
>>
>> Please adjust author and signed-off appropriately. If there are other
>> changes you are extracting from the source tarballs you have please
>> contact me so we can construct patch appropriately.
> If you want the original author's Signed-off-by to be preserved, why
> don't you extract it from your internal git tree and submit the patch on
> Mohamed's behalf?
Sure, I can submit the original patch to keep things simple and avoid
finding a lawyer right now.
>
> AFAICT what Clement is doing here is permissible given the Linux
> developer certificate of origin though I am not a lawyer of course.
But, It would be great to get some guidance and clarification on this
for sure.
I'm reading:
https://www.kernel.org/doc/html/v4.16/process/submitting-patches.html
The change was created entirely by Broadcom, so seems difficult for
somebody else to upstream change without appropriate authorship and
signed off from copyright holder. Point a) and b) are not met in
Developer's Certificate of Origin while point c) is being attempted
(without a or b being certified).
^ permalink raw reply
* Re: [PATCH] ARM: dts: cygnus: Add HWRNG node
From: Scott Branden @ 2018-06-06 17:31 UTC (permalink / raw)
To: Clément Péron, Florian Fainelli
Cc: devicetree, Rob Herring, Mark Rutland, Russell King, Ray Jui,
Scott Branden, Jon Mason, BCM Kernel Feedback, linux-arm-kernel,
linux-kernel, Clément Peron
In-Reply-To: <CAJiuCcdfmrdHf10JkVOGQXD77JN=_FUv2ysEGTzyvwON31HX_A@mail.gmail.com>
On 18-06-06 10:06 AM, Clément Péron wrote:
> Hi Scott, Florian,
>
> On Wed, 6 Jun 2018 at 18:47, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> On 06/06/201 8 09:03 AM, Scott Branden wrote:
>>> Hi Clement,
>>>
>>>
>>> On 18-06-06 02:34 AM, Clément Péron wrote:
>>>> From: Clément Peron <clement.peron@devialet.com>
>>>>
>>>> There is a HWRNG in Broadcom Cygnus SoC, so enable it.
>>>>
>>>> Signed-off-by: Clément Peron <clement.peron@devialet.com>
>>> Thanks for upstreaming some missing Cygnus components.
>>>
>>> But, the problem is the tarball release from Broadcom you are extracting
>>> these changes from does not contain git history; so, you are missing the
>>> original authors and signed-off's.
>>> I checked our internal git repository and for this commit the author is:
>>> Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
>>>
>>> Please adjust author and signed-off appropriately. If there are other
>>> changes you are extracting from the source tarballs you have please
>>> contact me so we can construct patch appropriately.
>> If you want the original author's Signed-off-by to be preserved, why
>> don't you extract it from your internal git tree and submit the patch on
>> Mohamed's behalf?
>>
>> AFAICT what Clement is doing here is permissible given the Linux
>> developer certificate of origin though I am not a lawyer of course.
>> --
>> Florian
> Totally not my goal to steal the author and agree to keep track of the
> original author
> as soon as it's possible. I didn't though it was important for this
> patch as the same
> code is available in the dt-bindings documentation.
>
> Actually there are still some buggy components like DSA (Arun proposed
> a patch this morning)
> the PWM (config and delay aren't correct) and I2C. These are mainlined
> but can't be used
> and need a minimal effort to correctly work on Cygnus.
We have internal versions of most everything. It's a matter of getting
people to push the appropriate patches out for upstream version to work.
Please contact the bcm-kernel-feedback list with issues and we can work
through common solution (or, likely already have a solution just not
upstreamed).
>
> Also there are some important components like USB Phy or Mailbox that
> were proposed and
> almost made it, but just need a small modification to be accepted.
Again - we may have internal solution already. Yes, mailbox was
submitted upstream a long time ago and I think got stalled being
accepted upstream. We can work through upstream solution by starting
with sending to bcm-kernel-feedback-list to discuss details.
>
> My idea was just to submit small patches that are trivial to review.
> In order to avoid keeping
> lots of patches in our kernel and also have something functional when
> building a mainline kernel.
I understand the difficulty you would have if you're trying to work with
a different kernel version in our release. If you send me a list
directly of the drivers you use in Cygnus that will help me get those
changes prioritized to be pushed upstream. And/or we can work together
on that.
>
> Regards,
> Clement
Thanks,
Scott
^ permalink raw reply
* Re: [PATCH V4 0/3] Microchip mcp25xxfd can controller driver
From: kernel @ 2018-06-06 17:32 UTC (permalink / raw)
To: linux-can, devicetree, Wolfgang Grandegger, Mark Kleine-Budde,
Rob Herring, Mark Rutland
Cc: Marcel Birthelmer, Sukkin Pang, Gerhard Bertelsmann
In-Reply-To: <20180514160313.29597-1-kernel@martin.sperl.org>
Hi!
Any updates/feedback on this driver?
It has been sitting here almost unchanged for the last 4 month without any feedback (except for Rob).
What is still needed to get it included?
As far as I see all the comments from end of November have been addressed already in V2 of this patch series…
Note also that:
Tested-by: Gerhard Bertelsmann <info@gerhard-bertelsmann.de>
(from January)
Thanks,
Martin
> On 14.05.2018, at 18:03, kernel@martin.sperl.org wrote:
>
> From: Martin Sperl <kernel@martin.sperl.org>
>
> This patchset adds a driver for the mcp25xxfd CanFD controller.
>
> Most of the features of the controller are supported by this
> driver release.
>
> The controller includes a few features that the current core Can(FD)
> implementation does not support:
> * Transmit Bandwidth Sharing bits
> - this waits for a configurable number of syncronization bits before
> atempting to transmit the next frame - for the moment controllable
> via a module parameter
> * SID11 with CanFD frames
> - at this moment not supported by driver
> * 3 transmit attempts in addition to ONE_SHOT
> * transmitter delay compensation configurations
> * micro second exact transmission and reception timestamps
> - used internally by driver
> * variable number of tx-fifos
> - exposed via module parameter at this moment
>
> The driver has been heavily optimized so that it can handle
> a 100% utilized 1MHz Can-bus (with 11 bit can frames with DLC=0)
> even on less powerful SOCs like the raspberry pi 1 without
> dropping frames due to driver/spi latencies (still dropps
> are observed in the can/network stack).
>
> To achive this the driver includes several code optimization
> Two of which prefers continuous long spi transfers over multiple
> small individual spi transfers of variable length.
> This is an optimization that would favour spi dma transfers instead
> of more expensive PIO in typical SPI controllers.
> Both of them can get explicitly enabled by the use of a module parameter.
> One of those is automatically used in the case of Can2.0 only bus
> configurations.
>
> Finer details of the implementation and rational is included with
> the driver code it self for future reference.
>
> The driver has also been tested for basic CanFD transfers with
> BRS up to 5.7Mhz data bitrates - the available transceiver did
> not allow for faster rates...
>
> The driver itself exposes lots of internal data/statistics via
> debugfs.
>
> The driver implements a lock-less design for transmissions
> making use instead of prepared spi messages submitted via spi_async
> for transmission in the start_xmit_start code without requireing
> an extra workqueue and the corresponding latencies.
>
> Note that there is an extra patch in the pipeline to implement pinctrl
> but this still shows some issues, so it is not included in this patchset.
>
> Changelog:
> V1 -> V2: new more generic name based on feedback from microchip
> cleanup of code (checkpatch)
> address all feedback on code
> handle (HW) systemerrors in a much better/reliable way
> cleanup of dt custom properties removing (most) gpio
> related properties
> implemented GPIOLIB support as per feedback
> V2 -> V3: added vendor-prefix for gpio-opendrain to dt-binding
> added gpio-controller to dt-binding
> added feedback by Rob Herring
> waited for other feedback regarding the code
> V3 -> V4: resend
> Patch-1 (dt) added: Reviewed-by: Rob Herring <robh@kernel.org>
>
> Martin Sperl (3):
> dt-binding: can: mcp25xxfd: document device tree bindings
> can: mcp25xxfd: Add Microchip mcp25xxfd CAN FD driver
> can: mcp25xxfd: add gpiolib support for GPIO0/1 (aka. INT0/INT1)
>
> .../bindings/net/can/microchip,mcp25xxfd.txt | 32 +
> drivers/net/can/spi/Kconfig | 6 +
> drivers/net/can/spi/Makefile | 1 +
> drivers/net/can/spi/mcp25xxfd.c | 4509 ++++++++++++++++++++
> 4 files changed, 4548 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/can/microchip,mcp25xxfd.txt
> create mode 100644 drivers/net/can/spi/mcp25xxfd.c
>
> --
> 2.11.0
^ permalink raw reply
* Re: [PATCH] ARM: dts: cygnus: Add HWRNG node
From: Florian Fainelli @ 2018-06-06 17:32 UTC (permalink / raw)
To: Scott Branden, Florian Fainelli, Clément Péron,
devicetree
Cc: Rob Herring, Mark Rutland, Russell King, Ray Jui, Scott Branden,
Jon Mason, bcm-kernel-feedback-list, linux-arm-kernel,
linux-kernel, Clément Peron
In-Reply-To: <676106a4-d763-725c-2342-f8d215fbd169@broadcom.com>
On 06/06/2018 10:14 AM, Scott Branden wrote:
>
>
> On 18-06-06 09:47 AM, Florian Fainelli wrote:
>> On 06/06/2018 09:03 AM, Scott Branden wrote:
>>> Hi Clement,
>>>
>>>
>>> On 18-06-06 02:34 AM, Clément Péron wrote:
>>>> From: Clément Peron <clement.peron@devialet.com>
>>>>
>>>> There is a HWRNG in Broadcom Cygnus SoC, so enable it.
>>>>
>>>> Signed-off-by: Clément Peron <clement.peron@devialet.com>
>>> Thanks for upstreaming some missing Cygnus components.
>>>
>>> But, the problem is the tarball release from Broadcom you are extracting
>>> these changes from does not contain git history; so, you are missing the
>>> original authors and signed-off's.
>>> I checked our internal git repository and for this commit the author is:
>>> Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
>>>
>>> Please adjust author and signed-off appropriately. If there are other
>>> changes you are extracting from the source tarballs you have please
>>> contact me so we can construct patch appropriately.
>> If you want the original author's Signed-off-by to be preserved, why
>> don't you extract it from your internal git tree and submit the patch on
>> Mohamed's behalf?
> Sure, I can submit the original patch to keep things simple and avoid
> finding a lawyer right now.
>>
>> AFAICT what Clement is doing here is permissible given the Linux
>> developer certificate of origin though I am not a lawyer of course.
> But, It would be great to get some guidance and clarification on this
> for sure.
> I'm reading:
> https://www.kernel.org/doc/html/v4.16/process/submitting-patches.html
>
> The change was created entirely by Broadcom, so seems difficult for
> somebody else to upstream change without appropriate authorship and
> signed off from copyright holder.
Indeed, but it is effectively Broadcom's fault for not providing a git
tree for the customer to pull from in order to preserve the original
authorship, if what was distributed is a tarball of changes against a
vanilla kernel (which is likely to be the case), then all author
attributions are lost.
Not suggesting you change how you deliver code to customers, we have the
same issue in the STB/CM group, except maybe customers care less about
upstreaming so we can do it ourselves at our own pace and using our own
attributions.
> Point a) and b) are not met in
> Developer's Certificate of Origin while point c) is being attempted
> (without a or b being certified).
I would think that point a) and b) are met by the very fact that the
Cygnus kernel port is GPLv2 code, being a derivative work of the Linux
kernel, and that should be enough.
This is kind of well established things, this has happened for many
Broadcom product lines unfortunately because not everyone is active like
you in getting things upstreamed. Those contributions were still
entirely valid and acceptable for the kernel community.
Maybe we do need a lawyer, Saul Goodman, are you here?
--
Florian
^ permalink raw reply
* Re: [PATCH v3 2/2] gpu: drm/panel: Add DLC DLC0700YZG-1 panel
From: Eric Anholt @ 2018-06-06 17:38 UTC (permalink / raw)
To: Marco Felsch, thierry.reding, robh+dt, mark.rutland
Cc: devicetree, dri-devel, kernel
In-Reply-To: <20180523092504.5142-3-m.felsch@pengutronix.de>
[-- Attachment #1.1: Type: text/plain, Size: 239 bytes --]
Marco Felsch <m.felsch@pengutronix.de> writes:
> From: Philipp Zabel <p.zabel@pengutronix.de>
>
> This patch adds support for DLC DLC0700YZG-1 1024x600 LVDS panels
> to the simple-panel driver.
Reviewed-by: Eric Anholt <eric@anholt.net>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH v2 1/1] ARM: dts: cygnus: enable iproc-hwrng
From: Scott Branden @ 2018-06-06 18:21 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Ray Jui, Clement Peron,
Florian Fainelli
Cc: BCM Kernel Feedback, devicetree, linux-arm-kernel, linux-kernel,
Mohamed Ismail Abdul Packir Mohamed, Scott Branden
From: Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
Enable the HW rng driver "iproc-rng200" for all cygnus platforms.
Signed-off-by: Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 9fe4f5a..b0e38fa 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -417,6 +417,11 @@
status = "disabled";
};
+ rng: rng@18032000 {
+ compatible = "brcm,iproc-rng200";
+ reg = <0x18032000 0x28>;
+ };
+
sdhci0: sdhci@18041000 {
compatible = "brcm,sdhci-iproc-cygnus";
reg = <0x18041000 0x100>;
--
2.5.0
^ permalink raw reply related
* Re: [PATCH v4 0/6] Enhance support for the SP805 WDT
From: Florian Fainelli @ 2018-06-06 19:29 UTC (permalink / raw)
To: Ray Jui, Wim Van Sebroeck, Guenter Roeck, Rob Herring,
Mark Rutland, Frank Rowand, Catalin Marinas, Will Deacon,
Robin Murphy
Cc: linux-watchdog, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list
In-Reply-To: <1527530497-10392-1-git-send-email-ray.jui@broadcom.com>
On 05/28/2018 11:01 AM, Ray Jui wrote:
> This patch series enhances the support for the SP805 watchdog timer.
> First of all, 'timeout-sec' devicetree property is added. In addition,
> support is also added to allow the driver to reset the watchdog if it
> has been detected that watchdot has been started in the bootloader. In
> this case, the driver will initiate the ping service from the kernel
> watchdog subsystem, before a user mode daemon takes over. This series
> also enables SP805 in the default ARM64 defconfig
>
> This patch series is based off v4.17-rc5 and is available on GIHUB:
> repo: https://github.com/Broadcom/arm64-linux.git
> branch: sp805-wdt-v4
>
> Changes since v3:
> - Improve description of 'timeout-sec' in the binding document, per
> recommendation from Guenter Roeck
>
> Changes since v2:
> - Fix indent and format to make them consistent within arm,sp805.txt
>
> Changes since v1:
> - Consolidate two duplicated SP805 binding documents into one
> - Slight change of the wdt_is_running implementation per discussion
>
> Ray Jui (6):
> Documentation: DT: Consolidate SP805 binding docs
> Documentation: DT: Add optional 'timeout-sec' property for sp805
> watchdog: sp805: add 'timeout-sec' DT property support
> watchdog: sp805: set WDOG_HW_RUNNING when appropriate
> arm64: dt: set initial SR watchdog timeout to 60 seconds
> arm64: defconfig: add CONFIG_ARM_SP805_WATCHDOG
I can take the last two patches and Guenter would take the first 4 or
would you want to proceed differently?
--
Florian
^ permalink raw reply
* Re: [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Frank Rowand @ 2018-06-06 19:30 UTC (permalink / raw)
To: Michel Pollet, linux-renesas-soc@vger.kernel.org, Simon Horman
Cc: Michel Pollet, Mark Rutland, Phil Edworthy, Florian Fainelli,
Rajendra Nayak, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Stefan Wahren, Magnus Damm,
Russell King, Douglas Anderson, Chen-Yu Tsai, Rob Herring,
Carlo Caione, Andreas Färber, Frank Rowand,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <OSBPR01MB2054E3A1E383495F3534B551D2650@OSBPR01MB2054.jpnprd01.prod.outlook.com>
Hi Michel,
On 06/05/18 23:36, Michel Pollet wrote:
> Hi Frank,
>
> On 05 June 2018 18:34, Frank wrote:
>> On 06/05/18 04:28, Michel Pollet wrote:
>>> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time,
>>> it requires a special enable method to get it started.
>>>
>>> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>>> ---
>>> arch/arm/mach-shmobile/Makefile | 1 +
>>> arch/arm/mach-shmobile/smp-r9a06g032.c | 79
>>> ++++++++++++++++++++++++++++++++++
>>> 2 files changed, 80 insertions(+)
>>> create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
>>>
>>> diff --git a/arch/arm/mach-shmobile/Makefile
>>> b/arch/arm/mach-shmobile/Makefile index 1939f52..d7fc98f 100644
>>> --- a/arch/arm/mach-shmobile/Makefile
>>> +++ b/arch/arm/mach-shmobile/Makefile
>>> @@ -34,6 +34,7 @@ smp-$(CONFIG_ARCH_SH73A0)+= smp-sh73a0.o
>> headsmp-scu.o platsmp-scu.o
>>> smp-$(CONFIG_ARCH_R8A7779)+= smp-r8a7779.o headsmp-scu.o
>> platsmp-scu.o
>>> smp-$(CONFIG_ARCH_R8A7790)+= smp-r8a7790.o
>>> smp-$(CONFIG_ARCH_R8A7791)+= smp-r8a7791.o
>>> +smp-$(CONFIG_ARCH_R9A06G032)+= smp-r9a06g032.o
>>> smp-$(CONFIG_ARCH_EMEV2)+= smp-emev2.o headsmp-scu.o
>> platsmp-scu.o
>>>
>>> # PM objects
>>> diff --git a/arch/arm/mach-shmobile/smp-r9a06g032.c
>>> b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>> new file mode 100644
>>> index 0000000..cd40e6e
>>> --- /dev/null
>>> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>> @@ -0,0 +1,79 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * R9A06G032 Second CA7 enabler.
>>> + *
>>> + * Copyright (C) 2018 Renesas Electronics Europe Limited
>>> + *
>>> + * Michel Pollet <michel.pollet@bp.renesas.com>,
>> <buserror@gmail.com>
>>> + * Derived from action,s500-smp
>>> + */
>>> +
>>> +#include <linux/io.h>
>>> +#include <linux/of.h>
>>> +#include <linux/of_address.h>
>>> +#include <linux/smp.h>
>>> +
>>> +/*
>>> + * The second CPU is parked in ROM at boot time. It requires waking
>>> +it after
>>> + * writing an address into the BOOTADDR register of sysctrl.
>>> + *
>>> + * So the default value of the "cpu-release-addr" corresponds to
>> BOOTADDR...
>>> + *
>>> + * *However* the BOOTADDR register is not available when the kernel
>>> + * starts in NONSEC mode.
>>> + *
>>> + * So for NONSEC mode, the bootloader re-parks the second CPU into a
>>> +pen
>>> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a
>>> +SRAM address,
>>> + * which is not restricted.
>>
>> The binding document for cpu-release-addr does not have a definition for 32
>> bit arm. The existing definition is only 64 bit arm. Please add the definition
>> for 32 bit arm to patch 1.
>
> Hmmm I do find a definition in
> Documentation/devicetree/bindings/arm/cpus.txt -- just under where I
> added my 'enable-method' -- And it is already used as 32 bits in at least
> arch/arm/boot/dts/stih407-family.dtsi.
>From cpus.txt:
- cpu-release-addr
Usage: required for systems that have an "enable-method"
property value of "spin-table".
Value type: <prop-encoded-array>
Definition:
# On ARM v8 64-bit systems must be a two cell
property identifying a 64-bit zero-initialised
memory location.
The definition specifies a two cell property for 64-bit systems.
Please add to the definition that cpu-release-addr is a one cell property
for 32-bit systems.
-Frank
>
> What do you want me to add to this exactly? Do you want me to just
> change "required for systems that have an "enable-method" property
> value of "spin-table" to also specify renesas,r9a06g032 ?
>
> Thanks!
> Michel
>
>>
>> -Frank
>>
>>
>>> + */
>>> +
>>> +static void __iomem *cpu_bootaddr;
>>> +
>>> +static DEFINE_SPINLOCK(cpu_lock);
>>> +
>>> +static int r9a06g032_smp_boot_secondary(unsigned int cpu, struct
>>> +task_struct *idle) {
>>> +if (!cpu_bootaddr)
>>> +return -ENODEV;
>>> +
>>> +spin_lock(&cpu_lock);
>>> +
>>> +writel(__pa_symbol(secondary_startup), cpu_bootaddr);
>>> +arch_send_wakeup_ipi_mask(cpumask_of(cpu));
>>> +
>>> +spin_unlock(&cpu_lock);
>>> +
>>> +return 0;
>>> +}
>>> +
>>> +static void __init r9a06g032_smp_prepare_cpus(unsigned int max_cpus)
>>> +{
>>> +struct device_node *dn;
>>> +int ret;
>>> +u32 bootaddr;
>>> +
>>> +dn = of_get_cpu_node(1, NULL);
>>> +if (!dn) {
>>> +pr_err("CPU#1: missing device tree node\n");
>>> +return;
>>> +}
>>> +/*
>>> + * Determine the address from which the CPU is polling.
>>> + * The bootloader *does* change this property
>>> + */
>>> +ret = of_property_read_u32(dn, "cpu-release-addr", &bootaddr);
>>> +of_node_put(dn);
>>> +if (ret) {
>>> +pr_err("CPU#1: invalid cpu-release-addr property\n");
>>> +return;
>>> +}
>>> +pr_info("CPU#1: cpu-release-addr %08x\n", bootaddr);
>>> +
>>> +cpu_bootaddr = ioremap(bootaddr, sizeof(bootaddr)); }
>>> +
>>> +static const struct smp_operations r9a06g032_smp_ops __initconst = {
>>> +.smp_prepare_cpus = r9a06g032_smp_prepare_cpus,
>>> +.smp_boot_secondary = r9a06g032_smp_boot_secondary, };
>>> +CPU_METHOD_OF_DECLARE(r9a06g032_smp, "renesas,r9a06g032-smp",
>>> +&r9a06g032_smp_ops);
>>>
>
>
>
>
> Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
>
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: dts: allwinner: a64: add R_I2C controller
From: Maxime Ripard @ 2018-06-06 19:32 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Catalin Marinas, Will Deacon,
Chen-Yu Tsai, Rob Herring, linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20180606051702.6478-2-anarsoul@gmail.com>
On Tue, Jun 05, 2018 at 10:17:00PM -0700, Vasily Khoruzhick wrote:
> From: Icenowy Zheng <icenowy@aosc.io>
>
> Allwinner A64 has a I2C controller, which is in the R_ MMIO zone and has
> two groups of pinmuxes on PL bank, so it's called R_I2C.
>
> Add support for this I2C controller and the pinmux which doesn't conflict
> with RSB.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 24 +++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 1b2ef28c42bd..dcf957b2e7c8 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -46,6 +46,7 @@
> #include <dt-bindings/clock/sun8i-r-ccu.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/reset/sun50i-a64-ccu.h>
> +#include <dt-bindings/reset/sun8i-r-ccu.h>
>
> / {
> interrupt-parent = <&gic>;
> @@ -655,6 +656,18 @@
> #reset-cells = <1>;
> };
>
> + r_i2c: i2c@1f02400 {
> + compatible = "allwinner,sun50i-a64-i2c",
> + "allwinner,sun6i-a31-i2c";
> + reg = <0x01f02400 0x400>;
> + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&r_ccu CLK_APB0_I2C>;
> + resets = <&r_ccu RST_APB0_I2C>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> r_pio: pinctrl@1f02c00 {
> compatible = "allwinner,sun50i-a64-r-pinctrl";
> reg = <0x01f02c00 0x400>;
> @@ -666,6 +679,17 @@
> interrupt-controller;
> #interrupt-cells = <3>;
>
> +
> + r_i2c_pins: i2c {
> + pins = "PL0", "PL1";
> + function = "s_i2c";
> + };
> +
We usually don't have pin groups that are not used by any boards. I've
removed it and applied.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 2/3] arm64: dts: allwinner: a64: Add PWM controllers
From: Maxime Ripard @ 2018-06-06 19:32 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Catalin Marinas, Will Deacon,
Chen-Yu Tsai, Rob Herring, Andre Przywara, linux-arm-kernel
In-Reply-To: <20180606051702.6478-3-anarsoul@gmail.com>
On Tue, Jun 05, 2018 at 10:17:01PM -0700, Vasily Khoruzhick wrote:
> From: Andre Przywara <andre.przywara@arm.com>
>
> The Allwinner A64 SoC features two PWM controllers, which are fully
> compatible to the one used in the A13 and H3 chips.
>
> Add the nodes for the devices (one for the "normal" PWM, the other for
> the one in the CPUS domain) and the pins their outputs are connected to.
>
> On the A64 the "normal" PWM is muxed together with one of the MDIO pins
> used to communicate with the Ethernet PHY, so it won't be usable on many
> boards. But the Pinebook laptop uses this pin for controlling the LCD
> backlight.
>
> On Pine64 the CPUS PWM pin however is routed to the "RPi2" header,
> at the same location as the PWM pin on the RaspberryPi.
>
> Tested on Pinebook and Teres-I
>
> [vasily: fixed comment message as requested by Stefan Bruens, added default
> muxing options to pwm and r_pwm nodes]
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> Tested-by: Harald Geyer <harald@ccbib.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Rob Herring @ 2018-06-06 19:35 UTC (permalink / raw)
To: Frank Rowand
Cc: Michel Pollet, linux-renesas-soc@vger.kernel.org, Simon Horman,
Michel Pollet, Mark Rutland, Phil Edworthy, Florian Fainelli,
Rajendra Nayak, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Stefan Wahren, Magnus Damm,
Russell King, Douglas Anderson, Chen-Yu Tsai, Carlo Caione,
Andreas Färber
In-Reply-To: <bbbd287c-437e-d7bd-d40f-6bb914d96860@gmail.com>
On Wed, Jun 6, 2018 at 2:30 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> Hi Michel,
>
> On 06/05/18 23:36, Michel Pollet wrote:
>> Hi Frank,
>>
>> On 05 June 2018 18:34, Frank wrote:
>>> On 06/05/18 04:28, Michel Pollet wrote:
>>>> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time,
>>>> it requires a special enable method to get it started.
>>>>
>>>> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>>>> ---
>>>> arch/arm/mach-shmobile/Makefile | 1 +
>>>> arch/arm/mach-shmobile/smp-r9a06g032.c | 79
>>>> ++++++++++++++++++++++++++++++++++
>>>> 2 files changed, 80 insertions(+)
>>>> create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
>>>>
>>>> diff --git a/arch/arm/mach-shmobile/Makefile
>>>> b/arch/arm/mach-shmobile/Makefile index 1939f52..d7fc98f 100644
>>>> --- a/arch/arm/mach-shmobile/Makefile
>>>> +++ b/arch/arm/mach-shmobile/Makefile
>>>> @@ -34,6 +34,7 @@ smp-$(CONFIG_ARCH_SH73A0)+= smp-sh73a0.o
>>> headsmp-scu.o platsmp-scu.o
>>>> smp-$(CONFIG_ARCH_R8A7779)+= smp-r8a7779.o headsmp-scu.o
>>> platsmp-scu.o
>>>> smp-$(CONFIG_ARCH_R8A7790)+= smp-r8a7790.o
>>>> smp-$(CONFIG_ARCH_R8A7791)+= smp-r8a7791.o
>>>> +smp-$(CONFIG_ARCH_R9A06G032)+= smp-r9a06g032.o
>>>> smp-$(CONFIG_ARCH_EMEV2)+= smp-emev2.o headsmp-scu.o
>>> platsmp-scu.o
>>>>
>>>> # PM objects
>>>> diff --git a/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>> b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>> new file mode 100644
>>>> index 0000000..cd40e6e
>>>> --- /dev/null
>>>> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>> @@ -0,0 +1,79 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +/*
>>>> + * R9A06G032 Second CA7 enabler.
>>>> + *
>>>> + * Copyright (C) 2018 Renesas Electronics Europe Limited
>>>> + *
>>>> + * Michel Pollet <michel.pollet@bp.renesas.com>,
>>> <buserror@gmail.com>
>>>> + * Derived from action,s500-smp
>>>> + */
>>>> +
>>>> +#include <linux/io.h>
>>>> +#include <linux/of.h>
>>>> +#include <linux/of_address.h>
>>>> +#include <linux/smp.h>
>>>> +
>>>> +/*
>>>> + * The second CPU is parked in ROM at boot time. It requires waking
>>>> +it after
>>>> + * writing an address into the BOOTADDR register of sysctrl.
>>>> + *
>>>> + * So the default value of the "cpu-release-addr" corresponds to
>>> BOOTADDR...
>>>> + *
>>>> + * *However* the BOOTADDR register is not available when the kernel
>>>> + * starts in NONSEC mode.
>>>> + *
>>>> + * So for NONSEC mode, the bootloader re-parks the second CPU into a
>>>> +pen
>>>> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a
>>>> +SRAM address,
>>>> + * which is not restricted.
>>>
>>> The binding document for cpu-release-addr does not have a definition for 32
>>> bit arm. The existing definition is only 64 bit arm. Please add the definition
>>> for 32 bit arm to patch 1.
>>
>> Hmmm I do find a definition in
>> Documentation/devicetree/bindings/arm/cpus.txt -- just under where I
>> added my 'enable-method' -- And it is already used as 32 bits in at least
>> arch/arm/boot/dts/stih407-family.dtsi.
>
> From cpus.txt:
>
> - cpu-release-addr
> Usage: required for systems that have an "enable-method"
> property value of "spin-table".
> Value type: <prop-encoded-array>
> Definition:
> # On ARM v8 64-bit systems must be a two cell
> property identifying a 64-bit zero-initialised
> memory location.
>
> The definition specifies a two cell property for 64-bit systems.
>
> Please add to the definition that cpu-release-addr is a one cell property
> for 32-bit systems.
Actually, this is all already documented in the DT spec and it is
always 2 cells[1]. We should perhaps just remove whatever is
duplicated from the spec.
Rob
[1]
``cpu-release-addr`` | SD | ``<u64>`` The
cpu-release-addr property is required for
cpu nodes that have
an enable-method property
value of
``"spin-table"``. The value specifies the
physical address of
a spin table entry that
releases a
secondary CPU from its spin loop.
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: allwinner: add support for Pinebook
From: Maxime Ripard @ 2018-06-06 19:37 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Catalin Marinas, Will Deacon,
Chen-Yu Tsai, Rob Herring, Icenowy Zheng, linux-arm-kernel
In-Reply-To: <20180606051702.6478-4-anarsoul@gmail.com>
On Tue, Jun 05, 2018 at 10:17:02PM -0700, Vasily Khoruzhick wrote:
> From: Icenowy Zheng <icenowy@aosc.xyz>
>
> Pinebook is a A64-based laptop produced by Pine64, with the following
> peripherals:
>
> USB:
> - Two external USB ports (one is directly connected to A64's OTG
> controller, the other is under a internal hub connected to the host-only
> controller.)
> - USB HID keyboard and touchpad connected to the internal hub.
> - USB UVC camera connected to the internal hub.
>
> Power-related:
> - A DC IN jack connected to AXP803's DCIN pin.
> - A Li-Polymer battery connected to AXP803's battery pins.
>
> Storage:
> - An eMMC by Foresee on the main board (in the product revision of the
> main board it's designed to be switchable).
> - An external MicroSD card slot.
>
> Display:
> - An eDP LCD panel (1366x768) connected via an ANX6345 RGB-eDP bridge.
> - A mini HDMI port.
>
> Misc:
> - A Hall sensor designed to detect the status of lid, connected to GPIO PL12.
> - A headphone jack connected to the SoC's internal codec.
> - A debug UART port muxed with headphone jack.
>
> This commit adds basical support for it.
>
> [vasily: squashed several commits into one, added simplefb node, added usbphy
> to ehci0 and ohci0 nodes and other cosmetic changes to dts]
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
I've updated Icenowy's domain and applied, thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH 1/2] MIPS: Ci20: Enable SPI/GPIO driver
From: Mathieu Malaterre @ 2018-06-06 19:37 UTC (permalink / raw)
To: James Hogan
Cc: Mathieu Malaterre, Rob Herring, Mark Rutland, Ralf Baechle,
devicetree, linux-mips, linux-kernel
Update the Ci20's defconfig to enable the JZ4780's SPI/GPIO driver.
Signed-off-by: Mathieu Malaterre <malat@debian.org>
---
arch/mips/configs/ci20_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig
index 0ddef6ad2652..0c08c7675b42 100644
--- a/arch/mips/configs/ci20_defconfig
+++ b/arch/mips/configs/ci20_defconfig
@@ -93,6 +93,8 @@ CONFIG_SERIAL_OF_PLATFORM=y
# CONFIG_HW_RANDOM is not set
CONFIG_I2C=y
CONFIG_I2C_JZ4780=y
+CONFIG_SPI=y
+CONFIG_SPI_GPIO=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_INGENIC=y
# CONFIG_HWMON is not set
--
2.11.0
^ permalink raw reply related
* [PATCH 2/2] MIPS: jz4780: DTS: Probe the spi-gpio driver from devicetree
From: Mathieu Malaterre @ 2018-06-06 19:37 UTC (permalink / raw)
To: James Hogan
Cc: Mathieu Malaterre, Rob Herring, Mark Rutland, Ralf Baechle,
devicetree, linux-mips, linux-kernel
In-Reply-To: <20180606193730.15087-1-malat@debian.org>
The spi-gpio driver supports jz4780.
Signed-off-by: Mathieu Malaterre <malat@debian.org>
---
arch/mips/boot/dts/ingenic/jz4780.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index 809f01a62955..308079ee8dd3 100644
--- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
@@ -167,6 +167,25 @@
};
};
+ spi_gpio {
+ compatible = "spi-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ num-chipselects = <2>;
+
+ gpio-miso = <&gpe 14 0>;
+ gpio-sck = <&gpe 15 0>;
+ gpio-mosi = <&gpe 17 0>;
+ cs-gpios = <&gpe 16 0
+ &gpe 18 0>;
+
+ spidev@0 {
+ compatible = "spidev";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+ };
+
uart0: serial@10030000 {
compatible = "ingenic,jz4780-uart";
reg = <0x10030000 0x100>;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Florian Fainelli @ 2018-06-06 19:37 UTC (permalink / raw)
To: Frank Rowand, Michel Pollet, linux-renesas-soc@vger.kernel.org,
Simon Horman
Cc: Michel Pollet, Mark Rutland, Phil Edworthy, Rajendra Nayak,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Stefan Wahren, Magnus Damm, Russell King, Douglas Anderson,
Chen-Yu Tsai, Rob Herring, Carlo Caione, Andreas Färber,
Frank Rowand, linux-arm-kernel@lists.infradead.org
In-Reply-To: <bbbd287c-437e-d7bd-d40f-6bb914d96860@gmail.com>
On 06/06/2018 12:30 PM, Frank Rowand wrote:
> Hi Michel,
>
> On 06/05/18 23:36, Michel Pollet wrote:
>> Hi Frank,
>>
>> On 05 June 2018 18:34, Frank wrote:
>>> On 06/05/18 04:28, Michel Pollet wrote:
>>>> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time,
>>>> it requires a special enable method to get it started.
>>>>
>>>> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>>>> ---
>>>> arch/arm/mach-shmobile/Makefile | 1 +
>>>> arch/arm/mach-shmobile/smp-r9a06g032.c | 79
>>>> ++++++++++++++++++++++++++++++++++
>>>> 2 files changed, 80 insertions(+)
>>>> create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
>>>>
>>>> diff --git a/arch/arm/mach-shmobile/Makefile
>>>> b/arch/arm/mach-shmobile/Makefile index 1939f52..d7fc98f 100644
>>>> --- a/arch/arm/mach-shmobile/Makefile
>>>> +++ b/arch/arm/mach-shmobile/Makefile
>>>> @@ -34,6 +34,7 @@ smp-$(CONFIG_ARCH_SH73A0)+= smp-sh73a0.o
>>> headsmp-scu.o platsmp-scu.o
>>>> smp-$(CONFIG_ARCH_R8A7779)+= smp-r8a7779.o headsmp-scu.o
>>> platsmp-scu.o
>>>> smp-$(CONFIG_ARCH_R8A7790)+= smp-r8a7790.o
>>>> smp-$(CONFIG_ARCH_R8A7791)+= smp-r8a7791.o
>>>> +smp-$(CONFIG_ARCH_R9A06G032)+= smp-r9a06g032.o
>>>> smp-$(CONFIG_ARCH_EMEV2)+= smp-emev2.o headsmp-scu.o
>>> platsmp-scu.o
>>>>
>>>> # PM objects
>>>> diff --git a/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>> b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>> new file mode 100644
>>>> index 0000000..cd40e6e
>>>> --- /dev/null
>>>> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>> @@ -0,0 +1,79 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +/*
>>>> + * R9A06G032 Second CA7 enabler.
>>>> + *
>>>> + * Copyright (C) 2018 Renesas Electronics Europe Limited
>>>> + *
>>>> + * Michel Pollet <michel.pollet@bp.renesas.com>,
>>> <buserror@gmail.com>
>>>> + * Derived from action,s500-smp
>>>> + */
>>>> +
>>>> +#include <linux/io.h>
>>>> +#include <linux/of.h>
>>>> +#include <linux/of_address.h>
>>>> +#include <linux/smp.h>
>>>> +
>>>> +/*
>>>> + * The second CPU is parked in ROM at boot time. It requires waking
>>>> +it after
>>>> + * writing an address into the BOOTADDR register of sysctrl.
>>>> + *
>>>> + * So the default value of the "cpu-release-addr" corresponds to
>>> BOOTADDR...
>>>> + *
>>>> + * *However* the BOOTADDR register is not available when the kernel
>>>> + * starts in NONSEC mode.
>>>> + *
>>>> + * So for NONSEC mode, the bootloader re-parks the second CPU into a
>>>> +pen
>>>> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a
>>>> +SRAM address,
>>>> + * which is not restricted.
>>>
>>> The binding document for cpu-release-addr does not have a definition for 32
>>> bit arm. The existing definition is only 64 bit arm. Please add the definition
>>> for 32 bit arm to patch 1.
>>
>> Hmmm I do find a definition in
>> Documentation/devicetree/bindings/arm/cpus.txt -- just under where I
>> added my 'enable-method' -- And it is already used as 32 bits in at least
>> arch/arm/boot/dts/stih407-family.dtsi.
>
> From cpus.txt:
>
> - cpu-release-addr
> Usage: required for systems that have an "enable-method"
> property value of "spin-table".
> Value type: <prop-encoded-array>
> Definition:
> # On ARM v8 64-bit systems must be a two cell
> property identifying a 64-bit zero-initialised
> memory location.
>
> The definition specifies a two cell property for 64-bit systems.
>
> Please add to the definition that cpu-release-addr is a one cell property
> for 32-bit systems.
Or maybe phrase it such that the number of cells encoded in
cpu-release-addr must exactly match the CPU node's #address-cells size?
--
Florian
^ permalink raw reply
* [PATCH 1/3] MIPS: jz4780: Allow access to jz4740-i2s
From: Mathieu Malaterre @ 2018-06-06 19:38 UTC (permalink / raw)
To: James Hogan
Cc: Mathieu Malaterre, Rob Herring, Mark Rutland, Ralf Baechle,
Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
devicetree, linux-mips, linux-kernel, alsa-devel
Make it possible to select SND_JZ4740_SOC_I2S on MACH_JZ4780
Signed-off-by: Mathieu Malaterre <malat@debian.org>
---
sound/soc/jz4740/Kconfig | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/sound/soc/jz4740/Kconfig b/sound/soc/jz4740/Kconfig
index 1a354a6b6e87..35d82d96e781 100644
--- a/sound/soc/jz4740/Kconfig
+++ b/sound/soc/jz4740/Kconfig
@@ -1,20 +1,20 @@
config SND_JZ4740_SOC
- tristate "SoC Audio for Ingenic JZ4740 SoC"
- depends on MACH_JZ4740 || COMPILE_TEST
+ tristate "SoC Audio for Ingenic JZ4740/JZ4780 SoC"
+ depends on MACH_JZ4740 || MACH_JZ4780 || COMPILE_TEST
select SND_SOC_GENERIC_DMAENGINE_PCM
help
Say Y or M if you want to add support for codecs attached to
- the JZ4740 I2S interface. You will also need to select the audio
+ the JZ4740/JZ4780 I2S interface. You will also need to select the audio
interfaces to support below.
if SND_JZ4740_SOC
config SND_JZ4740_SOC_I2S
- tristate "SoC Audio (I2S protocol) for Ingenic JZ4740 SoC"
+ tristate "SoC Audio (I2S protocol) for Ingenic JZ4740/JZ4780 SoC"
depends on HAS_IOMEM
help
Say Y if you want to use I2S protocol and I2S codec on Ingenic JZ4740
- based boards.
+ or JZ4780 based boards.
config SND_JZ4740_SOC_QI_LB60
tristate "SoC Audio support for Qi LB60"
--
2.11.0
^ permalink raw reply related
* [PATCH 2/3] MIPS: Ci20: Enable SND_JZ4740_SOC driver
From: Mathieu Malaterre @ 2018-06-06 19:38 UTC (permalink / raw)
To: James Hogan
Cc: Mathieu Malaterre, Rob Herring, Mark Rutland, Ralf Baechle,
Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
devicetree, linux-mips, linux-kernel, alsa-devel
In-Reply-To: <20180606193811.16007-1-malat@debian.org>
Update the Ci20's defconfig to enable the JZ4780's SND driver.
Signed-off-by: Mathieu Malaterre <malat@debian.org>
---
arch/mips/configs/ci20_defconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig
index e1c14f6af824..0c08c7675b42 100644
--- a/arch/mips/configs/ci20_defconfig
+++ b/arch/mips/configs/ci20_defconfig
@@ -104,6 +104,10 @@ CONFIG_REGULATOR=y
CONFIG_REGULATOR_DEBUG=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
# CONFIG_VGA_CONSOLE is not set
+CONFIG_SOUND=y
+CONFIG_SND=y
+CONFIG_SND_SOC=y
+CONFIG_SND_JZ4740_SOC=y
# CONFIG_HID is not set
# CONFIG_USB_SUPPORT is not set
CONFIG_MMC=y
--
2.11.0
^ permalink raw reply related
* [PATCH 3/3] MIPS: jz4780: DTS: Probe the jz4740-i2s driver from devicetree
From: Mathieu Malaterre @ 2018-06-06 19:38 UTC (permalink / raw)
To: James Hogan
Cc: Mathieu Malaterre, Rob Herring, Mark Rutland, Ralf Baechle,
Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
devicetree, linux-mips, linux-kernel, alsa-devel
In-Reply-To: <20180606193811.16007-1-malat@debian.org>
Since commit 967beb2e8777 ("ASoC: jz4740: Add jz4780 support"), jz4740-i2s
driver supports jz4780 hardware. Use proper compatible string.
Signed-off-by: Mathieu Malaterre <malat@debian.org>
---
arch/mips/boot/dts/ingenic/jz4780.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index ae57976bc016..308079ee8dd3 100644
--- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
@@ -57,6 +57,18 @@
clock-names = "rtc";
};
+ i2s: i2s@10020000 {
+ compatible = "ingenic,jz4780-i2s";
+ reg = <0x10020000 0x94>;
+
+ clocks = <&cgu JZ4780_CLK_AIC>, <&cgu JZ4780_CLK_I2SPLL>;
+ clock-names = "aic", "i2s";
+
+ dmas = <&dma 0 JZ4780_DMA_I2S0_RX 0xffffffff>,
+ <&dma JZ4780_DMA_I2S0_TX 0 0xffffffff>;
+ dma-names = "rx" , "tx";
+ };
+
pinctrl: pin-controller@10010000 {
compatible = "ingenic,jz4780-pinctrl";
reg = <0x10010000 0x600>;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Geert Uytterhoeven @ 2018-06-06 19:42 UTC (permalink / raw)
To: Rob Herring
Cc: Frank Rowand, Michel Pollet, linux-renesas-soc@vger.kernel.org,
Simon Horman, Michel Pollet, Mark Rutland, Phil Edworthy,
Florian Fainelli, Rajendra Nayak, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Stefan Wahren, Magnus Damm,
Russell King, Douglas Anderson, Chen-Yu Tsai, Carlo Caione
In-Reply-To: <CAL_JsqJCkP_c_wKGRc7Qzkiw8sZLRf6MGz-WgVsLjnQfqK8r6Q@mail.gmail.com>
Hi Rob,
On Wed, Jun 6, 2018 at 9:35 PM, Rob Herring <robh+dt@kernel.org> wrote:
> On Wed, Jun 6, 2018 at 2:30 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>> On 06/05/18 23:36, Michel Pollet wrote:
>>> On 05 June 2018 18:34, Frank wrote:
>>>> On 06/05/18 04:28, Michel Pollet wrote:
>>>>> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time,
>>>>> it requires a special enable method to get it started.
>>>>>
>>>>> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>>> +/*
>>>>> + * The second CPU is parked in ROM at boot time. It requires waking
>>>>> +it after
>>>>> + * writing an address into the BOOTADDR register of sysctrl.
>>>>> + *
>>>>> + * So the default value of the "cpu-release-addr" corresponds to
>>>> BOOTADDR...
>>>>> + *
>>>>> + * *However* the BOOTADDR register is not available when the kernel
>>>>> + * starts in NONSEC mode.
>>>>> + *
>>>>> + * So for NONSEC mode, the bootloader re-parks the second CPU into a
>>>>> +pen
>>>>> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a
>>>>> +SRAM address,
>>>>> + * which is not restricted.
>>>>
>>>> The binding document for cpu-release-addr does not have a definition for 32
>>>> bit arm. The existing definition is only 64 bit arm. Please add the definition
>>>> for 32 bit arm to patch 1.
>>>
>>> Hmmm I do find a definition in
>>> Documentation/devicetree/bindings/arm/cpus.txt -- just under where I
>>> added my 'enable-method' -- And it is already used as 32 bits in at least
>>> arch/arm/boot/dts/stih407-family.dtsi.
>>
>> From cpus.txt:
>>
>> - cpu-release-addr
>> Usage: required for systems that have an "enable-method"
>> property value of "spin-table".
>> Value type: <prop-encoded-array>
>> Definition:
>> # On ARM v8 64-bit systems must be a two cell
>> property identifying a 64-bit zero-initialised
>> memory location.
>>
>> The definition specifies a two cell property for 64-bit systems.
>>
>> Please add to the definition that cpu-release-addr is a one cell property
>> for 32-bit systems.
>
> Actually, this is all already documented in the DT spec and it is
> always 2 cells[1]. We should perhaps just remove whatever is
> duplicated from the spec.
>
> Rob
>
> [1]
> ``cpu-release-addr`` | SD | ``<u64>`` The
> cpu-release-addr property is required for
> cpu nodes that have
> an enable-method property
> value of
> ``"spin-table"``. The value specifies the
> physical address of
> a spin table entry that
> releases a
> secondary CPU from its spin loop.
Interesting. But why is this <u64>, and not just following #address-cells?
Due to the ePAPR-spec being 64-bit Power System-centric?
There's also "initial-mapped-area", which must use 64-bit values for effective
and physical addresses, according to ePAPR.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Geert Uytterhoeven @ 2018-06-06 19:46 UTC (permalink / raw)
To: Florian Fainelli
Cc: Frank Rowand, Michel Pollet, linux-renesas-soc@vger.kernel.org,
Simon Horman, Michel Pollet, Mark Rutland, Phil Edworthy,
Douglas Anderson, Rajendra Nayak, devicetree@vger.kernel.org,
Stefan Wahren, Magnus Damm, linux-kernel@vger.kernel.org,
Russell King, Chen-Yu Tsai, Rob Herring, Carlo Caione
In-Reply-To: <7e49c265-e332-29c5-5d91-4b5d5da6cb37@gmail.com>
Hi Florian,
On Wed, Jun 6, 2018 at 9:37 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 06/06/2018 12:30 PM, Frank Rowand wrote:
>> On 06/05/18 23:36, Michel Pollet wrote:
>>> On 05 June 2018 18:34, Frank wrote:
>>>> On 06/05/18 04:28, Michel Pollet wrote:
>>>>> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time,
>>>>> it requires a special enable method to get it started.
>>>>>
>>>>> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>>> +/*
>>>>> + * The second CPU is parked in ROM at boot time. It requires waking
>>>>> +it after
>>>>> + * writing an address into the BOOTADDR register of sysctrl.
>>>>> + *
>>>>> + * So the default value of the "cpu-release-addr" corresponds to
>>>> BOOTADDR...
>>>>> + *
>>>>> + * *However* the BOOTADDR register is not available when the kernel
>>>>> + * starts in NONSEC mode.
>>>>> + *
>>>>> + * So for NONSEC mode, the bootloader re-parks the second CPU into a
>>>>> +pen
>>>>> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a
>>>>> +SRAM address,
>>>>> + * which is not restricted.
>>>>
>>>> The binding document for cpu-release-addr does not have a definition for 32
>>>> bit arm. The existing definition is only 64 bit arm. Please add the definition
>>>> for 32 bit arm to patch 1.
>>>
>>> Hmmm I do find a definition in
>>> Documentation/devicetree/bindings/arm/cpus.txt -- just under where I
>>> added my 'enable-method' -- And it is already used as 32 bits in at least
>>> arch/arm/boot/dts/stih407-family.dtsi.
>>
>> From cpus.txt:
>>
>> - cpu-release-addr
>> Usage: required for systems that have an "enable-method"
>> property value of "spin-table".
>> Value type: <prop-encoded-array>
>> Definition:
>> # On ARM v8 64-bit systems must be a two cell
>> property identifying a 64-bit zero-initialised
>> memory location.
>>
>> The definition specifies a two cell property for 64-bit systems.
>>
>> Please add to the definition that cpu-release-addr is a one cell property
>> for 32-bit systems.
>
> Or maybe phrase it such that the number of cells encoded in
> cpu-release-addr must exactly match the CPU node's #address-cells size?
The CPU node's #address-cells size is unrelated.
You need the #address-cells value from the SoC bus (typically the root
node, not considering heterogeneous systems with multiple CPUs ;-).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: allwinner: add support for Pinebook
From: Vasily Khoruzhick @ 2018-06-06 20:16 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Catalin Marinas, Will Deacon,
Chen-Yu Tsai, Rob Herring, Icenowy Zheng, arm-linux
In-Reply-To: <20180606193701.seerxyy6g3nx3flk@flea>
On Wed, Jun 6, 2018 at 12:37 PM, Maxime Ripard
<maxime.ripard@bootlin.com> wrote:
>
> I've updated Icenowy's domain and applied, thanks!
> Maxime
Thanks!
^ permalink raw reply
* Re: [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Rob Herring @ 2018-06-06 20:28 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Frank Rowand, Michel Pollet, linux-renesas-soc@vger.kernel.org,
Simon Horman, Michel Pollet, Mark Rutland, Phil Edworthy,
Florian Fainelli, Rajendra Nayak, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Stefan Wahren, Magnus Damm,
Russell King, Douglas Anderson, Chen-Yu Tsai, Carlo Caione
In-Reply-To: <CAMuHMdXv2UXTx_ttCqytH2TePoJ-Pw4gJ-PaSOmUL969ac1BMw@mail.gmail.com>
On Wed, Jun 6, 2018 at 2:42 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Rob,
>
> On Wed, Jun 6, 2018 at 9:35 PM, Rob Herring <robh+dt@kernel.org> wrote:
>> On Wed, Jun 6, 2018 at 2:30 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>>> On 06/05/18 23:36, Michel Pollet wrote:
>>>> On 05 June 2018 18:34, Frank wrote:
>>>>> On 06/05/18 04:28, Michel Pollet wrote:
>>>>>> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time,
>>>>>> it requires a special enable method to get it started.
>>>>>>
>>>>>> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>
>>>>>> --- /dev/null
>>>>>> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
>
>>>>>> +/*
>>>>>> + * The second CPU is parked in ROM at boot time. It requires waking
>>>>>> +it after
>>>>>> + * writing an address into the BOOTADDR register of sysctrl.
>>>>>> + *
>>>>>> + * So the default value of the "cpu-release-addr" corresponds to
>>>>> BOOTADDR...
>>>>>> + *
>>>>>> + * *However* the BOOTADDR register is not available when the kernel
>>>>>> + * starts in NONSEC mode.
>>>>>> + *
>>>>>> + * So for NONSEC mode, the bootloader re-parks the second CPU into a
>>>>>> +pen
>>>>>> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a
>>>>>> +SRAM address,
>>>>>> + * which is not restricted.
>>>>>
>>>>> The binding document for cpu-release-addr does not have a definition for 32
>>>>> bit arm. The existing definition is only 64 bit arm. Please add the definition
>>>>> for 32 bit arm to patch 1.
>>>>
>>>> Hmmm I do find a definition in
>>>> Documentation/devicetree/bindings/arm/cpus.txt -- just under where I
>>>> added my 'enable-method' -- And it is already used as 32 bits in at least
>>>> arch/arm/boot/dts/stih407-family.dtsi.
>>>
>>> From cpus.txt:
>>>
>>> - cpu-release-addr
>>> Usage: required for systems that have an "enable-method"
>>> property value of "spin-table".
>>> Value type: <prop-encoded-array>
>>> Definition:
>>> # On ARM v8 64-bit systems must be a two cell
>>> property identifying a 64-bit zero-initialised
>>> memory location.
>>>
>>> The definition specifies a two cell property for 64-bit systems.
>>>
>>> Please add to the definition that cpu-release-addr is a one cell property
>>> for 32-bit systems.
>>
>> Actually, this is all already documented in the DT spec and it is
>> always 2 cells[1]. We should perhaps just remove whatever is
>> duplicated from the spec.
>>
>> Rob
>>
>> [1]
>> ``cpu-release-addr`` | SD | ``<u64>`` The
>> cpu-release-addr property is required for
>> cpu nodes that have
>> an enable-method property
>> value of
>> ``"spin-table"``. The value specifies the
>> physical address of
>> a spin table entry that
>> releases a
>> secondary CPU from its spin loop.
>
> Interesting. But why is this <u64>, and not just following #address-cells?
As you said in your other email, it's not the same.
> Due to the ePAPR-spec being 64-bit Power System-centric?
Other than #address-cells already having another defined purpose in
/cpus, my guess is 64-bit works for either and 32-bit SMP systems
didn't predate 64-bit (for the ePAPR author's perspective).
> There's also "initial-mapped-area", which must use 64-bit values for effective
> and physical addresses, according to ePAPR.
I would have thought that followed #{size,address}-cells being
/memory. Though, I guess the bootloader fills this in and it is much
easier to work with fixed sizes.
Rob
^ permalink raw reply
* Re: [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Frank Rowand @ 2018-06-06 21:31 UTC (permalink / raw)
To: Rob Herring
Cc: Michel Pollet, linux-renesas-soc@vger.kernel.org, Simon Horman,
Michel Pollet, Mark Rutland, Phil Edworthy, Florian Fainelli,
Rajendra Nayak, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Stefan Wahren, Magnus Damm,
Russell King, Douglas Anderson, Chen-Yu Tsai, Carlo Caione,
Andreas Färber
In-Reply-To: <CAL_JsqJCkP_c_wKGRc7Qzkiw8sZLRf6MGz-WgVsLjnQfqK8r6Q@mail.gmail.com>
On 06/06/18 12:35, Rob Herring wrote:
> On Wed, Jun 6, 2018 at 2:30 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>> Hi Michel,
>>
>> On 06/05/18 23:36, Michel Pollet wrote:
>>> Hi Frank,
>>>
>>> On 05 June 2018 18:34, Frank wrote:
>>>> On 06/05/18 04:28, Michel Pollet wrote:
>>>>> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time,
>>>>> it requires a special enable method to get it started.
>>>>>
>>>>> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>>>>> ---
>>>>> arch/arm/mach-shmobile/Makefile | 1 +
>>>>> arch/arm/mach-shmobile/smp-r9a06g032.c | 79
>>>>> ++++++++++++++++++++++++++++++++++
>>>>> 2 files changed, 80 insertions(+)
>>>>> create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
>>>>>
>>>>> diff --git a/arch/arm/mach-shmobile/Makefile
>>>>> b/arch/arm/mach-shmobile/Makefile index 1939f52..d7fc98f 100644
>>>>> --- a/arch/arm/mach-shmobile/Makefile
>>>>> +++ b/arch/arm/mach-shmobile/Makefile
>>>>> @@ -34,6 +34,7 @@ smp-$(CONFIG_ARCH_SH73A0)+= smp-sh73a0.o
>>>> headsmp-scu.o platsmp-scu.o
>>>>> smp-$(CONFIG_ARCH_R8A7779)+= smp-r8a7779.o headsmp-scu.o
>>>> platsmp-scu.o
>>>>> smp-$(CONFIG_ARCH_R8A7790)+= smp-r8a7790.o
>>>>> smp-$(CONFIG_ARCH_R8A7791)+= smp-r8a7791.o
>>>>> +smp-$(CONFIG_ARCH_R9A06G032)+= smp-r9a06g032.o
>>>>> smp-$(CONFIG_ARCH_EMEV2)+= smp-emev2.o headsmp-scu.o
>>>> platsmp-scu.o
>>>>>
>>>>> # PM objects
>>>>> diff --git a/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>>> b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>>> new file mode 100644
>>>>> index 0000000..cd40e6e
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>>> @@ -0,0 +1,79 @@
>>>>> +// SPDX-License-Identifier: GPL-2.0
>>>>> +/*
>>>>> + * R9A06G032 Second CA7 enabler.
>>>>> + *
>>>>> + * Copyright (C) 2018 Renesas Electronics Europe Limited
>>>>> + *
>>>>> + * Michel Pollet <michel.pollet@bp.renesas.com>,
>>>> <buserror@gmail.com>
>>>>> + * Derived from action,s500-smp
>>>>> + */
>>>>> +
>>>>> +#include <linux/io.h>
>>>>> +#include <linux/of.h>
>>>>> +#include <linux/of_address.h>
>>>>> +#include <linux/smp.h>
>>>>> +
>>>>> +/*
>>>>> + * The second CPU is parked in ROM at boot time. It requires waking
>>>>> +it after
>>>>> + * writing an address into the BOOTADDR register of sysctrl.
>>>>> + *
>>>>> + * So the default value of the "cpu-release-addr" corresponds to
>>>> BOOTADDR...
>>>>> + *
>>>>> + * *However* the BOOTADDR register is not available when the kernel
>>>>> + * starts in NONSEC mode.
>>>>> + *
>>>>> + * So for NONSEC mode, the bootloader re-parks the second CPU into a
>>>>> +pen
>>>>> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a
>>>>> +SRAM address,
>>>>> + * which is not restricted.
>>>>
>>>> The binding document for cpu-release-addr does not have a definition for 32
>>>> bit arm. The existing definition is only 64 bit arm. Please add the definition
>>>> for 32 bit arm to patch 1.
>>>
>>> Hmmm I do find a definition in
>>> Documentation/devicetree/bindings/arm/cpus.txt -- just under where I
>>> added my 'enable-method' -- And it is already used as 32 bits in at least
>>> arch/arm/boot/dts/stih407-family.dtsi.
>>
>> From cpus.txt:
>>
>> - cpu-release-addr
>> Usage: required for systems that have an "enable-method"
>> property value of "spin-table".
>> Value type: <prop-encoded-array>
>> Definition:
>> # On ARM v8 64-bit systems must be a two cell
>> property identifying a 64-bit zero-initialised
>> memory location.
>>
>> The definition specifies a two cell property for 64-bit systems.
>>
>> Please add to the definition that cpu-release-addr is a one cell property
>> for 32-bit systems.
>
> Actually, this is all already documented in the DT spec and it is
> always 2 cells[1]. We should perhaps just remove whatever is
> duplicated from the spec.
Thanks for noting that. I jumped to the (incorrect) conclusion that the
property should be one cell based on the code and the .dtsi.
There are about 4 more emails following this in the thread that discuss
what size cpu-release-addr should be. Whatever the end result is (one
cell or two or based on some #XXX-calls value), it needs to be documented
consistently in the binding and in the DT spec (or preferably only in the
DT spec), and if it is a two cell property for this system then
smp-r9a06g032.c and r9a06g032.dtsi need to be adjusted to reflect that.
-Frank
>
> Rob
>
> [1]
> ``cpu-release-addr`` | SD | ``<u64>`` The
> cpu-release-addr property is required for
> cpu nodes that have
> an enable-method property
> value of
> ``"spin-table"``. The value specifies the
> physical address of
> a spin table entry that
> releases a
> secondary CPU from its spin loop.
>
^ permalink raw reply
* USB role switches, usb-connector, typec and device trees
From: Mats Karrman @ 2018-06-06 21:36 UTC (permalink / raw)
To: Heikki Krogerus, Hans de Goede, Andrzej Hajda
Cc: Greg Kroah-Hartman, linux-usb, devicetree
Hello Gentlemen,
I'm trying to get my head around USB role switches in connection with Type-C ports
and device-trees. So far I have not found much documentation, e.g. there are no
device-tree bindings documented and really no good examples in existing device
trees, although there has been some attempts, e.g. [1] and [2]. Anyway, so I send
you a couple of questions instead:
1) tcpm uses the port device struct to find a single usb_role_switch but there is
room for three USB busses in the Type-C connector; one high speed and two (?) super-
speed. These would not all come from the same controller (there might even be
separate controllers for host and device mode for each bus).
The case I am working on now only have a single USB2 otg controller so it should
be possible to make that driver register a role switch but for other cases?
I imagine it would be possible to create a composite driver as a proxy for all role
switches but that would probably be different for every platform/product - not
very elegant. Could the role switch infrastructure be extended to handle arbitrary
sets of coordinated switches?
2) How should the connection between the Type-C port and the switches best be
expressed in a device tree? Using graph I presume, but should it be mixed into the
existing "usb-connector" or should this be a separate block?
I think it is unfortunate that the graph use numeric addresses that need to be
fixed by documentation and already I see problems with the current assignment
(0=HS, 1=SS, 2=SBU), e.g. if the host and device mode are handled by different
controllers. Graph do support multiple endpoints for one port but then we have
another level of magic numbers which does not exactly make things easier
(e.g. 0=dual or host controller, 1=device controller, 2=mode switch).
What are your thoughts on this? Please tell me I missed something and that there is
a simple solution :-)
BR // Mats
[1] https://www.spinics.net/lists/linux-usb/msg168071.html
[2] https://www.spinics.net/lists/linux-usb/msg168072.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox