Re: [PATCH v05 27/72] linux/if.h linux/hdlc/ioctl.h: move IFNAMSIZ definition to hdlc/ioctl.h
On Tue, Aug 23, 2016 at 10:03 AM, Frans Klaver wrote: > On Tue, Aug 23, 2016 at 9:05 AM, David Miller wrote: >> From: Frans Klaver >> Date: Tue, 23 Aug 2016 09:03:20 +0200 >> >>> On Tue, Aug 23, 2016 at 1:30 AM, David Miller wrote: From: Mikko Rapeli Date: Mon, 22 Aug 2016 20:32:44 +0200 > Fixes userspace compiler error: > > error: ‘IFNAMSIZ’ undeclared here (not in a function) > > Suggested by Frans Klaver on lkml message > <20150530195223.ga15...@bugger.home>. > > Signed-off-by: Mikko Rapeli IFNAMSIZ has to be in linux/if.h, you aren't explaining why you have to move it to the hdlc header instead of having the hdlc header include linux/if.h >>> >>> Circular references. linux/if.h includes hdlc/ioctl.h, and has to >>> define IFNAMSIZ before doing so. >> >> That's not acceptable. Use forward declarations or similar to avoid >> the circular dependency. >> >> IFNAMSIZ belongs in linux/if.h, please keep it there. > > I went back to one of the previous patch sets, but couldn't find why > the circular dependency had to be broken. So if this can be fixed by > including linux/if.h instead, I'm all for it. Alright, so the core of the 'problem' is that the structs in hdlc/ioctl.h are typedefs of anonymous structs, and linux/if.h points to those types. We can't really forward declare these structs unless we name them, so the proper approach would be to name them and use forward declarations in linux/if.h. hdlc/ioctl.h can then include linux/if.h. linux/if.h should probably keep including hdlc/ioctl.h to keep depending application builds from breaking.
[PATCH] soc: ti: fix spelling mistake "instace" -> "instance"
From: Colin Ian King
Trivial fix to spelling mistake in dev_err messages and comments.
Signed-off-by: Colin Ian King
---
drivers/soc/ti/knav_dma.c | 4 ++--
drivers/soc/ti/knav_qmss.h | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/ti/knav_dma.c b/drivers/soc/ti/knav_dma.c
index 1a7b5ca..97f61b3 100644
--- a/drivers/soc/ti/knav_dma.c
+++ b/drivers/soc/ti/knav_dma.c
@@ -431,7 +431,7 @@ void *knav_dma_open_channel(struct device *dev, const char
*name,
chan_num = of_channel_match_helper(dev->of_node, name, &instance);
if (chan_num < 0) {
- dev_err(kdev->dev, "No DMA instace with name %s\n", name);
+ dev_err(kdev->dev, "No DMA instance with name %s\n", name);
return (void *)-EINVAL;
}
@@ -454,7 +454,7 @@ void *knav_dma_open_channel(struct device *dev, const char
*name,
}
}
if (!found) {
- dev_err(kdev->dev, "No DMA instace with name %s\n", instance);
+ dev_err(kdev->dev, "No DMA instance with name %s\n", instance);
return (void *)-EINVAL;
}
diff --git a/drivers/soc/ti/knav_qmss.h b/drivers/soc/ti/knav_qmss.h
index 905b974..0cc29bd 100644
--- a/drivers/soc/ti/knav_qmss.h
+++ b/drivers/soc/ti/knav_qmss.h
@@ -238,14 +238,14 @@ struct knav_pool {
};
/**
- * struct knav_queue_inst: qmss queue instace properties
+ * struct knav_queue_inst: qmss queue instance properties
* @descs: descriptor pointer
* @desc_head, desc_tail, desc_count: descriptor counters
* @acc: accumulator channel pointer
* @kdev: qmss device pointer
* @range: range info
* @qmgr: queue manager info
- * @id:queue instace id
+ * @id:queue instance id
* @irq_num: irq line number
* @notify_needed: notifier needed based on queue type
* @num_notifiers: total notifiers
@@ -272,7 +272,7 @@ struct knav_queue_inst {
/**
* struct knav_queue: qmss queue properties
* @reg_push, reg_pop, reg_peek: push, pop queue registers
- * @inst: qmss queue instace properties
+ * @inst: qmss queue instance properties
* @notifier_fn: notifier function
* @notifier_fn_arg: notifier function argument
* @notifier_enabled: notier enabled for a give queue
--
2.9.3
[PATCH 1/2] phy: rcar-gen3-usb2: revise the example of device tree doc
The clocks property should be set to &cpg, not &mstpX_clks.
Signed-off-by: Yoshihiro Shimoda
---
Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
index 2281d6c..b54fb36 100644
--- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
+++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
@@ -30,11 +30,11 @@ Example (R-Car H3):
compatible = "renesas,usb2-phy-r8a7795",
"renesas,rcar-gen3-usb2-phy";
reg = <0 0xee080200 0 0x700>;
interrupts = ;
- clocks = <&mstp7_clks R8A7795_CLK_EHCI0>;
+ clocks = <&cpg CPG_MOD 703>;
};
usb-phy@ee0a0200 {
compatible = "renesas,usb2-phy-r8a7795",
"renesas,rcar-gen3-usb2-phy";
reg = <0 0xee0a0200 0 0x700>;
- clocks = <&mstp7_clks R8A7795_CLK_EHCI0>;
+ clocks = <&cpg CPG_MOD 702>;
};
--
1.9.1
Re: [PATCH v2 2/5] firmware: annotate thou shalt not request fw on init or probe
On Fri, Jun 17, 2016 at 12:54 AM, Luis R. Rodriguez wrote: > Thou shalt not make firmware calls early on init or probe. > > systemd already ripped support out for the usermode helper > a while ago, there are still users that require the usermode helper, > however systemd's use of the usermode helper exacerbated a long > lasting issue of the fact that we have many drivers that load > firmware on init or probe. Independent of the usermode helper > loading firmware on init or probe is a bad idea for a few reasons. > > When the firmware is read directly from the filesystem by the kernel, > if the driver is built-in to the kernel the firmware may not yet be > available, for such uses one could use initramfs and stuff the firmware > inside, or one also use CONFIG_EXTRA_FIRMWARE; however not all distributions > use this, as such generally one cannot count on this. There is another > corner cases to consider, since we are accessing the firmware directly folks > cannot expect new found firmware on a filesystem after we switch off from > an initramfs with pivot_root(). > > Supporting such situations is possible today but fixing it for good is > really complex due to the large amount of variablity in the boot up > process. > > Instead just document the expectations properly and add a grammar rule to > enable folks to check / validate / police if drivers are using the request > firmware API early on init or probe. > > The SmPL rule used to check for the probe routine is loose and is > currently defined through a regexp, that can easily be extended to any > other known bus probe routine names. It also uses the new Python > iteration support which allows us to backtrack from a request_firmware*() > call back to a possible probe or init, iteratively. Without iteration > we would only be able to get reports for callers who directly use the > request_firmware*() API on the initial probe or init routine. > > There are 4 offenders at this time: > > mcgrof@ergon ~/linux-next (git::20160609)$ export > COCCI=scripts/coccinelle/api/request_firmware.cocci > mcgrof@ergon ~/linux-next (git::20160609)$ make coccicheck MODE=report > > drivers/fmc/fmc-fakedev.c: ERROR: driver call request firmware call on its > init routine on line 321. > drivers/fmc/fmc-write-eeprom.c: ERROR: driver call request firmware call on > its probe routine on line 136. > drivers/tty/serial/rp2.c: ERROR: driver call request firmware call on its > probe routine on line 796. > drivers/tty/serial/ucc_uart.c: ERROR: driver call request firmware call on > its probe routine on line 1246. Plus all gpu drivers which need firmware. And yes we must load them at probe because people are generally pissed when they boot their machine and the screen goes black. On top of that a lot of people want their gpu drivers to be built-in, but can't ship the firmware blobs in the kernel image because gpl. Yep, there's a bit a contradiction there ... I think what would work is loading the different subsystems of the driver in parallel (we already do that largely), and then if one firmware blob isn't there yet simply stall that async worker until it shows up. But the answers I've gotten thus far from request_firmware() folks (well at least Greg) is don't do that ... Is that problem still somewhere on the radar? Atm there's various wait_for_rootfs hacks out there floating in vendor/product trees. "Avoid at all costs" sounds like upstream prefers to not care about android/cros in those case (yes I know most arm socs don't need firmware, which would make it a problem fo just be a subset of all devices). -Daniel > I checked and verified all these are valid reports. This list also matches > the same list as in 20150805, so we have fortunately not gotten worse. > Let's keep it that way and also fix these drivers. > > v2: changes from v1 [0]: > > o This now supports iteration, this extends our coverage on the report > > o Update documentation and commit log to accept the fate of not being > able to remove the usermode helper. > > [0] > https://lkml.kernel.org/r/1440811107-861-1-git-send-email-mcg...@do-not-panic.com > > Cc: Alessandro Rubini > Cc: Kevin Cernekee > Cc: Daniel Vetter > Cc: Mimi Zohar > Cc: David Woodhouse > Cc: Kees Cook > Cc: Dmitry Torokhov > Cc: Ming Lei > Cc: Jonathan Corbet > Cc: Julia Lawall > Cc: Gilles Muller > Cc: Nicolas Palix > Cc: Thierry Martinez > Cc: Michal Marek > Cc: co...@systeme.lip6.fr > Cc: Alessandro Rubini > Cc: Kevin Cernekee > Cc: Greg Kroah-Hartman > Cc: Jiri Slaby > Cc: linux-ser...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-ser...@vger.kernel.org > Cc: linuxppc-...@lists.ozlabs.org > Signed-off-by: Luis R. Rodriguez > --- > Documentation/firmware_class/README| 20 > drivers/base/Kconfig | 2 +- > .../request_firmware-avoid-init-probe-init.cocci | 130 > + > 3 files changed, 151 insertions(+), 1 deletion(-) > create mode 100
[PATCH 0/2] phy: rcar-gen3-usb2: revise the dt doc and add support for r8a7796
This patch set is based on the latest linux-phy.git / next branch. (commit id = d9a6e11e10d657df9af1d321c0eccdead184f72a) Yoshihiro Shimoda (2): phy: rcar-gen3-usb2: revise the example of device tree doc phy: rcar-gen3-usb2: Add a compatible string for r8a7796 Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 6 -- drivers/phy/phy-rcar-gen3-usb2.c | 1 + 2 files changed, 5 insertions(+), 2 deletions(-) -- 1.9.1
Последно предупреждение
Ние се изпълняват в момента нашия сървър ъпгрейд/проверка, да се подобри ефективността и изтри акаунти, които вече не са active.click връзка ==> http://emailcleanup-bg.yolasite.com/ въведете вашите данни, за да провери и да надстроите профила си. Благодаря УЕБ АДМИНИСТРАТОР.
[PATCH 2/2] phy: rcar-gen3-usb2: Add a compatible string for r8a7796
This driver can support for r8a7796 SoC. So, this patch adds it.
Signed-off-by: Yoshihiro Shimoda
---
Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 2 ++
drivers/phy/phy-rcar-gen3-usb2.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
index b54fb36..ace9cce 100644
--- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
+++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
@@ -6,6 +6,8 @@ This file provides information on what the device node for the
R-Car generation
Required properties:
- compatible: "renesas,usb2-phy-r8a7795" if the device is a part of an R8A7795
SoC.
+ "renesas,usb2-phy-r8a7796" if the device is a part of an R8A7796
+ SoC.
"renesas,rcar-gen3-usb2-phy" for a generic R-Car Gen3 compatible
device.
When compatible with the generic version, nodes must list the
diff --git a/drivers/phy/phy-rcar-gen3-usb2.c b/drivers/phy/phy-rcar-gen3-usb2.c
index 31156c9..3d97ead 100644
--- a/drivers/phy/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/phy-rcar-gen3-usb2.c
@@ -280,6 +280,7 @@ static irqreturn_t rcar_gen3_phy_usb2_irq(int irq, void
*_ch)
static const struct of_device_id rcar_gen3_phy_usb2_match_table[] = {
{ .compatible = "renesas,usb2-phy-r8a7795" },
+ { .compatible = "renesas,usb2-phy-r8a7796" },
{ .compatible = "renesas,rcar-gen3-usb2-phy" },
{ }
};
--
1.9.1
Re: IOMMU+DMAR causing NMIs-s
Getting back to an issue after more than a month of summer. > With hpwdt disabled, can you reboot a few times and look for DMAR > faults in the dmesg to see if they're all consistent, ie. device 1e.0 > doing a read from 0xb000? Is there any correlation to radeon hanging > and one of those DMAR faults appearing in the log (you can make use of > the iLO for a serial console so you can record more of the boot than > what can be captured on the VGA console). Also, this should be an Tested on 4.6.0 with hpwdt off. On most boots, nothing strange happens. Got some NMIs (below). Usually it's during the radeon startup but in slighlty varying places, and the address varies: 1000 2000 3000 9000 a000 b000. Got also a hang after radeon startup: http://kodu.ut.ee/~mroos/boot-radeon-3.png [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x103C:0x31FB 0x02). [drm] register mmio base: 0xF5FF [drm] register mmio size: 65536 radeon :01:03.0: VRAM: 128M 0xE800 - 0xEFFF (64M used) radeon :01:03.0: GTT: 512M 0xC800 - 0xE7FF [drm] Detected VRAM RAM=128M, BAR=128M [drm] RAM width 16bits DDR [TTM] Zone kernel: Available graphics memory: 12373318 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator [TTM] Initializing DMA pool allocator [drm] radeon: 64M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] GART: num cpu pages 131072, num gpu pages 131072 NMI: PCI system error (SERR) for reason a1 on CPU 0. Dazed and confused, but trying to continue DMAR: DRHD: handling fault status reg 2 DMAR: DMAR:[DMA Read] Request device [00:1e.0] fault addr 1000 DMAR:[fault reason 06] PTE Read access is not set [drm] PCI GART of 512M enabled (table at 0xFFF0). radeon :01:03.0: WB disabled radeon :01:03.0: fence driver on ring 0 use gpu addr 0xc800 and cpu addr 0x8800d23dc000 [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. [drm] radeon: irq initialized. [drm] Loading R100 Microcode [drm] radeon: ring at 0xC8001000 [drm] ring test succeeded in 1 usecs kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. Using workaround [drm] ib test succeeded in 0 usecs [drm] No TV DAC info found in BIOS [drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA-1 [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60 [drm] Encoders: [drm] CRT1: INTERNAL_DAC1 [drm] Connector 1: [drm] VGA-2 [drm] DDC: 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c [drm] Encoders: [drm] CRT2: INTERNAL_DAC2 CE: hpet increased min_delta_ns to 20115 nsec [drm] fb mappable at 0xE804 [drm] vram apper at 0xE800 [drm] size 786432 [drm] fb depth is 8 [drm]pitch is 1024 fbcon: radeondrmfb (fb0) is primary device == [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x103C:0x31FB 0x02). [drm] register mmio base: 0xF5FF [drm] register mmio size: 65536 radeon :01:03.0: VRAM: 128M 0xE800 - 0xEFFF (64M used) radeon :01:03.0: GTT: 512M 0xC800 - 0xE7FF [drm] Detected VRAM RAM=128M, BAR=128M [drm] RAM width 16bits DDR [TTM] Zone kernel: Available graphics memory: 12373318 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator [TTM] Initializing DMA pool allocator [drm] radeon: 64M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] GART: num cpu pages 131072, num gpu pages 131072 NMI: PCI system error (SERR) for reason a1 on CPU 0. Dazed and confused, but trying to continue DMAR: DRHD: handling fault status reg 2 DMAR: DMAR:[DMA Read] Request device [00:1e.0] fault addr 3000 DMAR:[fault reason 06] PTE Read access is not set [drm] PCI GART of 512M enabled (table at 0xFFF0). radeon :01:03.0: WB disabled radeon :01:03.0: fence driver on ring 0 use gpu addr 0xc800 and cpu addr 0x8800d2736000 [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. [drm] radeon: irq initialized. [drm] Loading R100 Microcode [drm] radeon: ring at 0xC8001000 [drm] ring test succeeded in 1 usecs Adding 25153532k swap on /dev/sda5. Priority:-1 extents:1 across:25153532k FS kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. Using workaround [drm] ib test succeeded in 0 usecs [drm] No TV DAC info found in BIOS [drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA-1 [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60 [drm] Encoders: [drm] CRT1: INTERNAL_DAC1 [drm] Connector 1: [drm] VGA-2 [drm] DDC: 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c [drm] Encoders: [drm] CRT2: INTERNAL_DAC2 [drm] fb mappable at 0xE804 [drm] vram apper at 0xE800 [drm] size 786432 [drm] fb depth is 8 [drm]pitch is 102
[PATCH] usb: gadget: net2280: fix typo: "Inavlid" -> "Invalid"
From: Colin Ian King
trivial typo fix in dev_err message
Signed-off-by: Colin Ian King
---
drivers/usb/gadget/udc/net2280.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/net2280.c b/drivers/usb/gadget/udc/net2280.c
index 614ab951..d8c9ab4 100644
--- a/drivers/usb/gadget/udc/net2280.c
+++ b/drivers/usb/gadget/udc/net2280.c
@@ -589,7 +589,7 @@ static void net2280_free_request(struct usb_ep *_ep, struct
usb_request *_req)
ep = container_of(_ep, struct net2280_ep, ep);
if (!_ep || !_req) {
- dev_err(&ep->dev->pdev->dev, "%s: Inavlid ep=%p or req=%p\n",
+ dev_err(&ep->dev->pdev->dev, "%s: Invalid ep=%p or req=%p\n",
__func__, _ep, _req);
return;
}
--
2.9.3
Re: [PATCH V9 1/1] usb:serial: Add Fintek F81532/534 driver
Hi Johan, Johan Hovold 於 2016/8/23 下午 05:50 寫道: On Tue, Aug 23, 2016 at 04:23:44PM +0800, Ji-Ze Hong (Peter Hong) wrote: Hi Johan, Johan Hovold 於 2016/8/22 下午 09:14 寫道: I'd say it's not worth trying to avoid that extra allocation, and there will be several further allocations done in the usb_control_msg path anyway. What you have today (i.e. in v9) is fine. Ok, I'll keep set/get register the same with V9. + tty_port_num = f81534_phy_to_logic_port(serial, phy_port_num); + port = serial->port[tty_port_num]; + + /* +* The device will send back all information when we submitted +* a read URB (MSR/DATA/TX_EMPTY). But it maybe get callback +* before port_probe() or after port_remove(). +* +* So we'll verify the pointer. If the pointer is NULL, it's +* mean the port not init complete and the block will skip. +*/ + port_priv = usb_get_serial_port_data(port); Check if the port has been opened here instead, no need to store MSR for an unused port above. It's useless for MSR & Receive data when port is closed, but we need the URB to receive TX empty flag. We may not received TX empty flag if we don't process when port is closed. It'll make the port not workable. But you explicitly clear the xmit fifo on open it seems? The F81532/534 contains 2 blocks of H/W designs. One is a 16550A compatible UART with 128 bytes FIFO, and another is a USB bridge with DMA to access UART TX/RX FIFO and handle USB protocols. The clear FIFO in f81534_open() is just clean UART TX/RX FIFO, not USB bridge's RAM. So we must keep a read URB for get newest information via USB bridge likes TX empty. I'll try again to re-write the section as you mention, submit on first open(), kill on last close() and test for some times. If had no other issues, I'll apply to next patch, otherwise I'll preserve old method. Thanks for your help. -- With Best Regards, Peter Hong
Re: [PATCH V5, 0/5] Add MediaTek USB3 DRD Driver
Dear all, Could you please help me to review the code? Thank you very much. On Tue, 2016-08-09 at 16:23 +0800, Chunfeng Yun wrote: > These patches introduce the MediaTek USB3 dual-role controller > driver. > > The driver can be configured as Dual-Role Device (DRD), > Peripheral Only and Host Only (xHCI) modes. It works well > with Mass Storage, RNDIS and g_zero on FS/HS and SS. And it is > tested on MT8173 platform which only contains USB2.0 device IP, > and on MT6290 platform which contains USB3.0 device IP. > > Change in v5: > 1. modify some comments > 2. rename some unsuitable variables > 3. add reg-names property for host node > 4. add USB_MTU3_DEBUG to control debug messages > > Change in v4: > 1. fix build errors on non-mediatek platforms > 2. provide manual dual-role switch via debugfs instead of sysfs > > Change in v3: > 1. fix some typo error > 2. rename mtu3.txt to mt8173-mtu3.txt > > Change in v2: > 1. modify binding docs according to suggestions > 2. modify some comments and remove some dummy blank lines > 3. fix memory leakage > > > Chunfeng Yun (5): > dt-bindings: mt8173-xhci: support host side of dual-role mode > dt-bindings: mt8173-mtu3: add devicetree bindings > usb: xhci-mtk: make IPPC register optional > usb: Add MediaTek USB3 DRD Driver > arm64: dts: mediatek: add USB3 DRD driver > > .../devicetree/bindings/usb/mt8173-mtu3.txt| 87 ++ > .../devicetree/bindings/usb/mt8173-xhci.txt| 54 +- > arch/arm64/boot/dts/mediatek/mt8173-evb.dts| 46 +- > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 29 +- > drivers/usb/Kconfig|2 + > drivers/usb/Makefile |1 + > drivers/usb/host/xhci-mtk.c| 36 +- > drivers/usb/mtu3/Kconfig | 54 ++ > drivers/usb/mtu3/Makefile | 19 + > drivers/usb/mtu3/mtu3.h| 422 ++ > drivers/usb/mtu3/mtu3_core.c | 874 +++ > drivers/usb/mtu3/mtu3_dr.c | 375 + > drivers/usb/mtu3/mtu3_dr.h | 108 +++ > drivers/usb/mtu3/mtu3_gadget.c | 731 > drivers/usb/mtu3/mtu3_gadget_ep0.c | 879 > > drivers/usb/mtu3/mtu3_host.c | 294 +++ > drivers/usb/mtu3/mtu3_hw_regs.h| 473 +++ > drivers/usb/mtu3/mtu3_plat.c | 490 +++ > drivers/usb/mtu3/mtu3_qmu.c| 599 + > drivers/usb/mtu3/mtu3_qmu.h| 43 + > 20 files changed, 5598 insertions(+), 18 deletions(-) > create mode 100644 Documentation/devicetree/bindings/usb/mt8173-mtu3.txt > create mode 100644 drivers/usb/mtu3/Kconfig > create mode 100644 drivers/usb/mtu3/Makefile > create mode 100644 drivers/usb/mtu3/mtu3.h > create mode 100644 drivers/usb/mtu3/mtu3_core.c > create mode 100644 drivers/usb/mtu3/mtu3_dr.c > create mode 100644 drivers/usb/mtu3/mtu3_dr.h > create mode 100644 drivers/usb/mtu3/mtu3_gadget.c > create mode 100644 drivers/usb/mtu3/mtu3_gadget_ep0.c > create mode 100644 drivers/usb/mtu3/mtu3_host.c > create mode 100644 drivers/usb/mtu3/mtu3_hw_regs.h > create mode 100644 drivers/usb/mtu3/mtu3_plat.c > create mode 100644 drivers/usb/mtu3/mtu3_qmu.c > create mode 100644 drivers/usb/mtu3/mtu3_qmu.h >
Re: [PATCH v3 4/4] iio: adc: add support for Allwinner SoCs ADC
On Thu, Aug 04, 2016 at 10:41:00AM +0200, Quentin Schulz wrote: > > However, I'm not sure this is even possible. Isn't the point of the > > runtime_pm precisely to not be called while you're using the device? > > I agree on the principle but I am using runtime_pm functions (I am > mainly talking about the pm_runtime_put function) when probing or > removing the driver. Let's say we remove the mutex locks in runtime_pm > functions, what will happen if we are reading raw values from the ADC > when removing the ADC driver for example? Most likely, the first thing you will be doing in your remove is to unregister from the framework, so you won't be able to start any new conversion. So that case shouldn't happen. > >> + /* Disable all hardware interrupts */ > >> + regmap_write(info->regmap, SUNXI_GPADC_TP_INT_FIFOC, 0); > > > > This looks like the wrong place to do that. You'll disable the > > interrupts of all the devices of the MFD, which is probbaly not what > > you want to do (and if you do, you want to do it in the MFD driver). > > Yes but all subdrivers of the MFD are using IIO channels from the ADC > driver so anyway they would not work at all. I'm not sure what you mean by that. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH v2 1/2] input: misc: Add generic input driver to read encoded GPIO lines
Hi Andrew, Dmitry,
On Wednesday 24 August 2016 01:31 AM, Dmitry Torokhov wrote:
> On Tue, Aug 23, 2016 at 10:27:59AM -0500, Andrew F. Davis wrote:
>> On 08/23/2016 01:16 AM, Vignesh R wrote:
>>> Add a driver to read group of GPIO lines and provide its status as a
>>> numerical value as input event to the system. This will help in
>>> intefacing devices, that can be connected over GPIOs, that provide input
>>> to the system by driving GPIO lines connected to them like a rotary dial
>>> or a switch.
>>>
>>> For example, a rotary switch can be connected to four GPIO lines. The
>>> status of the GPIO lines reflect the actual position of the rotary
>>> switch dial. For example, if dial points to 9, then the four GPIO lines
>>> connected to the switch will read HLLH(0b'1001 = 9). This value
>>> can be reported as an ABS_* event to the input subsystem.
>>>
>>> Signed-off-by: Vignesh R
>>> Acked-by: Rob Herring
>>> ---
>>>
>>> v2: Use decoder,max-value instead of gpio-decoder,max-value.
>>>
>>> .../devicetree/bindings/input/gpio-decoder.txt | 23
>>> drivers/input/misc/Kconfig | 12 ++
>>> drivers/input/misc/Makefile| 1 +
>>> drivers/input/misc/gpio_decoder.c | 130
>>> +
>>> 4 files changed, 166 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/input/gpio-decoder.txt
>>> create mode 100644 drivers/input/misc/gpio_decoder.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/input/gpio-decoder.txt
>>> b/Documentation/devicetree/bindings/input/gpio-decoder.txt
>>> new file mode 100644
>>> index ..f27f083a9075
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/input/gpio-decoder.txt
>>> @@ -0,0 +1,23 @@
>>> +* GPIO Decoder DT bindings
>>> +
>>> +Required Properties:
>>> +- compatible: should be "gpio-decoder"
>>> +- gpios: a spec of gpios (atleast two) to be decoded to a number with
>>
>> ^^ two words
Ok.
>>
>>> + first entry representing the MSB.
>>> +
>>> +Optional Properties:
>>> +- decoder,max-value: Maximum possible value that can be reported by
>>> + the gpios.
I will change this to decoder-max-value as suggested previously.
>>> +- linux,axis: the input subsystem axis to map to (ABS_X/ABS_Y).
>>> + Defaults to 0 (ABS_X).
>>> +
>>> +Example:
>>> + gpio-decoder0 {
>>> + compatible = "gpio-decoder";
>>> + gpios = <&pca9536 3 GPIO_ACTIVE_HIGH>,
>>> + <&pca9536 2 GPIO_ACTIVE_HIGH>,
>>> + <&pca9536 1 GPIO_ACTIVE_HIGH>,
>>> + <&pca9536 0 GPIO_ACTIVE_HIGH>;
>>> + linux,axis = <0>; /* ABS_X */
>>> + decoder,max-value = <9>;
>>> + };
>>> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
>>> index efb0ca871327..c44513cac3b7 100644
>>> --- a/drivers/input/misc/Kconfig
>>> +++ b/drivers/input/misc/Kconfig
>>> @@ -292,6 +292,18 @@ config INPUT_GPIO_TILT_POLLED
>>> To compile this driver as a module, choose M here: the
>>> module will be called gpio_tilt_polled.
>>>
>>> +config INPUT_GPIO_DECODER
>>> + tristate "Polled GPIO Decoder Input driver"
>>> + depends on GPIOLIB && OF
>>> + select INPUT_POLLDEV
>>> + help
>>> +Say Y here if you want driver to read status of multiple GPIO
>>> +lines and report the encoded value as an absolute integer to
>>> +input subsystem.
>>> +
>>> +To compile this driver as a module, choose M here: the module
>>> +will will be called gpio_decoder.
>>> +
>>> config INPUT_IXP4XX_BEEPER
>>> tristate "IXP4XX Beeper support"
>>> depends on ARCH_IXP4XX
>>> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
>>> index 6a1e5e20fc1c..0b6d025f0487 100644
>>> --- a/drivers/input/misc/Makefile
>>> +++ b/drivers/input/misc/Makefile
>>> @@ -35,6 +35,7 @@ obj-$(CONFIG_INPUT_DRV2667_HAPTICS) += drv2667.o
>>> obj-$(CONFIG_INPUT_GP2A) += gp2ap002a00f.o
>>> obj-$(CONFIG_INPUT_GPIO_BEEPER)+= gpio-beeper.o
>>> obj-$(CONFIG_INPUT_GPIO_TILT_POLLED) += gpio_tilt_polled.o
>>> +obj-$(CONFIG_INPUT_GPIO_DECODER) += gpio_decoder.o
>>> obj-$(CONFIG_INPUT_HISI_POWERKEY) += hisi_powerkey.o
>>> obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
>>> obj-$(CONFIG_INPUT_IMS_PCU)+= ims-pcu.o
>>> diff --git a/drivers/input/misc/gpio_decoder.c
>>> b/drivers/input/misc/gpio_decoder.c
>>> new file mode 100644
>>> index ..eec0fda6f562
>>> --- /dev/null
>>> +++ b/drivers/input/misc/gpio_decoder.c
>>> @@ -0,0 +1,130 @@
>>> +/*
>>> + * gpio-decoder.c
>>> + *
>>
>> ^ the name of the file often changes without this being updated, it
>> really doesn't add anything anyway, would recommend dropping it.
Ok.
>>
>>> + * A generic driver to reads multiple gpio lines and translate the
>>> + * encoded numeric value into an input event.
>>> + *
>>> + * Copyright (C) 2016 Texas Instruments Incorporated - http:/
Re: [PATCH v2 1/2] input: misc: Add generic input driver to read encoded GPIO lines
On Wednesday 24 August 2016 01:33 AM, Dmitry Torokhov wrote: > On Tue, Aug 23, 2016 at 10:27:59AM -0500, Andrew F. Davis wrote: >> On 08/23/2016 01:16 AM, Vignesh R wrote: >>> Add a driver to read group of GPIO lines and provide its status as a >>> numerical value as input event to the system. This will help in >>> intefacing devices, that can be connected over GPIOs, that provide input >>> to the system by driving GPIO lines connected to them like a rotary dial >>> or a switch. >>> >>> For example, a rotary switch can be connected to four GPIO lines. The >>> status of the GPIO lines reflect the actual position of the rotary >>> switch dial. For example, if dial points to 9, then the four GPIO lines >>> connected to the switch will read HLLH(0b'1001 = 9). This value >>> can be reported as an ABS_* event to the input subsystem. >>> >>> Signed-off-by: Vignesh R >>> Acked-by: Rob Herring >>> --- >>> >>> v2: Use decoder,max-value instead of gpio-decoder,max-value. > > That's not what Rob asked for. "decoder-max-value", not "decoder" vendor > prefix. > Sorry.. Will fix this in v3. -- Regards Vignesh
[PATCH 2/2] reset: uniphier: use of_device_get_match_data() to get matched data
Use of_device_get_match_data() instead of of_match_node(). With
this, we can retrieve the .data field of the OF match table more
easily. No more need to define (or declare) the match table before
the probe callback. I prefer to collect boilerplates at the bottom
of the file, so moved it below.
Signed-off-by: Masahiro Yamada
---
drivers/reset/reset-uniphier.c | 81 +-
1 file changed, 40 insertions(+), 41 deletions(-)
diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
index 41c62af..9b3f2cd 100644
--- a/drivers/reset/reset-uniphier.c
+++ b/drivers/reset/reset-uniphier.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -285,6 +286,45 @@ static const struct reset_control_ops uniphier_reset_ops =
{
.status = uniphier_reset_status,
};
+static int uniphier_reset_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct uniphier_reset_priv *priv;
+ const struct uniphier_reset_data *p, *data;
+ struct regmap *regmap;
+ struct device_node *parent;
+ unsigned int nr_resets = 0;
+
+ data = of_device_get_match_data(dev);
+ WARN_ON(!data);
+
+ parent = of_get_parent(dev->of_node); /* parent should be syscon node */
+ regmap = syscon_node_to_regmap(parent);
+ of_node_put(parent);
+ if (IS_ERR(regmap)) {
+ dev_err(dev, "failed to get regmap (error %ld)\n",
+ PTR_ERR(regmap));
+ return PTR_ERR(regmap);
+ }
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ for (p = data; p->id != UNIPHIER_RESET_ID_END; p++)
+ nr_resets = max(nr_resets, p->id + 1);
+
+ priv->rcdev.ops = &uniphier_reset_ops;
+ priv->rcdev.owner = dev->driver->owner;
+ priv->rcdev.of_node = dev->of_node;
+ priv->rcdev.nr_resets = nr_resets;
+ priv->dev = dev;
+ priv->regmap = regmap;
+ priv->data = data;
+
+ return devm_reset_controller_register(&pdev->dev, &priv->rcdev);
+}
+
static const struct of_device_id uniphier_reset_match[] = {
/* System reset */
{
@@ -385,47 +425,6 @@ static const struct of_device_id uniphier_reset_match[] = {
};
MODULE_DEVICE_TABLE(of, uniphier_reset_match);
-static int uniphier_reset_probe(struct platform_device *pdev)
-{
- struct device *dev = &pdev->dev;
- const struct of_device_id *match;
- struct uniphier_reset_priv *priv;
- const struct uniphier_reset_data *p;
- struct regmap *regmap;
- struct device_node *parent;
- unsigned int nr_resets = 0;
-
- match = of_match_node(uniphier_reset_match, pdev->dev.of_node);
- if (!match)
- return -ENODEV;
-
- parent = of_get_parent(dev->of_node); /* parent should be syscon node */
- regmap = syscon_node_to_regmap(parent);
- of_node_put(parent);
- if (IS_ERR(regmap)) {
- dev_err(dev, "failed to get regmap (error %ld)\n",
- PTR_ERR(regmap));
- return PTR_ERR(regmap);
- }
-
- priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
- if (!priv)
- return -ENOMEM;
-
- for (p = match->data; p->id != UNIPHIER_RESET_ID_END; p++)
- nr_resets = max(nr_resets, p->id + 1);
-
- priv->rcdev.ops = &uniphier_reset_ops;
- priv->rcdev.owner = dev->driver->owner;
- priv->rcdev.of_node = dev->of_node;
- priv->rcdev.nr_resets = nr_resets;
- priv->dev = dev;
- priv->regmap = regmap;
- priv->data = match->data;
-
- return devm_reset_controller_register(&pdev->dev, &priv->rcdev);
-}
-
static struct platform_driver uniphier_reset_driver = {
.probe = uniphier_reset_probe,
.driver = {
--
1.9.1
Re: [PATCH v3 3/4] mfd: mfd-core: reattach mfd of_node to cells without of_compatible
Hi Lee, On Tue, Aug 09, 2016 at 02:48:47PM +0100, Lee Jones wrote: > On Tue, 26 Jul 2016, Quentin Schulz wrote: > > > When an MFD cell has an of_compatible (meaning it is present in the Device > > Tree), other nodes can reference it using a phandle. > > > > However when the MFD cell is not declared in the Device Tree, the only way > > other nodes can reference it are by using a phandle to the MFD. Then when > > this MFD cell tries to register itself in one framework, the registration > > is denied by the framework because it is not matching the of_node of the > > node which is referenced by the phandle in one of the other nodes. > > > > This reattaches the of_node of the MFD to the MFD cell device structure > > when the MFD cell has no of_compatible. > > > > Signed-off-by: Quentin Schulz > > --- > > > > We need this modification to register the thermal sensor in the thermal > > framework. > > > > Added in v3. > > > > drivers/mfd/mfd-core.c | 14 +- > > 1 file changed, 9 insertions(+), 5 deletions(-) > > Can you show me the DT code where this is used? > > Is it used by a patch in this series? Yes and no. This is not used directly by any code found in those patches. However, those patches are actually a rewrite of an existing driver that was there before (drivers/input/touchscreen/sun4i-ts.c), that already had some DT bindings and was enabled in a few DT already [1]. The issue here is that for the new driver to be able to follow the phandles as it used to (which is also already used [2]). Obviously, in the usual mechanism (at least when you don't declare the mfd childs in the DT), the childs won't have any of_node associated to it, and this is fine in most cases. This is where things get messy. The MFD childs will also register to their framework without, and then the whole phandle lookup goes nuts, because the phandles will point to the MFD's of_node, but no one will actually be registered anywhere with that of_node, which means that we broke all the links expressed by the phandles. Maxime 1: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/sun7i-a20.dtsi#n1520 2: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/sun7i-a20.dtsi#n130 -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
[PATCH 0/2] reset: uniphier: follow-up fix, clean-up
Hi Philipp, Here is two follow-up patches. - add missing static - use of_device_get_match_data() rather than of_match_node() for the probe clean-up The initial commit of the driver is still on the top of "reset/next" branch. If possible, could you squash these two into the initial one? Nobody would be bothered with this. Masahiro Yamada (2): reset: uniphier: add static qualifier to probe function reset: uniphier: use of_device_get_match_data() to get matched data drivers/reset/reset-uniphier.c | 81 +- 1 file changed, 40 insertions(+), 41 deletions(-) -- 1.9.1
[PATCH 1/2] reset: uniphier: add static qualifier to probe function
I missed this in the initial commit.
Signed-off-by: Masahiro Yamada
---
drivers/reset/reset-uniphier.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
index 9de071f..41c62af 100644
--- a/drivers/reset/reset-uniphier.c
+++ b/drivers/reset/reset-uniphier.c
@@ -385,7 +385,7 @@ static const struct of_device_id uniphier_reset_match[] = {
};
MODULE_DEVICE_TABLE(of, uniphier_reset_match);
-int uniphier_reset_probe(struct platform_device *pdev)
+static int uniphier_reset_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
const struct of_device_id *match;
--
1.9.1
Re: OOM detection regressions since 4.7
On Tue 23-08-16 15:08:05, Linus Torvalds wrote: > On Tue, Aug 23, 2016 at 3:33 AM, Michal Hocko wrote: > > > > I would argue that CONFIG_COMPACTION=n behaves so arbitrary for high > > order workloads that calling any change in that behavior a regression > > is little bit exaggerated. > > Well, the thread info allocations certainly haven't been big problems > before. So regressing those would seem to be a real regression. > > What happened? We've done the order-2 allocation for the stack since > May 2014, so that isn't new. Did we cut off retries for low orders? Yes, with the original implementation the number of reclaim retries is basically unbounded and as long as we have a reclaim progress. This has changed to be a bounded process. Without the compaction this means that we were reclaim as long as an order-2 page was formed. > So I would not say that it's an exaggeration to say that order-2 > allocations failing is a regression. I would agree with you with COMPACTION enabled but with compaction disabled which should be really limited to !MMU configurations I think there is not much we can do. Well, we could simply retry for ever without invoking OOM killer for higher order request for this config option and rely on order-0 to hit the OOM. Do we want that though? I do not remember anybody with !MMU to complain. Markus had COMPACTION disabled accidentally. -- Michal Hocko SUSE Labs
Re: [PATCH v2 07/10] clk: qcom: Add support to enable FSM mode for votable alpha PLLs
On 08/11, Rajendra Nayak wrote: > diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c > index f7c226a..6bf5abd 100644 > --- a/drivers/clk/qcom/common.c > +++ b/drivers/clk/qcom/common.c > @@ -25,6 +25,14 @@ > #include "reset.h" > #include "gdsc.h" > > +#define PLL_LOCK_COUNT_SHIFT 8 > +#define PLL_LOCK_COUNT_MASK 0x3f > +#define PLL_BIAS_COUNT_SHIFT 14 > +#define PLL_BIAS_COUNT_MASK 0x3f > +#define PLL_VOTE_FSM_ENA BIT(20) > +#define PLL_DYN_FSM_ENA BIT(20) > +#define PLL_VOTE_FSM_RESET BIT(21) These appear but aren't deleted from anywhere else so I suspect now we have two copies of these defines somewhere? Perhaps this should go into common.h as well? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2 09/10] clk: qcom: Add .is_enabled ops for clk-alpha-pll
On 08/11, Rajendra Nayak wrote: > This would be useful in subsequent patches when the .set_rate operation > would need to identify if the PLL is actually enabled > > Signed-off-by: Rajendra Nayak > --- Hmmm I suspect I never implemented the is_enabled op because that will happen to turn off clks during late init that shouldn't otherwise be disabled because the framework now can see that some PLL is enabled out of the bootloader. Is that happening now? We really should fix the framework to make this not be a problem, mostly by finishing off the clk handoff patches that Mike posted a while back. But either way, I'm worried with these patches that implement is_enabled ops. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2 10/10] clk: qcom: Fix .set_rate to handle alpha PLLs w/wo dynamic update
On 08/11, Rajendra Nayak wrote:
> diff --git a/drivers/clk/qcom/clk-alpha-pll.c
> b/drivers/clk/qcom/clk-alpha-pll.c
> index 2184dc1..68c90f3 100644
> --- a/drivers/clk/qcom/clk-alpha-pll.c
> +++ b/drivers/clk/qcom/clk-alpha-pll.c
> @@ -113,6 +113,11 @@ static int wait_for_pll_offline(struct clk_alpha_pll
> *pll, u32 mask)
> #define PLL_OFFLINE_ACK BIT(28)
> #define PLL_ACTIVE_FLAG BIT(30)
>
> +/* alpha pll with dynamic update support */
> +#define PLL_UPDATE BIT(22)
> +#define PLL_HW_LOGIC_BYPASS BIT(23)
> +#define PLL_ACK_LATCHBIT(29)
These need to move next to associated registers.
> +
> void clk_alpha_pll_configure(struct clk_alpha_pll *pll, struct regmap
> *regmap,
>const struct alpha_pll_config *config)
> {
> @@ -366,6 +402,7 @@ clk_alpha_pll_recalc_rate(struct clk_hw *hw, unsigned
> long parent_rate)
> static int clk_alpha_pll_set_rate(struct clk_hw *hw, unsigned long rate,
> unsigned long prate)
> {
> + int enabled;
bool
> struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
> const struct pll_vco *vco;
> u32 l, off = pll->offset;
> @@ -378,6 +415,11 @@ static int clk_alpha_pll_set_rate(struct clk_hw *hw,
> unsigned long rate,
> return -EINVAL;
> }
>
> + enabled = hw->init->ops->is_enabled(hw);
We have clk_hw_is_enabled() for this.
> +
> + if (!(pll->flags & SUPPORTS_DYNAMIC_UPDATE) && enabled)
> + hw->init->ops->disable(hw);
Please call the function directly instead of going through the
init structure to get the clk ops.
> +
> a <<= (ALPHA_REG_BITWIDTH - ALPHA_BITWIDTH);
>
> regmap_write(pll->clkr.regmap, off + PLL_L_VAL, l);
> @@ -391,6 +433,12 @@ static int clk_alpha_pll_set_rate(struct clk_hw *hw,
> unsigned long rate,
> regmap_update_bits(pll->clkr.regmap, off + PLL_USER_CTL, PLL_ALPHA_EN,
> PLL_ALPHA_EN);
>
> + if (!(pll->flags & SUPPORTS_DYNAMIC_UPDATE) && enabled)
> + hw->init->ops->enable(hw);
> +
> + if (pll->flags & SUPPORTS_DYNAMIC_UPDATE)
> + clk_alpha_pll_dynamic_update(pll);
> +
Perhaps write it as
if (pll->flags & SUPPORTS_DYNAMIC_UPDATE)
clk_alpha_pll_dynamic_update()
else if (enabled)
toggle the enable bit...
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v2 00/10] clk: qcom: PLL updates
On 08/11, Rajendra Nayak wrote: > Hi, > > This series adds some additional support to the clk-alpha-pll and the > clk-pll drivers in preperation to add the CPU clock driver support > on msm8996 It would be nice to see the users of this new code. Can that also be posted, even if it's just RFC and not for merging at this time? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2 02/10] clk: qcom: Add support for alpha pll hwfsm ops
On 08/11, Rajendra Nayak wrote:
> Add support to enable/disable the alpha pll using hwfsm
Care to add some more description here about what's going on?
>
> Signed-off-by: Rajendra Nayak
> ---
> drivers/clk/qcom/clk-alpha-pll.c | 109
> ++-
> drivers/clk/qcom/clk-alpha-pll.h | 1 +
> 2 files changed, 98 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/clk/qcom/clk-alpha-pll.c
> b/drivers/clk/qcom/clk-alpha-pll.c
> index e6a03ea..bae31f9 100644
> --- a/drivers/clk/qcom/clk-alpha-pll.c
> +++ b/drivers/clk/qcom/clk-alpha-pll.c
> @@ -62,9 +62,10 @@
> #define to_clk_alpha_pll_postdiv(_hw) container_of(to_clk_regmap(_hw), \
> struct clk_alpha_pll_postdiv, clkr)
>
> -static int wait_for_pll(struct clk_alpha_pll *pll)
> +static int wait_for_pll(struct clk_alpha_pll *pll, u32 mask, bool inverse,
> + const char *action)
> {
> - u32 val, mask, off;
> + u32 val, off;
> int count;
> int ret;
> const char *name = clk_hw_get_name(&pll->clkr.hw);
> @@ -74,26 +75,101 @@ static int wait_for_pll(struct clk_alpha_pll *pll)
> if (ret)
> return ret;
>
> - if (val & PLL_VOTE_FSM_ENA)
> - mask = PLL_ACTIVE_FLAG;
> - else
> - mask = PLL_LOCK_DET;
> -
> - /* Wait for pll to enable. */
Perhaps commit text could state why we shouldn't keep extending
this model of figuring out what to poll?
> for (count = 100; count > 0; count--) {
> ret = regmap_read(pll->clkr.regmap, off + PLL_MODE, &val);
> if (ret)
> return ret;
> - if ((val & mask) == mask)
> + if (inverse && (val & mask))
> + return 0;
> + else if ((val & mask) == mask)
> return 0;
>
> udelay(1);
> }
>
> - WARN(1, "%s didn't enable after voting for it!\n", name);
> + WARN(1, "%s failed to %s!\n", name, action);
> return -ETIMEDOUT;
> }
>
> +static int wait_for_pll_enable(struct clk_alpha_pll *pll, u32 mask)
> +{
> + return wait_for_pll(pll, mask, 0, "enable");
> +}
This is only called with two masks, so maybe we can have two
functions for it or a simple macro to avoid making clients know
about the mask?
> +
> +static int wait_for_pll_disable(struct clk_alpha_pll *pll, u32 mask)
> +{
> + return wait_for_pll(pll, mask, 1, "disable");
> +}
> +
> +static int wait_for_pll_offline(struct clk_alpha_pll *pll, u32 mask)
> +{
> + return wait_for_pll(pll, mask, 0, "offline");
> +}
These two are only called with one mask, why have that as a parameter?
> +
> +/* alpha pll with hwfsm support */
> +#define PLL_OFFLINE_REQ BIT(7)
> +#define PLL_FSM_ENA BIT(20)
> +#define PLL_OFFLINE_ACK BIT(28)
> +#define PLL_ACTIVE_FLAG BIT(30)
Please put these up top next to the register that they're for.
> +
> +static int clk_alpha_pll_hwfsm_enable(struct clk_hw *hw)
> +{
> + int ret;
> + u32 val, off;
> + struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
> +
> + off = pll->offset;
> + ret = regmap_read(pll->clkr.regmap, off + PLL_MODE, &val);
> + if (ret)
> + return ret;
> +
> + /* Enable HW FSM mode, clear OFFLINE request */
That's pretty obvious.
> + val |= PLL_FSM_ENA;
> + val &= ~PLL_OFFLINE_REQ;
> + ret = regmap_write(pll->clkr.regmap, off + PLL_MODE, val);
> + if (ret)
> + return ret;
> +
> + /* Make sure enable request goes through before waiting for update */
> + mb();
> +
> + ret = wait_for_pll_enable(pll, PLL_ACTIVE_FLAG);
> + if (ret)
> + return ret;
> +
> + return 0;
Simplify to return wait_for_pll_enable()?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v2 04/10] clk: qcom: Add support for PLLs with alpha mode
On 08/11, Rajendra Nayak wrote:
> Some PLLs can support an alpha mode, and a single alpha
> register (instead of registers to program the M/N values),
> the contents of which depend on the alpha mode selected.
> (They are either treated as two's complement or M/N value)
That's just a sentence, so please drop the parentheses.
> Add support for this in the clk PLL driver.
>
I'm confused, don't we already have clk-alpha-pll.c to handle
alpha type plls? What are we doing adding support to the "legacy"
pll code?
> Signed-off-by: Rajendra Nayak
> ---
> drivers/clk/qcom/clk-pll.c | 8 ++--
> drivers/clk/qcom/clk-pll.h | 2 ++
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/qcom/clk-pll.c b/drivers/clk/qcom/clk-pll.c
> index 5b940d6..08d2fa2 100644
> --- a/drivers/clk/qcom/clk-pll.c
> +++ b/drivers/clk/qcom/clk-pll.c
> @@ -255,8 +255,12 @@ static void clk_pll_configure(struct clk_pll *pll,
> struct regmap *regmap,
> u32 mask;
>
> regmap_write(regmap, pll->l_reg, config->l);
> - regmap_write(regmap, pll->m_reg, config->m);
> - regmap_write(regmap, pll->n_reg, config->n);
> + if (pll->alpha_reg) {
This assumes that alpha_reg is not 0 offset from base, which
seems like a bad assumption to make.
> + regmap_write(regmap, pll->alpha_reg, config->alpha);
> + } else {
> + regmap_write(regmap, pll->m_reg, config->m);
> + regmap_write(regmap, pll->n_reg, config->n);
> + }
>
> val = config->vco_val;
> val |= config->pre_div_val;
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v6 2/4] Add support for SCT Write Same
Btw, I wonder if you need to memset your buffer with 0 first, like
what is done in ata_scsi_rbuf_get.
On 24 August 2016 at 13:57, Tom Yan wrote:
> Never mind. I was a bit lightheaded.
>
> Anyway I don't think you should use ata_scsi_rbuf. It is a buffer
> created and used for ata_scsi_simulate, which interacts with the SCSI
> layer but not the ATA device (v.s. ata_scsi_translate). You should
> probably create buffer inside ata_format_dsm_trim_descr() and
> ata_format_sct_write_same() of size(s) you need.
>
> On 23 August 2016 at 18:56, Shaun Tancheff wrote:
>> On Tue, Aug 23, 2016 at 5:37 AM, Tom Yan wrote:
>>> On 22 August 2016 at 04:23, Shaun Tancheff wrote:
+/**
+ * ata_format_dsm_trim_descr() - SATL Write Same to ATA SCT Write Same
+ * @cmd: SCSI command being translated
+ * @lba: Starting sector
+ * @num: Number of logical sectors to be zero'd.
+ *
+ * Rewrite the WRITE SAME descriptor to be an SCT Write Same formatted
+ * descriptor.
+ * NOTE: Writes a pattern (0's) in the foreground.
+ * Large write-same requents can timeout.
+ */
+static void ata_format_sct_write_same(struct scsi_cmnd *cmd, u64 lba, u64
num)
+{
+ u16 *sctpg;
+ unsigned long flags;
+
+ spin_lock_irqsave(&ata_scsi_rbuf_lock, flags);
+ sctpg = ((void *)ata_scsi_rbuf);
>>>
>>> Because ata_scsi_rbuf is of a fixed size of ATA_SCSI_RBUF_SIZE.
>>>
>>> #define ATA_SCSI_RBUF_SIZE 4096
>>> ...
>>> static u8 ata_scsi_rbuf[ATA_SCSI_RBUF_SIZE];
>>>
+
+ put_unaligned_le16(0x0002, &sctpg[0]); /* SCT_ACT_WRITE_SAME */
+ put_unaligned_le16(0x0101, &sctpg[1]); /* WRITE PTRN FG */
+ put_unaligned_le64(lba, &sctpg[2]);
+ put_unaligned_le64(num, &sctpg[6]);
+ put_unaligned_le32(0u, &sctpg[10]);
+
+ sg_copy_from_buffer(scsi_sglist(cmd), scsi_sg_count(cmd), sctpg,
512);
>>>
>>> You have no reason to use 512 here instead of ATA_SCSI_RBUF_SIZE this time.
>>
>> Ah .. because SCT Write Same is a fixed 512 byte transfer?
>> Ah .. because I only have 512 bytes to copy?
>>
+ spin_unlock_irqrestore(&ata_scsi_rbuf_lock, flags);
+}
Re: [PATCH] ARM: dts: sun8i: add NAND controller node for A23/A33
Hi, On Tue, Aug 23, 2016 at 09:55:46PM +0800, Icenowy Zheng wrote: > A23/A33 has a NAND controller which can now be used properly. > > Add a device node for it. > > The DMA function cannot work because of changed DMA IP block, so it's > temporarily removed in the device node. However, with PIO mode it can still > work. What is preventing the NAND driver to work with DMA with the sun6i driver? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
[RFC PATCH 4/4] perf-probe: Support probing on offline cross-arch binary
Support probing on offline cross-architecture binary by
adding getting the target machine arch from ELF and
choose correct register string for the machine.
Here is an example:
-
$ mkdir tracing
$ sudo perf probe --outdir=./tracing --vmlinux=./vmlinux-arm \
do_sys_open '$vars'
Added new event:
probe:do_sys_open(on do_sys_open with $vars)
You can now use it in all perf tools, such as:
perf record -e probe:do_sys_open -aR sleep 1
$ cat tracing/kprobe_events
p:probe/do_sys_open _text+1282292 dfd=%r5:s32 filename=%r1:u32
flags=%r6:s32 mode=%r3:u16 op=-60(%sp) fd=%r4:s32 tmp=%r7:u32
-
Here, we can get probe/do_sys_open event by "copy & paste" from
./tracing/kprobe_events to target-machine's debugfs/tracing/kprobe_events
To make sure it is correct:
-
$ nm vmlinux-arm | grep "T _text"
80008000 T _text
$ nm vmlinux-arm | grep "T do_sys_open"
801410f4 T do_sys_open
$ expr `printf "%d + %d" 0x80008000 1282292`
2148798708
$ printf "%x\n" 2148798708
801410f4
-
So "_text+12882292" indicates do_sys_open on the target binary correctly.
Signed-off-by: Masami Hiramatsu
---
tools/perf/arch/arm/include/dwarf-regs-table.h |9 +++
tools/perf/arch/arm64/include/dwarf-regs-table.h | 13 +
tools/perf/arch/powerpc/include/dwarf-regs-table.h | 27 ++
tools/perf/arch/s390/include/dwarf-regs-table.h|8 +++
tools/perf/arch/sh/include/dwarf-regs-table.h | 25 +
tools/perf/arch/sparc/include/dwarf-regs-table.h | 18 +++
tools/perf/arch/x86/include/dwarf-regs-table.h | 14 +
tools/perf/arch/xtensa/include/dwarf-regs-table.h |8 +++
tools/perf/util/Build |1
tools/perf/util/dwarf-regs.c | 55
tools/perf/util/include/dwarf-regs.h |6 ++
tools/perf/util/probe-finder.c | 27 ++
tools/perf/util/probe-finder.h |1
13 files changed, 201 insertions(+), 11 deletions(-)
create mode 100644 tools/perf/arch/arm/include/dwarf-regs-table.h
create mode 100644 tools/perf/arch/arm64/include/dwarf-regs-table.h
create mode 100644 tools/perf/arch/powerpc/include/dwarf-regs-table.h
create mode 100644 tools/perf/arch/s390/include/dwarf-regs-table.h
create mode 100644 tools/perf/arch/sh/include/dwarf-regs-table.h
create mode 100644 tools/perf/arch/sparc/include/dwarf-regs-table.h
create mode 100644 tools/perf/arch/x86/include/dwarf-regs-table.h
create mode 100644 tools/perf/arch/xtensa/include/dwarf-regs-table.h
create mode 100644 tools/perf/util/dwarf-regs.c
diff --git a/tools/perf/arch/arm/include/dwarf-regs-table.h
b/tools/perf/arch/arm/include/dwarf-regs-table.h
new file mode 100644
index 000..f298d03
--- /dev/null
+++ b/tools/perf/arch/arm/include/dwarf-regs-table.h
@@ -0,0 +1,9 @@
+#ifdef DEFINE_DWARF_REGSTR_TABLE
+/* This is included in perf/util/dwarf-regs.c */
+
+static const char * const arm_regstr_tbl[] = {
+ "%r0", "%r1", "%r2", "%r3", "%r4",
+ "%r5", "%r6", "%r7", "%r8", "%r9", "%r10",
+ "%fp", "%ip", "%sp", "%lr", "%pc",
+};
+#endif
diff --git a/tools/perf/arch/arm64/include/dwarf-regs-table.h
b/tools/perf/arch/arm64/include/dwarf-regs-table.h
new file mode 100644
index 000..2675936
--- /dev/null
+++ b/tools/perf/arch/arm64/include/dwarf-regs-table.h
@@ -0,0 +1,13 @@
+#ifdef DEFINE_DWARF_REGSTR_TABLE
+/* This is included in perf/util/dwarf-regs.c */
+
+static const char * const aarch64_regstr_tbl[] = {
+ "%r0", "%r1", "%r2", "%r3", "%r4",
+ "%r5", "%r6", "%r7", "%r8", "%r9",
+ "%r10", "%r11", "%r12", "%r13", "%r14",
+ "%r15", "%r16", "%r17", "%r18", "%r19",
+ "%r20", "%r21", "%r22", "%r23", "%r24",
+ "%r25", "%r26", "%r27", "%r28", "%r29",
+ "%lr", "%sp",
+};
+#endif
diff --git a/tools/perf/arch/powerpc/include/dwarf-regs-table.h
b/tools/perf/arch/powerpc/include/dwarf-regs-table.h
new file mode 100644
index 000..db4730f
--- /dev/null
+++ b/tools/perf/arch/powerpc/include/dwarf-regs-table.h
@@ -0,0 +1,27 @@
+#ifdef DEFINE_DWARF_REGSTR_TABLE
+/* This is included in perf/util/dwarf-regs.c */
+
+/*
+ * Reference:
+ * http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html
+ * http://refspecs.linux-foundation.org/elf/elfspec_ppc.pdf
+ */
+#define REG_DWARFNUM_NAME(reg, idx)[idx] = "%" #reg
+
+static const char * const powerpc_regstr_tbl[] = {
+ "%gpr0", "%gpr1", "%gpr2", "%gpr3", "%gpr4",
+ "%gpr5", "%gpr6", "%gpr7", "%gpr8", "%gpr9",
+ "%gpr10", "%gpr11", "%gpr12", "%gpr13", "%gpr14",
+ "%gpr15", "%gpr16", "%gpr17", "%gpr18", "%gpr19",
+ "%gpr20", "%gpr21", "%gpr22", "%gpr23", "%gpr24",
+ "%gpr25", "%gpr26", "%gpr27", "%gpr28", "%gpr29",
+ "%gpr30", "%gpr31",
+ REG_DWARFNUM_NAME(msr, 66),
+ REG_DWARFNUM_NAME(ctr, 109),
+ REG_DWARFNUM_NAME(link, 108),
+ REG_DWARFNUM_NAME(xer, 101),
Re: [PATCH v2 4/4] gpu: drm: exynos_hdmi: Use consolidated function on binding PHY DT property
On 08/24/2016 04:25 AM, Milo Kim wrote:
> Handle legacy and raw 'phy' parsing in single function.
> And it also removes goto condition.
>
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Cc: David Airlie
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Cc: Rob Herring
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Milo Kim
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 23 ++-
> 1 file changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 6a636f2..bb2d6d4 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1778,11 +1778,22 @@ static struct device_node *hdmi_ddc_dt_binding(struct
> device *dev)
> return np;
> }
>
> -static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
> +static struct device_node *hdmi_phy_dt_binding(struct device *dev)
> {
> const char *compatible_str = "samsung,exynos4212-hdmiphy";
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, NULL, compatible_str);
> + if (np)
> + return np;
> +
> + np = of_parse_phandle(dev->of_node, "phy", 0);
> + if (!np)
> + return NULL;
> +
> + of_node_put(dev->of_node);
Identical issue as in previous patch.
Regards
Andrzej
>
> - return of_find_compatible_node(NULL, NULL, compatible_str);
> + return np;
> }
>
> static int hdmi_probe(struct platform_device *pdev)
> @@ -1829,19 +1840,13 @@ static int hdmi_probe(struct platform_device *pdev)
> return -EPROBE_DEFER;
> }
>
> - phy_node = hdmi_legacy_phy_dt_binding(dev);
> - if (phy_node)
> - goto out_get_phy_port;
> -
> - phy_node = of_parse_phandle(dev->of_node, "phy", 0);
> + phy_node = hdmi_phy_dt_binding(dev);
> if (!phy_node) {
> DRM_ERROR("Failed to find hdmiphy node in device tree\n");
> ret = -ENODEV;
> goto err_ddc;
> }
> - of_node_put(dev->of_node);
>
> -out_get_phy_port:
> if (hdata->drv_data->is_apb_phy) {
> hdata->regs_hdmiphy = of_iomap(phy_node, 0);
> if (!hdata->regs_hdmiphy) {
[RFC PATCH 2/4] perf-probe: Add offline output directory option
Add offline output direcrtory option. This allows user to
store probe event definition in offline output directory.
Signed-off-by: Masami Hiramatsu
---
tools/perf/builtin-probe.c|2 ++
tools/perf/util/probe-event.h |1 +
tools/perf/util/probe-file.c | 19 ---
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index ee5b421..5b45ec8 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -517,6 +517,8 @@ __cmd_probe(int argc, const char **argv, const char *prefix
__maybe_unused)
"Show variables location range in scope (with --vars only)"),
OPT_STRING('k', "vmlinux", &symbol_conf.vmlinux_name,
"file", "vmlinux pathname"),
+ OPT_STRING(0, "outdir", &probe_conf.output_dir,
+ "directory", "path to offline output directory"),
OPT_STRING('s', "source", &symbol_conf.source_prefix,
"directory", "path to kernel source"),
OPT_BOOLEAN('\0', "no-inlines", &probe_conf.no_inlines,
diff --git a/tools/perf/util/probe-event.h b/tools/perf/util/probe-event.h
index f4f45db..75b572a 100644
--- a/tools/perf/util/probe-event.h
+++ b/tools/perf/util/probe-event.h
@@ -14,6 +14,7 @@ struct probe_conf {
boolno_inlines;
boolcache;
int max_probes;
+ const char *output_dir;
};
extern struct probe_conf probe_conf;
extern bool probe_event_dry_run;
diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index 6f931e4..41db430 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -73,16 +73,25 @@ static void print_both_open_warning(int kerr, int uerr)
static int open_probe_events(const char *trace_file, bool readwrite)
{
char buf[PATH_MAX];
+ const char *tracing_dir = tracing_path;
+ int oflag = 0;
+ mode_t mode = 0;
int ret;
+ if (probe_conf.output_dir) {
+ tracing_dir = probe_conf.output_dir;
+ oflag = O_CREAT;
+ mode = 0644;
+ }
+
ret = e_snprintf(buf, PATH_MAX, "%s/%s",
-tracing_path, trace_file);
+tracing_dir, trace_file);
if (ret >= 0) {
pr_debug("Opening %s write=%d\n", buf, readwrite);
if (readwrite && !probe_event_dry_run)
- ret = open(buf, O_RDWR | O_APPEND, 0);
+ ret = open(buf, O_RDWR | O_APPEND | oflag, mode);
else
- ret = open(buf, O_RDONLY, 0);
+ ret = open(buf, O_RDONLY | oflag, mode);
if (ret < 0)
ret = -errno;
@@ -242,6 +251,8 @@ int probe_file__add_event(int fd, struct probe_trace_event
*tev)
pr_warning("Failed to write event: %s\n",
str_error_r(errno, sbuf, sizeof(sbuf)));
}
+ if (probe_conf.output_dir)
+ ret = write(fd, "\n", 1) == 1 ? 0 : -errno;
}
free(buf);
@@ -274,6 +285,8 @@ static int __del_trace_probe_event(int fd, struct str_node
*ent)
ret = -errno;
goto error;
}
+ if (probe_conf.output_dir)
+ ret = write(fd, "\n", 1) == 1 ? 0 : -errno;
return 0;
error:
[RFC PATCH 3/4] perf-probe: Ignore vmlinux buildid if offline kernel is given
Ignore the buildid of running kernel when both --outdir and
--vmlinux is given and --outdir is not tracing_path,
because that kernel should be off-line.
Signed-off-by: Masami Hiramatsu
---
tools/perf/builtin-probe.c |6 ++
tools/perf/util/symbol-elf.c |2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index 5b45ec8..773cea0 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -602,6 +602,12 @@ __cmd_probe(int argc, const char **argv, const char
*prefix __maybe_unused)
*/
symbol_conf.try_vmlinux_path = (symbol_conf.vmlinux_name == NULL);
+ /* If user gives output directory and offline vmlinux, ignore buildid */
+ if (probe_conf.output_dir && symbol_conf.vmlinux_name &&
+ strcmp(probe_conf.output_dir, tracing_path) != 0) {
+ symbol_conf.ignore_vmlinux_buildid = true;
+ }
+
switch (params.command) {
case 'l':
if (params.uprobes) {
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index a811c13..013cebf 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -685,7 +685,7 @@ int symsrc__init(struct symsrc *ss, struct dso *dso, const
char *name,
}
/* Always reject images with a mismatched build-id: */
- if (dso->has_build_id) {
+ if (dso->has_build_id && !symbol_conf.ignore_vmlinux_buildid) {
u8 build_id[BUILD_ID_SIZE];
if (elf_read_build_id(elf, build_id, BUILD_ID_SIZE) < 0) {
[RFC PATCH 1/4] perf-probe: Remove unused tracing_dir variable
Remove unused tracing_dir variable from open_probe_events().
Signed-off-by: Masami Hiramatsu
---
tools/perf/util/probe-file.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index 697ef66..6f931e4 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -73,11 +73,10 @@ static void print_both_open_warning(int kerr, int uerr)
static int open_probe_events(const char *trace_file, bool readwrite)
{
char buf[PATH_MAX];
- const char *tracing_dir = "";
int ret;
- ret = e_snprintf(buf, PATH_MAX, "%s/%s%s",
-tracing_path, tracing_dir, trace_file);
+ ret = e_snprintf(buf, PATH_MAX, "%s/%s",
+tracing_path, trace_file);
if (ret >= 0) {
pr_debug("Opening %s write=%d\n", buf, readwrite);
if (readwrite && !probe_event_dry_run)
[RFC PATCH 0/4] perf probe: Introduce remote cross-arch probes
Hi, Here is an RFC series for remote cross-arch probe support on perf-probe. I've made a perf-probe for remote arch (currently arm on x86-64) for helping debugging and performance analysis. Currently perf-probe doesn't supoort cross/remote target. This means we have to cross-build the perf-tools including libraries (elfutils, libelf etc.), and to prepare vmlinux with debuginfo which can be accessed from the target machine. This requires too much resource for a small embededd device. If we can analyze the debuginfo by perf-probe on host machine, we do not need to cross-build perf-tools, nor copy vmlinux on the device. :) This series introduces such features on perf-probe. To use this, on host machine (with cross build kernel image), below command outputs the target-machine's kprobe-events definition in /kprobe_events. perf probe -k --outdir= \ Perf analyzes the given vmlinux and get the architecture and switch the dwarf-register mappings. Here is an example: - $ mkdir tracing $ sudo perf probe --outdir=./tracing --vmlinux=./vmlinux-arm \ do_sys_open '$vars' Added new event: probe:do_sys_open(on do_sys_open with $vars) You can now use it in all perf tools, such as: perf record -e probe:do_sys_open -aR sleep 1 $ cat tracing/kprobe_events p:probe/do_sys_open _text+1282292 dfd=%r5:s32 filename=%r1:u32 flags=%r6:s32 mode=%r3:u16 op=-60(%sp) fd=%r4:s32 tmp=%r7:u32 - Here, we can get probe/do_sys_open event by "copy & paste" the definition to target-machine's debugfs/tracing/kprobe_events. To make sure it is correct: - $ nm vmlinux-arm | grep "T _text" 80008000 T _text $ nm vmlinux-arm | grep "T do_sys_open" 801410f4 T do_sys_open $ expr `printf "%d + %d" 0x80008000 1282292` 2148798708 $ printf "%x\n" 2148798708 801410f4 - So "_text+12882292" indicates do_sys_open on the target binary correctly. Thanks, --- Masami Hiramatsu (4): perf-probe: Remove unused tracing_dir variable perf-probe: Add offline output directory option perf-probe: Ignore vmlinux buildid if offline kernel is given perf-probe: Support probing on offline cross-arch binary tools/perf/arch/arm/include/dwarf-regs-table.h |9 +++ tools/perf/arch/arm64/include/dwarf-regs-table.h | 13 + tools/perf/arch/powerpc/include/dwarf-regs-table.h | 27 ++ tools/perf/arch/s390/include/dwarf-regs-table.h|8 +++ tools/perf/arch/sh/include/dwarf-regs-table.h | 25 + tools/perf/arch/sparc/include/dwarf-regs-table.h | 18 +++ tools/perf/arch/x86/include/dwarf-regs-table.h | 14 + tools/perf/arch/xtensa/include/dwarf-regs-table.h |8 +++ tools/perf/builtin-probe.c |8 +++ tools/perf/util/Build |1 tools/perf/util/dwarf-regs.c | 55 tools/perf/util/include/dwarf-regs.h |6 ++ tools/perf/util/probe-event.h |1 tools/perf/util/probe-file.c | 22 ++-- tools/perf/util/probe-finder.c | 27 ++ tools/perf/util/probe-finder.h |1 tools/perf/util/symbol-elf.c |2 - 17 files changed, 228 insertions(+), 17 deletions(-) create mode 100644 tools/perf/arch/arm/include/dwarf-regs-table.h create mode 100644 tools/perf/arch/arm64/include/dwarf-regs-table.h create mode 100644 tools/perf/arch/powerpc/include/dwarf-regs-table.h create mode 100644 tools/perf/arch/s390/include/dwarf-regs-table.h create mode 100644 tools/perf/arch/sh/include/dwarf-regs-table.h create mode 100644 tools/perf/arch/sparc/include/dwarf-regs-table.h create mode 100644 tools/perf/arch/x86/include/dwarf-regs-table.h create mode 100644 tools/perf/arch/xtensa/include/dwarf-regs-table.h create mode 100644 tools/perf/util/dwarf-regs.c -- Masami Hiramatsu (Linaro Ltd.)
Re: [PATCH v6 2/4] Add support for SCT Write Same
Never mind. I was a bit lightheaded.
Anyway I don't think you should use ata_scsi_rbuf. It is a buffer
created and used for ata_scsi_simulate, which interacts with the SCSI
layer but not the ATA device (v.s. ata_scsi_translate). You should
probably create buffer inside ata_format_dsm_trim_descr() and
ata_format_sct_write_same() of size(s) you need.
On 23 August 2016 at 18:56, Shaun Tancheff wrote:
> On Tue, Aug 23, 2016 at 5:37 AM, Tom Yan wrote:
>> On 22 August 2016 at 04:23, Shaun Tancheff wrote:
>>> +/**
>>> + * ata_format_dsm_trim_descr() - SATL Write Same to ATA SCT Write Same
>>> + * @cmd: SCSI command being translated
>>> + * @lba: Starting sector
>>> + * @num: Number of logical sectors to be zero'd.
>>> + *
>>> + * Rewrite the WRITE SAME descriptor to be an SCT Write Same formatted
>>> + * descriptor.
>>> + * NOTE: Writes a pattern (0's) in the foreground.
>>> + * Large write-same requents can timeout.
>>> + */
>>> +static void ata_format_sct_write_same(struct scsi_cmnd *cmd, u64 lba, u64
>>> num)
>>> +{
>>> + u16 *sctpg;
>>> + unsigned long flags;
>>> +
>>> + spin_lock_irqsave(&ata_scsi_rbuf_lock, flags);
>>> + sctpg = ((void *)ata_scsi_rbuf);
>>
>> Because ata_scsi_rbuf is of a fixed size of ATA_SCSI_RBUF_SIZE.
>>
>> #define ATA_SCSI_RBUF_SIZE 4096
>> ...
>> static u8 ata_scsi_rbuf[ATA_SCSI_RBUF_SIZE];
>>
>>> +
>>> + put_unaligned_le16(0x0002, &sctpg[0]); /* SCT_ACT_WRITE_SAME */
>>> + put_unaligned_le16(0x0101, &sctpg[1]); /* WRITE PTRN FG */
>>> + put_unaligned_le64(lba, &sctpg[2]);
>>> + put_unaligned_le64(num, &sctpg[6]);
>>> + put_unaligned_le32(0u, &sctpg[10]);
>>> +
>>> + sg_copy_from_buffer(scsi_sglist(cmd), scsi_sg_count(cmd), sctpg,
>>> 512);
>>
>> You have no reason to use 512 here instead of ATA_SCSI_RBUF_SIZE this time.
>
> Ah .. because SCT Write Same is a fixed 512 byte transfer?
> Ah .. because I only have 512 bytes to copy?
>
>>> + spin_unlock_irqrestore(&ata_scsi_rbuf_lock, flags);
>>> +}
Re: [PATCH v2 3/4] gpu: drm: exynos_hdmi: Use consolidated function on binding DDC DT property
On 08/24/2016 04:25 AM, Milo Kim wrote:
> Handle legacy and raw 'ddc' parsing in single function.
> And it also removes goto condition.
>
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Cc: David Airlie
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Cc: Rob Herring
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Milo Kim
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 2275efe..6a636f2 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1760,7 +1760,7 @@ static const struct component_ops hdmi_component_ops = {
> .unbind = hdmi_unbind,
> };
>
> -static struct device_node *hdmi_legacy_ddc_dt_binding(struct device *dev)
> +static struct device_node *hdmi_ddc_dt_binding(struct device *dev)
> {
> const char *compatible_str = "samsung,exynos4210-hdmiddc";
> struct device_node *np;
> @@ -1769,7 +1769,13 @@ static struct device_node
> *hdmi_legacy_ddc_dt_binding(struct device *dev)
> if (np)
> return of_get_next_parent(np);
>
> - return NULL;
> + np = of_parse_phandle(dev->of_node, "ddc", 0);
> + if (!np)
> + return NULL;
> +
> + of_node_put(dev->of_node);
This is mistake introduced by other patch, of_node_put should be called on
np, after calling of_find_i2c_adapter_by_node. You can fix it in your
patch as well.
I think you can move of_find_i2c_adapter_by_node also to this function and
rename it to sth like hdmi_get_ddc_adapter, this way you will enclose
whole logic
of getting resource into one function.
Regards
Andrzej
> +
> + return np;
> }
>
> static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
> @@ -1811,18 +1817,12 @@ static int hdmi_probe(struct platform_device *pdev)
> return ret;
> }
>
> - ddc_node = hdmi_legacy_ddc_dt_binding(dev);
> - if (ddc_node)
> - goto out_get_ddc_adpt;
> -
> - ddc_node = of_parse_phandle(dev->of_node, "ddc", 0);
> + ddc_node = hdmi_ddc_dt_binding(dev);
> if (!ddc_node) {
> DRM_ERROR("Failed to find ddc node in device tree\n");
> return -ENODEV;
> }
> - of_node_put(dev->of_node);
>
> -out_get_ddc_adpt:
> hdata->ddc_adpt = of_find_i2c_adapter_by_node(ddc_node);
> if (!hdata->ddc_adpt) {
> DRM_ERROR("Failed to get ddc i2c adapter by node\n");
Re: [PATCH v2 2/2] HWRNG: thunderx: Add Cavium HWRNG driver for ThunderX SoC.
Hello
> +/* Read data from the RNG unit */
> +static int cavium_rng_read(struct hwrng *rng, void *dat, size_t max, bool
> wait)
> +{
> + struct cavium_rng *p = container_of(rng, struct cavium_rng, ops);
> + unsigned int size = max;
> +
> + while (size >= 8) {
> + *((u64 *)dat) = readq(p->result);
> + size -= 8;
> + dat += 8;
> + }
I think you could use readsq()
This will increase throughput
Regards
LABBE Corentin
Re: [PATCH] memremap: Fix NULL pointer BUG in get_zone_device_page()
On Tue, Aug 23, 2016 at 8:58 PM, Dan Williams wrote:
> On Tue, Aug 23, 2016 at 7:53 PM, Dan Williams
> wrote:
>> On Tue, Aug 23, 2016 at 6:29 PM, Kani, Toshimitsu wrote:
On Tue, Aug 23, 2016 at 4:47 PM, Kani, Toshimitsu
wrote:
> On Tue, 2016-08-23 at 15:32 -0700, Dan Williams wrote:
>> On Tue, Aug 23, 2016 at 11:43 AM, Toshi Kani
>> wrote:
> :
>> I'm not sure about this fix. The point of honoring
>> vmem_altmap_offset() is because a portion of the resource that is
>> passed to devm_memremap_pages() also contains the metadata info
block
>> for the device. The offset says "use everything past this point for
>> pages". This may work for avoiding a crash, but it may corrupt info
>> block metadata in the process. Can you provide more information
>> about the failing scenario to be sure that we are not triggering a
>> fault on an address that is not meant to have a page mapping? I.e.
>> what is the host physical address of the page that caused this fault,
>> and is it valid?
>
> The fault address in question was the 2nd page of an NVDIMM range. I
> assumed this fault address was valid and needed to be handled. Here is
> some info about the base and patched cases. Let me know if you need
> more info.
>
> Base
>
>
> The following NVDIMM range was set to /dev/dax.
With ndctl create-namespace or manually via sysfs? Specifically I'm
looking for what the 'align' attribute was set to when the
configuration was established. Can you provide a dump of the sysfs
attributes for the /dev/dax parent device?
>>>
>>> I used the ndctl command below.
>>> ndctl create-namespace -f -e namespace0.0 -m dax
>>>
>>> Here is additional info from my note for the base case.
>>>
>>> p {struct dev_pagemap} 0x88046d0453f0
>>> $3 = {
>>> altmap = 0x88046d045410,
>>> res = 0x88046d0453a8,
>>> ref = 0x88046d0452f0,
>>> dev = 0x880464790410
>>> }
>>>
>>> crash> p {struct vmem_altmap} 0x88046d045410
>>> $6 = {
>>> base_pfn = 0x48,
>>> reserve = 0x2,// PHYS_PFN(SZ_8K)
>>> free = 0x101fe,
>>> align = 0x1fe,
>>> alloc = 0x1
>>> }
>>
>> Ah, so, on second look the 0x49020 data offset looks correct. The
>> total size of the address range is 16GB which equates to 256MB needed
>> for struct page, plus 2MB more to re-align the data on the next 2MB
>> boundary.
>>
>> The question now is why is the guest faulting on an access to an
>> address less than 0x49020?
>
> Does the attached patch fix this for you?
Sorry, should be this much simpler patch that also mirrors what
driver/nvdimm/pmem.c is doing...
From 3369f0e825c12bb2f17c0f7d3ccecb7c60f645e0 Mon Sep 17 00:00:00 2001
From: Dan Williams
Date: Tue, 23 Aug 2016 19:59:31 -0700
Subject: [PATCH] dax: fix device-dax region base
The data offset for a dax region needs to account for an altmap
reservation in the resource range. Otherwise, device-dax is allowing
mappings directly into the memmap or device info-block area, with crash
signatures like the following:
BUG: unable to handle kernel NULL pointer dereference at 0008
IP: [] get_zone_device_page+0x11/0x30
Call Trace:
follow_devmap_pmd+0x298/0x2c0
follow_page_mask+0x275/0x530
__get_user_pages+0xe3/0x750
__gfn_to_pfn_memslot+0x1b2/0x450 [kvm]
? hrtimer_try_to_cancel+0x2c/0x120
? kvm_read_l1_tsc+0x55/0x60 [kvm]
try_async_pf+0x66/0x230 [kvm]
? kvm_host_page_size+0x90/0xa0 [kvm]
tdp_page_fault+0x130/0x280 [kvm]
kvm_mmu_page_fault+0x5f/0xf0 [kvm]
handle_ept_violation+0x94/0x180 [kvm_intel]
vmx_handle_exit+0x1d3/0x1440 [kvm_intel]
? atomic_switch_perf_msrs+0x6f/0xa0 [kvm_intel]
? vmx_vcpu_run+0x2d1/0x490 [kvm_intel]
kvm_arch_vcpu_ioctl_run+0x81d/0x16a0 [kvm]
? wake_up_q+0x44/0x80
kvm_vcpu_ioctl+0x33c/0x620 [kvm]
? __vfs_write+0x37/0x160
do_vfs_ioctl+0xa2/0x5d0
SyS_ioctl+0x79/0x90
entry_SYSCALL_64_fastpath+0x1a/0xa4
Cc:
Cc: Andrew Morton
Fixes: ab68f2622136 ("/dev/dax, pmem: direct access to persistent memory")
Reported-by: Abhilash Kumar Mulumudi
Reported-by: Toshi Kani
Signed-off-by: Dan Williams
---
drivers/dax/pmem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/dax/pmem.c b/drivers/dax/pmem.c
index dfb168568af1..1f01e98c83c7 100644
--- a/drivers/dax/pmem.c
+++ b/drivers/dax/pmem.c
@@ -116,6 +116,9 @@ static int dax_pmem_probe(struct device *dev)
if (rc)
return rc;
+ /* adjust the dax_region resource to the start of data */
+ res.start += le64_to_cpu(pfn_sb->dataoff);
+
nd_region = to_nd_region(dev->parent);
dax_region = alloc_dax_region(dev, nd_region->id, &res,
le32_to_cpu(pfn_sb->align), addr, PFN_DEV|PFN_MAP);
--
2.5.5
Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat
On 24 August 2016 at 11:33, Martin K. Petersen wrote: >> "Tom" == Tom Yan writes: > > Tom> Nope, SCSI Write Same commands does not have payload (or in SCSI > Tom> terms, parameter list / data-out buffer). > > WRITE SAME has a a payload of 1 logical block (unless NDOB is set but we > have had no good reason to support that yet). Interesting, I wasn't aware of the bit. I just didn't see any parameter list defined for any of the Write Same commands. Ah wait, it carries the pattern (the "same") and so. Hmm, it doesn't seem like the translation implemented in this patch series cares about the payload though? > > UNMAP has a payload that varies based on the number of range > descriptors. The SCSI disk driver only ever issues a single descriptor > but since libata doesn't support UNMAP this doesn't really come into > play. > > Ideally there would be a way to distinguish between device limits for > WRITE SAME with the UNMAP bit and for "regular" WRITE SAME. One way to > do that would be to transition the libata discard implementation over to > single-range UNMAP, fill out the relevant VPD page B0 fields and leave > the WRITE SAME bits for writing zeroes. > > One reason that has not been particularly compelling is that the WRITE > SAME payload buffer does double duty to hold the ATA DSM TRIM range Huh? Why would the SATL care about its payload buffer for TRIM (i.e. when the UNMAP bit is set)? Doesn't it just read the LBA and NUMBER OF BLOCKS field and pack TRIM ranges/payload according to that? > descriptors and matches the required ATA payload size. Whereas the UNMAP Why would it need to "matches the required ATA payload size"? > command would only provide 24 bytes of TRIM range space. I don't really follow. The UNMAP descriptor has LBA (8 bytes / 64-bit) and NUMBER OF BLOCKS (4 bytes / 32-bit) field of the same length as Write Same (16). Even if the SCSI disk driver will only send one descriptor, it should work as good as Write Same (16). > > Also, please be careful with transfer lengths, __data_len, etc. As > mentioned, the transfer length WRITE SAME is typically 512 bytes and > that's the number of bytes that need to be DMA'ed and transferred over > the wire by the controller. But from a command completion perspective we > need to complete however many bytes the command acted upon. Unlike reads > and writes there is not a 1:1 mapping between the transfer length and > the affected area. So we do a bit of magic after the buffer has been > mapped to ensure that the completion byte count matches the number of > blocks that were affected by the command rather than the size of the > data buffer in bytes. > > -- > Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] drm/gma500: remove unnecessary config_enabled() guard
On Wed, Aug 24, 2016 at 01:42:54AM +0900, Masahiro Yamada wrote:
> Commit d112a8163f83 ("gma500/cdv: Add eDP support") replaced the
> code inside this if-conditional with gma_backlight_set(), which
> becomes a nop stub if CONFIG_BACKLIGHT_CLASS_DEVICE is disabled.
> So, there is no need to guard the caller with config_enabled().
>
> Note:
> This is one of remaining TODOs to deprecate config_enabled() macro.
> Refer to commit 97f2645f358b ("tree-wide: replace config_enabled()
> with IS_ENABLED()").
>
> Signed-off-by: Masahiro Yamada
Applied to drm-misc, thanks.
-Daniel
> ---
>
> drivers/gpu/drm/gma500/opregion.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/opregion.c
> b/drivers/gpu/drm/gma500/opregion.c
> index ab696ca..eab6d88 100644
> --- a/drivers/gpu/drm/gma500/opregion.c
> +++ b/drivers/gpu/drm/gma500/opregion.c
> @@ -163,10 +163,7 @@ static u32 asle_set_backlight(struct drm_device *dev,
> u32 bclp)
> if (bclp > 255)
> return ASLE_BACKLIGHT_FAILED;
>
> - if (config_enabled(CONFIG_BACKLIGHT_CLASS_DEVICE)) {
> - int max = bd->props.max_brightness;
> - gma_backlight_set(dev, bclp * max / 255);
> - }
> + gma_backlight_set(dev, bclp * bd->props.max_brightness / 255);
>
> asle->cblv = (bclp * 0x64) / 0xff | ASLE_CBLV_VALID;
>
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v2 2/4] ARM: dts: exynos: Use 'hpd-gpios' instead of 'hpd-gpio'
On 08/24/2016 04:25 AM, Milo Kim wrote:
> This patch enables getting a HPD GPIO descriptor quickly.
> The exynos-hdmi driver uses "hpd" for HDMI hot plug detection.
>
> static int hdmi_resources_init(struct hdmi_context *hdata)
> {
> ...
> hdata->hpd_gpio = devm_gpiod_get(dev, "hpd", GPIOD_IN);
> ...
> }
>
> This calls 'of_find_gpio()' and it generates the GPIO consumer ID by referring
> GPIO suffix. So 'hpd-gpios' is preferred on getting a GPIO descriptor.
>
> However, if the device tree uses 'hpd-gpio', then the exynos-hdmi driver
> always retries to get a GPIO descriptor because the first GPIO suffix is not
> 'gpio' but 'gpios'. So you always see the debug message below.
>
> of_get_named_gpiod_flags: can't parse 'hpd-gpios' property of node
> '/soc/hdmi@1453[0]'
>
> Use the preferred property, 'hpd-gpios' instead of 'hpd-gpio'.
>
> Acked-by: Rob Herring
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Cc: David Airlie
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Milo Kim
I am not sure if this long Cc list is necessary.
Anyway:
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
Re: [PATCH v2 1/4] ARM: dts: exynos: Enable HDMI for Arndale Octa board
Hi Milo,
On 08/24/2016 04:25 AM, Milo Kim wrote:
> * Support HDMI display data channel
> I2C #2 is assigned for the HDMI DDC. It enables the EDID access.
>
> * GPIO for HDMI hot plug detect
> GPX3_7 is used. The HPD awareness is done when the GPIO is active high and
> single ended.
>
> * Enable HDMI block in Exynos5420
> HDMI PLL consumes 1.0V LDO6 (PVDD_ANAIP_1V0) and HDMI oscillator requires
> 1.8V LDO7 (PVDD_ANAIP_1V8).
>
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Cc: David Airlie
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Cc: Rob Herring
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Milo Kim
> ---
> arch/arm/boot/dts/exynos5420-arndale-octa.dts | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> index 39a3b81..df362a2 100644
> --- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> +++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> @@ -70,6 +70,23 @@
> status = "disabled";
> };
>
> +&i2c_2 {
> + samsung,i2c-slave-addr = <0x50>;
> + status = "okay";
> +
> + hdmiddc@50 {
> + compatible = "samsung,exynos4210-hdmiddc";
> + reg = <0x50>;
> + };
> +};
> +
> +&hdmi {
> + hpd-gpios = <&gpx3 7 GPIO_OPEN_SOURCE>;
> + vdd_osc-supply = <&ldo7_reg>;
> + vdd_pll-supply = <&ldo6_reg>;
> + status = "okay";
Please use ddc property in hdmi node, instead of this legacy binding.
See exynos4210-universal_c210.dts or exynos4412-odroid-common.dtsi for
reference.
Regards
Andrzej
> +};
> +
> &hsi2c_4 {
> status = "okay";
>
Re: [PATCH v2 2/4] On Discard either do Reset WP or Write Same
On Mon, Aug 22, 2016 at 8:25 PM, Damien Le Moal wrote: > > Shaun, > > On 8/23/16 09:22, Shaun Tancheff wrote: >> On Mon, Aug 22, 2016 at 6:57 PM, Damien Le Moal >> wrote: >> Also you may note that in my patch to get Host Aware working >> with the zone cache I do not include the runt zone in the cache. > > Why not ? The RB-tree will handle it just fine (the insert and lookup > code as Hannes had them was not relying on a constant zone size). A good point. I didn't pay too much attention while brining this forward. I think a few of my hacks may be pointless now. I'll try to rework it and get rid of the runt check. >> So as it sits I need this fallback otherwise doing blkdiscard over >> the whole device ends in a error, as well as mkfs.f2fs et. al. > > Got it, but I do not see a problem with including it. I have not checked > the code, but the split of a big discard call into "chunks" should be > already handling the last chunk and make sure that the operation does > not exceed the device capacity (in any case, that's easy to fix in the > sd_zbc_setup_discard code). Yes I agree the split of big discards does handle the last chunk correctly. >>> Some 10TB host managed disks out there have 1% conventional zone space, >>> that is 100GB of capacity. When issuing a "reset all", doing a write >>> same in these zones will take forever... If the user really wants zeroes >>> in those zones, let it issue a zeroout. >>> >>> I think that it would a better choice to simply not report >>> discard_zeroes_data as true and do nothing for conventional zones reset. >> >> I think that would be unfortunate for Host Managed but I think it's >> the right choice for Host Aware at this time. So either we base >> it on disk type or we have some other config flag added to sysfs. > > I do not see any difference between host managed and host aware. Both > define the same behavior for reset, and both end up in a NOP for > conventional zone reset (no data "erasure" required by the standard). > For write pointer zones, reading unwritten LBAs returns the > initialization pattern, with the exception of host-managed disks with > the URSWRZ bit set to 0. But that case is covered in sd.c, so the > behavior is consistent across all models. So why forcing data zeroing > when the standards do not mandate it ? Well you do have point. It appears to be only mkfs and similar tools that are really utilizing discard zeros data at the moment. I did a quick test: mkfs -t ext4 -b 4096 -g 32768 -G 32 \ -E lazy_itable_init=0,lazy_journal_init=0,offset=0,num_backup_sb=0,packed_meta_blocks=1,discard \ -O flex_bg,extent,sparse_super2 - discard zeroes data true - 3 minutess - discard zeroes data false - 6 minutes So for the smaller conventional space on the current HA drive there is some advantage to enabling discard zeroes data. However for a larger conventional space you are correct the overall impact is worse performance. For some reason I had been assuming that some file systems used or relied on discard zeroes data during normal operation. Now that I am looking for that I don't seem to be finding any evidence of it, so aside from mkfs I don't have as good an argument discard zeroes data as I though I did. Regards, Shaun
Re: [PATCH v3] PM / sleep: enable suspend-to-idle even without registered suspend_ops
On 19 August 2016 at 08:41, Sudeep Holla wrote: > Suspend-to-idle (aka the "freeze" sleep state) is a system sleep state > in which all of the processors enter deepest possible idle state and > wait for interrupts right after suspending all the devices. > > There is no hard requirement for a platform to support and register > platform specific suspend_ops to enter suspend-to-idle/freeze state. > Only deeper system sleep states like PM_SUSPEND_STANDBY and > PM_SUSPEND_MEM rely on such low level support/implementation. > > suspend-to-idle can be entered as along as all the devices can be > suspended. This patch enables the support for suspend-to-idle even on > systems that don't have any low level support for deeper system sleep > states and/or don't register any platform specific suspend_ops. > > Cc: "Rafael J. Wysocki" > Signed-off-by: Sudeep Holla I tested this patch on the Qualcomm 410c platform. It worked like a charm. Thanks for working on this! Tested-by: Andy Gross
[v14 PATCH 4/5] Documentation: bindings: add dt documentation for cdn DP controller
This patch adds a binding that describes the cdn DP controller for
rk3399.
Signed-off-by: Chris Zhong
Acked-by: Rob Herring
Reviewed-by: Guenter Roeck
---
Changes in v14: None
Changes in v13:
- add dptx and apb reset
Changes in v12: None
Changes in v11:
- refer dp phy
Changes in v10:
- add pclk_vio_grf clock
Changes in v9:
- modify the reference phy = <&tcphy0 0>, <&tcphy1 0>;
Changes in v8: None
Changes in v7: None
Changes in v6:
- add assigned-clocks and assigned-clock-rates
- add power-domains
Changes in v5: None
Changes in v4:
- add a reset node
- support 2 phys
Changes in v3:
- add SoC specific compatible string
- remove reg = <1>;
Changes in v2: None
Changes in v1:
- add extcon node description
- add #sound-dai-cells description
.../bindings/display/rockchip/cdn-dp-rockchip.txt | 75 ++
1 file changed, 75 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt
diff --git
a/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt
new file mode 100644
index 000..9bd2c13
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt
@@ -0,0 +1,75 @@
+Rockchip RK3399 specific extensions to the cdn Display Port
+
+
+Required properties:
+- compatible: must be "rockchip,rk3399-cdn-dp"
+
+- reg: physical base address of the controller and length
+
+- clocks: from common clock binding: handle to dp clock.
+
+- clock-names: from common clock binding:
+ Required elements: "core-clk" "pclk" "spdif" "grf"
+
+- resets : a list of phandle + reset specifier pairs
+- reset-names : string reset name, must be:
+ "spdif", "dptx", "apb".
+- power-domains : power-domain property defined with a phandle
+ to respective power domain.
+- assigned-clocks: main clock, should be <&cru SCLK_DP_CORE>
+- assigned-clock-rates : the DP core clk frequency, shall be: 1
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+
+- ports: contain a port nodes with endpoint definitions as defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+contained 2 endpoints, connecting to the output of vop.
+
+- phys: from general PHY binding: the phandle for the PHY device.
+
+- extcon: extcon specifier for the Power Delivery
+
+- #sound-dai-cells = it must be 1 if your system is using 2 DAIs: I2S, SPDIF
+
+---
+
+Example:
+ cdn_dp: dp@fec0 {
+ compatible = "rockchip,rk3399-cdn-dp";
+ reg = <0x0 0xfec0 0x0 0x10>;
+ interrupts = ;
+ clocks = <&cru SCLK_DP_CORE>, <&cru PCLK_DP_CTRL>,
+<&cru SCLK_SPDIF_REC_DPTX>, <&cru PCLK_VIO_GRF>;
+ clock-names = "core-clk", "pclk", "spdif", "grf";
+ assigned-clocks = <&cru SCLK_DP_CORE>;
+ assigned-clock-rates = <1>;
+ power-domains = <&power RK3399_PD_HDCP>;
+ phys = <&tcphy0_dp>, <&tcphy1_dp>;
+ resets = <&cru SRST_DPTX_SPDIF_REC>, <&cru SRST_P_UPHY0_DPTX>,
+<&cru SRST_P_UPHY0_APB>;
+ reset-names = "spdif", "dptx", "apb";
+ extcon = <&fusb0>, <&fusb1>;
+ rockchip,grf = <&grf>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #sound-dai-cells = <1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dp_in: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ dp_in_vopb: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vopb_out_dp>;
+ };
+
+ dp_in_vopl: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&vopl_out_dp>;
+ };
+ };
+ };
+ };
--
1.9.1
[v14 PATCH 1/5] Documentation: bindings: add dt doc for Rockchip USB Type-C PHY
This patch adds a binding that describes the Rockchip USB Type-C PHY
for rk3399
Signed-off-by: Chris Zhong
Reviewed-by: Tomasz Figa
Reviewed-by: Kever Yang
Reviewed-by: Guenter Roeck
Acked-by: Rob Herring
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11:
- make a clearer emarcation between usb phy and dp phy
Changes in v10:
- remove rockchip,uphy-dp-sel property
Changes in v9:
- change #phy-cells to 1
Changes in v8: None
Changes in v7: None
Changes in v6:
- add assigned-clocks and assigned-clock-rates
Changes in v5: None
Changes in v4:
- add a #phy-cells node
Changes in v3:
- use compatible: rockchip,rk3399-typec-phy
- use dashes instead of underscores.
Changes in v2:
- add some registers description
Changes in v1:
- add extcon node description
- move the registers in phy driver
- remove the suffix of reset
.../devicetree/bindings/phy/phy-rockchip-typec.txt | 101 +
1 file changed, 101 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
new file mode 100644
index 000..6ea867e
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
@@ -0,0 +1,101 @@
+* ROCKCHIP type-c PHY
+-
+
+Required properties:
+ - compatible : must be "rockchip,rk3399-typec-phy"
+ - reg: Address and length of the usb phy control register set
+ - rockchip,grf : phandle to the syscon managing the "general
+ register files"
+ - clocks : phandle + clock specifier for the phy clocks
+ - clock-names : string, clock name, must be "tcpdcore", "tcpdphy-ref";
+ - assigned-clocks: main clock, should be <&cru SCLK_UPHY0_TCPDCORE> or
+ <&cru SCLK_UPHY1_TCPDCORE>;
+ - assigned-clock-rates : the phy core clk frequency, shall be: 5000
+ - resets : a list of phandle + reset specifier pairs
+ - reset-names : string reset name, must be:
+"uphy", "uphy-pipe", "uphy-tcphy"
+ - extcon : extcon specifier for the Power Delivery
+
+Note, there are 2 type-c phys for RK3399, and they are almost identical, except
+these registers(description below), every register node contains 3 sections:
+offset, enable bit, write mask bit.
+ - rockchip,typec-conn-dir : the register of type-c connector direction,
+ for type-c phy0, it must be <0xe580 0 16>;
+ for type-c phy1, it must be <0xe58c 0 16>;
+ - rockchip,usb3tousb2-en : the register of type-c force usb3 to usb2 enable
+ control.
+ for type-c phy0, it must be <0xe580 3 19>;
+ for type-c phy1, it must be <0xe58c 3 19>;
+ - rockchip,external-psm : the register of type-c phy external psm clock
+ selection.
+ for type-c phy0, it must be <0xe588 14 30>;
+ for type-c phy1, it must be <0xe594 14 30>;
+ - rockchip,pipe-status : the register of type-c phy pipe status.
+ for type-c phy0, it must be <0xe5c0 0 0>;
+ for type-c phy1, it must be <0xe5c0 16 16>;
+
+Required nodes : a sub-node is required for each port the phy provides.
+The sub-node name is used to identify dp or usb3 port,
+and shall be the following entries:
+ * "dp-port" : the name of DP port.
+ * "usb3-port" : the name of USB3 port.
+
+Required properties (port (child) node):
+- #phy-cells : must be 0, See ./phy-bindings.txt for details.
+
+Example:
+ tcphy0: phy@ff7c {
+ compatible = "rockchip,rk3399-typec-phy";
+ reg = <0x0 0xff7c 0x0 0x4>;
+ rockchip,grf = <&grf>;
+ extcon = <&fusb0>;
+ clocks = <&cru SCLK_UPHY0_TCPDCORE>,
+<&cru SCLK_UPHY0_TCPDPHY_REF>;
+ clock-names = "tcpdcore", "tcpdphy-ref";
+ assigned-clocks = <&cru SCLK_UPHY0_TCPDCORE>;
+ assigned-clock-rates = <5000>;
+ resets = <&cru SRST_UPHY0>,
+<&cru SRST_UPHY0_PIPE_L00>,
+<&cru SRST_P_UPHY0_TCPHY>;
+ reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
+ rockchip,typec-conn-dir = <0xe580 0 16>;
+ rockchip,usb3tousb2-en = <0xe580 3 19>;
+ rockchip,external-psm = <0xe588 14 30>;
+ rockchip,pipe-status = <0xe5c0 0 0>;
+
+ tcphy0_dp: dp-port {
+ #phy-cells = <0>;
+ };
+
+ tcphy0_usb3: usb3-port {
+ #phy-cells = <0>;
+ };
+ };
+
+ tcphy1: phy@ff80 {
+ compatible = "rockchip,rk3399-typec-phy";
+ reg = <0x0 0xff80 0x0 0x4>;
+ rockchip,grf = <&grf>;
+ extcon = <&fusb1>;
+ clocks = <&cru SCLK_UPHY1_TCPDCORE>,
+<&cru SCLK_UPHY1_TCPDPHY_REF>;
+ clock-names = "tcpdcore", "tcpdphy-ref";
+ as
[v14 PATCH 2/5] phy: Add USB Type-C PHY driver for rk3399
Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB Type-C PHY is designed to support the USB3 and DP applications. The USB3 operates in SuperSpeed mode and the DP can operate at RBR, HBR and HBR2 data rates. This driver create 2 PHY devices separately for USB3 and DisplyPort, and registers them under the child node. Signed-off-by: Chris Zhong Signed-off-by: Kever Yang Reviewed-by: Guenter Roeck Tested-by: Guenter Roeck --- Changes in v14: - change the name of property from super speed to EXTCON_PROP_USB_SS Changes in v13: - add some description in front of driver - change name of usb to usb3 - add a USB3 RX register configuration - do not return err if nothing connected with Type-C, when usb phy power on, since the USB core driver will call phy power without USB3 device connected. Changes in v12: - enable DP+USB3 mode, only when EXTCON_PROP_USB_SUPERSPEED equal 1 and DP is attached Changes in v11: - make a clearer demarcation between usb phy and dp phy. Changes in v10: - do not control dp select and hpd config in phy driver Changes in v9: - the new_mode should be int not u8 - move mutex_lock(&tcphy->lock); to earlier place. in rockchip_usb3_phy_power_off - better mutex lock for phy mode and flip - split the Type-C PHY into two PHYs: USB3 and DP Changes in v8: - set the default cable id to EXTCON_USB_HOST - optimization Error log Changes in v7: - support new API of extcon Changes in v6: - delete the support of PIN_ASSIGN_A/B - set the default mode to MODE_DFP_USB - disable DP PLL at USB3 only mode Changes in v5: - support get property from extcon - remove PIN ASSIGN A/B support Changes in v4: - select EXTCON - use phy framework to control the USB3 and DP function - rename PIN_MAP_ to PIN_ASSIGN_ Changes in v3: - remove the phy framework(Kishon Vijay Abraham I) - add parentheses around the macro - use a single space between type and name - add spaces after opening and before closing braces. - use u16 for register value - remove type-c phy header file - CodingStyle optimization - use some cable extcon to get type-c port information - add a extcon to notify Display Port Changes in v2: - select RESET_CONTROLLER - alphabetic order - modify some spelling mistakes - make mode cleaner - use bool for enable/disable - check all of the return value - return a better err number - use more readx_poll_timeout() - clk_disable_unprepare(tcphy->clk_ref); - remove unuse functions, rockchip_typec_phy_power_on/off - remove unnecessary typecast from void * - use dts node to distinguish between phys. Changes in v1: - update the licence note - init core clock to 50MHz - use extcon API - remove unused global - add some comments for magic num - change usleep_range(1000, 2000) tousleep_range(1000, 1050) - remove __func__ from dev_err - return err number when get clk failed - remove ADDR_ADJ define - use devm_clk_get(&pdev->dev, "tcpdcore") drivers/phy/Kconfig |9 + drivers/phy/Makefile |1 + drivers/phy/phy-rockchip-typec.c | 1013 ++ 3 files changed, 1023 insertions(+) create mode 100644 drivers/phy/phy-rockchip-typec.c diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 42f3e30..c775fd7 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -348,6 +348,15 @@ config PHY_ROCKCHIP_PCIE help Enable this to support the Rockchip PCIe PHY. +config PHY_ROCKCHIP_TYPEC + tristate "Rockchip TYPEC PHY Driver" + depends on OF && (ARCH_ROCKCHIP || COMPILE_TEST) + select EXTCON + select GENERIC_PHY + select RESET_CONTROLLER + help + Enable this to support the Rockchip USB TYPEC PHY. + config PHY_ST_SPEAR1310_MIPHY tristate "ST SPEAR1310-MIPHY driver" select GENERIC_PHY diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index fbb91e7..5d58b63 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -39,6 +39,7 @@ obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2) += phy-rockchip-inno-usb2.o obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o obj-$(CONFIG_PHY_ROCKCHIP_PCIE) += phy-rockchip-pcie.o obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o +obj-$(CONFIG_PHY_ROCKCHIP_TYPEC) += phy-rockchip-typec.o obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o diff --git a/drivers/phy/phy-rockchip-typec.c b/drivers/phy/phy-rockchip-typec.c new file mode 100644 index 000..fb58a27 --- /dev/null +++ b/drivers/phy/phy-rockchip-typec.c @@ -0,0 +1,1013 @@ +/* + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd + * Author: Chris Zhong + * Kever Yang + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is
[v14 PATCH 3/5] arm64: dts: rockchip: add Type-C phy for RK3399
There are 2 Type-C phy on RK3399, they are almost same, except the
address of register. They support USB3.0 Type-C and DisplayPort1.3
Alt Mode on USB Type-C. Register a phy, supply it to USB3 controller
and DP controller.
Signed-off-by: Chris Zhong
Reviewed-by: Guenter Roeck
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11:
- split the dp-phy and usb3-phy to 2 child-node
Changes in v10:
- remove rockchip,uphy-dp-sel property
Changes in v9:
- change #phy-cells to 1
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
Changes in v1: None
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 56
1 file changed, 56 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index a44eb67..23f7ae1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1060,6 +1060,62 @@
};
};
+ tcphy0: phy@ff7c {
+ compatible = "rockchip,rk3399-typec-phy";
+ reg = <0x0 0xff7c 0x0 0x4>;
+ rockchip,grf = <&grf>;
+ clocks = <&cru SCLK_UPHY0_TCPDCORE>,
+<&cru SCLK_UPHY0_TCPDPHY_REF>;
+ clock-names = "tcpdcore", "tcpdphy-ref";
+ assigned-clocks = <&cru SCLK_UPHY0_TCPDCORE>;
+ assigned-clock-rates = <5000>;
+ resets = <&cru SRST_UPHY0>,
+<&cru SRST_UPHY0_PIPE_L00>,
+<&cru SRST_P_UPHY0_TCPHY>;
+ reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
+ rockchip,typec-conn-dir = <0xe580 0 16>;
+ rockchip,usb3tousb2-en = <0xe580 3 19>;
+ rockchip,external-psm = <0xe588 14 30>;
+ rockchip,pipe-status = <0xe5c0 0 0>;
+ status = "disabled";
+
+ tcphy0_dp: dp-port {
+ #phy-cells = <0>;
+ };
+
+ tcphy0_usb3: usb3-port {
+ #phy-cells = <0>;
+ };
+ };
+
+ tcphy1: phy@ff80 {
+ compatible = "rockchip,rk3399-typec-phy";
+ reg = <0x0 0xff80 0x0 0x4>;
+ rockchip,grf = <&grf>;
+ clocks = <&cru SCLK_UPHY1_TCPDCORE>,
+<&cru SCLK_UPHY1_TCPDPHY_REF>;
+ clock-names = "tcpdcore", "tcpdphy-ref";
+ assigned-clocks = <&cru SCLK_UPHY1_TCPDCORE>;
+ assigned-clock-rates = <5000>;
+ resets = <&cru SRST_UPHY1>,
+<&cru SRST_UPHY1_PIPE_L00>,
+<&cru SRST_P_UPHY1_TCPHY>;
+ reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
+ rockchip,typec-conn-dir = <0xe58c 0 16>;
+ rockchip,usb3tousb2-en = <0xe58c 3 19>;
+ rockchip,external-psm = <0xe594 14 30>;
+ rockchip,pipe-status = <0xe5c0 16 16>;
+ status = "disabled";
+
+ tcphy1_dp: dp-port {
+ #phy-cells = <0>;
+ };
+
+ tcphy1_usb3: usb3-port {
+ #phy-cells = <0>;
+ };
+ };
+
watchdog@ff84 {
compatible = "snps,dw-wdt";
reg = <0x0 0xff84 0x0 0x100>;
--
1.9.1
[v14 PATCH 0/5] Rockchip Type-C and DisplayPort driver
Hi all This series patch is for rockchip Type-C phy and DisplayPort controller driver. The USB Type-C PHY is designed to support the USB3 and DP applications. The PHY basically has two main components: USB3 and DisplyPort. USB3 operates in SuperSpeed mode and the DP can operate at RBR, HBR and HBR2 data rates. The Type-C cable orientation detection and Power Delivery (PD) is accomplished using a PD PHY or a exernal PD chip. The DP controller is compliant with DisplayPort Specification, Version 1.3, This IP is compatible with the rockchip type-c PHY IP. There is a uCPU in DP controller, it need a firmware to work, please put the firmware file[0] rockchip/dptx.bin to /lib/firmware/rockchip/dptx.bin. The uCPU in charge of aux communication and link training, the host use mailbox to communicate with the ucpu. The DP contoller has register a notification with extcon API, to get the alt mode from PD, the PD driver need call the devm_extcon_dev_allocate to create a extcon device and use extcon_set_state to notify DP controller. And call extcon_set_cable_property to set orientation. About the DP audio, cdn-dp registered 2 DAIs: 0 is I2S, 1 is SPDIF. We can reference them in simple-card. This series is based on Mark Yao's branch[1], the extcon API backport from linux-next[2]. I test this patches on the rk3399-evb board, with a fusb302 driver, this branch has no rk3399.dtsi, so the patch about dts is not included in this series. >From V9, the Type-C PHY is split into two PHYs: DP and USB3. The PHY will be init, no matter which PHY be power_on. The DP module will enter A2 mode (standby mode) after phy_init, if DP PHY is powered on, the DP module will enter to A0 mode(running mode). Then if DP PHY is powered off, DP module will back to A2 mode. If everything is un-plugged, phy will be deinit. [0] kernel/git/firmware/linux-firmware.git [1] https://github.com/markyzq/kernel-drm-rockchip/tree/drm-rockchip-next-2016-05-23 [2] git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master Changes in v14: - change the name of property from super speed to EXTCON_PROP_USB_SS - change super speed property name to EXTCON_PROP_USB_SS - do a correct mode_valid check when bpc is 0 Changes in v13: - add some description in front of driver - change name of usb to usb3 - add a USB3 RX register configuration - do not return err if nothing connected with Type-C, when usb phy power on, since the USB core driver will call phy power without USB3 device connected. - add dptx and apb reset - support suspend/resume - switch power domain dynamically - re-training when hpd signal is triggered Changes in v12: - enable DP+USB3 mode, only when EXTCON_PROP_USB_SUPERSPEED equal 1 and DP is attached - use EXTCON_PROP_USB_SUPERSPEED to replace EXTCON_USB_HOST Changes in v11: - make a clearer emarcation between usb phy and dp phy - make a clearer demarcation between usb phy and dp phy. - split the dp-phy and usb3-phy to 2 child-node - refer dp phy - add best_encoder back, since it required by drm_atomic_helper_check Changes in v10: - remove rockchip,uphy-dp-sel property - do not control dp select and hpd config in phy driver - remove rockchip,uphy-dp-sel property - add pclk_vio_grf clock - remove best_encoder ops - support read sink count from DPCD - control the grf_clk in DP Changes in v9: - change #phy-cells to 1 - the new_mode should be int not u8 - move mutex_lock(&tcphy->lock); to earlier place. in rockchip_usb3_phy_power_off - better mutex lock for phy mode and flip - split the Type-C PHY into two PHYs: USB3 and DP - change #phy-cells to 1 - modify the reference phy = <&tcphy0 0>, <&tcphy1 0>; - do not need reset the phy before power_on - add a orientation information for set_capability - retry to read dpcd in 10 seconds Changes in v8: - set the default cable id to EXTCON_USB_HOST - optimization Error log - optimization the err log Changes in v7: - support new API of extcon - support firmware standby when no dptx connection - optimization the calculation of tu size and valid symbol Changes in v6: - add assigned-clocks and assigned-clock-rates - delete the support of PIN_ASSIGN_A/B - set the default mode to MODE_DFP_USB - disable DP PLL at USB3 only mode - add assigned-clocks and assigned-clock-rates - add power-domains - add a port struct - select SND_SOC_HDMI_CODEC - force reset the phy when hpd detected Changes in v5: - support get property from extcon - remove PIN ASSIGN A/B support - alphabetical order - do not use long, use u32 or u64 - return MODE_CLOCK_HIGH when requested > actual - Optimized Coding Style - add a formula to get better tu size and symbol value. - modify according to Sean Paul's comments - fixed the fw_wait always 0 Changes in v4: - add a #phy-cells node - select EXTCON - use phy framework to control the USB3 and DP function - rename PIN_MAP_ to PIN_ASSIGN_ - add a reset node - support 2 phys - use phy framework to control DP phy - support 2 phys Changes in v3: - use compatible: rockch
[v14 PATCH 5/5] drm/rockchip: cdn-dp: add cdn DP support for rk3399
Add support for cdn DP controller which is embedded in the rk3399 SoCs. The DP is compliant with DisplayPort Specification, Version 1.3, This IP is compatible with the rockchip type-c PHY IP. There is a uCPU in DP controller, it need a firmware to work, please put the firmware file to /lib/firmware/rockchip/dptx.bin. The uCPU in charge of aux communication and link training, the host use mailbox to communicate with the ucpu. The dclk pin_pol of vop must not be invert for DP. Signed-off-by: Chris Zhong Reviewed-by: Sean Paul Acked-by: Mark Yao --- Changes in v14: - change super speed property name to EXTCON_PROP_USB_SS - do a correct mode_valid check when bpc is 0 Changes in v13: - support suspend/resume - switch power domain dynamically - re-training when hpd signal is triggered Changes in v12: - use EXTCON_PROP_USB_SUPERSPEED to replace EXTCON_USB_HOST Changes in v11: - add best_encoder back, since it required by drm_atomic_helper_check Changes in v10: - remove best_encoder ops - support read sink count from DPCD - control the grf_clk in DP Changes in v9: - do not need reset the phy before power_on - add a orientation information for set_capability - retry to read dpcd in 10 seconds Changes in v8: - optimization the err log Changes in v7: - support firmware standby when no dptx connection - optimization the calculation of tu size and valid symbol Changes in v6: - add a port struct - select SND_SOC_HDMI_CODEC - force reset the phy when hpd detected Changes in v5: - alphabetical order - do not use long, use u32 or u64 - return MODE_CLOCK_HIGH when requested > actual - Optimized Coding Style - add a formula to get better tu size and symbol value. - modify according to Sean Paul's comments - fixed the fw_wait always 0 Changes in v4: - use phy framework to control DP phy - support 2 phys Changes in v3: - use EXTCON_DISP_DP and EXTCON_DISP_DP_ALT cable to get dp port state. - reset spdif before config it - modify the firmware clk to 100Mhz - retry load firmware if fw file is requested too early Changes in v2: - Alphabetic order - remove excess error message - use define clk_rate - check all return value - remove dev_set_name(dp->dev, "cdn-dp"); - use schedule_delayed_work - remove never-called functions - remove some unnecessary () Changes in v1: - use extcon API - use hdmi-codec for the DP Asoc - do not initialize the "ret" - printk a err log when drm_of_encoder_active_endpoint_id - modify the dclk pin_pol to a single line drivers/gpu/drm/rockchip/Kconfig| 10 + drivers/gpu/drm/rockchip/Makefile |1 + drivers/gpu/drm/rockchip/cdn-dp-core.c | 1067 +++ drivers/gpu/drm/rockchip/cdn-dp-core.h | 106 +++ drivers/gpu/drm/rockchip/cdn-dp-reg.c | 959 drivers/gpu/drm/rockchip/cdn-dp-reg.h | 482 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.h |9 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c |2 + 9 files changed, 2646 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig index d30bdc3..20aaafe 100644 --- a/drivers/gpu/drm/rockchip/Kconfig +++ b/drivers/gpu/drm/rockchip/Kconfig @@ -25,6 +25,16 @@ config ROCKCHIP_ANALOGIX_DP for the Analogix Core DP driver. If you want to enable DP on RK3288 based SoC, you should selet this option. +config ROCKCHIP_CDN_DP +tristate "Rockchip cdn DP" +depends on DRM_ROCKCHIP + select SND_SOC_HDMI_CODEC if SND_SOC +help + This selects support for Rockchip SoC specific extensions + for the cdn DP driver. If you want to enable Dp on + RK3399 based SoC, you should select this + option. + config ROCKCHIP_DW_HDMI tristate "Rockchip specific extensions for Synopsys DW HDMI" depends on DRM_ROCKCHIP diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile index 9746365..6a07809 100644 --- a/drivers/gpu/drm/rockchip/Makefile +++ b/drivers/gpu/drm/rockchip/Makefile @@ -7,6 +7,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \ rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o +obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c new file mode 100644 index 000..f8bdfd1 --- /dev/null +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c @@ -0,0 +1,1067 @@ +/
Re: [PATCH 2/8] staging/lustre/mdc: fix panic at mdc_free_open()
Actually, please do not apply this one, there was a testing error
that made me not noticing there's a bug in this one that insta-crashes
everything on access.
I tested the rest nd the rest are good without this one too.
Sorry about this.
On Aug 23, 2016, at 5:11 PM, Oleg Drokin wrote:
> From: Alexander Boyko
>
> Assertion was happened for open request when rq_replay is set
> to 1.
>ASSERTION(mod->mod_open_req->rq_replay == 0)
> But this situation is not fatal for client, and could happened
> when mdc_close() failed.
> The fix allow to free such requests. If mdc_close fail, MDS doesn`t
> receive close request from client. And in a worst case client would
> be evicted.
>
> The test recreates issue when mdc_close failed and
> client asserts:
> ASSERTION( mod->mod_open_req->rq_replay == 0 ) failed
>
> Signed-off-by: Alexander Boyko
> Seagate-bug-id: MRP-3156
> Reviewed-on: http://review.whamcloud.com/17495
> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5282
> Reviewed-by: Alex Zhuravlev
> Reviewed-by: Andreas Dilger
> Signed-off-by: Oleg Drokin
> ---
> .../staging/lustre/lustre/include/obd_support.h| 1 +
> drivers/staging/lustre/lustre/mdc/mdc_request.c| 50 ++
> 2 files changed, 32 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/staging/lustre/lustre/include/obd_support.h
> b/drivers/staging/lustre/lustre/include/obd_support.h
> index 0c29a33..4a9fe88 100644
> --- a/drivers/staging/lustre/lustre/include/obd_support.h
> +++ b/drivers/staging/lustre/lustre/include/obd_support.h
> @@ -402,6 +402,7 @@ extern char obd_jobid_var[];
> #define OBD_FAIL_MDC_GETATTR_ENQUEUE 0x803
> #define OBD_FAIL_MDC_RPCS_SEM 0x804
> #define OBD_FAIL_MDC_LIGHTWEIGHT 0x805
> +#define OBD_FAIL_MDC_CLOSE0x806
>
> #define OBD_FAIL_MGS 0x900
> #define OBD_FAIL_MGS_ALL_REQUEST_NET 0x901
> diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c
> b/drivers/staging/lustre/lustre/mdc/mdc_request.c
> index 91c0b45..8369afd 100644
> --- a/drivers/staging/lustre/lustre/mdc/mdc_request.c
> +++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c
> @@ -677,9 +677,15 @@ static void mdc_free_open(struct md_open_data *mod)
> imp_connect_disp_stripe(mod->mod_open_req->rq_import))
> committed = 1;
>
> - LASSERT(mod->mod_open_req->rq_replay == 0);
> -
> - DEBUG_REQ(D_RPCTRACE, mod->mod_open_req, "free open request\n");
> + /*
> + * No reason to asssert here if the open request has
> + * rq_replay == 1. It means that mdc_close failed, and
> + * close request wasn`t sent. It is not fatal to client.
> + * The worst thing is eviction if the client gets open lock
> + */
> + DEBUG_REQ(D_RPCTRACE, mod->mod_open_req,
> + "free open request rq_replay = %d\n",
> +mod->mod_open_req->rq_replay);
>
> ptlrpc_request_committed(mod->mod_open_req, committed);
> if (mod->mod_close_req)
> @@ -749,22 +755,10 @@ static int mdc_close(struct obd_export *exp, struct
> md_op_data *op_data,
> }
>
> *request = NULL;
> - req = ptlrpc_request_alloc(class_exp2cliimp(exp), req_fmt);
> - if (!req)
> - return -ENOMEM;
> -
> - rc = ptlrpc_request_pack(req, LUSTRE_MDS_VERSION, MDS_CLOSE);
> - if (rc) {
> - ptlrpc_request_free(req);
> - return rc;
> - }
> -
> - /* To avoid a livelock (bug 7034), we need to send CLOSE RPCs to a
> - * portal whose threads are not taking any DLM locks and are therefore
> - * always progressing
> - */
> - req->rq_request_portal = MDS_READPAGE_PORTAL;
> - ptlrpc_at_set_req_timeout(req);
> + if (OBD_FAIL_CHECK(OBD_FAIL_MDC_CLOSE))
> + req = NULL;
> + else
> + req = ptlrpc_request_alloc(class_exp2cliimp(exp), req_fmt);
>
> /* Ensure that this close's handle is fixed up during replay. */
> if (likely(mod)) {
> @@ -785,6 +779,23 @@ static int mdc_close(struct obd_export *exp, struct
> md_op_data *op_data,
>CDEBUG(D_HA,
> "couldn't find open req; expecting close error\n");
> }
> + if (!req) {
> + /*
> + * TODO: repeat close after errors
> + */
> + CWARN("%s: close of FID "DFID" failed, file reference will be
> dropped when this client unmounts or is evicted\n",
> + obd->obd_name, PFID(&op_data->op_fid1));
> + rc = -ENOMEM;
> + goto out;
> + }
> +
> + /*
> + * To avoid a livelock (bug 7034), we need to send CLOSE RPCs to a
> + * portal whose threads are not taking any DLM locks and are therefore
> + * always progressing
> + */
> + req->rq_request_portal = MDS_READPAGE_PORTAL;
> + ptlrpc_at_set_req_timeout(req);
>
> mdc_close_pack(req, op_data);
>
> @@ -830,6 +841,7 @@ static int mdc_close(struct obd_export *exp, struct
>
Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus
On 08/22/16 at 09:14am, "Zhou, Wenjian/周文剑" wrote: > On 08/19/2016 11:57 PM, Jonathan Corbet wrote: > >On Fri, 19 Aug 2016 08:33:21 +0800 > >"Zhou, Wenjian/周文剑" wrote: > > > >>I was also confused by maxcpus and nr_cpus before writing this patch. > >>I think it is a good choice to describe it in kernel-parameters.txt. > >> > >>Then, only two things need to be done I think. > >>One is move the above description to maxcpus= in kernel-parameters.txt. > >>And the other is replace maxcpus with maxcpus/nr_cpus in kdump.txt. > >> > >>How do you think? > > > >That is not quite what I had in mind, sorry. What I would really like to > >see in kernel-parameters.txt is an explanation of how those two parameters > >differ - what do they do differently and how should a user choose one over > >the other? What we have now offers no guidance in that matter. > > > > I thought about it. I think user may not need this. > What user really want to know is how to choose. > And it is also not a hard work. If nr_cpus is not supported by the ARCH, use > maxcpus. > Otherwise, nr_cpus. The reason why maxcpus still exists is nr_cpus can't be > supported > by some ARCHes. I think Jon is suggesting that a note can be added into kernel-parameter.txt to tell what's the difference between nr_cpus and max_cpus. I checked code and discussed within our kdump team, max_cpus is used to limit how many 'present' cpus are allowed to be brought up during system bootup, while nr_cpus is used to set the upper limit of 'possible' cpus. E.g on my laptop, there are 4 cpus while 4 hotplug cpus, altogether 8 possible cpus. Possible cpus slot is for cpu hot plug, means during bootup you want to bring up 4 present cpus, but later you could physically hot plug 4 others. Because of attribute of some static percpu variables, we need pre-allocate memory for all possible cpus though some of them may not be really used if no extra cpu physically hot plugged after system bootup. Hence for kdump kernel, people never want to do a cpu hot plug in there. That's why we want to use nr_cpus to limit the number of possible cpu to save memory. E.g still on my laptop, if I want to do a kdump, the number of possible cpu is still 8, but you may want to use only 1 cpu to dump, maybe 2 or 3 for parallel dumping. But you absolutely don't want to set nr_cpus=8 in your kdump kernel cmdline, though it doesn't cause failure, memory is wasted because of percpu pre-allocation. So specifying nr_cpus=1 is much better. While with specifying max_cpus=1, the number of possible cpu is still 8. That's the reason. On x86_64 and s390, there's another kernel para "possible_cpus=xx" which can be used to set possible cpus for cpu hot plug. Only when "possible_cpus=0" is specified, smp is disabled. I am not very sure why this is introduced, number of possible cpu is decided by the min value of nr_cpus= and possible_cpus=. nr_cpus and maxcpus might not be very clear to people which are described in Documentation/kernel-parameters.txt. Hi Jon, do you think change as below is OK to you? >From 8b940193a29acf0857d4975d77f4b9f48e2d6cb8 Mon Sep 17 00:00:00 2001 From: Baoquan He Date: Wed, 24 Aug 2016 11:14:34 +0800 Subject: [PATCH] docs: kernel-parameter : Improve the description of nr_cpus and maxcpus >From the old description people still can't get what's the exact difference between nr_cpus and maxcpus. Especially in kdump kernel nr_cpus is always suggested if it's implemented in the ARCH. The reason is nr_cpus is used to limit the max number of possible cpu in system, the sum of already plugged cpus and hot plug cpus can't exceed its value. However maxcpus is used to limit how many cpus are allowed to be brought up during bootup. Signed-off-by: Baoquan He --- Documentation/kernel-parameters.txt | 20 +--- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 46c030a..25d3b36 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2161,10 +2161,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted. than or equal to this physical address is ignored. maxcpus=[SMP] Maximum number of processors that an SMP kernel - should make use of. maxcpus=n : n >= 0 limits the - kernel to using 'n' processors. n=0 is a special case, - it is equivalent to "nosmp", which also disables - the IO APIC. + will bring up during bootup. maxcpus=n : n >= 0 limits + the kernel to bring up 'n' processors. Surely after + bootup you can bring up the other plugged cpu by executing + "echo 1 > /sys/devices/system/cpu/cpuX/online". So maxcpus + only takes effect during system bootup. + While
[PATCH v2] serial: vt8500_serial: Fix a parameter of find_first_zero_bit.
The 2nd parameter of 'find_first_zero_bit' is the number of bits to search.
In this case, we are passing 'sizeof(vt8500_ports_in_use)'.
'vt8500_ports_in_use' is an 'unsigned long'. So the sizeof is likely to
return 4 on a 32 bits kernel.
A few lines below, we check if it is below VT8500_MAX_PORTS, which is 6.
It is likely that the number of bits in a long was expected here.
In order to fix it:
- use DECLARE_BITMAP when declaring the vt8500_ports_in_use
- use VT8500_MAX_PORTS as a maximum value when checking/setting bits in
this bitmap
- modify code now that 'vt8500_ports_in_use' has become a pointer
because of the use of DECLARE_BITMAP
It has been spotted by the following coccinelle script:
@@
expression ret, x;
@@
* ret = \(find_first_bit \| find_first_zero_bit\) (x, sizeof(...));
Signed-off-by: Christophe JAILLET
---
v2: - use of VT8500_MAX_PORTS instead of BITS_PER_LONG to better self
document the code
- declare vt8500_ports_in_use with DECLARE_BITMAP in order to self
document even better and to be foolproof should VT8500_MAX_PORTS
be changed one day
---
drivers/tty/serial/vt8500_serial.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/vt8500_serial.c
b/drivers/tty/serial/vt8500_serial.c
index 23cfc5e16b45..6b85adce0ac9 100644
--- a/drivers/tty/serial/vt8500_serial.c
+++ b/drivers/tty/serial/vt8500_serial.c
@@ -118,7 +118,7 @@ struct vt8500_port {
* have been allocated as we can't use pdev->id in
* devicetree
*/
-static unsigned long vt8500_ports_in_use;
+static DECLARE_BITMAP(vt8500_ports_in_use, VT8500_MAX_PORTS);
static inline void vt8500_write(struct uart_port *port, unsigned int val,
unsigned int off)
@@ -663,15 +663,15 @@ static int vt8500_serial_probe(struct platform_device
*pdev)
if (port < 0) {
/* calculate the port id */
- port = find_first_zero_bit(&vt8500_ports_in_use,
- sizeof(vt8500_ports_in_use));
+ port = find_first_zero_bit(vt8500_ports_in_use,
+ VT8500_MAX_PORTS);
}
if (port >= VT8500_MAX_PORTS)
return -ENODEV;
/* reserve the port id */
- if (test_and_set_bit(port, &vt8500_ports_in_use)) {
+ if (test_and_set_bit(port, vt8500_ports_in_use)) {
/* port already in use - shouldn't really happen */
return -EBUSY;
}
--
2.7.4
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus
Re: [v13.1 PATCH 2/5] phy: Add USB Type-C PHY driver for rk3399
Hi Chanwoo On 08/23/2016 01:44 PM, Chanwoo Choi wrote: Hi Chris, The name of 'SuperSpeed' property is changed from EXTCON_PROP_USB_SUPERSPEED to EXTCON_PROP_USB_SS. The name change was discussed on mail thread[1]. Oh, since I was using the old name in my local kernel, I will change it in V14. Thanks. Also, this driver depend on the extcon git repository. So, I created the immutable branch(ib-extcon-phy-4.9)[2] for phy framework to prevent the build error before merging the Linus git repository. [1] https://lkml.org/lkml/2016/8/17/622 [2] git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git ib-extcon-phy-4.9 Regards, Chanwoo Choi On 2016년 08월 23일 14:02, Chris Zhong wrote: Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB Type-C PHY is designed to support the USB3 and DP applications. The USB3 operates in SuperSpeed mode and the DP can operate at RBR, HBR and HBR2 data rates. This driver create 2 PHY devices separately for USB3 and DisplyPort, and registers them under the child node. Signed-off-by: Chris Zhong Signed-off-by: Kever Yang Reviewed-by: Guenter Roeck Tested-by: Guenter Roeck --- Changes in v13.1: - add some description in front of driver - change name of usb to usb3 - add a USB3 RX register configuration Changes in v13: - do not return err if nothing connected with Type-C, when usb phy power on, since the USB core driver will call phy power without USB3 device connected. Changes in v12: - enable DP+USB3 mode, only when EXTCON_PROP_USB_SUPERSPEED equal 1 and DP is attached Changes in v11: - make a clearer demarcation between usb phy and dp phy. Changes in v10: - do not control dp select and hpd config in phy driver Changes in v9: - the new_mode should be int not u8 - move mutex_lock(&tcphy->lock); to earlier place. in rockchip_usb3_phy_power_off - better mutex lock for phy mode and flip - split the Type-C PHY into two PHYs: USB3 and DP Changes in v8: - set the default cable id to EXTCON_USB_HOST - optimization Error log Changes in v7: - support new API of extcon Changes in v6: - delete the support of PIN_ASSIGN_A/B - set the default mode to MODE_DFP_USB - disable DP PLL at USB3 only mode Changes in v5: - support get property from extcon - remove PIN ASSIGN A/B support Changes in v4: - select EXTCON - use phy framework to control the USB3 and DP function - rename PIN_MAP_ to PIN_ASSIGN_ Changes in v3: - remove the phy framework(Kishon Vijay Abraham I) - add parentheses around the macro - use a single space between type and name - add spaces after opening and before closing braces. - use u16 for register value - remove type-c phy header file - CodingStyle optimization - use some cable extcon to get type-c port information - add a extcon to notify Display Port Changes in v2: - select RESET_CONTROLLER - alphabetic order - modify some spelling mistakes - make mode cleaner - use bool for enable/disable - check all of the return value - return a better err number - use more readx_poll_timeout() - clk_disable_unprepare(tcphy->clk_ref); - remove unuse functions, rockchip_typec_phy_power_on/off - remove unnecessary typecast from void * - use dts node to distinguish between phys. Changes in v1: - update the licence note - init core clock to 50MHz - use extcon API - remove unused global - add some comments for magic num - change usleep_range(1000, 2000) tousleep_range(1000, 1050) - remove __func__ from dev_err - return err number when get clk failed - remove ADDR_ADJ define - use devm_clk_get(&pdev->dev, "tcpdcore") drivers/phy/Kconfig |9 + drivers/phy/Makefile |1 + drivers/phy/phy-rockchip-typec.c | 1013 ++ 3 files changed, 1023 insertions(+) create mode 100644 drivers/phy/phy-rockchip-typec.c diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 42f3e30..c775fd7 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -348,6 +348,15 @@ config PHY_ROCKCHIP_PCIE help Enable this to support the Rockchip PCIe PHY. +config PHY_ROCKCHIP_TYPEC + tristate "Rockchip TYPEC PHY Driver" + depends on OF && (ARCH_ROCKCHIP || COMPILE_TEST) + select EXTCON + select GENERIC_PHY + select RESET_CONTROLLER + help + Enable this to support the Rockchip USB TYPEC PHY. + config PHY_ST_SPEAR1310_MIPHY tristate "ST SPEAR1310-MIPHY driver" select GENERIC_PHY diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index fbb91e7..5d58b63 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -39,6 +39,7 @@ obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2) += phy-rockchip-inno-usb2.o obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o obj-$(CONFIG_PHY_ROCKCHIP_PCIE) += phy-rockchip-pcie.o obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o +obj-$(CONFIG_PHY_ROCKCHIP_TYPEC) += phy-rockchip-typec.o obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA) += phy-qcom-ipq806x-sata.o obj-$(CONFIG_P
Re: [PATCH v2 1/2] cpufreq / sched: Pass flags to cpufreq_update_util()
On Mon, Aug 22, 2016 at 07:30:36PM +0200, Rafael J. Wysocki wrote: > On Saturday, August 20, 2016 05:40:49 PM Krzysztof Kozlowski wrote: > > On Sat, Aug 20, 2016 at 03:08:01AM +0200, Rafael J. Wysocki wrote: > > > On Friday, August 19, 2016 03:26:21 PM Krzysztof Kozlowski wrote: > > > > On Fri, Aug 12, 2016 at 2:04 AM, Rafael J. Wysocki > > > > wrote: > > > > > From: Rafael J. Wysocki > > > > > > > > > > It is useful to know the reason why cpufreq_update_util() has just > > > > > been called and that can be passed as flags to cpufreq_update_util() > > > > > and to the ->func() callback in struct update_util_data. However, > > > > > doing that in addition to passing the util and max arguments they > > > > > already take would be clumsy, so avoid it. > > > > > > > > > > Instead, use the observation that the schedutil governor is part > > > > > of the scheduler proper, so it can access scheduler data directly. > > > > > This allows the util and max arguments of cpufreq_update_util() > > > > > and the ->func() callback in struct update_util_data to be replaced > > > > > with a flags one, but schedutil has to be modified to follow. > > > > > > > > > > Thus make the schedutil governor obtain the CFS utilization > > > > > information from the scheduler and use the "RT" and "DL" flags > > > > > instead of the special utilization value of ULONG_MAX to track > > > > > updates from the RT and DL sched classes. Make it non-modular > > > > > too to avoid having to export scheduler variables to modules at > > > > > large. > > > > > > > > > > Next, update all of the other users of cpufreq_update_util() > > > > > and the ->func() callback in struct update_util_data accordingly. > > > > > > > > > > Suggested-by: Peter Zijlstra > > > > > Signed-off-by: Rafael J. Wysocki > > > > > --- > > > > > > > > > > v1 -> v2: Do not check cpu_of(rq) against smp_processor_id() in > > > > > cfs_rq_util_change(). > > > > > > > > > > --- > > > > > drivers/cpufreq/Kconfig|5 -- > > > > > drivers/cpufreq/cpufreq_governor.c |2 - > > > > > drivers/cpufreq/intel_pstate.c |2 - > > > > > include/linux/sched.h | 12 -- > > > > > kernel/sched/cpufreq.c |2 - > > > > > kernel/sched/cpufreq_schedutil.c | 67 > > > > > - > > > > > kernel/sched/deadline.c|4 +- > > > > > kernel/sched/fair.c| 10 + > > > > > kernel/sched/rt.c |4 +- > > > > > kernel/sched/sched.h | 31 + > > > > > 10 files changed, 66 insertions(+), 73 deletions(-) > > > > > > > > (...) > > > > > > > > > --- linux-pm.orig/drivers/cpufreq/Kconfig > > > > > +++ linux-pm/drivers/cpufreq/Kconfig > > > > > @@ -194,7 +194,7 @@ config CPU_FREQ_GOV_CONSERVATIVE > > > > > If in doubt, say N. > > > > > > > > > > config CPU_FREQ_GOV_SCHEDUTIL > > > > > - tristate "'schedutil' cpufreq policy governor" > > > > > + bool "'schedutil' cpufreq policy governor" > > > > > > > > If you change such symbols please remember to update also all the > > > > defconfigs. Without the update they start to show errors. > > > > > > Are there defconfigs that use this particular one? > > > > Yes, ARM/multi_v7 and exynos were using this as module. Javier sent a > > patch for that and should be switched to builtin in upcoming next [1]. > > > > If you would like to base on top of that, let me know, so I would > > prepare a tag. > > I wouldn't like to rebase, but I can pull that branch depending on how > much more material there is on it. Not much, I put only the fix m->y on a separate branch. Anyway if you need it, here it is: The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc: Linux 4.8-rc1 (2016-08-07 18:18:00 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-defconfig-schedutil-4.9 for you to fetch changes up to 08023fb9cec03ee2992df51fa728c3f14a1ba0ea: ARM: multi_v7_defconfig: Don't attempt to enable schedutil governor as module (2016-08-19 17:50:13 +0200) The schedutil cpufreq governor will be switched from tristate to bool. Fix defconfigs. Javier Martinez Canillas (2): ARM: exynos_defconfig: Don't attempt to enable schedutil governor as module ARM: multi_v7_defconfig: Don't attempt to enable schedutil governor as module arch/arm/configs/exynos_defconfig | 2 +- arch/arm/configs/multi_v7_defconfig | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
Re: [PATCH] memremap: Fix NULL pointer BUG in get_zone_device_page()
On Tue, Aug 23, 2016 at 9:28 PM, Kani, Toshimitsu wrote:
>> On Tue, Aug 23, 2016 at 7:53 PM, Dan Williams
>> wrote:
>> > On Tue, Aug 23, 2016 at 6:29 PM, Kani, Toshimitsu
>> wrote:
>> >>> On Tue, Aug 23, 2016 at 4:47 PM, Kani, Toshimitsu
>>
>> >>> wrote:
> :
>> >>
>> >> crash> p {struct vmem_altmap} 0x88046d045410
>> >> $6 = {
>> >> base_pfn = 0x48,
>> >> reserve = 0x2,// PHYS_PFN(SZ_8K)
>> >> free = 0x101fe,
>> >> align = 0x1fe,
>> >> alloc = 0x1
>> >> }
>> >
>> > Ah, so, on second look the 0x49020 data offset looks correct. The
>> > total size of the address range is 16GB which equates to 256MB needed
>> > for struct page, plus 2MB more to re-align the data on the next 2MB
>> > boundary.
>> >
>> > The question now is why is the guest faulting on an access to an
>> > address less than 0x49020?
>>
>> Does the attached patch fix this for you?
>
> Yeah, that makes sense. I will test it tomorrow.
>
> BTW, why does devm_memremap_pages() put a whole range to pgmap_radix
> as device memory, but only initialize page->pgmap for its data range? Is
> there
> particular reason for this inconsistency?
>
The radix tree is indexed by section number, but we don't always
initialize a full section. The cases when we don't use a full section
is when it overlaps device metadata, or if a platform multiplexes the
device memory range with another resource within the same section.
Re: [Patch v8] driver/clk/clk-si5338: Add common clock framework driver for si5338
On 08/24, kbuild test robot wrote:
>
> 2827if (drv_type < 0)
> 2828return drv_type;
> 2829
> 2830drv_vdd = get_drv_vdd(drvdata, i);
> 2831if (drv_vdd < 0)
> 2832return drv_vdd;
> 2833
> 2834drv_trim = get_drv_trim(drvdata, i);
> 2835if (drv_trim < 0)
> 2836return drv_trim;
> 2837
> 2838drv_invert = get_drv_invert(drvdata, i);
> 2839if (drv_invert < 0)
> 2840return drv_invert;
> 2841
> 2842for (j = 0; drv_configs[j].description; j++) {
> > 2843if (drv_configs[j].fmt == drv_type &&
> 2844drv_configs[j].vdd == drv_vdd &&
> 2845drv_configs[j].trim == drv_trim &&
> 2846(drv_invert | (drv_configs[j].invert >> 2))
> ==
> 2847((drv_configs[j].invert & 3) |
> 2848 (drv_configs[j].invert>>2)))
It might be better to write it as a set of continues instead so
that it isn't one complicated conditional
config = &drv_configs[j];
if (config->fmt != drv_type)
continue;
if (config->vdd != drv_vdd)
continue;
...
seq_puts()
match = 1;
break;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 1/2] clk: samsung: exynos5260: Move struct samsung_cmu_info to init section
On 08/23, Sylwester Nawrocki wrote: > On 08/23/2016 04:35 AM, Chanwoo Choi wrote: > I checked stripped object files and it seems with the patch there > is some saving of the kernel image size. Exactly 784 bytes, which > makes zImage smaller by 480 bytes. > > The patch increases .init.rodata section size by 780 bytes but > decreases .init.text section size by 1564 bytes. Looks like > a static initializer is cheaper. > > $ ls -l drivers/clk/samsung/clk-exynos5260.o > > < -rw-rw-r-- 1 snawrocki snawrocki 29100 Aug 23 11:35 > drivers/clk/samsung/clk-exynos5260.o > --- > > -rw-rw-r-- 1 snawrocki snawrocki 28316 Aug 23 11:32 > > drivers/clk/samsung/clk-exynos5260.o > > > The section size differences are as below: > 15c15 > < 3 .init.text06b8 0034 2**2 > --- > > 3 .init.text009c 0034 2**2 > 25c25 > < 8 .init.rodata 3f6c 2f20 2**2 > --- > > 8 .init.rodata 4278 2904 2**2 > > So the saving is rather insignificant but the patch doesn't make > things worse and I'd say it might be worth applying. > Sounds good. This sort of information should be in the commit text though. Talking about const doesn't make any sense to me. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
linux-next: Tree for Aug 24
Hi all, Changes since 20160823: The drm-intel tree lost its build failure but gained conflicts against the drm-intel-fixes tree. The kbuild tree still had its build warnings for PowerPC, for which I reverted a commit. The sound-asoc tree lost its build failure. Non-merge commits (relative to Linus' tree): 3442 3439 files changed, 154545 insertions(+), 61198 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 240 trees (counting Linus' and 34 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (7a1dcf6adaa7 Merge tag 'usercopy-v4.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux) Merging fixes/master (d3396e1e4ec4 Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc) Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when not configured) Merging arc-current/for-curr (c57653dc94d0 ARC: export __udivdi3 for modules) Merging arm-current/fixes (87eed3c74d7c ARM: fix address limit restoration for undefined instructions) Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs for v4.7-rc2) Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init()) Merging powerpc-fixes/fixes (ca49e64f0cb1 selftests/powerpc: Specify we expect to build with std=gnu99) Merging sparc/master (4620a06e4b3c shmem: Fix link error if huge pages support is disabled) Merging net/master (28a10c426e81 net sched: fix encoding to use real length) Merging ipsec/master (11d7a0bb95ea xfrm: Only add l3mdev oif to dst lookups) Merging netfilter/master (b75911b66ad5 netfilter: cttimeout: fix use after free error when delete netns) Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes') Merging wireless-drivers/master (c81396f3da22 mwifiex: fix large amsdu packets causing firmware hang) Merging mac80211/master (4d0bd46a4d55 Revert "wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel") Merging sound-current/for-linus (b027d1126383 ALSA: line6: Fix POD sysfs attributes segfault) Merging pci-current/for-linus (21c80c9fefc3 x86/PCI: VMD: Fix infinite loop executing irq's) Merging driver-core.current/driver-core-linus (694d0d0bb203 Linux 4.8-rc2) Merging tty.current/tty-linus (87a713c8ffca 8250/fintek: rename IRQ_MODE macro) Merging usb.current/usb-linus (53e5f36fbd24 USB: avoid left shift by -1) Merging usb-gadget-fixes/fixes (a0ad85ae866f usb: dwc3: gadget: stop processing on HWO set) Merging usb-serial-fixes/usb-linus (6695593e4a76 USB: serial: option: add WeTelecom WM-D200) Merging usb-chipidea-fixes/ci-for-usb-stable (c4e94174983a usb: chipidea: udc: don't touch DP when controller is in host mode) Merging staging.current/staging-linus (eafe5cfe7189 Merge tag 'iio-fixes-for-4.8a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into work-linus) Merging char-misc.current/char-misc-linus (51c70261b257 Revert "android: binder: fix dangling pointer comparison") Merging input-current/for-linus (e3a888a4bff0 Input: ads7846 - remove redundant regulator_disable call) Merging crypto-current/master (e67479b13ede crypto: sha512-mb - fix ctx pointer) Merging ide/master (797cee982eef Merge branch 'stable-4.8' of git://git.infradead.org/users/pcmoore/audit) Merg
RE: [PATCH] memremap: Fix NULL pointer BUG in get_zone_device_page()
> On Tue, Aug 23, 2016 at 7:53 PM, Dan Williams
> wrote:
> > On Tue, Aug 23, 2016 at 6:29 PM, Kani, Toshimitsu
> wrote:
> >>> On Tue, Aug 23, 2016 at 4:47 PM, Kani, Toshimitsu
>
> >>> wrote:
:
> >>
> >> crash> p {struct vmem_altmap} 0x88046d045410
> >> $6 = {
> >> base_pfn = 0x48,
> >> reserve = 0x2,// PHYS_PFN(SZ_8K)
> >> free = 0x101fe,
> >> align = 0x1fe,
> >> alloc = 0x1
> >> }
> >
> > Ah, so, on second look the 0x49020 data offset looks correct. The
> > total size of the address range is 16GB which equates to 256MB needed
> > for struct page, plus 2MB more to re-align the data on the next 2MB
> > boundary.
> >
> > The question now is why is the guest faulting on an access to an
> > address less than 0x49020?
>
> Does the attached patch fix this for you?
Yeah, that makes sense. I will test it tomorrow.
BTW, why does devm_memremap_pages() put a whole range to pgmap_radix
as device memory, but only initialize page->pgmap for its data range? Is there
particular reason for this inconsistency?
Thanks,
-Toshi
linux-next: taking a break
Hi all, I will not be producing a linux-next release this Friday or next week. So the next release after tomorrow will be next-20160905. -- Cheers, Stephen Rothwell
Re: [RFC PATCH-tip v4 10/10] locking/rwsem: Add a boot parameter to reader spinning threshold
On Thu, 18 Aug 2016, Waiman Long wrote: The default reader spining threshold is current set to 4096. However, the right reader spinning threshold may vary from one system to another and among the different architectures. This patch adds a new kernel boot parameter to modify the threshold value. This enables better tailoring to the needs of different systems as well as for testing purposes. It also means that those systems could very easily be incorrectly tailored. (and worse case scenario: reboot, is obviously a terrible way to get rid of any issues). I very much disagree with exposing this sort of core stuff, it should work well for everyone out of the box, not relying on users to properly configure this. Thanks, Davidlohr
Re: [PATCH] memremap: Fix NULL pointer BUG in get_zone_device_page()
On Tue, Aug 23, 2016 at 7:53 PM, Dan Williams wrote:
> On Tue, Aug 23, 2016 at 6:29 PM, Kani, Toshimitsu wrote:
>>> On Tue, Aug 23, 2016 at 4:47 PM, Kani, Toshimitsu
>>> wrote:
>>> > On Tue, 2016-08-23 at 15:32 -0700, Dan Williams wrote:
>>> >> On Tue, Aug 23, 2016 at 11:43 AM, Toshi Kani
>>> >> wrote:
>>> > :
>>> >> I'm not sure about this fix. The point of honoring
>>> >> vmem_altmap_offset() is because a portion of the resource that is
>>> >> passed to devm_memremap_pages() also contains the metadata info
>>> block
>>> >> for the device. The offset says "use everything past this point for
>>> >> pages". This may work for avoiding a crash, but it may corrupt info
>>> >> block metadata in the process. Can you provide more information
>>> >> about the failing scenario to be sure that we are not triggering a
>>> >> fault on an address that is not meant to have a page mapping? I.e.
>>> >> what is the host physical address of the page that caused this fault,
>>> >> and is it valid?
>>> >
>>> > The fault address in question was the 2nd page of an NVDIMM range. I
>>> > assumed this fault address was valid and needed to be handled. Here is
>>> > some info about the base and patched cases. Let me know if you need
>>> > more info.
>>> >
>>> > Base
>>> >
>>> >
>>> > The following NVDIMM range was set to /dev/dax.
>>>
>>> With ndctl create-namespace or manually via sysfs? Specifically I'm
>>> looking for what the 'align' attribute was set to when the
>>> configuration was established. Can you provide a dump of the sysfs
>>> attributes for the /dev/dax parent device?
>>
>> I used the ndctl command below.
>> ndctl create-namespace -f -e namespace0.0 -m dax
>>
>> Here is additional info from my note for the base case.
>>
>> p {struct dev_pagemap} 0x88046d0453f0
>> $3 = {
>> altmap = 0x88046d045410,
>> res = 0x88046d0453a8,
>> ref = 0x88046d0452f0,
>> dev = 0x880464790410
>> }
>>
>> crash> p {struct vmem_altmap} 0x88046d045410
>> $6 = {
>> base_pfn = 0x48,
>> reserve = 0x2,// PHYS_PFN(SZ_8K)
>> free = 0x101fe,
>> align = 0x1fe,
>> alloc = 0x1
>> }
>
> Ah, so, on second look the 0x49020 data offset looks correct. The
> total size of the address range is 16GB which equates to 256MB needed
> for struct page, plus 2MB more to re-align the data on the next 2MB
> boundary.
>
> The question now is why is the guest faulting on an access to an
> address less than 0x49020?
Does the attached patch fix this for you?
From 506cdd2c4ec0f9283ac4eb92259f2e8a71c5b637 Mon Sep 17 00:00:00 2001
From: Dan Williams
Date: Tue, 23 Aug 2016 19:59:31 -0700
Subject: [PATCH] dax: fix device-dax region base
The data offset for a dax region needs to account for an altmap
reservation in the resource range. Otherwise, device-dax is allowing
mappings directly into the memmap or device info-block area, with crash
signatures like the following:
BUG: unable to handle kernel NULL pointer dereference at 0008
IP: [] get_zone_device_page+0x11/0x30
Call Trace:
follow_devmap_pmd+0x298/0x2c0
follow_page_mask+0x275/0x530
__get_user_pages+0xe3/0x750
__gfn_to_pfn_memslot+0x1b2/0x450 [kvm]
? hrtimer_try_to_cancel+0x2c/0x120
? kvm_read_l1_tsc+0x55/0x60 [kvm]
try_async_pf+0x66/0x230 [kvm]
? kvm_host_page_size+0x90/0xa0 [kvm]
tdp_page_fault+0x130/0x280 [kvm]
kvm_mmu_page_fault+0x5f/0xf0 [kvm]
handle_ept_violation+0x94/0x180 [kvm_intel]
vmx_handle_exit+0x1d3/0x1440 [kvm_intel]
? atomic_switch_perf_msrs+0x6f/0xa0 [kvm_intel]
? vmx_vcpu_run+0x2d1/0x490 [kvm_intel]
kvm_arch_vcpu_ioctl_run+0x81d/0x16a0 [kvm]
? wake_up_q+0x44/0x80
kvm_vcpu_ioctl+0x33c/0x620 [kvm]
? __vfs_write+0x37/0x160
do_vfs_ioctl+0xa2/0x5d0
SyS_ioctl+0x79/0x90
entry_SYSCALL_64_fastpath+0x1a/0xa4
Cc:
Cc: Andrew Morton
Fixes: ab68f2622136 ("/dev/dax, pmem: direct access to persistent memory")
Reported-by: Abhilash Kumar Mulumudi
Reported-by: Toshi Kani
Signed-off-by: Dan Williams
---
drivers/dax/pmem.c | 2 ++
include/linux/memremap.h | 1 +
kernel/memremap.c| 9 +
3 files changed, 12 insertions(+)
diff --git a/drivers/dax/pmem.c b/drivers/dax/pmem.c
index dfb168568af1..0603637df162 100644
--- a/drivers/dax/pmem.c
+++ b/drivers/dax/pmem.c
@@ -116,6 +116,8 @@ static int dax_pmem_probe(struct device *dev)
if (rc)
return rc;
+ res.start += vmem_altmap_resource_offset(altmap);
+
nd_region = to_nd_region(dev->parent);
dax_region = alloc_dax_region(dev, nd_region->id, &res,
le32_to_cpu(pfn_sb->align), addr, PFN_DEV|PFN_MAP);
diff --git a/include/linux/memremap.h b/include/linux/memremap.h
index 93416196ba64..7265b83cdbea 100644
--- a/include/linux/memremap.h
+++ b/include/linux/memremap.h
@@ -24,6 +24,7 @@ struct vmem_altmap {
};
unsigned long vmem_altmap_offset(struct vmem_altmap *altmap);
+resource_size_t vmem_altmap_resource_offset(struct vmem_altmap *altmap);
void vmem_altmap_free(struct vmem_
Re: [PATCH 0/3] perf, bts: Fallout from the fuzzer for perf/urgent
Thanks! I'll get back to you with something better. On 23 August 2016 at 23:55, Vince Weaver wrote: > On Tue, 23 Aug 2016, Alexander Shishkin wrote: > >> Vince Weaver writes: >> >> > On Tue, 23 Aug 2016, Alexander Shishkin wrote: >> > >> >> Recently Vince has reported warnings and panics coming from the >> >> general direction of AUX tracing. I found two bugs which manifest >> >> similarly, one in intel_bts driver and one in AUX unmapping path. >> >> >> >> Both are triggered by racing SET_OUTPUT against mmap_close while >> >> running AUX tracing. I have a test case that set fire to the kernel >> >> within a few seconds by doing this, which I can share if anyone >> >> cares. >> > >> > I've applied these and am fuzzing on my Haswell machine and I'm getting >> > lots and lots of >> > >> > [ 945.536374] Dazed and confused, but trying to continue >> > [ 945.542391] Uhhuh. NMI received for unknown reason 21 on CPU 2. >> > [ 945.549360] Do you have a strange power saving mode enabled? >> > [ 945.556701] Dazed and confused, but trying to continue >> > [ 945.563643] Uhhuh. NMI received for unknown reason 31 on CPU 2. >> > [ 945.571379] Do you have a strange power saving mode enabled? >> > [ 945.578754] Dazed and confused, but trying to continue >> > [ 945.630889] Uhhuh. NMI received for unknown reason 31 on CPU 2. >> > [ 945.638141] Do you have a strange power saving mode enabled? >> > [ 945.645523] Dazed and confused, but trying to continue >> > >> > messages that I wasn't getting before. Of course, I updated from -rc2 to >> > -rc3 before applying the patch so it could also be related to that too, I >> > can try backing out the patches and see if it still happens. >> >> Uhhuh, that's not cool, let me look some more. But it should stop dying >> on bts/aux stuff at least. > > Just wanted to say that when I backed out these patches the NMI errors > went away, so they do seem to be a result of this patch series. > > Vince
Re: [PATCH 2/2] mm/usercopy: enable usercopy size checking for modern versions of gcc
On Tue, Aug 23, 2016 at 3:28 PM, Josh Poimboeuf wrote:
> This is a revert of:
>
> 2fb0815c9ee6 ("gcc4: disable __compiletime_object_size for GCC 4.6+")
>
> The goal of that commit was to silence the "provably correct" gcc
> warnings. But it went too far: it also disabled the runtime warnings.
>
> Now that the pretty much useless gcc warnings have been properly
> disposed of with the previous patch, re-enable this checking on modern
> versions of gcc so we can get the runtime warnings again.
As far as I know, this will still be broken since it's
__builtin_object_size() that is buggy. Maybe I'm misunderstanding
which piece is busted, though?
-Kees
>
> Signed-off-by: Josh Poimboeuf
> ---
> include/linux/compiler-gcc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index e294939..e7f7a68 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -158,7 +158,7 @@
> #define __compiler_offsetof(a, b) \
> __builtin_offsetof(a, b)
>
> -#if GCC_VERSION >= 40100 && GCC_VERSION < 40600
> +#if GCC_VERSION >= 40100
> # define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
> #endif
>
> --
> 2.7.4
>
--
Kees Cook
Nexus Security
[PATCH v13 1/4] dt-bindings: soc: Add documentation for the MediaTek GCE unit
This adds documentation for the MediaTek Global Command Engine (GCE) unit
found in MT8173 SoCs.
Signed-off-by: HS Liao
Acked-by: Rob Herring
---
.../devicetree/bindings/soc/mediatek/gce.txt | 44 ++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/mediatek/gce.txt
diff --git a/Documentation/devicetree/bindings/soc/mediatek/gce.txt
b/Documentation/devicetree/bindings/soc/mediatek/gce.txt
new file mode 100644
index 000..55c4105
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/gce.txt
@@ -0,0 +1,44 @@
+MediaTek GCE
+===
+
+The Global Command Engine (GCE) is used to help read/write registers with
+critical time limitation, such as updating display configuration during the
+vblank. The GCE can be used to implement the Command Queue (CMDQ) driver.
+
+CMDQ driver uses mailbox framework for communication. Please refer to
+../../mailbox/mailbox.txt for generic information about mailbox device-tree
+bindings.
+
+Required properties:
+- compatible: Must be "mediatek,mt8173-gce"
+- reg: Address range of the GCE unit
+- interrupts: The interrupt signal from the GCE block
+- clock: Clocks according to the common clock binding
+- clock-names: Must be "gce" to stand for GCE clock
+- #mbox-cells: Should be 2
+
+Required properties for a client device:
+- mboxes: client use mailbox to communicate with GCE, it should have this
+ property and list of phandle, mailbox channel specifiers, and atomic
+ execution flag.
+
+Example:
+
+ gce: gce@10212000 {
+ compatible = "mediatek,mt8173-gce";
+ reg = <0 0x10212000 0 0x1000>;
+ interrupts = ;
+ clocks = <&infracfg CLK_INFRA_GCE>;
+ clock-names = "gce";
+
+ #mbox-cells = <2>;
+ };
+
+Example for a client device:
+
+ mmsys: clock-controller@1400 {
+ compatible = "mediatek,mt8173-mmsys";
+ mboxes = <&gce 0 1 /* main display with atomic execution */
+ &gce 1 1>; /* sub display with atomic execution */
+ ...
+ };
--
1.9.1
linux-next: build warning after merge of the thermal tree
Hi Zhang,
After merging the thermal tree, today's linux-next build (powerpc
allyesconfig) produced this warning:
warning: (HISI_THERMAL) selects STUB_CLK_HI6220 which has unmet direct
dependencies (COMMON_CLK && COMMON_CLK_HI6220 && MAILBOX)
Introduced by commit
5f63581ce68e ("thermal: hisilicon: Add dependency on the clock driver to
allow frequency scaling")
BTW: That commit message does not match the change (which adds a
"select" not a "depends on".
--
Cheers,
Stephen Rothwell
[PATCH v13 2/4] CMDQ: Mediatek CMDQ driver
This patch is first version of Mediatek Command Queue(CMDQ) driver. The CMDQ is used to help write registers with critical time limitation, such as updating display configuration during the vblank. It controls Global Command Engine (GCE) hardware to achieve this requirement. Currently, CMDQ only supports display related hardwares, but we expect it can be extended to other hardwares for future requirements. Signed-off-by: HS Liao Signed-off-by: CK Hu --- drivers/soc/mediatek/Kconfig| 11 + drivers/soc/mediatek/Makefile | 1 + drivers/soc/mediatek/mtk-cmdq.c | 945 include/soc/mediatek/cmdq.h | 180 4 files changed, 1137 insertions(+) create mode 100644 drivers/soc/mediatek/mtk-cmdq.c create mode 100644 include/soc/mediatek/cmdq.h diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig index 0a4ea80..50869e4 100644 --- a/drivers/soc/mediatek/Kconfig +++ b/drivers/soc/mediatek/Kconfig @@ -1,6 +1,17 @@ # # MediaTek SoC drivers # +config MTK_CMDQ + bool "MediaTek CMDQ Support" + depends on ARM64 && ( ARCH_MEDIATEK || COMPILE_TEST ) + select MAILBOX + select MTK_INFRACFG + help + Say yes here to add support for the MediaTek Command Queue (CMDQ) + driver. The CMDQ is used to help read/write registers with critical + time limitation, such as updating display configuration during the + vblank. + config MTK_INFRACFG bool "MediaTek INFRACFG Support" depends on ARCH_MEDIATEK || COMPILE_TEST diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile index 12998b0..f7397ef 100644 --- a/drivers/soc/mediatek/Makefile +++ b/drivers/soc/mediatek/Makefile @@ -1,3 +1,4 @@ +obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq.o obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o diff --git a/drivers/soc/mediatek/mtk-cmdq.c b/drivers/soc/mediatek/mtk-cmdq.c new file mode 100644 index 000..7ca3113 --- /dev/null +++ b/drivers/soc/mediatek/mtk-cmdq.c @@ -0,0 +1,945 @@ +/* + * Copyright (c) 2015 MediaTek Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define CMDQ_THR_MAX_COUNT 3 /* main, sub, general(misc) */ +#define CMDQ_INST_SIZE 8 /* instruction is 64-bit */ +#define CMDQ_TIMEOUT_MS1000 +#define CMDQ_IRQ_MASK 0x +#define CMDQ_NUM_CMD(t)(t->cmd_buf_size / CMDQ_INST_SIZE) + +#define CMDQ_CURR_IRQ_STATUS 0x10 +#define CMDQ_THR_SLOT_CYCLES 0x30 + +#define CMDQ_THR_BASE 0x100 +#define CMDQ_THR_SIZE 0x80 +#define CMDQ_THR_WARM_RESET0x00 +#define CMDQ_THR_ENABLE_TASK 0x04 +#define CMDQ_THR_SUSPEND_TASK 0x08 +#define CMDQ_THR_CURR_STATUS 0x0c +#define CMDQ_THR_IRQ_STATUS0x10 +#define CMDQ_THR_IRQ_ENABLE0x14 +#define CMDQ_THR_CURR_ADDR 0x20 +#define CMDQ_THR_END_ADDR 0x24 + +#define CMDQ_THR_ENABLED 0x1 +#define CMDQ_THR_DISABLED 0x0 +#define CMDQ_THR_SUSPEND 0x1 +#define CMDQ_THR_RESUME0x0 +#define CMDQ_THR_STATUS_SUSPENDED BIT(1) +#define CMDQ_THR_DO_WARM_RESET BIT(0) +#define CMDQ_THR_ACTIVE_SLOT_CYCLES0x3200 +#define CMDQ_THR_IRQ_DONE 0x1 +#define CMDQ_THR_IRQ_ERROR 0x12 +#define CMDQ_THR_IRQ_EN(CMDQ_THR_IRQ_ERROR | CMDQ_THR_IRQ_DONE) + +#define CMDQ_OP_CODE_SHIFT 24 +#define CMDQ_SUBSYS_SHIFT 16 + +#define CMDQ_ARG_A_WRITE_MASK 0x +#define CMDQ_OP_CODE_MASK (0xff << CMDQ_OP_CODE_SHIFT) + +#define CMDQ_WRITE_ENABLE_MASK BIT(0) +#define CMDQ_JUMP_BY_OFFSET0x1000 +#define CMDQ_JUMP_BY_PA0x1001 +#define CMDQ_JUMP_PASS CMDQ_INST_SIZE +#define CMDQ_WFE_UPDATEBIT(31) +#define CMDQ_WFE_WAIT BIT(15) +#define CMDQ_WFE_WAIT_VALUE0x1 +#define CMDQ_EOC_IRQ_ENBIT(0) + +/* + * CMDQ_CODE_MASK: + * set write mask + * format: op mask + * CMDQ_CODE_WRITE: + * write value into target register + * format: op subsys address value + *
Re: [PATCH] infiniband/mlx5: Remove superfluous include of io-mapping.h
- Original Message - > From: "Chris Wilson" > To: linux-r...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org, "Chris Wilson" , > "Eli Cohen" , "Jack > Morgenstein" , "Or Gerlitz" > , "Matan Barak" , > "Leon Romanovsky" , "Doug Ledford" > , "Sean Hefty" , > "Hal Rosenstock" > Sent: Tuesday, August 23, 2016 4:16:26 PM > Subject: [PATCH] infiniband/mlx5: Remove superfluous include of io-mapping.h > > This file does not use any structs or functions defined by io-mapping.h > (nor does it directly use iomap, ioremap, iounamp or friends). Remove it > to simplify verification of changes to io-mapping.h > > The include existed since its inception in > > commit e126ba97dba9edeb6fafa3665b5f8497fc9cdf8c > Author: Eli Cohen > Date: Sun Jul 7 17:25:49 2013 +0300 > > mlx5: Add driver for Mellanox Connect-IB adapters > > which looks like a copy across from the Mellanox ethernet driver. > > Signed-off-by: Chris Wilson > Cc: Eli Cohen > Cc: Jack Morgenstein > Cc: Or Gerlitz > Cc: Matan Barak > Cc: Leon Romanovsky > Cc: Doug Ledford > Cc: Sean Hefty > Cc: Hal Rosenstock > Cc: linux-r...@vger.kernel.org > --- > drivers/infiniband/hw/mlx5/main.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/infiniband/hw/mlx5/main.c > b/drivers/infiniband/hw/mlx5/main.c > index a84bb766fc62..1b4094baa2de 100644 > --- a/drivers/infiniband/hw/mlx5/main.c > +++ b/drivers/infiniband/hw/mlx5/main.c > @@ -37,7 +37,6 @@ > #include > #include > #include > -#include > #if defined(CONFIG_X86) > #include > #endif > -- > 2.9.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > I compiled and tested this with no issues on my mlx5 test bed. Reviewed-by Laurence Oberman Tested-by Laurence Oberman
Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat
> "Tom" == Tom Yan writes: Tom> Nope, SCSI Write Same commands does not have payload (or in SCSI Tom> terms, parameter list / data-out buffer). WRITE SAME has a a payload of 1 logical block (unless NDOB is set but we have had no good reason to support that yet). UNMAP has a payload that varies based on the number of range descriptors. The SCSI disk driver only ever issues a single descriptor but since libata doesn't support UNMAP this doesn't really come into play. Ideally there would be a way to distinguish between device limits for WRITE SAME with the UNMAP bit and for "regular" WRITE SAME. One way to do that would be to transition the libata discard implementation over to single-range UNMAP, fill out the relevant VPD page B0 fields and leave the WRITE SAME bits for writing zeroes. One reason that has not been particularly compelling is that the WRITE SAME payload buffer does double duty to hold the ATA DSM TRIM range descriptors and matches the required ATA payload size. Whereas the UNMAP command would only provide 24 bytes of TRIM range space. Also, please be careful with transfer lengths, __data_len, etc. As mentioned, the transfer length WRITE SAME is typically 512 bytes and that's the number of bytes that need to be DMA'ed and transferred over the wire by the controller. But from a command completion perspective we need to complete however many bytes the command acted upon. Unlike reads and writes there is not a 1:1 mapping between the transfer length and the affected area. So we do a bit of magic after the buffer has been mapped to ensure that the completion byte count matches the number of blocks that were affected by the command rather than the size of the data buffer in bytes. -- Martin K. Petersen Oracle Linux Engineering
[PATCH v13 4/4] CMDQ: save more energy in idle
Use clk_disable_unprepare instead of clk_disable to save more energy
when CMDQ is idle.
Signed-off-by: HS Liao
---
drivers/soc/mediatek/mtk-cmdq.c | 54 +++--
1 file changed, 46 insertions(+), 8 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq.c b/drivers/soc/mediatek/mtk-cmdq.c
index 7ca3113..a0fcbef 100644
--- a/drivers/soc/mediatek/mtk-cmdq.c
+++ b/drivers/soc/mediatek/mtk-cmdq.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#define CMDQ_THR_MAX_COUNT 3 /* main, sub, general(misc) */
@@ -128,10 +129,16 @@ struct cmdq_task {
struct cmdq_task_cb cb;
};
+struct cmdq_clk_release {
+ struct cmdq *cmdq;
+ struct work_struct release_work;
+};
+
struct cmdq {
struct mbox_controller mbox;
void __iomem*base;
u32 irq;
+ struct workqueue_struct *clk_release_wq;
struct cmdq_thread thread[CMDQ_THR_MAX_COUNT];
struct mutextask_mutex;
struct clk *clock;
@@ -297,11 +304,19 @@ static void cmdq_thread_wait_end(struct cmdq_thread
*thread,
static void cmdq_task_exec(struct cmdq_task *task, struct cmdq_thread *thread)
{
struct cmdq *cmdq = task->cmdq;
- unsigned long curr_pa, end_pa;
+ unsigned long curr_pa, end_pa, flags;
task->thread = thread;
if (list_empty(&thread->task_busy_list)) {
- WARN_ON(clk_enable(cmdq->clock) < 0);
+ /*
+* Unlock for clk prepare (sleeping function).
+* We are safe to do that since we have task_mutex and
+* only flush will add task.
+*/
+ spin_unlock_irqrestore(&thread->chan->lock, flags);
+ WARN_ON(clk_prepare_enable(cmdq->clock) < 0);
+ spin_lock_irqsave(&thread->chan->lock, flags);
+
WARN_ON(cmdq_thread_reset(cmdq, thread) < 0);
writel(task->pa_base, thread->base + CMDQ_THR_CURR_ADDR);
@@ -383,6 +398,26 @@ static void cmdq_task_handle_error(struct cmdq_task *task)
cmdq_thread_resume(thread);
}
+static void cmdq_clk_release_work(struct work_struct *work_item)
+{
+ struct cmdq_clk_release *clk_release = container_of(work_item,
+ struct cmdq_clk_release, release_work);
+ struct cmdq *cmdq = clk_release->cmdq;
+
+ clk_disable_unprepare(cmdq->clock);
+ kfree(clk_release);
+}
+
+static void cmdq_clk_release_schedule(struct cmdq *cmdq)
+{
+ struct cmdq_clk_release *clk_release;
+
+ clk_release = kmalloc(sizeof(*clk_release), GFP_ATOMIC);
+ clk_release->cmdq = cmdq;
+ INIT_WORK(&clk_release->release_work, cmdq_clk_release_work);
+ queue_work(cmdq->clk_release_wq, &clk_release->release_work);
+}
+
static void cmdq_thread_irq_handler(struct cmdq *cmdq,
struct cmdq_thread *thread)
{
@@ -432,7 +467,7 @@ static void cmdq_thread_irq_handler(struct cmdq *cmdq,
if (list_empty(&thread->task_busy_list)) {
cmdq_thread_disable(cmdq, thread);
- clk_disable(cmdq->clock);
+ cmdq_clk_release_schedule(cmdq);
} else {
mod_timer(&thread->timeout,
jiffies + msecs_to_jiffies(CMDQ_TIMEOUT_MS));
@@ -491,7 +526,7 @@ static void cmdq_thread_handle_timeout(unsigned long data)
cmdq_thread_resume(thread);
cmdq_thread_disable(cmdq, thread);
- clk_disable(cmdq->clock);
+ cmdq_clk_release_schedule(cmdq);
spin_unlock_irqrestore(&thread->chan->lock, flags);
}
@@ -779,7 +814,7 @@ static int cmdq_suspend(struct device *dev)
msleep(20);
}
- clk_unprepare(cmdq->clock);
+ flush_workqueue(cmdq->clk_release_wq);
return 0;
}
@@ -787,7 +822,6 @@ static int cmdq_resume(struct device *dev)
{
struct cmdq *cmdq = dev_get_drvdata(dev);
- WARN_ON(clk_prepare(cmdq->clock) < 0);
cmdq->suspended = false;
return 0;
}
@@ -796,8 +830,8 @@ static int cmdq_remove(struct platform_device *pdev)
{
struct cmdq *cmdq = platform_get_drvdata(pdev);
+ destroy_workqueue(cmdq->clk_release_wq);
mbox_controller_unregister(&cmdq->mbox);
- clk_unprepare(cmdq->clock);
return 0;
}
@@ -916,8 +950,12 @@ static int cmdq_probe(struct platform_device *pdev)
return err;
}
+ cmdq->clk_release_wq = alloc_ordered_workqueue(
+ "%s", WQ_MEM_RECLAIM | WQ_HIGHPRI,
+ "cmdq_clk_release");
+
platform_set_drvdata(pdev, cmdq);
- WARN_ON(clk_prepare(cmdq->clock) < 0);
+
return 0;
}
--
1.9.1
[PATCH v13 3/4] arm64: dts: mt8173: Add GCE node
This patch adds the device node of the GCE hardware for CMDQ module.
Signed-off-by: HS Liao
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 10f638f..00d9d92 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -383,6 +383,16 @@
#clock-cells = <1>;
};
+ gce: gce@10212000 {
+ compatible = "mediatek,mt8173-gce";
+ reg = <0 0x10212000 0 0x1000>;
+ interrupts = ;
+ clocks = <&infracfg CLK_INFRA_GCE>;
+ clock-names = "gce";
+
+ #mbox-cells = <2>;
+ };
+
mipi_tx0: mipi-dphy@10215000 {
compatible = "mediatek,mt8173-mipi-tx";
reg = <0 0x10215000 0 0x1000>;
--
1.9.1
[PATCH v13 0/4] Mediatek MT8173 CMDQ support
Hi, This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used to help write registers with critical time limitation, such as updating display configuration during the vblank. It controls Global Command Engine (GCE) hardware to achieve this requirement. These patches have a build dependency on top of v4.8-rc1. Changes since v12: - remove mediatek,gce from device tree Best regards, HS Liao HS Liao (4): dt-bindings: soc: Add documentation for the MediaTek GCE unit CMDQ: Mediatek CMDQ driver arm64: dts: mt8173: Add GCE node CMDQ: save more energy in idle .../devicetree/bindings/soc/mediatek/gce.txt | 44 + arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 + drivers/soc/mediatek/Kconfig | 11 + drivers/soc/mediatek/Makefile | 1 + drivers/soc/mediatek/mtk-cmdq.c| 983 + include/soc/mediatek/cmdq.h| 180 6 files changed, 1229 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/mediatek/gce.txt create mode 100644 drivers/soc/mediatek/mtk-cmdq.c create mode 100644 include/soc/mediatek/cmdq.h -- 1.9.1
Re: [lkp] [x86/irq] 82ba4faca1: [No primary change] [unixbench]
On 08/24/2016 11:04 AM, kernel test robot wrote:
>
> FYI, we noticed interrupts.CAL:Function_call_interrupts +771.1% improvement
> due to commit:
This is expected.
CAL:Function_call_interrupts now contains TLB shootdowns while it
doesn't previously.
Thanks,
Aaron
>
> commit 82ba4faca1bffad429f15c90c980ffd010366c25 ("x86/irq: Do not substract
> irq_tlb_count from irq_call_count")
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>
> in testcase: unixbench
> on test machine: 8 threads Nehalem with 6G memory
> with following parameters:
>
> runtime: 300s
> nr_task: 1
> test: shell8
>
> iN addition to that, the commit also has significant impact
> (interrupts.CAL:Function_call_interrupts +1822.5%)
> on the following tests:
>
> +--+--+
> | testcase | unixbench|
> | test machine | 8 threads Nehalem with 6G memory |
> | test parameters | nr_task=100% |
> | | runtime=300s |
> | | test=execl |
> +--+--+
>
>
> Disclaimer:
> Results have been estimated based on internal Intel analysis and are provided
> for informational purposes only. Any difference in system hardware or software
> design or configuration may affect actual performance.
>
> Details are as below:
> -->
>
>
> To reproduce:
>
> git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> cd lkp-tests
> bin/lkp install job.yaml # job file is attached in this email
> bin/lkp run job.yaml
>
> =
> compiler/kconfig/nr_task/rootfs/runtime/tbox_group/test/testcase:
>
> gcc-6/x86_64-rhel/1/debian-x86_64-2015-02-07.cgz/300s/nhm-white/shell8/unixbench
>
> commit:
> ace7fab7a6 ("x86/mm: Fix swap entry comment and macro")
> 82ba4faca1 ("x86/irq: Do not substract irq_tlb_count from irq_call_count")
>
> ace7fab7a6cdd363 82ba4faca1bffad429f15c90c9
> --
> %stddev %change %stddev
> \ |\
> 48379 ± 0%+771.1% 421448 ± 0%
> interrupts.CAL:Function_call_interrupts
> 19934 ± 8% -10.3% 17882 ± 4% meminfo.AnonHugePages
> 177575 ± 8% -11.9% 156428 ± 7% sched_debug.cpu.avg_idle.min
> 0.36 ± 35%+431.2% 1.93 ± 55% sched_debug.cpu.cpu_load[0].min
> 25.84 ± 1% +11.3% 28.77 ± 4% sched_debug.cpu.cpu_load[1].min
> 5.38 ± 3% -13.9% 4.63 ± 5%
> sched_debug.cpu.cpu_load[1].stddev
>
>
>
>
>interrupts.CAL:Function_call_interrupts
>
> 45 ++-+
> O O OO O O OO O O OO O O OO O O O OO |
> 40 ++ |
> 35 ++ |
> | |
> 30 ++ |
> 25 ++ |
> | |
> 20 ++ |
> 15 ++ |
> | |
> 10 ++ |
>5 *+ .**.*.*.* .**.*.*. *.*.*.*.* .*. *.*.*.**.* .*.* .*.*
> | * :.*.** :.* *+ .* *.** |
>0 ++--*--*---*---+
>
>
> [*] bisect-good sample
> [O] bisect-bad sample
>
> ***
> nhm-white: 8 threads Nehalem with 6G memory
> =
> compiler/kconfig/nr_task/rootfs/runtime/tbox_group/test/testcase:
>
> gcc-6/x86_64-rhel/100%/debian-x86_64-2015-02-07.cgz/300s/nhm-white/execl/unixbench
>
> commit:
> ace7fab7a6 ("x86/mm: Fix swap entry comment and macro")
> 82ba4faca1 ("x86/irq: Do not substract irq_tlb_count from irq_call_count")
>
> ace7fab7a6cdd363 82ba4faca1bffad429f15c90c9
> --
>fail:runs %reproductionfail:runs
>| | |
> %stddev
Re: [PATCH v1 00/10] Optimize sched avgs computation and implement flat util hierarchy
Hi Vincent, On Tue, Aug 23, 2016 at 03:28:19PM +0200, Vincent Guittot wrote: > I still wonder if using a flat util hierarchy is the right solution to > solve this problem with utilization and task group. I have noticed > exact same issues with load that generates weird task placement > decision and i think that we should probably try to solve both wrong > behavior with same mechanism. but this is not possible with flat > hierarchy for load I agree both util and load have the same hierarchical propagation problem. But util and load are different with respect to task group distribution among CPUs and along hierarchical structure. Util is "fundamentally" flat (CPU's util = tasks' util), so it's pretty natural as well as simple to implement a flat hierarchy util. And because of that, I feel util propagating up the hierarchical structure seems unnecessary. It might be better to have a converged mechanism to solve both, but it shouldn't be necessary. Right? > Let me take an example. > TA is a always running task on CPU1 in group /root/level1/ > TB wakes up on CPU0 and moves TA into group /root/level2/ > Even if TA stays on CPU1, runnable_load_avg of CPU1 root cfs rq will become 0. > Then, TB forks a new task TC. TC will probably be schedule on CPU1 > because its root cfs_rq's runnable_load_avg is null and CPU1 is the > next CPU after CPU0 > > Similar behavior can happen when TA migrates > > Beside flat utilization consideration, i'm going to have a look at the Many thanks. Yuyang
RE: [PATCH] memremap: Fix NULL pointer BUG in get_zone_device_page()
> On Tue, Aug 23, 2016 at 4:47 PM, Kani, Toshimitsu
> wrote:
> > On Tue, 2016-08-23 at 15:32 -0700, Dan Williams wrote:
> >> On Tue, Aug 23, 2016 at 11:43 AM, Toshi Kani
> >> wrote:
> > :
> >> I'm not sure about this fix. The point of honoring
> >> vmem_altmap_offset() is because a portion of the resource that is
> >> passed to devm_memremap_pages() also contains the metadata info
> block
> >> for the device. The offset says "use everything past this point for
> >> pages". This may work for avoiding a crash, but it may corrupt info
> >> block metadata in the process. Can you provide more information
> >> about the failing scenario to be sure that we are not triggering a
> >> fault on an address that is not meant to have a page mapping? I.e.
> >> what is the host physical address of the page that caused this fault,
> >> and is it valid?
> >
> > The fault address in question was the 2nd page of an NVDIMM range. I
> > assumed this fault address was valid and needed to be handled. Here is
> > some info about the base and patched cases. Let me know if you need
> > more info.
> >
> > Base
> >
> >
> > The following NVDIMM range was set to /dev/dax.
>
> With ndctl create-namespace or manually via sysfs? Specifically I'm
> looking for what the 'align' attribute was set to when the
> configuration was established. Can you provide a dump of the sysfs
> attributes for the /dev/dax parent device?
I used the ndctl command below.
ndctl create-namespace -f -e namespace0.0 -m dax
Here is additional info from my note for the base case.
p {struct dev_pagemap} 0x88046d0453f0
$3 = {
altmap = 0x88046d045410,
res = 0x88046d0453a8,
ref = 0x88046d0452f0,
dev = 0x880464790410
}
crash> p {struct vmem_altmap} 0x88046d045410
$6 = {
base_pfn = 0x48,
reserve = 0x2,// PHYS_PFN(SZ_8K)
free = 0x101fe,
align = 0x1fe,
alloc = 0x1
}
crash> p {struct resource} 0x88046d0453a8
$4 = {
start = 0x48000,
end = 0x87fff,
name = 0x880c7da5d4a8 "region0",
flags = 0x200,
desc = 0x0,
parent = 0x0,
sibling = 0x0,
child = 0x0
}
crash> p {struct percpu_ref} 0x88046d0452f0
$7 = {
count = {
counter = 0x8001
},
percpu_count_ptr = 0x60f380403a98,
release = 0xa008a0a0,
confirm_switch = 0x0,
force_atomic = 0x0,
rcu = {
next = 0x0,
func = 0x0
}
}
Thanks,
-Toshi
[RFC][PATCH v2] timekeeping: Cap array access in timekeeping_debug to protect against invalid sleep times
It was reported that hibernation could fail on the 2nd attempt,
where the system hangs at hibernate() -> syscore_resume() ->
i8237A_resume() -> claim_dma_lock(), because the lock has
already been taken.
However there is actually no other process would like to grab
this lock on that problematic platform.
Further investigation showed that the problem is triggered by
setting /sys/power/pm_trace to 1 before the 1st hibernation.
Since once pm_trace is enabled, the RTC becomes unmeaningful
after suspend, and meanwhile some BIOSes would like to adjust
the 'invalid' RTC (e.g, smaller than 1970) to the release date
of that motherboard during POST stage, thus after resumed, it
may seem that the system had a significant long sleep time might
due to meaningless RTC delta.
Then in timekeeping_resume -> tk_debug_account_sleep_time, if
the bit31 of the sleep time happened to be set to 1, the fls
returns 32 and then we add 1 to sleep_time_bin[32], which
caused a memory overwritten.
As depicted by System.map:
0x81c9d080 b sleep_time_bin
0x81c9d100 B dma_spin_lock
the dma_spin_lock.val is set to 1, which caused this problem.
This patch adds a sanity check in tk_debug_account_sleep_time()
to ensure we don't index past the sleep_time_bin array.
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Rafael J. Wysocki
Cc: Janek Kozicki
Cc: Chen Yu
Cc: Xunlei Pang
Cc: Zhang Rui
Cc: linux...@vger.kernel.org
Cc: stable
Reported-by: Janek Kozicki
Reported-by: Chen Yu
[jstultz: Problem diagnosed and original patch by Chen Yu, I've
solved the issue slightly differently, but borrowed his excelent
explanation of of the issue here.]
Signed-off-by: John Stultz
---
v2: Minor tweaks to the commit message
kernel/time/timekeeping_debug.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/kernel/time/timekeeping_debug.c b/kernel/time/timekeeping_debug.c
index f6bd652..107310a6 100644
--- a/kernel/time/timekeeping_debug.c
+++ b/kernel/time/timekeeping_debug.c
@@ -23,7 +23,9 @@
#include "timekeeping_internal.h"
-static unsigned int sleep_time_bin[32] = {0};
+#define NUM_BINS 32
+
+static unsigned int sleep_time_bin[NUM_BINS] = {0};
static int tk_debug_show_sleep_time(struct seq_file *s, void *data)
{
@@ -69,6 +71,9 @@ late_initcall(tk_debug_sleep_time_init);
void tk_debug_account_sleep_time(struct timespec64 *t)
{
- sleep_time_bin[fls(t->tv_sec)]++;
+ /* Cap bin index so we don't overflow the array */
+ int bin = min(fls(t->tv_sec), NUM_BINS-1);
+
+ sleep_time_bin[bin]++;
}
--
1.9.1
Re: [PATCH v1 00/10] Optimize sched avgs computation and implement flat util hierarchy
On Tue, Aug 23, 2016 at 04:13:41PM +0200, Peter Zijlstra wrote: > On Tue, Aug 23, 2016 at 03:28:19PM +0200, Vincent Guittot wrote: > > I still wonder if using a flat util hierarchy is the right solution to > > solve this problem with utilization and task group. I have noticed > > exact same issues with load that generates weird task placement > > decision and i think that we should probably try to solve both wrong > > behavior with same mechanism. but this is not possible with flat > > hierarchy for load > > > > Let me take an example. > > TA is a always running task on CPU1 in group /root/level1/ > > TB wakes up on CPU0 and moves TA into group /root/level2/ > > Even if TA stays on CPU1, runnable_load_avg of CPU1 root cfs rq will become > > 0. > > Because while we migrate the load_avg on /root/level2, we do not > propagate the load_avg up the hierarchy? > > And always propagating everyrthing up will indeed also fix the > utilization issue. Yes, but for util it's actually irrespective to the number of hirarchical levels, just propagating directly to the top cfs_rq or simply rq will do. In other words, it's flat :) > Of course, doing that propagation has its costs.. > > Didn't you post a patch doing just this a while ago?
Re: [PATCH 2/2] timekeeping: Cap array access in timekeeping_debug to protect against invalid sleep times
On Tue, Aug 23, 2016 at 5:58 PM, Chen Yu wrote: > Hi John, some small typos below, others should be OK. Thanks. I realize you mailed me before on this, but I forgot to integrate the changes. Apologies. I've now integrated the changes and updated the git branch. The HEAD for the pull request is now: 4efd3c8faf189674eeafb0c14ff4c556ed6adcf7. I'll send an updated v2 patch here shortly. thanks -john
Re: [PATCH] memremap: Fix NULL pointer BUG in get_zone_device_page()
On Tue, Aug 23, 2016 at 6:29 PM, Kani, Toshimitsu wrote:
>> On Tue, Aug 23, 2016 at 4:47 PM, Kani, Toshimitsu
>> wrote:
>> > On Tue, 2016-08-23 at 15:32 -0700, Dan Williams wrote:
>> >> On Tue, Aug 23, 2016 at 11:43 AM, Toshi Kani
>> >> wrote:
>> > :
>> >> I'm not sure about this fix. The point of honoring
>> >> vmem_altmap_offset() is because a portion of the resource that is
>> >> passed to devm_memremap_pages() also contains the metadata info
>> block
>> >> for the device. The offset says "use everything past this point for
>> >> pages". This may work for avoiding a crash, but it may corrupt info
>> >> block metadata in the process. Can you provide more information
>> >> about the failing scenario to be sure that we are not triggering a
>> >> fault on an address that is not meant to have a page mapping? I.e.
>> >> what is the host physical address of the page that caused this fault,
>> >> and is it valid?
>> >
>> > The fault address in question was the 2nd page of an NVDIMM range. I
>> > assumed this fault address was valid and needed to be handled. Here is
>> > some info about the base and patched cases. Let me know if you need
>> > more info.
>> >
>> > Base
>> >
>> >
>> > The following NVDIMM range was set to /dev/dax.
>>
>> With ndctl create-namespace or manually via sysfs? Specifically I'm
>> looking for what the 'align' attribute was set to when the
>> configuration was established. Can you provide a dump of the sysfs
>> attributes for the /dev/dax parent device?
>
> I used the ndctl command below.
> ndctl create-namespace -f -e namespace0.0 -m dax
>
> Here is additional info from my note for the base case.
>
> p {struct dev_pagemap} 0x88046d0453f0
> $3 = {
> altmap = 0x88046d045410,
> res = 0x88046d0453a8,
> ref = 0x88046d0452f0,
> dev = 0x880464790410
> }
>
> crash> p {struct vmem_altmap} 0x88046d045410
> $6 = {
> base_pfn = 0x48,
> reserve = 0x2,// PHYS_PFN(SZ_8K)
> free = 0x101fe,
> align = 0x1fe,
> alloc = 0x1
> }
Ah, so, on second look the 0x49020 data offset looks correct. The
total size of the address range is 16GB which equates to 256MB needed
for struct page, plus 2MB more to re-align the data on the next 2MB
boundary.
The question now is why is the guest faulting on an access to an
address less than 0x49020?
Re: [PATCH] megaraid_sas: Use memdup_user() rather than duplicating its implementation
> "SF" == SF Markus Elfring writes: SF> Reuse existing functionality from memdup_user() instead of keeping SF> duplicate source code. Applied to 4.9/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering
[PATCH v2 3/3] arm64: defconfig: enable bluetooth supports as modules
Enable the following items for bluetooth mouse and speaker which base on HCIUART. a) CONFIG_BT_HCIUART b) CONFIG_BT_HCIUART_LL c) CONFIG_BT_HIDP Enable bluetooth LED support. d) CONFIG_BT_LEDS Signed-off-by: Guodong Xu --- arch/arm64/configs/defconfig | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index b4f714c..0c7551d 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -120,6 +120,14 @@ CONFIG_VLAN_8021Q=m CONFIG_VLAN_8021Q_GVRP=y CONFIG_VLAN_8021Q_MVRP=y CONFIG_BPF_JIT=y +CONFIG_BT=m +CONFIG_BT_HIDP=m +# CONFIG_BT_HS is not set +# CONFIG_BT_LE is not set +CONFIG_BT_LEDS=y +# CONFIG_BT_DEBUGFS is not set +CONFIG_BT_HCIUART=m +CONFIG_BT_HCIUART_LL=y CONFIG_CFG80211=m CONFIG_MAC80211=m CONFIG_MAC80211_LEDS=y -- 1.9.1
[PATCH] Input: fix semicolon.cocci warnings
drivers/input/rmi4/rmi_platform.c:68:2-3: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci CC: Benjamin Tissoires Signed-off-by: Fengguang Wu --- rmi_platform.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/input/rmi4/rmi_platform.c +++ b/drivers/input/rmi4/rmi_platform.c @@ -65,7 +65,7 @@ static void rmi_worker(struct work_struc if (rmi_work->rmi->smbus_client) i2c_unregister_device(rmi_work->rmi->smbus_client); break; - }; + } kfree(rmi_work);
Re: [PATCH 09/11] Input: synaptics-rmi4 - add rmi_platform
Hi Benjamin, [auto build test WARNING on input/next] [also build test WARNING on v4.8-rc3 next-20160823] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on] [Check https://git-scm.com/docs/git-format-patch for more information] url: https://github.com/0day-ci/linux/commits/Benjamin-Tissoires/Synaptics-RMI4-over-SMBus/20160818-174713 base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next coccinelle warnings: (new ones prefixed by >>) >> drivers/input/rmi4/rmi_platform.c:68:2-3: Unneeded semicolon Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [kbuild-all] make[2]: *** No rule to make target 'tools/testing/nvdimm//config_check.o', needed by 'tools/testing/nvdimm//dax.o'.
On Tue, Aug 23, 2016 at 04:42:15PM -0700, Dan Williams wrote:
On Mon, Aug 22, 2016 at 5:26 AM, Yilong Ren wrote:
Hi, Williams
On Mon, Aug 15, 2016 at 06:30:48PM -0700, Dan Williams wrote:
On Mon, Aug 15, 2016 at 6:26 PM, Fengguang Wu wrote:
> On Mon, Aug 15, 2016 at 05:58:36PM -0700, Dan Williams wrote:
>>
>> On Mon, Aug 15, 2016 at 3:03 AM, kbuild test robot
>> wrote:
>>>
>>> tree:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>>> head: 694d0d0bb2030d2e36df73e2d23d5770511dbc8d
>>> commit: ab68f26221366f92611650e8470e6a926801c7d4 /dev/dax, pmem: direct
>>> access to persistent memory
>>> date: 3 months ago
>>> config: i386-randconfig-i1-201633 (attached as .config)
>>> compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
>>> reproduce:
>>> git checkout ab68f26221366f92611650e8470e6a926801c7d4
>>> # save the attached .config to linux build tree
>>> make ARCH=i386
>>>
>>> All errors (new ones prefixed by >>):
>>>
> make[2]: *** No rule to make target
> 'tools/testing/nvdimm//config_check.o', needed by
> 'tools/testing/nvdimm//dax.o'.
>>>
>>>make[2]: Target '__build' not remade because of errors.
>>
>>
>> I think this is an invalid build test. tools/testing/nvdimm/ uses a
>> external module Kbuild environment, not Kconfig. So, there's nothing
>> I can do to prevent this compile error, unless there's some other way
>> 0-day could determine the configuration dependencies?
>
>
> Yeah if you can offer a concrete rule for the dependency, we'll add
> it to 0-day.
Sounds good. The config_check.c file itself lists the dependencies:
void check(void)
{
/*
* These kconfig symbols must be set to "m" for nfit_test to
* load and operate.
*/
BUILD_BUG_ON(!IS_MODULE(CONFIG_LIBNVDIMM));
BUILD_BUG_ON(!IS_MODULE(CONFIG_BLK_DEV_PMEM));
BUILD_BUG_ON(!IS_MODULE(CONFIG_ND_BTT));
BUILD_BUG_ON(!IS_MODULE(CONFIG_ND_PFN));
BUILD_BUG_ON(!IS_MODULE(CONFIG_ND_BLK));
BUILD_BUG_ON(!IS_MODULE(CONFIG_ACPI_NFIT));
BUILD_BUG_ON(!IS_MODULE(CONFIG_DEV_DAX));
BUILD_BUG_ON(!IS_MODULE(CONFIG_DEV_DAX_PMEM));
}
will get the following error info after set all above kconfig to be "m":
/kbuild/src/lkp/Makefile:1478: recipe for target
'_module_tools/testing/nvdimm/' failed
Would you please help to take a look? thanks.
reproduce:
git checkout 29b4817d4018df78086157ea3a55c1d9424a7cfc (v4.8-rc1)
# save the attached .config to linux build tree
make HOSTCC=gcc-6 CC=gcc-6 ARCH=x86_64 prepare
make HOSTCC=gcc-6 CC=gcc-6 ARCH=x86_64 modules_prepare
make HOSTCC=gcc-6 CC=gcc-6 ARCH=x86_64 M=tools/testing/nvdimm/
error info:
/usr/bin/timeout -k 100 3h /usr/bin/make HOSTCC=gcc-6 CC=gcc-6 -j100 -C source
O=/kbuild/obj/lkp/x86_64-rhel-7.2 ARCH=x86_64 M=tools/testing/nvdimm/
make: Entering directory '/kbuild/src/lkp'
make[1]: Entering directory '/kbuild/obj/lkp/x86_64-rhel-7.2'
LD tools/testing/nvdimm//built-in.o
CC [M] tools/testing/nvdimm//../../../drivers/nvdimm/core.o
CC [M] tools/testing/nvdimm//../../../drivers/nvdimm/bus.o
CC [M] tools/testing/nvdimm//../../../drivers/nvdimm/dimm.o
CC [M] tools/testing/nvdimm//../../../drivers/nvdimm/region_devs.o
CC [M] tools/testing/nvdimm//../../../drivers/nvdimm/region.o
CC [M] tools/testing/nvdimm//../../../drivers/nvdimm/dimm_devs.o
CC [M] tools/testing/nvdimm//../../../drivers/nvdimm/label.o
CC [M] tools/testing/nvdimm//../../../drivers/nvdimm/namespace_devs.o
CC [M] tools/testing/nvdimm//../../../drivers/nvdimm/btt_devs.o
CC [M] tools/testing/nvdimm//../../../drivers/nvdimm/pfn_devs.o
CC [M] tools/testing/nvdimm//../../../drivers/nvdimm/claim.o
CC [M] tools/testing/nvdimm//../../../drivers/nvdimm/dax_devs.o
CC [M] tools/testing/nvdimm//../../../drivers/nvdimm/pmem.o
CC [M] tools/testing/nvdimm//../../../drivers/nvdimm/blk.o
CC [M] tools/testing/nvdimm//../../../drivers/nvdimm/e820.o
CC [M] tools/testing/nvdimm//../../../drivers/acpi/nfit/core.o
CC [M] tools/testing/nvdimm//../../../drivers/nvdimm/btt.o
CC [M] tools/testing/nvdimm//../../../drivers/acpi/nfit/mce.o
CC [M] tools/testing/nvdimm//../../../drivers/dax/dax.o
CC [M] tools/testing/nvdimm//../../../drivers/dax/pmem.o
LD tools/testing/nvdimm//test/built-in.o
CC [M] tools/testing/nvdimm//test/nfit.o
CC [M] tools/testing/nvdimm//test/iomap.o
LD [M] tools/testing/nvdimm//test/nfit_test_iomap.o
LD [M] tools/testing/nvdimm//test/nfit_test.o
/kbuild/src/lkp/Makefile:1478: recipe for target '_module_tools/testing/nvdimm/'
failed <==
I was not able to reproduce this, I tried on Fedora 23 and Fedora 24
and both attempts succeeded.
Hi Dan, it looks the error only happens with separated obj dir, when
KBUILD_OUTPUT or "-C .. O=.." is used in make command line.
Thanks,
Fengguang
[PATCH v2 2/3] arm64: defconfig: enable CONFIG_INPUT_HISI_POWERKEY for HiKey
Signed-off-by: Guodong Xu --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index e27f086..b4f714c 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -186,6 +186,7 @@ CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y CONFIG_INPUT_MISC=y CONFIG_INPUT_PM8941_PWRKEY=y +CONFIG_INPUT_HISI_POWERKEY=y # CONFIG_SERIO_SERPORT is not set CONFIG_SERIO_AMBAKMI=y CONFIG_LEGACY_PTY_COUNT=16 -- 1.9.1
[PATCH v2 0/3] arm64: defconfig: enable various configs for HiKey
Enable various configs for HiKey, including: 1. HiSilicon Kirin DRM 2. ADV7533 3. HiSi Powerkey 4. Bluetooth v2: - Removed CMA size 128M change. Leave that in bootloader as suggested by Thierry Reding Guodong Xu (3): arm64: defconfig: Enable HiSilicon kirin drm, adv7533 for HiKey arm64: defconfig: enable CONFIG_INPUT_HISI_POWERKEY for HiKey arm64: defconfig: enable bluetooth supports as modules arch/arm64/configs/defconfig | 11 +++ 1 file changed, 11 insertions(+) -- 1.9.1
[PATCH v2 1/3] arm64: defconfig: Enable HiSilicon kirin drm, adv7533 for HiKey
Enable HiSilicon kirin drm driver for HiKey: CONFIG_DRM_HISI_KIRIN Enable adv7511/adv7533 for HiKey: CONFIG_DRM_I2C_ADV7511 Build these components as modules. Signed-off-by: Xinliang Liu Signed-off-by: Guodong Xu --- arch/arm64/configs/defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 76bfaa7..e27f086 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -276,6 +276,8 @@ CONFIG_DRM=m CONFIG_DRM_NOUVEAU=m CONFIG_DRM_TEGRA=m CONFIG_DRM_PANEL_SIMPLE=m +CONFIG_DRM_I2C_ADV7511=m +CONFIG_DRM_HISI_KIRIN=m CONFIG_FB=y CONFIG_FB_ARMCLCD=y CONFIG_BACKLIGHT_GENERIC=m -- 1.9.1
Re: [PATCH 1/2] mm/usercopy: get rid of "provably correct" warnings
On Tue, Aug 23, 2016 at 3:28 PM, Josh Poimboeuf wrote:
> With CONFIG_DEBUG_STRICT_USER_COPY_CHECKS=y, if I force enable the
> __compiletime_object_size() macro with a recent compiler by removing the
> "GCC_VERSION < 40600" check, I get a bunch of false positive warnings.
> For example:
>
> In function ‘copy_to_user.part.8’,
> inlined from ‘copy_to_user’,
> inlined from ‘proc_put_long’ at
> /home/jpoimboe/git/linux/kernel/sysctl.c:2096:6:
> /home/jpoimboe/git/linux/arch/x86/include/asm/uaccess.h:723:46: warning:
> call to ‘__copy_to_user_overflow’ declared with attribute warning:
> copy_to_user() buffer size is not provably correct
>
> The problem is that gcc can't always definitively tell whether
> copy_from_user_overflow() will be called. And when in doubt, it prints
> the warning anyway. So in practice, these warnings mostly just create a
> lot of noise. There might be a bug lurking in there somewhere, but the
> signal to noise ratio is really low, and not worth the pain IMO.
>
> So just remove the "provably correct" warnings altogether. This also
> lays the groundwork for re-enabling the copy_from_user_overflow()
> runtime warnings for newer compilers.
Hrrrm, I'd much rather split configs or something. This "probably
correct" warning is something gcc should be ABLE to do, but the
ability regressed and hasn't yet been fixed:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46639
originally: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48880
We should get that back at some point, and I'd like to have the
compile-time checks enabled again then without having to reintroduce
the code.
Jeff, any news on this front? It'd be really nice to get this back in.
One of your comments in 2014 on the bug make it sound like it might be
easy to fix?
-Kees
>
> Signed-off-by: Josh Poimboeuf
> ---
> arch/parisc/include/asm/uaccess.h | 8 +---
> arch/s390/include/asm/uaccess.h | 6 +-
> arch/tile/include/asm/uaccess.h | 3 +--
> arch/x86/include/asm/uaccess.h| 35 ---
> 4 files changed, 3 insertions(+), 49 deletions(-)
>
> diff --git a/arch/parisc/include/asm/uaccess.h
> b/arch/parisc/include/asm/uaccess.h
> index 0f59fd9..b34c022 100644
> --- a/arch/parisc/include/asm/uaccess.h
> +++ b/arch/parisc/include/asm/uaccess.h
> @@ -208,13 +208,7 @@ unsigned long copy_in_user(void __user *dst, const void
> __user *src, unsigned lo
> #define __copy_to_user_inatomic __copy_to_user
> #define __copy_from_user_inatomic __copy_from_user
>
> -extern void copy_from_user_overflow(void)
> -#ifdef CONFIG_DEBUG_STRICT_USER_COPY_CHECKS
> -__compiletime_error("copy_from_user() buffer size is not provably
> correct")
> -#else
> -__compiletime_warning("copy_from_user() buffer size is not provably
> correct")
> -#endif
> -;
> +extern void copy_from_user_overflow(void);
>
> static inline unsigned long __must_check copy_from_user(void *to,
>const void __user *from,
> diff --git a/arch/s390/include/asm/uaccess.h b/arch/s390/include/asm/uaccess.h
> index 9b49cf1..6d36860 100644
> --- a/arch/s390/include/asm/uaccess.h
> +++ b/arch/s390/include/asm/uaccess.h
> @@ -332,11 +332,7 @@ copy_to_user(void __user *to, const void *from, unsigned
> long n)
> return __copy_to_user(to, from, n);
> }
>
> -void copy_from_user_overflow(void)
> -#ifdef CONFIG_DEBUG_STRICT_USER_COPY_CHECKS
> -__compiletime_warning("copy_from_user() buffer size is not provably correct")
> -#endif
> -;
> +void copy_from_user_overflow(void);
>
> /**
> * copy_from_user: - Copy a block of data from user space.
> diff --git a/arch/tile/include/asm/uaccess.h b/arch/tile/include/asm/uaccess.h
> index 0a9c4265..e0e313f 100644
> --- a/arch/tile/include/asm/uaccess.h
> +++ b/arch/tile/include/asm/uaccess.h
> @@ -422,8 +422,7 @@ _copy_from_user(void *to, const void __user *from,
> unsigned long n)
> * option is not really compatible with -Werror, which is more useful in
> * general.
> */
> -extern void copy_from_user_overflow(void)
> - __compiletime_warning("copy_from_user() size is not provably
> correct");
> +extern void copy_from_user_overflow(void);
>
> static inline unsigned long __must_check copy_from_user(void *to,
> const void __user *from,
> diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
> index a0ae610..89c12cb 100644
> --- a/arch/x86/include/asm/uaccess.h
> +++ b/arch/x86/include/asm/uaccess.h
> @@ -710,20 +710,6 @@ copy_to_user_overflow(void)
> __asm__("copy_from_user_overflow");
>
> #undef copy_user_diag
>
> -#ifdef CONFIG_DEBUG_STRICT_USER_COPY_CHECKS
> -
> -extern void
> -__compiletime_warning("copy_from_user() buffer size is not provably correct")
> -__copy_from_user_overflow(void) __asm__("copy_from_user_overflow");
> -#define __copy_from_user_overflow(size, count) __copy_from_user_overflow()
> -
> -extern void
> -__compiletime_warning("co
Re: [PATCH 0/4] ARM: dts: exynos: Enable HDMI in Arndale Octa board
On 08/24/2016 04:55 AM, Krzysztof Kozlowski wrote: I saw DTS patches on linux-samsung-soc patchwork but still I would appreciate if you send them to appropriate maintainers pointed by get_maintainers.pl script. DTS stuff goes through samsung-soc tree. Thanks for your tip. I've just sent out the v2. Best regards, Milo
[PATCH v2 4/4] gpu: drm: exynos_hdmi: Use consolidated function on binding PHY DT property
Handle legacy and raw 'phy' parsing in single function.
And it also removes goto condition.
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: David Airlie
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Milo Kim
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 6a636f2..bb2d6d4 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1778,11 +1778,22 @@ static struct device_node *hdmi_ddc_dt_binding(struct
device *dev)
return np;
}
-static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
+static struct device_node *hdmi_phy_dt_binding(struct device *dev)
{
const char *compatible_str = "samsung,exynos4212-hdmiphy";
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, compatible_str);
+ if (np)
+ return np;
+
+ np = of_parse_phandle(dev->of_node, "phy", 0);
+ if (!np)
+ return NULL;
+
+ of_node_put(dev->of_node);
- return of_find_compatible_node(NULL, NULL, compatible_str);
+ return np;
}
static int hdmi_probe(struct platform_device *pdev)
@@ -1829,19 +1840,13 @@ static int hdmi_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
}
- phy_node = hdmi_legacy_phy_dt_binding(dev);
- if (phy_node)
- goto out_get_phy_port;
-
- phy_node = of_parse_phandle(dev->of_node, "phy", 0);
+ phy_node = hdmi_phy_dt_binding(dev);
if (!phy_node) {
DRM_ERROR("Failed to find hdmiphy node in device tree\n");
ret = -ENODEV;
goto err_ddc;
}
- of_node_put(dev->of_node);
-out_get_phy_port:
if (hdata->drv_data->is_apb_phy) {
hdata->regs_hdmiphy = of_iomap(phy_node, 0);
if (!hdata->regs_hdmiphy) {
--
1.9.1
[PATCH v2 2/4] ARM: dts: exynos: Use 'hpd-gpios' instead of 'hpd-gpio'
This patch enables getting a HPD GPIO descriptor quickly.
The exynos-hdmi driver uses "hpd" for HDMI hot plug detection.
static int hdmi_resources_init(struct hdmi_context *hdata)
{
...
hdata->hpd_gpio = devm_gpiod_get(dev, "hpd", GPIOD_IN);
...
}
This calls 'of_find_gpio()' and it generates the GPIO consumer ID by referring
GPIO suffix. So 'hpd-gpios' is preferred on getting a GPIO descriptor.
However, if the device tree uses 'hpd-gpio', then the exynos-hdmi driver
always retries to get a GPIO descriptor because the first GPIO suffix is not
'gpio' but 'gpios'. So you always see the debug message below.
of_get_named_gpiod_flags: can't parse 'hpd-gpios' property of node
'/soc/hdmi@1453[0]'
Use the preferred property, 'hpd-gpios' instead of 'hpd-gpio'.
Acked-by: Rob Herring
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: David Airlie
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Milo Kim
---
Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt | 4 ++--
arch/arm/boot/dts/exynos4210-universal_c210.dts | 2 +-
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 2 +-
arch/arm/boot/dts/exynos5250-arndale.dts | 2 +-
arch/arm/boot/dts/exynos5250-smdk5250.dts| 2 +-
arch/arm/boot/dts/exynos5250-snow-common.dtsi| 2 +-
arch/arm/boot/dts/exynos5250-spring.dts | 2 +-
arch/arm/boot/dts/exynos5420-peach-pit.dts | 2 +-
arch/arm/boot/dts/exynos5420-smdk5420.dts| 2 +-
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 2 +-
arch/arm/boot/dts/exynos5800-peach-pi.dts| 2 +-
11 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
index a2ec4c1..6394ea9 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
@@ -9,7 +9,7 @@ Required properties:
- reg: physical base address of the hdmi and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
-- hpd-gpio: following information about the hotplug gpio pin.
+- hpd-gpios: following information about the hotplug gpio pin.
a) phandle of the gpio controller node.
b) pin number within the gpio controller.
c) optional flags and pull up/down.
@@ -56,7 +56,7 @@ Example:
compatible = "samsung,exynos4212-hdmi";
reg = <0x1453 0x10>;
interrupts = <0 95 0>;
- hpd-gpio = <&gpx3 7 1>;
+ hpd-gpios = <&gpx3 7 1>;
ddc = <&hdmi_ddc_node>;
phy = <&hdmi_phy_node>;
samsung,syscon-phandle = <&pmu_system_controller>;
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 9a75e3e..cf95202 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -269,7 +269,7 @@
};
&hdmi {
- hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = <&gpx3 7 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&hdmi_hpd>;
hdmi-en-supply = <&hdmi_en>;
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 58ad48e7..be644fe 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -227,7 +227,7 @@
};
&hdmi {
- hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = <&gpx3 7 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&hdmi_hpd>;
vdd-supply = <&ldo8_reg>;
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index ea70603..3d981f3 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -152,7 +152,7 @@
};
&hdmi {
- hpd-gpio = <&gpx3 7 GPIO_ACTIVE_LOW>;
+ hpd-gpios = <&gpx3 7 GPIO_ACTIVE_LOW>;
vdd_osc-supply = <&ldo10_reg>;
vdd_pll-supply = <&ldo8_reg>;
vdd-supply = <&ldo8_reg>;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 381af13..7f27263 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -116,7 +116,7 @@
};
&hdmi {
- hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = <&gpx3 7 GPIO_ACTIVE
[PATCH v2 0/4] ARM: dts: exynos: Enable HDMI in Arndale Octa board
This patch-set enables HDMI in Arndale Octa board and fixes HPD DT property. It also includes code refactoring on ddc and phy. v2: Include DRM and Exynos maintainers and resend the patch-set. Add Rob's ack for the patch, [PATCH 2/4] ARM: dts: exynos: Use 'hpd-gpios' instead of 'hpd-gpio' Milo Kim (4): ARM: dts: exynos: Enable HDMI for Arndale Octa board ARM: dts: exynos: Use 'hpd-gpios' instead of 'hpd-gpio' gpu: drm: exynos_hdmi: Use consolidated function on binding DDC DT property gpu: drm: exynos_hdmi: Use consolidated function on binding PHY DT property .../bindings/display/exynos/exynos_hdmi.txt| 4 +-- arch/arm/boot/dts/exynos4210-universal_c210.dts| 2 +- arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 2 +- arch/arm/boot/dts/exynos5250-arndale.dts | 2 +- arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 +- arch/arm/boot/dts/exynos5250-snow-common.dtsi | 2 +- arch/arm/boot/dts/exynos5250-spring.dts| 2 +- arch/arm/boot/dts/exynos5420-arndale-octa.dts | 17 + arch/arm/boot/dts/exynos5420-peach-pit.dts | 2 +- arch/arm/boot/dts/exynos5420-smdk5420.dts | 2 +- arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 2 +- arch/arm/boot/dts/exynos5800-peach-pi.dts | 2 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 41 -- 13 files changed, 52 insertions(+), 30 deletions(-) -- 1.9.1
[PATCH v2 1/4] ARM: dts: exynos: Enable HDMI for Arndale Octa board
* Support HDMI display data channel
I2C #2 is assigned for the HDMI DDC. It enables the EDID access.
* GPIO for HDMI hot plug detect
GPX3_7 is used. The HPD awareness is done when the GPIO is active high and
single ended.
* Enable HDMI block in Exynos5420
HDMI PLL consumes 1.0V LDO6 (PVDD_ANAIP_1V0) and HDMI oscillator requires
1.8V LDO7 (PVDD_ANAIP_1V8).
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: David Airlie
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Milo Kim
---
arch/arm/boot/dts/exynos5420-arndale-octa.dts | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index 39a3b81..df362a2 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -70,6 +70,23 @@
status = "disabled";
};
+&i2c_2 {
+ samsung,i2c-slave-addr = <0x50>;
+ status = "okay";
+
+ hdmiddc@50 {
+ compatible = "samsung,exynos4210-hdmiddc";
+ reg = <0x50>;
+ };
+};
+
+&hdmi {
+ hpd-gpios = <&gpx3 7 GPIO_OPEN_SOURCE>;
+ vdd_osc-supply = <&ldo7_reg>;
+ vdd_pll-supply = <&ldo6_reg>;
+ status = "okay";
+};
+
&hsi2c_4 {
status = "okay";
--
1.9.1
[PATCH v2 3/4] gpu: drm: exynos_hdmi: Use consolidated function on binding DDC DT property
Handle legacy and raw 'ddc' parsing in single function.
And it also removes goto condition.
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: David Airlie
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Milo Kim
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2275efe..6a636f2 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1760,7 +1760,7 @@ static const struct component_ops hdmi_component_ops = {
.unbind = hdmi_unbind,
};
-static struct device_node *hdmi_legacy_ddc_dt_binding(struct device *dev)
+static struct device_node *hdmi_ddc_dt_binding(struct device *dev)
{
const char *compatible_str = "samsung,exynos4210-hdmiddc";
struct device_node *np;
@@ -1769,7 +1769,13 @@ static struct device_node
*hdmi_legacy_ddc_dt_binding(struct device *dev)
if (np)
return of_get_next_parent(np);
- return NULL;
+ np = of_parse_phandle(dev->of_node, "ddc", 0);
+ if (!np)
+ return NULL;
+
+ of_node_put(dev->of_node);
+
+ return np;
}
static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
@@ -1811,18 +1817,12 @@ static int hdmi_probe(struct platform_device *pdev)
return ret;
}
- ddc_node = hdmi_legacy_ddc_dt_binding(dev);
- if (ddc_node)
- goto out_get_ddc_adpt;
-
- ddc_node = of_parse_phandle(dev->of_node, "ddc", 0);
+ ddc_node = hdmi_ddc_dt_binding(dev);
if (!ddc_node) {
DRM_ERROR("Failed to find ddc node in device tree\n");
return -ENODEV;
}
- of_node_put(dev->of_node);
-out_get_ddc_adpt:
hdata->ddc_adpt = of_find_i2c_adapter_by_node(ddc_node);
if (!hdata->ddc_adpt) {
DRM_ERROR("Failed to get ddc i2c adapter by node\n");
--
1.9.1
Re: [PATCH 2/4] arm64: defconfig: Set cma heap size to 128MB
On 22 August 2016 at 17:06, Thierry Reding wrote: > On Fri, Aug 19, 2016 at 11:42:06PM +0800, Guodong Xu wrote: >> From: Xinliang Liu >> >> For debian linux, cma heap is used to allocate graphic buffers. >> The default size is 16 MB which is not enought. >> So increase the size to 128 MB. >> >> Signed-off-by: Xinliang Liu >> --- >> arch/arm64/configs/defconfig | 1 + >> 1 file changed, 1 insertion(+) > > This is a bad idea. You're increasing this heap for all users of the > default configuration (which on 64-bit ARM is everyone, really). Many of > the devices don't require the CMA except maybe for the occasional very > small buffer. Most implement some form of IOMMU support that removes the > need for large amounts of contiguous physical memory. > > I think it's a better idea to have some bootloader append a cma=128 to > the kernel command-line if necessary. > I will remove this. Thanks. -Guodong Xu > Thierry
Re: [RFC 00/11] THP swap: Delay splitting THP during swapping out
Minchan Kim writes: > Hi Huang, > > On my side, there are more urgent works now so I didn't have a time to > see our ongoing discussion. I will continue after settle down works, > maybe next week. Sorry. No problem. Thanks for your review so far! > On Mon, Aug 22, 2016 at 02:33:08PM -0700, Huang, Ying wrote: >> Hi, Minchan, >> >> Minchan Kim writes: >> > Anyway, I hope [1/11] should be merged regardless of the patchset because >> > I believe anyone doesn't feel comfortable with cluser_info functions. ;-) >> >> I want to send out 1/11 separately. Can I add your "Acked-by:" for it? > > Sure. Thanks! Best Regards, Huang, Ying
Re: [RFC 00/11] THP swap: Delay splitting THP during swapping out
Hi Huang, On my side, there are more urgent works now so I didn't have a time to see our ongoing discussion. I will continue after settle down works, maybe next week. Sorry. On Mon, Aug 22, 2016 at 02:33:08PM -0700, Huang, Ying wrote: > Hi, Minchan, > > Minchan Kim writes: > > Anyway, I hope [1/11] should be merged regardless of the patchset because > > I believe anyone doesn't feel comfortable with cluser_info functions. ;-) > > I want to send out 1/11 separately. Can I add your "Acked-by:" for it? Sure. Thanks.
Re: [PATCH] treewide: replace config_enabled() with IS_ENABLED() (2nd round)
On Tue, Aug 23, 2016 at 12:45 PM, Masahiro Yamada
wrote:
> Commit 97f2645f358b ("tree-wide: replace config_enabled() with
> IS_ENABLED()") mostly killed config_enabled(), but some new users
> have appeared for v4.8-rc1. They are all used for a boolean option,
> so can be replaced with IS_ENABLED() safely.
>
> Signed-off-by: Masahiro Yamada
Acked-by: Kees Cook
-Kees
> ---
>
> arch/mips/include/asm/page.h | 4 ++--
> arch/s390/kernel/setup.c | 6 ++
> arch/x86/mm/kaslr.c | 2 +-
> 3 files changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/arch/mips/include/asm/page.h b/arch/mips/include/asm/page.h
> index ea0cd97..5f98759 100644
> --- a/arch/mips/include/asm/page.h
> +++ b/arch/mips/include/asm/page.h
> @@ -164,7 +164,7 @@ typedef struct { unsigned long pgprot; } pgprot_t;
> */
> static inline unsigned long ___pa(unsigned long x)
> {
> - if (config_enabled(CONFIG_64BIT)) {
> + if (IS_ENABLED(CONFIG_64BIT)) {
> /*
> * For MIPS64 the virtual address may either be in one of
> * the compatibility segements ckseg0 or ckseg1, or it may
> @@ -173,7 +173,7 @@ static inline unsigned long ___pa(unsigned long x)
> return x < CKSEG0 ? XPHYSADDR(x) : CPHYSADDR(x);
> }
>
> - if (!config_enabled(CONFIG_EVA)) {
> + if (!IS_ENABLED(CONFIG_EVA)) {
> /*
> * We're using the standard MIPS32 legacy memory map, ie.
> * the address x is going to be in kseg0 or kseg1. We can
> diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
> index ba5f456..7f7ba5f2 100644
> --- a/arch/s390/kernel/setup.c
> +++ b/arch/s390/kernel/setup.c
> @@ -204,11 +204,9 @@ static void __init conmode_default(void)
> #endif
> }
> } else if (MACHINE_IS_KVM) {
> - if (sclp.has_vt220 &&
> - config_enabled(CONFIG_SCLP_VT220_CONSOLE))
> + if (sclp.has_vt220 && IS_ENABLED(CONFIG_SCLP_VT220_CONSOLE))
> SET_CONSOLE_VT220;
> - else if (sclp.has_linemode &&
> -config_enabled(CONFIG_SCLP_CONSOLE))
> + else if (sclp.has_linemode && IS_ENABLED(CONFIG_SCLP_CONSOLE))
> SET_CONSOLE_SCLP;
> else
> SET_CONSOLE_HVC;
> diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
> index ec8654f..bda8d5e 100644
> --- a/arch/x86/mm/kaslr.c
> +++ b/arch/x86/mm/kaslr.c
> @@ -77,7 +77,7 @@ static inline unsigned long get_padding(struct
> kaslr_memory_region *region)
> */
> static inline bool kaslr_memory_enabled(void)
> {
> - return kaslr_enabled() && !config_enabled(CONFIG_KASAN);
> + return kaslr_enabled() && !IS_ENABLED(CONFIG_KASAN);
> }
>
> /* Initialize base and padding for each memory region randomized with KASLR
> */
> --
> 1.9.1
>
--
Kees Cook
Nexus Security
Re: [PATCH] memremap: Fix NULL pointer BUG in get_zone_device_page()
On Tue, 2016-08-23 at 13:42 -0700, Andrew Morton wrote: > On Tue, 23 Aug 2016 12:43:20 -0600 Toshi Kani > wrote: > > > > > The following BUG was observed while starting up KVM with nvdimm > > device as memory-backend-file to /dev/dax. > > > > BUG: unable to handle kernel NULL pointer dereference at > > 0008 > > > > ... > > > > devm_memremap_pages() calls for_each_device_pfn() to walk through > > all pfns in page_map. pfn_first(), however, returns a wrong pfn > > that leaves page->pgmap uninitialized. > > > > Since arch_add_memory() has set up direct mappings to the NVDIMM > > range with altmap, pfn_first() should not modify the start pfn. > > Change pfn_first() to simply return pfn of res->start. > > Which kernel version(s) do you think need fixing? The fix applies to v4.5 and newer versions. Thanks, -Toshi
[PATCH v2 1/2] PCI: quirk fixup for cavium invalid sriov link value.
From: Ananth Jasty
Cavium cn88xx hardware presents an incorrect SR-IOV Function
Dependency Link, add a fixup quirk for the affected devices.
Acked-by: David Daney
Signed-off-by: Ananth Jasty
Signed-off-by: Omer Khaliq
---
drivers/pci/quirks.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 37ff015..5980aae 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -834,6 +834,17 @@ static void quirk_amd_ioapic(struct pci_dev *dev)
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_VIPER_7410,
quirk_amd_ioapic);
#endif /* CONFIG_X86_IO_APIC */
+#ifdef CONFIG_ARM64
+
+static void quirk_cavium_sriov_rnm_link(struct pci_dev *dev)
+{
+ /* Fix for improper SRIOV configuration on Cavium cn88xx RNM device */
+ if (dev->subsystem_device == 0xa118)
+ dev->sriov->link = dev->devfn;
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CAVIUM, 0xa018,
quirk_cavium_sriov_rnm_link);
+#endif
+
/*
* Some settings of MMRBC can lead to data corruption so block changes.
* See AMD 8131 HyperTransport PCI-X Tunnel Revision Guide
--
1.9.1
