* Re: [PATCH] ARM: dts: imx7: fix USB controller 'size' parameter
From: Peter Chen @ 2019-08-30 2:25 UTC (permalink / raw)
To: Thomas Schäfer
Cc: shawnguo@kernel.org, s.hauer@pengutronix.de, dl-linux-imx,
kernel@pengutronix.de, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190829154913.2049-1-thomas.schaefer@kontron.com>
On 19-08-29 17:49:13, Thomas Schaefer wrote:
> Currently the size parameter in the reg property of usbotg and
> usbh nodes in imx7s and imx7d dts includes is set to 0x200 which
> is wrong for the i.MX7 CPU. According to reference manual, spacing
> of USB controller registers is 0x10000 instead.
>
> This patch will fix this and set the 'size' to 0x10000.
>
> Signed-off-by: Thomas Schaefer <thomas.schaefer@kontron.com>
> ---
> arch/arm/boot/dts/imx7d.dtsi | 2 +-
> arch/arm/boot/dts/imx7s.dtsi | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
> index 42528d2812a2..f1b098d28b6e 100644
> --- a/arch/arm/boot/dts/imx7d.dtsi
> +++ b/arch/arm/boot/dts/imx7d.dtsi
> @@ -117,7 +117,7 @@
> &aips3 {
> usbotg2: usb@30b20000 {
> compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
> - reg = <0x30b20000 0x200>;
> + reg = <0x30b20000 0x10000>;
> interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clks IMX7D_USB_CTRL_CLK>;
> fsl,usbphy = <&usbphynop2>;
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index c1a4fff5ceda..9e25fccf33f0 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -1088,7 +1088,7 @@
>
> usbotg1: usb@30b10000 {
> compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
> - reg = <0x30b10000 0x200>;
> + reg = <0x30b10000 0x10000>;
> interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clks IMX7D_USB_CTRL_CLK>;
> fsl,usbphy = <&usbphynop1>;
> @@ -1099,7 +1099,7 @@
>
> usbh: usb@30b30000 {
> compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
> - reg = <0x30b30000 0x200>;
> + reg = <0x30b30000 0x10000>;
> interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clks IMX7D_USB_CTRL_CLK>;
> fsl,usbphy = <&usbphynop3>;
Hi Thomos,
The core controller range is 0x200, from offset 0x200, it is
non-core register, which is used by usbmisc. Fabio said you
met problem at u-boot for this size, what's the problem about
it?
Thanks,
Peter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V2] arm: xen: mm: use __GPF_DMA32 for arm64
From: Peng Fan @ 2019-08-30 2:28 UTC (permalink / raw)
To: sstabellini@kernel.org, linux@armlinux.org.uk,
catalin.marinas@arm.com, will@kernel.org, robin.murphy@arm.com
Cc: xen-devel@lists.xenproject.org, Peng Fan, dl-linux-imx,
linux-arm-kernel@lists.infradead.org
From: Peng Fan <peng.fan@nxp.com>
arm64 shares some code under arch/arm/xen, including mm.c.
However ZONE_DMA is removed by commit
ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
So introduce xen_set_gfp_dma for arm32/arm64 and using __GFP_DMA
for the former and __GFP_DMA32 for the latter.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
V2:
Follow suggestion from Stefano,
introduce static inline void xen_set_gfp_dma(gfp_t *flags) for arm32/arm64, and
for arm64 using __GFP_DMA for the former and __GFP_DMA32 for the latter.
arch/arm/include/asm/xen/page.h | 5 +++++
arch/arm/xen/mm.c | 2 +-
arch/arm64/include/asm/xen/page.h | 5 +++++
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 31bbc803cecb..d08309c45e6c 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -1 +1,6 @@
#include <xen/arm/page.h>
+
+static inline void xen_set_gfp_dma(gfp_t *flags)
+{
+ *flags |= __GFP_DMA;
+}
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index d33b77e9add3..828f49dc95f9 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -28,7 +28,7 @@ unsigned long xen_get_swiotlb_free_pages(unsigned int order)
for_each_memblock(memory, reg) {
if (reg->base < (phys_addr_t)0xffffffff) {
- flags |= __GFP_DMA;
+ xen_set_gfp_dma(&flags);
break;
}
}
diff --git a/arch/arm64/include/asm/xen/page.h b/arch/arm64/include/asm/xen/page.h
index 31bbc803cecb..5eeabf2c6494 100644
--- a/arch/arm64/include/asm/xen/page.h
+++ b/arch/arm64/include/asm/xen/page.h
@@ -1 +1,6 @@
#include <xen/arm/page.h>
+
+static inline void xen_set_gfp_dma(gfp_t *flags)
+{
+ *flags |= __GFP_DMA32;
+}
--
2.16.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] arm64: numa: check the node id before accessing node_to_cpumask_map
From: Yunsheng Lin @ 2019-08-30 2:26 UTC (permalink / raw)
To: will
Cc: mhocko, tglx, anshuman.khandual, linuxarm, linux-kernel, rppt,
cai, akpm, robin.murphy, adobriyan, linux-arm-kernel
Some buggy bios may not set the device' numa id, and dev_to_node
will return -1, which may cause global-out-of-bounds error
detected by KASAN.
This patch changes cpumask_of_node to return cpu_none_mask if the
node is not valid, and sync the cpumask_of_node between the
cpumask_of_node function in numa.h and numa.c.
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
---
arch/arm64/include/asm/numa.h | 6 ++++++
arch/arm64/mm/numa.c | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
index 626ad01..da891ed 100644
--- a/arch/arm64/include/asm/numa.h
+++ b/arch/arm64/include/asm/numa.h
@@ -25,6 +25,12 @@ const struct cpumask *cpumask_of_node(int node);
/* Returns a pointer to the cpumask of CPUs on Node 'node'. */
static inline const struct cpumask *cpumask_of_node(int node)
{
+ if (node >= nr_node_ids || node < 0)
+ return cpu_none_mask;
+
+ if (!node_to_cpumask_map[node])
+ return cpu_online_mask;
+
return node_to_cpumask_map[node];
}
#endif
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 4f241cc..3846313 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -46,7 +46,7 @@ EXPORT_SYMBOL(node_to_cpumask_map);
*/
const struct cpumask *cpumask_of_node(int node)
{
- if (WARN_ON(node >= nr_node_ids))
+ if (WARN_ON(node >= nr_node_ids || node < 0))
return cpu_none_mask;
if (WARN_ON(node_to_cpumask_map[node] == NULL))
--
2.8.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* RE: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Peng Fan @ 2019-08-30 2:47 UTC (permalink / raw)
To: Sudeep Holla
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
f.fainelli@gmail.com, andre.przywara@arm.com,
jassisinghbrar@gmail.com, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190828135802.GB21614@e107155-lin>
> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM
> SMC/HVC mailbox
>
> On Wed, Aug 28, 2019 at 03:02:58AM +0000, Peng Fan wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > The ARM SMC/HVC mailbox binding describes a firmware interface to
> > trigger actions in software layers running in the EL2 or EL3 exception levels.
> > The term "ARM" here relates to the SMC instruction as part of the ARM
> > instruction set, not as a standard endorsed by ARM Ltd.
> >
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > .../devicetree/bindings/mailbox/arm-smc.yaml | 125
> +++++++++++++++++++++
> > 1 file changed, 125 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > new file mode 100644
> > index 000000000000..f8eb28d5e307
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > @@ -0,0 +1,125 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fschemas%2Fmailbox%2Farm-smc.yaml%23&data=02%7
> C01%7Cp
> >
> +eng.fan%40nxp.com%7C37aa729c94944730868b08d72bbfc121%7C686ea1
> d3bc2b4c
> >
> +6fa92cd99c5c301635%7C0%7C1%7C637025974936865698&sdata=Inp
> %2FLs39m
> > +Gv1fe3dZMSaGmgmyWPT6awPh47s3mEtQ%2BQ%3D&reserved=0
> > +$schema:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=02%7C01%7Cpe
> ng.fan%
> >
> +40nxp.com%7C37aa729c94944730868b08d72bbfc121%7C686ea1d3bc2b4c
> 6fa92cd9
> >
> +9c5c301635%7C0%7C1%7C637025974936865698&sdata=jmoR1Qqm7
> 6N5NwDbgFE
> > +Fm8cpdW%2B%2FgqmG9mSGz9mXv58%3D&reserved=0
> > +
> > +title: ARM SMC Mailbox Interface
> > +
> > +maintainers:
> > + - Peng Fan <peng.fan@nxp.com>
> > +
> > +description: |
> > + This mailbox uses the ARM smc (secure monitor call) and hvc
> > +(hypervisor
> > + call) instruction to trigger a mailbox-connected activity in
> > +firmware,
> > + executing on the very same core as the caller. By nature this
> > +operation
> > + is synchronous and this mailbox provides no way for asynchronous
> > +messages
> > + to be delivered the other way round, from firmware to the OS, but
>
>
> > + asynchronous notification could also be supported.
>
> What do you mean by that ? I would prefer to drop the above line unless I am
Ok. Dropped it in v6.
> missing something. IMO it contradicts the previous statement less you
> elaborate more on this.
>
> > However the value of
> > + r0/w0/x0 the firmware returns after the smc call is delivered as a
> > + received message to the mailbox framework, so a synchronous
> > + communication can be established, for a asynchronous notification, no
> value will be returned.
>
> I assume you refer to asynchronous communication from OS to firmware in
> the above statement and "not asynchronous notification" from firmware to
> OS.
Since asynchronous notification dropped, so it should only be
synchronous communication could be established. So I'll
modify it as below:
r0/w0/x0 the firmware returns after the smc call is delivered as a received
message to the mailbox framework, so synchronous communication can be
established
>
> > + The exact meaning of both the action the mailbox triggers as well
> > + as the return value is defined by their users and is not subject to this
> binding.
> > +
> > + One use case of this mailbox is the SCMI interface, which uses
> > + shared memory to transfer commands and parameters, and a mailbox
> to
> > + trigger a function call. This allows SoCs without a separate
> > + management processor (or when such a processor is not available or
> > + used) to use this standardized interface anyway.
> > +
>
> Not sure if reference to SCMI is needed at all but I don't have any objections
> to it, just thought worth mentioning.
>
> > + This binding describes no hardware, but establishes a firmware
> interface.
> > + Upon receiving an SMC using one of the described SMC function
> > + identifiers, the firmware is expected to trigger some mailbox connected
> functionality.
> > + The communication follows the ARM SMC calling convention.
> > + Firmware expects an SMC function identifier in r0 or w0. The
> > + supported identifiers are passed from consumers, or listed in the
> > + the arm,func-ids properties as described below. The firmware can
> > + return one value in the first SMC result register, it is expected
> > + to be an error value, which shall be propagated to the mailbox client.
> > +
> > + Any core which supports the SMC or HVC instruction can be used, as
> > + long as a firmware component running in EL3 or EL2 is handling these
> calls.
> > +
>
>
> Other than the above points, I am fine with it. Once fixed,
>
> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Thanks,
Peng.
>
> Note I haven't reviewed the yaml scheme, but just binding in general.
>
> --
> Regards,
> Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v5 2/2] mailbox: introduce ARM SMC based mailbox
From: Peng Fan @ 2019-08-30 2:50 UTC (permalink / raw)
To: Sudeep Holla
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
f.fainelli@gmail.com, andre.przywara@arm.com,
jassisinghbrar@gmail.com, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190828140217.GC21614@e107155-lin>
> Subject: Re: [PATCH v5 2/2] mailbox: introduce ARM SMC based mailbox
>
> On Wed, Aug 28, 2019 at 03:03:02AM +0000, Peng Fan wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> > Modified from Andre Przywara's v2 patch
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2F&data=02%7C01%7
> Cpeng.fa
> >
> n%40nxp.com%7Ca1e96c6b782d43b2cfb208d72bc05898%7C686ea1d3bc2b
> 4c6fa92cd
> >
> 99c5c301635%7C0%7C0%7C637025977487779923&sdata=rzC%2B4Y1c
> q9Y3tSDFR
> > %2Fsvf5ktk7INP2rwXN%2BXdWCVjNs%3D&reserved=0
> >
> > Cc: Andre Przywara <andre.przywara@arm.com>
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > drivers/mailbox/Kconfig | 7 ++
> > drivers/mailbox/Makefile | 2 +
> > drivers/mailbox/arm-smc-mailbox.c | 215
> > ++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 224 insertions(+)
> > create mode 100644 drivers/mailbox/arm-smc-mailbox.c
> >
>
> [...]
>
> > +static int arm_smc_mbox_probe(struct platform_device *pdev) {
> > + struct device *dev = &pdev->dev;
> > + struct mbox_controller *mbox;
> > + struct arm_smc_chan_data *chan_data;
> > + const char *method;
> > + bool mem_trans = false;
> > + int ret, i;
> > + u32 val;
> > +
> > + if (!of_property_read_u32(dev->of_node, "arm,num-chans", &val)) {
> > + if (!val) {
> > + dev_err(dev, "invalid arm,num-chans value %u\n", val);
> > + return -EINVAL;
> > + }
> > + } else {
> > + return -EINVAL;
> > + }
> > +
> > + if (!of_property_read_string(dev->of_node, "transports", &method)) {
> > + if (!strcmp("mem", method)) {
> > + mem_trans = true;
> > + } else if (!strcmp("reg", method)) {
> > + mem_trans = false;
> > + } else {
> > + dev_warn(dev, "invalid \"transports\" property: %s\n",
> > + method);
> > +
> > + return -EINVAL;
> > + }
> > + } else {
> > + return -EINVAL;
> > + }
> > +
> > + if (!of_property_read_string(dev->of_node, "method", &method)) {
> > + if (!strcmp("hvc", method)) {
> > + invoke_smc_mbox_fn = __invoke_fn_hvc;
> > + } else if (!strcmp("smc", method)) {
> > + invoke_smc_mbox_fn = __invoke_fn_smc;
> > + } else {
> > + dev_warn(dev, "invalid \"method\" property: %s\n",
> > + method);
> > +
> > + return -EINVAL;
> > + }
> > + } else {
> > + return -EINVAL;
> > + }
> > +
> > + mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
> > + if (!mbox)
> > + return -ENOMEM;
> > +
> > + mbox->num_chans = val;
> > + mbox->chans = devm_kcalloc(dev, mbox->num_chans,
> sizeof(*mbox->chans),
> > + GFP_KERNEL);
> > + if (!mbox->chans)
> > + return -ENOMEM;
> > +
> > + chan_data = devm_kcalloc(dev, mbox->num_chans, sizeof(*chan_data),
> > + GFP_KERNEL);
> > + if (!chan_data)
> > + return -ENOMEM;
> > +
> > + for (i = 0; i < mbox->num_chans; i++) {
> > + u32 function_id;
> > +
> > + ret = of_property_read_u32_index(dev->of_node,
> > + "arm,func-ids", i,
> > + &function_id);
>
> I missed it in binding but I thought we agreed to make this "arm,func-ids"
> a required property and not optional ?
Not sure Jassi is fine with it being a required property, but I could convert
it to a required property in V6.
Thanks,
Peng.
>
> --
> Regards,
> Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 0/5] Add HDMI jack support on RK3288
From: Cheng-yi Chiang @ 2019-08-30 2:55 UTC (permalink / raw)
To: Tzung-Bi Shih
Cc: ALSA development, Douglas Anderson, Heiko Stuebner, Liam Girdwood,
David Airlie, dri-devel, Takashi Iwai, tzungbi,
Linux Kernel Mailing List, Hans Verkuil, Andrzej Hajda,
Russell King, Mark Brown, Laurent Pinchart, Daniel Vetter,
linux-rockchip, Dylan Reid, Jaroslav Kysela, linux-arm-kernel
In-Reply-To: <CA+Px+wX4gbntkd6y8NN8xwXpZLD4MH9rTeHcW9+Ndtw=3_mWBw@mail.gmail.com>
On Wed, Jul 17, 2019 at 6:28 PM Tzung-Bi Shih <tzungbi@google.com> wrote:
>
> On Wed, Jul 17, 2019 at 4:33 PM Cheng-Yi Chiang <cychiang@chromium.org> wrote:
> >
> > This patch series supports HDMI jack reporting on RK3288, which uses
> > DRM dw-hdmi driver and hdmi-codec codec driver.
> >
> > The previous discussion about reporting jack status using hdmi-notifier
> > and drm_audio_component is at
> >
> > https://lore.kernel.org/patchwork/patch/1083027/
> >
> > The new approach is to use a callback mechanism that is
> > specific to hdmi-codec.
> >
> > Changes from v4 to v5:
> > - synopsys/Kconfig: Remove the incorrect dependency change in v4.
> > - rockchip/Kconfig: Add dependency of hdmi-codec when it is really need
> > for jack support.
> >
> > Cheng-Yi Chiang (5):
> > ASoC: hdmi-codec: Add an op to set callback function for plug event
> > drm: bridge: dw-hdmi: Report connector status using callback
> > drm: dw-hdmi-i2s: Use fixed id for codec device
> > ASoC: rockchip_max98090: Add dai_link for HDMI
> > ASoC: rockchip_max98090: Add HDMI jack support
> >
> LGTM.
>
> Reviewed-by: Tzung-Bi Shih <tzungbi@google.com>
Hi Daniel,
Do you have further concern on this patch series related to hdmi-codec
and drm part ?
We would like to merge this patch series if possible.
They will be needed in many future chrome projects for HDMI audio jack
detection.
Thanks a lot!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5, 01/32] dt-bindings: mediatek: add binding for mt8183 display
From: CK Hu @ 2019-08-30 5:15 UTC (permalink / raw)
To: yongqiang.niu
Cc: Mark Rutland, devicetree, Philipp Zabel, David Airlie,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Daniel Vetter, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1567090254-15566-2-git-send-email-yongqiang.niu@mediatek.com>
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang.niu@mediatek.com wrote:
> From: Yongqiang Niu <yongqiang.niu@mediatek.com>
>
> Update device tree binding documention for the display subsystem for
> Mediatek MT8183 SOCs
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> .../bindings/display/mediatek/mediatek,display.txt | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,display.txt
>
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,display.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,display.txt
> new file mode 100644
> index 0000000..951d2a8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,display.txt
> @@ -0,0 +1,21 @@
> +Mediatek Display Device
> +============================
> +
> +The Mediatek Display Device provides power control to the system.
> +
> +Required Properties:
> +
> +- compatible: Should be one of:
> + - "mediatek,mt8183-display"
I think this is "mediatek,mt8183-mmsys".
Regards,
CK
> +
> +The Display Device power name are defined in
> +include\dt-bindings\power\mt*-power.h
> +
> +
> +Example:
> +
> +display_components: dispsys@14000000 {
> + compatible = "mediatek,mt8183-display";
> + reg = <0 0x14000000 0 0x1000>;
> + power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
> +};
> \ No newline at end of file
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5, 11/32] drm/mediatek: split DISP_REG_CONFIG_DSI_SEL setting into another use case
From: CK Hu @ 2019-08-30 5:21 UTC (permalink / raw)
To: yongqiang.niu
Cc: Mark Rutland, devicetree, Philipp Zabel, David Airlie,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Daniel Vetter, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1567090254-15566-12-git-send-email-yongqiang.niu@mediatek.com>
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang.niu@mediatek.com wrote:
> From: Yongqiang Niu <yongqiang.niu@mediatek.com>
>
> Here is two modifition in this patch:
> 1.bls->dpi0 and rdma1->dsi are differen usecase,
> Split DISP_REG_CONFIG_DSI_SEL setting into anther usecase
> 2.remove DISP_REG_CONFIG_DPI_SEL setting, DPI_SEL_IN_BLS is 0 and
> this is same with hardware defautl setting,
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 4866a9b..c93e1b7 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -392,10 +392,9 @@ static void mtk_ddp_sout_sel(void __iomem *config_regs,
> } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
> writel_relaxed(BLS_TO_DPI_RDMA1_TO_DSI,
> config_regs + DISP_REG_CONFIG_OUT_SEL);
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI0) {
> writel_relaxed(DSI_SEL_IN_RDMA,
> config_regs + DISP_REG_CONFIG_DSI_SEL);
> - writel_relaxed(DPI_SEL_IN_BLS,
> - config_regs + DISP_REG_CONFIG_DPI_SEL);
As internal discussion, please rewrite this to prevent breaking MT2701
connection. It's better to add comment to address the special usage for
MT2701.
Regards,
CK
> }
> }
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V3 01/10] dt-bindings: soc: Add dvfsrc driver bindings
From: Henry Chen @ 2019-08-30 5:26 UTC (permalink / raw)
To: Rob Herring
Cc: Nicolas Boichat, Weiyi Lu, James Liao, Viresh Kumar, linux-kernel,
Stephen Boyd, Fan Chen, devicetree, Rob Herring, Ryan Case,
Matthias Brugger, linux-mediatek, Georgi Djakov, linux-arm-kernel
In-Reply-To: <20190829191631.GA15714@bogus>
On Thu, 2019-08-29 at 14:16 -0500, Rob Herring wrote:
> On Wed, 28 Aug 2019 20:28:39 +0800, Henry Chen wrote:
> > Document the binding for enabling dvfsrc on MediaTek SoC.
> >
> > Signed-off-by: Henry Chen <henryc.chen@mediatek.com>
> > ---
> > .../devicetree/bindings/soc/mediatek/dvfsrc.txt | 23 ++++++++++++++++++++++
> > include/dt-bindings/soc/mtk,dvfsrc.h | 14 +++++++++++++
> > 2 files changed, 37 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/soc/mediatek/dvfsrc.txt
> > create mode 100644 include/dt-bindings/soc/mtk,dvfsrc.h
> >
>
> Please add Acked-by/Reviewed-by tags when posting new versions. However,
> there's no need to repost patches *only* to add the tags. The upstream
> maintainer will do that for acks received on the version they apply.
>
> If a tag was not added on purpose, please state why and what changed.
Hi Rob,
I'm sorry for the mistake. I stand corrected, and will add tags on next
version.
Henry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5, 12/32] drm/mediatek: add mmsys private data for ddp path config
From: CK Hu @ 2019-08-30 5:27 UTC (permalink / raw)
To: yongqiang.niu
Cc: Mark Rutland, devicetree, Philipp Zabel, David Airlie,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Daniel Vetter, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1567090254-15566-13-git-send-email-yongqiang.niu@mediatek.com>
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang.niu@mediatek.com wrote:
> From: Yongqiang Niu <yongqiang.niu@mediatek.com>
>
> This patch add mmsys private data for ddp path config
> all these register offset and value will be different in future SOC
> add these define into mmsys private data
> u32 ovl0_mout_en;
> u32 rdma1_sout_sel_in;
> u32 rdma1_sout_dsi0;
> u32 dpi0_sel_in;
> u32 dpi0_sel_in_rdma1;
> u32 dsi0_sel_in;
> u32 dsi0_sel_in_rdma1;
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 ++
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 86 +++++++++++++++++++++++----------
> drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 5 ++
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 3 ++
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 3 ++
> 5 files changed, 76 insertions(+), 25 deletions(-)
>
[snip]
>
> void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
> + const struct mtk_mmsys_reg_data *reg_data,
> enum mtk_ddp_comp_id cur,
> enum mtk_ddp_comp_id next)
> {
> unsigned int addr, value, reg;
>
> - value = mtk_ddp_mout_en(cur, next, &addr);
> + value = mtk_ddp_mout_en(reg_data, cur, next, &addr);
> if (value) {
> reg = readl_relaxed(config_regs + addr) | value;
> writel_relaxed(reg, config_regs + addr);
> }
>
> - mtk_ddp_sout_sel(config_regs, cur, next);
> + value = mtk_ddp_sout_sel(reg_data, cur, next, &addr);
> + if (value)
> + writel_relaxed(value, config_regs + addr);
I think the register could be written inside mtk_ddp_sout_sel(), why do
you move out of that function?
Regards,
CK
>
> - value = mtk_ddp_sel_in(cur, next, &addr);
> + value = mtk_ddp_sel_in(reg_data, cur, next, &addr);
> if (value) {
> reg = readl_relaxed(config_regs + addr) | value;
> writel_relaxed(reg, config_regs + addr);
> @@ -420,18 +455,19 @@ void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
> }
>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/5] dt-bindings: dma: ti-edma: Add option for reserved channel ranges
From: Peter Ujfalusi @ 2019-08-30 5:37 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, linux-kernel, vkoul, dmaengine, dan.j.williams,
linux-omap, linux-arm-kernel
In-Reply-To: <20190829224728.GA1198@bogus>
Rob,
On 30/08/2019 1.47, Rob Herring wrote:
> On Fri, Aug 23, 2019 at 03:56:17PM +0300, Peter Ujfalusi wrote:
>> Similarly to paRAM slots, channels can be used by other cores.
>>
>> Add optional property to configure the reserved channel ranges.
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>> ---
>> Documentation/devicetree/bindings/dma/ti-edma.txt | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt
>> index 4bbc94d829c8..1198682ada99 100644
>> --- a/Documentation/devicetree/bindings/dma/ti-edma.txt
>> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
>> @@ -42,6 +42,9 @@ Optional properties:
>> - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
>> the driver, they are allocated to be used by for example the
>> DSP. See example.
>> +- ti,edma-reserved-chan-ranges: channel ranges which should not be used by
>> + the driver, they are allocated to be used by for example the
>> + DSP. See example.
>
> Based on the other thread, I think extending dma-channel-mask to a
> uint32-array makes sense here.
Yes, that is the reason I have asked on that and I'm in progress of
converting the edma driver to use the dma-channel-mask.
Just need to do some shuffling in the driver to get the mask in a form
usable by the driver.
I'll send an updated series early next week.
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5, 12/32] drm/mediatek: add mmsys private data for ddp path config
From: CK Hu @ 2019-08-30 5:40 UTC (permalink / raw)
To: yongqiang.niu
Cc: Mark Rutland, devicetree, Philipp Zabel, David Airlie,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Daniel Vetter, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1567142858.5942.6.camel@mtksdaap41>
Hi, Yongqiang:
On Fri, 2019-08-30 at 13:27 +0800, CK Hu wrote:
> Hi, Yongqiang:
>
> On Thu, 2019-08-29 at 22:50 +0800, yongqiang.niu@mediatek.com wrote:
> > From: Yongqiang Niu <yongqiang.niu@mediatek.com>
> >
> > This patch add mmsys private data for ddp path config
> > all these register offset and value will be different in future SOC
> > add these define into mmsys private data
> > u32 ovl0_mout_en;
> > u32 rdma1_sout_sel_in;
> > u32 rdma1_sout_dsi0;
> > u32 dpi0_sel_in;
> > u32 dpi0_sel_in_rdma1;
> > u32 dsi0_sel_in;
> > u32 dsi0_sel_in_rdma1;
> >
> > Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 ++
> > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 86 +++++++++++++++++++++++----------
> > drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 5 ++
> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 3 ++
> > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 3 ++
> > 5 files changed, 76 insertions(+), 25 deletions(-)
> >
>
> [snip]
>
> >
> > void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
> > + const struct mtk_mmsys_reg_data *reg_data,
> > enum mtk_ddp_comp_id cur,
> > enum mtk_ddp_comp_id next)
> > {
> > unsigned int addr, value, reg;
> >
> > - value = mtk_ddp_mout_en(cur, next, &addr);
> > + value = mtk_ddp_mout_en(reg_data, cur, next, &addr);
> > if (value) {
> > reg = readl_relaxed(config_regs + addr) | value;
> > writel_relaxed(reg, config_regs + addr);
> > }
> >
> > - mtk_ddp_sout_sel(config_regs, cur, next);
> > + value = mtk_ddp_sout_sel(reg_data, cur, next, &addr);
> > + if (value)
> > + writel_relaxed(value, config_regs + addr);
>
> I think the register could be written inside mtk_ddp_sout_sel(), why do
> you move out of that function?
OK, after review other patch, I understand what you do here.
You want to align the method of mtk_ddp_mout_en(), mtk_ddp_sout_sel(),
and mtk_ddp_sel_in(). so modification in these three function would be
the same style. So I think this alignment should be an independent patch
before this patch.
Regards,
CK
>
> Regards,
> CK
>
> >
> > - value = mtk_ddp_sel_in(cur, next, &addr);
> > + value = mtk_ddp_sel_in(reg_data, cur, next, &addr);
> > if (value) {
> > reg = readl_relaxed(config_regs + addr) | value;
> > writel_relaxed(reg, config_regs + addr);
> > @@ -420,18 +455,19 @@ void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
> > }
> >
> >
> >
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5, 13/32] drm/mediatek: move rdma sout from mtk_ddp_mout_en into mtk_ddp_sout_sel
From: CK Hu @ 2019-08-30 5:41 UTC (permalink / raw)
To: yongqiang.niu
Cc: Mark Rutland, devicetree, Philipp Zabel, David Airlie,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Daniel Vetter, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1567090254-15566-14-git-send-email-yongqiang.niu@mediatek.com>
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang.niu@mediatek.com wrote:
> From: Yongqiang Niu <yongqiang.niu@mediatek.com>
>
> This patch move rdma sout from mtk_ddp_mout_en into mtk_ddp_sout_sel
> rdma only has single output, but no multi output,
> all these rdma->dsi/dpi usecase should move to mtk_ddp_sout_sel
Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 90 +++++++++++++++++-----------------
> 1 file changed, 45 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 338cc2f..a5a6689 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -299,51 +299,6 @@ static unsigned int mtk_ddp_mout_en(const struct mtk_mmsys_reg_data *data,
> } else if (cur == DDP_COMPONENT_OD1 && next == DDP_COMPONENT_RDMA1) {
> *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
> value = OD1_MOUT_EN_RDMA1;
> - } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI0) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> - value = RDMA0_SOUT_DPI0;
> - } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI1) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> - value = RDMA0_SOUT_DPI1;
> - } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI1) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> - value = RDMA0_SOUT_DSI1;
> - } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI2) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> - value = RDMA0_SOUT_DSI2;
> - } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI3) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> - value = RDMA0_SOUT_DSI3;
> - } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> - value = RDMA1_SOUT_DSI1;
> - } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI2) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> - value = RDMA1_SOUT_DSI2;
> - } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI3) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> - value = RDMA1_SOUT_DSI3;
> - } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> - *addr = data->rdma1_sout_sel_in;
> - value = data->rdma1_sout_dpi0;
> - } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> - value = RDMA1_SOUT_DPI1;
> - } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> - value = RDMA2_SOUT_DPI0;
> - } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI1) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> - value = RDMA2_SOUT_DPI1;
> - } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI1) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> - value = RDMA2_SOUT_DSI1;
> - } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI2) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> - value = RDMA2_SOUT_DSI2;
> - } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI3) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> - value = RDMA2_SOUT_DSI3;
> } else {
> value = 0;
> }
> @@ -423,6 +378,51 @@ static unsigned int mtk_ddp_sout_sel(const struct mtk_mmsys_reg_data *data,
> } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_OUT_SEL;
> value = BLS_TO_DPI_RDMA1_TO_DSI;
> + } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI0) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> + value = RDMA0_SOUT_DPI0;
> + } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI1) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> + value = RDMA0_SOUT_DPI1;
> + } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI1) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> + value = RDMA0_SOUT_DSI1;
> + } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI2) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> + value = RDMA0_SOUT_DSI2;
> + } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI3) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> + value = RDMA0_SOUT_DSI3;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> + value = RDMA1_SOUT_DSI1;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI2) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> + value = RDMA1_SOUT_DSI2;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI3) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> + value = RDMA1_SOUT_DSI3;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> + *addr = data->rdma1_sout_sel_in;
> + value = data->rdma1_sout_dpi0;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> + value = RDMA1_SOUT_DPI1;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> + value = RDMA2_SOUT_DPI0;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI1) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> + value = RDMA2_SOUT_DPI1;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI1) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> + value = RDMA2_SOUT_DSI1;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI2) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> + value = RDMA2_SOUT_DSI2;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI3) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> + value = RDMA2_SOUT_DSI3;
> } else {
> value = 0;
> }
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/8] media: cedrus: Detect first slice of a frame
From: Boris Brezillon @ 2019-08-30 5:48 UTC (permalink / raw)
To: Jernej Škrabec
Cc: devel, acourbot, pawel, jonas, gregkh, wens, mripard, tfiga,
paul.kocialkowski, kyungmin.park, linux-media, linux-arm-kernel,
hverkuil-cisco, mchehab, ezequiel, linux-kernel, m.szyprowski
In-Reply-To: <3132748.mYbjOY1tKM@jernej-laptop>
On Thu, 29 Aug 2019 21:04:28 +0200
Jernej Škrabec <jernej.skrabec@siol.net> wrote:
> Dne ponedeljek, 26. avgust 2019 ob 20:28:31 CEST je Boris Brezillon
> napisal(a):
> > Hi Jernej,
> >
> > On Thu, 22 Aug 2019 21:44:57 +0200
> >
> > Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> > > When codec supports multiple slices in one frame, VPU has to know when
> > > first slice of each frame is being processed, presumably to correctly
> > > clear/set data in auxiliary buffers.
> > >
> > > Add first_slice field to cedrus_run structure and set it according to
> > > timestamps of capture and output buffers. If timestamps are different,
> > > it's first slice and viceversa.
> > >
> > > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > > ---
> > >
> > > drivers/staging/media/sunxi/cedrus/cedrus.h | 1 +
> > > drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++
> > > 2 files changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > > b/drivers/staging/media/sunxi/cedrus/cedrus.h index
> > > 2f017a651848..32cb38e541c6 100644
> > > --- a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
> > > @@ -70,6 +70,7 @@ struct cedrus_mpeg2_run {
> > >
> > > struct cedrus_run {
> > >
> > > struct vb2_v4l2_buffer *src;
> > > struct vb2_v4l2_buffer *dst;
> > >
> > > + bool first_slice;
> > >
> > > union {
> > >
> > > struct cedrus_h264_run h264;
> > >
> > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > > b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c index
> > > 56ca4c9ad01c..d7b54accfe83 100644
> > > --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > > @@ -31,6 +31,8 @@ void cedrus_device_run(void *priv)
> > >
> > > run.src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> > > run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> > >
> > > + run.first_slice =
> > > + run.src->vb2_buf.timestamp != run.dst-
> >vb2_buf.timestamp;
> >
> > Can't we use slice->first_mb_in_slice to determine if a slice is the
> > first? I'd expect ->first_mb_in_slice to be 0 (unless we decide to
> > support ASO).
>
> I looked in all VPU documentation available to me (which isn't much) and there
> is no indication if ASO is supported or not. Do you have any sample video with
> out-of-order slices? It's my understanding that this is uncommon.
I'm not entirely sure, but my understanding was that it might be used
when streaming over network where some packets might be lost and
re-emitted later on.
> If it's
> supported, I would leave code as-is.
I remember seeing the ASO acronym mentioned in the hantro G1 spec, but
at the same time we're doing frame-based decoding, so I guess the HW
block expects slices to be ordered in that case. Honestly I don't know,
so let's keep the code as-is.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: numa: check the node id before accessing node_to_cpumask_map
From: Michal Hocko @ 2019-08-30 5:55 UTC (permalink / raw)
To: Yunsheng Lin
Cc: tglx, anshuman.khandual, robin.murphy, linuxarm, linux-kernel,
rppt, cai, akpm, will, adobriyan, linux-arm-kernel
In-Reply-To: <1567131991-189761-1-git-send-email-linyunsheng@huawei.com>
On Fri 30-08-19 10:26:31, Yunsheng Lin wrote:
> Some buggy bios may not set the device' numa id, and dev_to_node
> will return -1, which may cause global-out-of-bounds error
> detected by KASAN.
Why should we workaround a buggy bios like that? Is it so widespread and
no BIOS update available? Also, why is this arm64 specific?
> This patch changes cpumask_of_node to return cpu_none_mask if the
> node is not valid, and sync the cpumask_of_node between the
> cpumask_of_node function in numa.h and numa.c.
Why?
> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> ---
> arch/arm64/include/asm/numa.h | 6 ++++++
> arch/arm64/mm/numa.c | 2 +-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
> index 626ad01..da891ed 100644
> --- a/arch/arm64/include/asm/numa.h
> +++ b/arch/arm64/include/asm/numa.h
> @@ -25,6 +25,12 @@ const struct cpumask *cpumask_of_node(int node);
> /* Returns a pointer to the cpumask of CPUs on Node 'node'. */
> static inline const struct cpumask *cpumask_of_node(int node)
> {
> + if (node >= nr_node_ids || node < 0)
> + return cpu_none_mask;
> +
> + if (!node_to_cpumask_map[node])
> + return cpu_online_mask;
> +
> return node_to_cpumask_map[node];
> }
> #endif
> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
> index 4f241cc..3846313 100644
> --- a/arch/arm64/mm/numa.c
> +++ b/arch/arm64/mm/numa.c
> @@ -46,7 +46,7 @@ EXPORT_SYMBOL(node_to_cpumask_map);
> */
> const struct cpumask *cpumask_of_node(int node)
> {
> - if (WARN_ON(node >= nr_node_ids))
> + if (WARN_ON(node >= nr_node_ids || node < 0))
> return cpu_none_mask;
>
> if (WARN_ON(node_to_cpumask_map[node] == NULL))
> --
> 2.8.1
--
Michal Hocko
SUSE Labs
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5, 22/32] drm/mediatek: add ovl0/ovl_2l0 usecase
From: CK Hu @ 2019-08-30 5:58 UTC (permalink / raw)
To: yongqiang.niu
Cc: Mark Rutland, devicetree, Philipp Zabel, David Airlie,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Daniel Vetter, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1567090254-15566-23-git-send-email-yongqiang.niu@mediatek.com>
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang.niu@mediatek.com wrote:
> From: Yongqiang Niu <yongqiang.niu@mediatek.com>
>
> This patch add ovl0/ovl_2l0 usecase
> in ovl->ovl_2l0 direct link usecase:
> 1. the crtc support layer number will 4+2
> 2. ovl_2l0 background color input select ovl0 when crtc init
> and disable it when crtc finish
> 3. config ovl_2l0 layer, if crtc config layer number is
> bigger than ovl0 support layers(max is 4)
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 38 +++++++++++++++++++++++++++++++--
> 1 file changed, 36 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index c63ff2b..b55970a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -270,6 +270,15 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
>
> for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
> struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[i];
> + enum mtk_ddp_comp_id prev;
> +
> + if (i > 0)
> + prev = mtk_crtc->ddp_comp[i - 1]->id;
> + else
> + prev = DDP_COMPONENT_ID_MAX;
> +
> + if (prev == DDP_COMPONENT_OVL0)
> + mtk_ddp_comp_bgclr_in_on(comp);
Even though both OVL and OVL_2L implement this function, I think we
could still call this function for OVL and OVL_2L, and in
mtk_ovl_bgclr_in_on(), to judge it's OVL or OVL_2L.
Regards,
CK
>
> mtk_ddp_comp_config(comp, width, height, vrefresh, bpc);
> mtk_ddp_comp_start(comp);
> @@ -279,9 +288,18 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
> for (i = 0; i < mtk_crtc->layer_nr; i++) {
> struct drm_plane *plane = &mtk_crtc->planes[i];
> struct mtk_plane_state *plane_state;
> + struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
> + unsigned int comp_layer_nr = mtk_ddp_comp_layer_nr(comp);
> + unsigned int local_layer;
>
> plane_state = to_mtk_plane_state(plane->state);
> - mtk_ddp_comp_layer_config(mtk_crtc->ddp_comp[0], i,
> +
> + if (i >= comp_layer_nr) {
> + comp = mtk_crtc->ddp_comp[1];
> + local_layer = i - comp_layer_nr;
> + } else
> + local_layer = i;
> + mtk_ddp_comp_layer_config(comp, local_layer,
> plane_state);
> }
>
> @@ -307,6 +325,7 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc *mtk_crtc)
> mtk_crtc->ddp_comp[i]->id);
> mtk_disp_mutex_disable(mtk_crtc->mutex);
> for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
> + mtk_ddp_comp_bgclr_in_off(mtk_crtc->ddp_comp[i]);
> mtk_ddp_remove_comp_from_path(mtk_crtc->config_regs,
> mtk_crtc->mmsys_reg_data,
> mtk_crtc->ddp_comp[i]->id,
> @@ -327,6 +346,8 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
> struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
> struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
> unsigned int i;
> + unsigned int comp_layer_nr = mtk_ddp_comp_layer_nr(comp);
> + unsigned int local_layer;
>
> /*
> * TODO: instead of updating the registers here, we should prepare
> @@ -349,7 +370,14 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
> plane_state = to_mtk_plane_state(plane->state);
>
> if (plane_state->pending.config) {
> - mtk_ddp_comp_layer_config(comp, i, plane_state);
> + if (i >= comp_layer_nr) {
> + comp = mtk_crtc->ddp_comp[1];
> + local_layer = i - comp_layer_nr;
> + } else
> + local_layer = i;
> +
> + mtk_ddp_comp_layer_config(comp, local_layer,
> + plane_state);
> plane_state->pending.config = false;
> }
> }
> @@ -572,6 +600,12 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> }
>
> mtk_crtc->layer_nr = mtk_ddp_comp_layer_nr(mtk_crtc->ddp_comp[0]);
> + if (mtk_crtc->ddp_comp_nr > 1) {
> + struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[1];
> +
> + if (comp->funcs->bgclr_in_on)
> + mtk_crtc->layer_nr += mtk_ddp_comp_layer_nr(comp);
> + }
> mtk_crtc->planes = devm_kcalloc(dev, mtk_crtc->layer_nr,
> sizeof(struct drm_plane),
> GFP_KERNEL);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Jassi Brar @ 2019-08-30 5:58 UTC (permalink / raw)
To: Peng Fan
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
f.fainelli@gmail.com, andre.przywara@arm.com,
linux-kernel@vger.kernel.org, robh+dt@kernel.org, dl-linux-imx,
sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <1567004515-3567-2-git-send-email-peng.fan@nxp.com>
On Tue, Aug 27, 2019 at 10:02 PM Peng Fan <peng.fan@nxp.com> wrote:
>
> From: Peng Fan <peng.fan@nxp.com>
>
> The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
> actions in software layers running in the EL2 or EL3 exception levels.
> The term "ARM" here relates to the SMC instruction as part of the ARM
> instruction set, not as a standard endorsed by ARM Ltd.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> .../devicetree/bindings/mailbox/arm-smc.yaml | 125 +++++++++++++++++++++
> 1 file changed, 125 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
>
> diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> new file mode 100644
> index 000000000000..f8eb28d5e307
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> @@ -0,0 +1,125 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ARM SMC Mailbox Interface
> +
> +maintainers:
> + - Peng Fan <peng.fan@nxp.com>
> +
> +description: |
> + This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor
> + call) instruction to trigger a mailbox-connected activity in firmware,
> + executing on the very same core as the caller. By nature this operation
> + is synchronous and this mailbox provides no way for asynchronous messages
> + to be delivered the other way round, from firmware to the OS, but
> + asynchronous notification could also be supported. However the value of
> + r0/w0/x0 the firmware returns after the smc call is delivered as a received
> + message to the mailbox framework, so a synchronous communication can be
> + established, for a asynchronous notification, no value will be returned.
> + The exact meaning of both the action the mailbox triggers as well as the
> + return value is defined by their users and is not subject to this binding.
> +
> + One use case of this mailbox is the SCMI interface, which uses shared memory
> + to transfer commands and parameters, and a mailbox to trigger a function
> + call. This allows SoCs without a separate management processor (or when
> + such a processor is not available or used) to use this standardized
> + interface anyway.
> +
> + This binding describes no hardware, but establishes a firmware interface.
> + Upon receiving an SMC using one of the described SMC function identifiers,
> + the firmware is expected to trigger some mailbox connected functionality.
> + The communication follows the ARM SMC calling convention.
> + Firmware expects an SMC function identifier in r0 or w0. The supported
> + identifiers are passed from consumers, or listed in the the arm,func-ids
> + properties as described below. The firmware can return one value in
> + the first SMC result register, it is expected to be an error value,
> + which shall be propagated to the mailbox client.
> +
> + Any core which supports the SMC or HVC instruction can be used, as long as
> + a firmware component running in EL3 or EL2 is handling these calls.
> +
> +properties:
> + compatible:
> + const: arm,smc-mbox
> +
> + "#mbox-cells":
> + const: 1
> +
> + arm,num-chans:
> + description: The number of channels supported.
> + items:
> + minimum: 1
> + maximum: 4096 # Should be enough?
> +
> + method:
> + - enum:
> + - smc
> + - hvc
> +
> + transports:
> + - enum:
> + - mem
> + - reg
> +
> + arm,func-ids:
> + description: |
> + An array of 32-bit values specifying the function IDs used by each
> + mailbox channel. Those function IDs follow the ARM SMC calling
> + convention standard [1].
> +
> + There is one identifier per channel and the number of supported
> + channels is determined by the length of this array.
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + minItems: 0
> + maxItems: 4096 # Should be enough?
> +
> +required:
> + - compatible
> + - "#mbox-cells"
> + - arm,num-chans
> + - transports
> + - method
> +
> +examples:
> + - |
> + sram@910000 {
> + compatible = "mmio-sram";
> + reg = <0x0 0x93f000 0x0 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x0 0x93f000 0x1000>;
> +
> + cpu_scp_lpri: scp-shmem@0 {
> + compatible = "arm,scmi-shmem";
> + reg = <0x0 0x200>;
> + };
> +
> + cpu_scp_hpri: scp-shmem@200 {
> + compatible = "arm,scmi-shmem";
> + reg = <0x200 0x200>;
> + };
> + };
> +
> + firmware {
> + smc_mbox: mailbox {
> + #mbox-cells = <1>;
> + compatible = "arm,smc-mbox";
> + method = "smc";
> + arm,num-chans = <0x2>;
> + transports = "mem";
> + /* Optional */
> + arm,func-ids = <0xc20000fe>, <0xc20000ff>;
>
SMC/HVC is synchronously(block) running in "secure mode", i.e, there
can only be one instance running platform wide. Right? That implies
there is only one physical channel in the platform. So if you need to
initiate different functions (tx, rx), you call them sequentially by
changing the func-id for each request. Why not?
-Jassi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 01/11] dt-bindings: phy-mtk-tphy: add two optional properties for u2phy
From: Chunfeng Yun @ 2019-08-30 6:03 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, linux-kernel, Kishon Vijay Abraham I,
linux-mediatek, Matthias Brugger, linux-arm-kernel
In-Reply-To: <20190829192341.GA26293@bogus>
On Thu, 2019-08-29 at 14:23 -0500, Rob Herring wrote:
> On Fri, Aug 23, 2019 at 03:00:08PM +0800, Chunfeng Yun wrote:
> > Add two optional properties, one for J-K test, another for disconnect
> > threshold, both of them can be used to debug disconnection issues.
>
> Testing and debug properties aren't really things that belong in DT.
They are not only for test and debug, but also used to tune default
value for some platforms, I'll modify the description
>
> >
> > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> > ---
> > Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > index a5f7a4f0dbc1..d5b327f85fa2 100644
> > --- a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > +++ b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > @@ -52,6 +52,8 @@ Optional properties (PHY_TYPE_USB2 port (child) node):
> > - mediatek,eye-vrt : u32, the selection of VRT reference voltage
> > - mediatek,eye-term : u32, the selection of HS_TX TERM reference voltage
> > - mediatek,bc12 : bool, enable BC12 of u2phy if support it
> > +- mediatek,discth : u32, the voltage of disconnect threshold
> > +- mediatek,intr : u32, the value of internal R (resistance)
>
> These need units as defined in property-units.txt.
They are in fact the choice index of different level, will modify it
Thank you
>
> >
> > Example:
> >
> > --
> > 2.23.0
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5, 24/32] drm/mediatek: add clock property check before get it
From: CK Hu @ 2019-08-30 6:11 UTC (permalink / raw)
To: yongqiang.niu
Cc: Mark Rutland, devicetree, Philipp Zabel, David Airlie,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Daniel Vetter, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1567090254-15566-25-git-send-email-yongqiang.niu@mediatek.com>
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang.niu@mediatek.com wrote:
> From: Yongqiang Niu <yongqiang.niu@mediatek.com>
>
> This patch add clock property check before get it
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index a5a6689..effc24a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -657,10 +657,12 @@ static int mtk_ddp_probe(struct platform_device *pdev)
> for (i = 0; i < 10; i++)
> ddp->mutex[i].id = i;
>
> - ddp->clk = devm_clk_get(dev, NULL);
> - if (IS_ERR(ddp->clk)) {
> - dev_err(dev, "Failed to get clock\n");
> - return PTR_ERR(ddp->clk);
> + if (of_find_property(dev->of_node, "clocks", &i)) {
> + ddp->clk = devm_clk_get(dev, NULL);
> + if (IS_ERR(ddp->clk)) {
> + dev_err(dev, "Failed to get clock\n");
> + return PTR_ERR(ddp->clk);
> + }
Only "mediatek,mt8133-disp-mutex" has no clock property. For other SoC,
clock property is required. So I think this exception is just for
mt8183.
Regards,
CK
> }
>
> regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5, 25/32] drm/mediatek: add connection from OVL0 to OVL_2L0
From: CK Hu @ 2019-08-30 6:20 UTC (permalink / raw)
To: yongqiang.niu
Cc: Mark Rutland, devicetree, Philipp Zabel, David Airlie,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Daniel Vetter, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1567090254-15566-26-git-send-email-yongqiang.niu@mediatek.com>
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang.niu@mediatek.com wrote:
> From: Yongqiang Niu <yongqiang.niu@mediatek.com>
>
> This patch add connection from OVL0 to OVL_2L0
Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index effc24a..42a130a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -137,6 +137,8 @@
> #define DPI_SEL_IN_BLS 0x0
> #define DSI_SEL_IN_RDMA 0x1
>
> +#define OVL0_MOUT_EN_OVL0_2L BIT(4)
> +
> struct mtk_disp_mutex {
> int id;
> bool claimed;
> @@ -299,6 +301,9 @@ static unsigned int mtk_ddp_mout_en(const struct mtk_mmsys_reg_data *data,
> } else if (cur == DDP_COMPONENT_OD1 && next == DDP_COMPONENT_RDMA1) {
> *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
> value = OD1_MOUT_EN_RDMA1;
> + } else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_OVL_2L0) {
> + *addr = data->ovl0_mout_en;
> + value = OVL0_MOUT_EN_OVL0_2L;
> } else {
> value = 0;
> }
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 02/11] dt-bindings: phy-mtk-tphy: make the ref clock optional
From: Chunfeng Yun @ 2019-08-30 6:22 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, linux-kernel, Kishon Vijay Abraham I,
linux-mediatek, Matthias Brugger, linux-arm-kernel
In-Reply-To: <20190829192550.GA29881@bogus>
On Thu, 2019-08-29 at 14:25 -0500, Rob Herring wrote:
> On Fri, Aug 23, 2019 at 03:00:09PM +0800, Chunfeng Yun wrote:
> > Make the ref clock optional, then we no need refer to a fixed-clock
> > in DTS anymore when the clock of USB3 PHY comes from oscillator
> > directly
> >
> > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> > ---
> > .../devicetree/bindings/phy/phy-mtk-tphy.txt | 13 +++++++------
> > 1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > index d5b327f85fa2..1c18bf10b2fe 100644
> > --- a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > +++ b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > @@ -34,12 +34,6 @@ Optional properties (controller (parent) node):
> >
> > Required properties (port (child) node):
> > - reg : address and length of the register set for the port.
> > -- clocks : a list of phandle + clock-specifier pairs, one for each
> > - entry in clock-names
> > -- clock-names : must contain
> > - "ref": 48M reference clock for HighSpeed analog phy; and 26M
> > - reference clock for SuperSpeed analog phy, sometimes is
> > - 24M, 25M or 27M, depended on platform.
> > - #phy-cells : should be 1 (See second example)
> > cell after port phandle is phy type from:
> > - PHY_TYPE_USB2
> > @@ -48,6 +42,13 @@ Required properties (port (child) node):
> > - PHY_TYPE_SATA
> >
> > Optional properties (PHY_TYPE_USB2 port (child) node):
> > +- clocks : a list of phandle + clock-specifier pairs, one for each
> > + entry in clock-names
> > +- clock-names : may contain
> > + "ref": 48M reference clock for HighSpeed anolog phy; and 26M
> > + reference clock for SuperSpeed anolog phy, sometimes is
> > + 24M, 25M or 27M, depended on platform.
>
> How do you know the frequency when it is not present?
It's always present, but sometimes it's always on by default (e.g. 48Mhz
of U2 PHY), or comes from oscillator directly (e.g. 26Mhz of U3 PHY),
so not controlled by CCF, of course we can use a fixed-clock in latter
case, it's useful to make it optional for these two cases.
Thanks
>
> > +
> > - mediatek,eye-src : u32, the value of slew rate calibrate
> > - mediatek,eye-vrt : u32, the selection of VRT reference voltage
> > - mediatek,eye-term : u32, the selection of HS_TX TERM reference voltage
> > --
> > 2.23.0
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5, 26/32] drm/mediatek: add connection from RDMA0 to COLOR0
From: CK Hu @ 2019-08-30 6:23 UTC (permalink / raw)
To: yongqiang.niu
Cc: Mark Rutland, devicetree, Philipp Zabel, David Airlie,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Daniel Vetter, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1567090254-15566-27-git-send-email-yongqiang.niu@mediatek.com>
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang.niu@mediatek.com wrote:
> From: Yongqiang Niu <yongqiang.niu@mediatek.com>
>
> This patch add connection from RDMA0 to COLOR0
Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 42a130a..03a46ec 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -171,6 +171,8 @@ struct mtk_ddp {
>
> struct mtk_mmsys_reg_data {
> u32 ovl0_mout_en;
> + u32 rdma0_sout_sel_in;
> + u32 rdma0_sout_color0;
> u32 rdma1_sout_sel_in;
> u32 rdma1_sout_dpi0;
> u32 dpi0_sel_in;
> @@ -428,6 +430,9 @@ static unsigned int mtk_ddp_sout_sel(const struct mtk_mmsys_reg_data *data,
> } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI3) {
> *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> value = RDMA2_SOUT_DSI3;
> + } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_COLOR0) {
> + *addr = data->rdma0_sout_sel_in;
> + value = data->rdma0_sout_color0;
> } else {
> value = 0;
> }
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 04/11] dt-bindings: phy-mtk-tphy: add a new reference clock
From: Chunfeng Yun @ 2019-08-30 6:23 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, linux-kernel, Kishon Vijay Abraham I,
linux-mediatek, Matthias Brugger, linux-arm-kernel
In-Reply-To: <20190829200503.GA2542@bogus>
On Thu, 2019-08-29 at 15:05 -0500, Rob Herring wrote:
> On Fri, Aug 23, 2019 at 03:00:11PM +0800, Chunfeng Yun wrote:
> > Usually the digital and anolog phys use the same reference clock,
> > but on some platforms, they are separated, so add another optional
> > clock to support it.
> > In order to keep the clock names consistent with PHY IP's, use
> > the da_ref for anolog phy and ref clock for digital phy.
> >
> > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> > ---
> > Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt | 7 +++++--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > index dbc143ed5999..ed9a2641f204 100644
> > --- a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > +++ b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > @@ -41,9 +41,12 @@ Optional properties (PHY_TYPE_USB2 port (child) node):
> > - clocks : a list of phandle + clock-specifier pairs, one for each
> > entry in clock-names
> > - clock-names : may contain
> > - "ref": 48M reference clock for HighSpeed anolog phy; and 26M
> > - reference clock for SuperSpeed anolog phy, sometimes is
> > + "ref": 48M reference clock for HighSpeed (digital) phy; and 26M
> > + reference clock for SuperSpeed (digital) phy, sometimes is
> > 24M, 25M or 27M, depended on platform.
> > + "da_ref": the reference clock of anolog phy, used if the clocks
> > + of anolog and digital phys are separated, otherwise uses
>
> s/amolog/analog/
will fix it
>
> > + "ref" clock only if need.
>
> needed.
also here
Thanks a lot
>
> >
> > - mediatek,eye-src : u32, the value of slew rate calibrate
> > - mediatek,eye-vrt : u32, the selection of VRT reference voltage
> > --
> > 2.23.0
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 0/3] perf cs-etm: Add support for callchain
From: Leo Yan @ 2019-08-30 6:24 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Mathieu Poirier, Suzuki K Poulose,
Alexander Shishkin, Jiri Olsa, Namhyung Kim, linux-arm-kernel,
linux-kernel, Mike Leach, Robert Walker, Adrian Hunter
Cc: Leo Yan
This patch seris adds support for instruction sample's callchain.
Patch 01 is to refactor the instruction size calculation; patch 02
is to add thread stack and callchain support; patch 03 is a minor fixing
for instruction sample generation thus the instruction sample can be
alignment with the callchain generation.
Before:
# perf script --itrace=g16l64i100
main 1579 100 instructions: ffff0000102137f0 group_sched_in+0xb0 ([kernel.kallsyms])
main 1579 100 instructions: ffff000010213b78 flexible_sched_in+0xf0 ([kernel.kallsyms])
main 1579 100 instructions: ffff0000102135ac event_sched_in.isra.57+0x74 ([kernel.kallsyms])
main 1579 100 instructions: ffff000010219344 perf_swevent_add+0x6c ([kernel.kallsyms])
main 1579 100 instructions: ffff000010214854 perf_event_update_userpage+0x4c ([kernel.kallsyms])
[...]
After:
# perf script --itrace=g16l64i100
main 1579 100 instructions:
ffff0000102137f0 group_sched_in+0xb0 ([kernel.kallsyms])
main 1579 100 instructions:
ffff000010213b78 flexible_sched_in+0xf0 ([kernel.kallsyms])
ffff00001020c0b4 visit_groups_merge+0x12c ([kernel.kallsyms])
main 1579 100 instructions:
ffff0000102135ac event_sched_in.isra.57+0x74 ([kernel.kallsyms])
ffff0000102137a0 group_sched_in+0x60 ([kernel.kallsyms])
ffff000010213b84 flexible_sched_in+0xfc ([kernel.kallsyms])
ffff00001020c0b4 visit_groups_merge+0x12c ([kernel.kallsyms])
main 1579 100 instructions:
ffff000010219344 perf_swevent_add+0x6c ([kernel.kallsyms])
ffff0000102135f4 event_sched_in.isra.57+0xbc ([kernel.kallsyms])
ffff0000102137a0 group_sched_in+0x60 ([kernel.kallsyms])
ffff000010213b84 flexible_sched_in+0xfc ([kernel.kallsyms])
ffff00001020c0b4 visit_groups_merge+0x12c ([kernel.kallsyms])
main 1579 100 instructions:
ffff000010214854 perf_event_update_userpage+0x4c ([kernel.kallsyms])
ffff000010219360 perf_swevent_add+0x88 ([kernel.kallsyms])
ffff0000102135f4 event_sched_in.isra.57+0xbc ([kernel.kallsyms])
ffff0000102137a0 group_sched_in+0x60 ([kernel.kallsyms])
ffff000010213b84 flexible_sched_in+0xfc ([kernel.kallsyms])
ffff00001020c0b4 visit_groups_merge+0x12c ([kernel.kallsyms])
[...]
Leo Yan (3):
perf cs-etm: Refactor instruction size handling
perf cs-etm: Add callchain to instruction sample
perf cs-etm: Correct the packet usage for instruction sample
tools/perf/util/cs-etm.c | 122 +++++++++++++++++++++++++++++++++------
1 file changed, 105 insertions(+), 17 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 1/3] perf cs-etm: Refactor instruction size handling
From: Leo Yan @ 2019-08-30 6:24 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Mathieu Poirier, Suzuki K Poulose,
Alexander Shishkin, Jiri Olsa, Namhyung Kim, linux-arm-kernel,
linux-kernel, Mike Leach, Robert Walker, Adrian Hunter
Cc: Leo Yan
In-Reply-To: <20190830062421.31275-1-leo.yan@linaro.org>
There has several code pieces need to know the instruction size, but
now every place calculates the instruction size separately.
This patch refactors to create a new function cs_etm__instr_size() as
a central place to analyze the instruction length based on ISA type
and instruction value.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
tools/perf/util/cs-etm.c | 44 +++++++++++++++++++++++++++-------------
1 file changed, 30 insertions(+), 14 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index b3a5daaf1a8f..882a0718033d 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -914,6 +914,26 @@ static inline int cs_etm__t32_instr_size(struct cs_etm_queue *etmq,
return ((instrBytes[1] & 0xF8) >= 0xE8) ? 4 : 2;
}
+static inline int cs_etm__instr_size(struct cs_etm_queue *etmq,
+ u8 trace_chan_id,
+ enum cs_etm_isa isa,
+ u64 addr)
+{
+ int insn_len;
+
+ /*
+ * T32 instruction size might be 32-bit or 16-bit, decide by calling
+ * cs_etm__t32_instr_size().
+ */
+ if (isa == CS_ETM_ISA_T32)
+ insn_len = cs_etm__t32_instr_size(etmq, trace_chan_id, addr);
+ /* Otherwise, A64 and A32 instruction size are always 32-bit. */
+ else
+ insn_len = 4;
+
+ return insn_len;
+}
+
static inline u64 cs_etm__first_executed_instr(struct cs_etm_packet *packet)
{
/* Returns 0 for the CS_ETM_DISCONTINUITY packet */
@@ -938,19 +958,23 @@ static inline u64 cs_etm__instr_addr(struct cs_etm_queue *etmq,
const struct cs_etm_packet *packet,
u64 offset)
{
+ int insn_len;
+
if (packet->isa == CS_ETM_ISA_T32) {
u64 addr = packet->start_addr;
while (offset > 0) {
- addr += cs_etm__t32_instr_size(etmq,
- trace_chan_id, addr);
+ addr += cs_etm__instr_size(etmq, trace_chan_id,
+ packet->isa, addr);
offset--;
}
return addr;
}
- /* Assume a 4 byte instruction size (A32/A64) */
- return packet->start_addr + offset * 4;
+ /* Return instruction size for A32/A64 */
+ insn_len = cs_etm__instr_size(etmq, trace_chan_id,
+ packet->isa, packet->start_addr);
+ return packet->start_addr + offset * insn_len;
}
static void cs_etm__update_last_branch_rb(struct cs_etm_queue *etmq,
@@ -1090,16 +1114,8 @@ static void cs_etm__copy_insn(struct cs_etm_queue *etmq,
return;
}
- /*
- * T32 instruction size might be 32-bit or 16-bit, decide by calling
- * cs_etm__t32_instr_size().
- */
- if (packet->isa == CS_ETM_ISA_T32)
- sample->insn_len = cs_etm__t32_instr_size(etmq, trace_chan_id,
- sample->ip);
- /* Otherwise, A64 and A32 instruction size are always 32-bit. */
- else
- sample->insn_len = 4;
+ sample->insn_len = cs_etm__instr_size(etmq, trace_chan_id,
+ packet->isa, sample->ip);
cs_etm__mem_access(etmq, trace_chan_id, sample->ip,
sample->insn_len, (void *)sample->insn);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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