* [PATCH 3/9] soc: fsl: set rcpm bit for FTM
From: Yinbo Zhu @ 2018-05-14 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM4PR0401MB16995DFED0376ACE0DD5E7A78F9F0@AM4PR0401MB1699.eurprd04.prod.outlook.com>
-----Original Message-----
From: Leo Li
Sent: 2018?5?12? 1:00
To: Yinbo Zhu <yinbo.zhu@nxp.com>; Yinbo Zhu <yinbo.zhu@nxp.com>; Rob Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; Catalin Marinas ) <catalin.marinas@arm.com>; Will Deacon ) <will.deacon@arm.com>; Lorenzo Pieralisi ) <lorenzo.pieralisi@arm.com>
Cc: Xiaobo Xie <xiaobo.xie@nxp.com>; Ran Wang <ran.wang_1@nxp.com>; Daniel Lezcano <daniel.lezcano@linaro.org>; Thomas Gleixner <tglx@linutronix.de>; Shawn Guo <shawnguo@kernel.org>; Madalin-cristian Bucur <madalin.bucur@nxp.com>; Z.q. Hou <zhiqiang.hou@nxp.com>; Jerry Huang <jerry.huang@nxp.com>; M.h. Lian <minghuan.lian@nxp.com>; Qiang Zhao <qiang.zhao@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>; Jiaheng Fan <jiaheng.fan@nxp.com>; Po Liu <po.liu@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Horia Geant? <horia.geanta@nxp.com>; Priyanka Jain <priyanka.jain@nxp.com>; Sumit Garg <sumit.garg@nxp.com>; costi <constantin.tudor@freescale.com>; Bogdan Purcareata <bogdan.purcareata@nxp.com>; open list:CLOCKSOURCE, CLOCKEVENT DRIVERS <linux-kernel@vger.kernel.org>; open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>; linux-arm-kernel at lists.infradead.org; open list:FREESCALE SOC DRIVERS <linuxppc-dev@lists.ozlabs.org>; Andy Tang <andy.tang@nxp.com>; Ying Zhang <ying.zhang22455@nxp.com>
Subject: RE: [PATCH 3/9] soc: fsl: set rcpm bit for FTM
> -----Original Message-----
> From: Yinbo Zhu [mailto:yinbo.zhu at nxp.com]
> Sent: Thursday, May 10, 2018 10:35 PM
> To: Yinbo Zhu <yinbo.zhu@nxp.com>; Rob Herring <robh+dt@kernel.org>;
> Mark Rutland <mark.rutland@arm.com>; Catalin Marinas )
> <catalin.marinas@arm.com>; Will Deacon ) <will.deacon@arm.com>;
> Lorenzo Pieralisi ) <lorenzo.pieralisi@arm.com>; Leo Li
> <leoyang.li@nxp.com>
> Cc: Xiaobo Xie <xiaobo.xie@nxp.com>; Ran Wang <ran.wang_1@nxp.com>;
> Daniel Lezcano <daniel.lezcano@linaro.org>; Thomas Gleixner
> <tglx@linutronix.de>; Shawn Guo <shawnguo@kernel.org>;
> Madalin-cristian Bucur <madalin.bucur@nxp.com>; Z.q. Hou
> <zhiqiang.hou@nxp.com>; Jerry Huang <jerry.huang@nxp.com>; M.h. Lian
> <minghuan.lian@nxp.com>; Qiang Zhao <qiang.zhao@nxp.com>; Fabio
> Estevam <fabio.estevam@nxp.com>; Jiaheng Fan <jiaheng.fan@nxp.com>; Po
> Liu <po.liu@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Horia Geant?
> <horia.geanta@nxp.com>; Priyanka Jain <priyanka.jain@nxp.com>; Sumit
> Garg <sumit.garg@nxp.com>; costi <constantin.tudor@freescale.com>;
> Bogdan Purcareata <bogdan.purcareata@nxp.com>; Meng Yi
> <meng.yi@nxp.com>; Wang Dongsheng <dongsheng.wang@nxp.com>; open
> list:CLOCKSOURCE, CLOCKEVENT DRIVERS <linux-kernel@vger.kernel.org>;
> open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> <devicetree@vger.kernel.org>; linux-arm-kernel at lists.infradead.org;
> open list:FREESCALE SOC DRIVERS <linuxppc-dev@lists.ozlabs.org>; Andy
> Tang <andy.tang@nxp.com>; Ying Zhang <ying.zhang22455@nxp.com>
> Subject: [PATCH 3/9] soc: fsl: set rcpm bit for FTM
>
> From: Zhang Ying-22455 <ying.zhang22455@nxp.com>
>
> Set RCPM for FTM when using FTM as wakeup source. Because the RCPM
> module of each platform has different big-end and little-end mode,
> there need to set RCPM depending on the platform.
>
> Signed-off-by: Zhang Ying-22455 <ying.zhang22455@nxp.com>
> Signed-off-by: Yinbo Zhu <yinbo.zhu@nxp.com>
> ---
> .../devicetree/bindings/timer/fsl,ftm-timer.txt | 7 ++
> drivers/soc/fsl/layerscape/ftm_alarm.c | 92 ++++++++++++++++++-
> 2 files changed, 94 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> index aa8c402..15ead58 100644
> --- a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> +++ b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> @@ -3,6 +3,13 @@ Freescale FlexTimer Module (FTM) Timer Required
> properties:
>
> - compatible : should be "fsl,ftm-timer"
>Hi Yingbo,
>This is a change that breaks backward compatibility and not acceptable.
Hi leo,
This patch if I keep the change as inner patch and push it to dash-linnux but I will not push it to upstream, It's okay?
As far as I know, there was a other patch and file for replace the file and that the patch is already on the upstream
https://patchwork.kernel.org/patch/9391293/
> + Possible compatibles for ARM:
> + "fsl,ls1012a-ftm"
> + "fsl,ls1021a-ftm"
> + "fsl,ls1043a-ftm"
> + "fsl,ls1046a-ftm"
> + "fsl,ls1088a-ftm"
> + "fsl,ls208xa-ftm"
> - reg : Specifies base physical address and size of the register sets for the
> clock event device and clock source device.
> - interrupts : Should be the clock event device interrupt.
> diff --git a/drivers/soc/fsl/layerscape/ftm_alarm.c
> b/drivers/soc/fsl/layerscape/ftm_alarm.c
> index 6f9882f..811dcfa 100644
> --- a/drivers/soc/fsl/layerscape/ftm_alarm.c
> +++ b/drivers/soc/fsl/layerscape/ftm_alarm.c
>There is no such file in the mainline kernel. So it looks like the patch set is
> based on some internal git repo instead of the upstream Linux kernel. This kind of patches
> shouldn't be sent to the upstream mailing list for review.
>Regards,
>Leo
This patch will not to upstream.
Regards,
Yinbo.
^ permalink raw reply
* 答复: reply: [PATCH v3 1/2] PCI: kirin: Add MSI support
From: songxiaowei @ 2018-05-14 7:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VfHfUCNKNun4-bb2BhwV6D9jg2+hzVjrDER+af0SrzqjA@mail.gmail.com>
Hi Andy Shevchenko
> -----????-----
> ???: Andy Shevchenko [mailto:andy.shevchenko at gmail.com]
> ????: 2018?5?14? 15:17
> ???: songxiaowei <songxiaowei@hisilicon.com>
> ??: chenyao (F) <chenyao11@huawei.com>; Wangbinghui
> <wangbinghui@hisilicon.com>; Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>;
> Bjorn Helgaas <bhelgaas@google.com>; xuwei (O) <xuwei5@huawei.com>;
> Rob Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>;
> Catalin Marinas <catalin.marinas@arm.com>; Will Deacon
> <will.deacon@arm.com>; linux-pci at vger.kernel.org; Linux Kernel Mailing List
> <linux-kernel@vger.kernel.org>; linux-arm Mailing List
> <linux-arm-kernel@lists.infradead.org>; devicetree
> <devicetree@vger.kernel.org>; dimitrysh at google.com;
> guodong.xu at linaro.org; Suzhuangluan <suzhuangluan@hisilicon.com>; Kongfei
> <kongfei@hisilicon.com>
> ??: Re: reply: [PATCH v3 1/2] PCI: kirin: Add MSI support
>
> On Mon, May 14, 2018 at 4:11 AM, songxiaowei <songxiaowei@hisilicon.com>
> wrote:
>
> >> > + int ret;
> >> > +
> >> > + if (IS_ENABLED(CONFIG_PCI_MSI)) {
> >>
> >> > + pci->pp.msi_irq = platform_get_irq(pdev, 0);
> >> > + if (pci->pp.msi_irq < 0) {
> >> > + dev_err(&pdev->dev, "failed to get MSI IRQ
> >> (%d)\n",
> >> > + pci->pp.msi_irq);
> >>
> >> > + return -ENODEV;
> >>
> >> Why shadowing actual error code?
> > [songxiaowei] Sorry, I can't get your point about this, would you explain it
> for me.
>
> platform_get_irq() returns either correct IRQ number or negative error code.
> In the code above you shadow the actual error (as returned by that
> call) by -ENODEV. Any reason why?
>
[songxiaowei] I guess the reason is that she wanted to keep the same with other hosts,
So, you'd like to use "return pci->pp.msi_irq " instead of " return -ENODEV ".
> --
> With Best Regards,
> Andy Shevchenko
Thanks a lot,
Xiaowei.
^ permalink raw reply
* [PATCH 3/3] arm64: dts: renesas: draak: Describe HDMI input
From: jacopo mondi @ 2018-05-14 7:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513125755.GQ18974@bigcity.dyn.berto.se>
Hi Niklas,
On Sun, May 13, 2018 at 02:57:55PM +0200, Niklas S?derlund wrote:
> Hi Jacopo,
>
> Thanks for your patch.
>
> On 2018-05-11 12:00:02 +0200, Jacopo Mondi wrote:
> > Describe HDMI input connected to VIN4 interface for R-Car D3 Draak
> > development board.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > ---
> > arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 68 ++++++++++++++++++++++++++
> > 1 file changed, 68 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > index d03f194..e0ce462 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > @@ -59,6 +59,17 @@
> > };
> > };
> >
> > + hdmi-in {
> > + compatible = "hdmi-connector";
> > + type = "a";
> > +
> > + port {
> > + hdmi_con_in: endpoint {
> > + remote-endpoint = <&adv7612_in>;
> > + };
> > + };
> > + };
> > +
> > memory at 48000000 {
> > device_type = "memory";
> > /* first 128MB is reserved for secure area. */
> > @@ -142,6 +153,11 @@
> > groups = "usb0";
> > function = "usb0";
> > };
> > +
> > + vin4_pins: vin4 {
> > + groups = "vin4_data24", "vin4_sync", "vin4_clk", "vin4_clkenb";
> > + function = "vin4";
> > + };
> > };
> >
> > &i2c0 {
> > @@ -154,6 +170,35 @@
> > reg = <0x50>;
> > pagesize = <8>;
> > };
> > +
> > + hdmi-decoder at 4c {
> > + compatible = "adi,adv7612";
> > + reg = <0x4c>;
> > + default-input = <0>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port at 0 {
> > + reg = <0>;
> > + adv7612_in: endpoint {
> > + remote-endpoint = <&hdmi_con_in>;
> > + };
> > + };
> > +
> > + port at 2 {
> > + reg = <2>;
> > + adv7612_out: endpoint {
> > + pclk-sample = <0>;
> > + hsync-active = <0>;
> > + vsync-active = <0>;
>
> This differs from the Gen2 DT bindings which is a very similar hardware
> setup using the same components. Defining these properties will make the
> bus marked as V4L2_MBUS_PARALLEL instead of V4L2_MBUS_BT656.
And that's what we want....
>
> This will change how the hardware is configured for capture if the media
> bus is in a UYVY format, see VNMC_INF register in rvin_setup(). Maybe
> this it not an issue here but still I'm curious to why this differ
> between Gen2 and Gen3 :-)
Actually this won't impact the VIN configuration as this is the
'remote endpoint' from VIN perspective and the properties used to
configure the interface are the ones in the 'local endpoint'.
>
> > +
> > + remote-endpoint = <&vin4_in>;
> > + };
> > + };
> > + };
> > + };
> > };
> >
> > &i2c1 {
> > @@ -246,3 +291,26 @@
> > timeout-sec = <60>;
> > status = "okay";
> > };
> > +
> > +&vin4 {
> > + pinctrl-0 = <&vin4_pins>;
> > + pinctrl-names = "default";
> > +
> > + status = "okay";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port at 0 {
> > + reg = <0>;
> > +
> > + vin4_in: endpoint {
> > + hsync-active = <0>;
> > + vsync-active = <0>;
>
> Comparing this to the Gen2 bindings some properties are missing,
>
> bus-width = <24>;
> pclk-sample = <1>;
> data-active = <1>;
The VIN driver does not parse them, so there is no value in having
them there, if not confusing people as it happened to me reading the
Gen2 DT.
>
> This is not a big deal as the VIN driver don't use these properties so
> no functional change should come of this but still a difference.
Exactly.
On a side note. I have not seen a way to configure the pixel clock
sampling level in the interface datasheet. The register used to
configure synchronism signals polarities is VnDMR2, and there I read
we can configure HSYNC/VSYNC and CLOCKENB (which is data enable, not
pixel clock) polarities. Is it configured through some other
register?
>
> Over all I'm happy with this change but before I add my tag I would like
> to understand why it differs from the Gen2 configuration for the adv7612
> properties.
>
> Also on a side not it is possible with hardware switches on the board
> switch the VIN4 source to a completely different pipeline CVBS connector
> -> adv7180 -> VIN4. But I think it's best we keep the HDMI as default as
> this seems to be how the boards are shipped. But maybe mentioning this
> in the commit message would not hurt if you end-up resending the patch.
Oh I see. SW-49 to SW-52 enables the HDMI input, SW53-SW54 CVBS one.
And actually, reading the 'initial setting of slide switches' in the
Draak board manual, it turns out that the board default configuration
is with CVBS input selected... What should we do here? reflect
defaults in the DT, or prioritize HDMI?
Thanks
j
>
> > +
> > + remote-endpoint = <&adv7612_out>;
> > + };
> > + };
> > + };
> > +};
> > --
> > 2.7.4
> >
>
> --
> Regards,
> Niklas S?derlund
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180514/5816d47b/attachment-0001.sig>
^ permalink raw reply
* [RFC PATCH] driver core: make deferring probe forever optional
From: Alexander Graf @ 2018-05-14 7:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaYN-wKErERP_65T2NH6L-+8O_ugSgg7pXfkaLkn1A2KQ@mail.gmail.com>
On 05/14/2018 12:01 AM, Linus Walleij wrote:
> On Wed, May 9, 2018 at 11:44 AM, Alexander Graf <agraf@suse.de> wrote:
>> On 05/07/2018 08:31 PM, Bjorn Andersson wrote:
>>> Can you please name platform that has enough support for Alexander to
>>> care about backwards and forwards compatibility but lacks a pinctrl
>>> driver.
>> ZynqMP is one example that immediately comes to my mind. I'm sure there are
>> others too.
> Why isn't that using drivers/pinctrl/pinctrl-zynq.c?
>
> How is it so very different from (old) Zynq as it is already using
> the same GPIO driver?
That one is very simple: ZynqMP is usually an AMP system where Linux
doesn't have full knowledge of the overall system. IIUC they have a tiny
microblaze (PMU) that does the actual full system configuration for
peripherals that may interfere with each other. This architecture also
allows for safety critical code to run alongside a (less safe) Linux system.
I think we'll see architectures like this pop up more over time. TI
Sitara has similar issues. I know that Jailhouse ran into exactly that
problem before. I also know that during Linaro Connect Budapest even the
OP-TEE people realized the current model is bad, because Linux may
control pins/clocks/etc of devices that the secure world wants to use.
So I actually believe we will see more SoCs in the future that may even
start with Linux controllable pinctrl or no pinctrl driver but then will
move to firmware controlled drivers once it starts being necessary.
Alex
^ permalink raw reply
* [PATCH 6/8] serial: Add Tegra Combined UART driver
From: Mikko Perttunen @ 2018-05-14 7:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VeJcqaiWUVr=oXEH5YurY3yCDdE1eeoWumo6jCa_4PWEQ@mail.gmail.com>
On 14.05.2018 01:20, Andy Shevchenko wrote:
> On Sun, May 13, 2018 at 9:04 PM, Mikko Perttunen <cyndis@kapsi.fi> wrote:
>> On 05/13/2018 05:16 PM, Andy Shevchenko wrote:
>>>
>>> On Tue, May 8, 2018 at 2:44 PM, Mikko Perttunen <mperttunen@nvidia.com>
>>> wrote:
>>>>
>>>> The Tegra Combined UART (TCU) is a mailbox-based mechanism that allows
>>>> multiplexing multiple "virtual UARTs" into a single hardware serial
>>>> port. The TCU is the primary serial port on Tegra194 devices.
>>>>
>>>> Add a TCU driver utilizing the mailbox framework, as the used mailboxes
>>>> are part of Tegra HSP blocks that are already controlled by the Tegra
>>>> HSP mailbox driver.
>
>>>> +static void tegra_tcu_uart_set_mctrl(struct uart_port *port, unsigned
>>>> int mctrl)
>>>> +{
>>>
>>>
>>>> + (void)port;
>>>> + (void)mctrl;
>>>
>>>
>>> Huh?
>>
>>
>> The serial core calls these callbacks without checking if they are set. They
>> don't make sense for this driver so they are stubbed out.
>
> My question why do you need these ugly lines? I'm pretty sure no other
> driver with stubs using such style.
It's my personal style, being explicit about unused variables in this
way - I don't consider them ugly. But I can certainly remove them for
the next version.
>
>>>> +}
>
>>>> + if (written == 3) {
>>>> + value |= 3 << 24;
>>>> + value |= BIT(26);
>>>> + mbox_send_message(tcu->tx, &value);
>>>
>>>
>>>> + }
>>>
>>>
>>> (1)
>>>
>>>> + }
>>>> +
>>>> + if (written) {
>>>> + value |= written << 24;
>>>> + value |= BIT(26);
>>>> + mbox_send_message(tcu->tx, &value);
>>>> + }
>>>
>>>
>>> (2)
>>>
>>> These are code duplications.
>>
>>
>> Indeed - the length of the duplicated code is so short, and the instances
>> are so close to each other, that I don't find it necessary (or clearer) to
>> have an extra function.
>
> It makes sense. Consider to refactor other way w/o duplication then.
I'll see if I can refactor it out.
>
>>>> +static void tegra_tcu_uart_set_termios(struct uart_port *port,
>>>> + struct ktermios *new,
>>>> + struct ktermios *old)
>>>> +{
>>>> + (void)port;
>>>> + (void)new;
>>>> + (void)old;
>>>> +}
>>>
>>>
>>> Remove those unused stub contents.
>>
>>
>> Sure. I had these here so that we don't get unused parameter warnings, but I
>> can just as well remove the parameter names.
>
> What warnings? How did you get them? We have them disabled as far as I
> know even with W=1.
May be - it's just a habit, maybe from other projects where the warning
is enabled.
>
>>
>>>
>>>> + return uart_set_options(&tegra_tcu_uart_port, cons,
>>>> + 115200, 'n', 8, 'n');
>>>
>>>
>>> Can't it be one line?
>>
>>
>> It would be a total of 81 characters in length on one line, so no.
>
> So, yes. 1 character doesn't prevent us make the readability better.
> Please, put to one line.
>
Ok, I'll change this.
Thanks,
Mikko
^ permalink raw reply
* [PATCH RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Maxime Ripard @ 2018-05-14 7:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v66F_Ho2OZdrF3p6xe9mQ=zJZ_KjE9MnW1VmWs9jw65eEg@mail.gmail.com>
On Sun, May 13, 2018 at 09:59:22PM -0700, Chen-Yu Tsai wrote:
> On Sun, May 13, 2018 at 1:29 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > On Sun, May 13, 2018 at 01:11:08PM -0700, Chen-Yu Tsai wrote:
> >> On Sun, May 13, 2018 at 1:05 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> >> >> > Hi Chen-Yu
> >> >> >
> >> >> > Are these delays the MAC applies? Not the PHY. It would be good to
> >> >> > make it clear here these are MAC imposed delays.
> >> >>
> >> >> Yes these are applied on the MAC side. Being described in the device
> >> >> tree bindings for the MAC, I thought this was implied to be the case?
> >> >> Are there known exceptions?
> >> >
> >> > There is frequent confusion with this. Most of the time, the PHY does
> >> > the delay, not the MAC, based on the phy-mode. So the MAC doing it is
> >> > an exception in itself.
> >> >
> >> > Do you actually need these delays for the board you adding support
> >> > for? Does the PHY not support adding the needed delays? If you don't
> >> > need the delays, i would not even implement them.
> >>
> >> Yes this is already used on the Bananapi M3. This patch merely reformats
> >> the description and adds a note saying this only applies to RGMII mode.
> >
> > Yes, the current code is needed for the Bananapi M3. But you have
> > another patch which extends the code to support a smaller range. Do
> > you have a board which actually needs this? If not, i would not add
> > that new code.
>
> IIRC the delay on the PHY side is either 2ns or none. The delay on the
> MAC side here is an order smaller, likely fine tuning to cope with board
> design deficiencies.
>
> Currently no other board requires this, but this is already part of the
> binding. The new stuff limits the range for a specific SoC, simply because
> that is the range supported by the control register. Not implementing, i.e.
> supporting the whole range from the property, which might get truncated,
> doesn't make much sense to me.
With that driver we don't, but the previous design had the same
feature and it was used on more boards. It was simply initialized
statically in U-Boot, and not in Linux through the DT like it is done
here.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180514/e639ce99/attachment.sig>
^ permalink raw reply
* reply: [PATCH v3 1/2] PCI: kirin: Add MSI support
From: Andy Shevchenko @ 2018-05-14 7:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <99B4C6BADD9E3241B25E52B02BA737C54127E3BF@DGGEMA505-MBS.china.huawei.com>
On Mon, May 14, 2018 at 4:11 AM, songxiaowei <songxiaowei@hisilicon.com> wrote:
>> > + int ret;
>> > +
>> > + if (IS_ENABLED(CONFIG_PCI_MSI)) {
>>
>> > + pci->pp.msi_irq = platform_get_irq(pdev, 0);
>> > + if (pci->pp.msi_irq < 0) {
>> > + dev_err(&pdev->dev, "failed to get MSI IRQ
>> (%d)\n",
>> > + pci->pp.msi_irq);
>>
>> > + return -ENODEV;
>>
>> Why shadowing actual error code?
> [songxiaowei] Sorry, I can't get your point about this, would you explain it for me.
platform_get_irq() returns either correct IRQ number or negative error code.
In the code above you shadow the actual error (as returned by that
call) by -ENODEV. Any reason why?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] ARM: dts: socfpga: Fix NAND controller node compatible
From: Steffen Trumtrar @ 2018-05-14 7:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180510125223.16056-1-marex@denx.de>
Marek Vasut <marex@denx.de> writes:
> The compatible string for the Denali NAND controller is
> incorrect,
> fix it by replacing it with one matching the DT bindings and the
> driver.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Fixes: d837a80d19 ("ARM: dts: socfpga: add nand controller
> nodes")
> Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> Cc: Dinh Nguyen <dinguyen@kernel.org>
> ---
> arch/arm/boot/dts/socfpga.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/socfpga.dtsi
> b/arch/arm/boot/dts/socfpga.dtsi
> index 7e24dc8e82d4..d697f5062624 100644
> --- a/arch/arm/boot/dts/socfpga.dtsi
> +++ b/arch/arm/boot/dts/socfpga.dtsi
> @@ -744,7 +744,7 @@
> nand0: nand at ff900000 {
> #address-cells = <0x1>;
> #size-cells = <0x1>;
> - compatible = "denali,denali-nand-dt";
> + compatible = "altr,socfpga-denali-nand";
> reg = <0xff900000 0x100000>,
> <0xffb80000 0x10000>;
> reg-names = "nand_data", "denali_reg";
Ack. As the binding was changed after d837a80d19 this is obviously
correct.
@Dinh: Maybe you also want to cleanup the socfpga_arria10.dtsi? It
has
both compatibles, but the "denali,denali-nand-dt" seems to be
obsolete.
Thanks,
Steffen
--
Pengutronix e.K. | Steffen Trumtrar
|
Industrial Linux Solutions |
http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone:
+49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax:
+49-5121-206917-5555 |
^ permalink raw reply
* Allwinner A64: Issue on external rtc clock to wifi chip
From: Jagan Teki @ 2018-05-14 7:07 UTC (permalink / raw)
To: linux-arm-kernel
Hi Maxime and All,
We are trying to bring-up AP6330 Wifi chip for A64 board. We noticed
to have an external rtc clock has driven from wifi chip.
So the devicetree is configured according to this as below.
/ {
wifi_pwrseq: wifi-pwrseq {
compatible = "mmc-pwrseq-simple";
clocks = <&rtc 1>;
clock-names = "ext_clock";
reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
post-power-on-delay-ms = <400>;
};
};
&rtc {
clock-output-names = "rtc-osc32k", "rtc-osc32k-out";
clocks = <&osc32k>;
#clock-cells = <1>;
};
&mmc1 {
pinctrl-names = "default";
pinctrl-0 = <&mmc1_pins>;
vmmc-supply = <®_dcdc1>;
vqmmc-supply = <®_eldo1>;
mmc-pwrseq = <&wifi_pwrseq>;
bus-width = <4>;
non-removable;
status = "okay";
brcmf: wifi at 1 {
reg = <1>;
compatible = "brcm,bcm4329-fmac";
interrupt-parent = <&r_pio>;
interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* WL-WAKE-AP: PL3 */
interrupt-names = "host-wake";
};
};
And observed rtc-osc32k-out clock is never enabled[1] and the value of
LOSC_OUT_GATING is 0x0 which eventually not enabling
LOSC_OUT_GATING_EN
Pls. let us know if we miss anything here?
[1] https://paste.ubuntu.com/p/X2By4q8kD2/
Jagan.
--
Jagan Teki
Senior Linux Kernel Engineer | Amarula Solutions
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply
* [GIT PULL] i.MX fixes for 4.17
From: Shawn Guo @ 2018-05-14 6:33 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-fixes-4.17
for you to fetch changes up to 6d3299aef7df7225ecff653feedafb5d1646998b:
ARM: dts: imx51-zii-rdu1: fix touchscreen bindings (2018-05-11 13:50:27 +0800)
----------------------------------------------------------------
i.MX fixes for 4.17:
- Add missing 'fsl,sec-era' property for i.MX7S device tree CAAM node,
as the era information is used in various places inside CAAM driver.
- There are a few errors in imx51-zii-rdu1 device tree touchscreen
node. Fix them to get touchscreen actually work.
----------------------------------------------------------------
Fabio Estevam (1):
ARM: dts: imx7s: Pass the 'fsl,sec-era' property
Nikita Yushchenko (1):
ARM: dts: imx51-zii-rdu1: fix touchscreen bindings
arch/arm/boot/dts/imx51-zii-rdu1.dts | 6 +++---
arch/arm/boot/dts/imx7s.dtsi | 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH v2 04/13] soc: rockchip: power-domain: Fix wrong value when power up pd
From: Greg KH @ 2018-05-14 6:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268578-9361-1-git-send-email-zhangqing@rock-chips.com>
On Mon, May 14, 2018 at 11:29:38AM +0800, Elaine Zhang wrote:
> From: Finley Xiao <finley.xiao@rock-chips.com>
>
> Solve the pd could only ever turn off but never turn them on again,
> If the pd registers have the writemask bits.
>
> Fix up the code error for commit:
> commit 79bb17ce8edb3141339b5882e372d0ec7346217c
> Author: Elaine Zhang <zhangqing@rock-chips.com>
> Date: Fri Dec 23 11:47:52 2016 +0800
>
> soc: rockchip: power-domain: Support domain control in hiword-registers
>
> New Rockchips SoCs may have their power-domain control in registers
> using a writemask-based access scheme (upper 16bit being the write
> mask). So add a DOMAIN_M type and handle this case accordingly.
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
>
> Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> ---
> drivers/soc/rockchip/pm_domains.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
^ permalink raw reply
* [PATCH V3] ARM: dts: da850-evm: Enable LCD and Backlight
From: Sekhar Nori @ 2018-05-14 5:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513232033.22571-1-aford173@gmail.com>
Hi Adam,
On Monday 14 May 2018 04:50 AM, Adam Ford wrote:
> When using the board files the LCD works, but not with the DT.
> This adds enables the original da850-evm to work with the same
> LCD in device tree mode.
>
> The EVM has a gpio for the regulator and a gpio enable. The LCD and
> the vpif display pins are mutually exclusive, so if using the LCD,
> do not load the vpif driver.
Its not sufficient just note this in patch description.
a) Disable (status = "disabled") the VPIF node which clashes for pins
with LCD.
b) Add a comment on top of the status = "disabled" giving information on
how user can enable it (disable lcdc node and then change to status =
"okay").
>
> Signed-off-by: Adam Ford <aford173@gmail.com>
> ---
> V3: Fix errant GPIO, label GPIO pins, and rename the regulator to be more explict to
> backlight which better matches the schematic. Updated the description to explain
> that it cannot be used at the same time as the vpif driver.
>
> V2: Add regulator and GPIO enable pins. Remove PWM backlight and replace with GPIO
>
> diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
> index 2e817da37fdb..3f1c8be07efe 100644
> --- a/arch/arm/boot/dts/da850-evm.dts
> +++ b/arch/arm/boot/dts/da850-evm.dts
> @@ -27,6 +27,50 @@
> spi0 = &spi1;
> };
>
> + backlight {
> + compatible = "gpio-backlight";
> + enable-gpios = <&gpio 7 GPIO_ACTIVE_HIGH>; /* GP0[7] */
The gpio-backlight binding does not describe a property called
enable-gpios. It should just be gpios.
a) Are you using gpio-backlight because you are not able to get the PWM
to work?
b) What is GP0[7] connected to in the schematic you have? In the
schematic I have I see LCD_PWM0 is connected to
SPI1_SCS[0]/EPWM1B/GP2[14]/TM64P3_IN12.
c) The /* GP0[7] */ comment is not really useful on its own as it can be
computed. What I wanted to see is the schematic symbol like "LCD_PWM0".
Same for other places like this below.
> @@ -35,6 +79,16 @@
> regulator-boot-on;
> };
>
> + backlight_reg: backlight-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "lcd_backlight_pwr";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio 47 GPIO_ACTIVE_HIGH>; /* GP2[15] */
> + regulator-always-on;
Why should this regulator never be disabled?
Thanks,
Sekhar
^ permalink raw reply
* [PATCH RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Icenowy Zheng @ 2018-05-14 5:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v66F_Ho2OZdrF3p6xe9mQ=zJZ_KjE9MnW1VmWs9jw65eEg@mail.gmail.com>
? 2018?5?14? GMT+08:00 ??12:59:22, Chen-Yu Tsai <wens@csie.org> ??:
>On Sun, May 13, 2018 at 1:29 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> On Sun, May 13, 2018 at 01:11:08PM -0700, Chen-Yu Tsai wrote:
>>> On Sun, May 13, 2018 at 1:05 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>> >> > Hi Chen-Yu
>>> >> >
>>> >> > Are these delays the MAC applies? Not the PHY. It would be good
>to
>>> >> > make it clear here these are MAC imposed delays.
>>> >>
>>> >> Yes these are applied on the MAC side. Being described in the
>device
>>> >> tree bindings for the MAC, I thought this was implied to be the
>case?
>>> >> Are there known exceptions?
>>> >
>>> > There is frequent confusion with this. Most of the time, the PHY
>does
>>> > the delay, not the MAC, based on the phy-mode. So the MAC doing it
>is
>>> > an exception in itself.
>>> >
>>> > Do you actually need these delays for the board you adding support
>>> > for? Does the PHY not support adding the needed delays? If you
>don't
>>> > need the delays, i would not even implement them.
>>>
>>> Yes this is already used on the Bananapi M3. This patch merely
>reformats
>>> the description and adds a note saying this only applies to RGMII
>mode.
>>
>> Yes, the current code is needed for the Bananapi M3. But you have
>> another patch which extends the code to support a smaller range. Do
>> you have a board which actually needs this? If not, i would not add
>> that new code.
>
>IIRC the delay on the PHY side is either 2ns or none. The delay on the
>MAC side here is an order smaller, likely fine tuning to cope with
>board
>design deficiencies.
And the weird thing is that the delay fails to work on some batches
of RTL8211E, notably many cases are shown on Pine A64+
board.
P.S. The delay is intended to be set via wires on PCB, other than
by software. Although Realtek provided some magic numbers
to Pine64, in order to fix the network problem due to PHY
delay failure.
>
>Currently no other board requires this, but this is already part of the
>binding. The new stuff limits the range for a specific SoC, simply
>because
>that is the range supported by the control register. Not implementing,
>i.e.
>supporting the whole range from the property, which might get
>truncated,
>doesn't make much sense to me.
>
>Regards
>ChenYu
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] arm64: Clear the stack
From: Mark Rutland @ 2018-05-14 5:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f180b312-d1cf-3992-4e89-9632c1674cd6@linux.com>
On Sun, May 13, 2018 at 11:40:07AM +0300, Alexander Popov wrote:
> It seems that previously I was very "lucky" to accidentally have those MIN_STACK_LEFT,
> call trace depth and oops=panic together to experience a hang on stack overflow
> during BUG().
>
>
> When I run my test in a loop _without_ VMAP_STACK, I manage to corrupt the neighbour
> processes with BUG() handling overstepping the stack boundary. It's a pity, but
> I have an idea.
I think that in the absence of VMAP_STACK, there will always be cases where we
*could* corrupt a neighbouring stack, but I agree that trying to minimize that
possibility would be good.
> In kernel/sched/core.c we already have:
>
> #ifdef CONFIG_SCHED_STACK_END_CHECK
> if (task_stack_end_corrupted(prev))
> panic("corrupted stack end detected inside scheduler\n");
> #endif
>
> So what would you think if I do the following in check_alloca():
>
> if (size >= stack_left) {
> #if !defined(CONFIG_VMAP_STACK) && defined(CONFIG_SCHED_STACK_END_CHECK)
> panic("alloca over the kernel stack boundary\n");
> #else
> BUG();
> #endif
Given this is already out-of-line, how about we always use panic(), regardless
of VMAP_STACK and SCHED_STACK_END_CHECK? i.e. just
if (unlikely(size >= stack_left))
panic("alloca over the kernel stack boundary");
If we have VMAP_STACK selected, and overflow during the panic, it's the same as
if we overflowed during the BUG(). It's likely that panic() will use less stack
space than BUG(), and the compiler can put the call in a slow path that
shouldn't affect most calls, so in all cases it's likely preferable.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v6 3/6] kernel/reboot.c: export pm_power_off_prepare
From: Oleksij Rempel @ 2018-05-14 5:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a431b0e1-f4f4-1439-f0bf-736018c6ab0c@pengutronix.de>
On 14.05.2018 06:33, Oleksij Rempel wrote:
>
>
> On 12.05.2018 13:13, Rafael J. Wysocki wrote:
>> On Friday, May 4, 2018 8:50:52 PM CEST Oleksij Rempel wrote:
>>> Hallo Andrew,
>>> I need your ACK or NACK for this patch.
>>>
>>> This function is used to configure external PMIC to interpret
>>> signal which will be triggered by pm_power_off as power off.
>>> Since same signal can be used for stand by, I linked PMIC configuration
>>> with pm_power_off_prepare to avoid possible conflicts.
>>>
>>> On Mon, Mar 05, 2018 at 11:25:20AM +0100, Oleksij Rempel wrote:
>>>> Export pm_power_off_prepare. It is needed to implement power off on
>>>> Freescale/NXP iMX6 based boards with external power management
>>>> integrated circuit (PMIC).
>>>>
>>>> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
>>>> ---
>>>> kernel/reboot.c | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/kernel/reboot.c b/kernel/reboot.c
>>>> index e4ced883d8de..350be6baa60d 100644
>>>> --- a/kernel/reboot.c
>>>> +++ b/kernel/reboot.c
>>>> @@ -49,6 +49,7 @@ int reboot_force;
>>>> */
>>>>
>>>> void (*pm_power_off_prepare)(void);
>>>> +EXPORT_SYMBOL(pm_power_off_prepare);
>>
>> Why not EXPORT_SYMBOL_GPL() ?
>
> No special reason. Fixed.
> Any other comments?
>
Or with other words, will it be enough to get your Signed-of-by for this
patch?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180514/3f63f47f/attachment-0001.sig>
^ permalink raw reply
* [PATCH RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Chen-Yu Tsai @ 2018-05-14 4:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513202938.GH12738@lunn.ch>
On Sun, May 13, 2018 at 1:29 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Sun, May 13, 2018 at 01:11:08PM -0700, Chen-Yu Tsai wrote:
>> On Sun, May 13, 2018 at 1:05 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> >> > Hi Chen-Yu
>> >> >
>> >> > Are these delays the MAC applies? Not the PHY. It would be good to
>> >> > make it clear here these are MAC imposed delays.
>> >>
>> >> Yes these are applied on the MAC side. Being described in the device
>> >> tree bindings for the MAC, I thought this was implied to be the case?
>> >> Are there known exceptions?
>> >
>> > There is frequent confusion with this. Most of the time, the PHY does
>> > the delay, not the MAC, based on the phy-mode. So the MAC doing it is
>> > an exception in itself.
>> >
>> > Do you actually need these delays for the board you adding support
>> > for? Does the PHY not support adding the needed delays? If you don't
>> > need the delays, i would not even implement them.
>>
>> Yes this is already used on the Bananapi M3. This patch merely reformats
>> the description and adds a note saying this only applies to RGMII mode.
>
> Yes, the current code is needed for the Bananapi M3. But you have
> another patch which extends the code to support a smaller range. Do
> you have a board which actually needs this? If not, i would not add
> that new code.
IIRC the delay on the PHY side is either 2ns or none. The delay on the
MAC side here is an order smaller, likely fine tuning to cope with board
design deficiencies.
Currently no other board requires this, but this is already part of the
binding. The new stuff limits the range for a specific SoC, simply because
that is the range supported by the control register. Not implementing, i.e.
supporting the whole range from the property, which might get truncated,
doesn't make much sense to me.
Regards
ChenYu
^ permalink raw reply
* [PATCH v6 3/6] kernel/reboot.c: export pm_power_off_prepare
From: Oleksij Rempel @ 2018-05-14 4:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1937901.oyadCYFYNo@aspire.rjw.lan>
On 12.05.2018 13:13, Rafael J. Wysocki wrote:
> On Friday, May 4, 2018 8:50:52 PM CEST Oleksij Rempel wrote:
>> Hallo Andrew,
>> I need your ACK or NACK for this patch.
>>
>> This function is used to configure external PMIC to interpret
>> signal which will be triggered by pm_power_off as power off.
>> Since same signal can be used for stand by, I linked PMIC configuration
>> with pm_power_off_prepare to avoid possible conflicts.
>>
>> On Mon, Mar 05, 2018 at 11:25:20AM +0100, Oleksij Rempel wrote:
>>> Export pm_power_off_prepare. It is needed to implement power off on
>>> Freescale/NXP iMX6 based boards with external power management
>>> integrated circuit (PMIC).
>>>
>>> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
>>> ---
>>> kernel/reboot.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/kernel/reboot.c b/kernel/reboot.c
>>> index e4ced883d8de..350be6baa60d 100644
>>> --- a/kernel/reboot.c
>>> +++ b/kernel/reboot.c
>>> @@ -49,6 +49,7 @@ int reboot_force;
>>> */
>>>
>>> void (*pm_power_off_prepare)(void);
>>> +EXPORT_SYMBOL(pm_power_off_prepare);
>
> Why not EXPORT_SYMBOL_GPL() ?
No special reason. Fixed.
Any other comments?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180514/8e85cd06/attachment.sig>
^ permalink raw reply
* [PATCH v2 13/13] soc: rockchip: power-domain: add power domain support for px30
From: Elaine Zhang @ 2018-05-14 3:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268455-9133-1-git-send-email-zhangqing@rock-chips.com>
From: Finley Xiao <finley.xiao@rock-chips.com>
This driver is modified to support PX30 SoC.
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
drivers/soc/rockchip/pm_domains.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 90dcd5e21ae6..d0c5615132e3 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -18,6 +18,7 @@
#include <linux/clk.h>
#include <linux/regmap.h>
#include <linux/mfd/syscon.h>
+#include <dt-bindings/power/px30-power.h>
#include <dt-bindings/power/rk3036-power.h>
#include <dt-bindings/power/rk3128-power.h>
#include <dt-bindings/power/rk3228-power.h>
@@ -114,6 +115,9 @@ struct rockchip_pmu {
.active_wakeup = wakeup, \
}
+#define DOMAIN_PX30(pwr, status, req, wakeup) \
+ DOMAIN_M(pwr, status, req, (req) + 16, req, wakeup)
+
#define DOMAIN_RK3288(pwr, status, req, wakeup) \
DOMAIN(pwr, status, req, req, (req) + 16, wakeup)
@@ -712,6 +716,17 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
return error;
}
+static const struct rockchip_domain_info px30_pm_domains[] = {
+ [PX30_PD_USB] = DOMAIN_PX30(5, 5, 10, false),
+ [PX30_PD_SDCARD] = DOMAIN_PX30(8, 8, 9, false),
+ [PX30_PD_GMAC] = DOMAIN_PX30(10, 10, 6, false),
+ [PX30_PD_MMC_NAND] = DOMAIN_PX30(11, 11, 5, false),
+ [PX30_PD_VPU] = DOMAIN_PX30(12, 12, 14, false),
+ [PX30_PD_VO] = DOMAIN_PX30(13, 13, 7, false),
+ [PX30_PD_VI] = DOMAIN_PX30(14, 14, 8, false),
+ [PX30_PD_GPU] = DOMAIN_PX30(15, 15, 2, false),
+};
+
static const struct rockchip_domain_info rk3036_pm_domains[] = {
[RK3036_PD_MSCH] = DOMAIN_RK3036(14, 23, 30, true),
[RK3036_PD_CORE] = DOMAIN_RK3036(13, 17, 24, false),
@@ -811,6 +826,17 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
[RK3399_PD_SDIOAUDIO] = DOMAIN_RK3399(31, 31, 29, true),
};
+static const struct rockchip_pmu_info px30_pmu = {
+ .pwr_offset = 0x18,
+ .status_offset = 0x20,
+ .req_offset = 0x64,
+ .idle_offset = 0x6c,
+ .ack_offset = 0x6c,
+
+ .num_domains = ARRAY_SIZE(px30_pm_domains),
+ .domain_info = px30_pm_domains,
+};
+
static const struct rockchip_pmu_info rk3036_pmu = {
.req_offset = 0x148,
.idle_offset = 0x14c,
@@ -915,6 +941,10 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
static const struct of_device_id rockchip_pm_domain_dt_match[] = {
{
+ .compatible = "rockchip,px30-power-controller",
+ .data = (void *)&px30_pmu,
+ },
+ {
.compatible = "rockchip,rk3036-power-controller",
.data = (void *)&rk3036_pmu,
},
--
1.9.1
^ permalink raw reply related
* [PATCH v2 12/13] dt-bindings: add binding for px30 power domains
From: Elaine Zhang @ 2018-05-14 3:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268455-9133-1-git-send-email-zhangqing@rock-chips.com>
From: Finley Xiao <finley.xiao@rock-chips.com>
Add binding documentation for the power domains
found on Rockchip PX30 SoCs.
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
Documentation/devicetree/bindings/soc/rockchip/power_domain.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
index affe36dcfa17..5d49d0a2ff29 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
+++ b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
@@ -5,6 +5,7 @@ powered up/down by software based on different application scenes to save power.
Required properties for power domain controller:
- compatible: Should be one of the following.
+ "rockchip,px30-power-controller" - for PX30 SoCs.
"rockchip,rk3036-power-controller" - for RK3036 SoCs.
"rockchip,rk3128-power-controller" - for RK3128 SoCs.
"rockchip,rk3228-power-controller" - for RK3228 SoCs.
@@ -20,6 +21,7 @@ Required properties for power domain controller:
Required properties for power domain sub nodes:
- reg: index of the power domain, should use macros in:
+ "include/dt-bindings/power/px30-power.h" - for PX30 type power domain.
"include/dt-bindings/power/rk3036-power.h" - for RK3036 type power domain.
"include/dt-bindings/power/rk3128-power.h" - for RK3128 type power domain.
"include/dt-bindings/power/rk3228-power.h" - for RK3228 type power domain.
@@ -99,6 +101,7 @@ Node of a device using power domains must have a power-domains property,
containing a phandle to the power device node and an index specifying which
power domain to use.
The index should use macros in:
+ "include/dt-bindings/power/px30-power.h" - for px30 type power domain.
"include/dt-bindings/power/rk3036-power.h" - for rk3036 type power domain.
"include/dt-bindings/power/rk3128-power.h" - for rk3128 type power domain.
"include/dt-bindings/power/rk3128-power.h" - for rk3228 type power domain.
--
1.9.1
^ permalink raw reply related
* [PATCH v2 11/13] dt-bindings: power: add PX30 SoCs header for power-domain
From: Elaine Zhang @ 2018-05-14 3:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268455-9133-1-git-send-email-zhangqing@rock-chips.com>
From: Finley Xiao <finley.xiao@rock-chips.com>
According to a description from TRM, add all the power domains.
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
include/dt-bindings/power/px30-power.h | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
create mode 100644 include/dt-bindings/power/px30-power.h
diff --git a/include/dt-bindings/power/px30-power.h b/include/dt-bindings/power/px30-power.h
new file mode 100644
index 000000000000..4ed482e80950
--- /dev/null
+++ b/include/dt-bindings/power/px30-power.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#ifndef __DT_BINDINGS_POWER_PX30_POWER_H__
+#define __DT_BINDINGS_POWER_PX30_POWER_H__
+
+/* VD_CORE */
+#define PX30_PD_A35_0 0
+#define PX30_PD_A35_1 1
+#define PX30_PD_A35_2 2
+#define PX30_PD_A35_3 3
+#define PX30_PD_SCU 4
+
+/* VD_LOGIC */
+#define PX30_PD_USB 5
+#define PX30_PD_DDR 6
+#define PX30_PD_SDCARD 7
+#define PX30_PD_CRYPTO 8
+#define PX30_PD_GMAC 9
+#define PX30_PD_MMC_NAND 10
+#define PX30_PD_VPU 11
+#define PX30_PD_VO 12
+#define PX30_PD_VI 13
+#define PX30_PD_GPU 14
+
+/* VD_PMU */
+#define PX30_PD_PMU 15
+
+#endif
--
1.9.1
^ permalink raw reply related
* [PATCH v2 10/13] soc: rockchip: power-domain: add power domain support for rk3228
From: Elaine Zhang @ 2018-05-14 3:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268455-9133-1-git-send-email-zhangqing@rock-chips.com>
This driver is modified to support RK3228 SoC.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
drivers/soc/rockchip/pm_domains.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 99a2dd8a7801..90dcd5e21ae6 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -20,6 +20,7 @@
#include <linux/mfd/syscon.h>
#include <dt-bindings/power/rk3036-power.h>
#include <dt-bindings/power/rk3128-power.h>
+#include <dt-bindings/power/rk3228-power.h>
#include <dt-bindings/power/rk3288-power.h>
#include <dt-bindings/power/rk3328-power.h>
#include <dt-bindings/power/rk3366-power.h>
@@ -729,6 +730,20 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
[RK3128_PD_GPU] = DOMAIN_RK3288(1, 1, 3, false),
};
+static const struct rockchip_domain_info rk3228_pm_domains[] = {
+ [RK3228_PD_CORE] = DOMAIN_RK3036(0, 0, 16, true),
+ [RK3228_PD_MSCH] = DOMAIN_RK3036(1, 1, 17, true),
+ [RK3228_PD_BUS] = DOMAIN_RK3036(2, 2, 18, true),
+ [RK3228_PD_SYS] = DOMAIN_RK3036(3, 3, 19, true),
+ [RK3228_PD_VIO] = DOMAIN_RK3036(4, 4, 20, false),
+ [RK3228_PD_VOP] = DOMAIN_RK3036(5, 5, 21, false),
+ [RK3228_PD_VPU] = DOMAIN_RK3036(6, 6, 22, false),
+ [RK3228_PD_RKVDEC] = DOMAIN_RK3036(7, 7, 23, false),
+ [RK3228_PD_GPU] = DOMAIN_RK3036(8, 8, 24, false),
+ [RK3228_PD_PERI] = DOMAIN_RK3036(9, 9, 25, true),
+ [RK3228_PD_GMAC] = DOMAIN_RK3036(10, 10, 26, false),
+};
+
static const struct rockchip_domain_info rk3288_pm_domains[] = {
[RK3288_PD_VIO] = DOMAIN_RK3288(7, 7, 4, false),
[RK3288_PD_HEVC] = DOMAIN_RK3288(14, 10, 9, false),
@@ -816,6 +831,15 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
.domain_info = rk3128_pm_domains,
};
+static const struct rockchip_pmu_info rk3228_pmu = {
+ .req_offset = 0x40c,
+ .idle_offset = 0x488,
+ .ack_offset = 0x488,
+
+ .num_domains = ARRAY_SIZE(rk3228_pm_domains),
+ .domain_info = rk3228_pm_domains,
+};
+
static const struct rockchip_pmu_info rk3288_pmu = {
.pwr_offset = 0x08,
.status_offset = 0x0c,
@@ -899,6 +923,10 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
.data = (void *)&rk3128_pmu,
},
{
+ .compatible = "rockchip,rk3228-power-controller",
+ .data = (void *)&rk3228_pmu,
+ },
+ {
.compatible = "rockchip,rk3288-power-controller",
.data = (void *)&rk3288_pmu,
},
--
1.9.1
^ permalink raw reply related
* [PATCH v2 09/13] dt-bindings: add binding for rk3228 power domains
From: Elaine Zhang @ 2018-05-14 3:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268455-9133-1-git-send-email-zhangqing@rock-chips.com>
Add binding documentation for the power domains
found on Rockchip RK3228 SoCs.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
Documentation/devicetree/bindings/soc/rockchip/power_domain.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
index 9a3f5fd36a80..affe36dcfa17 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
+++ b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
@@ -7,6 +7,7 @@ Required properties for power domain controller:
- compatible: Should be one of the following.
"rockchip,rk3036-power-controller" - for RK3036 SoCs.
"rockchip,rk3128-power-controller" - for RK3128 SoCs.
+ "rockchip,rk3228-power-controller" - for RK3228 SoCs.
"rockchip,rk3288-power-controller" - for RK3288 SoCs.
"rockchip,rk3328-power-controller" - for RK3328 SoCs.
"rockchip,rk3366-power-controller" - for RK3366 SoCs.
@@ -21,6 +22,7 @@ Required properties for power domain sub nodes:
- reg: index of the power domain, should use macros in:
"include/dt-bindings/power/rk3036-power.h" - for RK3036 type power domain.
"include/dt-bindings/power/rk3128-power.h" - for RK3128 type power domain.
+ "include/dt-bindings/power/rk3228-power.h" - for RK3228 type power domain.
"include/dt-bindings/power/rk3288-power.h" - for RK3288 type power domain.
"include/dt-bindings/power/rk3328-power.h" - for RK3328 type power domain.
"include/dt-bindings/power/rk3366-power.h" - for RK3366 type power domain.
@@ -99,6 +101,7 @@ power domain to use.
The index should use macros in:
"include/dt-bindings/power/rk3036-power.h" - for rk3036 type power domain.
"include/dt-bindings/power/rk3128-power.h" - for rk3128 type power domain.
+ "include/dt-bindings/power/rk3128-power.h" - for rk3228 type power domain.
"include/dt-bindings/power/rk3288-power.h" - for rk3288 type power domain.
"include/dt-bindings/power/rk3328-power.h" - for rk3328 type power domain.
"include/dt-bindings/power/rk3366-power.h" - for rk3366 type power domain.
--
1.9.1
^ permalink raw reply related
* [PATCH v2 08/13] dt-bindings: power: add RK3228 SoCs header for power-domain
From: Elaine Zhang @ 2018-05-14 3:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268455-9133-1-git-send-email-zhangqing@rock-chips.com>
According to a description from TRM, add all the power domains.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
include/dt-bindings/power/rk3228-power.h | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
create mode 100644 include/dt-bindings/power/rk3228-power.h
diff --git a/include/dt-bindings/power/rk3228-power.h b/include/dt-bindings/power/rk3228-power.h
new file mode 100644
index 000000000000..fa1264d5a995
--- /dev/null
+++ b/include/dt-bindings/power/rk3228-power.h
@@ -0,0 +1,26 @@
+/*
+ * Copyright (c) 2018 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#ifndef __DT_BINDINGS_POWER_RK3228_POWER_H__
+#define __DT_BINDINGS_POWER_RK3228_POWER_H__
+
+/**
+ * RK3228 idle id Summary.
+ */
+
+#define RK3228_PD_CORE 0
+#define RK3228_PD_MSCH 1
+#define RK3228_PD_BUS 2
+#define RK3228_PD_SYS 3
+#define RK3228_PD_VIO 4
+#define RK3228_PD_VOP 5
+#define RK3228_PD_VPU 6
+#define RK3228_PD_RKVDEC 7
+#define RK3228_PD_GPU 8
+#define RK3228_PD_PERI 9
+#define RK3228_PD_GMAC 10
+
+#endif
--
1.9.1
^ permalink raw reply related
* [PATCH v2 07/13] soc: rockchip: power-domain: add power domain support for rk3128
From: Elaine Zhang @ 2018-05-14 3:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268455-9133-1-git-send-email-zhangqing@rock-chips.com>
This driver is modified to support RK3128 SoC.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
drivers/soc/rockchip/pm_domains.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 01d4ba26a054..99a2dd8a7801 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -19,6 +19,7 @@
#include <linux/regmap.h>
#include <linux/mfd/syscon.h>
#include <dt-bindings/power/rk3036-power.h>
+#include <dt-bindings/power/rk3128-power.h>
#include <dt-bindings/power/rk3288-power.h>
#include <dt-bindings/power/rk3328-power.h>
#include <dt-bindings/power/rk3366-power.h>
@@ -720,6 +721,14 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
[RK3036_PD_SYS] = DOMAIN_RK3036(8, 22, 29, false),
};
+static const struct rockchip_domain_info rk3128_pm_domains[] = {
+ [RK3128_PD_CORE] = DOMAIN_RK3288(0, 0, 4, false),
+ [RK3128_PD_MSCH] = DOMAIN_RK3288(-1, -1, 6, true),
+ [RK3128_PD_VIO] = DOMAIN_RK3288(3, 3, 2, false),
+ [RK3128_PD_VIDEO] = DOMAIN_RK3288(2, 2, 1, false),
+ [RK3128_PD_GPU] = DOMAIN_RK3288(1, 1, 3, false),
+};
+
static const struct rockchip_domain_info rk3288_pm_domains[] = {
[RK3288_PD_VIO] = DOMAIN_RK3288(7, 7, 4, false),
[RK3288_PD_HEVC] = DOMAIN_RK3288(14, 10, 9, false),
@@ -796,6 +805,17 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
.domain_info = rk3036_pm_domains,
};
+static const struct rockchip_pmu_info rk3128_pmu = {
+ .pwr_offset = 0x04,
+ .status_offset = 0x08,
+ .req_offset = 0x0c,
+ .idle_offset = 0x10,
+ .ack_offset = 0x10,
+
+ .num_domains = ARRAY_SIZE(rk3128_pm_domains),
+ .domain_info = rk3128_pm_domains,
+};
+
static const struct rockchip_pmu_info rk3288_pmu = {
.pwr_offset = 0x08,
.status_offset = 0x0c,
@@ -875,6 +895,10 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
.data = (void *)&rk3036_pmu,
},
{
+ .compatible = "rockchip,rk3128-power-controller",
+ .data = (void *)&rk3128_pmu,
+ },
+ {
.compatible = "rockchip,rk3288-power-controller",
.data = (void *)&rk3288_pmu,
},
--
1.9.1
^ permalink raw reply related
* [PATCH v2 06/13] dt-bindings: add binding for rk3128 power domains
From: Elaine Zhang @ 2018-05-14 3:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268455-9133-1-git-send-email-zhangqing@rock-chips.com>
Add binding documentation for the power domains
found on Rockchip RK3128 SoCs.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
Documentation/devicetree/bindings/soc/rockchip/power_domain.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
index 79924ee9ae86..9a3f5fd36a80 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
+++ b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
@@ -6,6 +6,7 @@ powered up/down by software based on different application scenes to save power.
Required properties for power domain controller:
- compatible: Should be one of the following.
"rockchip,rk3036-power-controller" - for RK3036 SoCs.
+ "rockchip,rk3128-power-controller" - for RK3128 SoCs.
"rockchip,rk3288-power-controller" - for RK3288 SoCs.
"rockchip,rk3328-power-controller" - for RK3328 SoCs.
"rockchip,rk3366-power-controller" - for RK3366 SoCs.
@@ -19,6 +20,7 @@ Required properties for power domain controller:
Required properties for power domain sub nodes:
- reg: index of the power domain, should use macros in:
"include/dt-bindings/power/rk3036-power.h" - for RK3036 type power domain.
+ "include/dt-bindings/power/rk3128-power.h" - for RK3128 type power domain.
"include/dt-bindings/power/rk3288-power.h" - for RK3288 type power domain.
"include/dt-bindings/power/rk3328-power.h" - for RK3328 type power domain.
"include/dt-bindings/power/rk3366-power.h" - for RK3366 type power domain.
@@ -96,6 +98,7 @@ containing a phandle to the power device node and an index specifying which
power domain to use.
The index should use macros in:
"include/dt-bindings/power/rk3036-power.h" - for rk3036 type power domain.
+ "include/dt-bindings/power/rk3128-power.h" - for rk3128 type power domain.
"include/dt-bindings/power/rk3288-power.h" - for rk3288 type power domain.
"include/dt-bindings/power/rk3328-power.h" - for rk3328 type power domain.
"include/dt-bindings/power/rk3366-power.h" - for rk3366 type power domain.
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox