* Re: [PATCH 2/2] dt: Add bindings for IDT VersaClock 5P49V5925
From: Stephen Boyd @ 2020-05-29 4:05 UTC (permalink / raw)
To: Adam Ford, linux-clk
Cc: aford, charles.stevens, Adam Ford, Michael Turquette, Rob Herring,
Marek Vasut, devicetree, linux-kernel
In-Reply-To: <20200404161537.2312297-2-aford173@gmail.com>
Quoting Adam Ford (2020-04-04 09:15:36)
> IDT VersaClock 5 5P49V6965 has 5 clock outputs, 4 fractional dividers.
>
> Signed-off-by: Adam Ford <aford173@gmail.com>
>
> diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
> index 05a245c9df08..bcff681a4bd0 100644
> --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
Applied to clk-next
BTW, the patch format threw my scripts off because there isn't a triple
dash after the SoB line.
^ permalink raw reply
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Viresh Kumar @ 2020-05-29 4:07 UTC (permalink / raw)
To: Rob Herring
Cc: Jassi Brar, Arnd Bergmann, Frank Rowand, Bjorn Andersson,
Vincent Guittot, linux-arm-kernel, Sudeep Holla, devicetree,
linux-kernel
In-Reply-To: <20200528192005.GA494874@bogus>
On 28-05-20, 13:20, Rob Herring wrote:
> Whether Linux
> requires serializing mailbox accesses is a separate issue. On that side,
> it seems silly to not allow driving the h/w in the most efficient way
> possible.
That's exactly what we are trying to say. The hardware allows us to
write all 32 bits in parallel, without any hardware issues, why
shouldn't we do that ? The delay (which Sudeep will find out, he is
facing issues with hardware access because of lockdown right now)
which may be small in transmitting across a mailbox becomes
significant because of the fact that it happens synchronously and the
receiver will send some sort of acknowledgement (and that depends on
the firmware there) and the kernel needs to wait for it, while the
kernel doesn't really need to. There is no reason IMHO for being
inefficient here while we can do better.
--
viresh
^ permalink raw reply
* Re: [PATCH 0/3] MIPS: Loongson64: Initial LS7A PCH support
From: Huacai Chen @ 2020-05-29 4:13 UTC (permalink / raw)
To: Jiaxun Yang
Cc: Marc Zyngier, Thomas Bogendoerfer, Rob Herring, open list:MIPS,
devicetree, LKML
In-Reply-To: <20200529034338.1137776-1-jiaxun.yang@flygoat.com>
Hi, Jiaxun,
On Fri, May 29, 2020 at 11:45 AM Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
>
> With this series, LS7A and Loongson-3A4000 is finally supported
> note that this series should depend on irqchip support[1], which
> is likely to get merged soon.
>
> Thanks.
>
> [1]: https://lkml.org/lkml/2020/5/16/72
>
> Jiaxun Yang (3):
> dt-bindings: mips: Document two Loongson generic boards
> MIPS: Loongson64: DeviceTree for LS7A PCH
> MIPS: Loongson64:Load LS7A dtbs
>
> .../bindings/mips/loongson/devices.yaml | 8 +
> arch/mips/boot/dts/loongson/Makefile | 5 +-
> .../dts/loongson/loongson3-r4-package.dtsi | 74 +++++++
> .../dts/loongson/loongson3_4core_ls7a.dts | 25 +++
> .../boot/dts/loongson/loongson3_r4_ls7a.dts | 10 +
> arch/mips/boot/dts/loongson/ls7a-pch.dtsi | 185 ++++++++++++++++++
> .../asm/mach-loongson64/builtin_dtbs.h | 2 +
> arch/mips/loongson64/env.c | 56 +++---
> 8 files changed, 342 insertions(+), 23 deletions(-)
> create mode 100644 arch/mips/boot/dts/loongson/loongson3-r4-package.dtsi
> create mode 100644 arch/mips/boot/dts/loongson/loongson3_4core_ls7a.dts
> create mode 100644 arch/mips/boot/dts/loongson/loongson3_r4_ls7a.dts
> create mode 100644 arch/mips/boot/dts/loongson/ls7a-pch.dtsi
I think the naming can be like this: Old processor (Loongson 3A R1~R3)
use loongson64c_ prefix instead of loongson3, new processor (Loongson
3A R4) use loongson64g_ prefix instead of loongson3_r4, and
Loongson-2K use loongson64r_ prefix, this makes them consistent with
their PRID definitions.
>
> --
> 2.27.0.rc0
>
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: clock: mediatek: document clk bindings for Mediatek MT6765 SoC
From: Stephen Boyd @ 2020-05-29 4:19 UTC (permalink / raw)
To: Catalin Marinas, Chunfeng Yun, Evan Green, Fabien Parent,
Joerg Roedel, Macpaul Lin, Marc Zyngier, Mark Rutland, Mars Cheng,
Matthias Brugger, Michael Turquette, Owen Chen, Rob Herring,
Ryder Lee, Sean Wang, Shawn Guo, Weiyi Lu, Will Deacon, Yong Wu,
devicetree, linux-arm-kernel, linux-clk, linux-kernel,
linux-mediatek, mtk01761
Cc: Mediatek WSD Upstream, CC Hwang, Loda Chou
In-Reply-To: <1582278742-1626-2-git-send-email-macpaul.lin@mediatek.com>
Quoting Macpaul Lin (2020-02-21 01:52:18)
> This patch adds the binding documentation for apmixedsys, audsys, camsys,
> imgsys, infracfg, mmsys, pericfg, topckgen
>
> Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
> Signed-off-by: Owen Chen <owen.chen@mediatek.com>
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH 2/5] dt-bindings: clock: mediatek: document clk bindings mipi0a for Mediatek MT6765 SoC
From: Stephen Boyd @ 2020-05-29 4:19 UTC (permalink / raw)
To: Catalin Marinas, Chunfeng Yun, Evan Green, Fabien Parent,
Joerg Roedel, Macpaul Lin, Marc Zyngier, Mark Rutland, Mars Cheng,
Matthias Brugger, Michael Turquette, Owen Chen, Rob Herring,
Ryder Lee, Sean Wang, Shawn Guo, Weiyi Lu, Will Deacon, Yong Wu,
devicetree, linux-arm-kernel, linux-clk, linux-kernel,
linux-mediatek, mtk01761
Cc: Mediatek WSD Upstream, CC Hwang, Loda Chou
In-Reply-To: <1582278742-1626-3-git-send-email-macpaul.lin@mediatek.com>
Quoting Macpaul Lin (2020-02-21 01:52:19)
> This patch adds the binding documentation for mipi0a.
>
> Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
> Signed-off-by: Owen Chen <owen.chen@mediatek.com>
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> ---
Applied to clk-next
^ permalink raw reply
* Re: [RFC PATCH 3/6] dt-bindings: display/bridge/nwl-dsi: Drop mux handling
From: Guido Günther @ 2020-05-29 4:23 UTC (permalink / raw)
To: Rob Herring
Cc: Laurent Pinchart, David Airlie, Daniel Vetter, Shawn Guo,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Andrzej Hajda, Sam Ravnborg, Anson Huang, Leonard Crestez,
Lucas Stach, Peng Fan, Robert Chiras, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20200528195914.GB568887@bogus>
Hi Rob,
On Thu, May 28, 2020 at 01:59:14PM -0600, Rob Herring wrote:
> On Fri, May 15, 2020 at 03:12:12PM +0200, Guido Günther wrote:
> > No need to encode the SoC specifics in the bridge driver. For the
> > imx8mq we can use the mux-input-bridge.
>
> You can't just change bindings like this. You'd still have to support
> the "old" way. But IMO, this way is the right way.
My understanding is that binding stability only applies to released
kernels and this binding never was in released kernel yet. Does it still
apply in this case?
Cheers,
-- Guido
>
> >
> > Signed-off-by: Guido Günther <agx@sigxcpu.org>
> > ---
> > .../devicetree/bindings/display/bridge/nwl-dsi.yaml | 6 ------
> > 1 file changed, 6 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 3/5] dt-bindings: clock: mediatek: document clk bindings vcodecsys for Mediatek MT6765 SoC
From: Stephen Boyd @ 2020-05-29 4:23 UTC (permalink / raw)
To: Catalin Marinas, Chunfeng Yun, Evan Green, Fabien Parent,
Joerg Roedel, Macpaul Lin, Marc Zyngier, Mark Rutland, Mars Cheng,
Matthias Brugger, Michael Turquette, Owen Chen, Rob Herring,
Ryder Lee, Sean Wang, Shawn Guo, Weiyi Lu, Will Deacon, Yong Wu,
devicetree, linux-arm-kernel, linux-clk, linux-kernel,
linux-mediatek, mtk01761
Cc: Mediatek WSD Upstream, CC Hwang, Loda Chou
In-Reply-To: <1582278742-1626-4-git-send-email-macpaul.lin@mediatek.com>
Quoting Macpaul Lin (2020-02-21 01:52:20)
> This patch adds the binding documentation for vcodecsys.
>
> Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
> Signed-off-by: Owen Chen <owen.chen@mediatek.com>
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH 4/5] clk: mediatek: add mt6765 clock IDs
From: Stephen Boyd @ 2020-05-29 4:24 UTC (permalink / raw)
To: Catalin Marinas, Chunfeng Yun, Evan Green, Fabien Parent,
Joerg Roedel, Macpaul Lin, Marc Zyngier, Mark Rutland, Mars Cheng,
Matthias Brugger, Michael Turquette, Owen Chen, Rob Herring,
Ryder Lee, Sean Wang, Shawn Guo, Weiyi Lu, Will Deacon, Yong Wu,
devicetree, linux-arm-kernel, linux-clk, linux-kernel,
linux-mediatek, mtk01761
Cc: Mediatek WSD Upstream, CC Hwang, Loda Chou
In-Reply-To: <1582278742-1626-5-git-send-email-macpaul.lin@mediatek.com>
Quoting Macpaul Lin (2020-02-21 01:52:21)
> From: Mars Cheng <mars.cheng@mediatek.com>
>
> Add MT6765 clock dt-bindings, include topckgen, apmixedsys,
> infracfg, mcucfg and subsystem clocks.
>
> Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
> Signed-off-by: Owen Chen <owen.chen@mediatek.com>
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH 5/5] clk: mediatek: Add MT6765 clock support
From: Stephen Boyd @ 2020-05-29 4:24 UTC (permalink / raw)
To: Catalin Marinas, Chunfeng Yun, Evan Green, Fabien Parent,
Joerg Roedel, Macpaul Lin, Marc Zyngier, Mark Rutland, Mars Cheng,
Matthias Brugger, Michael Turquette, Owen Chen, Rob Herring,
Ryder Lee, Sean Wang, Shawn Guo, Weiyi Lu, Will Deacon, Yong Wu,
devicetree, linux-arm-kernel, linux-clk, linux-kernel,
linux-mediatek, mtk01761
Cc: Mediatek WSD Upstream, CC Hwang, Loda Chou
In-Reply-To: <1582278742-1626-6-git-send-email-macpaul.lin@mediatek.com>
Quoting Macpaul Lin (2020-02-21 01:52:22)
> From: Owen Chen <owen.chen@mediatek.com>
>
> Add MT6765 clock support, include topckgen, apmixedsys,
> infracfg, mcucfg and subsystem clocks.
>
> Signed-off-by: Owen Chen <owen.chen@mediatek.com>
> Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH V2 1/3] clk: vc5: Allow Versaclock driver to support multiple instances
From: Stephen Boyd @ 2020-05-29 4:29 UTC (permalink / raw)
To: Adam Ford, linux-clk
Cc: aford, charles.stevens, Adam Ford, Michael Turquette, Rob Herring,
Marek Vasut, devicetree, linux-kernel
In-Reply-To: <20200502122126.188001-1-aford173@gmail.com>
Quoting Adam Ford (2020-05-02 05:21:24)
> diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
> index fa96659f8023..81255d923f00 100644
> --- a/drivers/clk/clk-versaclock5.c
> +++ b/drivers/clk/clk-versaclock5.c
> @@ -881,6 +871,8 @@ static int vc5_probe(struct i2c_client *client,
> goto err_clk;
> }
>
> + dev_info(&client->dev, "probed");
> +
Please remove this.
> return 0;
>
> err_clk:
^ permalink raw reply
* Re: [PATCH 0/3] MIPS: Loongson64: Initial LS7A PCH support
From: Jiaxun Yang @ 2020-05-29 4:36 UTC (permalink / raw)
To: Huacai Chen
Cc: Marc Zyngier, Thomas Bogendoerfer, Rob Herring, open list:MIPS,
devicetree, LKML
In-Reply-To: <CAAhV-H5B+6drcEiz=JCexa0LC3JAPS0K5WZ0zwndvuKv-e9NRQ@mail.gmail.com>
于 2020年5月29日 GMT+08:00 下午12:13:36, Huacai Chen <chenhc@lemote.com> 写到:
>Hi, Jiaxun,
>
>On Fri, May 29, 2020 at 11:45 AM Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
>>
>> With this series, LS7A and Loongson-3A4000 is finally supported
>> note that this series should depend on irqchip support[1], which
>> is likely to get merged soon.
>>
>> Thanks.
>>
>> [1]: https://lkml.org/lkml/2020/5/16/72
>>
>> Jiaxun Yang (3):
>> dt-bindings: mips: Document two Loongson generic boards
>> MIPS: Loongson64: DeviceTree for LS7A PCH
>> MIPS: Loongson64:Load LS7A dtbs
>>
>> .../bindings/mips/loongson/devices.yaml | 8 +
>> arch/mips/boot/dts/loongson/Makefile | 5 +-
>> .../dts/loongson/loongson3-r4-package.dtsi | 74 +++++++
>> .../dts/loongson/loongson3_4core_ls7a.dts | 25 +++
>> .../boot/dts/loongson/loongson3_r4_ls7a.dts | 10 +
>> arch/mips/boot/dts/loongson/ls7a-pch.dtsi | 185 ++++++++++++++++++
>> .../asm/mach-loongson64/builtin_dtbs.h | 2 +
>> arch/mips/loongson64/env.c | 56 +++---
>> 8 files changed, 342 insertions(+), 23 deletions(-)
>> create mode 100644 arch/mips/boot/dts/loongson/loongson3-r4-package.dtsi
>> create mode 100644 arch/mips/boot/dts/loongson/loongson3_4core_ls7a.dts
>> create mode 100644 arch/mips/boot/dts/loongson/loongson3_r4_ls7a.dts
>> create mode 100644 arch/mips/boot/dts/loongson/ls7a-pch.dtsi
>I think the naming can be like this: Old processor (Loongson 3A R1~R3)
>use loongson64c_ prefix instead of loongson3, new processor (Loongson
>3A R4) use loongson64g_ prefix instead of loongson3_r4, and
>Loongson-2K use loongson64r_ prefix, this makes them consistent with
>their PRID definitions.
DeviceTree bindings have stable ABI. Although they're currently
only used internally in Kernel. I don't think it's a good idea
to rename existing bindings.
Also, Loongson64C/64G/64R never came to a part of Loongson's
official naming. I doubt if end users will recognize these names.
I'd prefer keep naming as is. It's really not a big deal.
Thanks.
>
>>
>> --
>> 2.27.0.rc0
>>
--
Jiaxun Yang
^ permalink raw reply
* Re: [PATCH v8 04/10] OPP: Add support for parsing interconnect bandwidth
From: Viresh Kumar @ 2020-05-29 4:44 UTC (permalink / raw)
To: Georgi Djakov
Cc: vireshk, nm, sboyd, rjw, saravanak, sibis, mka, robh+dt, rnayak,
bjorn.andersson, vincent.guittot, jcrouse, evgreen, linux-pm,
devicetree, linux-kernel
In-Reply-To: <20200512125327.1868-5-georgi.djakov@linaro.org>
On 12-05-20, 15:53, Georgi Djakov wrote:
> struct dev_pm_opp *_opp_allocate(struct opp_table *table)
> {
> struct dev_pm_opp *opp;
> - int count, supply_size;
> + int supply_count, supply_size, icc_size;
>
> /* Allocate space for at least one supply */
> - count = table->regulator_count > 0 ? table->regulator_count : 1;
> - supply_size = sizeof(*opp->supplies) * count;
> + supply_count = table->regulator_count > 0 ? table->regulator_count : 1;
> + supply_size = sizeof(*opp->supplies) * supply_count;
> + icc_size = sizeof(*opp->bandwidth) * table->path_count;
>
> /* allocate new OPP node and supplies structures */
> - opp = kzalloc(sizeof(*opp) + supply_size, GFP_KERNEL);
> + opp = kzalloc(sizeof(*opp) + supply_size + icc_size, GFP_KERNEL);
> +
> if (!opp)
> return NULL;
>
> /* Put the supplies at the end of the OPP structure as an empty array */
> opp->supplies = (struct dev_pm_opp_supply *)(opp + 1);
> + opp->bandwidth = (struct dev_pm_opp_icc_bw *)(opp->supplies + supply_count);
> INIT_LIST_HEAD(&opp->node);
Added this delta here.
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 7302f2631f8d..dfbd3d10410c 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -1330,7 +1330,8 @@ struct dev_pm_opp *_opp_allocate(struct opp_table *table)
/* Put the supplies at the end of the OPP structure as an empty array */
opp->supplies = (struct dev_pm_opp_supply *)(opp + 1);
- opp->bandwidth = (struct dev_pm_opp_icc_bw *)(opp->supplies + supply_count);
+ if (icc_size)
+ opp->bandwidth = (struct dev_pm_opp_icc_bw *)(opp->supplies + supply_count);
INIT_LIST_HEAD(&opp->node);
return opp;
--
viresh
^ permalink raw reply related
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Jassi Brar @ 2020-05-29 5:20 UTC (permalink / raw)
To: Rob Herring
Cc: Viresh Kumar, Arnd Bergmann, Frank Rowand, Bjorn Andersson,
Vincent Guittot, linux-arm-kernel, Sudeep Holla, Devicetree List,
Linux Kernel Mailing List
In-Reply-To: <20200528192005.GA494874@bogus>
On Thu, May 28, 2020 at 2:20 PM Rob Herring <robh@kernel.org> wrote:
>
> On Fri, May 15, 2020 at 10:47:38AM +0530, Viresh Kumar wrote:
> > From: Sudeep Holla <sudeep.holla@arm.com>
> >
> > Hi Rob, Arnd and Jassi,
> >
> > This stuff has been doing rounds on the mailing list since several years
> > now with no agreed conclusion by all the parties. And here is another
> > attempt to get some feedback from everyone involved to close this once
> > and for ever. Your comments will very much be appreciated.
> >
> > The ARM MHU is defined here in the TRM [1] for your reference, which
> > states following:
> >
> > "The MHU drives the signal using a 32-bit register, with all 32
> > bits logically ORed together. The MHU provides a set of
> > registers to enable software to set, clear, and check the status
> > of each of the bits of this register independently. The use of
> > 32 bits for each interrupt line enables software to provide more
> > information about the source of the interrupt. For example, each
> > bit of the register can be associated with a type of event that
> > can contribute to raising the interrupt."
> >
> > On few other platforms, like qcom, similar doorbell mechanism is present
> > with separate interrupt for each of the bits (that's how I understood
> > it), while in case of ARM MHU, there is a single interrupt line for all
> > the 32 bits. Also in case of ARM MHU, these registers and interrupts
> > have 3 copies for different priority levels, i.e. low priority
> > non-secure, high priority non-secure and secure channels.
> >
> > For ARM MHU, both the dt bindings and the Linux driver support 3
> > channels for the different priorities right now and support sending a 32
> > bit data on every transfer in a locked fashion, i.e. only one transfer
> > can be done at once and the other have to wait for it to finish first.
> >
> > Here are the point of view of the parties involved on this subject:
> >
> > Jassi's viewpoint:
> >
> > - Virtualization of channels should be discouraged in software based on
> > specific usecases of the application. This may invite other mailbox
> > driver authors to ask for doing virtualization in their drivers.
> >
> > - In mailbox's terminology, every channel is equivalent to a signal,
> > since there is only one signal generated here by the MHU, there should
> > be only one channel per priority level.
> >
> > - The clients should send data (of just setting 1 bit or many in the 32
> > bit word) using the existing mechanism as the delays due to
> > serialization shouldn't be significant anyway.
> >
> > - The driver supports 90% of the users with the current implementation
> > and it shouldn't be extended to support doorbell and implement two
> > different modes by changing value of #mbox-cells field in bindings.
> >
> > Sudeep (ARM) and myself as well to some extent:
> >
> > - The hardware gives us the capability to write the register in
> > parallel, i.e. we can write 0x800 and 0x400 together without any
> > software locks, and so these 32 bits should be considered as separate
> > channel even if only one interrupt is issued by the hardware finally.
> > This shouldn't be called as virtualization of the channels, as the
> > hardware supports this (as clearly mentioned in the TRM) and it takes
> > care of handling the signal properly.
> >
> > - With serialization, if we use only one channel as today at every
> > priority, if there are 5 requests to send signal to the receiver and
> > the dvfs request is the last one in queue (which may be called from
> > scheduler's hot path with fast switching), it unnecessarily needs to
> > wait for the first four transfers to finish due to the software
> > locking imposed by the mailbox framework. This adds additional delay,
> > maybe of few ms only, which isn't required by the hardware but just by
> > the software and few ms can be important in scheduler's hotpath.
> >
> > - With the current approach it isn't possible to assign different bits
> > (or doorbell numbers) to clients from DT and the only way of doing
> > that without adding new bindings is by extending #mbox-cells to accept
> > a value of 2 as done in this patch.
> >
> > Jassi and Sudeep, I hope I was able to represent both the view points
> > properly here. Please correct me if I have made a mistake here.
> >
> > This is it. It would be nice to get the views of everyone now on this
> > and how should this be handled.
>
> I am perfectly fine with adding another cell which seems appropriate
> here. You can have 5 cells for all I care if that makes sense for
> the h/w. That has nothing to do with the Linux design. Whether Linux
> requires serializing mailbox accesses is a separate issue. On that side,
> it seems silly to not allow driving the h/w in the most efficient way
> possible.
>
The fact that all these bits are backed by one physical signal makes
the firmware implement its own mux-demux'ing scheme. So the choice was
between demux and single signal at a time. Had there been one signal
per bit, the implementation would have definitely been 'efficient'.
And the first platform the driver was developed on, required message
passing over the registers. So now my approach is to make do with what
we have...unless it shows in numbers.
Anyways, if it comes to that, I'd rather a separate "doorbell' driver
than a driver working in two s/w modes.
Thanks.
^ permalink raw reply
* Re: [PATCH] usb/phy-generic: Add support for OTG VBUS supply control
From: Mike Looijmans @ 2020-05-29 5:47 UTC (permalink / raw)
To: Peter Chen
Cc: linux-usb@vger.kernel.org, gregkh@linuxfoundation.org,
robh+dt@kernel.org, balbi@kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20200528112051.GB2604@b29397-desktop>
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: mike.looijmans@topicproducts.com
W: www.topicproducts.com
Please consider the environment before printing this e-mail
On 28-05-2020 13:20, Peter Chen wrote:
> On 20-05-26 16:50:51, Mike Looijmans wrote:
>> This enables support for VBUS on boards where the power is supplied
>> by a regulator. The regulator is enabled when the USB port enters
>> HOST mode.
>>
> Why you don't do this at your host controller driver?
That was my first thought too, but it made more sense to do it here.
It's about how things are connected on the board, and not about the
controller. Also makes for a consistent devicetree when using different
SOCs on the same carrier board.
I already needed this driver to properly reset the USB phy, which the
controller driver also did not do. So it made sense to add the vbus
power control to this driver too.
If you have a strong preference for the controller driver, I can move
this to the DWC3 driver which happens to be the controller for the
latest batch of SOMs.
>
> Peter
>> Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
>> ---
>> .../devicetree/bindings/usb/usb-nop-xceiv.txt | 3 ++
>> drivers/usb/phy/phy-generic.c | 44 ++++++++++++++++++-
>> drivers/usb/phy/phy-generic.h | 2 +
>> 3 files changed, 48 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> index 4dc6a8ee3071..775a19fdb613 100644
>> --- a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> +++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> @@ -16,6 +16,9 @@ Optional properties:
>>
>> - vcc-supply: phandle to the regulator that provides power to the PHY.
>>
>> +- vbus-supply: phandle to the regulator that provides the VBUS power for when
>> + the device is in HOST mode.
>> +
>> - reset-gpios: Should specify the GPIO for reset.
>>
>> - vbus-detect-gpio: should specify the GPIO detecting a VBus insertion
>> diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
>> index 661a229c105d..ebfb90764511 100644
>> --- a/drivers/usb/phy/phy-generic.c
>> +++ b/drivers/usb/phy/phy-generic.c
>> @@ -203,13 +203,43 @@ static int nop_set_host(struct usb_otg *otg, struct usb_bus *host)
>> return 0;
>> }
>>
>> +static int nop_set_vbus(struct usb_otg *otg, bool enabled)
>> +{
>> + struct usb_phy_generic *nop;
>> + int ret;
>> +
>> + if (!otg)
>> + return -ENODEV;
>> +
>> + nop = container_of(otg->usb_phy, struct usb_phy_generic, phy);
>> +
>> + if (!nop->vbus_reg)
>> + return 0;
>> +
>> + if (enabled) {
>> + if (nop->vbus_reg_enabled)
>> + return 0;
>> + ret = regulator_enable(nop->vbus_reg);
>> + if (ret < 0)
>> + return ret;
>> + nop->vbus_reg_enabled = true;
>> + } else {
>> + if (!nop->vbus_reg_enabled)
>> + return 0;
>> + ret = regulator_disable(nop->vbus_reg);
>> + if (ret < 0)
>> + return ret;
>> + nop->vbus_reg_enabled = false;
>> + }
There's a "return 0" missing here, will fix that in v2
>> +}
>> +
>> int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop)
>> {
>> enum usb_phy_type type = USB_PHY_TYPE_USB2;
>> int err = 0;
>>
>> u32 clk_rate = 0;
>> - bool needs_vcc = false, needs_clk = false;
>> + bool needs_vcc = false, needs_clk = false, needs_vbus = false;
>>
>> if (dev->of_node) {
>> struct device_node *node = dev->of_node;
>> @@ -219,6 +249,7 @@ int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop)
>>
>> needs_vcc = of_property_read_bool(node, "vcc-supply");
>> needs_clk = of_property_read_bool(node, "clocks");
>> + needs_vbus = of_property_read_bool(node, "vbus-supply");
>> }
>> nop->gpiod_reset = devm_gpiod_get_optional(dev, "reset",
>> GPIOD_ASIS);
>> @@ -268,6 +299,16 @@ int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop)
>> return -EPROBE_DEFER;
>> }
>>
>> + nop->vbus_reg = devm_regulator_get(dev, "vbus");
>> + if (IS_ERR(nop->vbus_reg)) {
>> + dev_dbg(dev, "Error getting vbus regulator: %ld\n",
>> + PTR_ERR(nop->vbus_reg));
>> + if (needs_vbus)
>> + return -EPROBE_DEFER;
>> +
>> + nop->vbus_reg = NULL;
>> + }
>> +
>> nop->dev = dev;
>> nop->phy.dev = nop->dev;
>> nop->phy.label = "nop-xceiv";
>> @@ -278,6 +319,7 @@ int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop)
>> nop->phy.otg->usb_phy = &nop->phy;
>> nop->phy.otg->set_host = nop_set_host;
>> nop->phy.otg->set_peripheral = nop_set_peripheral;
>> + nop->phy.otg->set_vbus = nop_set_vbus;
>>
>> return 0;
>> }
>> diff --git a/drivers/usb/phy/phy-generic.h b/drivers/usb/phy/phy-generic.h
>> index 7ee80211a688..a3663639ea1e 100644
>> --- a/drivers/usb/phy/phy-generic.h
>> +++ b/drivers/usb/phy/phy-generic.h
>> @@ -14,7 +14,9 @@ struct usb_phy_generic {
>> struct gpio_desc *gpiod_reset;
>> struct gpio_desc *gpiod_vbus;
>> struct regulator *vbus_draw;
>> + struct regulator *vbus_reg;
>> bool vbus_draw_enabled;
>> + bool vbus_reg_enabled;
>> unsigned long mA;
>> unsigned int vbus;
>> };
>> --
>> 2.17.1
>>
--
Mike Looijmans
^ permalink raw reply
* [PATCH v4 0/2] sc16is7xx: IrDA mode and threaded IRQs
From: Daniel Mack @ 2020-05-29 5:50 UTC (permalink / raw)
To: devicetree, linux-serial
Cc: gregkh, robh+dt, jslaby, jringle, m.brock, pascal.huerst,
Daniel Mack
This is a resend of the first two patches of the series to bring IrDA
support to the sc16is7xx driver.
The "linux," prefix is now dropped from the DT property.
The patches are rebased on top of the other 4 that have already been
merged.
Pascal Huerst (2):
dt-bindings: sc16is7xx: Add flag to activate IrDA mode
sc16is7xx: Add flag to activate IrDA mode
.../bindings/serial/nxp,sc16is7xx.txt | 4 ++++
drivers/tty/serial/sc16is7xx.c | 20 +++++++++++++++++++
2 files changed, 24 insertions(+)
--
2.26.2
^ permalink raw reply
* [PATCH v4 2/2] sc16is7xx: Add flag to activate IrDA mode
From: Daniel Mack @ 2020-05-29 5:50 UTC (permalink / raw)
To: devicetree, linux-serial
Cc: gregkh, robh+dt, jslaby, jringle, m.brock, pascal.huerst,
Daniel Mack
In-Reply-To: <20200529055058.1606910-1-daniel@zonque.org>
From: Pascal Huerst <pascal.huerst@gmail.com>
This series of uart controllers is able to work in IrDA mode.
Add per-port flag to the device-tree to enable that feature if needed.
Signed-off-by: Pascal Huerst <pascal.huerst@gmail.com>
Signed-off-by: Daniel Mack <daniel@zonque.org>
---
drivers/tty/serial/sc16is7xx.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c
index 56508e63f9a0..deb55e2ad169 100644
--- a/drivers/tty/serial/sc16is7xx.c
+++ b/drivers/tty/serial/sc16is7xx.c
@@ -315,6 +315,7 @@ struct sc16is7xx_one {
struct kthread_work tx_work;
struct kthread_work reg_work;
struct sc16is7xx_one_config config;
+ bool irda_mode;
};
struct sc16is7xx_port {
@@ -986,6 +987,7 @@ static int sc16is7xx_config_rs485(struct uart_port *port,
static int sc16is7xx_startup(struct uart_port *port)
{
+ struct sc16is7xx_one *one = to_sc16is7xx_one(port, port);
struct sc16is7xx_port *s = dev_get_drvdata(port->dev);
unsigned int val;
@@ -1024,6 +1026,13 @@ static int sc16is7xx_startup(struct uart_port *port)
/* Now, initialize the UART */
sc16is7xx_port_write(port, SC16IS7XX_LCR_REG, SC16IS7XX_LCR_WORD_LEN_8);
+ /* Enable IrDA mode if requested in DT */
+ /* This bit must be written with LCR[7] = 0 */
+ sc16is7xx_port_update(port, SC16IS7XX_MCR_REG,
+ SC16IS7XX_MCR_IRDA_BIT,
+ one->irda_mode ?
+ SC16IS7XX_MCR_IRDA_BIT : 0);
+
/* Enable the Rx and Tx FIFO */
sc16is7xx_port_update(port, SC16IS7XX_EFCR_REG,
SC16IS7XX_EFCR_RXDISABLE_BIT |
@@ -1304,6 +1313,17 @@ static int sc16is7xx_probe(struct device *dev,
sc16is7xx_power(&s->p[i].port, 0);
}
+ if (dev->of_node) {
+ struct property *prop;
+ const __be32 *p;
+ u32 u;
+
+ of_property_for_each_u32(dev->of_node, "irda-mode-ports",
+ prop, p, u)
+ if (u < devtype->nr_uart)
+ s->p[u].irda_mode = true;
+ }
+
/*
* Setup interrupt. We first try to acquire the IRQ line as level IRQ.
* If that succeeds, we can allow sharing the interrupt as well.
--
2.26.2
^ permalink raw reply related
* [PATCH v4 1/2] dt-bindings: sc16is7xx: Add flag to activate IrDA mode
From: Daniel Mack @ 2020-05-29 5:50 UTC (permalink / raw)
To: devicetree, linux-serial
Cc: gregkh, robh+dt, jslaby, jringle, m.brock, pascal.huerst,
Daniel Mack, Rob Herring
In-Reply-To: <20200529055058.1606910-1-daniel@zonque.org>
From: Pascal Huerst <pascal.huerst@gmail.com>
This series of uart controllers is able to work in IrDA mode.
This adds a property to the device tree to enable that feature on
selected ports if needed.
Signed-off-by: Pascal Huerst <pascal.huerst@gmail.com>
Signed-off-by: Daniel Mack <daniel@zonque.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
index c1091a923a89..0fa8e3e43bf8 100644
--- a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
+++ b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
@@ -21,6 +21,8 @@ Optional properties:
the second cell is used to specify the GPIO polarity:
0 = active high,
1 = active low.
+- irda-mode-ports: An array that lists the indices of the port that
+ should operate in IrDA mode.
Example:
sc16is750: sc16is750@51 {
@@ -55,6 +57,8 @@ Optional properties:
the second cell is used to specify the GPIO polarity:
0 = active high,
1 = active low.
+- irda-mode-ports: An array that lists the indices of the port that
+ should operate in IrDA mode.
Example:
sc16is750: sc16is750@0 {
--
2.26.2
^ permalink raw reply related
* [PATCH v2] usb/phy-generic: Add support for OTG VBUS supply control
From: Mike Looijmans @ 2020-05-29 6:00 UTC (permalink / raw)
To: linux-usb
Cc: gregkh, robh+dt, balbi, devicetree, linux-kernel, Mike Looijmans
This enables support for VBUS on boards where the power is supplied
by a regulator. The regulator is enabled when the USB port enters
HOST mode.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
---
v2: Added missing "return 0;" in set_vbus method
.../devicetree/bindings/usb/usb-nop-xceiv.txt | 3 ++
drivers/usb/phy/phy-generic.c | 46 ++++++++++++++++++-
drivers/usb/phy/phy-generic.h | 2 +
3 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
index 4dc6a8ee3071..775a19fdb613 100644
--- a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
+++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
@@ -16,6 +16,9 @@ Optional properties:
- vcc-supply: phandle to the regulator that provides power to the PHY.
+- vbus-supply: phandle to the regulator that provides the VBUS power for when
+ the device is in HOST mode.
+
- reset-gpios: Should specify the GPIO for reset.
- vbus-detect-gpio: should specify the GPIO detecting a VBus insertion
diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index 661a229c105d..69bf39510e27 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -203,13 +203,45 @@ static int nop_set_host(struct usb_otg *otg, struct usb_bus *host)
return 0;
}
+static int nop_set_vbus(struct usb_otg *otg, bool enabled)
+{
+ struct usb_phy_generic *nop;
+ int ret;
+
+ if (!otg)
+ return -ENODEV;
+
+ nop = container_of(otg->usb_phy, struct usb_phy_generic, phy);
+
+ if (!nop->vbus_reg)
+ return 0;
+
+ if (enabled) {
+ if (nop->vbus_reg_enabled)
+ return 0;
+ ret = regulator_enable(nop->vbus_reg);
+ if (ret < 0)
+ return ret;
+ nop->vbus_reg_enabled = true;
+ } else {
+ if (!nop->vbus_reg_enabled)
+ return 0;
+ ret = regulator_disable(nop->vbus_reg);
+ if (ret < 0)
+ return ret;
+ nop->vbus_reg_enabled = false;
+ }
+
+ return 0;
+}
+
int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop)
{
enum usb_phy_type type = USB_PHY_TYPE_USB2;
int err = 0;
u32 clk_rate = 0;
- bool needs_vcc = false, needs_clk = false;
+ bool needs_vcc = false, needs_clk = false, needs_vbus = false;
if (dev->of_node) {
struct device_node *node = dev->of_node;
@@ -219,6 +251,7 @@ int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop)
needs_vcc = of_property_read_bool(node, "vcc-supply");
needs_clk = of_property_read_bool(node, "clocks");
+ needs_vbus = of_property_read_bool(node, "vbus-supply");
}
nop->gpiod_reset = devm_gpiod_get_optional(dev, "reset",
GPIOD_ASIS);
@@ -268,6 +301,16 @@ int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop)
return -EPROBE_DEFER;
}
+ nop->vbus_reg = devm_regulator_get(dev, "vbus");
+ if (IS_ERR(nop->vbus_reg)) {
+ dev_dbg(dev, "Error getting vbus regulator: %ld\n",
+ PTR_ERR(nop->vbus_reg));
+ if (needs_vbus)
+ return -EPROBE_DEFER;
+
+ nop->vbus_reg = NULL;
+ }
+
nop->dev = dev;
nop->phy.dev = nop->dev;
nop->phy.label = "nop-xceiv";
@@ -278,6 +321,7 @@ int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop)
nop->phy.otg->usb_phy = &nop->phy;
nop->phy.otg->set_host = nop_set_host;
nop->phy.otg->set_peripheral = nop_set_peripheral;
+ nop->phy.otg->set_vbus = nop_set_vbus;
return 0;
}
diff --git a/drivers/usb/phy/phy-generic.h b/drivers/usb/phy/phy-generic.h
index 7ee80211a688..a3663639ea1e 100644
--- a/drivers/usb/phy/phy-generic.h
+++ b/drivers/usb/phy/phy-generic.h
@@ -14,7 +14,9 @@ struct usb_phy_generic {
struct gpio_desc *gpiod_reset;
struct gpio_desc *gpiod_vbus;
struct regulator *vbus_draw;
+ struct regulator *vbus_reg;
bool vbus_draw_enabled;
+ bool vbus_reg_enabled;
unsigned long mA;
unsigned int vbus;
};
--
2.17.1
^ permalink raw reply related
* Fwd: [PATCH v3 2/2] media: cec: i2c: ch7322: Add ch7322 CEC controller driver
From: Jeff Chase @ 2020-05-29 6:10 UTC (permalink / raw)
To: linux-media; +Cc: mchehab, Hans Verkuil, robh+dt, devicetree
In-Reply-To: <CALTkaQ2OR+bc2QGeucA5aP3SiM5HLnx5=DoZQ51E_1d99Hb5Uw@mail.gmail.com>
(Resending as plain text, sorry)
> +static int ch7322_cec_adap_enable(struct cec_adapter *adap, bool enable)
> +{
> + struct ch7322 *ch7322 = cec_get_drvdata(adap);
> + int ret;
> +
> + if (enable)
> + ret = ch7322_unmask_interrupt(ch7322);
> + else
> + ret = ch7322_mask_interrupt(ch7322);
> +
> + return ret;
> +}
> +
I just realized that doing this here is broken -- the driver depends
on the interrupt to detect when the physical address changes. I could
mask only the tx/rx interrupt here instead but that is starting to
feel a bit pointless.
I haven't looked into the cec notifier mechanism yet but would it be
better to try to use that instead if possible and just ignore this
device's physical address detection? Then I could do more of a proper
reset in this enable op. But I'm not sure if I can properly associate
the device with an HDMI port on my platform unless I make some changes
to coreboot.
Thanks,
Jeff
^ permalink raw reply
* [PATCH 2/2] rtc: fsl-ftm-alarm: fix freeze(s2idle) doesnot wake
From: Ran Wang @ 2020-05-29 6:10 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Rob Herring, Li Biwen
Cc: linux-rtc, devicetree, linux-kernel, Ran Wang
In-Reply-To: <20200529061035.18912-1-ran.wang_1@nxp.com>
Use dev_pm_set_wake_irq() instead of flag IRQF_NO_SUSPEND to enable
wakeup system feature for both freeze(s2idle) and mem(deep).
Use property 'wakeup-source' to control this feature.
Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
---
drivers/rtc/rtc-fsl-ftm-alarm.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-fsl-ftm-alarm.c b/drivers/rtc/rtc-fsl-ftm-alarm.c
index 756af62..c6945d84 100644
--- a/drivers/rtc/rtc-fsl-ftm-alarm.c
+++ b/drivers/rtc/rtc-fsl-ftm-alarm.c
@@ -21,6 +21,7 @@
#include <linux/rtc.h>
#include <linux/time.h>
#include <linux/acpi.h>
+#include <linux/pm_wakeirq.h>
#define FTM_SC_CLK(c) ((c) << FTM_SC_CLK_MASK_SHIFT)
@@ -41,6 +42,7 @@ struct ftm_rtc {
struct rtc_device *rtc_dev;
void __iomem *base;
bool big_endian;
+ bool wakeup;
u32 alarm_freq;
};
@@ -267,6 +269,9 @@ static int ftm_rtc_probe(struct platform_device *pdev)
return PTR_ERR(rtc->base);
}
+ rtc->wakeup =
+ device_property_read_bool(&pdev->dev, "wakeup-source");
+
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(&pdev->dev, "can't get irq number\n");
@@ -274,7 +279,7 @@ static int ftm_rtc_probe(struct platform_device *pdev)
}
ret = devm_request_irq(&pdev->dev, irq, ftm_rtc_alarm_interrupt,
- IRQF_NO_SUSPEND, dev_name(&pdev->dev), rtc);
+ 0, dev_name(&pdev->dev), rtc);
if (ret < 0) {
dev_err(&pdev->dev, "failed to request irq\n");
return ret;
@@ -286,7 +291,10 @@ static int ftm_rtc_probe(struct platform_device *pdev)
rtc->alarm_freq = (u32)FIXED_FREQ_CLK / (u32)MAX_FREQ_DIV;
rtc->rtc_dev->ops = &ftm_rtc_ops;
- device_init_wakeup(&pdev->dev, true);
+ device_init_wakeup(&pdev->dev, rtc->wakeup);
+ ret = dev_pm_set_wake_irq(&pdev->dev, irq);
+ if (ret)
+ dev_err(&pdev->dev, "irq wake enable failed.\n");
ret = rtc_register_device(rtc->rtc_dev);
if (ret) {
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: rtc: add wakeup-source for FlexTimer
From: Ran Wang @ 2020-05-29 6:10 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Rob Herring, Li Biwen
Cc: linux-rtc, devicetree, linux-kernel, Ran Wang
Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
---
Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt b/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
index fffac74..d7c482c 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
@@ -20,6 +20,7 @@ Required properties:
Optional properties:
- big-endian: If the host controller is big-endian mode, specify this property.
The default endian mode is little-endian.
+- wakeup-source: Enable it as a wakeup source
Example:
rcpm: rcpm@1e34040 {
@@ -32,5 +33,6 @@ ftm_alarm0: timer@2800000 {
compatible = "fsl,ls1088a-ftm-alarm";
reg = <0x0 0x2800000 0x0 0x10000>;
fsl,rcpm-wakeup = <&rcpm 0x0 0x0 0x0 0x0 0x4000 0x0>;
+ wakeup-source;
interrupts = <0 44 4>;
};
--
2.7.4
^ permalink raw reply related
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Viresh Kumar @ 2020-05-29 6:27 UTC (permalink / raw)
To: Jassi Brar
Cc: Rob Herring, Arnd Bergmann, Frank Rowand, Bjorn Andersson,
Vincent Guittot, linux-arm-kernel, Sudeep Holla, Devicetree List,
Linux Kernel Mailing List
In-Reply-To: <CABb+yY3KKpDHTsTBescW_rXmqmLzJh-Ogaotk2n=nYRkfHy2cg@mail.gmail.com>
On 29-05-20, 00:20, Jassi Brar wrote:
> The fact that all these bits are backed by one physical signal makes
I believe that within the IP itself, there must be 32 signals, just
that only one comes out of it all OR'd together. Maybe that can be
verified by writing 0x01 to it multiple times and it should generate
the interrupt only once on the first instance. i.e. writing 1 to any
big again won't raise the interrupt.
> the firmware implement its own mux-demux'ing scheme.
Similar to how the interrupt controllers do it in the kernel, they
receive a single interrupt and then go check its registers/bits to see
which peripheral raised it.
> So the choice was
> between demux and single signal at a time.
Well, the demux is on the firmware side and the kernel may not need to
worry about that, let the platform do it ?
> Had there been one signal
> per bit, the implementation would have definitely been 'efficient'.
I will say 'More efficient', it will still be 'efficient' if we
implement doorbell.
> And the first platform the driver was developed on, required message
> passing over the registers.
I think it was correctly done at that point of time. No doubt about
that.
> So now my approach is to make do with what
> we have...unless it shows in numbers.
ARM's office is closed (lock-down) and he doesn't have remote access
to the board and so was unable to do it until now.
Numbers or no numbers, I don't think there is a question here about
what is the most efficient way of doing it. Doing it in parallel (when
the hardware allows) is surely going to be more efficient. Sending a
signal, getting it processed by the firmware, doing something with it
and then sending an Ack and that being received by kernel will take
time. Why make a queue on the kernel side when we don't have to. :)
> Anyways, if it comes to that, I'd rather a separate "doorbell' driver
> than a driver working in two s/w modes.
I think that would be fine with everyone, if you are fine with that
now (based on plain logic and no numbers), maybe we can get that done
now?
--
viresh
^ permalink raw reply
* [PATCH] dt-bindings: clock: Convert i.MX8QXP LPCG to json-schema
From: Anson Huang @ 2020-05-29 6:21 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, shawnguo, s.hauer, kernel, festevam,
aisheng.dong, linux-clk, devicetree, linux-arm-kernel,
linux-kernel
Cc: Linux-imx
Convert the i.MX8QXP LPCG binding to DT schema format using json-schema.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/clock/imx8qxp-lpcg.txt | 51 ---------------
.../devicetree/bindings/clock/imx8qxp-lpcg.yaml | 72 ++++++++++++++++++++++
2 files changed, 72 insertions(+), 51 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
diff --git a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt
deleted file mode 100644
index 965cfa4..0000000
--- a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt
+++ /dev/null
@@ -1,51 +0,0 @@
-* NXP i.MX8QXP LPCG (Low-Power Clock Gating) Clock bindings
-
-The Low-Power Clock Gate (LPCG) modules contain a local programming
-model to control the clock gates for the peripherals. An LPCG module
-is used to locally gate the clocks for the associated peripheral.
-
-Note:
-This level of clock gating is provided after the clocks are generated
-by the SCU resources and clock controls. Thus even if the clock is
-enabled by these control bits, it might still not be running based
-on the base resource.
-
-Required properties:
-- compatible: Should be one of:
- "fsl,imx8qxp-lpcg-adma",
- "fsl,imx8qxp-lpcg-conn",
- "fsl,imx8qxp-lpcg-dc",
- "fsl,imx8qxp-lpcg-dsp",
- "fsl,imx8qxp-lpcg-gpu",
- "fsl,imx8qxp-lpcg-hsio",
- "fsl,imx8qxp-lpcg-img",
- "fsl,imx8qxp-lpcg-lsio",
- "fsl,imx8qxp-lpcg-vpu"
-- reg: Address and length of the register set
-- #clock-cells: Should be <1>
-
-The clock consumer should specify the desired clock by having the clock
-ID in its "clocks" phandle cell.
-See the full list of clock IDs from:
-include/dt-bindings/clock/imx8qxp-clock.h
-
-Examples:
-
-#include <dt-bindings/clock/imx8qxp-clock.h>
-
-conn_lpcg: clock-controller@5b200000 {
- compatible = "fsl,imx8qxp-lpcg-conn";
- reg = <0x5b200000 0xb0000>;
- #clock-cells = <1>;
-};
-
-usdhc1: mmc@5b010000 {
- compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc";
- interrupt-parent = <&gic>;
- interrupts = <GIC_SPI 232 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x5b010000 0x10000>;
- clocks = <&conn_lpcg IMX8QXP_CONN_LPCG_SDHC0_IPG_CLK>,
- <&conn_lpcg IMX8QXP_CONN_LPCG_SDHC0_PER_CLK>,
- <&conn_lpcg IMX8QXP_CONN_LPCG_SDHC0_HCLK>;
- clock-names = "ipg", "per", "ahb";
-};
diff --git a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
new file mode 100644
index 0000000..d5b6825
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/imx8qxp-lpcg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX8QXP LPCG (Low-Power Clock Gating) Clock bindings
+
+maintainers:
+ - Aisheng Dong <aisheng.dong@nxp.com>
+
+description: |
+ The Low-Power Clock Gate (LPCG) modules contain a local programming
+ model to control the clock gates for the peripherals. An LPCG module
+ is used to locally gate the clocks for the associated peripheral.
+
+ This level of clock gating is provided after the clocks are generated
+ by the SCU resources and clock controls. Thus even if the clock is
+ enabled by these control bits, it might still not be running based
+ on the base resource.
+
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell. See the full list of clock IDs from:
+ include/dt-bindings/clock/imx8-clock.h
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx8qxp-lpcg-adma
+ - fsl,imx8qxp-lpcg-conn
+ - fsl,imx8qxp-lpcg-dc
+ - fsl,imx8qxp-lpcg-dsp
+ - fsl,imx8qxp-lpcg-gpu
+ - fsl,imx8qxp-lpcg-hsio
+ - fsl,imx8qxp-lpcg-img
+ - fsl,imx8qxp-lpcg-lsio
+ - fsl,imx8qxp-lpcg-vpu
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8-clock.h>
+ #include <dt-bindings/firmware/imx/rsrc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ clock-controller@5b200000 {
+ compatible = "fsl,imx8qxp-lpcg-conn";
+ reg = <0x5b200000 0xb0000>;
+ #clock-cells = <1>;
+ };
+
+ mmc@5b010000 {
+ compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc";
+ interrupts = <GIC_SPI 232 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0x5b010000 0x10000>;
+ clocks = <&conn_lpcg IMX_CONN_LPCG_SDHC0_IPG_CLK>,
+ <&conn_lpcg IMX_CONN_LPCG_SDHC0_PER_CLK>,
+ <&conn_lpcg IMX_CONN_LPCG_SDHC0_HCLK>;
+ clock-names = "ipg", "per", "ahb";
+ power-domains = <&pd IMX_SC_R_SDHC_0>;
+ status = "disabled";
+ };
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 0/6] arm64: dts: qcom: smmu/USB nodes and HDK855/HDK865 dts
From: Bjorn Andersson @ 2020-05-29 6:44 UTC (permalink / raw)
To: Jonathan Marek
Cc: linux-arm-msm, Andy Gross,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Rob Herring
In-Reply-To: <0630ae9c-6ae7-b74e-5dd3-0c569bad74f5@marek.ca>
On Thu 28 May 20:15 PDT 2020, Jonathan Marek wrote:
> On 5/28/20 11:05 PM, Bjorn Andersson wrote:
> > On Sat 23 May 19:38 PDT 2020, Jonathan Marek wrote:
> >
> > > Add dts nodes for apps_smmu and USB for both sm8150 and sm8250.
> > >
> > > Also add initial dts files for HDK855 and HDK865, based on mtp dts, with a
> > > few changes. Notably, the HDK865 dts has regulator config changed a bit based
> > > on downstream (I think sm8250-mtp.dts is wrong and copied too much from sm8150).
> >
> > Can you please elaborate on this discrepancy? I do remember seeing
> > something odd when looking at this, but it seems like I didn't document
> > it anywhere...
> >
> > Thanks,
> > Bjorn
> >
>
> Mainly there's a few regulators with different min/max voltage values. For
> example with l16a, downstream has min/max 3024000/3304000 but upstream
> sm8250-mtp has 2704000/2960000. I also added l18a.
>
Thanks, we'll double check these.
Regards,
Bjorn
> > >
> > > Jonathan Marek (6):
> > > arm64: dts: qcom: sm8150: add apps_smmu node
> > > arm64: dts: qcom: sm8250: add apps_smmu node
> > > arm64: dts: qcom: sm8150: Add secondary USB and PHY nodes
> > > arm64: dts: qcom: sm8250: Add USB and PHY device nodes
> > > arm64: dts: qcom: add sm8150 hdk dts
> > > arm64: dts: qcom: add sm8250 hdk dts
> > >
> > > arch/arm64/boot/dts/qcom/Makefile | 2 +
> > > arch/arm64/boot/dts/qcom/sm8150-hdk.dts | 461 ++++++++++++++++++++++++
> > > arch/arm64/boot/dts/qcom/sm8150.dtsi | 180 +++++++++
> > > arch/arm64/boot/dts/qcom/sm8250-hdk.dts | 454 +++++++++++++++++++++++
> > > arch/arm64/boot/dts/qcom/sm8250.dtsi | 287 +++++++++++++++
> > > 5 files changed, 1384 insertions(+)
> > > create mode 100644 arch/arm64/boot/dts/qcom/sm8150-hdk.dts
> > > create mode 100644 arch/arm64/boot/dts/qcom/sm8250-hdk.dts
> > >
> > > --
> > > 2.26.1
> > >
^ permalink raw reply
* Re: [PATCH v4 2/7] dt-bindings: mdf: ti,j721e-system-controller.yaml: Add J721e
From: Roger Quadros @ 2020-05-29 6:55 UTC (permalink / raw)
To: t-kristo, robh; +Cc: kishon, nm, nsekhar, vigneshr, devicetree, linux-kernel
In-Reply-To: <a2d6b4c3-f17f-389b-305e-8be4646aa397@ti.com>
Hi Rob,
On 19/05/2020 16:51, Roger Quadros wrote:
> Add DT binding schema for J721e system controller.
>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
> Changelog:
> v4
> -address comments.
Hope this patch is OK now?
cheers,
-roger
>
> .../mfd/ti,j721e-system-controller.yaml | 76 +++++++++++++++++++
> 1 file changed, 76 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml
>
> diff --git a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml
> new file mode 100644
> index 000000000000..cb28dc480c4c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml
> @@ -0,0 +1,76 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/ti,j721e-system-controller.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI J721e System Controller Registers R/W Device Tree Bindings
> +
> +description: |
> + This represents the Control Module registers (CTRL_MMR0) on the SoC.
> + System controller node represents a register region containing a set
> + of miscellaneous registers. The registers are not cohesive enough to
> + represent as any specific type of device. The typical use-case is
> + for some other node's driver, or platform-specific code, to acquire
> + a reference to the syscon node (e.g. by phandle, node path, or
> + search using a specific compatible value), interrogate the node (or
> + associated OS driver) to determine the location of the registers,
> + and access the registers directly.
> +
> +maintainers:
> + - Kishon Vijay Abraham I <kishon@ti.com>
> + - Roger Quadros <rogerq@ti.com
> +
> +properties:
> + compatible:
> + anyOf:
> + - items:
> + - enum:
> + - ti,j721e-system-controller
> + - const: syscon
> + - const: simple-mfd
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 1
> +
> + ranges:
> + description:
> + Should translate from local addresses to bus addresses.
> +
> +# Optional children
> +
> + "^serdes-ln-ctrl@[0-9a-f]+$":
> + type: object
> + description: |
> + This is the SERDES lane control mux. It should follow the bindings
> + specified in
> + Documentation/devicetree/bindings/mux/reg-mux.txt
> +
> +required:
> + - compatible
> + - reg
> + - "#address-cells"
> + - "#size-cells"
> + - ranges
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + scm_conf: scm-conf@100000 {
> + compatible = "ti,j721e-system-controller", "syscon", "simple-mfd";
> + reg = <0x00100000 0x1c000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + serdes_ln_ctrl: serdes-ln-ctrl@4080 {
> + compatible = "mmio-mux";
> + reg = <0x00004080 0x50>;
> + };
> + };
> +...
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox