Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 2/2] remoteproc/k3-dsp: Add support for C71x DSPs
From: Suman Anna @ 2020-05-21 15:16 UTC (permalink / raw)
  To: Bjorn Andersson, Rob Herring, Mathieu Poirier
  Cc: devicetree, Lokesh Vutla, linux-remoteproc, linux-kernel,
	Suman Anna, linux-arm-kernel
In-Reply-To: <20200521151636.28260-1-s-anna@ti.com>

The Texas Instrument's K3 J721E SoCs have a newer next-generation
C71x DSP Subsystem in the MAIN voltage domain in addition to the
previous generation C66x DSP subsystems. The C71x DSP subsystem is
based on the TMS320C71x DSP CorePac module. The C71x CPU is a true
64-bit machine including 64-bit memory addressing and single-cycle
64-bit base arithmetic operations and supports vector signal processing
providing a significant lift in DSP processing power over C66x DSPs.
J721E SoCs use a C711 (a one-core 512-bit vector width CPU core) DSP
that is cache coherent with the A72 Arm cores.

Each subsystem has one or more Fixed/Floating-Point DSP CPUs, with 32 KB
of L1P Cache, 48 KB of L1D SRAM that can be configured and partitioned as
either RAM and/or Cache, and 512 KB of L2 SRAM configurable as either RAM
and/or Cache. The CorePac also includes a Matrix Multiplication Accelerator
(MMA), a Stream Engine (SE) and a C71x Memory Management Unit (CMMU), an
Interrupt Controller (INTC) and a Powerdown Management Unit (PMU) modules.

Update the existing K3 DSP remoteproc driver to add support for this C71x
DSP subsystem. The firmware loading support is provided by using the newly
added 64-bit ELF loader support, and is limited to images using only
external DDR memory at the moment. The L1D and L2 SRAMs are used as scratch
memory when using as RAMs, and cannot be used for loadable segments. The
CMMU is also not supported to begin with, and the driver is designed to
treat the MMU as if it is in bypass mode.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2: 
 - k3_dsp_rproc_prepare/unprepare plugged in dynamically based on local reset,
   C71x doesn't use local resets
 - Dropped the sanity_check ops override, not needed on latest codebase
v1: https://patchwork.kernel.org/patch/11458595/

 drivers/remoteproc/ti_k3_dsp_remoteproc.c | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
index 610fbbf85ee6..2dbed316b6ac 100644
--- a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
@@ -406,8 +406,6 @@ static void *k3_dsp_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
 }
 
 static const struct rproc_ops k3_dsp_rproc_ops = {
-	.prepare	= k3_dsp_rproc_prepare,
-	.unprepare	= k3_dsp_rproc_unprepare,
 	.start		= k3_dsp_rproc_start,
 	.stop		= k3_dsp_rproc_stop,
 	.kick		= k3_dsp_rproc_kick,
@@ -617,6 +615,10 @@ static int k3_dsp_rproc_probe(struct platform_device *pdev)
 
 	rproc->has_iommu = false;
 	rproc->recovery_disabled = true;
+	if (data->uses_lreset) {
+		rproc->ops->prepare = k3_dsp_rproc_prepare;
+		rproc->ops->unprepare = k3_dsp_rproc_unprepare;
+	}
 	kproc = rproc->priv;
 	kproc->rproc = rproc;
 	kproc->dev = dev;
@@ -744,6 +746,12 @@ static const struct k3_dsp_mem_data c66_mems[] = {
 	{ .name = "l1dram", .dev_addr = 0xf00000 },
 };
 
+/* C71x cores only have a L1P Cache, there are no L1P SRAMs */
+static const struct k3_dsp_mem_data c71_mems[] = {
+	{ .name = "l2sram", .dev_addr = 0x800000 },
+	{ .name = "l1dram", .dev_addr = 0xe00000 },
+};
+
 static const struct k3_dsp_dev_data c66_data = {
 	.mems = c66_mems,
 	.num_mems = ARRAY_SIZE(c66_mems),
@@ -751,8 +759,16 @@ static const struct k3_dsp_dev_data c66_data = {
 	.uses_lreset = true,
 };
 
+static const struct k3_dsp_dev_data c71_data = {
+	.mems = c71_mems,
+	.num_mems = ARRAY_SIZE(c71_mems),
+	.boot_align_addr = SZ_2M,
+	.uses_lreset = false,
+};
+
 static const struct of_device_id k3_dsp_of_match[] = {
 	{ .compatible = "ti,j721e-c66-dsp", .data = &c66_data, },
+	{ .compatible = "ti,j721e-c71-dsp", .data = &c71_data, },
 	{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, k3_dsp_of_match);
-- 
2.26.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 v2 0/2] Update K3 DSP remoteproc driver for C71x DSPs
From: Suman Anna @ 2020-05-21 15:16 UTC (permalink / raw)
  To: Bjorn Andersson, Rob Herring, Mathieu Poirier
  Cc: devicetree, Lokesh Vutla, linux-remoteproc, linux-kernel,
	Suman Anna, linux-arm-kernel

Hi All,

This series is an updated version of the enhancements to the K3 DSP
remoteproc driver to support the 64-bit TI DSP called C71x. The series
is on top of the K3 DSP remoteproc driver v2 [1], and includes only
the platform driver portions. Please see the v1 cover-letter [2] for
a summary of supported features.

The 64-bit resource type enhancements (patches 2 and 3 from v1 [3][4])
can be reviewed and discussed separately. I can post the next versions
just for those based on any review comments on those.

Please see the individual patches for differences in v2.

regards
Suman

[1] https://patchwork.kernel.org/cover/11561787/
[2] https://patchwork.kernel.org/cover/11458599/
[3] https://patchwork.kernel.org/patch/11458593/
[4] https://patchwork.kernel.org/patch/11458589/

Suman Anna (2):
  dt-bindings: remoteproc: k3-dsp: Update bindings for C71x DSPs
  remoteproc/k3-dsp: Add support for C71x DSPs

 .../bindings/remoteproc/ti,k3-dsp-rproc.yaml  | 76 +++++++++++++++++--
 drivers/remoteproc/ti_k3_dsp_remoteproc.c     | 20 ++++-
 2 files changed, 86 insertions(+), 10 deletions(-)

-- 
2.26.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 v2 1/2] dt-bindings: remoteproc: k3-dsp: Update bindings for C71x DSPs
From: Suman Anna @ 2020-05-21 15:16 UTC (permalink / raw)
  To: Bjorn Andersson, Rob Herring, Mathieu Poirier
  Cc: devicetree, Rob Herring, Lokesh Vutla, linux-remoteproc,
	linux-kernel, Suman Anna, linux-arm-kernel
In-Reply-To: <20200521151636.28260-1-s-anna@ti.com>

Some Texas Instruments K3 family of SoCs have one of more newer
generation TMS320C71x CorePac processor subsystem in addition to
the existing TMS320C66x CorePac processor subsystems. Update the
device tree bindings document for the C71x DSP devices.

The example is also updated to show the single C71 DSP present
on J721E SoCs.

Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
v2: 
 - Rebased patch, no changes to binding properties
 - Example additions indented one level to right as part of rebase and
   changes done in updated C66x bindings patch
 - Added Rob's Reviewed-by
v1: https://patchwork.kernel.org/patch/11458601/

 .../bindings/remoteproc/ti,k3-dsp-rproc.yaml  | 76 +++++++++++++++++--
 1 file changed, 68 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
index cdf649655838..47642015c884 100644
--- a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
@@ -27,9 +27,12 @@ description: |
 
 properties:
   compatible:
-    const: ti,j721e-c66-dsp
+    enum:
+      - ti,j721e-c66-dsp
+      - ti,j721e-c71-dsp
     description:
       Use "ti,j721e-c66-dsp" for C66x DSPs on K3 J721E SoCs
+      Use "ti,j721e-c71-dsp" for C71x DSPs on K3 J721E SoCs
 
   reg:
     description: |
@@ -37,18 +40,11 @@ properties:
       Each entry should have the memory region's start address
       and the size of the region, the representation matching
       the parent node's '#address-cells' and '#size-cells' values.
-    minItems: 3
-    maxItems: 3
 
   reg-names:
     description: |
       Should contain strings with the names of the specific internal
       memory regions, and should be defined in this order
-    maxItems: 3
-    items:
-      - const: l2sram
-      - const: l1pram
-      - const: l1dram
 
   ti,sci:
     $ref: /schemas/types.yaml#/definitions/phandle
@@ -121,6 +117,41 @@ properties:
       should be defined as per the generic bindings in,
       Documentation/devicetree/bindings/sram/sram.yaml
 
+if:
+  properties:
+    compatible:
+      enum:
+        - ti,j721e-c66-dsp
+then:
+  properties:
+    reg:
+      minItems: 3
+      maxItems: 3
+    reg-names:
+      minItems: 3
+      maxItems: 3
+      items:
+        - const: l2sram
+        - const: l1pram
+        - const: l1dram
+else:
+  if:
+    properties:
+      compatible:
+        enum:
+          - ti,j721e-c71-dsp
+  then:
+    properties:
+      reg:
+        minItems: 2
+        maxItems: 2
+      reg-names:
+        minItems: 2
+        maxItems: 2
+        items:
+          - const: l2sram
+          - const: l1dram
+
 required:
  - compatible
  - reg
@@ -160,6 +191,18 @@ examples:
                 reg = <0x00 0xa6100000 0x00 0xf00000>;
                 no-map;
             };
+
+            c71_0_dma_memory_region: c71-dma-memory@a8000000 {
+                compatible = "shared-dma-pool";
+                reg = <0x00 0xa8000000 0x00 0x100000>;
+                no-map;
+            };
+
+            c71_0_memory_region: c71-memory@a8100000 {
+                compatible = "shared-dma-pool";
+                reg = <0x00 0xa8100000 0x00 0xf00000>;
+                no-map;
+            };
         };
 
         cbass_main: bus@100000 {
@@ -167,6 +210,7 @@ examples:
             #address-cells = <2>;
             #size-cells = <2>;
             ranges = <0x00 0x00100000 0x00 0x00100000 0x00 0x00020000>, /* ctrl mmr */
+                     <0x00 0x64800000 0x00 0x64800000 0x00 0x00800000>, /* C71_0 */
                      <0x4d 0x80800000 0x4d 0x80800000 0x00 0x00800000>, /* C66_0 */
                      <0x4d 0x81800000 0x4d 0x81800000 0x00 0x00800000>; /* C66_1 */
 
@@ -186,5 +230,21 @@ examples:
                                 <&c66_0_memory_region>;
                 mboxes = <&mailbox0_cluster3 &mbox_c66_0>;
             };
