* [PATCH v14 01/10] dt-binding: gce: remove thread-num property
From: Bibby Hsieh @ 2019-08-29 1:48 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, srv_heupstream, linux-kernel,
Houlong Wei, Dennis-YC Hsieh, linux-mediatek, Bibby Hsieh,
linux-arm-kernel
In-Reply-To: <20190829014817.25482-1-bibby.hsieh@mediatek.com>
"thread-num" is an unused property so we remove it from example.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/mailbox/mtk-gce.txt | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
index 7d72b21c9e94..cfe40b01d164 100644
--- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
+++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
@@ -39,7 +39,6 @@ Example:
interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_LOW>;
clocks = <&infracfg CLK_INFRA_GCE>;
clock-names = "gce";
- thread-num = CMDQ_THR_MAX_COUNT;
#mbox-cells = <3>;
};
--
2.18.0
_______________________________________________
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 v14 00/10] support gce on mt8183 platform
From: Bibby Hsieh @ 2019-08-29 1:48 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, srv_heupstream, linux-kernel,
Houlong Wei, Dennis-YC Hsieh, linux-mediatek, Bibby Hsieh,
linux-arm-kernel
Changes since v13:
- separate poll function as poll w/ & w/o mask function
- directly pass inst into append_command function instead
of returns a pointer
- fixup coding style
- rebase onto 5.3-rc1
Changes since v12:
- clear the value of command ptr address
- fixup some typo and remove unused define
Changes since v11:
- correct some data type to avoid type conversion
Changes since v10:
- remove subsys-cell from gce device node
- use of_parse_phandle_with_fixed_args instead of
of_parse_phandle_with_args
Changes since v8 and v9:
- change the error return code in cmdq_dev_get_client_reg()
Changes since v7:
- remove the memory allocation out of cmdq_dev_get_client_reg()
- rebase onto 5.2-rc1
Changes since v6:
- remove cmdq_dev_get_event function and gce event property
- separate some changes to indepentent patch
- change the binding document related to gce-client-reg property
Changes since v5:
- fix typo
- remove gce-event-name form the dt-binding
- add reasons in commit message
Changes since v4:
- refine the architecture of the packet encoder function
- refine the gce enevt property
- change the patch's title
Changes since v3:
- fix a typo in dt-binding and dtsi
- cast the return value to right format
Changes since v2:
- according to CK's review comment, change the property name and
refine the parameter
- change the patch's title
- remove unused property from dt-binding and dts
Changes since v1:
- add prefix "cmdq" in the commit subject
- add dt-binding document for get event and subsys function
- add fix up tag in fixup patch
- fix up some coding style (alignment)
MTK will support gce function on mt8183 platform.
dt-binding: gce: add gce header file for mt8183
mailbox: mediatek: cmdq: support mt8183 gce function
arm64: dts: add gce node for mt8183
Besides above patches, we refine gce driver on those patches.
mailbox: mediatek: cmdq: move the CMDQ_IRQ_MASK into cmdq driver data
mailbox: mediatek: cmdq: clear the event in cmdq initial flow
In order to enhance the convenience of gce usage, we add new helper functions and refine the method of instruction combining.
dt-binding: gce: remove thread-num property
dt-binding: gce: add binding for gce client reg property
soc: mediatek: cmdq: define the instruction struct
soc: mediatek: cmdq: add polling function
soc: mediatek: cmdq: add cmdq_dev_get_client_reg function
Bibby Hsieh (10):
dt-binding: gce: remove thread-num property
dt-binding: gce: add gce header file for mt8183
dt-binding: gce: add binding for gce client reg property
mailbox: mediatek: cmdq: move the CMDQ_IRQ_MASK into cmdq driver data
mailbox: mediatek: cmdq: support mt8183 gce function
mailbox: mediatek: cmdq: clear the event in cmdq initial flow
soc: mediatek: cmdq: define the instruction struct
soc: mediatek: cmdq: add polling function
soc: mediatek: cmdq: add cmdq_dev_get_client_reg function
arm64: dts: add gce node for mt8183
.../devicetree/bindings/mailbox/mtk-gce.txt | 23 ++-
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 10 +
drivers/mailbox/mtk-cmdq-mailbox.c | 18 +-
drivers/soc/mediatek/mtk-cmdq-helper.c | 136 +++++++++++---
include/dt-bindings/gce/mt8183-gce.h | 175 ++++++++++++++++++
include/linux/mailbox/mtk-cmdq-mailbox.h | 14 ++
include/linux/soc/mediatek/mtk-cmdq.h | 56 +++++-
7 files changed, 390 insertions(+), 42 deletions(-)
create mode 100644 include/dt-bindings/gce/mt8183-gce.h
--
2.18.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 -next] media: imx: remove unused including <linux/version.h>
From: YueHaibing @ 2019-08-29 1:22 UTC (permalink / raw)
To: Steve Longerbeam, Philipp Zabel, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team
Cc: devel, kernel-janitors, YueHaibing, linux-arm-kernel, linux-media
Remove including <linux/version.h> that don't need it.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/staging/media/imx/imx-media-csc-scaler.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/media/imx/imx-media-csc-scaler.c b/drivers/staging/media/imx/imx-media-csc-scaler.c
index de599af59ffc..2b635ebf62d6 100644
--- a/drivers/staging/media/imx/imx-media-csc-scaler.c
+++ b/drivers/staging/media/imx/imx-media-csc-scaler.c
@@ -8,7 +8,6 @@
#include <linux/module.h>
#include <linux/delay.h>
#include <linux/fs.h>
-#include <linux/version.h>
#include <linux/sched.h>
#include <linux/slab.h>
#include <video/imx-ipu-v3.h>
_______________________________________________
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 01/11] ftrace: move recordmcount tools to scripts/ftrace
From: Changbin Du @ 2019-08-28 23:41 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-arch, linux-s390, linux-parisc, Jonathan Corbet, linux-sh,
John F . Reiser, x86, linux-doc, linux-kernel, linux-mips,
Ingo Molnar, Jessica Yu, sparclinux, linux-kbuild,
Thomas Gleixner, Matt Helsley, linuxppc-dev, linux-riscv,
linux-arm-kernel, Changbin Du
In-Reply-To: <20190826184444.09334ae9@gandalf.local.home>
On Mon, Aug 26, 2019 at 06:44:44PM -0400, Steven Rostedt wrote:
> On Sun, 25 Aug 2019 21:23:20 +0800
> Changbin Du <changbin.du@gmail.com> wrote:
>
> > Move ftrace tools to its own directory. We will add another tool later.
> >
> > Cc: John F. Reiser <jreiser@BitWagon.com>
> > Signed-off-by: Changbin Du <changbin.du@gmail.com>
> > ---
> > scripts/.gitignore | 1 -
> > scripts/Makefile | 2 +-
> > scripts/Makefile.build | 10 +++++-----
> > scripts/ftrace/.gitignore | 4 ++++
> > scripts/ftrace/Makefile | 4 ++++
> > scripts/{ => ftrace}/recordmcount.c | 0
> > scripts/{ => ftrace}/recordmcount.h | 0
> > scripts/{ => ftrace}/recordmcount.pl | 0
> > 8 files changed, 14 insertions(+), 7 deletions(-)
> > create mode 100644 scripts/ftrace/.gitignore
> > create mode 100644 scripts/ftrace/Makefile
> > rename scripts/{ => ftrace}/recordmcount.c (100%)
> > rename scripts/{ => ftrace}/recordmcount.h (100%)
> > rename scripts/{ => ftrace}/recordmcount.pl (100%)
> > mode change 100755 => 100644
>
> Note, we are in the process of merging recordmcount with objtool. It
> would be better to continue from that work.
>
> http://lkml.kernel.org/r/2767f55f4a5fbf30ba0635aed7a9c5ee92ac07dd.1563992889.git.mhelsley@vmware.com
>
> -- Steve
Thanks for reminding. Let me check if prototype tool can merge into
objtool easily after above work.
--
Cheers,
Changbin Du
_______________________________________________
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 net-next] phy: mdio-sun4i: use devm_platform_ioremap_resource() to simplify code
From: David Miller @ 2019-08-28 21:51 UTC (permalink / raw)
To: yuehaibing
Cc: andrew, f.fainelli, netdev, linux-kernel, mripard, wens,
linux-arm-kernel, hkallweit1
In-Reply-To: <20190827135032.14620-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Tue, 27 Aug 2019 21:50:32 +0800
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
_______________________________________________
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 net-next] phy: mdio-mux-meson-g12a: use devm_platform_ioremap_resource() to simplify code
From: David Miller @ 2019-08-28 21:51 UTC (permalink / raw)
To: yuehaibing
Cc: andrew, f.fainelli, netdev, linux-kernel, khilman, linux-amlogic,
linux-arm-kernel, hkallweit1
In-Reply-To: <20190827134940.14944-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Tue, 27 Aug 2019 21:49:40 +0800
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
_______________________________________________
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 net-next] phy: mdio-bcm-iproc: use devm_platform_ioremap_resource() to simplify code
From: David Miller @ 2019-08-28 21:51 UTC (permalink / raw)
To: yuehaibing
Cc: andrew, f.fainelli, sbranden, rjui, linux-kernel,
bcm-kernel-feedback-list, netdev, linux-arm-kernel, hkallweit1
In-Reply-To: <20190827134616.11396-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Tue, 27 Aug 2019 21:46:16 +0800
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
_______________________________________________
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] arm-smmu: check for generic bindings first
From: Stefano Stabellini @ 2019-08-28 20:48 UTC (permalink / raw)
To: Robin Murphy
Cc: Stefano Stabellini, linux-kernel, michal.simek, git, will,
linux-arm-kernel
In-Reply-To: <f6fe31f1-52e1-8ab8-4ba4-f23db262d1b5@arm.com>
On Wed, 28 Aug 2019, Robin Murphy wrote:
> On 28/08/2019 18:38, Stefano Stabellini wrote:
> > From: Stefano Stabellini <stefano.stabellini@xilinx.com>
> >
> > Today, the arm-smmu driver checks for mmu-masters on device tree, the
> > legacy property, if it is absent it assumes that we are using the new
> > bindings. If it is present it assumes that we are using the legacy
> > bindings. All arm-smmus need to use the same bindings: legacy or new.
> >
> > There are two issues with this:
> >
> > - we are not actually checking for the new bindings explicitly
> > It would be better to have an explicit check for the new bindings rather
> > than assuming we must be using the new if the old are not there.
>
> The legacy binding is the special case, though. Isn't it perfectly logical to
> check for the special case, and assume the normal case otherwise? ;)
I don't know ... all cases are special and all cases are normal
depending on who you ask or when. The normal case of today can be the
special case of tomorrow and vice versa.
> > - old and new bindings cannot coexist
> > It would be nice to be able to provide both old and new bindings so
> > that software that hasn't been updated yet is still able to get IOMMU
> > information from the legacy bindings while at the same time newer
> > software can get the latest information via the new bindings. (Xen has
> > not been updated to use the new binding yet for instance.) The current
> > code breaks under these circumstances because if the old bindings are
> > present, the new are not even checked.
>
> FWIW that was a deliberate design decision. We didn't want to see DTs with
> both bindings at once - the legacy binding support remains only for the sake
> of DTBs deployed in fossilised firmware that can't/won't ever be updated. And
> I'm pretty sure the intervening 3 years have only reinforced that position.
> Only a couple more months now until it will have been deprecated for longer
> than it wasn't :)
This way the people that would be willing to put in extra effort to
maintain compatibility wouldn't be able to achieve the goal.
> Do note that "mmu-masters" isn't just deprecated for giggles either - the
> binding made some flawed assumptions, and there are Stream ID topologies that
> it cannot possibly describe, which do exist in the real world.
>
> > This patch changes the scheme by checking for #iommu-cells, which is
> > only present with the new bindings, before checking for mmu-masters.
> > The new bindings are always favored when present. All SMMUs still need
> > to use the same bindings: mix-and-matching new and old bindings between
> > different SMMUs is not allowed.
> >
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> > ---
> >
> > Let me know if you'd like me to turn the two using_*_binding variables
> > into a single one.
> >
> > Also, please note that this is not meant as an excuse not to get Xen
> > updated to use the new binding.
>
> Fair enough, but conversely, what makes it Linux's responsibility to handle?
> If Xen wants to deal with funky hybrid DTs then why shouldn't it be Xen's job
> to just filter deprecated properties out of whatever it presents to Linux?
Yes, Xen does it just fine. But if you boot Linux with the same DT but
without Xen, problems occur.
The code looked suboptimal to me because of the reasons I listed in the
commit message. I thought it was done this way by "mistake". However, I
now realize that if it is written this way on purpose, then I have a
very little chance of convincing you to change it.
> > drivers/iommu/arm-smmu.c | 22 +++++++++++++---------
> > 1 file changed, 13 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> > index 64977c131ee6..79b518ff215c 100644
> > --- a/drivers/iommu/arm-smmu.c
> > +++ b/drivers/iommu/arm-smmu.c
> > @@ -2118,7 +2118,7 @@ static int arm_smmu_device_dt_probe(struct
> > platform_device *pdev,
> > {
> > const struct arm_smmu_match_data *data;
> > struct device *dev = &pdev->dev;
> > - bool legacy_binding;
> > + bool legacy_binding, generic_binding;
> > if (of_property_read_u32(dev->of_node, "#global-interrupts",
> > &smmu->num_global_irqs)) {
> > @@ -2132,16 +2132,20 @@ static int arm_smmu_device_dt_probe(struct
> > platform_device *pdev,
> > parse_driver_options(smmu);
> > - legacy_binding = of_find_property(dev->of_node, "mmu-masters", NULL);
> > - if (legacy_binding && !using_generic_binding) {
> > - if (!using_legacy_binding)
> > - pr_notice("deprecated \"mmu-masters\" DT property in
> > use; DMA API support unavailable\n");
> > - using_legacy_binding = true;
> > - } else if (!legacy_binding && !using_legacy_binding) {
> > + generic_binding = of_find_property(dev->of_node, "#iommu-cells",
> > NULL);
> > + if (generic_binding && !using_legacy_binding) {
> > using_generic_binding = true;
> > } else {
> > - dev_err(dev, "not probing due to mismatched DT properties\n");
> > - return -ENODEV;
> > + legacy_binding = of_find_property(dev->of_node, "mmu-masters",
> > + NULL);
> > + if (legacy_binding && !using_generic_binding) {
> > + if (!using_legacy_binding)
> > + pr_notice("deprecated \"mmu-masters\" DT
> > property in use; DMA API support unavailable\n");
> > + using_legacy_binding = true;
> > + } else {
> > + dev_err(dev, "not probing due to mismatched DT
> > properties\n");
> > + return -ENODEV;
> > + }
> > }
> > if (of_dma_is_coherent(dev->of_node))
> >
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCHv1 3/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to HDMI supply
From: Anand Moon @ 2019-08-28 20:27 UTC (permalink / raw)
To: Rob Herring, Martin Blumenstingl, Jerome Brunet, Neil Armstrong,
Kevin Hilman
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-amlogic
In-Reply-To: <20190828202723.1145-1-linux.amoon@gmail.com>
As per shematics HDMI_P5V0 is supplied by P5V0 so add missing link.
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Jerome Brunet <jbrunet@baylibre.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index a078a1ee5004..47789fd50415 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -213,6 +213,8 @@
status = "okay";
pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
pinctrl-names = "default";
+ /* AP2331SA-7 */
+ hdmi-supply = <&p5v0>;
};
&hdmi_tx_tmds_port {
--
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 related
* [PATCHv1 2/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to VDDIO_AO3V3 regulator
From: Anand Moon @ 2019-08-28 20:27 UTC (permalink / raw)
To: Rob Herring, Martin Blumenstingl, Jerome Brunet, Neil Armstrong,
Kevin Hilman
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-amlogic
In-Reply-To: <20190828202723.1145-1-linux.amoon@gmail.com>
As per shematics TFLASH_VDD, TF_IO, VCC3V3 fixed regulator output which
is supplied by VDDIO_AO3V3.
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Jerome Brunet <jbrunet@baylibre.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 98e742bf44c1..a078a1ee5004 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -67,17 +67,19 @@
};
tflash_vdd: regulator-tflash_vdd {
- /*
- * signal name from schematics: TFLASH_VDD_EN
- */
compatible = "regulator-fixed";
regulator-name = "TFLASH_VDD";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
+ /*
+ * signal name from schematics: TFLASH_VDD_EN
+ */
gpio = <&gpio GPIOY_12 GPIO_ACTIVE_HIGH>;
enable-active-high;
+ /* U16 RT9179GB */
+ vin-supply = <&vddio_ao3v3>;
};
tf_io: gpio-regulator-tf_io {
@@ -95,6 +97,8 @@
states = <3300000 0
1800000 1>;
+ /* U12/U13 RT9179GB */
+ vin-supply = <&vddio_ao3v3>;
};
vcc1v8: regulator-vcc1v8 {
@@ -102,6 +106,9 @@
regulator-name = "VCC1V8";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ /* U18 RT9179GB */
+ vin-supply = <&vddio_ao3v3>;
};
vddio_ao1v8: regulator-vddio-ao1v8 {
--
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 related
* [PATCHv1 1/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to P5V0 regulator
From: Anand Moon @ 2019-08-28 20:27 UTC (permalink / raw)
To: Rob Herring, Martin Blumenstingl, Jerome Brunet, Neil Armstrong,
Kevin Hilman
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-amlogic
In-Reply-To: <20190828202723.1145-1-linux.amoon@gmail.com>
As per shematics VDDIO_AO18, VDDIO_AO3V3/VDD3V3 DDR3_1V5/DDR_VDDC:
fixed regulator output which is supplied by P5V0.
Rename vcc3v3 regulator node to vddio_ao3v3 as per shematics.
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Jerome Brunet <jbrunet@baylibre.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
.../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 29 +++++++++++++++++--
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 792698a60a12..98e742bf44c1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -104,11 +104,34 @@
regulator-max-microvolt = <1800000>;
};
- vcc3v3: regulator-vcc3v3 {
+ vddio_ao1v8: regulator-vddio-ao1v8 {
compatible = "regulator-fixed";
- regulator-name = "VCC3V3";
+ regulator-name = "VDDIO_AO1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ /* U17 RT9179GB */
+ vin-supply = <&p5v0>;
+ };
+
+ vddio_ao3v3: regulator-vddio-ao3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_AO3V3";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ /* U11 MP2161GJ-C499 */
+ vin-supply = <&p5v0>;
+ };
+
+ vddc_ddr: regulator-vddc-ddr {
+ compatible = "regulator-fixed";
+ regulator-name = "DDR_VDDC";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-always-on;
+ /* U15 MP2161GJ-C499 */
+ vin-supply = <&p5v0>;
};
emmc_pwrseq: emmc-pwrseq {
@@ -301,7 +324,7 @@
mmc-hs200-1_8v;
mmc-pwrseq = <&emmc_pwrseq>;
- vmmc-supply = <&vcc3v3>;
+ vmmc-supply = <&vddio_ao3v3>;
vqmmc-supply = <&vcc1v8>;
};
--
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 related
* [PATCHv1 0/3] Odroid c2 missing regulator linking
From: Anand Moon @ 2019-08-28 20:27 UTC (permalink / raw)
To: Rob Herring, Martin Blumenstingl, Jerome Brunet, Neil Armstrong,
Kevin Hilman
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-amlogic
Below small changes help re-configure or fix missing inter linking
of regulator node.
Changes based top on my prevoius series.
[0] https://patchwork.kernel.org/cover/11113091/
TOOD: Add support for DVFS GXBB odroid board in next series.
Best Regards
-Anand
Anand Moon (3):
arm64: dts: meson: odroid-c2: Add missing regulator linked to P5V0
regulator
arm64: dts: meson: odroid-c2: Add missing regulator linked to
VDDIO_AO3V3 regulator
arm64: dts: meson: odroid-c2: Add missing regulator linked to HDMI
supply
.../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 44 ++++++++++++++++---
1 file changed, 38 insertions(+), 6 deletions(-)
--
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 0/2] Coresight: Fix for v5.3-rc5
From: Greg KH @ 2019-08-28 20:25 UTC (permalink / raw)
To: Mathieu Poirier; +Cc: linux-arm-kernel
In-Reply-To: <CANLsYkyrJTDeNNXrmNLgwRD7W00aj=YMtAx-DeezZk_xiVw05g@mail.gmail.com>
On Wed, Aug 21, 2019 at 01:28:43PM -0600, Mathieu Poirier wrote:
> On Tue, 20 Aug 2019 at 13:41, Mathieu Poirier
> <mathieu.poirier@linaro.org> wrote:
> >
> > Good day,
> >
> > Please see if you can add the following fix to the current cycle. If
> > you think it is a little late I'll simply lump them with the set I
> > have for v5.4.
>
> I found an issue with a corner case - please ignore this request.
Now dropped, thanks.
greg k-h
_______________________________________________
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 RESEND v11 7/8] open: openat2(2) syscall
From: Spencer Baugh @ 2019-08-28 20:17 UTC (permalink / raw)
To: Jeff Layton, linux-fsdevel
Cc: linux-arch, linux-ia64, linux-parisc, linux-sh, linux-api,
linux-kernel, linux-mips, linuxppc-dev, linux-alpha, sparclinux,
linux-arm-kernel
In-Reply-To: <4da231cd52880991d8a038adb8fbb2ef3d724db9.camel@kernel.org>
Jeff Layton <jlayton@kernel.org> writes:
> On Mon, 2019-08-26 at 19:50 +0000, sbaugh@catern.com wrote:
>> Aleksa Sarai <cyphar@cyphar.com> writes:
>> > To this end, we introduce the openat2(2) syscall. It provides all of the
>> > features of openat(2) through the @how->flags argument, but also
>> > also provides a new @how->resolve argument which exposes RESOLVE_* flags
>> > that map to our new LOOKUP_* flags. It also eliminates the long-standing
>> > ugliness of variadic-open(2) by embedding it in a struct.
>>
>> I don't like this usage of a structure in memory to pass arguments that
>> would fit in registers. This would be quite inconvenient for me as a
>> userspace developer.
>>
>> Others have brought up issues with this: the issue of seccomp, and the
>> issue of mismatch between the userspace interface and the kernel
>> interface, are the most important for me. I want to add another,
>> admittedly somewhat niche, concern.
>>
>> This interfaces requires a program to allocate memory (even on the
>> stack) just to pass arguments to the kernel which could be passed
>> without allocating that memory. That makes it more difficult and less
>> efficient to use this syscall in any case where memory is not so easily
>> allocatable: such as early program startup or assembly, where the stack
>> may be limited in size or not even available yet, or when injecting a
>> syscall while ptracing.
>>
>> A struct-passing interface was needed for clone, since we ran out of
>> registers; but we have not run out of registers yet for openat, so it
>> would be nice to avoid this if we can. We can always expand later...
>>
>
> We can't really expand later like you suggest.
>
> Suppose in a couple of years that we need to add some new argument to
> openat2 that isn't just a new flag. If all these values are passed by
> individual arguments, you can't add one later without adding yet another
> syscall.
Sure we can. This new syscall doesn't need to use all 6 available
arguments. It can enforce that the unused ones are 0. Then if we
eventually run out of flags and need to switch to pass arguments via
struct, we can just use one of the unused arguments for that purpose.
Even if we used all 6 arguments, in the worst-case scenario, the last
flag we add could change the interpretation of some other argument so it
can be used to pass a pointer to a struct.
_______________________________________________
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 0/5] perf: Treat perf_event_paranoid and kptr_restrict like the kernel does it
From: Arnaldo Carvalho de Melo @ 2019-08-28 20:22 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Suzuki Poulouse, Alexander Shishkin, Alexey Budankov,
Igor Lubashev, James Morris, Linux Kernel Mailing List,
Peter Zijlstra, Jiri Olsa, Namhyung Kim, linux-arm-kernel
In-Reply-To: <CANLsYkwZm9ehopjDMXNw-3JOj8MPeT_shPPJBOeLNe7BUtibmA@mail.gmail.com>
Em Wed, Aug 28, 2019 at 01:31:21PM -0600, Mathieu Poirier escreveu:
> On Mon, 26 Aug 2019 at 19:40, Igor Lubashev <ilubashe@akamai.com> wrote:
> > Igor Lubashev (5):
> > perf event: Check ref_reloc_sym before using it
> > perf tools: Use CAP_SYS_ADMIN with perf_event_paranoid checks
> > perf util: kernel profiling is disallowed only when perf_event_paranoid > 1
> > perf symbols: Use CAP_SYSLOG with kptr_restrict checks
> > perf: warn that perf_event_paranoid can restrict kernel symbols
> > tools/perf/arch/arm/util/cs-etm.c | 3 ++-
> For the coresight part:
> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> > tools/perf/arch/arm64/util/arm-spe.c | 3 ++-
> > tools/perf/arch/x86/util/intel-bts.c | 3 ++-
> > tools/perf/arch/x86/util/intel-pt.c | 2 +-
> > tools/perf/builtin-record.c | 2 +-
> > tools/perf/builtin-top.c | 2 +-
> > tools/perf/builtin-trace.c | 2 +-
> > tools/perf/util/event.c | 7 ++++---
> > tools/perf/util/evsel.c | 2 +-
> > tools/perf/util/symbol.c | 15 ++++++++++++---
> > 10 files changed, 27 insertions(+), 14 deletions(-)
>
> For the set:
>
> Tested-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Thanks, updated the patches with your tags,
- Arnaldo
_______________________________________________
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 net-next v4 3/3] dt-bindings: net: ethernet: Update mt7622 docs and dts to reflect the new phylink API
From: David Miller @ 2019-08-28 19:56 UTC (permalink / raw)
To: matthias.bgg
Cc: nelson.chang, frank-w, netdev, sean.wang, linux-mips, linux,
opensource, linux-mediatek, john, sr, linux-arm-kernel
In-Reply-To: <e45565b1-bb63-66af-16f6-5c7c1094dd67@gmail.com>
From: Matthias Brugger <matthias.bgg@gmail.com>
Date: Wed, 28 Aug 2019 11:29:45 +0200
> Thanks for taking this patch. For the next time, please make sure that dts[i]
> patches are independent from the binding description, as dts[i] should go
> through my tree. No problem for this round, just saying for the future.
That's not always possible nor reasonable, to be quite honest.
_______________________________________________
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 0/5] perf: Treat perf_event_paranoid and kptr_restrict like the kernel does it
From: Mathieu Poirier @ 2019-08-28 19:31 UTC (permalink / raw)
To: Igor Lubashev
Cc: Suzuki Poulouse, Alexander Shishkin, Alexey Budankov,
James Morris, Linux Kernel Mailing List, Arnaldo Carvalho de Melo,
Peter Zijlstra, Jiri Olsa, Namhyung Kim, linux-arm-kernel
In-Reply-To: <1566869956-7154-1-git-send-email-ilubashe@akamai.com>
On Mon, 26 Aug 2019 at 19:40, Igor Lubashev <ilubashe@akamai.com> wrote:
>
> This is a follow up series to the ensure perf treats perf_event_paranoid and
> kptr_restrict in a way that is similar to the kernel's. That includes use of
> capabilities instead of euid==0, when possible, as well as adjusting the logic
> and fixing bugs.
>
> Prior discussion: https://lkml.kernel.org/lkml/cover.1565188228.git.ilubashe@akamai.com
>
> === Testing notes ===
>
> I have tested on x86 with perf binary installed according to
> Documentation/admin-guide/perf-security.rst (cap_sys_admin, cap_sys_ptrace,
> cap_syslog assigned to the perf executable).
>
> I tested each permutation of:
>
> * 7 commits:
> 1. HEAD of perf/core
> 2. patch 01 on top of perf/core
> 3. patches 01-02 on top of perf/core
> 4. patches 01-03 on top of perf/core
> 5. patches 01-04 on top of perf/core
> 6. patches 01-05 on top of perf/core
> 7. HEAD of perf/cap (with known bug fixed by patch 01 of this series)
>
> * 2 build environments: with and without libcap-dev
>
> * 3 kernel.kptr_restrict values: 0, 1, 2
>
> * 4 kernel.perf_event_paranoid values: -1, 0, 1, 2
>
> * 2 users: root and non-root
>
> Total: 336 permutations
>
> Each permutation consisted of:
> perf test
> perf record -e instructions -- sleep 1
>
> All test runs were expected. Also, as expected, the following permutation (just
> that permutation) resulted in segmentation failure:
> commit: perf/cap
> build: no libcap-dev
> kernel.kptr_restrict: 0
> kernel.perf_event_paranoid: 2
> user: non-root
>
> The perf/cap commit was included in the test to ensure that we can reproduce the
> crash and hence test that the patch series fixes the crash, while retaining the
> desired behavior of perf/cap.
>
> === Series Contents ===
>
> 01: perf event: Check ref_reloc_sym before using it
> Fix the pre-existing cause of the crash above: use of ref_reloc_sym without
> a check for NULL
>
> 02: perf tools: Use CAP_SYS_ADMIN with perf_event_paranoid checks
> Replace the use of euid==0 with a check for CAP_SYS_ADMIN whenever
> perf_event_paranoid level is verified.
> * This patch has been reviewed previously and is unchanged.
> * I kept Acks and Sign-offs.
>
> 03: perf util: kernel profiling is disallowed only when perf_event_paranoid>1
> Align perf logic regarding perf_event_paranoid to match kernel's.
> This has been reported by Arnaldo.
>
> 04: perf symbols: Use CAP_SYSLOG with kptr_restrict checks
> Replace the use of uid and euid with a check for CAP_SYSLOG when
> kptr_restrict is verified (similar to kernel/kallsyms.c and lib/vsprintf.c).
> Consult perf_event_paranoid when kptr_restrict==0 (see kernel/kallsyms.c).
> * A previous version of this patch has been reviewed previously, but I
> * modified it in a non-trivial way, so I removed Acks.
>
> 05: perf: warn perf_event_paranoid restrict kernel symbols
> Warn that /proc/sys/kernel/perf_event_paranoid can also restrict kernel
> symbols.
>
> Igor Lubashev (5):
> perf event: Check ref_reloc_sym before using it
> perf tools: Use CAP_SYS_ADMIN with perf_event_paranoid checks
> perf util: kernel profiling is disallowed only when perf_event_paranoid > 1
> perf symbols: Use CAP_SYSLOG with kptr_restrict checks
> perf: warn that perf_event_paranoid can restrict kernel symbols
>
> tools/perf/arch/arm/util/cs-etm.c | 3 ++-
For the coresight part:
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> tools/perf/arch/arm64/util/arm-spe.c | 3 ++-
> tools/perf/arch/x86/util/intel-bts.c | 3 ++-
> tools/perf/arch/x86/util/intel-pt.c | 2 +-
> tools/perf/builtin-record.c | 2 +-
> tools/perf/builtin-top.c | 2 +-
> tools/perf/builtin-trace.c | 2 +-
> tools/perf/util/event.c | 7 ++++---
> tools/perf/util/evsel.c | 2 +-
> tools/perf/util/symbol.c | 15 ++++++++++++---
> 10 files changed, 27 insertions(+), 14 deletions(-)
For the set:
Tested-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> --
> 2.7.4
>
_______________________________________________
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] arm-smmu: check for generic bindings first
From: Robin Murphy @ 2019-08-28 18:55 UTC (permalink / raw)
To: Stefano Stabellini, will
Cc: linux-kernel, Stefano Stabellini, michal.simek, linux-arm-kernel,
git
In-Reply-To: <20190828173837.29617-1-sstabellini@kernel.org>
On 28/08/2019 18:38, Stefano Stabellini wrote:
> From: Stefano Stabellini <stefano.stabellini@xilinx.com>
>
> Today, the arm-smmu driver checks for mmu-masters on device tree, the
> legacy property, if it is absent it assumes that we are using the new
> bindings. If it is present it assumes that we are using the legacy
> bindings. All arm-smmus need to use the same bindings: legacy or new.
>
> There are two issues with this:
>
> - we are not actually checking for the new bindings explicitly
> It would be better to have an explicit check for the new bindings rather
> than assuming we must be using the new if the old are not there.
The legacy binding is the special case, though. Isn't it perfectly
logical to check for the special case, and assume the normal case
otherwise? ;)
> - old and new bindings cannot coexist
> It would be nice to be able to provide both old and new bindings so
> that software that hasn't been updated yet is still able to get IOMMU
> information from the legacy bindings while at the same time newer
> software can get the latest information via the new bindings. (Xen has
> not been updated to use the new binding yet for instance.) The current
> code breaks under these circumstances because if the old bindings are
> present, the new are not even checked.
FWIW that was a deliberate design decision. We didn't want to see DTs
with both bindings at once - the legacy binding support remains only for
the sake of DTBs deployed in fossilised firmware that can't/won't ever
be updated. And I'm pretty sure the intervening 3 years have only
reinforced that position. Only a couple more months now until it will
have been deprecated for longer than it wasn't :)
Do note that "mmu-masters" isn't just deprecated for giggles either -
the binding made some flawed assumptions, and there are Stream ID
topologies that it cannot possibly describe, which do exist in the real
world.
> This patch changes the scheme by checking for #iommu-cells, which is
> only present with the new bindings, before checking for mmu-masters.
> The new bindings are always favored when present. All SMMUs still need
> to use the same bindings: mix-and-matching new and old bindings between
> different SMMUs is not allowed.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> ---
>
> Let me know if you'd like me to turn the two using_*_binding variables
> into a single one.
>
> Also, please note that this is not meant as an excuse not to get Xen
> updated to use the new binding.
Fair enough, but conversely, what makes it Linux's responsibility to
handle? If Xen wants to deal with funky hybrid DTs then why shouldn't it
be Xen's job to just filter deprecated properties out of whatever it
presents to Linux?
Robin.
> drivers/iommu/arm-smmu.c | 22 +++++++++++++---------
> 1 file changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 64977c131ee6..79b518ff215c 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -2118,7 +2118,7 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev,
> {
> const struct arm_smmu_match_data *data;
> struct device *dev = &pdev->dev;
> - bool legacy_binding;
> + bool legacy_binding, generic_binding;
>
> if (of_property_read_u32(dev->of_node, "#global-interrupts",
> &smmu->num_global_irqs)) {
> @@ -2132,16 +2132,20 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev,
>
> parse_driver_options(smmu);
>
> - legacy_binding = of_find_property(dev->of_node, "mmu-masters", NULL);
> - if (legacy_binding && !using_generic_binding) {
> - if (!using_legacy_binding)
> - pr_notice("deprecated \"mmu-masters\" DT property in use; DMA API support unavailable\n");
> - using_legacy_binding = true;
> - } else if (!legacy_binding && !using_legacy_binding) {
> + generic_binding = of_find_property(dev->of_node, "#iommu-cells", NULL);
> + if (generic_binding && !using_legacy_binding) {
> using_generic_binding = true;
> } else {
> - dev_err(dev, "not probing due to mismatched DT properties\n");
> - return -ENODEV;
> + legacy_binding = of_find_property(dev->of_node, "mmu-masters",
> + NULL);
> + if (legacy_binding && !using_generic_binding) {
> + if (!using_legacy_binding)
> + pr_notice("deprecated \"mmu-masters\" DT property in use; DMA API support unavailable\n");
> + using_legacy_binding = true;
> + } else {
> + dev_err(dev, "not probing due to mismatched DT properties\n");
> + return -ENODEV;
> + }
> }
>
> if (of_dma_is_coherent(dev->of_node))
>
_______________________________________________
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 14/22] ARM: omap1: use pci_ioremap_io() for omap_cf
From: Tony Lindgren @ 2019-08-28 18:45 UTC (permalink / raw)
To: Aaro Koskinen
Cc: Arnd Bergmann, Bartlomiej Zolnierkiewicz, Greg Kroah-Hartman,
Linus Walleij, Linux Kernel Mailing List, Dominik Brodowski,
Tomi Valkeinen, linux-omap, Linux ARM
In-Reply-To: <20190828182318.GL30291@darkstar.musicnaut.iki.fi>
* Aaro Koskinen <aaro.koskinen@iki.fi> [190828 18:23]:
> On Wed, Aug 28, 2019 at 03:02:36PM +0200, Arnd Bergmann wrote:
> > I assume you checked that the uart output wasn't already broken
> > by one of the earlier patches, right?
>
> Correct, it's only with the mapping change patch it hangs.
>
> > Also, looking at arch/arm/mach-omap1/include/mach/uncompress.h
> > it seems that SX1 normally uses UART3, not UART1.
> > Is that different in qemu?
>
> In QEMU all uarts can be used, trying with UART3 as early console
> hangs as well. (It prints Uncompressing... done. but I guess that's
> done with the physical address.)
Hmm maybe we now need to get rid of the machine based
detection code for DEBUGLL like we did for mach-omap2.
Just get rid of arch_decomp_setup() in mach-omap1
uncompress.h file and make sure the assembly code
only relies on the the Kconfig options only.
That needs to be done at least for device tree based
support since we use a generic machine ID. But maybe
with multiarch support we need to rely on generic
uncompress.h and assembly.
Regards,
Tony
_______________________________________________
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 5/5] serial: imx: use Tx ready rather than Tx empty irq
From: Sergey Organov @ 2019-08-28 18:37 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Sascha Hauer, Sergey Organov, NXP Linux Team,
Pengutronix Kernel Team, Uwe Kleine-König, linux-arm-kernel
In-Reply-To: <1567017475-11919-1-git-send-email-sorganov@gmail.com>
This should help to avoid unnecessary gaps in transmission while
adding little overhead due to low default Tx threshold level (2
bytes).
Signed-off-by: Sergey Organov <sorganov@gmail.com>
---
drivers/tty/serial/imx.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index e89045a..87c58f9 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -439,7 +439,7 @@ static void imx_uart_stop_tx(struct uart_port *port)
return;
ucr1 = imx_uart_readl(sport, UCR1);
- imx_uart_writel(sport, ucr1 & ~UCR1_TXMPTYEN, UCR1);
+ imx_uart_writel(sport, ucr1 & ~UCR1_TRDYEN, UCR1);
/* in rs485 mode disable transmitter if shifter is empty */
if (port->rs485.flags & SER_RS485_ENABLED &&
@@ -517,7 +517,7 @@ static inline void imx_uart_transmit_buffer(struct imx_port *sport)
* and the TX IRQ is disabled.
**/
ucr1 = imx_uart_readl(sport, UCR1);
- ucr1 &= ~UCR1_TXMPTYEN;
+ ucr1 &= ~UCR1_TRDYEN;
if (sport->dma_is_txing) {
ucr1 |= UCR1_TXDMAEN;
imx_uart_writel(sport, ucr1, UCR1);
@@ -679,7 +679,7 @@ static void imx_uart_start_tx(struct uart_port *port)
if (!sport->dma_is_enabled) {
ucr1 = imx_uart_readl(sport, UCR1);
- imx_uart_writel(sport, ucr1 | UCR1_TXMPTYEN, UCR1);
+ imx_uart_writel(sport, ucr1 | UCR1_TRDYEN, UCR1);
}
if (sport->dma_is_enabled) {
@@ -688,7 +688,7 @@ static void imx_uart_start_tx(struct uart_port *port)
* disable TX DMA to let TX interrupt to send X-char */
ucr1 = imx_uart_readl(sport, UCR1);
ucr1 &= ~UCR1_TXDMAEN;
- ucr1 |= UCR1_TXMPTYEN;
+ ucr1 |= UCR1_TRDYEN;
imx_uart_writel(sport, ucr1, UCR1);
return;
}
@@ -874,7 +874,7 @@ static irqreturn_t imx_uart_int(int irq, void *dev_id)
usr1 &= ~USR1_RRDY;
if ((ucr2 & UCR2_ATEN) == 0)
usr1 &= ~USR1_AGTIM;
- if ((ucr1 & UCR1_TXMPTYEN) == 0)
+ if ((ucr1 & UCR1_TRDYEN) == 0)
usr1 &= ~USR1_TRDY;
if ((ucr4 & UCR4_TCEN) == 0)
usr2 &= ~USR2_TXDC;
@@ -1474,7 +1474,7 @@ static void imx_uart_shutdown(struct uart_port *port)
spin_lock_irqsave(&sport->port.lock, flags);
ucr1 = imx_uart_readl(sport, UCR1);
- ucr1 &= ~(UCR1_TXMPTYEN | UCR1_RRDYEN | UCR1_RTSDEN | UCR1_UARTEN | UCR1_RXDMAEN | UCR1_ATDMAEN);
+ ucr1 &= ~(UCR1_TRDYEN | UCR1_RRDYEN | UCR1_RTSDEN | UCR1_UARTEN | UCR1_RXDMAEN | UCR1_ATDMAEN);
imx_uart_writel(sport, ucr1, UCR1);
spin_unlock_irqrestore(&sport->port.lock, flags);
@@ -1778,7 +1778,7 @@ static int imx_uart_poll_init(struct uart_port *port)
ucr1 |= IMX1_UCR1_UARTCLKEN;
ucr1 |= UCR1_UARTEN;
- ucr1 &= ~(UCR1_TXMPTYEN | UCR1_RTSDEN | UCR1_RRDYEN);
+ ucr1 &= ~(UCR1_TRDYEN | UCR1_RTSDEN | UCR1_RRDYEN);
ucr2 |= UCR2_RXEN;
ucr2 &= ~UCR2_ATEN;
@@ -1938,7 +1938,7 @@ imx_uart_console_write(struct console *co, const char *s, unsigned int count)
if (imx_uart_is_imx1(sport))
ucr1 |= IMX1_UCR1_UARTCLKEN;
ucr1 |= UCR1_UARTEN;
- ucr1 &= ~(UCR1_TXMPTYEN | UCR1_RRDYEN | UCR1_RTSDEN);
+ ucr1 &= ~(UCR1_TRDYEN | UCR1_RRDYEN | UCR1_RTSDEN);
imx_uart_writel(sport, ucr1, UCR1);
@@ -2294,7 +2294,7 @@ static int imx_uart_probe(struct platform_device *pdev)
/* Disable interrupts before requesting them */
ucr1 = imx_uart_readl(sport, UCR1);
ucr1 &= ~(UCR1_ADEN | UCR1_TRDYEN | UCR1_IDEN | UCR1_RRDYEN |
- UCR1_TXMPTYEN | UCR1_RTSDEN);
+ UCR1_TRDYEN | UCR1_RTSDEN);
imx_uart_writel(sport, ucr1, UCR1);
if (!imx_uart_is_imx1(sport) && sport->dte_mode) {
--
2.10.0.1.g57b01a3
_______________________________________________
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 v2 4/5] serial: imx: fix data breakage on termios change
From: Sergey Organov @ 2019-08-28 18:37 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Sascha Hauer, Sergey Organov, NXP Linux Team,
Pengutronix Kernel Team, Uwe Kleine-König, linux-arm-kernel
In-Reply-To: <1567017475-11919-1-git-send-email-sorganov@gmail.com>
imx_set_termios(): avoid writing baud rate divider registers when the
values to be written are the same as current. Any writing seems to
restart transmission/receiving logic in the hardware, that leads to
data breakage even when rate doesn't in fact change. E.g., user
switches RTS/CTS handshake and suddenly gets broken bytes.
Signed-off-by: Sergey Organov <sorganov@gmail.com>
---
drivers/tty/serial/imx.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index cc3783c..e89045a 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1545,7 +1545,7 @@ imx_uart_set_termios(struct uart_port *port, struct ktermios *termios,
unsigned int baud, quot;
unsigned int old_csize = old ? old->c_cflag & CSIZE : CS8;
unsigned long div;
- unsigned long num, denom;
+ unsigned long num, denom, old_ubir, old_ubmr;
uint64_t tdiv64;
/*
@@ -1670,8 +1670,21 @@ imx_uart_set_termios(struct uart_port *port, struct ktermios *termios,
ufcr = (ufcr & (~UFCR_RFDIV)) | UFCR_RFDIV_REG(div);
imx_uart_writel(sport, ufcr, UFCR);
- imx_uart_writel(sport, num, UBIR);
- imx_uart_writel(sport, denom, UBMR);
+ /*
+ * Two registers below should always be written both and in this
+ * particular order. One consequence is that we need to check if any of
+ * them changes and then update both. We do need the check for change
+ * as even writing the same values seem to "restart"
+ * transmission/receiving logic in the hardware, that leads to data
+ * breakage even when rate doesn't in fact change. E.g., user switches
+ * RTS/CTS handshake and suddenly gets broken bytes.
+ */
+ old_ubir = imx_uart_readl(sport, UBIR);
+ old_ubmr = imx_uart_readl(sport, UBMR);
+ if (old_ubir != num || old_ubmr != denom) {
+ imx_uart_writel(sport, num, UBIR);
+ imx_uart_writel(sport, denom, UBMR);
+ }
if (!imx_uart_is_imx1(sport))
imx_uart_writel(sport, sport->port.uartclk / div / 1000,
--
2.10.0.1.g57b01a3
_______________________________________________
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 v2 3/5] serial: imx: do not disable individual irqs during termios change
From: Sergey Organov @ 2019-08-28 18:37 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Sascha Hauer, Sergey Organov, NXP Linux Team,
Pengutronix Kernel Team, Uwe Kleine-König, linux-arm-kernel
In-Reply-To: <1567017475-11919-1-git-send-email-sorganov@gmail.com>
imx_set_termios(): disabling individual interrupt requests in UART for
duration of the routine is pointless. Get rid of it.
Signed-off-by: Sergey Organov <sorganov@gmail.com>
---
drivers/tty/serial/imx.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index fa723a9a..cc3783c 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1541,7 +1541,7 @@ imx_uart_set_termios(struct uart_port *port, struct ktermios *termios,
{
struct imx_port *sport = (struct imx_port *)port;
unsigned long flags;
- u32 ucr2, old_ucr1, old_ucr2, ufcr;
+ u32 ucr2, old_ucr2, ufcr;
unsigned int baud, quot;
unsigned int old_csize = old ? old->c_cflag & CSIZE : CS8;
unsigned long div;
@@ -1643,15 +1643,6 @@ imx_uart_set_termios(struct uart_port *port, struct ktermios *termios,
*/
uart_update_timeout(port, termios->c_cflag, baud);
- /*
- * disable interrupts
- */
- old_ucr1 = imx_uart_readl(sport, UCR1);
- imx_uart_writel(sport,
- old_ucr1 & ~(UCR1_TXMPTYEN | UCR1_RRDYEN | UCR1_RTSDEN),
- UCR1);
- imx_uart_writel(sport, old_ucr2 & ~UCR2_ATEN, UCR2);
-
/* custom-baudrate handling */
div = sport->port.uartclk / (baud * 16);
if (baud == 38400 && quot != div)
@@ -1686,8 +1677,6 @@ imx_uart_set_termios(struct uart_port *port, struct ktermios *termios,
imx_uart_writel(sport, sport->port.uartclk / div / 1000,
IMX21_ONEMS);
- imx_uart_writel(sport, old_ucr1, UCR1);
-
imx_uart_writel(sport, ucr2, UCR2);
if (UART_ENABLE_MS(&sport->port, termios->c_cflag))
--
2.10.0.1.g57b01a3
_______________________________________________
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 v2 2/5] serial: imx: do not stop Rx/Tx on termios change
From: Sergey Organov @ 2019-08-28 18:37 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Sascha Hauer, Sergey Organov, NXP Linux Team,
Pengutronix Kernel Team, Uwe Kleine-König, linux-arm-kernel
In-Reply-To: <1567017475-11919-1-git-send-email-sorganov@gmail.com>
imx_set_termios(): stopping receiver and transmitter does harm when
something that doesn't touch transmission format/rate changes, such as
RTS/CTS handshake.
OTOH, it does no good on baud rate or format change, as
synchronization on upper-level protocols is still required to do it
right.
Therefore, just stop doing it.
Signed-off-by: Sergey Organov <sorganov@gmail.com>
---
drivers/tty/serial/imx.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 47b6156..fa723a9a 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1652,9 +1652,6 @@ imx_uart_set_termios(struct uart_port *port, struct ktermios *termios,
UCR1);
imx_uart_writel(sport, old_ucr2 & ~UCR2_ATEN, UCR2);
- /* then, disable everything */
- imx_uart_writel(sport, old_ucr2 & ~(UCR2_TXEN | UCR2_RXEN | UCR2_ATEN), UCR2);
-
/* custom-baudrate handling */
div = sport->port.uartclk / (baud * 16);
if (baud == 38400 && quot != div)
--
2.10.0.1.g57b01a3
_______________________________________________
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 v2 1/5] serial: imx: get rid of unbounded busy-waiting loop
From: Sergey Organov @ 2019-08-28 18:37 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Sascha Hauer, Sergey Organov, NXP Linux Team,
Pengutronix Kernel Team, Uwe Kleine-König, linux-arm-kernel
In-Reply-To: <1567017475-11919-1-git-send-email-sorganov@gmail.com>
imx_set_termios(): remove busy-waiting "drain Tx FIFO" loop. Worse
yet, it was potentially unbounded wait due to RTS/CTS (hardware)
handshake.
Let user space ensure draining is done before termios change, if
draining is needed in the first place.
Signed-off-by: Sergey Organov <sorganov@gmail.com>
---
drivers/tty/serial/imx.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index d9a73c7..47b6156 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1644,7 +1644,7 @@ imx_uart_set_termios(struct uart_port *port, struct ktermios *termios,
uart_update_timeout(port, termios->c_cflag, baud);
/*
- * disable interrupts and drain transmitter
+ * disable interrupts
*/
old_ucr1 = imx_uart_readl(sport, UCR1);
imx_uart_writel(sport,
@@ -1652,9 +1652,6 @@ imx_uart_set_termios(struct uart_port *port, struct ktermios *termios,
UCR1);
imx_uart_writel(sport, old_ucr2 & ~UCR2_ATEN, UCR2);
- while (!(imx_uart_readl(sport, USR2) & USR2_TXDC))
- barrier();
-
/* then, disable everything */
imx_uart_writel(sport, old_ucr2 & ~(UCR2_TXEN | UCR2_RXEN | UCR2_ATEN), UCR2);
--
2.10.0.1.g57b01a3
_______________________________________________
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 v2 0/5] Serial: imx: various fixes
From: Sergey Organov @ 2019-08-28 18:37 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Sascha Hauer, Sergey Organov, NXP Linux Team,
Pengutronix Kernel Team, Uwe Kleine-König, linux-arm-kernel
In-Reply-To: <20190530152950.25377-1-sorganov@gmail.com>
The original problem that caused these changes was broken bytes being
sent/received at random on RTS/CTS handshake switch (i.e., on
setting/clearing termios CRTSCTS bit).
As it went, a few other problems were found and fixed, and then the
fix for original issue has been split into multiple patches that seem
to make sense by themselves. Thus, the "serial: imx: fix data breakage
on termios change", that finally fixes the issue, depends on 2
preceding patches.
The last patch in the series, "serial: imx: use Tx ready rather than
Tx empty irq" is independent of the rest and doesn't fix any serious
issue, but it should get rid of holes in continuous output,
specifically in PIO mode.
Changes in v2:
- Removed wrong [PATCH 1/8] serial: imx: fix DTR inversion
- Rebased on top of "tty-next"
Sergey Organov (5):
serial: imx: get rid of unbounded busy-waiting loop
serial: imx: do not stop Rx/Tx on termios change
serial: imx: do not disable individual irqs during termios change
serial: imx: fix data breakage on termios change
serial: imx: use Tx ready rather than Tx empty irq
drivers/tty/serial/imx.c | 56 ++++++++++++++++++++++--------------------------
1 file changed, 26 insertions(+), 30 deletions(-)
--
2.10.0.1.g57b01a3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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