Re: [PATCH v2 0/6] Add support for Actions Semi Owl socinfo
Hi, On 01.04.21 12:27, Manivannan Sadhasivam wrote: > On Thu, Apr 01, 2021 at 12:40:41PM +0300, Cristian Ciocaltea wrote: >> On Thu, Apr 01, 2021 at 10:54:38AM +0530, Manivannan Sadhasivam wrote: >>> On Tue, Mar 30, 2021 at 04:48:15PM +0300, Cristian Ciocaltea wrote: This patchset adds a socinfo driver which provides information about Actions Semi Owl SoCs to user space via sysfs: machine, family, soc_id, serial_number. Please note the serial number is currently available only for the S500 SoC variant. This has been tested on the S500 SoC based RoseapplePi SBC. >>> >>> Is this the soc_id provided by the vendor bootloader (uboot)? If so, under >>> what basis it provides? I don't think the SoC has the provision for >>> soc_id based on HW parameters. >> >> No, the soc_id is not provided by the bootloader, or at least I couldn't >> identify any related implementation. Instead, I provided this via the >> driver itself, since I've encountered this approach in some other soc >> drivers as well (e.g. imx/soc-imx.c, versatile/soc-integrator.c). >> > > Sorry, I was referring to serial_number. Since your comment says so, can > you point to the corresponding code? Seconded that this needs to be better understood. If this is just a convention of some downstream U-Boot that's not implemented in mainline (and maybe not even for Guitar or Labrador? tested on RoseapplePi only), it might not be worth its own reserved-memory based kernel driver? Implementing a standard interface such as DMI tables or a DT property in mainline U-Boot may be more useful then. Is it still Mani's S900 only? Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Re: [PATCH 1/1] ARM: owl: Add Actions Semi Owl S500 SoC machine
Hi Cristian, On 11.03.21 20:19, Cristian Ciocaltea wrote: > Add machine entry for the S500 variant of the Actions Semi Owl SoCs > family. > > For the moment the only purpose is to provide the system serial > information which will be used by the Owl Ethernet MAC driver to > generate a stable MAC address. Can't that be done in either a sys_soc driver or U-Boot? Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Re: [PATCH v2 18/18] MAINTAINERS: Add linux-actions ML for Actions Semi Arch
On 29.11.20 20:48, Cristian Ciocaltea wrote: > On Sat, Nov 28, 2020 at 01:13:50PM +0530, Manivannan Sadhasivam wrote: >> On Fri, Nov 20, 2020 at 01:56:12AM +0200, Cristian Ciocaltea wrote: >>> Add the linux-actions mailing list for the Actions Semi architecture. >>> >>> Signed-off-by: Cristian Ciocaltea >> >> There was a patch from me for this change but I don't mind taking yours >> as long as we keep the list updated :) > > Sorry about that, I often forget to manually append this mailing list > before submitting related patches and therefore I considered this is > a good opportunity to have this issue fixed once and for all.. :) > >> I have just one comment below, with that fixed: >> >> Reviewed-by: Manivannan Sadhasivam >> >>> --- >>> MAINTAINERS | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/MAINTAINERS b/MAINTAINERS >>> index a85c1881cf07..8428aba52581 100644 >>> --- a/MAINTAINERS >>> +++ b/MAINTAINERS >>> @@ -1497,6 +1497,7 @@ ARM/ACTIONS SEMI ARCHITECTURE >>> M: Andreas Färber >>> M: Manivannan Sadhasivam >>> L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) >> >> No need to keep the generic list, please remove. Why? They're not mutually exclusive. Regards, Andreas > > Done, thanks! > >> Thanks, >> Mani >> >>> +L: linux-acti...@lists.infradead.org (moderated for non-subscribers) >>> S: Maintained >>> F: Documentation/devicetree/bindings/arm/actions.yaml >>> F: Documentation/devicetree/bindings/clock/actions,owl-cmu.txt >>> -- >>> 2.29.2 >>> -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Re: [PATCH net-next] net: mvneta: Fix validation of 2.5G HSGMII without comphy
Hi Russell, On 15.11.20 02:02, Russell King - ARM Linux admin wrote: > On Sun, Nov 15, 2020 at 01:41:51AM +0100, Andreas Färber wrote: >> Commit 1a642ca7f38992b086101fe204a1ae3c90ed8016 (net: ethernet: mvneta: >> Add 2500BaseX support for SoCs without comphy) added support for 2500BaseX. >> >> In case a comphy is not provided, mvneta_validate()'s check >> state->interface == PHY_INTERFACE_MODE_2500BASEX >> could never be true (it would've returned with empty bitmask before), >> so that 2500baseT_Full and 2500baseX_Full do net get added to the mask. > > This makes me nervous. It was intentional that if there is no comphy > configured in DT for SoCs such as Armada 388, then there is no support > to switch between 1G and 2.5G speed. Unfortunately, the configuration > of the comphy is up to the board to do, not the SoC .dtsi, so we can't > rely on there being a comphy on Armada 388 systems. Please note that the if clause at the beginning of the validate function does not check for comphy at all. So even with comphy, if there is a code path that attempts to validate state 2500BASEX, it is broken, too. Do you consider the modification of both ifs (validate and power_up) as correct? Should they be split off from my main _NA change you discuss? > So, one of the side effects of this patch is it incorrectly opens up > the possibility of allowing 2.5G support on Armada 388 without a comphy > configured. > > We really need a better way to solve this; just relying on the lack of > comphy and poking at a register that has no effect on Armada 388 to > select 2.5G speed while allowing 1G and 2.5G to be arbitarily chosen > doesn't sound like a good idea to me. [snip] May I add that the comphy needs better documentation? Marek and I independently came up with < 2> in the end, but the DT binding doesn't explain what the index is supposed to be and how I might figure it out. It cost me days of reading U-Boot and kernel sources and playing around with values until I had the working one. Might be helpful to have a symbolic dt-bindings #define for this 2. U-Boot v2020.10 on Turris Omnia dumps this table: | Lane # | Speed | Type | | 0| 6 | SATA0 | | 1| 5 | USB3 HOST0 | | 2| 5 | PCIe1 | | 3| 5 | USB3 HOST1 | | 4| 5 | PCIe2 | | 5| 0 | SGMII2 | But IIUC the Linux comphy driver doesn't take any type ID as argument but rather an index into a table of "ports" which specifies another index to apply or look up? Terribly indirect and magic to non-experts. As a DT contributor I would need the binding to tell me that it's an enum with 2 meaning SGMII2. Not even the max of 2 is documented. The Linux driver talks of ports, but I don't see that term used in U-Boot, and U-Boot APIs appeared to pass very different args in the board code. The binding also still needs to be converted to YAML before we can extend it with any better explanations. (And before you suggest it: Since I obviously don't fully understand that hardware, I'm the wrong person to attempt documenting it. The 38x comphy seems not mentioned in MAINTAINERS, only the 3700 one.) Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
[PATCH net-next] net: mvneta: Fix validation of 2.5G HSGMII without comphy
Commit 1a642ca7f38992b086101fe204a1ae3c90ed8016 (net: ethernet: mvneta:
Add 2500BaseX support for SoCs without comphy) added support for 2500BaseX.
In case a comphy is not provided, mvneta_validate()'s check
state->interface == PHY_INTERFACE_MODE_2500BASEX
could never be true (it would've returned with empty bitmask before),
so that 2500baseT_Full and 2500baseX_Full do net get added to the mask.
This causes phylink_sfp_config() to fail validation of 2.5G SFP support.
Address this by adding 2500baseX_Full and 2500baseT_Full to the mask for
state->interface == PHY_INTERFACE_MODE_NA
as well.
Also handle PHY_INTERFACE_MODE_2500BASEX in two checks for allowed modes
and update a comment.
Tested with 2.5G and 1G SFPs on Turris Omnia before assigning comphy.
Fixes: 1a642ca7f389 ("net: ethernet: mvneta: Add 2500BaseX support for SoCs
without comphy")
Cc: Sascha Hauer
Cc: David S. Miller
Cc: Marek Behún
Cc: Andrew Lunn
Cc: Uwe Kleine-König
Cc: Jason Cooper
Cc: Gregory CLEMENT
Signed-off-by: Andreas Färber
---
drivers/net/ethernet/marvell/mvneta.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c
b/drivers/net/ethernet/marvell/mvneta.c
index 54b0bf574c05..c5016036de3a 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3812,10 +3812,11 @@ static void mvneta_validate(struct phylink_config
*config,
struct mvneta_port *pp = netdev_priv(ndev);
__ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
- /* We only support QSGMII, SGMII, 802.3z and RGMII modes */
+ /* We only support QSGMII, SGMII, HSGMII, 802.3z and RGMII modes */
if (state->interface != PHY_INTERFACE_MODE_NA &&
state->interface != PHY_INTERFACE_MODE_QSGMII &&
state->interface != PHY_INTERFACE_MODE_SGMII &&
+ state->interface != PHY_INTERFACE_MODE_2500BASEX &&
!phy_interface_mode_is_8023z(state->interface) &&
!phy_interface_mode_is_rgmii(state->interface)) {
bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
@@ -3834,7 +3835,8 @@ static void mvneta_validate(struct phylink_config *config,
phylink_set(mask, 1000baseT_Full);
phylink_set(mask, 1000baseX_Full);
}
- if (pp->comphy || state->interface == PHY_INTERFACE_MODE_2500BASEX) {
+ if (pp->comphy || state->interface == PHY_INTERFACE_MODE_2500BASEX
+ || state->interface == PHY_INTERFACE_MODE_NA) {
phylink_set(mask, 2500baseT_Full);
phylink_set(mask, 2500baseX_Full);
}
@@ -5038,6 +5040,7 @@ static int mvneta_port_power_up(struct mvneta_port *pp,
int phy_mode)
if (phy_mode != PHY_INTERFACE_MODE_QSGMII &&
phy_mode != PHY_INTERFACE_MODE_SGMII &&
+ phy_mode != PHY_INTERFACE_MODE_2500BASEX &&
!phy_interface_mode_is_8023z(phy_mode) &&
!phy_interface_mode_is_rgmii(phy_mode))
return -EINVAL;
--
2.28.0
[PATCH 1/2] rtw88: Fix probe error handling race with firmware loading
In case of rtw8822be, a probe failure after successful rtw_core_init()
has been observed to occasionally lead to an oops from rtw_load_firmware_cb():
[3.924268] pci 0001:01:00.0: [10ec:b822] type 00 class 0xff
[3.930531] pci 0001:01:00.0: reg 0x10: [io 0x-0x00ff]
[3.936360] pci 0001:01:00.0: reg 0x18: [mem 0x-0x 64bit]
[3.944042] pci 0001:01:00.0: supports D1 D2
[3.948438] pci 0001:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[3.957312] pci 0001:01:00.0: BAR 2: no space for [mem size 0x0001 64bit]
[3.964645] pci 0001:01:00.0: BAR 2: failed to assign [mem size 0x0001
64bit]
[3.972332] pci 0001:01:00.0: BAR 0: assigned [io 0x1-0x100ff]
[3.986240] rtw_8822be 0001:01:00.0: enabling device ( -> 0001)
[3.992735] rtw_8822be 0001:01:00.0: failed to map pci memory
[3.998638] rtw_8822be 0001:01:00.0: failed to request pci io region
[4.005166] rtw_8822be 0001:01:00.0: failed to setup pci resources
[4.011580] rtw_8822be: probe of 0001:01:00.0 failed with error -12
[4.018827] cfg80211: Loading compiled-in X.509 certificates for regulatory
database
[4.029121] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[4.050828] Unable to handle kernel paging request at virtual address
edafeaac9607952c
[4.058975] Mem abort info:
[4.058980] ESR = 0x9604
[4.058990] EC = 0x25: DABT (current EL), IL = 32 bits
[4.070353] SET = 0, FnV = 0
[4.073487] EA = 0, S1PTW = 0
[4.073501] dw-apb-uart 98007800.serial: forbid DMA for kernel console
[4.076723] Data abort info:
[4.086415] ISV = 0, ISS = 0x0004
[4.087731] Freeing unused kernel memory: 1792K
[4.090391] CM = 0, WnR = 0
[4.098091] [edafeaac9607952c] address between user and kernel address ranges
[4.105418] Internal error: Oops: 9604 [#1] PREEMPT SMP
[4.29] Modules linked in:
[4.114275] CPU: 1 PID: 31 Comm: kworker/1:1 Not tainted
5.9.0-rc5-next-20200915+ #700
[4.122386] Hardware name: Realtek Saola EVB (DT)
[4.127223] Workqueue: events request_firmware_work_func
[4.132676] pstate: 6005 (nZCv daif -PAN -UAO BTYPE=--)
[4.138393] pc : rtw_load_firmware_cb+0x54/0xbc
[4.143040] lr : request_firmware_work_func+0x44/0xb4
[4.148217] sp : 800010133d70
[4.151616] x29: 800010133d70 x28:
[4.157069] x27: x26:
[4.162520] x25: x24:
[4.167971] x23: 7ac21908 x22: 7ebb2100
[4.173424] x21: 7ad35880 x20: edafeaac96079504
[4.178877] x19: 7ad35870 x18:
[4.184328] x17: 44d8 x16: 4310
[4.189780] x15: 0800 x14: ef006305
[4.195231] x13: x12:
[4.200682] x11: 0020 x10: 0003
[4.206135] x9 : x8 : 7e73f680
[4.211585] x7 : x6 : 80001119b588
[4.217036] x5 : 7e649c80 x4 : 7e649c80
[4.222487] x3 : 80001119b588 x2 : 8000108d1718
[4.227940] x1 : 800011bd5000 x0 : 7ac21600
[4.233391] Call trace:
[4.235906] rtw_load_firmware_cb+0x54/0xbc
[4.240198] request_firmware_work_func+0x44/0xb4
[4.245027] process_one_work+0x178/0x1e4
[4.249142] worker_thread+0x1d0/0x268
[4.252989] kthread+0xe8/0xf8
[4.256127] ret_from_fork+0x10/0x18
[4.259800] Code: f94013f5 a8c37bfd d65f03c0 f9000260 (f9401681)
[4.266049] ---[ end trace f822ebae1a8545c2 ]---
To avoid this, wait on the completion callbacks in rtw_core_deinit()
before releasing firmware and continuing teardown.
Note that rtw_wait_firmware_completion() was introduced with
c8e5695eae9959fc5774c0f490f2450be8bad3de ("rtw88: load wowlan firmware
if wowlan is supported"), so backports to earlier branches may need to
inline wait_for_completion(>fw.completion) instead.
Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
Fixes: c8e5695eae99 ("rtw88: load wowlan firmware if wowlan is supported")
Cc: Yan-Hsuan Chuang
Signed-off-by: Andreas Färber
---
drivers/net/wireless/realtek/rtw88/main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw88/main.c
b/drivers/net/wireless/realtek/rtw88/main.c
index 9770982b2f14..dc48ec4b0a31 100644
--- a/drivers/net/wireless/realtek/rtw88/main.c
+++ b/drivers/net/wireless/realtek/rtw88/main.c
@@ -1486,6 +1486,8 @@ void rtw_core_deinit(struct rtw_dev *rtwdev)
struct rtw_rsvd_page *rsvd_pkt, *tmp;
unsigned long flags;
+ rtw_wait_firmware_completion(rtwdev);
+
if (fw->firmware)
release_firmware(fw->firmware);
--
2.28.0
[PATCH 2/2] rtw88: Fix potential probe error handling race with wow firmware loading
If rtw_core_init() fails to load the wow firmware, rtw_core_deinit()
will not get called to clean up the regular firmware.
Ensure that an error loading the wow firmware does not produce an oops
for the regular firmware by waiting on its completion to be signalled
before returning. Also release the loaded firmware.
Fixes: c8e5695eae99 ("rtw88: load wowlan firmware if wowlan is supported")
Cc: Chin-Yen Lee
Cc: Yan-Hsuan Chuang
Signed-off-by: Andreas Färber
---
drivers/net/wireless/realtek/rtw88/main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw88/main.c
b/drivers/net/wireless/realtek/rtw88/main.c
index dc48ec4b0a31..cc82c80f0433 100644
--- a/drivers/net/wireless/realtek/rtw88/main.c
+++ b/drivers/net/wireless/realtek/rtw88/main.c
@@ -1472,6 +1472,9 @@ int rtw_core_init(struct rtw_dev *rtwdev)
ret = rtw_load_firmware(rtwdev, RTW_WOWLAN_FW);
if (ret) {
rtw_warn(rtwdev, "no wow firmware loaded\n");
+ wait_for_completion(>fw.completion);
+ if (rtwdev->fw.firmware)
+ release_firmware(rtwdev->fw.firmware);
return ret;
}
}
--
2.28.0
[PATCH 0/2] net: wireless: rtw88: Fix oops on probe errors
Hello, This mini-series fixes oopses in rtw88 device probe error handling, resulting from asynchronous firmware loading. Since there does not appear to be a public kernel API for canceling scheduled or ongoing firmware loads, it seems we need to wait with teardown until rtw88's callback was invoked and signals completion. Found on RTD1296 arm64 SoC with experimental PCI host bridge driver (https://github.com/afaerber/linux/commits/rtd1295-next) with a 4K physical bar window, resulting in rtw_pci_setup_resource() failing, or with non-implemented 4K remapping resulting in rtw_pci_read32() returning 0x values and causing rtw_mac_power_on() to fail. Cheers, Andreas Andreas Färber (2): rtw88: Fix probe error handling race with firmware loading rtw88: Fix potential probe error handling race with wow firmware loading drivers/net/wireless/realtek/rtw88/main.c | 5 + 1 file changed, 5 insertions(+) -- 2.28.0
Re: [PATCH v3 5/9] dt-bindings: pinctrl: realtek: Add Realtek DHC SoC rtd1295
Am 17.08.20 um 22:33 schrieb Rob Herring: > On Thu, 13 Aug 2020 15:49:04 +0800, TY Chang wrote: >> Add device tree binding Documentation for rtd1295 >> pinctrl driver. >> >> Signed-off-by: TY Chang >> --- >> .../pinctrl/realtek,rtd1295-pinctrl.yaml | 192 ++ >> 1 file changed, 192 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/pinctrl/realtek,rtd1295-pinctrl.yaml >> > > > Please add Acked-by/Reviewed-by tags when posting new versions. However, > there's no need to repost patches *only* to add the tags. The upstream > maintainer will do that for acks received on the version they apply. > > If a tag was not added on purpose, please state why and what changed. The thing really missing here is a per-patch change log. Things were added here that I'm sure you would not give your Reviewed-by for, in particular new properties prefixed with unregistered rtk prefix instead of the registered realtek prefix. @TY, hiding such changes in a big previously reviewed patch without any mention is problematic - please rather do smaller follow-up patches to not invalidate previous reviews with new features. Thanks, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Re: [PATCH v1] arm64: dts: actions: Fix smp Bringing up secondary CPUs
Hi Matheus, Am 05.07.20 um 21:19 schrieb Matheus Castello: Change the enable-method to fix the failed to boot errors: [0.040330] smp: Bringing up secondary CPUs ... [0.040683] psci: failed to boot CPU1 (-22) [0.040691] CPU1: failed to boot: -22 [0.041062] psci: failed to boot CPU2 (-22) [0.041071] CPU2: failed to boot: -22 [0.041408] psci: failed to boot CPU3 (-22) [0.041417] CPU3: failed to boot: -22 [0.041443] smp: Brought up 1 node, 1 CPU [0.041451] SMP: Total of 1 processors activated. Tested on Caninos Labrador v3 based on Actions Semi S700. Signed-off-by: Matheus Castello --- arch/arm64/boot/dts/actions/s700.dtsi | 33 +++ 1 file changed, 23 insertions(+), 10 deletions(-) NACK. For starters, if this were an actual fix, it should have a Fixes header. Don't do random changes in a single patch and call it a "fix". I don't see what changing the cell size has to do with smp, nor adding L2 cache. The latter could be a patch of its own, after fixes are applied (to avoid conflicts when backporting that fix to older branches). A cell size of two used to be perfectly valid, please checking the DT binding. Finally, you're changing generic S700 code here - you can't just break Cubieboard7 just because your Labrador has too old BL31 firmware. Can't you just update its TF-A firmware and use the standard PSCI interface for Linux? If not, then you should add your workaround to your module's/board's .dts(i) instead of the SoC's .dtsi. Thanks, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Re: [PATCH v2 18/29] nvmem: Add Realtek DHC eFuse driver
Hi Srini, Am 23.06.20 um 11:32 schrieb Srinivas Kandagatla: On 23/06/2020 03:50, Andreas Färber wrote: Implement enough of a read-only nvmem driver to easily read efuse cells. Cc: Cheng-Yu Lee Signed-off-by: Andreas Färber --- This patch itself looks okay to me, I will apply this once DT patches are Reviewed/applied by DT maintainers! Thanks - let's give the Realtek engineers some time to review, too: * Driver naming - new [rtk-]dhc (Stanley) vs. in-tree rtd1195 elsewhere. * My other driver was previously reading u32-sized registers directly, whereas here I switched to byte-sized reads based on other in-tree nvmem drivers. Downstream driver seems inconsistent wrt .word_size: https://github.com/BPI-SINOVOIP/BPI-M4-bsp/blob/master/linux-rtk/drivers/nvmem/rtk-efuse.c#L191 * RTD1619 (RTD1319, too?) may need special handling and therefore its own DT compatible: There's a magic OTP_CTRL register write downstream that I am lacking documentation w/ names and use case for. https://github.com/BPI-SINOVOIP/BPI-M4-bsp/blob/master/linux-rtk/drivers/nvmem/rtk-efuse.c#L216 That might obviously affect the binding, too, requiring oneOf - could be changed in a later step though. I would take the .dts patches through my linux-realtek.git once the binding is approved. * The downstream DTs have nvmem-cells and nvmem-cell-names properties in the efuse node directly, which I regarded as unnecessary from reading the consumer binding, placing those properties into the consuming node. * Downstream DTs have more eFuse fields declared than the one I use in this series [1]; they are also inconsistent in prefixing them efuse_ vs. otp_; in the RTD1295 datasheet the block is called eFuse, so I used efuse_ for consistency. I have enforced the dashes convention for nodes, as I didn't see the node name get used anywhere. [1] https://patchwork.kernel.org/patch/11619643/ One more comment inline... v2: New MAINTAINERS | 1 + drivers/nvmem/Kconfig | 9 drivers/nvmem/Makefile | 2 + drivers/nvmem/rtk-dhc-efuse.c | 86 +++ 4 files changed, 98 insertions(+) create mode 100644 drivers/nvmem/rtk-dhc-efuse.c diff --git a/MAINTAINERS b/MAINTAINERS index 1d0d6ab20451..02117fbf0e57 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2312,6 +2312,7 @@ F: Documentation/devicetree/bindings/soc/realtek/ F: arch/arm/boot/dts/rtd* F: arch/arm/mach-realtek/ F: arch/arm64/boot/dts/realtek/ +F: drivers/nvmem/rtk-dhc-efuse.c F: drivers/soc/realtek/ ARM/RENESAS ARM64 ARCHITECTURE [snip] This line addition will conflict with the next line, added earlier in this patchset. Same for the binding patch. Do you need a v3 reordering them? This driver seems easier to target for 5.9 than the rest of the series. If you do not intend to take the dt-bindings patch (17/29) through your tree, I can queue it once ack'ed by Rob and you. Thanks for the quick review, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
[PATCH v2 10/29] arm64: dts: realtek: rtd139x: Add chip info node
Add a DT node for chip identification.
Signed-off-by: Andreas Färber
---
v2: New
arch/arm64/boot/dts/realtek/rtd139x.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/realtek/rtd139x.dtsi
b/arch/arm64/boot/dts/realtek/rtd139x.dtsi
index 586b05350274..3d4d2323294b 100644
--- a/arch/arm64/boot/dts/realtek/rtd139x.dtsi
+++ b/arch/arm64/boot/dts/realtek/rtd139x.dtsi
@@ -199,6 +199,11 @@ sb2_hd_sem: hwspinlock@0 {
#hwlock-cells = <0>;
};
+ chip-info@200 {
+ compatible = "realtek,rtd1195-chip";
+ reg = <0x200 0x8>;
+ };
+
sb2_hd_sem_new: hwspinlock@620 {
compatible = "realtek,rtd1195-sb2-sem";
reg = <0x620 0x20>;
--
2.26.2
[PATCH v2 12/29] arm64: dts: realtek: rtd16xx: Add chip info node
Add a DT node for chip identification.
Signed-off-by: Andreas Färber
---
v2: New
arch/arm64/boot/dts/realtek/rtd16xx.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/realtek/rtd16xx.dtsi
b/arch/arm64/boot/dts/realtek/rtd16xx.dtsi
index afba5f04c8ec..04cb546142a0 100644
--- a/arch/arm64/boot/dts/realtek/rtd16xx.dtsi
+++ b/arch/arm64/boot/dts/realtek/rtd16xx.dtsi
@@ -227,3 +227,10 @@ uart2: serial2@400 {
status = "disabled";
};
};
+
+ {
+ chip-info@200 {
+ compatible = "realtek,rtd1195-chip";
+ reg = <0x200 0x8>;
+ };
+};
--
2.26.2
[PATCH v2 00/29] ARM: Realtek DHC SoC info
Hello, This series adds a soc bus driver for Realtek Digital Home Center SoC families. v2 is rebased on syscon and RTD1319, adjusts field widths and incorporates data additions from Stanley's monolithic patch. The previous RFC's reg hack is superseded in v2 with a trivial read-only eFuse driver, along with an extension of the nvmem consumer API. Reminder: For RTD1293 I had to invent my own detection logic, possibly flawed. Nor have the names of the magic register bits been disclosed. We have no RTD1294 nor RTD1392 DT in mainline, so their detection is included mainly as proof of concept. No EVB names were visible in public BSP sources; Ligomedia seems the only vendor so far with publicly announced RTD1392 STBs, for RTD1294 I only find one all-Chinese page and some Russian forum posts - patches and testing welcome. Otherwise we can only test that the other models are not misdetected as RTD1392 or RTD1294. DHC upstreaming progress is being tracked at: https://en.opensuse.org/HCL:Realtek_DHC Latest experimental patches at: https://github.com/afaerber/linux/commits/rtd1295-next Have a lot of fun! Cheers, Andreas v1 -> v2: * Cleaned up binding schema (Rob) * Rebased onto syscon mfd refactoring of containing SB2, Iso, etc. * Limit chip id and rev to 16 bits, as per old header files * Include mentioned RTD1395, RTD1619 and RTD1319 patches * Incorporate RTD1392 and RTD1319 bits from Stanley's API export patch * Add eFuse nvmem driver and adopt and extend nvmem cell API Cc: devicet...@vger.kernel.org Cc: Rob Herring Cc: Srinivas Kandagatla Cc: James Tai Cc: Stanley Chang [昌育德] Cc: Edgar Lee Cc: h...@ligomedia.com Andreas Färber (27): dt-bindings: soc: Add Realtek RTD1195 chip info binding soc: Add Realtek DHC chip info driver for RTD1195 and RTD1295 arm64: dts: realtek: rtd129x: Add chip info node ARM: dts: rtd1195: Add chip info node dt-bindings: soc: realtek: rtd1195-chip: Add iso-syscon property soc: realtek: chip: Detect RTD1296 arm64: dts: realtek: rtd129x: Extend chip-info reg with CHIP_INFO1 soc: realtek: chip: Detect RTD1293 soc: realtek: chip: Add RTD1395 info arm64: dts: realtek: rtd139x: Add chip info node soc: realtek: chip: Add RTD1619 info arm64: dts: realtek: rtd16xx: Add chip info node soc: realtek: chip: Add RTD1319 info arm64: dts: realtek: rtd13xx: Add chip info node dt-bindings: nvmem: Add Realtek RTD1195 eFuse nvmem: Add Realtek DHC eFuse driver ARM: dts: rtd1195: Add eFuse node arm64: dts: realtek: rtd129x: Add eFuse node arm64: dts: realtek: rtd139x: Add eFuse node arm64: dts: realtek: rtd16xx: Add eFuse node arm64: dts: realtek: rtd13xx: Add eFuse node dt-bindings: soc: realtek: rtd1195-chip: Allow nvmem-cells property arm64: dts: realtek: rtd129x: Add eFuse package_id to chip-info soc: realtek: chip: Detect RTD1294 nvmem: core: Grammar fixes for help text nvmem: core: Add nvmem_cell_read_u8() soc: realtek: chip: Adopt nvmem_cell_read_u8() helper Stanley Chang (2): soc: realtek: chip: Add RTD1319 revisions soc: realtek: chip: Detect RTD1392 .../bindings/nvmem/realtek,rtd1195-efuse.yaml | 53 .../soc/realtek/realtek,rtd1195-chip.yaml | 55 MAINTAINERS | 4 + arch/arm/boot/dts/rtd1195.dtsi| 13 + arch/arm64/boot/dts/realtek/rtd129x.dtsi | 23 ++ arch/arm64/boot/dts/realtek/rtd139x.dtsi | 15 +- arch/arm64/boot/dts/realtek/rtd13xx.dtsi | 15 + arch/arm64/boot/dts/realtek/rtd16xx.dtsi | 15 + drivers/nvmem/Kconfig | 9 + drivers/nvmem/Makefile| 2 + drivers/nvmem/core.c | 27 +- drivers/nvmem/rtk-dhc-efuse.c | 86 ++ drivers/soc/Kconfig | 1 + drivers/soc/Makefile | 1 + drivers/soc/realtek/Kconfig | 13 + drivers/soc/realtek/Makefile | 2 + drivers/soc/realtek/chip.c| 269 ++ include/linux/nvmem-consumer.h| 1 + 18 files changed, 597 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/nvmem/realtek,rtd1195-efuse.yaml create mode 100644 Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml create mode 100644 drivers/nvmem/rtk-dhc-efuse.c create mode 100644 drivers/soc/realtek/Kconfig create mode 100644 drivers/soc/realtek/Makefile create mode 100644 drivers/soc/realtek/chip.c -- 2.26.2
[PATCH v2 06/29] soc: realtek: chip: Detect RTD1296
Detection logic from downstream drivers/soc/realtek/rtd129x/rtk_chip.c.
Acked-by: James Tai
Signed-off-by: Andreas Färber
---
TODO: Name the bit in ISO_CHIP_INFO1:bound_opts.
v1 -> v2:
* Instead of direct iso register access use the new syscon regmap
drivers/soc/realtek/chip.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c
index c4650d512c91..103f564aad7f 100644
--- a/drivers/soc/realtek/chip.c
+++ b/drivers/soc/realtek/chip.c
@@ -23,6 +23,8 @@
#define SB2_CHIP_INFO_REVISE_IDGENMASK(31, 16)
+#define REG_ISO_CHIP_INFO1 0x028
+
struct dhc_soc_revision {
const char *name;
u16 chip_rev;
@@ -57,9 +59,32 @@ static const char *default_name(struct device *dev, const
struct dhc_soc *s)
return s->family;
}
+static const char *rtd1295_name(struct device *dev, const struct dhc_soc *s)
+{
+ struct regmap *regmap;
+ unsigned int val;
+ int ret;
+
+ regmap = syscon_regmap_lookup_by_phandle(dev->of_node, "iso-syscon");
+ if (IS_ERR(regmap)) {
+ ret = PTR_ERR(regmap);
+ if (ret == -EPROBE_DEFER)
+ return ERR_PTR(ret);
+ dev_warn(dev, "Could not check iso (%d)\n", ret);
+ } else {
+ ret = regmap_read(regmap, REG_ISO_CHIP_INFO1, );
+ if (ret)
+ dev_warn(dev, "Could not read chip_info1 (%d)\n", ret);
+ else if (val & BIT(11))
+ return "RTD1296";
+ }
+
+ return "RTD1295";
+}
+
static const struct dhc_soc dhc_soc_families[] = {
{ 0x6329, "RTD1195", default_name, rtd1195_revisions, "Phoenix" },
- { 0x6421, "RTD1295", default_name, rtd1295_revisions, "Kylin" },
+ { 0x6421, "RTD1295", rtd1295_name, rtd1295_revisions, "Kylin" },
};
static const struct dhc_soc *dhc_soc_by_chip_id(u16 chip_id)
--
2.26.2
[PATCH v2 14/29] soc: realtek: chip: Add RTD1319 revisions
From: Stanley Chang
Identify RTD1319 SoC revisions B00 to B02.
Signed-off-by: Stanley Chang
Signed-off-by: Andreas Färber
---
v2: New
* Split out from Stanley's v1
drivers/soc/realtek/chip.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c
index ae7c5322f338..6b3d1f3d3816 100644
--- a/drivers/soc/realtek/chip.c
+++ b/drivers/soc/realtek/chip.c
@@ -3,6 +3,7 @@
* Realtek Digital Home Center System-on-Chip info
*
* Copyright (c) 2017-2020 Andreas Färber
+ * Copyright (c) 2019 Realtek Semiconductor Corp.
*/
#include
@@ -61,6 +62,9 @@ static const struct dhc_soc_revision rtd1619_revisions[] = {
static const struct dhc_soc_revision rtd1319_revisions[] = {
{ "A00", 0x },
+ { "B00", 0x0001 },
+ { "B01", 0x0002 },
+ { "B02", 0x0003 },
{ }
};
--
2.26.2
[PATCH v2 13/29] soc: realtek: chip: Add RTD1319 info
Revision based on downstream drivers/soc/realtek/rtd13xx/rtk_chip.c.
Signed-off-by: Stanley Chang
Signed-off-by: Andreas Färber
---
v2: New
* Filled in chip ID based on Stanley's v1
drivers/soc/realtek/chip.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c
index e3220187e336..ae7c5322f338 100644
--- a/drivers/soc/realtek/chip.c
+++ b/drivers/soc/realtek/chip.c
@@ -59,6 +59,11 @@ static const struct dhc_soc_revision rtd1619_revisions[] = {
{ }
};
+static const struct dhc_soc_revision rtd1319_revisions[] = {
+ { "A00", 0x },
+ { }
+};
+
struct dhc_soc {
u16 chip_id;
const char *family;
@@ -103,6 +108,7 @@ static const struct dhc_soc dhc_soc_families[] = {
{ 0x6421, "RTD1295", rtd1295_name, rtd1295_revisions, "Kylin" },
{ 0x6481, "RTD1395", default_name, rtd1395_revisions, "Hercules" },
{ 0x6525, "RTD1619", default_name, rtd1619_revisions, "Thor" },
+ { 0x6570, "RTD1319", default_name, rtd1319_revisions, "Hank" },
};
static const struct dhc_soc *dhc_soc_by_chip_id(u16 chip_id)
--
2.26.2
[PATCH v2 02/29] soc: Add Realtek DHC chip info driver for RTD1195 and RTD1295
Add a soc bus driver to print chip model and revision details.
Revisions from downstream drivers/soc/realtek/rtd{119x,129x}/rtk_chip.c.
Signed-off-by: Andreas Färber
---
v1 -> v2:
* Added entry to MAINTAINERS
* Changed chip_id and chip_rev from u32 to u16, based on reg field definitions
* Added error return path for get_name for deferred probing, reordered code
MAINTAINERS | 1 +
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/realtek/Kconfig | 13 +++
drivers/soc/realtek/Makefile | 2 +
drivers/soc/realtek/chip.c | 181 +++
6 files changed, 199 insertions(+)
create mode 100644 drivers/soc/realtek/Kconfig
create mode 100644 drivers/soc/realtek/Makefile
create mode 100644 drivers/soc/realtek/chip.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 78adbc3cc101..ff0ee48fee6f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2311,6 +2311,7 @@ F:Documentation/devicetree/bindings/soc/realtek/
F: arch/arm/boot/dts/rtd*
F: arch/arm/mach-realtek/
F: arch/arm64/boot/dts/realtek/
+F: drivers/soc/realtek/
ARM/RENESAS ARM64 ARCHITECTURE
M: Geert Uytterhoeven
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 425ab6f7e375..925647993119 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -11,6 +11,7 @@ source "drivers/soc/imx/Kconfig"
source "drivers/soc/ixp4xx/Kconfig"
source "drivers/soc/mediatek/Kconfig"
source "drivers/soc/qcom/Kconfig"
+source "drivers/soc/realtek/Kconfig"
source "drivers/soc/renesas/Kconfig"
source "drivers/soc/rockchip/Kconfig"
source "drivers/soc/samsung/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 36452bed86ef..cdcf00bbad10 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_SOC_XWAY)+= lantiq/
obj-y += mediatek/
obj-y += amlogic/
obj-y += qcom/
+obj-y += realtek/
obj-y += renesas/
obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
obj-$(CONFIG_SOC_SAMSUNG) += samsung/
diff --git a/drivers/soc/realtek/Kconfig b/drivers/soc/realtek/Kconfig
new file mode 100644
index ..be75c1889c61
--- /dev/null
+++ b/drivers/soc/realtek/Kconfig
@@ -0,0 +1,13 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+if ARCH_REALTEK || COMPILE_TEST
+
+config REALTEK_SOC
+ tristate "Realtek chip info"
+ default ARCH_REALTEK
+ select SOC_BUS
+ help
+ Say 'y' here to enable support for SoC info on Realtek RTD1195 and
+ RTD1295 SoC families.
+ If unsure, say 'n'.
+
+endif
diff --git a/drivers/soc/realtek/Makefile b/drivers/soc/realtek/Makefile
new file mode 100644
index ..49900273905b
--- /dev/null
+++ b/drivers/soc/realtek/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+obj-$(CONFIG_REALTEK_SOC) += chip.o
diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c
new file mode 100644
index ..c4650d512c91
--- /dev/null
+++ b/drivers/soc/realtek/chip.c
@@ -0,0 +1,181 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Realtek Digital Home Center System-on-Chip info
+ *
+ * Copyright (c) 2017-2020 Andreas Färber
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define REG_SB2_CHIP_ID0x200
+#define REG_SB2_CHIP_INFO 0x204
+
+#define SB2_CHIP_ID_CHIP_IDGENMASK(15, 0)
+
+#define SB2_CHIP_INFO_REVISE_IDGENMASK(31, 16)
+
+struct dhc_soc_revision {
+ const char *name;
+ u16 chip_rev;
+};
+
+static const struct dhc_soc_revision rtd1195_revisions[] = {
+ { "A", 0x },
+ { "B", 0x0001 },
+ { "C", 0x0002 },
+ { "D", 0x0003 },
+ { }
+};
+
+static const struct dhc_soc_revision rtd1295_revisions[] = {
+ { "A00", 0x },
+ { "A01", 0x0001 },
+ { "B00", 0x0002 },
+ { "B01", 0x0003 },
+ { }
+};
+
+struct dhc_soc {
+ u16 chip_id;
+ const char *family;
+ const char *(*get_name)(struct device *dev, const struct dhc_soc *s);
+ const struct dhc_soc_revision *revisions;
+ const char *codename;
+};
+
+static const char *default_name(struct device *dev, const struct dhc_soc *s)
+{
+ return s->family;
+}
+
+static const struct dhc_soc dhc_soc_families[] = {
+ { 0x6329, "RTD1195", default_name, rtd1195_revisions, "Phoenix" },
+ { 0x6421, "RTD1295", default_name, rtd1295_revisions, "Kylin" },
+};
+
+static const struct dhc_soc *dhc_soc_by_chip_id(u16 chip_id)
+{
+ int i;
+
+ for (i = 0; i < A
[PATCH v2 07/29] arm64: dts: realtek: rtd129x: Extend chip-info reg with CHIP_INFO1
This additional register is needed to distinguish RTD1296 from RTD1295.
Signed-off-by: Andreas Färber
---
v1 -> v2:
* Switched from reg to new iso-syscon phandle
arch/arm64/boot/dts/realtek/rtd129x.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi
b/arch/arm64/boot/dts/realtek/rtd129x.dtsi
index b5be9df80dae..30a7782aa0d9 100644
--- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi
+++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi
@@ -204,6 +204,7 @@ sb2_hd_sem: hwspinlock@0 {
chip-info@200 {
compatible = "realtek,rtd1195-chip";
reg = <0x200 0x8>;
+ iso-syscon = <>;
};
sb2_hd_sem_new: hwspinlock@620 {
--
2.26.2
[PATCH v2 08/29] soc: realtek: chip: Detect RTD1293
Logic self-determined by comparing DS418j and DS418 registers.
Signed-off-by: Andreas Färber
---
TODO: Identify the bit in ISO_CHIP_INFO1:bound_opts and what it really means.
v1 -> v2:
* Rebased onto iso syscon regmap
drivers/soc/realtek/chip.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c
index 103f564aad7f..32ed0e4a3646 100644
--- a/drivers/soc/realtek/chip.c
+++ b/drivers/soc/realtek/chip.c
@@ -75,8 +75,11 @@ static const char *rtd1295_name(struct device *dev, const
struct dhc_soc *s)
ret = regmap_read(regmap, REG_ISO_CHIP_INFO1, );
if (ret)
dev_warn(dev, "Could not read chip_info1 (%d)\n", ret);
- else if (val & BIT(11))
+ else if (val & BIT(11)) {
+ if (val & BIT(4))
+ return "RTD1293";
return "RTD1296";
+ }
}
return "RTD1295";
--
2.26.2
[PATCH v2 21/29] arm64: dts: realtek: rtd139x: Add eFuse node
Add a DT node for eFuse.
Signed-off-by: Andreas Färber
---
v2: New
arch/arm64/boot/dts/realtek/rtd139x.dtsi | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/realtek/rtd139x.dtsi
b/arch/arm64/boot/dts/realtek/rtd139x.dtsi
index 3d4d2323294b..48746d432328 100644
--- a/arch/arm64/boot/dts/realtek/rtd139x.dtsi
+++ b/arch/arm64/boot/dts/realtek/rtd139x.dtsi
@@ -2,7 +2,7 @@
/*
* Realtek RTD1395 SoC family
*
- * Copyright (c) 2019 Andreas Färber
+ * Copyright (c) 2019-2020 Andreas Färber
*/
/memreserve/ 0x 0x0002f000;
@@ -79,6 +79,14 @@ iso: syscon@7000 {
ranges = <0x0 0x7000 0x1000>;
};
+ efuse: efuse@17000 {
+ compatible = "realtek,rtd1195-efuse";
+ reg = <0x17000 0x400>;
+ read-only;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
sb2: syscon@1a000 {
compatible = "syscon", "simple-mfd";
reg = <0x1a000 0x1000>;
--
2.26.2
[PATCH v2 26/29] soc: realtek: chip: Detect RTD1294
Detection logic from downstream include/soc/realtek/rtd129x_cpu.h.
Signed-off-by: Andreas Färber
---
Note: We don't have any RTD1294 .dtsi/.dts yet.
v1 -> v2:
* Instead of direct eFuse register access use nvmem cell API
* Warn on errors other than deferred probing
drivers/soc/realtek/chip.c | 39 ++
1 file changed, 39 insertions(+)
diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c
index 9cee760bac35..bed028ce1b16 100644
--- a/drivers/soc/realtek/chip.c
+++ b/drivers/soc/realtek/chip.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -26,6 +27,8 @@
#define REG_ISO_CHIP_INFO1 0x028
+#define REG_EFUSE_PACKAGE_ID 0x1d8
+
struct dhc_soc_revision {
const char *name;
u16 chip_rev;
@@ -76,6 +79,33 @@ struct dhc_soc {
const char *codename;
};
+static int dhc_efuse_read_u8(struct device *dev, const char *cell_id, u8 *val)
+{
+ struct nvmem_cell *cell;
+ void *buf;
+ size_t len;
+
+ cell = nvmem_cell_get(dev, cell_id);
+ if (IS_ERR(cell))
+ return PTR_ERR(cell);
+
+ buf = nvmem_cell_read(cell, );
+ if (IS_ERR(buf)) {
+ nvmem_cell_put(cell);
+ return PTR_ERR(buf);
+ }
+ if (len != sizeof(*val)) {
+ kfree(buf);
+ nvmem_cell_put(cell);
+ return -EINVAL;
+ }
+ memcpy(val, buf, 1);
+ kfree(buf);
+ nvmem_cell_put(cell);
+
+ return 0;
+}
+
static const char *default_name(struct device *dev, const struct dhc_soc *s)
{
return s->family;
@@ -86,6 +116,15 @@ static const char *rtd1295_name(struct device *dev, const
struct dhc_soc *s)
struct regmap *regmap;
unsigned int val;
int ret;
+ u8 b;
+
+ ret = dhc_efuse_read_u8(dev, "efuse_package_id", );
+ if (ret == -EPROBE_DEFER)
+ return ERR_PTR(ret);
+ else if (ret)
+ dev_warn(dev, "Could not read efuse package_id (%d)\n", ret);
+ else if (b == 0x1)
+ return "RTD1294";
regmap = syscon_regmap_lookup_by_phandle(dev->of_node, "iso-syscon");
if (IS_ERR(regmap)) {
--
2.26.2
[PATCH v2 27/29] nvmem: core: Grammar fixes for help text
It's "an unsigned" but "a U".
Similarly, "an entry" but "a binary entry".
While at it, also drop superfluous articles for negative and zero.
Fixes: 8b977c5498b8 ("nvmem: core: add nvmem_cell_read_u64")
Fixes: 0a9b2d1ce422 ("nvmem: core: add nvmem_cell_read_u16")
Fixes: d026d70a2e94 ("nvmem: core: Add nvmem_cell_read_u32")
Fixes: f1f50eca5f90 ("nvmem: Introduce devm_nvmem_(un)register()")
Fixes: eace75cfdcf7 ("nvmem: Add a simple NVMEM framework for nvmem providers")
Signed-off-by: Andreas Färber
---
In theory, for clean backports this would need to be split into 5 pieces...
Not sure whether anyone would actually do that for help text?
Dropping the Fixes headers might be an alternative.
v2: New
drivers/nvmem/core.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index fc480d636be2..95bed31391cd 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -573,7 +573,7 @@ static int nvmem_add_cells_from_of(struct nvmem_device
*nvmem)
/**
* nvmem_register() - Register a nvmem device for given nvmem_config.
- * Also creates an binary entry in /sys/bus/nvmem/devices/dev-name/nvmem
+ * Also creates a binary entry in /sys/bus/nvmem/devices/dev-name/nvmem
*
* @config: nvmem device configuration with which nvmem device is created.
*
@@ -728,7 +728,7 @@ static void devm_nvmem_release(struct device *dev, void
*res)
/**
* devm_nvmem_register() - Register a managed nvmem device for given
* nvmem_config.
- * Also creates an binary entry in /sys/bus/nvmem/devices/dev-name/nvmem
+ * Also creates a binary entry in /sys/bus/nvmem/devices/dev-name/nvmem
*
* @dev: Device that uses the nvmem device.
* @config: nvmem device configuration with which nvmem device is created.
@@ -772,7 +772,7 @@ static int devm_nvmem_match(struct device *dev, void *res,
void *data)
* @dev: Device that uses the nvmem device.
* @nvmem: Pointer to previously registered nvmem device.
*
- * Return: Will be an negative on error or a zero on success.
+ * Return: Will be negative on error or zero on success.
*/
int devm_nvmem_unregister(struct device *dev, struct nvmem_device *nvmem)
{
@@ -1375,7 +1375,7 @@ static int nvmem_cell_read_common(struct device *dev,
const char *cell_id,
}
/**
- * nvmem_cell_read_u16() - Read a cell value as an u16
+ * nvmem_cell_read_u16() - Read a cell value as a u16
*
* @dev: Device that requests the nvmem cell.
* @cell_id: Name of nvmem cell to read.
@@ -1390,7 +1390,7 @@ int nvmem_cell_read_u16(struct device *dev, const char
*cell_id, u16 *val)
EXPORT_SYMBOL_GPL(nvmem_cell_read_u16);
/**
- * nvmem_cell_read_u32() - Read a cell value as an u32
+ * nvmem_cell_read_u32() - Read a cell value as a u32
*
* @dev: Device that requests the nvmem cell.
* @cell_id: Name of nvmem cell to read.
@@ -1405,7 +1405,7 @@ int nvmem_cell_read_u32(struct device *dev, const char
*cell_id, u32 *val)
EXPORT_SYMBOL_GPL(nvmem_cell_read_u32);
/**
- * nvmem_cell_read_u64() - Read a cell value as an u64
+ * nvmem_cell_read_u64() - Read a cell value as a u64
*
* @dev: Device that requests the nvmem cell.
* @cell_id: Name of nvmem cell to read.
--
2.26.2
[PATCH v2 29/29] soc: realtek: chip: Adopt nvmem_cell_read_u8() helper
Replace the local helper with the newly introduced official one.
Cc: Srinivas Kandagatla
Signed-off-by: Andreas Färber
---
This could be squashed if the new API and this commit were to get merged in
subsequent merge windows or with the help of a topic branch.
v2: New
drivers/soc/realtek/chip.c | 29 +
1 file changed, 1 insertion(+), 28 deletions(-)
diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c
index bed028ce1b16..46e0d9063b5d 100644
--- a/drivers/soc/realtek/chip.c
+++ b/drivers/soc/realtek/chip.c
@@ -79,33 +79,6 @@ struct dhc_soc {
const char *codename;
};
-static int dhc_efuse_read_u8(struct device *dev, const char *cell_id, u8 *val)
-{
- struct nvmem_cell *cell;
- void *buf;
- size_t len;
-
- cell = nvmem_cell_get(dev, cell_id);
- if (IS_ERR(cell))
- return PTR_ERR(cell);
-
- buf = nvmem_cell_read(cell, );
- if (IS_ERR(buf)) {
- nvmem_cell_put(cell);
- return PTR_ERR(buf);
- }
- if (len != sizeof(*val)) {
- kfree(buf);
- nvmem_cell_put(cell);
- return -EINVAL;
- }
- memcpy(val, buf, 1);
- kfree(buf);
- nvmem_cell_put(cell);
-
- return 0;
-}
-
static const char *default_name(struct device *dev, const struct dhc_soc *s)
{
return s->family;
@@ -118,7 +91,7 @@ static const char *rtd1295_name(struct device *dev, const
struct dhc_soc *s)
int ret;
u8 b;
- ret = dhc_efuse_read_u8(dev, "efuse_package_id", );
+ ret = nvmem_cell_read_u8(dev, "efuse_package_id", );
if (ret == -EPROBE_DEFER)
return ERR_PTR(ret);
else if (ret)
--
2.26.2
[PATCH v2 25/29] arm64: dts: realtek: rtd129x: Add eFuse package_id to chip-info
Add the package_id field as sub-node to eFuse and reference it for
chip identification.
Signed-off-by: Andreas Färber
---
v1 -> v2:
* Instead of extending reg, use nvmem-cells reference for eFuse
arch/arm64/boot/dts/realtek/rtd129x.dtsi | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi
b/arch/arm64/boot/dts/realtek/rtd129x.dtsi
index 8f96d4e4c46b..c35955e915f4 100644
--- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi
+++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi
@@ -156,6 +156,13 @@ reset4: reset-controller@50 {
};
};
+ {
+ efuse_package_id: package-id@1d8 {
+ reg = <0x1d8 0x1>;
+ bits = <0 2>;
+ };
+};
+
{
iso_reset: reset-controller@88 {
compatible = "snps,dw-low-reset";
@@ -202,13 +209,6 @@ uart2: serial@400 {
};
};
- {
- otp_package_id: package-id@1d8 {
- reg = <0x1d8 0x1>;
- bits = <0 2>;
- };
-};
-
{
sb2_hd_sem: hwspinlock@0 {
compatible = "realtek,rtd1195-sb2-sem";
@@ -220,6 +220,8 @@ chip-info@200 {
compatible = "realtek,rtd1195-chip";
reg = <0x200 0x8>;
iso-syscon = <>;
+ nvmem-cells = <_package_id>;
+ nvmem-cell-names = "efuse_package_id";
};
sb2_hd_sem_new: hwspinlock@620 {
--
2.26.2
[PATCH v2 19/29] ARM: dts: rtd1195: Add eFuse node
Add a DT node for eFuse.
Signed-off-by: Andreas Färber
---
v2: New
arch/arm/boot/dts/rtd1195.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/rtd1195.dtsi b/arch/arm/boot/dts/rtd1195.dtsi
index 5ad0e81c37af..2ae08f6da9e8 100644
--- a/arch/arm/boot/dts/rtd1195.dtsi
+++ b/arch/arm/boot/dts/rtd1195.dtsi
@@ -119,6 +119,14 @@ iso: syscon@7000 {
ranges = <0x0 0x7000 0x1000>;
};
+ efuse: efuse@17000 {
+ compatible = "realtek,rtd1195-efuse";
+ reg = <0x17000 0x400>;
+ read-only;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
sb2: syscon@1a000 {
compatible = "syscon", "simple-mfd";
reg = <0x1a000 0x1000>;
--
2.26.2
[PATCH v2 22/29] arm64: dts: realtek: rtd16xx: Add eFuse node
Add a DT node for eFuse.
Signed-off-by: Andreas Färber
---
v2: New
arch/arm64/boot/dts/realtek/rtd16xx.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/realtek/rtd16xx.dtsi
b/arch/arm64/boot/dts/realtek/rtd16xx.dtsi
index 04cb546142a0..3c955fc7450c 100644
--- a/arch/arm64/boot/dts/realtek/rtd16xx.dtsi
+++ b/arch/arm64/boot/dts/realtek/rtd16xx.dtsi
@@ -155,6 +155,14 @@ iso: syscon@7000 {
ranges = <0x0 0x7000 0x1000>;
};
+ efuse: efuse@17000 {
+ compatible = "realtek,rtd1195-efuse";
+ reg = <0x17000 0x1000>;
+ read-only;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
sb2: syscon@1a000 {
compatible = "syscon", "simple-mfd";
reg = <0x1a000 0x1000>;
--
2.26.2
[PATCH v2 18/29] nvmem: Add Realtek DHC eFuse driver
Implement enough of a read-only nvmem driver to easily read efuse cells.
Cc: Cheng-Yu Lee
Signed-off-by: Andreas Färber
---
v2: New
MAINTAINERS | 1 +
drivers/nvmem/Kconfig | 9
drivers/nvmem/Makefile| 2 +
drivers/nvmem/rtk-dhc-efuse.c | 86 +++
4 files changed, 98 insertions(+)
create mode 100644 drivers/nvmem/rtk-dhc-efuse.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 1d0d6ab20451..02117fbf0e57 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2312,6 +2312,7 @@ F:Documentation/devicetree/bindings/soc/realtek/
F: arch/arm/boot/dts/rtd*
F: arch/arm/mach-realtek/
F: arch/arm64/boot/dts/realtek/
+F: drivers/nvmem/rtk-dhc-efuse.c
F: drivers/soc/realtek/
ARM/RENESAS ARM64 ARCHITECTURE
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index d7b7f6d688e7..75cf43b16cf9 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -129,6 +129,15 @@ config NVMEM_SPMI_SDAM
Qualcomm Technologies, Inc. PMICs. It provides the clients
an interface to read/write to the SDAM module's shared memory.
+config REALTEK_DHC_EFUSE
+ tristate "Realtek DHC eFuse Support"
+ depends on ARCH_REALTEK || COMPILE_TEST
+ depends on HAS_IOMEM
+ help
+ Say y here to enable read-only access to the Realtek Digital Home
+ This driver can also be built as a module. If so, the module
+ will be called nvmem-rtk-dhc-efuse.
+
config ROCKCHIP_EFUSE
tristate "Rockchip eFuse Support"
depends on ARCH_ROCKCHIP || COMPILE_TEST
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index a7c377218341..67cefdfa44e6 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -33,6 +33,8 @@ obj-$(CONFIG_ROCKCHIP_EFUSE) += nvmem_rockchip_efuse.o
nvmem_rockchip_efuse-y := rockchip-efuse.o
obj-$(CONFIG_ROCKCHIP_OTP) += nvmem-rockchip-otp.o
nvmem-rockchip-otp-y := rockchip-otp.o
+obj-$(CONFIG_REALTEK_DHC_EFUSE)+= nvmem-rtk-dhc-efuse.o
+nvmem-rtk-dhc-efuse-y := rtk-dhc-efuse.o
obj-$(CONFIG_NVMEM_SUNXI_SID) += nvmem_sunxi_sid.o
nvmem_stm32_romem-y:= stm32-romem.o
obj-$(CONFIG_NVMEM_STM32_ROMEM) += nvmem_stm32_romem.o
diff --git a/drivers/nvmem/rtk-dhc-efuse.c b/drivers/nvmem/rtk-dhc-efuse.c
new file mode 100644
index ..4672db2c2619
--- /dev/null
+++ b/drivers/nvmem/rtk-dhc-efuse.c
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Realtek Digital Home Center eFuse
+ *
+ * Copyright (c) 2020 Andreas Färber
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct dhc_efuse {
+ struct device *dev;
+ void __iomem *base;
+ struct nvmem_device *nvmem;
+};
+
+static int dhc_efuse_reg_read(void *priv, unsigned int offset, void *val,
+ size_t bytes)
+{
+ struct dhc_efuse *efuse = priv;
+ u8 *buf = val;
+
+ while (bytes--)
+ *buf++ = readb_relaxed(efuse->base + offset++);
+
+ return 0;
+}
+
+static int dhc_efuse_probe(struct platform_device *pdev)
+{
+ struct dhc_efuse *efuse;
+ struct nvmem_config config = {};
+ struct resource *res;
+
+ efuse = devm_kzalloc(>dev, sizeof(*efuse), GFP_KERNEL);
+ if (!efuse)
+ return -ENOMEM;
+
+ efuse->base = devm_platform_get_and_ioremap_resource(pdev, 0, );
+ if (IS_ERR(efuse->base))
+ return PTR_ERR(efuse->base);
+
+ efuse->dev = >dev;
+
+ config.dev = >dev;
+ config.name = "dhc-efuse";
+ config.owner = THIS_MODULE;
+ config.type = NVMEM_TYPE_OTP;
+ config.read_only = true,
+ config.word_size = 4;
+ config.stride = 1;
+ config.size = resource_size(res);
+ config.reg_read = dhc_efuse_reg_read;
+ config.priv = efuse;
+
+ efuse->nvmem = devm_nvmem_register(>dev, );
+ if (IS_ERR(efuse->nvmem)) {
+ dev_err(>dev, "failed to register nvmem (%ld)\n",
+ PTR_ERR(efuse->nvmem));
+ return PTR_ERR(efuse->nvmem);
+ }
+
+ return 0;
+}
+
+static const struct of_device_id dhc_efuse_dt_ids[] = {
+{ .compatible = "realtek,rtd1195-efuse" },
+{ }
+};
+
+static struct platform_driver dhc_efuse_driver = {
+ .probe = dhc_efuse_probe,
+ .driver = {
+ .name = "rtk-dhc-efuse",
+ .of_match_table = dhc_efuse_dt_ids,
+ },
+};
+module_platform_driver(dhc_efuse_driver);
+
+MODULE_DESCRIPTION("Realtek DHC eFuse driver");
+MODULE_LICENSE("GPL");
--
2.26.2
[PATCH v2 28/29] nvmem: core: Add nvmem_cell_read_u8()
Complement the u16, u32 and u64 helpers with a u8 variant to ease
accessing byte-sized values.
This helper will be useful for Realtek Digital Home Center platforms,
which store some byte and sub-byte sized values in non-volatile memory.
Signed-off-by: Andreas Färber
---
v2: New
drivers/nvmem/core.c | 15 +++
include/linux/nvmem-consumer.h | 1 +
2 files changed, 16 insertions(+)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 95bed31391cd..d6bacc878500 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -1374,6 +1374,21 @@ static int nvmem_cell_read_common(struct device *dev,
const char *cell_id,
return 0;
}
+/**
+ * nvmem_cell_read_u8() - Read a cell value as a u8
+ *
+ * @dev: Device that requests the nvmem cell.
+ * @cell_id: Name of nvmem cell to read.
+ * @val: pointer to output value.
+ *
+ * Return: 0 on success or negative errno.
+ */
+int nvmem_cell_read_u8(struct device *dev, const char *cell_id, u8 *val)
+{
+ return nvmem_cell_read_common(dev, cell_id, val, sizeof(*val));
+}
+EXPORT_SYMBOL_GPL(nvmem_cell_read_u8);
+
/**
* nvmem_cell_read_u16() - Read a cell value as a u16
*
diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
index 1b311d27c9b8..052293f4cbdb 100644
--- a/include/linux/nvmem-consumer.h
+++ b/include/linux/nvmem-consumer.h
@@ -61,6 +61,7 @@ void nvmem_cell_put(struct nvmem_cell *cell);
void devm_nvmem_cell_put(struct device *dev, struct nvmem_cell *cell);
void *nvmem_cell_read(struct nvmem_cell *cell, size_t *len);
int nvmem_cell_write(struct nvmem_cell *cell, void *buf, size_t len);
+int nvmem_cell_read_u8(struct device *dev, const char *cell_id, u8 *val);
int nvmem_cell_read_u16(struct device *dev, const char *cell_id, u16 *val);
int nvmem_cell_read_u32(struct device *dev, const char *cell_id, u32 *val);
int nvmem_cell_read_u64(struct device *dev, const char *cell_id, u64 *val);
--
2.26.2
[PATCH v2 16/29] soc: realtek: chip: Detect RTD1392
From: Stanley Chang
Distinguish RTD1392 from RTD1395 via ISO_CHIP_INFO1 register.
Signed-off-by: Stanley Chang
Signed-off-by: Andreas Färber
---
TODO: Name the bit in ISO_CHIP_INFO1:bound_opts.
Note: We don't have any RTD1392 .dtsi/.dts yet.
v2: New
* Split out from Stanley's v1
drivers/soc/realtek/chip.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c
index 6b3d1f3d3816..9cee760bac35 100644
--- a/drivers/soc/realtek/chip.c
+++ b/drivers/soc/realtek/chip.c
@@ -107,10 +107,33 @@ static const char *rtd1295_name(struct device *dev, const
struct dhc_soc *s)
return "RTD1295";
}
+static const char *rtd1395_name(struct device *dev, const struct dhc_soc *s)
+{
+ struct regmap *regmap;
+ unsigned int val;
+ int ret;
+
+ regmap = syscon_regmap_lookup_by_phandle(dev->of_node, "iso-syscon");
+ if (IS_ERR(regmap)) {
+ ret = PTR_ERR(regmap);
+ if (ret == -EPROBE_DEFER)
+ return ERR_PTR(ret);
+ dev_warn(dev, "Could not check iso (%d)\n", ret);
+ } else {
+ ret = regmap_read(regmap, REG_ISO_CHIP_INFO1, );
+ if (ret)
+ dev_warn(dev, "Could not read chip_info1 (%d)\n", ret);
+ else if (val & BIT(12))
+ return "RTD1392";
+ }
+
+ return "RTD1395";
+}
+
static const struct dhc_soc dhc_soc_families[] = {
{ 0x6329, "RTD1195", default_name, rtd1195_revisions, "Phoenix" },
{ 0x6421, "RTD1295", rtd1295_name, rtd1295_revisions, "Kylin" },
- { 0x6481, "RTD1395", default_name, rtd1395_revisions, "Hercules" },
+ { 0x6481, "RTD1395", rtd1395_name, rtd1395_revisions, "Hercules" },
{ 0x6525, "RTD1619", default_name, rtd1619_revisions, "Thor" },
{ 0x6570, "RTD1319", default_name, rtd1319_revisions, "Hank" },
};
--
2.26.2
[PATCH v2 23/29] arm64: dts: realtek: rtd13xx: Add eFuse node
Add a DT node for eFuse.
Signed-off-by: Andreas Färber
---
v2: New
arch/arm64/boot/dts/realtek/rtd13xx.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
index e4271ef5cb1e..ed5ee7cc6a44 100644
--- a/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
+++ b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
@@ -139,6 +139,14 @@ iso: syscon@7000 {
ranges = <0x0 0x7000 0x1000>;
};
+ efuse: efuse@17000 {
+ compatible = "realtek,rtd1195-efuse";
+ reg = <0x17000 0x1000>;
+ read-only;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
sb2: syscon@1a000 {
compatible = "syscon", "simple-mfd";
reg = <0x1a000 0x1000>;
--
2.26.2
[PATCH v2 05/29] dt-bindings: soc: realtek: rtd1195-chip: Add iso-syscon property
Allow to optionally specify a phandle to iso syscon to identify the chip.
RTD1295 family will want to check the ISO_CHIP_INFO1 register.
Signed-off-by: Andreas Färber
---
A SoC specific binding would defeat the purpose of the generic Linux driver
detecting the SoC based on registers.
Simply allowing it all for SoC families seems the most flexible.
v1 -> v2:
* Instead of extending reg, allow optional iso-syscon property for RTD129x.
Iso syscon currently does not have a compatible, and it may need to differ
across SoC families.
.../bindings/soc/realtek/realtek,rtd1195-chip.yaml | 9 +
1 file changed, 9 insertions(+)
diff --git
a/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml
b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml
index 86a1de214782..dfe33c95f68d 100644
--- a/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml
+++ b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml
@@ -11,6 +11,7 @@ maintainers:
description: |
The Realtek DHC SoCs have some registers to identify the chip and revision.
+ To identify the exact model within a family, further registers are needed.
properties:
compatible:
@@ -19,6 +20,8 @@ properties:
reg:
maxItems: 1
+ iso-syscon: true
+
required:
- compatible
- reg
@@ -31,4 +34,10 @@ examples:
compatible = "realtek,rtd1195-chip";
reg = <0x1801a200 0x8>;
};
+ - |
+chip-info@9801a200 {
+compatible = "realtek,rtd1195-chip";
+reg = <0x9801a200 0x8>;
+iso-syscon = <>;
+};
...
--
2.26.2
[PATCH v2 01/29] dt-bindings: soc: Add Realtek RTD1195 chip info binding
Define a binding for RTD1195 and later DHC SoCs' chip info registers.
Add the new directory to MAINTAINERS.
Signed-off-by: Andreas Färber
---
Note: The binding gets extended compatibly twice with additional properties.
Could be squashed later if approved.
v1 -> v2:
* Dropped quotes for compatible (Rob)
* Added additionalProperties: false (Rob)
.../soc/realtek/realtek,rtd1195-chip.yaml | 34 +++
MAINTAINERS | 1 +
2 files changed, 35 insertions(+)
create mode 100644
Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml
diff --git
a/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml
b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml
new file mode 100644
index ..86a1de214782
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml
@@ -0,0 +1,34 @@
+# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/soc/realtek/realtek,rtd1195-chip.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Realtek Digital Home Center chip identification
+
+maintainers:
+ - Andreas Färber
+
+description: |
+ The Realtek DHC SoCs have some registers to identify the chip and revision.
+
+properties:
+ compatible:
+const: realtek,rtd1195-chip
+
+ reg:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+chip-info@1801a200 {
+compatible = "realtek,rtd1195-chip";
+reg = <0x1801a200 0x8>;
+};
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index d282ee3492e0..78adbc3cc101 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2307,6 +2307,7 @@ L:linux-arm-ker...@lists.infradead.org (moderated
for non-subscribers)
L: linux-realtek-...@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/arm/realtek.yaml
+F: Documentation/devicetree/bindings/soc/realtek/
F: arch/arm/boot/dts/rtd*
F: arch/arm/mach-realtek/
F: arch/arm64/boot/dts/realtek/
--
2.26.2
[PATCH v2 24/29] dt-bindings: soc: realtek: rtd1195-chip: Allow nvmem-cells property
Allow to optionally specify nvmem cells to identify the chip.
RTD1295 family will want the eFuse package_id cell.
Signed-off-by: Andreas Färber
---
v1 -> v2:
* Instead of extending reg, allow nvmem-cells reference for eFuse
.../bindings/soc/realtek/realtek,rtd1195-chip.yaml | 12
1 file changed, 12 insertions(+)
diff --git
a/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml
b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml
index dfe33c95f68d..57a6e0df4494 100644
--- a/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml
+++ b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1195-chip.yaml
@@ -22,6 +22,10 @@ properties:
iso-syscon: true
+ nvmem-cells: true
+
+ nvmem-cell-names: true
+
required:
- compatible
- reg
@@ -40,4 +44,12 @@ examples:
reg = <0x9801a200 0x8>;
iso-syscon = <>;
};
+ - |
+chip-info@9801a200 {
+compatible = "realtek,rtd1195-chip";
+reg = <0x9801a200 0x8>;
+iso-syscon = <>;
+nvmem-cells = <_package_id>;
+nvmem-cell-names = "efuse_package_id";
+};
...
--
2.26.2
[PATCH v2 20/29] arm64: dts: realtek: rtd129x: Add eFuse node
Add a DT node for eFuse.
Signed-off-by: Andreas Färber
---
v2: New
arch/arm64/boot/dts/realtek/rtd129x.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi
b/arch/arm64/boot/dts/realtek/rtd129x.dtsi
index 30a7782aa0d9..8f96d4e4c46b 100644
--- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi
+++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi
@@ -81,6 +81,14 @@ iso: syscon@7000 {
ranges = <0x0 0x7000 0x1000>;
};
+ efuse: efuse@17000 {
+ compatible = "realtek,rtd1195-efuse";
+ reg = <0x17000 0x400>;
+ read-only;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
sb2: syscon@1a000 {
compatible = "syscon", "simple-mfd";
reg = <0x1a000 0x1000>;
@@ -194,6 +202,13 @@ uart2: serial@400 {
};
};
+ {
+ otp_package_id: package-id@1d8 {
+ reg = <0x1d8 0x1>;
+ bits = <0 2>;
+ };
+};
+
{
sb2_hd_sem: hwspinlock@0 {
compatible = "realtek,rtd1195-sb2-sem";
--
2.26.2
[PATCH v2 09/29] soc: realtek: chip: Add RTD1395 info
Chip ID from BPi-M4.
Revisions based on downstream drivers/soc/realtek/rtd139x/rtk_chip.c.
Signed-off-by: Andreas Färber
---
v2: New
drivers/soc/realtek/chip.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c
index 32ed0e4a3646..aa7ca6bb1e64 100644
--- a/drivers/soc/realtek/chip.c
+++ b/drivers/soc/realtek/chip.c
@@ -46,6 +46,13 @@ static const struct dhc_soc_revision rtd1295_revisions[] = {
{ }
};
+static const struct dhc_soc_revision rtd1395_revisions[] = {
+ { "A00", 0x },
+ { "A01", 0x0001 },
+ { "A02", 0x0002 },
+ { }
+};
+
struct dhc_soc {
u16 chip_id;
const char *family;
@@ -88,6 +95,7 @@ static const char *rtd1295_name(struct device *dev, const
struct dhc_soc *s)
static const struct dhc_soc dhc_soc_families[] = {
{ 0x6329, "RTD1195", default_name, rtd1195_revisions, "Phoenix" },
{ 0x6421, "RTD1295", rtd1295_name, rtd1295_revisions, "Kylin" },
+ { 0x6481, "RTD1395", default_name, rtd1395_revisions, "Hercules" },
};
static const struct dhc_soc *dhc_soc_by_chip_id(u16 chip_id)
--
2.26.2
[PATCH v2 17/29] dt-bindings: nvmem: Add Realtek RTD1195 eFuse
Add a DT binding for eFuse on Realtek Digital Home Center SoCs.
Signed-off-by: Andreas Färber
---
v2: New
.../bindings/nvmem/realtek,rtd1195-efuse.yaml | 53 +++
MAINTAINERS | 1 +
2 files changed, 54 insertions(+)
create mode 100644
Documentation/devicetree/bindings/nvmem/realtek,rtd1195-efuse.yaml
diff --git a/Documentation/devicetree/bindings/nvmem/realtek,rtd1195-efuse.yaml
b/Documentation/devicetree/bindings/nvmem/realtek,rtd1195-efuse.yaml
new file mode 100644
index ..a616cb22673e
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/realtek,rtd1195-efuse.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/nvmem/realtek,rtd1195-efuse.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Realtek Digital Home Center eFuse
+
+maintainers:
+ - Andreas Färber
+
+description: |
+ The Realtek DHC SoCs have an eFuse block with non-volatile OTP memory.
+
+allOf:
+ - $ref: "nvmem.yaml#"
+
+properties:
+ compatible:
+const: realtek,rtd1195-efuse
+
+ reg:
+maxItems: 1
+
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 1
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+efuse@18017000 {
+compatible = "realtek,rtd1195-efuse";
+reg = <0x18017000 0x400>;
+};
+ - |
+efuse@98017000 {
+compatible = "realtek,rtd1195-efuse";
+reg = <0x98017000 0x400>;
+#address-cells = <1>;
+#size-cells = <1>;
+
+efuse_package_id: package-id@1d8 {
+reg = <0x1d8 0x1>;
+bits = <0 2>;
+};
+};
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index ff0ee48fee6f..1d0d6ab20451 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2307,6 +2307,7 @@ L:linux-arm-ker...@lists.infradead.org (moderated
for non-subscribers)
L: linux-realtek-...@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/arm/realtek.yaml
+F: Documentation/devicetree/bindings/nvmem/realtek,rtd1195-efuse.yaml
F: Documentation/devicetree/bindings/soc/realtek/
F: arch/arm/boot/dts/rtd*
F: arch/arm/mach-realtek/
--
2.26.2
[PATCH v2 04/29] ARM: dts: rtd1195: Add chip info node
Add a DT node for chip identification.
Signed-off-by: Andreas Färber
---
v1 -> v2:
* Rebased onto SB2 syscon
arch/arm/boot/dts/rtd1195.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/rtd1195.dtsi b/arch/arm/boot/dts/rtd1195.dtsi
index 6fd12a2d766e..5ad0e81c37af 100644
--- a/arch/arm/boot/dts/rtd1195.dtsi
+++ b/arch/arm/boot/dts/rtd1195.dtsi
@@ -223,6 +223,11 @@ sb2_hd_sem: hwspinlock@0 {
#hwlock-cells = <0>;
};
+ chip-info@200 {
+ compatible = "realtek,rtd1195-chip";
+ reg = <0x200 0x8>;
+ };
+
sb2_hd_sem_new: hwspinlock@620 {
compatible = "realtek,rtd1195-sb2-sem";
reg = <0x620 0x20>;
--
2.26.2
[PATCH v2 03/29] arm64: dts: realtek: rtd129x: Add chip info node
Add a DT node for chip identification.
Acked-by: James Tai
Signed-off-by: Andreas Färber
---
v1 -> v2:
* Rebased onto SB2 syscon
arch/arm64/boot/dts/realtek/rtd129x.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi
b/arch/arm64/boot/dts/realtek/rtd129x.dtsi
index 93ab6fdd03d4..b5be9df80dae 100644
--- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi
+++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi
@@ -201,6 +201,11 @@ sb2_hd_sem: hwspinlock@0 {
#hwlock-cells = <0>;
};
+ chip-info@200 {
+ compatible = "realtek,rtd1195-chip";
+ reg = <0x200 0x8>;
+ };
+
sb2_hd_sem_new: hwspinlock@620 {
compatible = "realtek,rtd1195-sb2-sem";
reg = <0x620 0x20>;
--
2.26.2
[PATCH v2 15/29] arm64: dts: realtek: rtd13xx: Add chip info node
Add a DT node for chip identification.
Signed-off-by: Andreas Färber
---
v2: New
arch/arm64/boot/dts/realtek/rtd13xx.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
index e41be02f2e3a..e4271ef5cb1e 100644
--- a/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
+++ b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
@@ -211,3 +211,10 @@ uart2: serial@400 {
status = "disabled";
};
};
+
+ {
+ chip-info@200 {
+ compatible = "realtek,rtd1195-chip";
+ reg = <0x200 0x8>;
+ };
+};
--
2.26.2
[PATCH v2 11/29] soc: realtek: chip: Add RTD1619 info
Revisions based on downstream drivers/soc/realtek/rtd16xx/rtk_chip.c.
Signed-off-by: Andreas Färber
---
v2: New
drivers/soc/realtek/chip.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c
index aa7ca6bb1e64..e3220187e336 100644
--- a/drivers/soc/realtek/chip.c
+++ b/drivers/soc/realtek/chip.c
@@ -53,6 +53,12 @@ static const struct dhc_soc_revision rtd1395_revisions[] = {
{ }
};
+static const struct dhc_soc_revision rtd1619_revisions[] = {
+ { "A00", 0x },
+ { "A01", 0x0001 },
+ { }
+};
+
struct dhc_soc {
u16 chip_id;
const char *family;
@@ -96,6 +102,7 @@ static const struct dhc_soc dhc_soc_families[] = {
{ 0x6329, "RTD1195", default_name, rtd1195_revisions, "Phoenix" },
{ 0x6421, "RTD1295", rtd1295_name, rtd1295_revisions, "Kylin" },
{ 0x6481, "RTD1395", default_name, rtd1395_revisions, "Hercules" },
+ { 0x6525, "RTD1619", default_name, rtd1619_revisions, "Thor" },
};
static const struct dhc_soc *dhc_soc_by_chip_id(u16 chip_id)
--
2.26.2
Re: [PATCH v4 3/3] arm64: dts: realtek: Add RTD1319 SoC and Realtek Pym Particles EVB
Hi James,
Am 21.06.20 um 01:32 schrieb Andreas Färber:
From: James Tai
Add Device Trees for Realtek RTD1319 SoC family, RTD1319 SoC and
Realtek Pym Particles EVB.
Signed-off-by: James Tai
Signed-off-by: Andreas Färber
---
v3 -> v4:
* Updated Realtek copyright for 2 out of 3 files from v3
* Renamed from rtd1319-pymparticle.dts to rtd1319-pymparticles.dts
* Updated compatible from pymparticle to pym-particles
* Updated PMU compatible from armv8-pmuv3 to cortex-a55-pmu (Robin)
v2 -> v3:
* Add virtual maintenance interrupt for architecture timer
* Correct the GIC redistributor address range
[...]
diff --git a/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
new file mode 100644
index ..8c5b6fc7b8eb
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
[...]
+ gic: interrupt-controller@ff10 {
+ compatible = "arm,gic-v3";
+ reg = <0xff10 0x1>,
+ <0xff14 0x8>;
+ interrupts = ;
In my testing this appears to cause the following error:
[2.239858] irq: type mismatch, failed to map hwirq-25 for
interrupt-controller@ff10!
...
[3.505649] kvm [1]: IPA Size Limit: 40bits
[3.506051] kvm [1]: GICv3: no GICV resource entry
[3.506058] kvm [1]: disabling GICv2 emulation
[3.506081] kvm [1]: GIC system register CPU interface enabled
[3.506175] kvm [1]: vgic interrupt IRQ1
[3.506293] kvm [1]: Hyp mode initialized successfully
If I change it to IRQ_TYPE_LEVEL_LOW, that error goes away:
[3.506030] kvm [1]: IPA Size Limit: 40bits
[3.506430] kvm [1]: GICv3: no GICV resource entry
[3.506437] kvm [1]: disabling GICv2 emulation
[3.506459] kvm [1]: GIC system register CPU interface enabled
[3.506551] kvm [1]: vgic interrupt IRQ1
[3.506672] kvm [1]: Hyp mode initialized successfully
In-tree RTD1619 has it as HIGH, too, but doesn't show above error:
[2.918973] kvm [1]: IPA Size Limit: 40bits
[2.919345] kvm [1]: GICv3: no GICV resource entry
[2.919352] kvm [1]: disabling GICv2 emulation
[2.919373] kvm [1]: GIC system register CPU interface enabled
[2.919522] kvm [1]: vgic interrupt IRQ1
[2.919700] kvm [1]: Hyp mode initialized successfully
RTD1619 doesn't show an error either if I change it to LOW though:
[2.918843] kvm [1]: IPA Size Limit: 40bits
[2.919212] kvm [1]: GICv3: no GICV resource entry
[2.919218] kvm [1]: disabling GICv2 emulation
[2.919240] kvm [1]: GIC system register CPU interface enabled
[2.919390] kvm [1]: vgic interrupt IRQ1
[2.919567] kvm [1]: Hyp mode initialized successfully
The GICv3 bindings example does have it as 4 == HIGH, but so does the
GICv2 binding example, and yet we used LOW == 8 for in-tree RTD139x,
RTD129x and RTD1195. The downstream BSP uses value 4 == HIGH for both
RTD16xx and RTD13xx - is it possible this was never actually tested?
Thanks in advance for clarifying the correct interrupt polarity.
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ };
[snip]
Regards,
Andreas
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
Re: [PATCH v4 3/3] arm64: dts: realtek: Add RTD1319 SoC and Realtek Pym Particles EVB
Am 21.06.20 um 01:32 schrieb Andreas Färber:
diff --git a/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
new file mode 100644
index ..8c5b6fc7b8eb
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
[...]
+ {
+ uart0: serial0@800 {
Node name should be serial, not serial0.
+ compatible = "snps,dw-apb-uart";
+ reg = <0x800 0x400>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = ;
+ clock-frequency = <43200>;
+ status = "disabled";
+ };
+};
+
+ {
+ uart1: serial1@200 {
Ditto, serial.
+ compatible = "snps,dw-apb-uart";
+ reg = <0x200 0x400>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = ;
+ clock-frequency = <43200>;
+ status = "disabled";
+ };
+
+ uart2: serial2@400 {
Ditto.
+ compatible = "snps,dw-apb-uart";
+ reg = <0x400 0x400>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = ;
+ clock-frequency = <43200>;
+ status = "disabled";
+ };
+};
Regards,
Andreas
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
[PATCH v4 3/3] arm64: dts: realtek: Add RTD1319 SoC and Realtek Pym Particles EVB
From: James Tai
Add Device Trees for Realtek RTD1319 SoC family, RTD1319 SoC and
Realtek Pym Particles EVB.
Signed-off-by: James Tai
Signed-off-by: Andreas Färber
---
v3 -> v4:
* Updated Realtek copyright for 2 out of 3 files from v3
* Renamed from rtd1319-pymparticle.dts to rtd1319-pymparticles.dts
* Updated compatible from pymparticle to pym-particles
* Updated PMU compatible from armv8-pmuv3 to cortex-a55-pmu (Robin)
v2 -> v3:
* Add virtual maintenance interrupt for architecture timer
* Correct the GIC redistributor address range
v1 -> v2:
* Reserve the boot ROM address
* Reserve boot loader address
* Reserve audio/video FW address
* Reserve RPC and ring buffer address
* Reserve TEE address
* Support 1 GiB RAM by default
* Reduce rbus range to 2 MiB
* Apply the syscon for ISO,MISC,CRT,SB2,SCPU_WRAPPER
* Adjust compatible strings order in document
arch/arm64/boot/dts/realtek/Makefile | 2 +
.../boot/dts/realtek/rtd1319-pymparticles.dts | 43
arch/arm64/boot/dts/realtek/rtd1319.dtsi | 12 +
arch/arm64/boot/dts/realtek/rtd13xx.dtsi | 213 ++
4 files changed, 270 insertions(+)
create mode 100644 arch/arm64/boot/dts/realtek/rtd1319-pymparticles.dts
create mode 100644 arch/arm64/boot/dts/realtek/rtd1319.dtsi
create mode 100644 arch/arm64/boot/dts/realtek/rtd13xx.dtsi
diff --git a/arch/arm64/boot/dts/realtek/Makefile
b/arch/arm64/boot/dts/realtek/Makefile
index ef8d8fcbaa05..83708596726d 100644
--- a/arch/arm64/boot/dts/realtek/Makefile
+++ b/arch/arm64/boot/dts/realtek/Makefile
@@ -9,6 +9,8 @@ dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-zidoo-x9s.dtb
dtb-$(CONFIG_ARCH_REALTEK) += rtd1296-ds418.dtb
+dtb-$(CONFIG_ARCH_REALTEK) += rtd1319-pymparticles.dtb
+
dtb-$(CONFIG_ARCH_REALTEK) += rtd1395-bpi-m4.dtb
dtb-$(CONFIG_ARCH_REALTEK) += rtd1395-lionskin.dtb
diff --git a/arch/arm64/boot/dts/realtek/rtd1319-pymparticles.dts
b/arch/arm64/boot/dts/realtek/rtd1319-pymparticles.dts
new file mode 100644
index ..e0b3c3707a85
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1319-pymparticles.dts
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+/*
+ * Copyright (c) 2019-2020 Realtek Semiconductor Corp.
+ */
+
+/dts-v1/;
+
+#include "rtd1319.dtsi"
+
+/ {
+ compatible = "realtek,pym-particles", "realtek,rtd1319";
+ model = "Realtek Pym Particles EVB";
+
+ memory@2e000 {
+ device_type = "memory";
+ reg = <0x2e000 0x3ffd2000>; /* boot ROM to 1 GiB or 2 GiB */
+ };
+
+ chosen {
+ stdout-path = "serial0:460800n8";
+ };
+
+ aliases {
+ serial0 =
+ serial1 =
+ serial2 =
+ };
+};
+
+/* debug console (J1) */
+ {
+ status = "okay";
+};
+
+/* M.2 slots (CON2, CON8) and J14 */
+ {
+ status = "disabled";
+};
+
+/* GPIO connector (T1) */
+ {
+ status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/realtek/rtd1319.dtsi
b/arch/arm64/boot/dts/realtek/rtd1319.dtsi
new file mode 100644
index ..1dcee9cd
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1319.dtsi
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+/*
+ * Realtek RTD1319 SoC
+ *
+ * Copyright (c) 2019 Realtek Semiconductor Corp.
+ */
+
+#include "rtd13xx.dtsi"
+
+/ {
+ compatible = "realtek,rtd1319";
+};
diff --git a/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
new file mode 100644
index ..8c5b6fc7b8eb
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+/*
+ * Realtek RTD13xx SoC family
+ *
+ * Copyright (c) 2019-2020 Realtek Semiconductor Corp.
+ */
+
+/memreserve/ 0x 0x0002e000; /* Boot ROM */
+/memreserve/ 0x0002e000 0x0010; /* Boot loader */
+/memreserve/ 0x0f40 0x0050; /* Video FW */
+/memreserve/ 0x0f90 0x0050; /* Audio FW */
+/memreserve/ 0x1000 0x00014000; /* Audio FW RAM */
+
+#include
+#include
+
+/ {
+ interrupt-parent = <>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ rpc_comm: rpc@3f000 {
+ reg = <0x3f000 0x1000>;
+ };
+
+ rpc_ringbuf: rpc@1ffe000 {
+ reg = <0x1ffe000 0x4000>;
+ };
+
+ tee: tee@1010 {
+ reg = <0x1010 0xf0>;
+ no-map;
+ };
+
[PATCH v4 1/3] dt-bindings: arm: realtek: Convert comments to descriptions
Turn the SoC-level comments into description properties. Signed-off-by: Andreas Färber --- v4: New .../devicetree/bindings/arm/realtek.yaml | 24 +-- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/realtek.yaml b/Documentation/devicetree/bindings/arm/realtek.yaml index 845f9c76d6f7..0b388016bbcd 100644 --- a/Documentation/devicetree/bindings/arm/realtek.yaml +++ b/Documentation/devicetree/bindings/arm/realtek.yaml @@ -14,21 +14,21 @@ properties: const: '/' compatible: oneOf: - # RTD1195 SoC based boards - - items: + - description: RTD1195 SoC based boards +items: - enum: - mele,x1000 # MeLE X1000 - realtek,horseradish # Realtek Horseradish EVB - const: realtek,rtd1195 - # RTD1293 SoC based boards - - items: + - description: RTD1293 SoC based boards +items: - enum: - synology,ds418j # Synology DiskStation DS418j - const: realtek,rtd1293 - # RTD1295 SoC based boards - - items: + - description: RTD1295 SoC based boards +items: - enum: - mele,v9 # MeLE V9 - probox2,ava # ProBox2 AVA @@ -36,21 +36,21 @@ properties: - zidoo,x9s # Zidoo X9S - const: realtek,rtd1295 - # RTD1296 SoC based boards - - items: + - description: RTD1296 SoC based boards +items: - enum: - synology,ds418 # Synology DiskStation DS418 - const: realtek,rtd1296 - # RTD1395 SoC based boards - - items: + - description: RTD1395 SoC based boards +items: - enum: - bananapi,bpi-m4 # Banana Pi BPI-M4 - realtek,lion-skin # Realtek Lion Skin EVB - const: realtek,rtd1395 - # RTD1619 SoC based boards - - items: + - description: RTD1619 SoC based boards +items: - enum: - realtek,mjolnir # Realtek Mjolnir EVB - const: realtek,rtd1619 -- 2.26.2
[PATCH v4 2/3] dt-bindings: arm: realtek: Document RTD1319 and Realtek Pym Particles EVB
From: James Tai Define compatible strings for Realtek RTD1319 SoC and Realtek Pym Particles EVB. Signed-off-by: James Tai Signed-off-by: Andreas Färber --- v3 -> v4: * Renamed compatible from pymparticle to pym-particles * Turned SoC comment into description v2 -> v3: Unchanged v1 -> v2: * Put string in alphabetical order Documentation/devicetree/bindings/arm/realtek.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/realtek.yaml b/Documentation/devicetree/bindings/arm/realtek.yaml index 0b388016bbcd..e36e87df3521 100644 --- a/Documentation/devicetree/bindings/arm/realtek.yaml +++ b/Documentation/devicetree/bindings/arm/realtek.yaml @@ -42,6 +42,12 @@ properties: - synology,ds418 # Synology DiskStation DS418 - const: realtek,rtd1296 + - description: RTD1319 SoC based boards +items: + - enum: + - realtek,pym-particles # Realtek Pym Particles EVB + - const: realtek,rtd1319 + - description: RTD1395 SoC based boards items: - enum: -- 2.26.2
[PATCH v4 0/3] arm64: dts: realtek: Initial RTD1319 and Pym Particles support
Hello, This patch series adds initial Device Trees for Realtek RTD1319 SoC and Realtek Pym Particles EVB. This v4 is an update of James' v3, incorporating pending review comments. Upstreaming progress being tracked at: https://en.opensuse.org/HCL:Realtek_DHC Latest experimental patches at: https://github.com/afaerber/linux/commits/rtd1295-next Have a lot of fun! Cheers, Andreas v3 -> v4: * Updated Realtek copyright for files changed in v3 * Updated PMU compatible (Robin) * Changed compatible, renamed .dts * Updated bindings schema and prepended refactoring Cc: devicet...@vger.kernel.org Cc: Rob Herring Cc: James Tai Andreas Färber (1): dt-bindings: arm: realtek: Convert comments to descriptions James Tai (2): dt-bindings: arm: realtek: Document RTD1319 and Realtek Pym Particles EVB arm64: dts: realtek: Add RTD1319 SoC and Realtek Pym Particles EVB .../devicetree/bindings/arm/realtek.yaml | 30 ++- arch/arm64/boot/dts/realtek/Makefile | 2 + .../boot/dts/realtek/rtd1319-pymparticles.dts | 43 arch/arm64/boot/dts/realtek/rtd1319.dtsi | 12 + arch/arm64/boot/dts/realtek/rtd13xx.dtsi | 213 ++ 5 files changed, 288 insertions(+), 12 deletions(-) create mode 100644 arch/arm64/boot/dts/realtek/rtd1319-pymparticles.dts create mode 100644 arch/arm64/boot/dts/realtek/rtd1319.dtsi create mode 100644 arch/arm64/boot/dts/realtek/rtd13xx.dtsi -- 2.26.2
[PATCH v4 2/3] dt-bindings: arm: realtek: Document RTD1319 and Realtek Pym Particles EVB
From: James Tai Define compatible strings for Realtek RTD1319 SoC and Realtek Pym Particles EVB. Signed-off-by: James Tai Signed-off-by: Andreas Färber --- v3 -> v4: * Renamed compatible from pymparticle to pym-particles * Turned SoC comment into description v2 -> v3: Unchanged v1 -> v2: * Put string in alphabetical order Documentation/devicetree/bindings/arm/realtek.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/realtek.yaml b/Documentation/devicetree/bindings/arm/realtek.yaml index 0b388016bbcd..e36e87df3521 100644 --- a/Documentation/devicetree/bindings/arm/realtek.yaml +++ b/Documentation/devicetree/bindings/arm/realtek.yaml @@ -42,6 +42,12 @@ properties: - synology,ds418 # Synology DiskStation DS418 - const: realtek,rtd1296 + - description: RTD1319 SoC based boards +items: + - enum: + - realtek,pym-particles # Realtek Pym Particles EVB + - const: realtek,rtd1319 + - description: RTD1395 SoC based boards items: - enum: -- 2.26.2
[PATCH v4 3/3] arm64: dts: realtek: Add RTD1319 SoC and Realtek Pym Particles EVB
From: James Tai
Add Device Trees for Realtek RTD1319 SoC family, RTD1319 SoC and
Realtek Pym Particles EVB.
Signed-off-by: James Tai
Signed-off-by: Andreas Färber
---
v3 -> v4:
* Updated Realtek copyright for 2 out of 3 files from v3
* Renamed from rtd1319-pymparticle.dts to rtd1319-pymparticles.dts
* Updated compatible from pymparticle to pym-particles
* Updated PMU compatible from armv8-pmuv3 to cortex-a55-pmu (Robin)
v2 -> v3:
* Add virtual maintenance interrupt for architecture timer
* Correct the GIC redistributor address range
v1 -> v2:
* Reserve the boot ROM address
* Reserve boot loader address
* Reserve audio/video FW address
* Reserve RPC and ring buffer address
* Reserve TEE address
* Support 1 GiB RAM by default
* Reduce rbus range to 2 MiB
* Apply the syscon for ISO,MISC,CRT,SB2,SCPU_WRAPPER
* Adjust compatible strings order in document
arch/arm64/boot/dts/realtek/Makefile | 2 +
.../boot/dts/realtek/rtd1319-pymparticles.dts | 43
arch/arm64/boot/dts/realtek/rtd1319.dtsi | 12 +
arch/arm64/boot/dts/realtek/rtd13xx.dtsi | 213 ++
4 files changed, 270 insertions(+)
create mode 100644 arch/arm64/boot/dts/realtek/rtd1319-pymparticles.dts
create mode 100644 arch/arm64/boot/dts/realtek/rtd1319.dtsi
create mode 100644 arch/arm64/boot/dts/realtek/rtd13xx.dtsi
diff --git a/arch/arm64/boot/dts/realtek/Makefile
b/arch/arm64/boot/dts/realtek/Makefile
index ef8d8fcbaa05..83708596726d 100644
--- a/arch/arm64/boot/dts/realtek/Makefile
+++ b/arch/arm64/boot/dts/realtek/Makefile
@@ -9,6 +9,8 @@ dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-zidoo-x9s.dtb
dtb-$(CONFIG_ARCH_REALTEK) += rtd1296-ds418.dtb
+dtb-$(CONFIG_ARCH_REALTEK) += rtd1319-pymparticles.dtb
+
dtb-$(CONFIG_ARCH_REALTEK) += rtd1395-bpi-m4.dtb
dtb-$(CONFIG_ARCH_REALTEK) += rtd1395-lionskin.dtb
diff --git a/arch/arm64/boot/dts/realtek/rtd1319-pymparticles.dts
b/arch/arm64/boot/dts/realtek/rtd1319-pymparticles.dts
new file mode 100644
index ..e0b3c3707a85
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1319-pymparticles.dts
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+/*
+ * Copyright (c) 2019-2020 Realtek Semiconductor Corp.
+ */
+
+/dts-v1/;
+
+#include "rtd1319.dtsi"
+
+/ {
+ compatible = "realtek,pym-particles", "realtek,rtd1319";
+ model = "Realtek Pym Particles EVB";
+
+ memory@2e000 {
+ device_type = "memory";
+ reg = <0x2e000 0x3ffd2000>; /* boot ROM to 1 GiB or 2 GiB */
+ };
+
+ chosen {
+ stdout-path = "serial0:460800n8";
+ };
+
+ aliases {
+ serial0 =
+ serial1 =
+ serial2 =
+ };
+};
+
+/* debug console (J1) */
+ {
+ status = "okay";
+};
+
+/* M.2 slots (CON2, CON8) and J14 */
+ {
+ status = "disabled";
+};
+
+/* GPIO connector (T1) */
+ {
+ status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/realtek/rtd1319.dtsi
b/arch/arm64/boot/dts/realtek/rtd1319.dtsi
new file mode 100644
index ..1dcee9cd
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1319.dtsi
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+/*
+ * Realtek RTD1319 SoC
+ *
+ * Copyright (c) 2019 Realtek Semiconductor Corp.
+ */
+
+#include "rtd13xx.dtsi"
+
+/ {
+ compatible = "realtek,rtd1319";
+};
diff --git a/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
new file mode 100644
index ..8c5b6fc7b8eb
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+/*
+ * Realtek RTD13xx SoC family
+ *
+ * Copyright (c) 2019-2020 Realtek Semiconductor Corp.
+ */
+
+/memreserve/ 0x 0x0002e000; /* Boot ROM */
+/memreserve/ 0x0002e000 0x0010; /* Boot loader */
+/memreserve/ 0x0f40 0x0050; /* Video FW */
+/memreserve/ 0x0f90 0x0050; /* Audio FW */
+/memreserve/ 0x1000 0x00014000; /* Audio FW RAM */
+
+#include
+#include
+
+/ {
+ interrupt-parent = <>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ rpc_comm: rpc@3f000 {
+ reg = <0x3f000 0x1000>;
+ };
+
+ rpc_ringbuf: rpc@1ffe000 {
+ reg = <0x1ffe000 0x4000>;
+ };
+
+ tee: tee@1010 {
+ reg = <0x1010 0xf0>;
+ no-map;
+ };
+
[PATCH v4 1/3] dt-bindings: arm: realtek: Convert comments to descriptions
Turn the SoC-level comments into description properties. Signed-off-by: Andreas Färber --- v4: New .../devicetree/bindings/arm/realtek.yaml | 24 +-- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/realtek.yaml b/Documentation/devicetree/bindings/arm/realtek.yaml index 845f9c76d6f7..0b388016bbcd 100644 --- a/Documentation/devicetree/bindings/arm/realtek.yaml +++ b/Documentation/devicetree/bindings/arm/realtek.yaml @@ -14,21 +14,21 @@ properties: const: '/' compatible: oneOf: - # RTD1195 SoC based boards - - items: + - description: RTD1195 SoC based boards +items: - enum: - mele,x1000 # MeLE X1000 - realtek,horseradish # Realtek Horseradish EVB - const: realtek,rtd1195 - # RTD1293 SoC based boards - - items: + - description: RTD1293 SoC based boards +items: - enum: - synology,ds418j # Synology DiskStation DS418j - const: realtek,rtd1293 - # RTD1295 SoC based boards - - items: + - description: RTD1295 SoC based boards +items: - enum: - mele,v9 # MeLE V9 - probox2,ava # ProBox2 AVA @@ -36,21 +36,21 @@ properties: - zidoo,x9s # Zidoo X9S - const: realtek,rtd1295 - # RTD1296 SoC based boards - - items: + - description: RTD1296 SoC based boards +items: - enum: - synology,ds418 # Synology DiskStation DS418 - const: realtek,rtd1296 - # RTD1395 SoC based boards - - items: + - description: RTD1395 SoC based boards +items: - enum: - bananapi,bpi-m4 # Banana Pi BPI-M4 - realtek,lion-skin # Realtek Lion Skin EVB - const: realtek,rtd1395 - # RTD1619 SoC based boards - - items: + - description: RTD1619 SoC based boards +items: - enum: - realtek,mjolnir # Realtek Mjolnir EVB - const: realtek,rtd1619 -- 2.26.2
[PATCH v4 0/3] arm64: dts: realtek: Initial RTD1319 and Pym Particles support
Hello, This patch series adds initial Device Trees for Realtek RTD1319 SoC and Realtek Pym Particles EVB. This v4 is an update of James' v3, incorporating pending review comments. Upstreaming progress being tracked at: https://en.opensuse.org/HCL:Realtek_DHC Latest experimental patches at: https://github.com/afaerber/linux/commits/rtd1295-next Have a lot of fun! Cheers, Andreas v3 -> v4: * Updated Realtek copyright for files changed in v3 * Updated PMU compatible (Robin) * Changed compatible, renamed .dts * Updated bindings schema and prepended refactoring Cc: devicet...@vger.kernel.org Cc: Rob Herring Cc: James Tai Andreas Färber (1): dt-bindings: arm: realtek: Convert comments to descriptions James Tai (2): dt-bindings: arm: realtek: Document RTD1319 and Realtek Pym Particles EVB arm64: dts: realtek: Add RTD1319 SoC and Realtek Pym Particles EVB .../devicetree/bindings/arm/realtek.yaml | 30 ++- arch/arm64/boot/dts/realtek/Makefile | 2 + .../boot/dts/realtek/rtd1319-pymparticles.dts | 43 arch/arm64/boot/dts/realtek/rtd1319.dtsi | 12 + arch/arm64/boot/dts/realtek/rtd13xx.dtsi | 213 ++ 5 files changed, 288 insertions(+), 12 deletions(-) create mode 100644 arch/arm64/boot/dts/realtek/rtd1319-pymparticles.dts create mode 100644 arch/arm64/boot/dts/realtek/rtd1319.dtsi create mode 100644 arch/arm64/boot/dts/realtek/rtd13xx.dtsi -- 2.26.2
Re: [PATCH v2 1/5] dt-bindings: arm: Initial MStar vendor prefixes and compatible strings
+ linux-mediatek Am 10.06.20 um 11:03 schrieb Daniel Palmer: diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index ef6d75b9113a..1770fc794027 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml [...] @@ -678,6 +680,8 @@ patternProperties: description: Microsemi Corporation "^msi,.*": description: Micro-Star International Co. Ltd. + "^mstar,.*": +description: MStar Semiconductor, Inc. Depending on what exactly its legal status is these days (https://en.wikipedia.org/wiki/MStar), you might either follow the below MIPS example of describing it as "MediaTek Inc. (formerly MStar Semiconductor, Inc.)", or you might extend above description as "MStar Semiconductor, Inc. (acquired by MediaTek Inc.)" if it still exists. Or accordingly "Xiamen Xingchen Technology Co., Ltd. (formerly MStar Semiconductor, Inc.)" if it was renamed to Sigmastar (in which case you might additionally reserve sstar prefix for Sigmastar while at it). http://www.sigmastarsemi.com/en/enterprisenews/info.aspx?itemid=441 "^mti,.*": description: Imagination Technologies Ltd. (formerly MIPS Technologies Inc.) "^multi-inno,.*": [...] diff --git a/MAINTAINERS b/MAINTAINERS index 77a3fa5e3edd..1ca77f97b8ee 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2110,6 +2110,12 @@ L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S:Maintained F:arch/arm/mach-pxa/mioa701.c +ARM/MStar/Sigmastar ARMv7 SoC support Here you do mention Sigmastar. +M: Daniel Palmer +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +S: Maintained +F: Documentation/devicetree/bindings/arm/mstar.yaml + ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT M:Michael Petchkovsky S:Maintained Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Re: [PATCH v2 3/5] ARM: mstar: Add infinity/mercury series dtsi
Hi, Am 11.06.20 um 16:19 schrieb Daniel Palmer: On Thu, 11 Jun 2020 at 22:39, Andreas Färber wrote: diff --git a/arch/arm/boot/dts/mstar-v7.dtsi b/arch/arm/boot/dts/mstar-v7.dtsi new file mode 100644 index ..0fccc4ca52a4 --- /dev/null +++ b/arch/arm/boot/dts/mstar-v7.dtsi So this is the only file starting with mstar. Have you thought about prefixing infinity/mercury, so that they're grouped together? I have been thinking about that. I didn't see any other dts in arm that had the vendor as a prefix though. With arm64 everything is in per vendor subdirectories to achieve the same thing. qcom- and arm- are examples. Admittedly outliers, but for a new target you don't have all the historical backwards-compatibility baggage. The downside would be if someone wanted to add newer sstar chips under the new name later, then they wouldn't be grouped with predecessor families. Right now it seems like mercury and infinity are not that different, so I figured it might be useful for people contributing patches to see that changes in one might require review of the other. Cheers, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Re: [PATCH v2 2/5] ARM: mstar: Add machine for MStar/Sigmastar infinity/mercury family ARMv7 SoCs
Hi Daniel, Am 11.06.20 um 15:01 schrieb Daniel Palmer: On Thu, 11 Jun 2020 at 21:49, Andreas Färber wrote: peripherals and system memory in a single tiny QFN package that can be hand soldered allowing almost anyone to embed Linux "soldered, allowing"? The original reads ok to me. Maybe I can just split that into two sentences? Like ".. QFN package that can be hand soldered. This allows almost anyone..". As non-native speaker I merely wondered whether a comma should better be inserted to separate the two parts of the sentence. Splitting it in two or leaving as is should be fine, too - I assume you're a native speaker. Most people will rather read the bindings document than old git history, so you might want to consider adding such a description below its title. --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2114,6 +2114,7 @@ ARM/MStar/Sigmastar ARMv7 SoC support M: Daniel Palmer L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Maintained +F: arch/arm/mach-mstar/ F: Documentation/devicetree/bindings/arm/mstar.yaml ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT [snip] The sort order has recently been changed to case-sensitive, i.e., you should append arch after Documentation. Interesting. Checkpatch didn't complain about that although it complained about the original ordering I had. I only noticed because someone refactored my Realtek section, causing a merge conflict. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3b50142d8528e1efc1c07f69c540f926c58ab3ad Which reminds me, in 1/5 you should probably add a W: line (after S: according to above sort commit) pointing to your http://linux-chenxing.org/ website. And for the community following your project, you may want to set up a linux-chenxing mailing list on vger.kernel.org or on infradead.org and add it as L:, to allow for error reports and patches to not just go to you and crowded LAKML. Cheers, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Re: [PATCH v2 5/5] ARM: mstar: Add dts for 70mai midrive d08
BTW I think the subject convention has been "ARM: dts: ...", with "ARM:
mstar: ..." more for mach-mstar.
Am 10.06.20 um 11:04 schrieb Daniel Palmer:
Adds inital support for the 70mai midrive d08 dash camera.
Signed-off-by: Daniel Palmer
---
arch/arm/boot/dts/Makefile| 3 ++-
.../boot/dts/mercury5-ssc8336n-midrive08.dts | 25 +++
2 files changed, 27 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/mercury5-ssc8336n-midrive08.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4a5f8075a4f6..35c7ecc52c60 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1344,7 +1344,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
dtb-$(CONFIG_ARCH_MILBEAUT) += milbeaut-m10v-evb.dtb
dtb-$(CONFIG_ARCH_MSTARV7) += \
infinity-msc313-breadbee_crust.dtb \
- infinity3-msc313e-breadbee.dtb
+ infinity3-msc313e-breadbee.dtb \
+ mercury5-ssc8336n-midrive08.dtb
dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-ast2500-evb.dtb \
diff --git a/arch/arm/boot/dts/mercury5-ssc8336n-midrive08.dts
b/arch/arm/boot/dts/mercury5-ssc8336n-midrive08.dts
new file mode 100644
index ..4ee50ecf6ab1
--- /dev/null
+++ b/arch/arm/boot/dts/mercury5-ssc8336n-midrive08.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 thingy.jp.
+ * Author: Daniel Palmer
+ */
+
+/dts-v1/;
+#include "mercury5-ssc8336n.dtsi"
+
+/ {
+ model = "midrive d08";
Couldn't find this on their website. Should this be "70mai midrive ..."
or is "midrive" a different brand?
+ compatible = "70mai,midrived08", "mstar,mercury5";
Have you considered naming it "70mai,midrive-d08" for better
readability? (affects 1/5)
+
+ aliases {
+ serial0 = _uart;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+_uart {
+ status = "okay";
clock-frequency?
+};
Regards,
Andreas
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
Re: [PATCH v2 4/5] ARM: mstar: Add dts for msc313(e) based BreadBee boards
Am 10.06.20 um 11:04 schrieb Daniel Palmer:
BreadBee is an opensource development board based on the
MStar msc313(e) SoC.
Hardware details, schematics and so on can be found at:
https://github.com/breadbee/breadbee
Signed-off-by: Daniel Palmer
---
arch/arm/boot/dts/Makefile| 3 +++
.../dts/infinity-msc313-breadbee_crust.dts| 25 +++
.../boot/dts/infinity3-msc313e-breadbee.dts | 25 +++
3 files changed, 53 insertions(+)
create mode 100644 arch/arm/boot/dts/infinity-msc313-breadbee_crust.dts
create mode 100644 arch/arm/boot/dts/infinity3-msc313e-breadbee.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e6a1cac0bfc7..4a5f8075a4f6 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1342,6 +1342,9 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt8127-moose.dtb \
mt8135-evbp1.dtb
dtb-$(CONFIG_ARCH_MILBEAUT) += milbeaut-m10v-evb.dtb
+dtb-$(CONFIG_ARCH_MSTARV7) += \
+ infinity-msc313-breadbee_crust.dtb \
+ infinity3-msc313e-breadbee.dtb
dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-ast2500-evb.dtb \
diff --git a/arch/arm/boot/dts/infinity-msc313-breadbee_crust.dts
b/arch/arm/boot/dts/infinity-msc313-breadbee_crust.dts
new file mode 100644
index ..8a827c8fd8b2
--- /dev/null
+++ b/arch/arm/boot/dts/infinity-msc313-breadbee_crust.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 thingy.jp.
+ * Author: Daniel Palmer
+ */
+
+/dts-v1/;
+#include "infinity-msc313.dtsi"
+
+/ {
+ model = "breadbee-crust";
This is user-visible text, so "BreadBee Crust" or so?
+ compatible = "thingyjp,breadbee-crust", "mstar,infinity";
+
+ aliases {
+ serial0 = _uart;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+_uart {
+ status = "okay";
Might this be a more suited place for temporary clock-frequency? For
lack of clk driver it would seem to depend on the board's bootloader
pre-configuring it rather than being a default of the SoC.
+};
diff --git a/arch/arm/boot/dts/infinity3-msc313e-breadbee.dts
b/arch/arm/boot/dts/infinity3-msc313e-breadbee.dts
new file mode 100644
index ..423bb32e6b74
--- /dev/null
+++ b/arch/arm/boot/dts/infinity3-msc313e-breadbee.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 thingy.jp.
+ * Author: Daniel Palmer
+ */
+
+/dts-v1/;
+#include "infinity3-msc313e.dtsi"
+
+/ {
+ model = "breadbee";
Ditto, "BreadBee"?
+ compatible = "thingyjp,breadbee", "mstar,infinity3";
+
+ aliases {
+ serial0 = _uart;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+_uart {
+ status = "okay";
Ditto, clock-frequency?
+};
Regards,
Andreas
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
Re: [PATCH v2 3/5] ARM: mstar: Add infinity/mercury series dtsi
Hi,
Am 10.06.20 um 11:04 schrieb Daniel Palmer:
Adds initial dtsi for the base MStar ARMv7 SoCs, family dtsis for infinity
and mercury families, and then some chip level dtsis for chips in those
families.
Signed-off-by: Daniel Palmer
---
MAINTAINERS | 3 +
arch/arm/boot/dts/infinity-msc313.dtsi | 14 +
arch/arm/boot/dts/infinity.dtsi | 10
arch/arm/boot/dts/infinity3-msc313e.dtsi | 14 +
arch/arm/boot/dts/infinity3.dtsi | 10
arch/arm/boot/dts/mercury5-ssc8336n.dtsi | 14 +
arch/arm/boot/dts/mercury5.dtsi | 10
arch/arm/boot/dts/mstar-v7.dtsi | 71
8 files changed, 146 insertions(+)
Can you split this up into three parts for easier review?
create mode 100644 arch/arm/boot/dts/infinity-msc313.dtsi
create mode 100644 arch/arm/boot/dts/infinity.dtsi
create mode 100644 arch/arm/boot/dts/infinity3-msc313e.dtsi
create mode 100644 arch/arm/boot/dts/infinity3.dtsi
create mode 100644 arch/arm/boot/dts/mercury5-ssc8336n.dtsi
create mode 100644 arch/arm/boot/dts/mercury5.dtsi
create mode 100644 arch/arm/boot/dts/mstar-v7.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index 754521938303..839ae0250d3d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2114,6 +2114,9 @@ ARM/MStar/Sigmastar ARMv7 SoC support
M:Daniel Palmer
L:linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
S:Maintained
+F: arch/arm/boot/dts/infinity*.dtsi
+F: arch/arm/boot/dts/mercury*.dtsi
+F: arch/arm/boot/dts/mstar-v7.dtsi
Sort order wrt D.
F:arch/arm/mach-mstar/
F:Documentation/devicetree/bindings/arm/mstar.yaml
diff --git a/arch/arm/boot/dts/infinity-msc313.dtsi b/arch/arm/boot/dts/infinity-msc313.dtsi
new file mode 100644
index ..4eb522e6a75d
--- /dev/null
+++ b/arch/arm/boot/dts/infinity-msc313.dtsi
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0
DTs as hardware description should be dual-licensed as either MIT or
BSD-2-Clause, similar to the schema.
Also, elsewhere, for any code that might get reused for OpenOCD (e.g.,
clk drivers and low-level init like machine - 2/5) or other non-kernel
projects potentially incompatible with GPL-2.0-only, it would be useful
to use the -or-later version of the GPL for code sharing - if the
sources you used permit that.
+/*
+ * Copyright (c) 2019 thingy.jp.
2019-2020? Check elsewhere.
+ * Author: Daniel Palmer
+ */
+
+#include "infinity.dtsi"
+
+/ {
+ memory {
+ device_type = "memory";
+ reg = <0x2000 0x400>;
The memory node needs to become memory@2000 then.
+ };
I take it, this RAM is integrated? Maybe add some explanation of what
this file is
+};
diff --git a/arch/arm/boot/dts/infinity.dtsi b/arch/arm/boot/dts/infinity.dtsi
new file mode 100644
index ..25d379028689
--- /dev/null
+++ b/arch/arm/boot/dts/infinity.dtsi
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 thingy.jp.
+ * Author: Daniel Palmer
+ */
+
+#include "mstar-v7.dtsi"
+
+/ {
+};
What do you intend to add here? Is it really needed? (same below)
Pre-DT-Schema I used to add a compatible property in the .dtsi, to make
sure we have at least the SoC's, in case someone neglects to add one in
their board's .dts. With DT schema that's no longer valid (if enum/const
is required), but Linux would still work better with than without.
diff --git a/arch/arm/boot/dts/infinity3-msc313e.dtsi
b/arch/arm/boot/dts/infinity3-msc313e.dtsi
new file mode 100644
index ..d0c53153faad
--- /dev/null
+++ b/arch/arm/boot/dts/infinity3-msc313e.dtsi
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 thingy.jp.
+ * Author: Daniel Palmer
+ */
+
+#include "infinity3.dtsi"
+
+/ {
+ memory {
Ditto, unit address missing.
+ device_type = "memory";
+ reg = <0x2000 0x400>;
+ };
+};
diff --git a/arch/arm/boot/dts/infinity3.dtsi b/arch/arm/boot/dts/infinity3.dtsi
new file mode 100644
index ..cf5f18a07835
--- /dev/null
+++ b/arch/arm/boot/dts/infinity3.dtsi
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 thingy.jp.
+ * Author: Daniel Palmer
+ */
+
+#include "infinity.dtsi"
+
+/ {
+};
Don't you anticipate incompatibilities between infinity and infinity3,
i.e., things you don't want to inherit? Seems a bit optimistic. You can
of course overwrite properties, but deleting is more difficult.
diff --git a/arch/arm/boot/dts/mercury5-ssc8336n.dtsi
b/arch/arm/boot/dts/mercury5-ssc8336n.dtsi
new file mode 100644
index ..7513f903c838
--- /dev/null
+++ b/arch/arm/boot/dts/mercury5-ssc8336n.dtsi
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 thingy.jp.
+ * Author: Daniel Palmer
+ */
+
+#include "mercury5.dtsi"
+
+/ {
+ memory {
Unit
Re: [PATCH v2 2/5] ARM: mstar: Add machine for MStar/Sigmastar infinity/mercury family ARMv7 SoCs
Am 10.06.20 um 11:04 schrieb Daniel Palmer: diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 59fde2d598d8..e7f4ca060c0f 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -197,6 +197,7 @@ machine-$(CONFIG_ARCH_MXC) += imx machine-$(CONFIG_ARCH_MEDIATEK) += mediatek machine-$(CONFIG_ARCH_MILBEAUT) += milbeaut machine-$(CONFIG_ARCH_MXS)+= mxs +machine-$(CONFIG_ARCH_MSTARV7) += mstar machine-$(CONFIG_ARCH_NOMADIK)+= nomadik machine-$(CONFIG_ARCH_NPCM) += npcm machine-$(CONFIG_ARCH_NSPIRE) += nspire diff --git a/arch/arm/mach-mstar/Kconfig b/arch/arm/mach-mstar/Kconfig new file mode 100644 index ..6235d0a7860a --- /dev/null +++ b/arch/arm/mach-mstar/Kconfig @@ -0,0 +1,26 @@ +menuconfig ARCH_MSTARV7 You call the dir mach-mstar, but name the Kconfig ARCH_MSTARV7. I had previously been asked to just use the vendor name, so this should probably be just ARCH_MSTAR. Outside arch/arm/ you can then use ARM && ARCH_MSTAR condition to make things 32-bit only, allowing to reuse ARCH_MSTAR for arm64 or whatever. + bool "MStar/Sigmastar ARMv7 SoC Support" + depends on ARCH_MULTI_V7 + select ARM_GIC + select ARM_HEAVY_MB + help + Support for newer MStar/Sigmastar SoC families that are + based on ARMv7 cores like the Cortex A7 and share the same + basic hardware like the infinity and mercury series. + +if ARCH_MSTARV7 + +config MACH_INFINITY + bool "MStar/Sigmastar infinity SoC support" + default ARCH_MSTARV7 + help + Support for MStar/Sigmastar infinity IP camera SoCs. + +config MACH_MERCURY + bool "MStar/Sigmastar mercury SoC support" + default ARCH_MSTARV7 + help + Support for MStar/Sigmastar mercury dash camera SoCs. + Note that older Mercury2 SoCs are ARM9 based and not supported. Is this comment really helpful? This menu item would only seem to come up after having selected multi_v7, which kind of rules out ARM9. Consider adding mercury in a second step? + +endif Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Re: [PATCH v2 2/5] ARM: mstar: Add machine for MStar/Sigmastar infinity/mercury family ARMv7 SoCs
Am 10.06.20 um 11:04 schrieb Daniel Palmer: Initial support for the MStar/Sigmastar infinity/mercury series of ARMv7 based IP camera and dashcam SoCs. These chips are interesting in that they contain a Cortex A7, "Cortex-A7" peripherals and system memory in a single tiny QFN package that can be hand soldered allowing almost anyone to embed Linux "soldered, allowing"? in their projects. Signed-off-by: Daniel Palmer --- MAINTAINERS | 1 + arch/arm/Kconfig | 2 + arch/arm/Makefile | 1 + arch/arm/mach-mstar/Kconfig | 26 + arch/arm/mach-mstar/Makefile | 1 + arch/arm/mach-mstar/mstarv7.c | 72 +++ 6 files changed, 103 insertions(+) create mode 100644 arch/arm/mach-mstar/Kconfig create mode 100644 arch/arm/mach-mstar/Makefile create mode 100644 arch/arm/mach-mstar/mstarv7.c diff --git a/MAINTAINERS b/MAINTAINERS index 1ca77f97b8ee..754521938303 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2114,6 +2114,7 @@ ARM/MStar/Sigmastar ARMv7 SoC support M:Daniel Palmer L:linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S:Maintained +F: arch/arm/mach-mstar/ F:Documentation/devicetree/bindings/arm/mstar.yaml ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT [snip] The sort order has recently been changed to case-sensitive, i.e., you should append arch after Documentation. Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Re: [PATCH v2 1/5] dt-bindings: arm: Initial MStar vendor prefixes and compatible strings
Hi Daniel, Am 10.06.20 um 11:03 schrieb Daniel Palmer: Adds a prefixes for MStar, thingy.jp, 70mai and then defines compatible strings for the first MStar based boards. Signed-off-by: Daniel Palmer --- .../devicetree/bindings/arm/mstar.yaml| 30 +++ .../devicetree/bindings/vendor-prefixes.yaml | 6 MAINTAINERS | 6 3 files changed, 42 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/mstar.yaml diff --git a/Documentation/devicetree/bindings/arm/mstar.yaml b/Documentation/devicetree/bindings/arm/mstar.yaml new file mode 100644 index ..09e87cf6d6f0 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mstar.yaml @@ -0,0 +1,30 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/mstar.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MStar platforms device tree bindings + +maintainers: + - Daniel Palmer + +properties: + $nodename: +const: '/' + compatible: +oneOf: + - description: thingy.jp BreadBee +items: + - const: thingyjp,breadbee + - const: mstar,infinity3 + + - description: thingy.jp BreadBee Crust +items: + - const: thingyjp,breadbee-crust + - const: mstar,infinity + + - description: 70mai midrive d08 +items: + - const: 70mai,midrived08 + - const: mstar,mercury5 I would advise to restructure these three for forward planning: Use const only for the SoC compatible. For the boards use an enum with (for now) only the one entry. This affects the description, which may mislead people to duplicate these blocks for each board rather than just for each SoC family. Take a look at other existing files (e.g., my realtek.yaml and actions.yaml, but note they don't have the new-style description line yet - I assume it'll work the same in enum as in your oneOf). diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index ef6d75b9113a..1770fc794027 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -23,6 +23,8 @@ patternProperties: "^(simple-audio-card|simple-graph-card|st-plgpio|st-spics|ts),.*": true # Keep list in alphabetical order. + "^70mai,.*": +description: 70mai "70mai Co., Ltd." please - don't just repeat the prefix. "^abilis,.*": description: Abilis Systems "^abracon,.*": @@ -678,6 +680,8 @@ patternProperties: description: Microsemi Corporation "^msi,.*": description: Micro-Star International Co. Ltd. + "^mstar,.*": +description: MStar Semiconductor, Inc. "^mti,.*": description: Imagination Technologies Ltd. (formerly MIPS Technologies Inc.) "^multi-inno,.*": @@ -1030,6 +1034,8 @@ patternProperties: description: Three Five Corp "^thine,.*": description: THine Electronics, Inc. + "^thingyjp,.*": +description: thingy.jp "^ti,.*": description: Texas Instruments "^tianma,.*": If you split the vendor prefixes to a preceding patch, they have a chance of getting Reviewed-bys more quickly. You can then also CC the vendors on the prefixes you're assigning for them. diff --git a/MAINTAINERS b/MAINTAINERS index 77a3fa5e3edd..1ca77f97b8ee 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2110,6 +2110,12 @@ L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S:Maintained F:arch/arm/mach-pxa/mioa701.c +ARM/MStar/Sigmastar ARMv7 SoC support +M: Daniel Palmer +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +S: Maintained +F: Documentation/devicetree/bindings/arm/mstar.yaml + ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT M:Michael Petchkovsky S:Maintained In theory it's spelled Armv7 since 2017, but MAINTAINERS, subject prefix conventions and many other places in Linux still use the old upper-case spelling, too... Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Re: [PATCH 1/1] tty: serial: owl: Add support for kernel debugger
Hi,
Am 29.05.20 um 17:50 schrieb Cristian Ciocaltea:
Implement poll_put_char and poll_get_char callbacks in struct uart_ops
that enables OWL UART to be used for KGDB debugging over serial line.
Signed-off-by: Cristian Ciocaltea
---
drivers/tty/serial/owl-uart.c | 45 ++-
1 file changed, 39 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/owl-uart.c b/drivers/tty/serial/owl-uart.c
index c2fa2f15d50a..26dcc374dec5 100644
--- a/drivers/tty/serial/owl-uart.c
+++ b/drivers/tty/serial/owl-uart.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -20,13 +21,13 @@
#include
#include
-#define OWL_UART_PORT_NUM 7
-#define OWL_UART_DEV_NAME "ttyOWL"
+#define OWL_UART_PORT_NUM 7
+#define OWL_UART_DEV_NAME "ttyOWL"
-#define OWL_UART_CTL 0x000
-#define OWL_UART_RXDAT 0x004
-#define OWL_UART_TXDAT 0x008
-#define OWL_UART_STAT 0x00c
+#define OWL_UART_CTL 0x000
+#define OWL_UART_RXDAT 0x004
+#define OWL_UART_TXDAT 0x008
+#define OWL_UART_STAT 0x00c
Please do not unnecessarily re-indent kernel code. You can do so when
you're actually adding something new.
#define OWL_UART_CTL_DWLS_MASK GENMASK(1, 0)
#define OWL_UART_CTL_DWLS_5BITS (0x0 << 0)
@@ -461,6 +462,34 @@ static void owl_uart_config_port(struct uart_port *port,
int flags)
}
}
+#ifdef CONFIG_CONSOLE_POLL
+
+static int owl_uart_poll_get_char(struct uart_port *port)
+{
+ u32 c = NO_POLL_CHAR;
+
+ if (!(owl_uart_read(port, OWL_UART_STAT) & OWL_UART_STAT_RFEM))
+ c = owl_uart_read(port, OWL_UART_RXDAT);
+
+ return c;
+}
+
+static void owl_uart_poll_put_char(struct uart_port *port, unsigned char c)
+{
+ /* Wait while TX FIFO is full */
+ while (owl_uart_read(port, OWL_UART_STAT) & OWL_UART_STAT_TFFU)
+ cpu_relax();
+
+ /* Send the character out */
+ owl_uart_write(port, c, OWL_UART_TXDAT);
+
+ /* Wait for transmitter to become empty */
+ while (owl_uart_read(port, OWL_UART_STAT) & OWL_UART_STAT_TRFL_MASK)
+ cpu_relax();
+}
How is this different from earlycon? I dislike that this is being
open-coded. Please try to reuse existing functions for this.
Regards,
Andreas
+
+#endif /* CONFIG_CONSOLE_POLL */
+
static const struct uart_ops owl_uart_ops = {
.set_mctrl = owl_uart_set_mctrl,
.get_mctrl = owl_uart_get_mctrl,
@@ -476,6 +505,10 @@ static const struct uart_ops owl_uart_ops = {
.request_port = owl_uart_request_port,
.release_port = owl_uart_release_port,
.verify_port = owl_uart_verify_port,
+#ifdef CONFIG_CONSOLE_POLL
+ .poll_get_char = owl_uart_poll_get_char,
+ .poll_put_char = owl_uart_poll_put_char,
+#endif
};
#ifdef CONFIG_SERIAL_OWL_CONSOLE
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
Re: [PATCH 1/1] tty: serial: owl: Initialize lock before registering port
Am 29.05.20 um 13:34 schrieb Greg Kroah-Hartman:
On Fri, May 29, 2020 at 02:06:47PM +0300, Cristian Ciocaltea wrote:
Running a lockdep-enabled kernel leads to the following splat when
probing the owl-uart driver:
[1.271784] b0124000.serial: ttyOWL2 at MMIO 0xb0124000 (irq = 22, base_baud
= 150) is a owl-uart
[1.281226] INFO: trying to register non-static key.
[1.286179] the code is fine but needs lockdep annotation.
[1.291648] turning off the locking correctness validator.
[1.297125] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc7+ #70
[1.303462] Hardware name: Generic DT based system
[1.308268] [<80111d3c>] (unwind_backtrace) from [<8010c9b8>]
(show_stack+0x10/0x14)
[1.316003] [<8010c9b8>] (show_stack) from [<805016b4>]
(dump_stack+0xb4/0xe0)
[1.323218] [<805016b4>] (dump_stack) from [<80182dec>]
(register_lock_class+0x25c/0x8f4)
[1.331391] [<80182dec>] (register_lock_class) from [<8017ee34>]
(__lock_acquire+0xb4/0x2ee4)
[1.339901] [<8017ee34>] (__lock_acquire) from [<8018291c>]
(lock_acquire+0x424/0x4c8)
[1.347813] [<8018291c>] (lock_acquire) from [<808597b0>]
(_raw_spin_lock_irqsave+0x54/0x68)
[1.356242] [<808597b0>] (_raw_spin_lock_irqsave) from [<80582e94>]
(uart_add_one_port+0x384/0x510)
[1.365276] [<80582e94>] (uart_add_one_port) from [<8058b4d0>]
(owl_uart_probe+0x1bc/0x248)
[1.373621] [<8058b4d0>] (owl_uart_probe) from [<8059c0e4>]
(platform_drv_probe+0x48/0x94)
[1.381874] [<8059c0e4>] (platform_drv_probe) from [<805997c4>]
(really_probe+0x200/0x470)
[1.390123] [<805997c4>] (really_probe) from [<80599c80>]
(driver_probe_device+0x16c/0x1bc)
[1.398461] [<80599c80>] (driver_probe_device) from [<80599f18>]
(device_driver_attach+0x44/0x60)
[1.407317] [<80599f18>] (device_driver_attach) from [<8059a078>]
(__driver_attach+0x144/0x14c)
[1.416000] [<8059a078>] (__driver_attach) from [<805978ac>]
(bus_for_each_dev+0x5c/0xb4)
[1.424162] [<805978ac>] (bus_for_each_dev) from [<8059896c>]
(bus_add_driver+0x118/0x204)
[1.432410] [<8059896c>] (bus_add_driver) from [<8059ae6c>]
(driver_register+0xbc/0xf8)
[1.440405] [<8059ae6c>] (driver_register) from [<80c1fd24>]
(owl_uart_init+0x20/0x40)
[1.448313] [<80c1fd24>] (owl_uart_init) from [<801021d8>]
(do_one_initcall+0x184/0x3a4)
[1.456399] [<801021d8>] (do_one_initcall) from [<80c01100>]
(kernel_init_freeable+0x264/0x2e4)
[1.465085] [<80c01100>] (kernel_init_freeable) from [<80850a88>]
(kernel_init+0x8/0x110)
[1.473249] [<80850a88>] (kernel_init) from [<80100114>]
(ret_from_fork+0x14/0x20)
[1.480800] Exception stack(0xee8bdfb0 to 0xee8bdff8)
[1.485841] dfa0:
[1.494002] dfc0:
[1.502162] dfe0: 0013
[1.508914] printk: console [ttyOWL2] enabled
The locking issue occurs in uart_configure_port() when trying to
guard the call to set_mctrl().
uart_add_one_port() should normally initialize the spinlock via
uart_port_spin_lock_init(), but it never happens because the port is
detected as a console and, as a consequence, the spinlock is expected
to be already initialized.
The commit a3cb39d258ef
("serial: core: Allow detach and attach serial device for console")
changed the lock initialization logic to assume the spinlock is
initialized even if the console is not enabled.
Therefore, initialize the lock explicitly in owl_uart_probe(), before
attempting to invoke uart_add_one_port().
Fixes: a3cb39d258ef ("serial: core: Allow detach and attach serial device for
console")
Signed-off-by: Cristian Ciocaltea
---
drivers/tty/serial/owl-uart.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/owl-uart.c b/drivers/tty/serial/owl-uart.c
index c149f8c30007..c2fa2f15d50a 100644
--- a/drivers/tty/serial/owl-uart.c
+++ b/drivers/tty/serial/owl-uart.c
@@ -705,6 +705,8 @@ static int owl_uart_probe(struct platform_device *pdev)
owl_uart_ports[pdev->id] = owl_port;
platform_set_drvdata(pdev, owl_port);
+ spin_lock_init(_port->port.lock);
+
ret = uart_add_one_port(_uart_driver, _port->port);
if (ret)
owl_uart_ports[pdev->id] = NULL;
Ugh, another one :(
Thanks for this, will queue this up now.
Thanks. If this is the expected pattern now, I'll also have to update
in-flight patches, such as Sunplus.
Regards,
Andreas
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
Re: [PATCH v5 2/3] dt-bindings: arm: actions: Document Caninos Loucos Labrador
Hi, Am 25.05.20 um 03:30 schrieb Matheus Castello: Update the documentation to add the Caninos Loucos Labrador. Labrador project consists of a computer on module based on the Actions Semi S500 processor and the Labrador base board. Signed-off-by: Matheus Castello Acked-by: Rob Herring --- Documentation/devicetree/bindings/arm/actions.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/actions.yaml b/Documentation/devicetree/bindings/arm/actions.yaml index ace3fdaa8396..2187e1c5bc73 100644 --- a/Documentation/devicetree/bindings/arm/actions.yaml +++ b/Documentation/devicetree/bindings/arm/actions.yaml @@ -19,6 +19,11 @@ properties: - allo,sparky # Allo.com Sparky - cubietech,cubieboard6 # Cubietech CubieBoard6 - const: actions,s500 + - items: + - enum: + - caninos,labrador-v2 # Labrador Core v2 + - caninos,labrador-base-m # Labrador Base Board M v1 This enum still strikes me as wrong, it means either-or. (Was planning to look into it myself, but no time yet...) caninos,labrador-v2 should be a const one level down: board, SoM, SoC from most specific to most generic. Compare Guitar below. + - const: actions,s500 - items: - enum: - lemaker,guitar-bb-rev-b # LeMaker Guitar Base Board rev. B Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Re: [PATCH v2 02/15] ARM: actions: Drop unneeded select of COMMON_CLK
Hi Geert, Am 05.05.20 um 17:07 schrieb Geert Uytterhoeven: Support for Actions Semi SoCs depends on ARCH_MULTI_V7, and thus on ARCH_MULTIPLATFORM. As the latter selects COMMON_CLK, there is no need for ARCH_ACTIONS to select COMMON_CLK. Signed-off-by: Geert Uytterhoeven Cc: Andreas Färber Cc: Manivannan Sadhasivam Acked-by: Arnd Bergmann Reviewed-by: Andreas Färber --- v2: - Add Acked-by, Reviewed-by. --- arch/arm/mach-actions/Kconfig | 1 - 1 file changed, 1 deletion(-) Do you intend to apply the whole series through soc (my assumption due to soc in To), or should I pick this one up as maintainer? Thanks, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Re: [PATCH v3 1/1] dma: actions: Fix lockdep splat for owl-dma
Am 29.04.20 um 17:28 schrieb Cristian Ciocaltea:
When the kernel is built with lockdep support and the owl-dma driver is
used, the following message is shown:
[2.496939] INFO: trying to register non-static key.
[2.501889] the code is fine but needs lockdep annotation.
[2.507357] turning off the locking correctness validator.
[2.512834] CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.6.3+ #15
[2.519084] Hardware name: Generic DT based system
[2.523878] Workqueue: events_freezable mmc_rescan
[2.528681] [<801127f0>] (unwind_backtrace) from [<8010da58>]
(show_stack+0x10/0x14)
[2.536420] [<8010da58>] (show_stack) from [<8080fbe8>]
(dump_stack+0xb4/0xe0)
[2.543645] [<8080fbe8>] (dump_stack) from [<8017efa4>]
(register_lock_class+0x6f0/0x718)
[2.551816] [<8017efa4>] (register_lock_class) from [<8017b7d0>]
(__lock_acquire+0x78/0x25f0)
[2.560330] [<8017b7d0>] (__lock_acquire) from [<8017e5e4>]
(lock_acquire+0xd8/0x1f4)
[2.568159] [<8017e5e4>] (lock_acquire) from [<80831fb0>]
(_raw_spin_lock_irqsave+0x3c/0x50)
[2.576589] [<80831fb0>] (_raw_spin_lock_irqsave) from [<8051b5fc>]
(owl_dma_issue_pending+0xbc/0x120)
[2.585884] [<8051b5fc>] (owl_dma_issue_pending) from [<80668cbc>]
(owl_mmc_request+0x1b0/0x390)
[2.594655] [<80668cbc>] (owl_mmc_request) from [<80650ce0>]
(mmc_start_request+0x94/0xbc)
[2.602906] [<80650ce0>] (mmc_start_request) from [<80650ec0>]
(mmc_wait_for_req+0x64/0xd0)
[2.611245] [<80650ec0>] (mmc_wait_for_req) from [<8065aa10>]
(mmc_app_send_scr+0x10c/0x144)
[2.619669] [<8065aa10>] (mmc_app_send_scr) from [<80659b3c>]
(mmc_sd_setup_card+0x4c/0x318)
[2.628092] [<80659b3c>] (mmc_sd_setup_card) from [<80659f0c>]
(mmc_sd_init_card+0x104/0x430)
[2.636601] [<80659f0c>] (mmc_sd_init_card) from [<8065a3e0>]
(mmc_attach_sd+0xcc/0x16c)
[2.644678] [<8065a3e0>] (mmc_attach_sd) from [<8065301c>]
(mmc_rescan+0x3ac/0x40c)
[2.652332] [<8065301c>] (mmc_rescan) from [<80143244>]
(process_one_work+0x2d8/0x780)
[2.660239] [<80143244>] (process_one_work) from [<80143730>]
(worker_thread+0x44/0x598)
[2.668323] [<80143730>] (worker_thread) from [<8014b5f8>]
(kthread+0x148/0x150)
[2.675708] [<8014b5f8>] (kthread) from [<801010b4>]
(ret_from_fork+0x14/0x20)
[2.682912] Exception stack(0xee8fdfb0 to 0xee8fdff8)
[2.687954] dfa0:
[2.696118] dfc0:
[2.704277] dfe0: 0013
The obvious fix would be to use 'spin_lock_init()' on 'pchan->lock'
before attempting to call 'spin_lock_irqsave()' in 'owl_dma_get_pchan()'.
However, according to Manivannan Sadhasivam, 'pchan->lock' was supposed
to only protect 'pchan->vchan' while 'od->lock' does a similar job in
'owl_dma_terminate_pchan'.
Therefore, this patch will simply substitute 'pchan->lock' with 'od->lock'
and removes the 'lock' attribute in 'owl_dma_pchan' struct.
Please add:
Fixes: 47e20577c24d ("dmaengine: Add Actions Semi Owl family S900 DMA
driver")
Signed-off-by: Cristian Ciocaltea
Reviewed-by: Manivannan Sadhasivam
---
Changes in v3:
* Get rid of the kerneldoc comment for the removed struct attribute
* Add the Reviewed-by tag in the commit message
Changes in v2:
* Improve the fix as suggested by Manivannan Sadhasivam: substitute
'pchan->lock' with 'od->lock' and get rid of the 'lock' attribute in
'owl_dma_pchan' struct
* Update the commit message to reflect the changes
drivers/dma/owl-dma.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
Otherwise no objections from my side,
Acked-by: Andreas Färber
Maybe the DMA maintainers can add those two lines when picking it up, to
avoid a v4?
Regards,
Andreas
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
Re: [PATCH 1/1] dma: actions: Fix lockdep splat for owl-dma
Am 28.04.20 um 20:18 schrieb Manivannan Sadhasivam: On Tue, Apr 28, 2020 at 09:11:15PM +0300, Cristian Ciocaltea wrote: On Tue, Apr 28, 2020 at 10:19:21PM +0530, Manivannan Sadhasivam wrote: On Tue, Apr 28, 2020 at 01:56:12PM +0300, Cristian Ciocaltea wrote: When the kernel is build with lockdep support and the owl-dma driver is used, the following message is shown: [...] The required fix is to use spin_lock_init() on the pchan lock before attempting to call any spin_lock_irqsave() in owl_dma_get_pchan(). Right, this is a bug. But while looking at the code now, I feel that we don't need 'pchan->lock'. The idea was to protect 'pchan->vchan', but I think 'od->lock' is the better candidate for that since it already protects it in 'owl_dma_terminate_pchan'. So I'd be happy if you remove the lock from 'pchan' and just directly use the one in 'od'. Out of curiosity, on which platform you're testing this? Totally agree, I will send a new patch revision as soon as I do some more testing. Coo[l], thanks! I'm currently experimenting on an Actions S500 based board (Roseapple Pi) trying to extend, if possible, the existing mainline support for those SoCs. Awesome! It's great to see that Actions platform is seeing some attention these days :) I don't have much progress so far, since I started quite recently and I also lack experience in the kernel development area, but I do my best to come back with more patches once I get a consistent functionality. No worries. Feel free to reach out to me if you have any questions. There is a lot of work to do and for sure it will be a good learning curve. We do have an IRC channel (##linux-actions) for quick discussions. Fee[l] free to join! Please also CC the linux-actions mailing list on any patches: https://lists.infradead.org/mailman/listinfo/linux-actions Mani, do you have a 5.7-rc1 tree set up or should I queue patches this round? It still seems missing in MAINTAINERS, and then there's Matheus' patches in review. Thanks, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
[PATCH v2 02/11] dt-bindings: reset: Add Realtek RTD1195
Add a header with symbolic reset indices for Realtek RTD1195 SoC. Naming was derived from BSP register description headers. Signed-off-by: Andreas Färber --- v2: New include/dt-bindings/reset/realtek,rtd1195.h | 74 + 1 file changed, 74 insertions(+) create mode 100644 include/dt-bindings/reset/realtek,rtd1195.h diff --git a/include/dt-bindings/reset/realtek,rtd1195.h b/include/dt-bindings/reset/realtek,rtd1195.h new file mode 100644 index ..27902abf935b --- /dev/null +++ b/include/dt-bindings/reset/realtek,rtd1195.h @@ -0,0 +1,74 @@ +/* SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) */ +/* + * Realtek RTD1195 reset controllers + * + * Copyright (c) 2017 Andreas Färber + */ +#ifndef DT_BINDINGS_RESET_RTD1195_H +#define DT_BINDINGS_RESET_RTD1195_H + +/* soft reset 1 */ +#define RTD1195_RSTN_MISC 0 +#define RTD1195_RSTN_RNG 1 +#define RTD1195_RSTN_USB3_POW 2 +#define RTD1195_RSTN_GSPI 3 +#define RTD1195_RSTN_USB3_P0_MDIO 4 +#define RTD1195_RSTN_VE_H265 5 +#define RTD1195_RSTN_USB 6 +#define RTD1195_RSTN_USB_PHY0 8 +#define RTD1195_RSTN_USB_PHY1 9 +#define RTD1195_RSTN_HDMIRX11 +#define RTD1195_RSTN_HDMI 12 +#define RTD1195_RSTN_ETN 14 +#define RTD1195_RSTN_AIO 15 +#define RTD1195_RSTN_GPU 16 +#define RTD1195_RSTN_VE_H264 17 +#define RTD1195_RSTN_VE_JPEG 18 +#define RTD1195_RSTN_TVE 19 +#define RTD1195_RSTN_VO20 +#define RTD1195_RSTN_LVDS 21 +#define RTD1195_RSTN_SE22 +#define RTD1195_RSTN_DCU 23 +#define RTD1195_RSTN_DC_PHY24 +#define RTD1195_RSTN_CP25 +#define RTD1195_RSTN_MD26 +#define RTD1195_RSTN_TP27 +#define RTD1195_RSTN_AE28 +#define RTD1195_RSTN_NF29 +#define RTD1195_RSTN_MIPI 30 + +/* soft reset 2 */ +#define RTD1195_RSTN_ACPU 0 +#define RTD1195_RSTN_VCPU 1 +#define RTD1195_RSTN_PCR 9 +#define RTD1195_RSTN_CR10 +#define RTD1195_RSTN_EMMC 11 +#define RTD1195_RSTN_SDIO 12 +#define RTD1195_RSTN_I2C_5 18 +#define RTD1195_RSTN_RTC 20 +#define RTD1195_RSTN_I2C_4 23 +#define RTD1195_RSTN_I2C_3 24 +#define RTD1195_RSTN_I2C_2 25 +#define RTD1195_RSTN_I2C_1 26 +#define RTD1195_RSTN_UR1 28 + +/* soft reset 3 */ +#define RTD1195_RSTN_SB2 0 + +/* iso soft reset */ +#define RTD1195_ISO_RSTN_VFD 0 +#define RTD1195_ISO_RSTN_IR1 +#define RTD1195_ISO_RSTN_CEC0 2 +#define RTD1195_ISO_RSTN_CEC1 3 +#define RTD1195_ISO_RSTN_DP4 +#define RTD1195_ISO_RSTN_CBUSTX5 +#define RTD1195_ISO_RSTN_CBUSRX6 +#define RTD1195_ISO_RSTN_EFUSE 7 +#define RTD1195_ISO_RSTN_UR0 8 +#define RTD1195_ISO_RSTN_GMAC 9 +#define RTD1195_ISO_RSTN_GPHY 10 +#define RTD1195_ISO_RSTN_I2C_0 11 +#define RTD1195_ISO_RSTN_I2C_6 12 +#define RTD1195_ISO_RSTN_CBUS 13 + +#endif -- 2.16.4
[PATCH v2 10/11] arm64: dts: realtek: Adopt RTD129x reset constants
Replace reset controller indices with constants.
Signed-off-by: Andreas Färber
---
v1 -> v2: Unchanged
arch/arm64/boot/dts/realtek/rtd129x.dtsi | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi
b/arch/arm64/boot/dts/realtek/rtd129x.dtsi
index 15d321d9515c..4433114476f5 100644
--- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi
+++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi
@@ -12,6 +12,7 @@
/memreserve/ 0x01ffe000 0x4000;
#include
+#include
/ {
interrupt-parent = <>;
@@ -79,7 +80,7 @@
reg-shift = <2>;
reg-io-width = <4>;
clock-frequency = <2700>;
- resets = <_reset 8>;
+ resets = <_reset RTD1295_ISO_RSTN_UR0>;
status = "disabled";
};
@@ -89,7 +90,7 @@
reg-shift = <2>;
reg-io-width = <4>;
clock-frequency = <43200>;
- resets = < 28>;
+ resets = < RTD1295_RSTN_UR1>;
status = "disabled";
};
@@ -99,7 +100,7 @@
reg-shift = <2>;
reg-io-width = <4>;
clock-frequency = <43200>;
- resets = < 27>;
+ resets = < RTD1295_RSTN_UR2>;
status = "disabled";
};
--
2.16.4
[PATCH v2 06/11] arm64: dts: realtek: Add RTD129x reset controller nodes
Add nodes for the Realtek RTD1295 reset controllers.
Signed-off-by: Andreas Färber
---
v1 -> v2:
* Rebased, moved from rtd1295.dtsi to rtd129x.dtsi
arch/arm64/boot/dts/realtek/rtd129x.dtsi | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi
b/arch/arm64/boot/dts/realtek/rtd129x.dtsi
index 0b2ac0c33b8b..282ab8bfaad1 100644
--- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi
+++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi
@@ -37,6 +37,36 @@
/* Exclude up to 2 GiB of RAM */
ranges = <0x8000 0x8000 0x8000>;
+ reset1: reset-controller@9800 {
+ compatible = "snps,dw-low-reset";
+ reg = <0x9800 0x4>;
+ #reset-cells = <1>;
+ };
+
+ reset2: reset-controller@9804 {
+ compatible = "snps,dw-low-reset";
+ reg = <0x9804 0x4>;
+ #reset-cells = <1>;
+ };
+
+ reset3: reset-controller@9808 {
+ compatible = "snps,dw-low-reset";
+ reg = <0x9808 0x4>;
+ #reset-cells = <1>;
+ };
+
+ reset4: reset-controller@9850 {
+ compatible = "snps,dw-low-reset";
+ reg = <0x9850 0x4>;
+ #reset-cells = <1>;
+ };
+
+ iso_reset: reset-controller@98007088 {
+ compatible = "snps,dw-low-reset";
+ reg = <0x98007088 0x4>;
+ #reset-cells = <1>;
+ };
+
wdt: watchdog@98007680 {
compatible = "realtek,rtd1295-watchdog";
reg = <0x98007680 0x100>;
--
2.16.4
[PATCH v2 03/11] reset: simple: Keep alphabetical order
Restore alphabetical order for Kconfig dependencies and help text.
Compatibles got out of order too, but no functional change done here.
Goal is to make it obvious where to add new platforms.
Fixes: 64c47b624f64 ("reset: Add reset controller support for BM1880 SoC")
Fixes: 1d7592f84f92 ("reset: simple: Enable for ASPEED systems")
Fixes: 96a2f50305d1 ("reset: build simple reset controller driver for Agilex")
Cc: Philipp Zabel
Signed-off-by: Andreas Färber
---
v2: New (prepares for following patch extending it to Realtek)
drivers/reset/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 46f7986c3587..fac356a9b818 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -129,7 +129,7 @@ config RESET_SCMI
config RESET_SIMPLE
bool "Simple Reset Controller Driver" if COMPILE_TEST
- default ARCH_STM32 || ARCH_STRATIX10 || ARCH_SUNXI || ARCH_ZX ||
ARCH_ASPEED || ARCH_BITMAIN || ARC || ARCH_AGILEX
+ default ARCH_AGILEX || ARCH_ASPEED || ARCH_BITMAIN || ARCH_STM32 ||
ARCH_STRATIX10 || ARCH_SUNXI || ARCH_ZX || ARC
help
This enables a simple reset controller driver for reset lines that
that can be asserted and deasserted by toggling bits in a contiguous,
@@ -138,10 +138,10 @@ config RESET_SIMPLE
Currently this driver supports:
- Altera SoCFPGAs
- ASPEED BMC SoCs
+ - Bitmain BM1880 SoC
- RCC reset controller in STM32 MCUs
- Allwinner SoCs
- ZTE's zx2967 family
- - Bitmain BM1880 SoC
config RESET_STM32MP157
bool "STM32MP157 Reset Driver" if COMPILE_TEST
--
2.16.4
[PATCH v2 05/11] arm64: realtek: Select reset controller
Select RESET_CONTROLLER for ARCH_REALTEK. Signed-off-by: Andreas Färber --- v2: New arch/arm64/Kconfig.platforms | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 63b463b88040..90d3c04ebff0 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -189,6 +189,7 @@ config ARCH_QCOM config ARCH_REALTEK bool "Realtek Platforms" + select RESET_CONTROLLER help This enables support for the ARMv8 based Realtek chipsets, like the RTD1295. -- 2.16.4
[PATCH v2 04/11] reset: simple: Add Realtek RTD1195/RTD1295
Enable RESET_SIMPLE for ARCH_REALTEK. They can reuse the DesignWare bindings to avoid a new compatible. Signed-off-by: Andreas Färber --- v1 -> v2: * Instead of adding a new driver, reuse reset-simple (Philipp) drivers/reset/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index fac356a9b818..3ad7817ce1f0 100644 --- a/drivers/reset/Kconfig +++ b/drivers/reset/Kconfig @@ -129,7 +129,7 @@ config RESET_SCMI config RESET_SIMPLE bool "Simple Reset Controller Driver" if COMPILE_TEST - default ARCH_AGILEX || ARCH_ASPEED || ARCH_BITMAIN || ARCH_STM32 || ARCH_STRATIX10 || ARCH_SUNXI || ARCH_ZX || ARC + default ARCH_AGILEX || ARCH_ASPEED || ARCH_BITMAIN || ARCH_REALTEK || ARCH_STM32 || ARCH_STRATIX10 || ARCH_SUNXI || ARCH_ZX || ARC help This enables a simple reset controller driver for reset lines that that can be asserted and deasserted by toggling bits in a contiguous, @@ -139,6 +139,7 @@ config RESET_SIMPLE - Altera SoCFPGAs - ASPEED BMC SoCs - Bitmain BM1880 SoC + - Realtek SoCs - RCC reset controller in STM32 MCUs - Allwinner SoCs - ZTE's zx2967 family -- 2.16.4
[PATCH v2 07/11] arm64: dts: realtek: Add RTD129x UART resets
Associate the UART nodes with the corresponding reset controller bits. Signed-off-by: Andreas Färber --- v1 -> v2: * Rebased, moved from rtd1295.dtsi to rtd129x.dtsi arch/arm64/boot/dts/realtek/rtd129x.dtsi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi b/arch/arm64/boot/dts/realtek/rtd129x.dtsi index 282ab8bfaad1..15d321d9515c 100644 --- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi +++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi @@ -79,6 +79,7 @@ reg-shift = <2>; reg-io-width = <4>; clock-frequency = <2700>; + resets = <_reset 8>; status = "disabled"; }; @@ -88,6 +89,7 @@ reg-shift = <2>; reg-io-width = <4>; clock-frequency = <43200>; + resets = < 28>; status = "disabled"; }; @@ -97,6 +99,7 @@ reg-shift = <2>; reg-io-width = <4>; clock-frequency = <43200>; + resets = < 27>; status = "disabled"; }; -- 2.16.4
[PATCH v2 09/11] ARM: dts: rtd1195: Add UART resets
Associate the UART nodes with the corresponding reset controller bits. Signed-off-by: Andreas Färber --- v2: New arch/arm/boot/dts/rtd1195.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/rtd1195.dtsi b/arch/arm/boot/dts/rtd1195.dtsi index fdcaf48a26f2..e2cdcbcf70f4 100644 --- a/arch/arm/boot/dts/rtd1195.dtsi +++ b/arch/arm/boot/dts/rtd1195.dtsi @@ -128,6 +128,7 @@ reg = <0x18007800 0x400>; reg-shift = <2>; reg-io-width = <4>; + resets = <_reset 8>; clock-frequency = <2700>; status = "disabled"; }; @@ -137,6 +138,7 @@ reg = <0x1801b200 0x100>; reg-shift = <2>; reg-io-width = <4>; + resets = < 28>; clock-frequency = <2700>; status = "disabled"; }; -- 2.16.4
[PATCH v2 08/11] ARM: dts: rtd1195: Add reset nodes
Add reset controller nodes for Realtek RTD1195 SoC.
Signed-off-by: Andreas Färber
---
v2: New
arch/arm/boot/dts/rtd1195.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/rtd1195.dtsi b/arch/arm/boot/dts/rtd1195.dtsi
index 475740c67d26..fdcaf48a26f2 100644
--- a/arch/arm/boot/dts/rtd1195.dtsi
+++ b/arch/arm/boot/dts/rtd1195.dtsi
@@ -93,6 +93,30 @@
#size-cells = <1>;
ranges;
+ reset1: reset-controller@1800 {
+ compatible = "snps,dw-low-reset";
+ reg = <0x1800 0x4>;
+ #reset-cells = <1>;
+ };
+
+ reset2: reset-controller@1804 {
+ compatible = "snps,dw-low-reset";
+ reg = <0x1804 0x4>;
+ #reset-cells = <1>;
+ };
+
+ reset3: reset-controller@1808 {
+ compatible = "snps,dw-low-reset";
+ reg = <0x1808 0x4>;
+ #reset-cells = <1>;
+ };
+
+ iso_reset: reset-controller@18007088 {
+ compatible = "snps,dw-low-reset";
+ reg = <0x18007088 0x4>;
+ #reset-cells = <1>;
+ };
+
wdt: watchdog@18007680 {
compatible = "realtek,rtd1295-watchdog";
reg = <0x18007680 0x100>;
--
2.16.4
[PATCH v2 11/11] ARM: dts: rtd1195: Adopt reset constants
Replace reset controller indices with constants.
Signed-off-by: Andreas Färber
---
v2: New
arch/arm/boot/dts/rtd1195.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/rtd1195.dtsi b/arch/arm/boot/dts/rtd1195.dtsi
index e2cdcbcf70f4..9ccf8fa04718 100644
--- a/arch/arm/boot/dts/rtd1195.dtsi
+++ b/arch/arm/boot/dts/rtd1195.dtsi
@@ -13,6 +13,7 @@
/memreserve/ 0x1810 0x0100; /* nor */
#include
+#include
/ {
compatible = "realtek,rtd1195";
@@ -128,7 +129,7 @@
reg = <0x18007800 0x400>;
reg-shift = <2>;
reg-io-width = <4>;
- resets = <_reset 8>;
+ resets = <_reset RTD1195_ISO_RSTN_UR0>;
clock-frequency = <2700>;
status = "disabled";
};
@@ -138,7 +139,7 @@
reg = <0x1801b200 0x100>;
reg-shift = <2>;
reg-io-width = <4>;
- resets = < 28>;
+ resets = < RTD1195_RSTN_UR1>;
clock-frequency = <2700>;
status = "disabled";
};
--
2.16.4
[PATCH v2 00/11] arm64: Realtek RTD1295 reset controllers
Hello, This series adds reset controllers for the Realtek RTD1295 and RTD1195 SoCs. v2 adopts reset-simple driver and DesignWare bindings as simplification and covers RTD1195, too. Note that reset-simple driver would allow to cover RTD1195's reset1-3 in one DT node, but it only maps the first resource, so RTD1295's reset4 would need to remain separate due to a gap in between. I've therefore left them all as separate nodes for now. Also note that my initial 32-bit arm patch already selects RESET_CONTROLLER, to avoid needing a separate patch here to add that one line as done for arm64. If I can take the bindings patches through the Realtek tree then I can squash the two final DT patches depending on them into the patches added the resets, otherwise they need to go into v5.6 or be merged via a topic branch. More experimental patches at: https://github.com/afaerber/linux/commits/rtd1295-next Have a lot of fun! Cheers, Andreas v1 -> v2: * Drop custom reset driver * Drop "realtek,rtd1295-reset" binding * Reordered to not depend on irqchip or clk patches * Extended with RTD1195 patches Cc: Philipp Zabel Cc: devicet...@vger.kernel.org Andreas Färber (11): dt-bindings: reset: Add Realtek RTD1295 dt-bindings: reset: Add Realtek RTD1195 reset: simple: Keep alphabetical order reset: simple: Add Realtek RTD1195/RTD1295 arm64: realtek: Select reset controller arm64: dts: realtek: Add RTD129x reset controller nodes arm64: dts: realtek: Add RTD129x UART resets ARM: dts: rtd1195: Add reset nodes ARM: dts: rtd1195: Add UART resets arm64: dts: realtek: Adopt RTD129x reset constants ARM: dts: rtd1195: Adopt reset constants arch/arm/boot/dts/rtd1195.dtsi | 27 +++ arch/arm64/Kconfig.platforms| 1 + arch/arm64/boot/dts/realtek/rtd129x.dtsi| 34 + drivers/reset/Kconfig | 5 +- include/dt-bindings/reset/realtek,rtd1195.h | 74 +++ include/dt-bindings/reset/realtek,rtd1295.h | 111 6 files changed, 250 insertions(+), 2 deletions(-) create mode 100644 include/dt-bindings/reset/realtek,rtd1195.h create mode 100644 include/dt-bindings/reset/realtek,rtd1295.h -- 2.16.4
[PATCH v2 01/11] dt-bindings: reset: Add Realtek RTD1295
Add a header with symbolic reset indices for Realtek RTD1295 SoC. Naming was derived from reset-names in an OEM's Device Tree. Acked-by: Rob Herring [AF: Dropped RTD1295 specific binding definition, updated SPDX] Signed-off-by: Andreas Färber --- v1 -> v2: * Dropped textual binding with new compatible * Updated SPDX-License-Identifier location * Updated to SPDX 2.0 * Changed from MIT to BSD (Rob) include/dt-bindings/reset/realtek,rtd1295.h | 111 1 file changed, 111 insertions(+) create mode 100644 include/dt-bindings/reset/realtek,rtd1295.h diff --git a/include/dt-bindings/reset/realtek,rtd1295.h b/include/dt-bindings/reset/realtek,rtd1295.h new file mode 100644 index ..2c0cb6afe816 --- /dev/null +++ b/include/dt-bindings/reset/realtek,rtd1295.h @@ -0,0 +1,111 @@ +/* SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) */ +/* + * Realtek RTD1295 reset controllers + * + * Copyright (c) 2017 Andreas Färber + */ +#ifndef DT_BINDINGS_RESET_RTD1295_H +#define DT_BINDINGS_RESET_RTD1295_H + +/* soft reset 1 */ +#define RTD1295_RSTN_MISC 0 +#define RTD1295_RSTN_NAT 1 +#define RTD1295_RSTN_USB3_PHY0_POW 2 +#define RTD1295_RSTN_GSPI 3 +#define RTD1295_RSTN_USB3_P0_MDIO 4 +#define RTD1295_RSTN_SATA_05 +#define RTD1295_RSTN_USB 6 +#define RTD1295_RSTN_SATA_PHY_07 +#define RTD1295_RSTN_USB_PHY0 8 +#define RTD1295_RSTN_USB_PHY1 9 +#define RTD1295_RSTN_SATA_PHY_POW_010 +#define RTD1295_RSTN_SATA_FUNC_EXIST_0 11 +#define RTD1295_RSTN_HDMI 12 +#define RTD1295_RSTN_VE1 13 +#define RTD1295_RSTN_VE2 14 +#define RTD1295_RSTN_VE3 15 +#define RTD1295_RSTN_ETN 16 +#define RTD1295_RSTN_AIO 17 +#define RTD1295_RSTN_GPU 18 +#define RTD1295_RSTN_TVE 19 +#define RTD1295_RSTN_VO20 +#define RTD1295_RSTN_LVDS 21 +#define RTD1295_RSTN_SE22 +#define RTD1295_RSTN_DCU 23 +#define RTD1295_RSTN_DC_PHY24 +#define RTD1295_RSTN_CP25 +#define RTD1295_RSTN_MD26 +#define RTD1295_RSTN_TP27 +#define RTD1295_RSTN_AE28 +#define RTD1295_RSTN_NF29 +#define RTD1295_RSTN_MIPI 30 +#define RTD1295_RSTN_RSA 31 + +/* soft reset 2 */ +#define RTD1295_RSTN_ACPU 0 +#define RTD1295_RSTN_JPEG 1 +#define RTD1295_RSTN_USB_PHY3 2 +#define RTD1295_RSTN_USB_PHY2 3 +#define RTD1295_RSTN_USB3_PHY1_POW 4 +#define RTD1295_RSTN_USB3_P1_MDIO 5 +#define RTD1295_RSTN_PCIE0_STITCH 6 +#define RTD1295_RSTN_PCIE0_PHY 7 +#define RTD1295_RSTN_PCIE0 8 +#define RTD1295_RSTN_PCR_CNT 9 +#define RTD1295_RSTN_CR10 +#define RTD1295_RSTN_EMMC 11 +#define RTD1295_RSTN_SDIO 12 +#define RTD1295_RSTN_PCIE0_CORE13 +#define RTD1295_RSTN_PCIE0_POWER 14 +#define RTD1295_RSTN_PCIE0_NONSTICH15 +#define RTD1295_RSTN_PCIE1_PHY 16 +#define RTD1295_RSTN_PCIE1 17 +#define RTD1295_RSTN_I2C_5 18 +#define RTD1295_RSTN_PCIE1_STITCH 19 +#define RTD1295_RSTN_PCIE1_CORE20 +#define RTD1295_RSTN_PCIE1_POWER 21 +#define RTD1295_RSTN_PCIE1_NONSTICH22 +#define RTD1295_RSTN_I2C_4 23 +#define RTD1295_RSTN_I2C_3 24 +#define RTD1295_RSTN_I2C_2 25 +#define RTD1295_RSTN_I2C_1 26 +#define RTD1295_RSTN_UR2 27 +#define RTD1295_RSTN_UR1 28 +#define RTD1295_RSTN_MISC_SC 29 +#define RTD1295_RSTN_CBUS_TX 30 +#define RTD1295_RSTN_SDS_PHY 31 + +/* soft reset 4 */ +#define RTD1295_RSTN_DCPHY_CRT 0 +#define RTD1295_RSTN_DCPHY_ALERT_RX1 +#define RTD1295_RSTN_DCPHY_PTR 2 +#define RTD1295_RSTN_DCPHY_LDO 3 +#define RTD1295_RSTN_DCPHY_SSC_DIG 4 +#define RTD1295_RSTN_HDMIRX5 +#define RTD1295_RSTN_CBUSRX6 +#define RTD1295_RSTN_SATA_PHY_POW_17 +#define RTD1295_RSTN_SATA_FUNC_EXIST_1 8 +#define RTD1295_RSTN_SATA_PHY_19 +#define RTD1295_RSTN_SATA_110 +#define RTD1295_RSTN_FAN 11 +#define RTD1295_RSTN_HDMIRX_WRAP 12 +#define RTD1295_RSTN_PCIE0_PHY_MDIO13 +#define RTD1295_RSTN_PCIE1_PHY_MDIO14 +#define RTD1295_RSTN_DISP 15 + +/* iso reset */ +#define RTD1295_ISO_RSTN_IR1 +#define RTD1295_ISO_RSTN_CEC0 2 +#define RTD1295_ISO_RSTN_CEC1 3 +#define RTD1295_ISO_RSTN_DP4 +#define RTD1295_ISO_RSTN_CBUSTX5 +#define RTD1295_ISO_RSTN_CBUSRX6 +#define RTD1295_ISO_RSTN_EFUSE 7 +#define RTD1295_ISO_RSTN_
Re: [PATCH v5.1 RESEND] dt-bindings: hwrng: Add Samsung Exynos 5250+ True RNG bindings
Hi guys, Am 26.03.19 um 12:42 schrieb Krzysztof Kozlowski: > On Fri, 11 Jan 2019 at 14:22, Łukasz Stelmach wrote: >> >> Add binding documentation for the True Random Number Generator >> found on Samsung Exynos 5250+ SoCs. >> >> Acked-by: Rob Herring >> Reviewed-by: Krzysztof Kozlowski >> Signed-off-by: Łukasz Stelmach >> --- > > Rob, > Could you apply this directly? You acked this some time ago but it > never went through drivers tree. Lukasz resent this patch and it is > waiting since then. > The driver implementing compatible is already in mainline. For some reason this text file in linux-next is lonely in devicetree/... rather than living in Documentation/devicetree/... - please fix that. The patch here looks correct, so not sure what went wrong: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/devicetree/bindings/rng/samsung,exynos5250-trng.txt?h=next-20191023=85552c22f03c9066c33f26f34538b67fee6a91a8 Thanks, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
[PATCH 3/3] ARM: dts: Prepare Realtek RTD1195 and MeLE X1000
Add Device Trees for Realtek RTD1195 SoC and MeLE X1000 TV box.
Reuse the existing RTD1295 watchdog compatible for now.
Signed-off-by: Andreas Färber
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/rtd1195-mele-x1000.dts | 30
arch/arm/boot/dts/rtd1195.dtsi | 128 +++
3 files changed, 160 insertions(+)
create mode 100644 arch/arm/boot/dts/rtd1195-mele-x1000.dts
create mode 100644 arch/arm/boot/dts/rtd1195.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 73d33611c372..89a951485da8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -858,6 +858,8 @@ dtb-$(CONFIG_ARCH_QCOM) += \
dtb-$(CONFIG_ARCH_RDA) += \
rda8810pl-orangepi-2g-iot.dtb \
rda8810pl-orangepi-i96.dtb
+dtb-$(CONFIG_ARCH_REALTEK) += \
+ rtd1195-mele-x1000.dtb
dtb-$(CONFIG_ARCH_REALVIEW) += \
arm-realview-pb1176.dtb \
arm-realview-pb11mp.dtb \
diff --git a/arch/arm/boot/dts/rtd1195-mele-x1000.dts
b/arch/arm/boot/dts/rtd1195-mele-x1000.dts
new file mode 100644
index ..ce9a255950d3
--- /dev/null
+++ b/arch/arm/boot/dts/rtd1195-mele-x1000.dts
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+/*
+ * Copyright (c) 2017 Andreas Färber
+ */
+
+/dts-v1/;
+
+#include "rtd1195.dtsi"
+
+/ {
+ compatible = "mele,x1000", "realtek,rtd1195";
+ model = "MeLE X1000";
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x4000>;
+ };
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/rtd1195.dtsi b/arch/arm/boot/dts/rtd1195.dtsi
new file mode 100644
index ..475740c67d26
--- /dev/null
+++ b/arch/arm/boot/dts/rtd1195.dtsi
@@ -0,0 +1,128 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+/*
+ * Copyright (c) 2017 Andreas Färber
+ */
+
+/memreserve/ 0x 0xc000; /* boot code */
+/memreserve/ 0xc000 0x000f4000;
+/memreserve/ 0x01b0 0x0040; /* audio */
+/memreserve/ 0x01ffe000 0x4000; /* rpc ringbuf */
+/memreserve/ 0x1000 0x0010; /* secure */
+/memreserve/ 0x17fff000 0x1000;
+/memreserve/ 0x1800 0x0010; /* rbus */
+/memreserve/ 0x1810 0x0100; /* nor */
+
+#include
+
+/ {
+ compatible = "realtek,rtd1195";
+ interrupt-parent = <>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x0>;
+ clock-frequency = <10>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x1>;
+ clock-frequency = <10>;
+ };
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ secure@1000 {
+ reg = <0x1000 0x10>;
+ no-map;
+ };
+
+ rbus@1800 {
+ reg = <0x1800 0x10>;
+ no-map;
+ };
+
+ nor@1810 {
+ reg = <0x1810 0x100>;
+ no-map;
+ };
+ };
+
+ arm-pmu {
+ compatible = "arm,cortex-a7-pmu";
+ interrupts = ,
+;
+ interrupt-affinity = <>, <>;
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = ,
+,
+,
+;
+ clock-frequency = <2700>;
+ };
+
+ osc27M: osc {
+ compatible = "fixed-clock";
+ clock-frequency = <2700>;
+ #clock-cells = <0>;
+ clock-output-names = "osc27M";
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ wdt: watchdog@18007680 {
+ compatible = "realtek,rtd1295-watchdog";
+ re
[PATCH 1/3] dt-bindings: arm: realtek: Add RTD1195 and MeLE X1000
Add bindings for Realtek RTD1195 SoC and MeLE X1000 TV box. Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/arm/realtek.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/realtek.yaml b/Documentation/devicetree/bindings/arm/realtek.yaml index ab59de17152d..091616880d25 100644 --- a/Documentation/devicetree/bindings/arm/realtek.yaml +++ b/Documentation/devicetree/bindings/arm/realtek.yaml @@ -14,6 +14,12 @@ properties: const: '/' compatible: oneOf: + # RTD1195 SoC based boards + - items: + - enum: + - mele,x1000 # MeLE X1000 + - const: realtek,rtd1195 + # RTD1293 SoC based boards - items: - enum: -- 2.16.4
[PATCH 2/3] ARM: Prepare Realtek RTD1195
Introduce ARCH_REALTEK Kconfig option also for 32-bit Arm. Override the text offset to cope with boot ROM living up to 0xf4000. Signed-off-by: Andreas Färber --- arch/arm/Kconfig | 2 ++ arch/arm/Makefile | 1 + arch/arm/mach-realtek/Kconfig | 16 3 files changed, 19 insertions(+) create mode 100644 arch/arm/mach-realtek/Kconfig diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 8a50efb559f3..ac0d1837253d 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -700,6 +700,8 @@ source "arch/arm/mach-qcom/Kconfig" source "arch/arm/mach-rda/Kconfig" +source "arch/arm/mach-realtek/Kconfig" + source "arch/arm/mach-realview/Kconfig" source "arch/arm/mach-rockchip/Kconfig" diff --git a/arch/arm/Makefile b/arch/arm/Makefile index db857d07114f..60c76380f380 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -148,6 +148,7 @@ head-y := arch/arm/kernel/head$(MMUEXT).o textofs-y := 0x8000 # We don't want the htc bootloader to corrupt kernel during resume textofs-$(CONFIG_PM_H1940) := 0x00108000 +textofs-$(CONFIG_ARCH_REALTEK) := 0x00108000 # SA DMA bug: we don't want the kernel to live in precious DMA-able memory ifeq ($(CONFIG_ARCH_SA1100),y) textofs-$(CONFIG_SA) := 0x00208000 diff --git a/arch/arm/mach-realtek/Kconfig b/arch/arm/mach-realtek/Kconfig new file mode 100644 index ..67ae5f122acb --- /dev/null +++ b/arch/arm/mach-realtek/Kconfig @@ -0,0 +1,16 @@ +# SPDX-License-Identifier: GPL-2.0-or-later +menuconfig ARCH_REALTEK + bool "Realtek SoCs" + depends on ARCH_MULTI_V7 + select ARM_AMBA + select ARM_GIC + select ARM_GLOBAL_TIMER + select CACHE_L2X0 + select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK + select COMMON_CLK + select GENERIC_IRQ_CHIP + select HAVE_ARM_SCU if SMP + select HAVE_ARM_TWD if SMP + select RESET_CONTROLLER + help + This enables support for the Realtek RTD1195 SoC family. -- 2.16.4
[PATCH v3 2/2] arm64: dts: realtek: Add watchdog node for RTD129x
Add the watchdog node to the RTD129x Device Tree.
Acked-by: Rob Herring
Acked-by: Guenter Roeck
[AF: Moved from RTD1295 to new RTD129x]
Signed-off-by: Andreas Färber
---
v2 -> v3:
* rtd129x.dtsi was factored out of rtd1295.dtsi, add it there
v1 -> v2: Unchanged
arch/arm64/boot/dts/realtek/rtd129x.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi
b/arch/arm64/boot/dts/realtek/rtd129x.dtsi
index 4fb16611159b..0b2ac0c33b8b 100644
--- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi
+++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi
@@ -37,6 +37,12 @@
/* Exclude up to 2 GiB of RAM */
ranges = <0x8000 0x8000 0x8000>;
+ wdt: watchdog@98007680 {
+ compatible = "realtek,rtd1295-watchdog";
+ reg = <0x98007680 0x100>;
+ clocks = <>;
+ };
+
uart0: serial@98007800 {
compatible = "snps,dw-apb-uart";
reg = <0x98007800 0x400>;
--
2.16.4
[PATCH v3 1/2] arm64: dts: realtek: Add oscillator for RTD129x
Add 27 MHz oscillator clock node.
Signed-off-by: Andreas Färber
---
v3: New (from previously blocking clk patch series)
arch/arm64/boot/dts/realtek/rtd129x.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi
b/arch/arm64/boot/dts/realtek/rtd129x.dtsi
index a26c375ee1bb..4fb16611159b 100644
--- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi
+++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi
@@ -23,6 +23,13 @@
interrupts = ;
};
+ osc27M: osc {
+ compatible = "fixed-clock";
+ clock-frequency = <2700>;
+ #clock-cells = <0>;
+ clock-output-names = "osc27M";
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <1>;
--
2.16.4
[PATCH v2 1/8] dt-bindings: watchdog: realtek: Convert RTD119x to schema
Convert the Realtek watchdog binding to a YAML schema.
Signed-off-by: Andreas Färber
---
v2: New
.../bindings/watchdog/realtek,rtd119x.txt | 17 --
.../bindings/watchdog/realtek,rtd119x.yaml | 38 ++
2 files changed, 38 insertions(+), 17 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/watchdog/realtek,rtd119x.txt
create mode 100644
Documentation/devicetree/bindings/watchdog/realtek,rtd119x.yaml
diff --git a/Documentation/devicetree/bindings/watchdog/realtek,rtd119x.txt
b/Documentation/devicetree/bindings/watchdog/realtek,rtd119x.txt
deleted file mode 100644
index 05653054bd5b..
--- a/Documentation/devicetree/bindings/watchdog/realtek,rtd119x.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Realtek RTD1295 Watchdog
-
-
-Required properties:
-
-- compatible : Should be "realtek,rtd1295-watchdog"
-- reg: Specifies the physical base address and size of registers
-- clocks : Specifies one clock input
-
-
-Example:
-
- watchdog@98007680 {
- compatible = "realtek,rtd1295-watchdog";
- reg = <0x98007680 0x100>;
- clocks = <>;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/realtek,rtd119x.yaml
b/Documentation/devicetree/bindings/watchdog/realtek,rtd119x.yaml
new file mode 100644
index ..5d92cfdfd046
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/realtek,rtd119x.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/watchdog/realtek,rtd119x.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Realtek RTD1295 Watchdog
+
+maintainers:
+ - Andreas Färber
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+oneOf:
+ - const: realtek,rtd1295-watchdog
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+examples:
+ - |
+ watchdog@98007680 {
+ compatible = "realtek,rtd1295-watchdog";
+ reg = <0x98007680 0x100>;
+ clocks = <>;
+ };
+...
--
2.16.4
[PATCH v2 5/8] arm64: dts: realtek: Change dual-license from MIT to BSD
Move the SPDX-License-Identifier to the top line and update to SPDX 2.0. While at it, switch from GPLv2+/MIT to GPLv2+/BSD2c before adding more. Suggested-by: Rob Herring Cc: Rob Herring Signed-off-by: Andreas Färber --- v2: New arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts | 3 +-- arch/arm64/boot/dts/realtek/rtd1295.dtsi | 3 +-- arch/arm64/boot/dts/realtek/rtd129x.dtsi | 3 +-- 3 files changed, 3 insertions(+), 6 deletions(-) diff --git a/arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts b/arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts index da19faab29d5..e98e508b9514 100644 --- a/arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts +++ b/arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts @@ -1,7 +1,6 @@ +// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) /* * Copyright (c) 2016-2017 Andreas Färber - * - * SPDX-License-Identifier: (GPL-2.0+ OR MIT) */ /dts-v1/; diff --git a/arch/arm64/boot/dts/realtek/rtd1295.dtsi b/arch/arm64/boot/dts/realtek/rtd1295.dtsi index 41d7858da826..93f0e1d97721 100644 --- a/arch/arm64/boot/dts/realtek/rtd1295.dtsi +++ b/arch/arm64/boot/dts/realtek/rtd1295.dtsi @@ -1,9 +1,8 @@ +// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) /* * Realtek RTD1295 SoC * * Copyright (c) 2016-2017 Andreas Färber - * - * SPDX-License-Identifier: (GPL-2.0+ OR MIT) */ #include "rtd129x.dtsi" diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi b/arch/arm64/boot/dts/realtek/rtd129x.dtsi index b9cb92466fc7..a26c375ee1bb 100644 --- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi +++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi @@ -1,9 +1,8 @@ +// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) /* * Realtek RTD1293/RTD1295/RTD1296 SoC * * Copyright (c) 2016-2017 Andreas Färber - * - * SPDX-License-Identifier: (GPL-2.0+ OR MIT) */ /memreserve/ 0x 0x0003; -- 2.16.4
[PATCH v2 2/8] dt-bindings: rtc: realtek: Convert RTD119x to schema
Convert the RTD119x binding to a YAML schema.
Signed-off-by: Andreas Färber
---
v2: New
.../devicetree/bindings/rtc/realtek,rtd119x.txt| 16 -
.../devicetree/bindings/rtc/realtek,rtd119x.yaml | 38 ++
2 files changed, 38 insertions(+), 16 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/rtc/realtek,rtd119x.txt
create mode 100644 Documentation/devicetree/bindings/rtc/realtek,rtd119x.yaml
diff --git a/Documentation/devicetree/bindings/rtc/realtek,rtd119x.txt
b/Documentation/devicetree/bindings/rtc/realtek,rtd119x.txt
deleted file mode 100644
index bbf1ccb5df31..
--- a/Documentation/devicetree/bindings/rtc/realtek,rtd119x.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Realtek RTD129x Real-Time Clock
-===
-
-Required properties:
-- compatible : Should be "realtek,rtd1295-rtc"
-- reg: Specifies the physical base address and size
-- clocks : Specifies the clock gate
-
-
-Example:
-
- rtc@9801b600 {
- compatible = "realtek,rtd1295-clk";
- reg = <0x9801b600 0x100>;
- clocks = < RTD1295_CLK_EN_MISC_RTC>;
- };
diff --git a/Documentation/devicetree/bindings/rtc/realtek,rtd119x.yaml
b/Documentation/devicetree/bindings/rtc/realtek,rtd119x.yaml
new file mode 100644
index ..71b7396bd469
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/realtek,rtd119x.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/realtek,rtd119x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek RTD129x Real-Time Clock
+
+allOf:
+ - $ref: "rtc.yaml#"
+
+maintainers:
+ - Andreas Färber
+
+properties:
+ compatible:
+const: realtek,rtd1295-rtc
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+description: Specifies the clock gate
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+examples:
+ - |
+ rtc@9801b600 {
+ compatible = "realtek,rtd1295-clk";
+ reg = <0x9801b600 0x100>;
+ clocks = < RTD1295_CLK_EN_MISC_RTC>;
+ };
+...
--
2.16.4
[PATCH v2 4/8] dt-bindings: arm: realtek: Document RTD1293 and Synology DS418j
Define compatible strings for Realtek RTD1293 SoC and Synology DiskStation DS418j NAS. Cc: i...@synology.com Acked-by: Rob Herring [AF: Converted to json-schema] Signed-off-by: Andreas Färber --- v1 -> v2: * Converted to YAML schema Documentation/devicetree/bindings/arm/realtek.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/realtek.yaml b/Documentation/devicetree/bindings/arm/realtek.yaml index 66458a3f422d..6ea3a79825cc 100644 --- a/Documentation/devicetree/bindings/arm/realtek.yaml +++ b/Documentation/devicetree/bindings/arm/realtek.yaml @@ -14,6 +14,12 @@ properties: const: '/' compatible: oneOf: + # RTD1293 SoC based boards + - items: + - enum: + - synology,ds418j # Synology DiskStation DS418j + - const: realtek,rtd1293 + # RTD1295 SoC based boards - items: - enum: -- 2.16.4
[PATCH v2 8/8] arm64: dts: realtek: Add RTD1296 and Synology DS418
Add Device Trees for RTD1296 SoC and Synology DiskStation DS418.
Cc: i...@synology.com
Signed-off-by: Andreas Färber
---
v1 -> v2:
* Moved SPDX-License-Identifier to top
* Dropped "arm,armv8" (Rob)
* Changed from MIT to BSD-2-Clause (Rob)
* Dropped accidental enable-method and cpu-release-addr
* Fixed DS418 to use rtd1296.dtsi
arch/arm64/boot/dts/realtek/Makefile | 2 +
arch/arm64/boot/dts/realtek/rtd1296-ds418.dts | 30 +
arch/arm64/boot/dts/realtek/rtd1296.dtsi | 65 +++
3 files changed, 97 insertions(+)
create mode 100644 arch/arm64/boot/dts/realtek/rtd1296-ds418.dts
create mode 100644 arch/arm64/boot/dts/realtek/rtd1296.dtsi
diff --git a/arch/arm64/boot/dts/realtek/Makefile
b/arch/arm64/boot/dts/realtek/Makefile
index e7ff40461ddc..555638ada721 100644
--- a/arch/arm64/boot/dts/realtek/Makefile
+++ b/arch/arm64/boot/dts/realtek/Makefile
@@ -5,3 +5,5 @@ dtb-$(CONFIG_ARCH_REALTEK) += rtd1293-ds418j.dtb
dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-mele-v9.dtb
dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-probox2-ava.dtb
dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-zidoo-x9s.dtb
+
+dtb-$(CONFIG_ARCH_REALTEK) += rtd1296-ds418.dtb
diff --git a/arch/arm64/boot/dts/realtek/rtd1296-ds418.dts
b/arch/arm64/boot/dts/realtek/rtd1296-ds418.dts
new file mode 100644
index ..5a051a52bf88
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1296-ds418.dts
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+/*
+ * Copyright (c) 2017-2019 Andreas Färber
+ */
+
+/dts-v1/;
+
+#include "rtd1296.dtsi"
+
+/ {
+ compatible = "synology,ds418", "realtek,rtd1296";
+ model = "Synology DiskStation DS418";
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x8000>;
+ };
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/realtek/rtd1296.dtsi
b/arch/arm64/boot/dts/realtek/rtd1296.dtsi
new file mode 100644
index ..0f9e59cac086
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1296.dtsi
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+/*
+ * Realtek RTD1296 SoC
+ *
+ * Copyright (c) 2017-2019 Andreas Färber
+ */
+
+#include "rtd129x.dtsi"
+
+/ {
+ compatible = "realtek,rtd1296";
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x0>;
+ next-level-cache = <>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x1>;
+ next-level-cache = <>;
+ };
+
+ cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x2>;
+ next-level-cache = <>;
+ };
+
+ cpu3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x3>;
+ next-level-cache = <>;
+ };
+
+ l2: l2-cache {
+ compatible = "cache";
+ };
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = ,
+,
+,
+;
+ };
+};
+
+_pmu {
+ interrupt-affinity = <>, <>, <>, <>;
+};
--
2.16.4
[PATCH v2 7/8] dt-bindings: arm: realtek: Document RTD1296 and Synology DS418
Define compatible strings for Realtek RTD1296 SoC and Synology DiskStation DS418 NAS. Cc: i...@synology.com Acked-by: Rob Herring [AF: Converted to json-schema] Signed-off-by: Andreas Färber --- v1 -> v2: * Converted to YAML schema Documentation/devicetree/bindings/arm/realtek.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/realtek.yaml b/Documentation/devicetree/bindings/arm/realtek.yaml index 6ea3a79825cc..ab59de17152d 100644 --- a/Documentation/devicetree/bindings/arm/realtek.yaml +++ b/Documentation/devicetree/bindings/arm/realtek.yaml @@ -27,4 +27,10 @@ properties: - probox2,ava # ProBox2 AVA - zidoo,x9s # Zidoo X9S - const: realtek,rtd1295 + + # RTD1296 SoC based boards + - items: + - enum: + - synology,ds418 # Synology DiskStation DS418 + - const: realtek,rtd1296 ... -- 2.16.4
[PATCH v2 3/8] dt-bindings: arm: realtek: Tidy up conversion to json-schema
Restore the device names for compatible strings as comments.
Prepare for adding more SoCs by inserting oneOf.
Fixes: 693af5f3eeaa ("dt-bindings: arm: Convert Realtek board/soc bindings to
json-schema")
Signed-off-by: Andreas Färber
---
v2: New
Documentation/devicetree/bindings/arm/realtek.yaml | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/realtek.yaml
b/Documentation/devicetree/bindings/arm/realtek.yaml
index 3528b61963b4..66458a3f422d 100644
--- a/Documentation/devicetree/bindings/arm/realtek.yaml
+++ b/Documentation/devicetree/bindings/arm/realtek.yaml
@@ -13,11 +13,12 @@ properties:
$nodename:
const: '/'
compatible:
-# RTD1295 SoC based boards
-items:
- - enum:
- - mele,v9
- - probox2,ava
- - zidoo,x9s
- - const: realtek,rtd1295
+oneOf:
+ # RTD1295 SoC based boards
+ - items:
+ - enum:
+ - mele,v9 # MeLE V9
+ - probox2,ava # ProBox2 AVA
+ - zidoo,x9s # Zidoo X9S
+ - const: realtek,rtd1295
...
--
2.16.4
[PATCH v2 6/8] arm64: dts: realtek: Add RTD1293 and Synology DS418j
Add Device Trees for RTD1293 SoC and Synology DiskStation DS418j NAS.
Cc: i...@synology.com
Signed-off-by: Andreas Färber
---
v1 -> v2:
* Moved SPDX-License-Identifier to top
* Dropped "arm,armv8" (Rob)
* Changed from MIT to BSD-2-Clause (Rob)
* Dropped accidental enable-method and cpu-release-addr
arch/arm64/boot/dts/realtek/Makefile | 3 ++
arch/arm64/boot/dts/realtek/rtd1293-ds418j.dts | 30 +++
arch/arm64/boot/dts/realtek/rtd1293.dtsi | 51 ++
3 files changed, 84 insertions(+)
create mode 100644 arch/arm64/boot/dts/realtek/rtd1293-ds418j.dts
create mode 100644 arch/arm64/boot/dts/realtek/rtd1293.dtsi
diff --git a/arch/arm64/boot/dts/realtek/Makefile
b/arch/arm64/boot/dts/realtek/Makefile
index 90c897ac3f7a..e7ff40461ddc 100644
--- a/arch/arm64/boot/dts/realtek/Makefile
+++ b/arch/arm64/boot/dts/realtek/Makefile
@@ -1,4 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
+
+dtb-$(CONFIG_ARCH_REALTEK) += rtd1293-ds418j.dtb
+
dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-mele-v9.dtb
dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-probox2-ava.dtb
dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-zidoo-x9s.dtb
diff --git a/arch/arm64/boot/dts/realtek/rtd1293-ds418j.dts
b/arch/arm64/boot/dts/realtek/rtd1293-ds418j.dts
new file mode 100644
index ..b2dd583146b4
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1293-ds418j.dts
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+/*
+ * Copyright (c) 2017 Andreas Färber
+ */
+
+/dts-v1/;
+
+#include "rtd1293.dtsi"
+
+/ {
+ compatible = "synology,ds418j", "realtek,rtd1293";
+ model = "Synology DiskStation DS418j";
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x4000>;
+ };
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/realtek/rtd1293.dtsi
b/arch/arm64/boot/dts/realtek/rtd1293.dtsi
new file mode 100644
index ..bd4e22723f7b
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1293.dtsi
@@ -0,0 +1,51 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+/*
+ * Realtek RTD1293 SoC
+ *
+ * Copyright (c) 2017-2019 Andreas Färber
+ */
+
+#include "rtd129x.dtsi"
+
+/ {
+ compatible = "realtek,rtd1293";
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x0>;
+ next-level-cache = <>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x1>;
+ next-level-cache = <>;
+ };
+
+ l2: l2-cache {
+ compatible = "cache";
+ };
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = ,
+,
+,
+;
+ };
+};
+
+_pmu {
+ interrupt-affinity = <>, <>;
+};
--
2.16.4
Re: [PATCH] MAINTAINERS: Add mailing list for Realtek SoCs
Am 19.10.19 um 16:13 schrieb Andreas Färber: > Document linux-realtek-soc mailing list to be CC'ed on patches. > > Signed-off-by: Andreas Färber > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index c7b48525822a..8be71b3d25e7 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2168,6 +2168,7 @@ F: > Documentation/devicetree/bindings/timer/rda,8810pl-timer.txt > ARM/REALTEK ARCHITECTURE > M: Andreas Färber > L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) > +L: linux-realtek-...@lists.infradead.org (moderated for non-subscribers) > S: Maintained > F: arch/arm64/boot/dts/realtek/ > F: Documentation/devicetree/bindings/arm/realtek.yaml Applied to linux-realtek.git v5.5/arm64: https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-realtek.git/log/?h=v5.5/arm64 Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
[PATCH] MAINTAINERS: Add mailing list for Realtek SoCs
Document linux-realtek-soc mailing list to be CC'ed on patches. Signed-off-by: Andreas Färber --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index c7b48525822a..8be71b3d25e7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2168,6 +2168,7 @@ F: Documentation/devicetree/bindings/timer/rda,8810pl-timer.txt ARM/REALTEK ARCHITECTURE M: Andreas Färber L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +L: linux-realtek-...@lists.infradead.org (moderated for non-subscribers) S: Maintained F: arch/arm64/boot/dts/realtek/ F: Documentation/devicetree/bindings/arm/realtek.yaml -- 2.16.4
Re: [PATCH] regmap: fix writes to non incrementing registers
Am Mittwoch, den 14.08.2019, 17:05 +0100 schrieb Mark Brown: > On Wed, Aug 14, 2019 at 03:32:37PM +0200, Andreas Färber wrote: > > > Then please add a Fixes: header to your commit message, so that it > > gets > > backported to all affected upstream and downstream trees. > > This still isn't a sensible fix for the reasons I outlined. No contradiction here. Cheers, Andreas -- SUSE Linux GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
Re: [PATCH] regmap: fix writes to non incrementing registers
Am 14.08.19 um 15:09 schrieb Ben Whitten: > On Wed, 14 Aug 2019 at 11:01, Mark Brown wrote: >> >> On Tue, Aug 13, 2019 at 10:22:51PM +0100, Ben Whitten wrote: >> >>> @@ -1489,10 +1489,11 @@ static int _regmap_raw_write_impl(struct regmap >>> *map, unsigned int reg, >>> WARN_ON(!map->bus); >>> >>> /* Check for unwritable registers before we start */ >>> - for (i = 0; i < val_len / map->format.val_bytes; i++) >>> - if (!regmap_writeable(map, >>> - reg + regmap_get_offset(map, i))) >>> - return -EINVAL; >>> + if (!regmap_writeable_noinc(map, reg)) >>> + for (i = 0; i < val_len / map->format.val_bytes; i++) >>> + if (!regmap_writeable(map, >>> + reg + regmap_get_offset(map, i))) >>> + return -EINVAL; >> >> This feels like we're getting ourselves confused about nonincrementing >> registers and probably have other breakage somewhere else - we're >> already checking for nonincrementability in regmap_write_noinc(), and >> here we're only checking if the first register in the block has that >> property which might blow up on us if there's a register in the middle >> of the block that is nonincrementable. If we're going to check this >> here I think we should check on every register, but this is >> _raw_write_impl() which is part of the call path for implementing >> regmap_noinc_write() so checking here will break the API purpose >> designed for nonincrementing writes. > > So it appeared that the last patch in this area for validating a register > block [1] broke the regmap_noinc_write use case. Then please add a Fixes: header to your commit message, so that it gets backported to all affected upstream and downstream trees. Thanks, Andreas > Because regmap_noinc_write calls _regmap_raw_write and in > turn hits the _regmap_raw_write_impl, the val_len is the depth of the > one register to write to and not a block of registers which is assumed > by the previous check. By inserting a check that the first (and only) > register is a noinc one allows me to start writing to my FIFO again. > > I'm all for an alternative solution though if there is a cleaner approach. > > Kind regards, > Ben > > [1] https://lore.kernel.org/patchwork/patch/1057184/ > -- SUSE Linux GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
Re: [PATCH 0/6] Add Banana Pi BPI-W2 basic support
Am 07.07.19 um 15:22 schrieb Aleix Roca Nonell: > This patch series adds minimum support to boot a Banana Pi BPI-W2. Thanks for looking into this. Please CC linux-realtek-...@lists.infradead.org next time. Regards, Andreas -- SUSE Linux GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
Re: [PATCH 5/6] dt-bindings: arm: Document RTD1296
Am 07.07.19 um 15:23 schrieb Aleix Roca Nonell: > Add bindings for Relatek RTD1296 SoC. And the Bannana Pi BPI-W2 board. "Realtek", "Banana" > > Signed-off-by: Aleix Roca Nonell > --- > Documentation/devicetree/bindings/arm/realtek.txt | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/realtek.txt > b/Documentation/devicetree/bindings/arm/realtek.txt > index 95839e19ae92..78da1004d38c 100644 > --- a/Documentation/devicetree/bindings/arm/realtek.txt > +++ b/Documentation/devicetree/bindings/arm/realtek.txt > @@ -20,3 +20,16 @@ Root node property compatible must contain, depending on > board: > Example: > > compatible = "zidoo,x9s", "realtek,rtd1295"; > + > + > +RTD1296 SoC > +=== > + > +Required root node properties: > + > + - compatible : must contain "realtek,rtd1296" I'm pretty sure that I had such a patch on the list already, so this is lacking my authorship. Also, Rob has been working to convert these to YAML, so we should probably complete that first and then add RTD1296 properly. > + > + > +Root node property compatible must contain, depending on board: > + > + - Bannana Pi BPI-W2: "bananapi,bpi-w2" "Banana" Regards, Andreas -- SUSE Linux GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
Re: [PATCH 2/6] irqchip: Add Realtek RTD129x intc driver
Am 07.07.19 um 15:22 schrieb Aleix Roca Nonell: > This driver adds support for the RTD1296 and RTD1295 interrupt > controller (intc). It is based on both the BPI-SINOVOIP project and > Andreas Färber's previous attempt to submit a similar driver. Doing that without my Signed-off-by and Copyright is certainly not okay. It is also lacking a clear description of what you changed from my last submission or the post-submission GitHub version adressing review comments, which broke. Regards, Andreas -- SUSE Linux GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
Re: [PATCH] csky: dts: Add NationalChip GX6605S
Am 25.06.19 um 02:45 schrieb Guo Ren:
> Thx for the patch. No need seperate part into dtsi,
Sorry, I know from many arm contributions that using a .dtsi is the
right thing here. It logically separates the chip from the board, even
if there's only one evaluation board currently. Think about set-top
boxes that someone might author a .dts for - they should be able to
reuse the .dtsi for the SoC rather than copy it.
> just follow:
> https://lore.kernel.org/linux-csky/1561376581-19568-1-git-send-email-guo...@kernel.org/T/#u
Thanks for that pointer! I still think my node names are cleaner and
also the structure of keeping clocks and gpio users outside of /soc. I
see the value you use is 27 MHz, will try it tomorrow. I see you use
nice KEY_ constants, whereas I just took the raw values from the dtb.
I notice that your patch doesn't have any Copyright header, how should I
credit you in the resulting combined patch? I would then also add your
SoB from the patch you linked to.
More comments inline...
> On Tue, Jun 25, 2019 at 8:28 AM Andreas Färber wrote:
>>
>> Add Device Trees for NationalChip GX6605S SoC (based on CK610 CPU) and its
>> dev board. GxLoader expects as filename gx6605s.dtb, so keep that.
>> The bootargs are prepared to boot from USB and to output to serial.
>>
>> Compatibles for the SoC and board are left out for now.
>>
>> Signed-off-by: Andreas Färber
>> ---
>> arch/csky/boot/dts/gx6605s.dts | 104
>>
>> arch/csky/boot/dts/gx6605s.dtsi | 82 +++
>> 2 files changed, 186 insertions(+)
>> create mode 100644 arch/csky/boot/dts/gx6605s.dts
>> create mode 100644 arch/csky/boot/dts/gx6605s.dtsi
>>
>> diff --git a/arch/csky/boot/dts/gx6605s.dts b/arch/csky/boot/dts/gx6605s.dts
>> new file mode 100644
>> index ..f7511024ec6f
>> --- /dev/null
>> +++ b/arch/csky/boot/dts/gx6605s.dts
[...]
>> + leds {
>> + compatible = "gpio-leds";
>> +
>> + led0 {
>> + label = "led10";
I forgot to align the numbering here. The label matches the GPIO and
what is printed on the board.
>> + gpios = < 10 GPIO_ACTIVE_LOW>;
>> + linux,default-trigger = "heartbeat";
This green one stops blinking and stays on.
>> + };
>> +
>> + led1 {
>> + label = "led11";
>> + gpios = < 11 GPIO_ACTIVE_LOW>;
>> + linux,default-trigger = "timer";
This red one keeps blinking after the panic.
>> + };
>> +
>> + led2 {
>> + label = "led12";
>> + gpios = < 12 GPIO_ACTIVE_LOW>;
>> + linux,default-trigger = "default-on";
>> + };
>> +
>> + led3 {
>> + label = "led13";
>> + gpios = < 13 GPIO_ACTIVE_LOW>;
>> + linux,default-trigger = "default-on";
These two remain off. So I wonder whether the GPIO polarity is wrong?
In the example usb.img the gpio-leds module is not loaded by default, so
maybe it wasn't noticed before?
Also, many arm boards use more complex LED labels with multiple parts
separated by colon, like "boardname:name:function" or so.
>> + };
>> + };
[...]
>> diff --git a/arch/csky/boot/dts/gx6605s.dtsi
>> b/arch/csky/boot/dts/gx6605s.dtsi
>> new file mode 100644
>> index ..956af5674add
>> --- /dev/null
>> +++ b/arch/csky/boot/dts/gx6605s.dtsi
>> @@ -0,0 +1,82 @@
>> +/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause */
>> +/*
>> + * NationalChip GX6605S SoC
>> + *
>> + * Copyright (c) 2019 Andreas Färber
>> + */
>> +
>> +/ {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + cpu0: cpu@0 {
>> + device_type = "cpu";
>> + compatible = "csky,ck610";
>> + reg = <0>;
>> + };
>> + };
>> +
>> + soc {
>> + compatible = "simple-bus";
>> + interrupt-parent = <>;
>> + #address-cells = <1>;
>&