+
+            /* J721E C71_0 DSP node */
+            c71_0: dsp@64800000 {
+                compatible = "ti,j721e-c71-dsp";
+                reg = <0x00 0x64800000 0x00 0x00080000>,
+                      <0x00 0x64e00000 0x00 0x0000c000>;
+                reg-names = "l2sram", "l1dram";
+                ti,sci = <&dmsc>;
+                ti,sci-dev-id = <15>;
+                ti,sci-proc-ids = <0x30 0xFF>;
+                resets = <&k3_reset 15 1>;
+                firmware-name = "j7-c71_0-fw";
+                memory-region = <&c71_0_dma_memory_region>,
+                                <&c71_0_memory_region>;
+                mboxes = <&mailbox0_cluster4 &mbox_c71_0>;
+            };
         };
     };
-- 
2.26.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

* Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
From: Ira Weiny @ 2020-05-21 15:14 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen, dri-devel,
	linux-mips, James E.J. Bottomley, Max Filippov, Paul Mackerras,
	H. Peter Anvin, sparclinux, Dan Williams, Helge Deller, x86,
	linux-csky, Christoph Hellwig, Ingo Molnar, linux-snps-arc,
	linux-xtensa, Borislav Petkov, Al Viro, Andy Lutomirski,
	Thomas Gleixner, linux-arm-kernel, Chris Zankel,
	Thomas Bogendoerfer, linux-parisc, linux-kernel, Christian Koenig,
	Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200519194215.GA71941@roeck-us.net>

On Tue, May 19, 2020 at 12:42:15PM -0700, Guenter Roeck wrote:
> > On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> > > as do the nosmp sparc32 boot tests,
> > > but sparc32 boot tests with SMP enabled still fail with lots of messages
> > > such as:
> > > 
> > > BUG: Bad page state in process swapper/0  pfn:006a1
> > > page:f0933420 refcount:0 mapcount:1 mapping:(ptrval) index:0x1
> > > flags: 0x0()
> > > raw: 00000000 00000100 00000122 00000000 00000001 00000000 00000000 00000000
> > > page dumped because: nonzero mapcount
> > > Modules linked in:
> > > CPU: 0 PID: 1 Comm: swapper/0 Tainted: G    B             5.7.0-rc6-next-20200518-00002-gb178d2d56f29 #1
> > > [f00e7ab8 :
> > > bad_page+0xa8/0x108 ]
> > > [f00e8b54 :
> > > free_pcppages_bulk+0x154/0x52c ]
> > > [f00ea024 :
> > > free_unref_page+0x54/0x6c ]
> > > [f00ed864 :
> > > free_reserved_area+0x58/0xec ]
> > > [f0527104 :
> > > kernel_init+0x14/0x110 ]
> > > [f000b77c :
> > > ret_from_kernel_thread+0xc/0x38 ]
> > > [00000000 :
> > > 0x0 ]
> > > 
> > > Code path leading to that message is different but always the same
> > > from free_unref_page().
> > > 
> > > Still testing ppc images.
> > > 
> 
> ppc image tests are passing with this patch.

How about sparc?  I finally got your scripts to run on sparc and everything
looks to be passing?

Are we all good now?

Thanks again!
Ira

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH] usb: gadget: lpc32xx_udc: don't dereference ep pointer before null check
From: Colin King @ 2020-05-21 15:13 UTC (permalink / raw)
  To: Felipe Balbi, Greg Kroah-Hartman, Vladimir Zapolskiy,
	Sylvain Lemieux, linux-usb, linux-arm-kernel
  Cc: kernel-janitors, linux-kernel

From: Colin Ian King <colin.king@canonical.com>

Currently pointer ep is being dereferenced before it is null checked
leading to a null pointer dereference issue.  Fix this by only assigning
pointer udc once ep is known to be not null.  Also remove a debug
message that requires a valid udc which may not be possible at that
point.

Addresses-Coverity: ("Dereference before null check")
Fixes: 24a28e428351 ("USB: gadget driver for LPC32xx")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
 drivers/usb/gadget/udc/lpc32xx_udc.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/gadget/udc/lpc32xx_udc.c b/drivers/usb/gadget/udc/lpc32xx_udc.c
index cb997b82c008..7aefd6b5597b 100644
--- a/drivers/usb/gadget/udc/lpc32xx_udc.c
+++ b/drivers/usb/gadget/udc/lpc32xx_udc.c
@@ -1614,17 +1614,17 @@ static int lpc32xx_ep_enable(struct usb_ep *_ep,
 			     const struct usb_endpoint_descriptor *desc)
 {
 	struct lpc32xx_ep *ep = container_of(_ep, struct lpc32xx_ep, ep);
-	struct lpc32xx_udc *udc = ep->udc;
+	struct lpc32xx_udc *udc;
 	u16 maxpacket;
 	u32 tmp;
 	unsigned long flags;
 
 	/* Verify EP data */
 	if ((!_ep) || (!ep) || (!desc) ||
-	    (desc->bDescriptorType != USB_DT_ENDPOINT)) {
-		dev_dbg(udc->dev, "bad ep or descriptor\n");
+	    (desc->bDescriptorType != USB_DT_ENDPOINT))
 		return -EINVAL;
-	}
+
+	udc = ep->udc;
 	maxpacket = usb_endpoint_maxp(desc);
 	if ((maxpacket == 0) || (maxpacket > ep->maxpacket)) {
 		dev_dbg(udc->dev, "bad ep descriptor's packet size\n");
@@ -1872,7 +1872,7 @@ static int lpc32xx_ep_dequeue(struct usb_ep *_ep, struct usb_request *_req)
 static int lpc32xx_ep_set_halt(struct usb_ep *_ep, int value)
 {
 	struct lpc32xx_ep *ep = container_of(_ep, struct lpc32xx_ep, ep);
-	struct lpc32xx_udc *udc = ep->udc;
+	struct lpc32xx_udc *udc;
 	unsigned long flags;
 
 	if ((!ep) || (ep->hwep_num <= 1))
@@ -1882,6 +1882,7 @@ static int lpc32xx_ep_set_halt(struct usb_ep *_ep, int value)
 	if (ep->is_in)
 		return -EAGAIN;
 
+	udc = ep->udc;
 	spin_lock_irqsave(&udc->lock, flags);
 
 	if (value == 1) {
-- 
2.25.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 04/11] ARM: Allow IPIs to be handled as normal interrupts
From: Russell King - ARM Linux admin @ 2020-05-21 15:12 UTC (permalink / raw)
  To: Valentin Schneider
  Cc: Sumit Garg, kernel-team, Jason Cooper, Marc Zyngier, linux-kernel,
	Catalin Marinas, Thomas Gleixner, Will Deacon, linux-arm-kernel
In-Reply-To: <jhjk115xu4a.mognet@arm.com>

On Thu, May 21, 2020 at 03:03:49PM +0100, Valentin Schneider wrote:
> 
> On 19/05/20 23:24, Russell King - ARM Linux admin wrote:
> > On Tue, May 19, 2020 at 05:17:48PM +0100, Marc Zyngier wrote:
> >> In order to deal with IPIs as normal interrupts, let's add
> >> a new way to register them with the architecture code.
> >>
> >> set_smp_ipi_range() takes a range of interrupts, and allows
> >> the arch code to request them as if the were normal interrupts.
> >> A standard handler is then called by the core IRQ code to deal
> >> with the IPI.
> >>
> >> This means that we don't need to call irq_enter/irq_exit, and
> >> that we don't need to deal with set_irq_regs either. So let's
> >> move the dispatcher into its own function, and leave handle_IPI()
> >> as a compatibility function.
> >>
> >> On the sending side, let's make use of ipi_send_mask, which
> >> already exists for this purpose.
> >
> > You say nothing about the nesting of irq_enter() and irq_exit()
> > for scheduler_ipi().
> >
> > Given that lockdep introduced the requirement that hard IRQs can't
> > be nested, are we sure that calling irq_exit() twice is safe?
> >
> > Looking at irqtime_account_irq(), it seems that will cause double-
> > accounting of in-interrupt time, since we will increment
> > irq_start_time by just over twice the the period spent handling
> > the IPI.
> >
> > I think the rest of irq_exit() should be safe, but still, this
> > behaviour should be documented at the very least, if not avoided.
> >
> 
> x86 does the same (though IIUC only when tracing reschedule IPI's),

Right, so when the system is operating normally, then the accounting is
correct.  When the reschedule path is being explicitly traced, then
the accounting will be doubled for it.

What's being proposed for ARM is to always have this mis-accounting,
where no mis-accounting was present before - and some of us (me) /do/
enable IRQ accounting in our kernels as standard. So, you can take
this as a kernel regression report from a user.

> and MIPS has the same issue as it also uses generic IRQ IPI's - so
> although it's not ideal, I think we can live with it.

Yes, but is there anyone who cares about this for MIPS?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [GIT PULL] i.MX fixes for 5.7, round 2
From: Shawn Guo @ 2020-05-21 15:07 UTC (permalink / raw)
  To: soc, arm
  Cc: Stefan Agner, Li Yang, linux-imx, kernel, Fabio Estevam,
	linux-arm-kernel

The following changes since commit 1248c86fd6391c63da947718bbd43686fa95185f:

  arm64: dts: freescale: imx8mp: update input_val for AUDIOMIX_BIT_STREAM (2020-04-29 11:30:32 +0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-fixes-5.7-2

for you to fetch changes up to 665e7c73a7724a393b4ec92d1ae1e029925ef2b7:

  ARM: dts/imx6q-bx50v3: Set display interface clock parents (2020-05-20 10:48:02 +0800)

----------------------------------------------------------------
i.MX fixes for 5.7, round 2:

One imx6q-bx50v3 device tree change to fix an issue, attempting atomic
modeset while using HDMI and display port at the same time causes LDB
clock programming to destroy the programming of HDMI.

----------------------------------------------------------------
Robert Beckett (1):
      ARM: dts/imx6q-bx50v3: Set display interface clock parents

 arch/arm/boot/dts/imx6q-b450v3.dts  |  7 -------
 arch/arm/boot/dts/imx6q-b650v3.dts  |  7 -------
 arch/arm/boot/dts/imx6q-b850v3.dts  | 11 -----------
 arch/arm/boot/dts/imx6q-bx50v3.dtsi | 15 +++++++++++++++
 4 files changed, 15 insertions(+), 25 deletions(-)

_______________________________________________
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 5/7] arm64: dts: mt8183: add usb and phy nodes
From: Matthias Brugger @ 2020-05-21 15:06 UTC (permalink / raw)
  To: Chunfeng Yun, Greg Kroah-Hartman, Rob Herring
  Cc: Mark Rutland, devicetree, Mathias Nyman, linux-usb, linux-kernel,
	linux-mediatek, linux-arm-kernel
In-Reply-To: <1567150854-30033-6-git-send-email-chunfeng.yun@mediatek.com>



On 30/08/2019 09:40, Chunfeng Yun wrote:
> Add USB related nodes for MT8183, set it as host mode by default.
> 
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> v2~v3: no changes
> ---
>  arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 22 +++++++++
>  arch/arm64/boot/dts/mediatek/mt8183.dtsi    | 55 +++++++++++++++++++++
>  2 files changed, 77 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> index d8e555cbb5d3..142ff52f0f42 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> @@ -6,7 +6,9 @@
>   */
>  
>  /dts-v1/;
> +#include <dt-bindings/gpio/gpio.h>
>  #include "mt8183.dtsi"
> +#include "mt6358.dtsi"

mt6358.dtsi is accepted upstream now.
While the rest of the series implements wake up function, I understand that this
patch is independent and enables USB without wake up.

If so, let me know and I can take it now.

Regards,
Matthias

>  
>  / {
>  	model = "MediaTek MT8183 evaluation board";
> @@ -24,6 +26,16 @@
>  	chosen {
>  		stdout-path = "serial0:921600n8";
>  	};
> +
> +	usb_vbus: regulator@0 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "p0_vbus";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		gpio = <&pio 42 GPIO_ACTIVE_HIGH>;
> +		enable-active-high;
> +		regulator-always-on;
> +	};
>  };
>  
>  &auxadc {
> @@ -135,6 +147,16 @@
>  
>  };
>  
> +&ssusb {
> +	vusb33-supply = <&mt6358_vusb_reg>;
> +	dr_mode = "host";
> +	status = "okay";
> +};
> +
> +&usb_host {
> +	status = "okay";
> +};
> +
>  &uart0 {
>  	status = "okay";
>  };
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index c2749c4631bc..28da334237c6 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -8,6 +8,7 @@
>  #include <dt-bindings/clock/mt8183-clk.h>
>  #include <dt-bindings/interrupt-controller/arm-gic.h>
>  #include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/phy/phy.h>
>  #include "mt8183-pinfunc.h"
>  
>  / {
> @@ -372,6 +373,35 @@
>  			status = "disabled";
>  		};
>  
> +		ssusb: usb@11201000 {
> +			compatible = "mediatek,mt8183-mtu3", "mediatek,mtu3";
> +			reg = <0 0x11201000 0 0x2e00>,
> +			      <0 0x11203e00 0 0x0100>;
> +			reg-names = "mac", "ippc";
> +			interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_LOW>;
> +			phys = <&u2port0 PHY_TYPE_USB2>,
> +			       <&u3port0 PHY_TYPE_USB3>;
> +			clocks = <&infracfg CLK_INFRA_UNIPRO_SCK>,
> +				 <&infracfg CLK_INFRA_USB>;
> +			clock-names = "sys_ck", "ref_ck";
> +			#address-cells = <2>;
> +			#size-cells = <2>;
> +			ranges;
> +			status = "disabled";
> +
> +			usb_host: xhci@11200000 {
> +				compatible = "mediatek,mt8183-xhci",
> +					     "mediatek,mtk-xhci";
> +				reg = <0 0x11200000 0 0x1000>;
> +				reg-names = "mac";
> +				interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_LOW>;
> +				clocks = <&infracfg CLK_INFRA_UNIPRO_SCK>,
> +					 <&infracfg CLK_INFRA_USB>;
> +				clock-names = "sys_ck", "ref_ck";
> +				status = "disabled";
> +			};
> +		};
> +
>  		audiosys: syscon@11220000 {
>  			compatible = "mediatek,mt8183-audiosys", "syscon";
>  			reg = <0 0x11220000 0 0x1000>;
> @@ -384,6 +414,31 @@
>  			reg = <0 0x11f10000 0 0x1000>;
>  		};
>  
> +		u3phy: usb-phy@11f40000 {
> +			compatible = "mediatek,mt8183-tphy",
> +				     "mediatek,generic-tphy-v2";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			ranges = <0 0 0x11f40000 0x1000>;
> +			status = "okay";
> +
> +			u2port0: usb-phy@0 {
> +				reg = <0x0 0x700>;
> +				clocks = <&clk26m>;
> +				clock-names = "ref";
> +				#phy-cells = <1>;
> +				status = "okay";
> +			};
> +
> +			u3port0: usb-phy@0700 {
> +				reg = <0x0700 0x900>;
> +				clocks = <&clk26m>;
> +				clock-names = "ref";
> +				#phy-cells = <1>;
> +				status = "okay";
> +			};
> +		};
> +
>  		mfgcfg: syscon@13000000 {
>  			compatible = "mediatek,mt8183-mfgcfg", "syscon";
>  			reg = <0 0x13000000 0 0x1000>;
> 

_______________________________________________
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 12/12] bus: fsl-mc: Add ACPI support for fsl-mc
From: Laurentiu Tudor @ 2020-05-21 15:03 UTC (permalink / raw)
  To: Lorenzo Pieralisi, linux-arm-kernel
  Cc: devicetree, Sudeep Holla, Catalin Marinas, Will Deacon, linux-pci,
	Joerg Roedel, Hanjun Guo, Rafael J. Wysocki, iommu, linux-acpi,
	Makarand Pawagi, Rob Herring, Marc Zyngier, Diana Craciun,
	Bjorn Helgaas, Robin Murphy
In-Reply-To: <20200521130008.8266-13-lorenzo.pieralisi@arm.com>

Hi Lorenzo,

On 5/21/2020 4:00 PM, Lorenzo Pieralisi wrote:
> From: Diana Craciun <diana.craciun@oss.nxp.com>
> 
> Add ACPI support in the fsl-mc driver. Driver parses MC DSDT table to
> extract memory and other resources.
> 
> Interrupt (GIC ITS) information is extracted from the MADT table
> by drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
> 
> IORT table is parsed to configure DMA.
> 
> Signed-off-by: Makarand Pawagi <makarand.pawagi@nxp.com>
> Signed-off-by: Diana Craciun <diana.craciun@oss.nxp.com>
> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> ---

The author of this patch should be Makarand. I think I accidentaly broke
it when we exchanged the patches. Very sorry about it.

---
Best Regards, Laurentiu


>  drivers/bus/fsl-mc/fsl-mc-bus.c             | 73 +++++++++++++++-----
>  drivers/bus/fsl-mc/fsl-mc-msi.c             | 37 +++++-----
>  drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 75 ++++++++++++++++++++-
>  3 files changed, 150 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
> index 824ff77bbe86..324d49d6df89 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> @@ -18,6 +18,8 @@
>  #include <linux/bitops.h>
>  #include <linux/msi.h>
>  #include <linux/dma-mapping.h>
> +#include <linux/acpi.h>
> +#include <linux/iommu.h>
>  
>  #include "fsl-mc-private.h"
>  
> @@ -38,6 +40,7 @@ struct fsl_mc {
>  	struct fsl_mc_device *root_mc_bus_dev;
>  	u8 num_translation_ranges;
>  	struct fsl_mc_addr_translation_range *translation_ranges;
> +	void *fsl_mc_regs;
>  };
>  
>  /**
> @@ -56,6 +59,10 @@ struct fsl_mc_addr_translation_range {
>  	phys_addr_t start_phys_addr;
>  };
>  
> +#define FSL_MC_FAPR	0x28
> +#define MC_FAPR_PL	BIT(18)
> +#define MC_FAPR_BMT	BIT(17)
> +
>  /**
>   * fsl_mc_bus_match - device to driver matching callback
>   * @dev: the fsl-mc device to match against
> @@ -124,7 +131,10 @@ static int fsl_mc_dma_configure(struct device *dev)
>  	while (dev_is_fsl_mc(dma_dev))
>  		dma_dev = dma_dev->parent;
>  
> -	return of_dma_configure_id(dev, dma_dev->of_node, 0, &input_id);
> +	if (dev_of_node(dma_dev))
> +		return of_dma_configure_id(dev, dma_dev->of_node, 0, &input_id);
> +
> +	return acpi_dma_configure_id(dev, DEV_DMA_COHERENT, &input_id);
>  }
>  
>  static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
> @@ -865,8 +875,11 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
>  	struct fsl_mc_io *mc_io = NULL;
>  	int container_id;
>  	phys_addr_t mc_portal_phys_addr;
> -	u32 mc_portal_size;
> -	struct resource res;
> +	u32 mc_portal_size, mc_stream_id;
> +	struct resource *plat_res;
> +
> +	if (!iommu_present(&fsl_mc_bus_type))
> +		return -EPROBE_DEFER;
>  
>  	mc = devm_kzalloc(&pdev->dev, sizeof(*mc), GFP_KERNEL);
>  	if (!mc)
> @@ -874,19 +887,33 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
>  
>  	platform_set_drvdata(pdev, mc);
>  
> +	plat_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> +	mc->fsl_mc_regs = devm_ioremap_resource(&pdev->dev, plat_res);
> +	if (IS_ERR(mc->fsl_mc_regs))
> +		return PTR_ERR(mc->fsl_mc_regs);
> +
> +	if (IS_ENABLED(CONFIG_ACPI) && !dev_of_node(&pdev->dev)) {
> +		mc_stream_id = readl(mc->fsl_mc_regs + FSL_MC_FAPR);
> +		/*
> +		 * HW ORs the PL and BMT bit, places the result in bit 15 of
> +		 * the StreamID and ORs in the ICID. Calculate it accordingly.
> +		 */
> +		mc_stream_id = (mc_stream_id & 0xffff) |
> +				((mc_stream_id & (MC_FAPR_PL | MC_FAPR_BMT)) ?
> +					0x4000 : 0);
> +		error = acpi_dma_configure_id(&pdev->dev, DEV_DMA_COHERENT,
> +					      &mc_stream_id);
> +		if (error)
> +			dev_warn(&pdev->dev, "failed to configure dma: %d.\n",
> +				 error);
> +	}
> +
>  	/*
>  	 * Get physical address of MC portal for the root DPRC:
>  	 */
> -	error = of_address_to_resource(pdev->dev.of_node, 0, &res);
> -	if (error < 0) {
> -		dev_err(&pdev->dev,
> -			"of_address_to_resource() failed for %pOF\n",
> -			pdev->dev.of_node);
> -		return error;
> -	}
> -
> -	mc_portal_phys_addr = res.start;
> -	mc_portal_size = resource_size(&res);
> +	plat_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	mc_portal_phys_addr = plat_res->start;
> +	mc_portal_size = resource_size(plat_res);
>  	error = fsl_create_mc_io(&pdev->dev, mc_portal_phys_addr,
>  				 mc_portal_size, NULL,
>  				 FSL_MC_IO_ATOMIC_CONTEXT_PORTAL, &mc_io);
> @@ -903,11 +930,13 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
>  	dev_info(&pdev->dev, "MC firmware version: %u.%u.%u\n",
>  		 mc_version.major, mc_version.minor, mc_version.revision);
>  
> -	error = get_mc_addr_translation_ranges(&pdev->dev,
> -					       &mc->translation_ranges,
> -					       &mc->num_translation_ranges);
> -	if (error < 0)
> -		goto error_cleanup_mc_io;
> +	if (dev_of_node(&pdev->dev)) {
> +		error = get_mc_addr_translation_ranges(&pdev->dev,
> +						&mc->translation_ranges,
> +						&mc->num_translation_ranges);
> +		if (error < 0)
> +			goto error_cleanup_mc_io;
> +	}
>  
>  	error = dprc_get_container_id(mc_io, 0, &container_id);
>  	if (error < 0) {
> @@ -934,6 +963,7 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
>  		goto error_cleanup_mc_io;
>  
>  	mc->root_mc_bus_dev = mc_bus_dev;
> +	mc_bus_dev->dev.fwnode = pdev->dev.fwnode;
>  	return 0;
>  
>  error_cleanup_mc_io:
> @@ -967,11 +997,18 @@ static const struct of_device_id fsl_mc_bus_match_table[] = {
>  
>  MODULE_DEVICE_TABLE(of, fsl_mc_bus_match_table);
>  
> +static const struct acpi_device_id fsl_mc_bus_acpi_match_table[] = {
> +	{"NXP0008", 0 },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(acpi, fsl_mc_bus_acpi_match_table);
> +
>  static struct platform_driver fsl_mc_bus_driver = {
>  	.driver = {
>  		   .name = "fsl_mc_bus",
>  		   .pm = NULL,
>  		   .of_match_table = fsl_mc_bus_match_table,
> +		   .acpi_match_table = fsl_mc_bus_acpi_match_table,
>  		   },
>  	.probe = fsl_mc_bus_probe,
>  	.remove = fsl_mc_bus_remove,
> diff --git a/drivers/bus/fsl-mc/fsl-mc-msi.c b/drivers/bus/fsl-mc/fsl-mc-msi.c
> index e7bbff445a83..8edadf05cbb7 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-msi.c
> +++ b/drivers/bus/fsl-mc/fsl-mc-msi.c
> @@ -13,6 +13,7 @@
>  #include <linux/irq.h>
>  #include <linux/irqdomain.h>
>  #include <linux/msi.h>
> +#include <linux/acpi_iort.h>
>  
>  #include "fsl-mc-private.h"
>  
> @@ -179,25 +180,31 @@ struct irq_domain *fsl_mc_msi_create_irq_domain(struct fwnode_handle *fwnode,
>  
>  struct irq_domain *fsl_mc_find_msi_domain(struct device *dev)
>  {
> -	struct irq_domain *msi_domain = NULL;
> +	struct device *root_dprc_dev;
> +	struct device *bus_dev;
> +	struct irq_domain *msi_domain;
>  	struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
>  
> -	msi_domain = of_msi_map_get_device_domain(dev, mc_dev->icid,
> +	fsl_mc_get_root_dprc(dev, &root_dprc_dev);
> +	bus_dev = root_dprc_dev->parent;
> +
> +	if (bus_dev->of_node) {
> +		msi_domain = of_msi_map_get_device_domain(dev,
> +						  mc_dev->icid,
>  						  DOMAIN_BUS_FSL_MC_MSI);
>  
> -	/*
> -	 * if the msi-map property is missing assume that all the
> -	 * child containers inherit the domain from the parent
> -	 */
> -	if (!msi_domain) {
> -		struct device *root_dprc_dev;
> -		struct device *bus_dev;
> -
> -		fsl_mc_get_root_dprc(dev, &root_dprc_dev);
> -		bus_dev = root_dprc_dev->parent;
> -		msi_domain = of_msi_get_domain(bus_dev,
> -					       bus_dev->of_node,
> -					       DOMAIN_BUS_FSL_MC_MSI);
> +		/*
> +		 * if the msi-map property is missing assume that all the
> +		 * child containers inherit the domain from the parent
> +		 */
> +		if (!msi_domain)
> +
> +			msi_domain = of_msi_get_domain(bus_dev,
> +						bus_dev->of_node,
> +						DOMAIN_BUS_FSL_MC_MSI);
> +	} else {
> +		msi_domain = iort_get_device_domain(dev, mc_dev->icid,
> +						    DOMAIN_BUS_FSL_MC_MSI);
>  	}
>  
>  	return msi_domain;
> diff --git a/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c b/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
> index a5c8d577e424..b8b948fb6b2d 100644
> --- a/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
> @@ -7,6 +7,8 @@
>   *
>   */
>  
> +#include <linux/acpi.h>
> +#include <linux/acpi_iort.h>
>  #include <linux/of_device.h>
>  #include <linux/of_address.h>
>  #include <linux/irq.h>
> @@ -30,7 +32,8 @@ static u32 fsl_mc_msi_domain_get_msi_id(struct irq_domain *domain,
>  	u32 out_id;
>  
>  	of_node = irq_domain_get_of_node(domain);
> -	out_id = of_msi_map_id(&mc_dev->dev, of_node, mc_dev->icid);
> +	out_id = of_node ? of_msi_map_id(&mc_dev->dev, of_node, mc_dev->icid) :
> +			iort_msi_map_id(&mc_dev->dev, mc_dev->icid);
>  
>  	return out_id;
>  }
> @@ -79,7 +82,67 @@ static const struct of_device_id its_device_id[] = {
>  	{},
>  };
>  
> -static int __init its_fsl_mc_msi_init(void)
> +static int __init its_fsl_mc_msi_init_one(struct fwnode_handle *handle,
> +					  const char *name)
> +{
> +	struct irq_domain *parent;
> +	struct irq_domain *mc_msi_domain;
> +
> +	parent = irq_find_matching_fwnode(handle, DOMAIN_BUS_NEXUS);
> +	if (!parent || !msi_get_domain_info(parent)) {
> +		pr_err("%s: Unable to locate ITS domain\n", name);
> +		return -ENXIO;
> +	}
> +
> +	mc_msi_domain = fsl_mc_msi_create_irq_domain(handle,
> +						&its_fsl_mc_msi_domain_info,
> +						parent);
> +	if (!mc_msi_domain)
> +		pr_err("ACPIF: unable to create fsl-mc domain\n");
> +
> +	pr_info("fsl-mc MSI: domain created\n");
> +
> +	return 0;
> +}
> +
> +static int __init
> +its_fsl_mc_msi_parse_madt(union acpi_subtable_headers *header,
> +			  const unsigned long end)
> +{
> +	struct acpi_madt_generic_translator *its_entry;
> +	struct fwnode_handle *dom_handle;
> +	const char *node_name;
> +	int err = -ENXIO;
> +
> +	its_entry = (struct acpi_madt_generic_translator *)header;
> +	node_name = kasprintf(GFP_KERNEL, "ITS@0x%lx",
> +			      (long)its_entry->base_address);
> +
> +	dom_handle = iort_find_domain_token(its_entry->translation_id);
> +	if (!dom_handle) {
> +		pr_err("%s: Unable to locate ITS domain handle\n", node_name);
> +		goto out;
> +	}
> +
> +	err = its_fsl_mc_msi_init_one(dom_handle, node_name);
> +	if (!err)
> +		pr_info("fsl-mc MSI: %s domain created\n", node_name);
> +
> +out:
> +	kfree(node_name);
> +	return err;
> +}
> +
> +
> +static int __init its_fsl_mc_acpi_msi_init(void)
> +{
> +	acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
> +			      its_fsl_mc_msi_parse_madt, 0);
> +
> +	return 0;
> +}
> +
> +static int __init its_fsl_mc_of_msi_init(void)
>  {
>  	struct device_node *np;
>  	struct irq_domain *parent;
> @@ -113,4 +176,12 @@ static int __init its_fsl_mc_msi_init(void)
>  	return 0;
>  }
>  
> +static int __init its_fsl_mc_msi_init(void)
> +{
> +	its_fsl_mc_of_msi_init();
> +	its_fsl_mc_acpi_msi_init();
> +
> +	return 0;
> +}
> +
>  early_initcall(its_fsl_mc_msi_init);
> 

_______________________________________________
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 v12 2/3] i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver
From: Andy Shevchenko @ 2020-05-21 14:53 UTC (permalink / raw)
  To: Tali Perry
  Cc: devicetree, Tomer Maimon, Wolfram Sang, avifishman70,
	Patrick Venture, OpenBMC Maillist, Brendan Higgins, Ofer Yehielli,
	Linux Kernel Mailing List, kfting, Rob Herring, linux-i2c,
	Nancy Yuen, linux-arm-kernel, Benjamin Fair
In-Reply-To: <CAHb3i=vcVLWHjdiJoNZQrwJCqzszpOL7e9SAjqObsZCRH4ifwg@mail.gmail.com>

On Thu, May 21, 2020 at 05:45:03PM +0300, Tali Perry wrote:
> On Thu, May 21, 2020 at 5:31 PM Wolfram Sang <wsa@the-dreams.de> wrote:
> > On Thu, May 21, 2020 at 05:23:40PM +0300, Andy Shevchenko wrote:
> > > On Thu, May 21, 2020 at 02:09:09PM +0300, Tali Perry wrote:
> > > > Add Nuvoton NPCM BMC I2C controller driver.
> > >
> > > Thanks. My comments below.
> > > After addressing them, FWIW,
> > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> >
> > Thanks, Andy, for all the review!
> >
> 
> Highly appreciate your time and patience for a newbie :)
> 
> > From a glimpse, this looks good to go. I will have a close look later
> > today.
> >
> > > > +#ifdef CONFIG_DEBUG_FS
> > >
> > > Again, why is this here?
> > >
> > > Have you checked debugfs.h for !CONFIG_DEBUG_FS case?
> 
> I compiled both options. I removed the ifdef in most places, except in the
> struct itself. Users that don't use the debugfs don't need this in the struct.
> 
> >
> > I wondered also about DEBUG_FS entries. I can see their value when
> > developing the driver. But since this is done now, do they really help a
> > user to debug a difficult case? I am not sure, and then I wonder if we
> > should have that code in upstream. I am open for discussion, though.
> 
> The user wanted to have health monitor implemented on top of the driver.
> The user has 16 channels connected the multiple devices. All are operated
> using various daemons in the system. Sometimes the slave devices are power down.
> Therefor the user wanted to track the health status of the devices.

Ah, then there are these options I have in mind (Wolfram, FYI as well!):
1) push with debugfs as a temporary solution and convert to devlink health protocol [1];
2) drop it and develop devlink_health solution;
3) push debugfs and wait if I²C will gain devlink health support

[1]: https://www.kernel.org/doc/html/latest/networking/devlink/devlink-health.html

-- 
With Best Regards,
Andy Shevchenko



_______________________________________________
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] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build
From: Russell King - ARM Linux admin @ 2020-05-21 14:50 UTC (permalink / raw)
  To: Mike Rapoport
  Cc: Florian Fainelli, Arnd Bergmann, Stephen Boyd, Kevin Cernekee,
	Doug Berger, Gregory Fong, linux-arm-kernel
In-Reply-To: <20200521140745.GS1059226@linux.ibm.com>

On Thu, May 21, 2020 at 05:07:45PM +0300, Mike Rapoport wrote:
> On Thu, May 21, 2020 at 03:33:29PM +0300, Mike Rapoport wrote:
> > On Thu, May 21, 2020 at 01:03:08PM +0100, Russell King - ARM Linux admin wrote:
> > > On Thu, May 21, 2020 at 11:18:23AM +0300, Mike Rapoport wrote:
> > > > (resendig for the correct address and with mailing list cc'ed, sorry for
> > > > the noise)
> > > > 
> > > > Hi,
> > > > 
> > > > Following the discussion at [1], I'm resending the patches that enable
> > > > memory model selection in menuconfig and such.
> > > > 
> > > > These patches do not change the way the configuration is generated from the
> > > > defconfigs and they do not change explicit selection of SPARSEMEM for
> > > > platforms that have "select ARCH_ENABLE_SPARSEMEM".
> > > > 
> > > > The mere change is that when a user runs an interactive configuration they
> > > > will be allowed to select between FLATMEM and SPARSMEM, which is not the
> > > > case today.
> > > > 
> > > > There is indeed some awkwardness in, e.g. removal of
> > > > ARCH_SPARSEMEM_DEFAULT, but this is what memory model selection logic in
> > > > mm/Kconfig imposes.
> > > > 
> > > > For example, below is the diffs of the configurations generated with
> > > > 'make rpc_defconfig' and 'make defconfig':
> > > > 
> > > > $ diff -s old/rpc_defconfig new/rpc_defconfig
> > > > Files old/rpc_defconfig and new/rpc_defconfig are identical
> > > > 
> > > > $ diff -u old/defconfig new/defconfig
> > > > --- old/defconfig	2020-05-20 17:51:01.832649705 +0300
> > > > +++ new/defconfig	2020-05-20 18:15:21.084385880 +0300
> > > > @@ -674,6 +674,9 @@
> > > >  CONFIG_AEABI=y
> > > >  # CONFIG_OABI_COMPAT is not set
> > > >  CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
> > > > +CONFIG_ARCH_SELECT_MEMORY_MODEL=y
> > > > +CONFIG_ARCH_FLATMEM_ENABLE=y
> > > > +CONFIG_ARCH_SPARSEMEM_ENABLE=y
> > > >  CONFIG_HAVE_ARCH_PFN_VALID=y
> > > >  CONFIG_HIGHMEM=y
> > > >  CONFIG_HIGHPTE=y
> > > > @@ -1061,6 +1064,9 @@
> > > >  #
> > > >  # Memory Management options
> > > >  #
> > > > +CONFIG_SELECT_MEMORY_MODEL=y
> > > > +CONFIG_FLATMEM_MANUAL=y
> > > > +# CONFIG_SPARSEMEM_MANUAL is not set
> > > >  CONFIG_FLATMEM=y
> > > >  CONFIG_FLAT_NODE_MEM_MAP=y
> > > >  CONFIG_ARCH_KEEP_MEMBLOCK=y
> > > 
> > > Right, but the question is whether we want to offer flatmem for rpc.
> > > It isn't allowed today, and so far no one has said why it's a
> > > desirable change to make.
> > 
> > With ARCH_RPC=y (or ARCH_SA1100 or ARCH_EP93XX for that matter)
> > ARCH_MULTIPLATFORM=n which prevents ARCH_SELECT_MEMORY_MODEL from being
> > enabled and since any of these machines explicitly selects
> > ARCH_SPARSEMEM_ENABLE, the only available memory model would be
> > SPARSEMEM.
> > 
> > I played a bit with menuconfig and if any of the platforms requiring
> > sparsemem is selected, the menu allowing the user to choose the memory
> > model disappears.
> 
> Ah, when either of these patforms will become a part of the
> multiplatform build, the only option for multiplatform build will be
> sparsemem.
> So it would be nice if somebody could check the cost of using sparsemem
> vs flatmem, espessially on low end machines.

Do you think they will become part of multiplatform?

If they're low-end machines, then adding:

(a) the additional memory overhead of a multiplatform kernel
(b) the additional runtime overhead of the complexities of multiplatform
    kernels

is surely an odd thing to do, especially when few really care about
these platforms becoming part of a multiplatform kernel, except those
who like the idea of multiplat.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up

_______________________________________________
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 v12 2/3] i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver
From: Tali Perry @ 2020-05-21 14:45 UTC (permalink / raw)
  To: Wolfram Sang
  Cc: devicetree, Tomer Maimon, Nancy Yuen, avifishman70,
	Patrick Venture, OpenBMC Maillist, Brendan Higgins, Ofer Yehielli,
	Linux Kernel Mailing List, kfting, Rob Herring, linux-i2c,
	Andy Shevchenko, linux-arm-kernel, Benjamin Fair
In-Reply-To: <20200521143100.GA16812@ninjato>

On Thu, May 21, 2020 at 5:31 PM Wolfram Sang <wsa@the-dreams.de> wrote:
>
> Hi Tali, Andy!
>
> On Thu, May 21, 2020 at 05:23:40PM +0300, Andy Shevchenko wrote:
> > On Thu, May 21, 2020 at 02:09:09PM +0300, Tali Perry wrote:
> > > Add Nuvoton NPCM BMC I2C controller driver.
> >
> > Thanks. My comments below.
> > After addressing them, FWIW,
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> Thanks, Andy, for all the review!
>

Highly appreciate your time and patience for a newbie :)

> From a glimpse, this looks good to go. I will have a close look later
> today.
>
> > > +#ifdef CONFIG_DEBUG_FS
> >
> > Again, why is this here?
> >
> > Have you checked debugfs.h for !CONFIG_DEBUG_FS case?

I compiled both options. I removed the ifdef in most places, except in the
struct itself. Users that don't use the debugfs don't need this in the struct.

>
> I wondered also about DEBUG_FS entries. I can see their value when
> developing the driver. But since this is done now, do they really help a
> user to debug a difficult case? I am not sure, and then I wonder if we
> should have that code in upstream. I am open for discussion, though.

The user wanted to have health monitor implemented on top of the driver.
The user has 16 channels connected the multiple devices. All are operated
using various daemons in the system. Sometimes the slave devices are power down.
Therefor the user wanted to track the health status of the devices.

>
> > > +MODULE_VERSION("0.1.3");
> >
> > Module version is defined by kernel commit hash. But it's up to you and
> > subsystem maintainer to decide.
>
> Please drop it. I also think commit id's (or even kernel versions) are a
> more precise description.

will remove.

>
> Regards,
>
>    Wolfram
>

BR,
Tali

_______________________________________________
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/16] arm64: dts: arm: Fix node address fields
From: Liviu Dudau @ 2020-05-21 14:40 UTC (permalink / raw)
  To: Robin Murphy
  Cc: Mark Rutland, devicetree, Lorenzo Pieralisi, Rob Herring,
	Andre Przywara, Sudeep Holla, linux-arm-kernel
In-Reply-To: <347cdcba-a1cf-d308-1cc2-6c2194f40d19@arm.com>

On Tue, May 05, 2020 at 06:18:19PM +0100, Robin Murphy wrote:
> On 2020-05-05 5:52 pm, Andre Przywara wrote:
> > The Arm Ltd. boards were using an outdated address convention in the DT
> > node names, by separating the high from the low 32-bits of an address by
> > a comma.
> 
> I thought that historically that was deliberate, since the actual thing
> being encoded is <chip select>,<address>, rather than just cosmetically
> splitting a 64-bit address value?
> 
> Or maybe I'm thinking too far back and things have already changed in the
> meantime :/

Robin is right, if you look in the "ARM Motherboard Express µATX Technical
Reference Manual", in the RS1 memory map (aka "Cortex-A Series memory map")
the Ethernet for example is at CS2 offset 0x02000000. CS2 area is between
0x18000000 and 0x1c000000. So actual physical address for LAN9118 is
0x1a000000.

You might want to drop this patch or convert to physical addresses.

Best regards,
Liviu

> 
> Robin.
> 
> > Remove the comma from the node name suffix to be DT spec compliant.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> >   arch/arm/boot/dts/vexpress-v2m-rs1.dtsi              | 10 +++++-----
> >   arch/arm64/boot/dts/arm/foundation-v8.dtsi           |  4 ++--
> >   arch/arm64/boot/dts/arm/juno-motherboard.dtsi        |  6 +++---
> >   arch/arm64/boot/dts/arm/rtsm_ve-motherboard-rs2.dtsi |  2 +-
> >   arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi     |  6 +++---
> >   5 files changed, 14 insertions(+), 14 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> > index 5c183483ec3b..8010cdcdb37a 100644
> > --- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> > +++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> > @@ -31,7 +31,7 @@
> >   			#interrupt-cells = <1>;
> >   			ranges;
> > -			nor_flash: flash@0,00000000 {
> > +			nor_flash: flash@0 {
> >   				compatible = "arm,vexpress-flash", "cfi-flash";
> >   				reg = <0 0x00000000 0x04000000>,
> >   				      <4 0x00000000 0x04000000>;
> > @@ -41,13 +41,13 @@
> >   				};
> >   			};
> > -			psram@1,00000000 {
> > +			psram@100000000 {
> >   				compatible = "arm,vexpress-psram", "mtd-ram";
> >   				reg = <1 0x00000000 0x02000000>;
> >   				bank-width = <4>;
> >   			};
> > -			ethernet@2,02000000 {
> > +			ethernet@202000000 {
> >   				compatible = "smsc,lan9118", "smsc,lan9115";
> >   				reg = <2 0x02000000 0x10000>;
> >   				interrupts = <15>;
> > @@ -59,14 +59,14 @@
> >   				vddvario-supply = <&v2m_fixed_3v3>;
> >   			};
> > -			usb@2,03000000 {
> > +			usb@203000000 {
> >   				compatible = "nxp,usb-isp1761";
> >   				reg = <2 0x03000000 0x20000>;
> >   				interrupts = <16>;
> >   				port1-otg;
> >   			};
> > -			iofpga@3,00000000 {
> > +			iofpga@300000000 {
> >   				compatible = "simple-bus";
> >   				#address-cells = <1>;
> >   				#size-cells = <1>;
> > diff --git a/arch/arm64/boot/dts/arm/foundation-v8.dtsi b/arch/arm64/boot/dts/arm/foundation-v8.dtsi
> > index 12f039fa3dad..e26b492795c5 100644
> > --- a/arch/arm64/boot/dts/arm/foundation-v8.dtsi
> > +++ b/arch/arm64/boot/dts/arm/foundation-v8.dtsi
> > @@ -151,7 +151,7 @@
> >   				<0 0 41 &gic 0 0 GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
> >   				<0 0 42 &gic 0 0 GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
> > -		ethernet@2,02000000 {
> > +		ethernet@202000000 {
> >   			compatible = "smsc,lan91c111";
> >   			reg = <2 0x02000000 0x10000>;
> >   			interrupts = <15>;
> > @@ -178,7 +178,7 @@
> >   			clock-output-names = "v2m:refclk32khz";
> >   		};
> > -		iofpga@3,00000000 {
> > +		iofpga@300000000 {
> >   			compatible = "simple-bus";
> >   			#address-cells = <1>;
> >   			#size-cells = <1>;
> > diff --git a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> > index e3983ded3c3c..d5cefddde08c 100644
> > --- a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> > +++ b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> > @@ -103,7 +103,7 @@
> >   				};
> >   			};
> > -			flash@0,00000000 {
> > +			flash@0 {
> >   				/* 2 * 32MiB NOR Flash memory mounted on CS0 */
> >   				compatible = "arm,vexpress-flash", "cfi-flash";
> >   				reg = <0 0x00000000 0x04000000>;
> > @@ -120,7 +120,7 @@
> >   				};
> >   			};
> > -			ethernet@2,00000000 {
> > +			ethernet@200000000 {
> >   				compatible = "smsc,lan9118", "smsc,lan9115";
> >   				reg = <2 0x00000000 0x10000>;
> >   				interrupts = <3>;
> > @@ -133,7 +133,7 @@
> >   				vddvario-supply = <&mb_fixed_3v3>;
> >   			};
> > -			iofpga@3,00000000 {
> > +			iofpga@300000000 {
> >   				compatible = "simple-bus";
> >   				#address-cells = <1>;
> >   				#size-cells = <1>;
> > diff --git a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard-rs2.dtsi b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard-rs2.dtsi
> > index 60703b5763c6..350cbf17e8b4 100644
> > --- a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard-rs2.dtsi
> > +++ b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard-rs2.dtsi
> > @@ -9,7 +9,7 @@
> >   		motherboard {
> >   			arm,v2m-memory-map = "rs2";
> > -			iofpga@3,00000000 {
> > +			iofpga@300000000 {
> >   				virtio-p9@140000 {
> >   					compatible = "virtio,mmio";
> >   					reg = <0x140000 0x200>;
> > diff --git a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
> > index e333c8d2d0e4..d1bfa62ca073 100644
> > --- a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
> > +++ b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
> > @@ -17,14 +17,14 @@
> >   			#interrupt-cells = <1>;
> >   			ranges;
> > -			flash@0,00000000 {
> > +			flash@0 {
> >   				compatible = "arm,vexpress-flash", "cfi-flash";
> >   				reg = <0 0x00000000 0x04000000>,
> >   				      <4 0x00000000 0x04000000>;
> >   				bank-width = <4>;
> >   			};
> > -			ethernet@2,02000000 {
> > +			ethernet@202000000 {
> >   				compatible = "smsc,lan91c111";
> >   				reg = <2 0x02000000 0x10000>;
> >   				interrupts = <15>;
> > @@ -51,7 +51,7 @@
> >   				clock-output-names = "v2m:refclk32khz";
> >   			};
> > -			iofpga@3,00000000 {
> > +			iofpga@300000000 {
> >   				compatible = "simple-bus";
> >   				#address-cells = <1>;
> >   				#size-cells = <1>;
> > 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [RFC PATCH shawnguo] clk: imx: imx8m_clk_composite_mux_ops can be static
From: Shawn Guo @ 2020-05-21 14:39 UTC (permalink / raw)
  To: kbuild test robot; +Cc: Dong Aisheng, Peng Fan, kbuild-all, linux-arm-kernel
In-Reply-To: <20200521110439.GA55876@f61f8b3f25ca>

On Thu, May 21, 2020 at 07:04:39PM +0800, kbuild test robot wrote:
> 
> Fixes: 3f0365dafe32 ("clk: imx: add mux ops for i.MX8M composite clk")
> Signed-off-by: kbuild test robot <lkp@intel.com>
> ---
>  clk-composite-8m.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/imx/clk-composite-8m.c b/drivers/clk/imx/clk-composite-8m.c
> index 8fa60f22d377f..2d9562ebddc3f 100644
> --- a/drivers/clk/imx/clk-composite-8m.c
> +++ b/drivers/clk/imx/clk-composite-8m.c
> @@ -164,7 +164,7 @@ imx8m_clk_composite_mux_determine_rate(struct clk_hw *hw,
>  }
>  
>  
> -const struct clk_ops imx8m_clk_composite_mux_ops = {
> +static const struct clk_ops imx8m_clk_composite_mux_ops = {

Amended the change.  Thanks!

Shawn

>  	.get_parent = imx8m_clk_composite_mux_get_parent,
>  	.set_parent = imx8m_clk_composite_mux_set_parent,
>  	.determine_rate = imx8m_clk_composite_mux_determine_rate,

_______________________________________________
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 v7 13/24] iommu/arm-smmu-v3: Enable broadcast TLB maintenance
From: Marc Zyngier @ 2020-05-21 14:38 UTC (permalink / raw)
  To: Will Deacon
  Cc: Jean-Philippe Brucker, kevin.tian, jacob.jun.pan, devicetree, jgg,
	linux-pci, joro, Jonathan.Cameron, fenghua.yu, hch, linux-mm,
	iommu, zhangfei.gao, catalin.marinas, felix.kuehling, xuzaibo,
	robin.murphy, christian.koenig, linux-arm-kernel, baolu.lu
In-Reply-To: <20200521141730.GJ6608@willie-the-truck>

On 2020-05-21 15:17, Will Deacon wrote:
> [+Marc]
> 
> On Tue, May 19, 2020 at 07:54:51PM +0200, Jean-Philippe Brucker wrote:
>> The SMMUv3 can handle invalidation targeted at TLB entries with shared
>> ASIDs. If the implementation supports broadcast TLB maintenance, 
>> enable it
>> and keep track of it in a feature bit. The SMMU will then be affected 
>> by
>> inner-shareable TLB invalidations from other agents.
>> 
>> A major side-effect of this change is that stage-2 translation 
>> contexts
>> are now affected by all invalidations by VMID. VMIDs are all shared 
>> and
>> the only ways to prevent over-invalidation, since the stage-2 page 
>> tables
>> are not shared between CPU and SMMU, are to either disable BTM or 
>> allocate
>> different VMIDs. This patch does not address the problem.
> 
> This sounds like a potential performance issue, particularly as we 
> expose
> stage-2 contexts via VFIO directly. Maybe we could reserve some portion 
> of
> VMID space for the SMMU? Marc, what do you reckon?

Certainly doable when we have 16bits VMIDs. With smaller VMID spaces 
(like on
v8.0), this is a bit more difficult (we do have pretty large v8.0 
systems
around). How many VMID bits are we talking about?

         M.
-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v3] drm/exynos: Remove dev_err() on platform_get_irq() failure
From: Tamseel Shams @ 2020-05-21 14:22 UTC (permalink / raw)
  To: inki.dae, jy0922.shim, sw0312.kim, kyungmin.park, airlied, daniel
  Cc: linux-samsung-soc, shaik.ameer, linux-kernel, krzk, dri-devel,
	alim.akhtar, Tamseel Shams, linux-arm-kernel
In-Reply-To: <CGME20200521143647epcas5p279d486b29125419c67ff96e0b5b1454e@epcas5p2.samsung.com>

platform_get_irq() will call dev_err() itself on failure,
so there is no need for the driver to also do this.
This is detected by coccinelle.

Signed-off-by: Tamseel Shams <m.shams@samsung.com>
---
- Changes since v2:
* Addressed Inki Dae comments

 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index fcee33a43aca..03be31427181 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1498,7 +1498,6 @@ static int g2d_probe(struct platform_device *pdev)
 
 	g2d->irq = platform_get_irq(pdev, 0);
 	if (g2d->irq < 0) {
-		dev_err(dev, "failed to get irq\n");
 		ret = g2d->irq;
 		goto err_put_clk;
 	}
-- 
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

* Re: [PATCH v12 3/3] i2c: npcm7xx: Add support for slave mode for Nuvoton
From: Andy Shevchenko @ 2020-05-21 14:36 UTC (permalink / raw)
  To: Tali Perry
  Cc: devicetree, tmaimon77, yuenn, avifishman70, venture, openbmc, wsa,
	brendanhiggins, ofery, linux-kernel, kfting, robh+dt, linux-i2c,
	linux-arm-kernel, benjaminfair
In-Reply-To: <20200521110910.45518-4-tali.perry1@gmail.com>

On Thu, May 21, 2020 at 02:09:10PM +0300, Tali Perry wrote:
> Add support for slave mode for Nuvoton
> NPCM BMC I2C controller driver.

...

> +#if IS_ENABLED(CONFIG_I2C_SLAVE)
> +/*
> + * npcm_i2caddr array:
> + * The module supports having multiple own slave addresses.
> + * Since the addr regs are sprinkled all over the address space,
> + * use this array to get the address or each register.
> + */
> +#define I2C_NUM_OWN_ADDR 10
> +const int  npcm_i2caddr[I2C_NUM_OWN_ADDR] = {NPCM_I2CADDR1, NPCM_I2CADDR2,

Extra spaces.
On top. please start assignment from the new line.

> +					     NPCM_I2CADDR3, NPCM_I2CADDR4,
> +					     NPCM_I2CADDR5, NPCM_I2CADDR6,
> +					     NPCM_I2CADDR7, NPCM_I2CADDR8,

> +					     NPCM_I2CADDR9, NPCM_I2CADDR10};

Split }; to new line and leave comma with the last member.

> +#endif

...

> +static int  npcm_i2c_slave_enable(struct npcm_i2c *bus, enum i2c_addr addr_type,
> +				  u8 addr, bool enable)

Extra spaces. Check entire patch for that and fix accordingly.

> +#if IS_ENABLED(CONFIG_I2C_SLAVE)
> +	if (bus->slave)

> +		npcm_i2c_slave_enable(bus, I2C_SLAVE_ADDR1, bus->slave->addr,
> +				      true);

I would leave this on one line.

> +#endif

...

> +static void npcm_i2c_write_fifo_slave(struct npcm_i2c *bus, u16 max_bytes)
> +{
> +	u8 size_free_fifo;

+ blank line.

> +	/*
> +	 * Fill the FIFO, while the FIFO is not full and there are more bytes
> +	 * to write
> +	 */
> +	npcm_i2c_clear_fifo_int(bus);
> +	npcm_i2c_clear_tx_fifo(bus);
> +	iowrite8(0, bus->reg + NPCM_I2CTXF_CTL);

> +	size_free_fifo = I2C_HW_FIFO_SIZE - npcm_i2c_fifo_usage(bus);

Dup, move into loop.

> +	while (max_bytes-- && size_free_fifo) {
> +		if (bus->slv_wr_size > 0) {
> +			bus->slv_wr_ind = bus->slv_wr_ind % I2C_HW_FIFO_SIZE;
> +			npcm_i2c_wr_byte(bus, bus->slv_wr_buf[bus->slv_wr_ind]);
> +			bus->slv_wr_ind++;
> +			bus->slv_wr_ind = bus->slv_wr_ind % I2C_HW_FIFO_SIZE;
> +			bus->slv_wr_size--;
> +			size_free_fifo = I2C_HW_FIFO_SIZE -
> +					 npcm_i2c_fifo_usage(bus);
> +		} else {
> +			break;
> +		}
> +	}

	while (...) {
		if (...)
			break;
		...
	}

> +}

...

> +static int npcm_i2c_slave_get_wr_buf(struct npcm_i2c *bus)
> +{
> +	int i;

> +	u8 value = 0;

Redundant assignment.

> +	int ind;
> +	int ret = bus->slv_wr_ind;
> +
> +	/* fill a cyclic buffer */
> +	for (i = 0; i < I2C_HW_FIFO_SIZE; i++) {
> +		if (bus->slv_wr_size >= I2C_HW_FIFO_SIZE)
> +			break;
> +		i2c_slave_event(bus->slave, I2C_SLAVE_READ_REQUESTED, &value);
> +		ind = (bus->slv_wr_ind + bus->slv_wr_size) % I2C_HW_FIFO_SIZE;
> +		bus->slv_wr_buf[ind] = value;
> +		bus->slv_wr_size++;
> +		i2c_slave_event(bus->slave, I2C_SLAVE_READ_PROCESSED, &value);
> +	}
> +	return I2C_HW_FIFO_SIZE - ret;
> +}

-- 
With Best Regards,
Andy Shevchenko



_______________________________________________
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 v12 2/3] i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver
From: Wolfram Sang @ 2020-05-21 14:31 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: devicetree, linux-kernel, tmaimon77, yuenn, avifishman70, venture,
	openbmc, brendanhiggins, ofery, Tali Perry, kfting, robh+dt,
	linux-i2c, linux-arm-kernel, benjaminfair
In-Reply-To: <20200521142340.GM1634618@smile.fi.intel.com>


[-- Attachment #1.1: Type: text/plain, Size: 1136 bytes --]

Hi Tali, Andy!

On Thu, May 21, 2020 at 05:23:40PM +0300, Andy Shevchenko wrote:
> On Thu, May 21, 2020 at 02:09:09PM +0300, Tali Perry wrote:
> > Add Nuvoton NPCM BMC I2C controller driver.
> 
> Thanks. My comments below.
> After addressing them, FWIW,
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Thanks, Andy, for all the review!

From a glimpse, this looks good to go. I will have a close look later
today.

> > +#ifdef CONFIG_DEBUG_FS
> 
> Again, why is this here?
> 
> Have you checked debugfs.h for !CONFIG_DEBUG_FS case?

I wondered also about DEBUG_FS entries. I can see their value when
developing the driver. But since this is done now, do they really help a
user to debug a difficult case? I am not sure, and then I wonder if we
should have that code in upstream. I am open for discussion, though.

> > +MODULE_VERSION("0.1.3");
> 
> Module version is defined by kernel commit hash. But it's up to you and
> subsystem maintainer to decide.

Please drop it. I also think commit id's (or even kernel versions) are a
more precise description.

Regards,

   Wolfram


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
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 v12 2/3] i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver
From: Andy Shevchenko @ 2020-05-21 14:23 UTC (permalink / raw)
  To: Tali Perry
  Cc: devicetree, tmaimon77, yuenn, avifishman70, venture, openbmc, wsa,
	brendanhiggins, ofery, linux-kernel, kfting, robh+dt, linux-i2c,
	linux-arm-kernel, benjaminfair
In-Reply-To: <20200521110910.45518-3-tali.perry1@gmail.com>

On Thu, May 21, 2020 at 02:09:09PM +0300, Tali Perry wrote:
> Add Nuvoton NPCM BMC I2C controller driver.

Thanks. My comments below.
After addressing them, FWIW,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

...

> +	/* Frequency larger than 1 MHZ is not supported */

1 MHZ -> 1MHz

...

> +#ifdef CONFIG_DEBUG_FS

Again, why is this here?

Have you checked debugfs.h for !CONFIG_DEBUG_FS case?

> +/* i2c debugfs directory: used to keep health monitor of i2c devices */
> +static struct dentry *npcm_i2c_debugfs_dir;
> +
> +static void i2c_init_debugfs(struct platform_device *pdev, struct npcm_i2c *bus)
> +{
> +	struct dentry *d;
> +
> +	if (!npcm_i2c_debugfs_dir)
> +		return;
> +
> +	d = debugfs_create_dir(dev_name(&pdev->dev), npcm_i2c_debugfs_dir);
> +	if (IS_ERR_OR_NULL(d))
> +		return;
> +
> +	debugfs_create_u64("ber_cnt", 0444, d, &bus->ber_cnt);
> +	debugfs_create_u64("nack_cnt", 0444, d, &bus->nack_cnt);
> +	debugfs_create_u64("rec_succ_cnt", 0444, d, &bus->rec_succ_cnt);
> +	debugfs_create_u64("rec_fail_cnt", 0444, d, &bus->rec_fail_cnt);
> +	debugfs_create_u64("timeout_cnt", 0444, d, &bus->timeout_cnt);
> +
> +	bus->debugfs = d;
> +}

> +#else
> +static void i2c_init_debugfs(struct platform_device *pdev, struct npcm_i2c *bus)
> +{
> +}

This is completely redundant.

> +#endif

...

> +#ifdef CONFIG_DEBUG_FS

Ditto.

> +static int __init npcm_i2c_init(void)
> +{
> +	struct dentry *dir;
> +
> +	dir = debugfs_create_dir("i2c", NULL);
> +	if (IS_ERR_OR_NULL(dir))
> +		return 0;
> +
> +	npcm_i2c_debugfs_dir = dir;
> +	return 0;
> +}
> +
> +static void __exit npcm_i2c_exit(void)
> +{
> +	debugfs_remove_recursive(npcm_i2c_debugfs_dir);
> +}
> +
> +module_init(npcm_i2c_init);
> +module_exit(npcm_i2c_exit);
> +#endif

...

> +MODULE_VERSION("0.1.3");

Module version is defined by kernel commit hash. But it's up to you and
subsystem maintainer to decide.

-- 
With Best Regards,
Andy Shevchenko



_______________________________________________
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 v7 13/24] iommu/arm-smmu-v3: Enable broadcast TLB maintenance
From: Will Deacon @ 2020-05-21 14:17 UTC (permalink / raw)
  To: Jean-Philippe Brucker
  Cc: devicetree, kevin.tian, jacob.jun.pan, maz, jgg, linux-pci, joro,
	Jonathan.Cameron, fenghua.yu, hch, linux-mm, iommu, zhangfei.gao,
	catalin.marinas, felix.kuehling, xuzaibo, robin.murphy,
	christian.koenig, linux-arm-kernel, baolu.lu
In-Reply-To: <20200519175502.2504091-14-jean-philippe@linaro.org>

[+Marc]

On Tue, May 19, 2020 at 07:54:51PM +0200, Jean-Philippe Brucker wrote:
> The SMMUv3 can handle invalidation targeted at TLB entries with shared
> ASIDs. If the implementation supports broadcast TLB maintenance, enable it
> and keep track of it in a feature bit. The SMMU will then be affected by
> inner-shareable TLB invalidations from other agents.
> 
> A major side-effect of this change is that stage-2 translation contexts
> are now affected by all invalidations by VMID. VMIDs are all shared and
> the only ways to prevent over-invalidation, since the stage-2 page tables
> are not shared between CPU and SMMU, are to either disable BTM or allocate
> different VMIDs. This patch does not address the problem.

This sounds like a potential performance issue, particularly as we expose
stage-2 contexts via VFIO directly. Maybe we could reserve some portion of
VMID space for the SMMU? Marc, what do you reckon?

Will

_______________________________________________
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 v2] drm/exynos: Remove dev_err() on platform_get_irq() failure
From: M Tamseel Shams @ 2020-05-21 14:17 UTC (permalink / raw)
  To: 'Inki Dae', jy0922.shim, sw0312.kim, kyungmin.park,
	airlied, daniel
  Cc: linux-samsung-soc, shaik.ameer, linux-kernel, krzk, dri-devel,
	alim.akhtar, linux-arm-kernel
In-Reply-To: <fa372f07-abba-a296-c315-e9769fb43623@samsung.com>



> -----Original Message-----
> From: Inki Dae <inki.dae@samsung.com>
> Sent: Wednesday, May 20, 2020 11:08 AM
> To: Tamseel Shams <m.shams@samsung.com>; jy0922.shim@samsung.com;
> sw0312.kim@samsung.com; kyungmin.park@samsung.com; airlied@linux.ie;
> daniel@ffwll.ch
> Cc: dri-devel@lists.freedesktop.org; linux-arm-kernel@lists.infradead.org; linux-
> samsung-soc@vger.kernel.org; linux-kernel@vger.kernel.org;
> shaik.ameer@samsung.com; krzk@kernel.org; alim.akhtar@samsung.com
> Subject: Re: [PATCH v2] drm/exynos: Remove dev_err() on platform_get_irq()
> failure
> 
> Hi Tamseel,
> 
> Same patch[1] has been merged. So could you re-post this patch after rebasing
> it on top of exynos-drm-next branch?
> After rebase, only g2d part would be valid.
> 

Hi Inki Dae,
Thanks for letting me know, I will send updated patch for G2D file.

Thanks & Regards
Tamseel Shams



_______________________________________________
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 V1 RESEND 1/3] perf/imx_ddr: Add system PMU identifier for userspace
From: John Garry @ 2020-05-21 14:16 UTC (permalink / raw)
  To: Mark Rutland, Will Deacon
  Cc: Rob Herring, devicetree, Joakim Zhang, linux-kernel, linux-imx,
	shawnguo, linux-arm-kernel
In-Reply-To: <20200521132641.GB47848@C02TD0UTHF1T.local>

On 21/05/2020 14:26, Mark Rutland wrote:
> On Wed, May 20, 2020 at 08:33:04AM +0100, Will Deacon wrote:
>> On Tue, May 19, 2020 at 12:51:25PM -0600, Rob Herring wrote:
>>> On Tue, May 12, 2020 at 03:31:13PM +0800, Joakim Zhang wrote:
>>>> +static ssize_t ddr_perf_identifier_show(struct device *dev,
>>>> +					struct device_attribute *attr,
>>>> +					char *page)
>>>> +{
>>>> +	struct ddr_pmu *pmu = dev_get_drvdata(dev);
>>>> +
>>>> +	return sprintf(page, "%s\n", pmu->devtype_data->identifier);
>>>
>>> Why do we need yet another way to identify the SoC from userspace?
>>
>> I also really dislike this. What's the preferred way to identify the SoC
>> from userspace? It's needed so that the perf userspace tool can describe
>> perf events that are supported for the PMU, as this isn't probe-able
>> directly from the hardware. We have the same issue with the SMMUv3 PMCG [1],
>> and so we need to solve the problem for both DT and ACPI.
> 
> Worth noting that while in this case it happens to identify the SoC,
> in general you can have distinct instances of system IP in a single
> system, so I do think that we need *something* instance-specific, even
> if that's combined with SoC info.
> 

Hi Mark,

> Where IP gets reused across SoCs, it makes sense for that to not depend
> on top-level SoC info.

This would be quite an uncommon case. Generally most instances of a 
given PMU in a SoC would be identical implementations.

And anyway, we should be able to solve that problem in perf tool, as 
long as the PMU device name is fixed. Like what we have for the SMMUv3 
PMU, where the device name contains the device bus address, i.e don't 
use idr for perf drivers device naming....

Thanks,
John

_______________________________________________
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 v7 00/24] iommu: Shared Virtual Addressing for SMMUv3
From: Will Deacon @ 2020-05-21 14:17 UTC (permalink / raw)
  To: Jean-Philippe Brucker
  Cc: devicetree, kevin.tian, jacob.jun.pan, catalin.marinas,
	fenghua.yu, linux-pci, joro, christian.koenig, hch, jgg, iommu,
	xuzaibo, Jonathan.Cameron, zhangfei.gao, felix.kuehling,
	robin.murphy, linux-mm, linux-arm-kernel, baolu.lu
In-Reply-To: <20200521103513.GE5360@willie-the-truck>

On Thu, May 21, 2020 at 11:35:14AM +0100, Will Deacon wrote:
> On Tue, May 19, 2020 at 07:54:38PM +0200, Jean-Philippe Brucker wrote:
> > Shared Virtual Addressing (SVA) allows to share process page tables with
> > devices using the IOMMU, PASIDs and I/O page faults. Add SVA support to
> > the Arm SMMUv3 driver.
> > 
> > Since v6 [1]:
> > * Rename ioasid_free() to ioasid_put() in patch 02, requiring changes to
> >   the Intel drivers.
> > * Use mmu_notifier_register() in patch 16 to avoid copying the ops and
> >   simplify the invalidate() notifier in patch 17.
> > * As a result, replace context spinlock with a mutex. Simplified locking in
> >   patch 11 (That patch still looks awful, but I think the series is more
> >   readable overall). And I've finally been able to remove the GFP_ATOMIC
> >   allocations.
> > * Use a single patch (04) for io-pgfault.c, since the code was simplified
> >   in v6. Fixed partial list in patch 04.
> 
> There's an awful lot here and it stretches across quite a few subsystems,
> with different git trees. What's the plan for merging it?
> 
> I'm happy to take some of the arm64 and smmu changes for 5.8, then perhaps
> we can review what's left and target 5.9? It would also be helpful to split
> that up into separate series where there aren't strong dependencies, I
> think.

Hmm, so the way the series is structured makes it quite difficult to apply
much of this at all :(

I've taken patch 5 into the arm64 tree and patch 8 into the smmu tree. I'll
leave a couple of Acks on some of the simpler patches, but I think this
really needs splitting up a bit to make it more manageable.

I also notice a bunch of TODOs that get introduced and then removed. Given
that the series needs to be bisectable, these shouldn't be needed and can
just be removed.

Thanks,

Will

_______________________________________________
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 v7 14/24] iommu/arm-smmu-v3: Add SVA feature checking
From: Will Deacon @ 2020-05-21 14:17 UTC (permalink / raw)
  To: Jean-Philippe Brucker
  Cc: devicetree, kevin.tian, jacob.jun.pan, jgg, linux-pci, joro,
	Jonathan.Cameron, Suzuki K Poulose, fenghua.yu, hch, linux-mm,
	iommu, zhangfei.gao, catalin.marinas, felix.kuehling, xuzaibo,
	robin.murphy, christian.koenig, linux-arm-kernel, baolu.lu
In-Reply-To: <20200519175502.2504091-15-jean-philippe@linaro.org>

On Tue, May 19, 2020 at 07:54:52PM +0200, Jean-Philippe Brucker wrote:
> Aggregate all sanity-checks for sharing CPU page tables with the SMMU
> under a single ARM_SMMU_FEAT_SVA bit. For PCIe SVA, users also need to
> check FEAT_ATS and FEAT_PRI. For platform SVA, they will most likely have
> to check FEAT_STALLS.
> 
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> ---
>  drivers/iommu/arm-smmu-v3.c | 72 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 72 insertions(+)
> 
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index 9332253e3608..a9f6f1d7014e 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -660,6 +660,7 @@ struct arm_smmu_device {
>  #define ARM_SMMU_FEAT_RANGE_INV		(1 << 15)
>  #define ARM_SMMU_FEAT_E2H		(1 << 16)
>  #define ARM_SMMU_FEAT_BTM		(1 << 17)
> +#define ARM_SMMU_FEAT_SVA		(1 << 18)
>  	u32				features;
>  
>  #define ARM_SMMU_OPT_SKIP_PREFETCH	(1 << 0)
> @@ -3935,6 +3936,74 @@ static int arm_smmu_device_reset(struct arm_smmu_device *smmu, bool bypass)
>  	return 0;
>  }
>  
> +static bool arm_smmu_supports_sva(struct arm_smmu_device *smmu)
> +{
> +	unsigned long reg, fld;
> +	unsigned long oas;
> +	unsigned long asid_bits;
> +
> +	u32 feat_mask = ARM_SMMU_FEAT_BTM | ARM_SMMU_FEAT_COHERENCY;

Aha -- here's the coherency check I missed!

> +
> +	if ((smmu->features & feat_mask) != feat_mask)
> +		return false;
> +
> +	if (!(smmu->pgsize_bitmap & PAGE_SIZE))
> +		return false;
> +
> +	/*
> +	 * Get the smallest PA size of all CPUs (sanitized by cpufeature). We're
> +	 * not even pretending to support AArch32 here.
> +	 */
> +	reg = read_sanitised_ftr_reg(SYS_ID_AA64MMFR0_EL1);
> +	fld = cpuid_feature_extract_unsigned_field(reg, ID_AA64MMFR0_PARANGE_SHIFT);
> +	switch (fld) {
> +	case 0x0:
> +		oas = 32;
> +		break;
> +	case 0x1:
> +		oas = 36;
> +		break;
> +	case 0x2:
> +		oas = 40;
> +		break;
> +	case 0x3:
> +		oas = 42;
> +		break;
> +	case 0x4:
> +		oas = 44;
> +		break;
> +	case 0x5:
> +		oas = 48;
> +		break;
> +	case 0x6:

We can use ID_AA64MMFR0_PARANGE_xx constants instead of the hardcoded hex
numbers here.

With that:

Acked-by: Will Deacon <will@kernel.org>

Will

_______________________________________________
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 v7 12/24] iommu/arm-smmu-v3: Add support for VHE
From: Will Deacon @ 2020-05-21 14:16 UTC (permalink / raw)
  To: Jean-Philippe Brucker
  Cc: devicetree, kevin.tian, jacob.jun.pan, jgg, linux-pci, joro,
	Jonathan.Cameron, fenghua.yu, hch, linux-mm, iommu, zhangfei.gao,
	catalin.marinas, felix.kuehling, xuzaibo, robin.murphy,
	christian.koenig, linux-arm-kernel, baolu.lu
In-Reply-To: <20200519175502.2504091-13-jean-philippe@linaro.org>

On Tue, May 19, 2020 at 07:54:50PM +0200, Jean-Philippe Brucker wrote:
> ARMv8.1 extensions added Virtualization Host Extensions (VHE), which allow
> to run a host kernel at EL2. When using normal DMA, Device and CPU address
> spaces are dissociated, and do not need to implement the same
> capabilities, so VHE hasn't been used in the SMMU until now.
> 
> With shared address spaces however, ASIDs are shared between MMU and SMMU,
> and broadcast TLB invalidations issued by a CPU are taken into account by
> the SMMU. TLB entries on both sides need to have identical exception level
> in order to be cleared with a single invalidation.
> 
> When the CPU is using VHE, enable VHE in the SMMU for all STEs. Normal DMA
> mappings will need to use TLBI_EL2 commands instead of TLBI_NH, but
> shouldn't be otherwise affected by this change.
> 
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> ---
>  drivers/iommu/arm-smmu-v3.c | 31 ++++++++++++++++++++++++++-----
>  1 file changed, 26 insertions(+), 5 deletions(-)

Acked-by: Will Deacon <will@kernel.org>

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox