Re: [PATCH v15 00/16] drm/i915: Implement HDCP2.2
On Mon, Feb 25, 2019 at 05:12:09AM +, C, Ramalingam wrote: > Tomas, > > Lkp issue is complaining about the header drm/i915_mei_hdcp_interface.h, > Which is already merged in drm-tip through below commit. So don’t think > this is a genuine issue. May be this build was tried in different tree, > where this commit is not added yet? Yeah our topic trees aren't pushed into linux-next, 0day can't find them. Usually it will then fail to apply (and in that case it doesn't complain), but it does complain if everything applies but doesn't build. -Daniel > > commit 1626eab70ebc61d015e69a4bc3479d9228539343 > Author: Ramalingam C > Date: Fri Feb 15 14:04:58 2019 +0530 > > drm/i915: header for i915 - MEI_HDCP interface > > v15 is now part of github. > > Best Regards, > Ramalingam C > > > > -Original Message- > > From: Winkler, Tomas > > Sent: Monday, February 25, 2019 1:45 AM > > To: C, Ramalingam ; intel-...@lists.freedesktop.org; > > dri-devel@lists.freedesktop.org; daniel.vet...@ffwll.ch; Shankar, Uma > > > > Subject: RE: [PATCH v15 00/16] drm/i915: Implement HDCP2.2 > > > > Have you fixed the lkp issue? > > I didn't see you pushed the code to github. > > Thanks > > > > > > > -Original Message- > > > From: C, Ramalingam > > > Sent: Sunday, February 24, 2019 18:33 > > > To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; > > > daniel.vet...@ffwll.ch; Winkler, Tomas ; > > > Shankar, Uma > > > Subject: Re: [PATCH v15 00/16] drm/i915: Implement HDCP2.2 > > > > > > Tomas, > > > > > > Could you please help to review and give final "Go" for the series? > > > > > > Thanks > > > --Ram. > > > > > > On 2/21/2019 11:41 PM, Ramalingam C wrote: > > > > This series enables the HDCP2.2 Type 0 for I915. The sequence for > > > > HDCP2.2 authentication and encryption is implemented as a generic > > > > flow between HDMI and DP. Encoder specific implementations are moved > > > > into hdcp_shim. > > > > > > > > Intel HWs supports HDCP2.2 through ME FW. Hence this series > > > > introduces a client driver for mei bus, so that for HDCP2.2 > > > > authentication, > > > > HDCP2.2 stack in I915 can avail the services from ME FW. To enable > > > > this client driver set the config variable CONFIG_INTEL_MEI_HDCP. > > > > > > > > Userspace interface remains unchanged as version agnostic. When > > > > userspace request for HDCP enable, Kernel will detect the HDCP > > > > source and sink's HDCP version(1.4/2.2)capability and enable the > > > > best capable version for that combination. > > > > > > > > This series enables the HDCP2.2 for Type0 content streams. > > > > > > > > Test-with: > > > > <1549566452-30175-1-git-send-email-ramalinga...@intel.com> > > > > So that CP will be tested on BAT machine too. > > > > > > > > Major changes in v15 > > > >- All I915 patches are merged. So dropping them. > > > >- Few minor suggestions are incorporated at mei changes. > > > > > > > > To ease the review process, series is hosted at > > > > https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_v15 > > > > > > > > Ramalingam C (15): > > > >misc/mei/hdcp: Client driver for HDCP application > > > >misc/mei/hdcp: Define ME FW interface for HDCP2.2 > > > >misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session > > > >misc/mei/hdcp: Verify Receiver Cert and prepare km > > > >misc/mei/hdcp: Verify H_prime > > > >misc/mei/hdcp: Store the HDCP Pairing info > > > >misc/mei/hdcp: Initiate Locality check > > > >misc/mei/hdcp: Verify L_prime > > > >misc/mei/hdcp: Prepare Session Key > > > >misc/mei/hdcp: Repeater topology verification and ack > > > >misc/mei/hdcp: Verify M_prime > > > >misc/mei/hdcp: Enabling the HDCP authentication > > > >misc/mei/hdcp: Closing wired HDCP2.2 Tx Session > > > >misc/mei/hdcp: Component framework for I915 Interface > > > >FOR_TEST_ONLY: i915/Kconfig: Select mei_hdcp by I915 > > > > > > > > Tomas Winkler (1): > > > >mei: bus: whitelist hdcp client > > > > > > > > drivers/misc/mei/Kconfig | 11 + > > > > drivers/misc/mei/Makefile| 2 + > > > > drivers/misc/mei/bus-fixup.c | 16 + > > > > drivers/misc/mei/hdcp/Makefile | 7 + > > > > drivers/misc/mei/hdcp/mei_hdcp.c | 849 > > > +++ > > > > drivers/misc/mei/hdcp/mei_hdcp.h | 377 + > > > > 6 files changed, 1262 insertions(+) > > > > create mode 100644 drivers/misc/mei/hdcp/Makefile > > > > create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.c > > > > create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.h > > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 3/3] drm/qxl: remove conflicting framebuffers earlier
Add error checking while being at it. Signed-off-by: Gerd Hoffmann Reviewed-by: Daniel Vetter --- drivers/gpu/drm/qxl/qxl_drv.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c index bb81e310eb6d..578d867a81d5 100644 --- a/drivers/gpu/drm/qxl/qxl_drv.c +++ b/drivers/gpu/drm/qxl/qxl_drv.c @@ -79,6 +79,10 @@ qxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) if (ret) goto free_dev; + ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0, "qxl"); + if (ret) + goto disable_pci; + ret = qxl_device_init(qdev, &qxl_driver, pdev); if (ret) goto disable_pci; @@ -94,7 +98,6 @@ qxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) if (ret) goto modeset_cleanup; - drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0, "qxl"); drm_fbdev_generic_setup(&qdev->ddev, 32); return 0; -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/6] R-Car DU DPAD support for D3 and E3
Hi Morimoto-san, On Mon, Feb 25, 2019 at 04:44:55PM +0900, Kuninori Morimoto wrote: > > Hi Laurent > > > For your convenience the patches are available from > > > > git://linuxtv.org/pinchartl/media.git drm/du/d3e3 > > It seems we can't find this branch/tag on your branch > Is it removed ? or not yet pushed ? > > https://git.linuxtv.org/pinchartl/media.git/refs/heads The branch has been merged to drm-next (for the DU driver part) and to Simon's next branch (for the DT part), so I've removed it from my tree. You can find a merge of those two branches in my repository in the drm/du/base branch. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/3] drm/fb-helper: call vga_remove_vgacon automatically.
Add vga_remove_vgacon() call to
drm_fb_helper_remove_conflicting_pci_framebuffers().
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
include/drm/drm_fb_helper.h | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index bb9acea61369..286d58efed5d 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -36,6 +36,7 @@ struct drm_fb_helper;
#include
#include
#include
+#include
enum mode_set_atomic {
LEAVE_ATOMIC_MODE_SET,
@@ -642,11 +643,18 @@ drm_fb_helper_remove_conflicting_pci_framebuffers(struct
pci_dev *pdev,
int resource_id,
const char *name)
{
+ int ret = 0;
+
+ /*
+* WARNING: Apparently we must kick fbdev drivers before vgacon,
+* otherwise the vga fbdev driver falls over.
+*/
#if IS_REACHABLE(CONFIG_FB)
- return remove_conflicting_pci_framebuffers(pdev, resource_id, name);
-#else
- return 0;
+ ret = remove_conflicting_pci_framebuffers(pdev, resource_id, name);
#endif
+ if (ret == 0)
+ ret = vga_remove_vgacon(pdev);
+ return ret;
}
#endif
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 0/3] drm & vgaarb: handle vgacon removal in vgaarb.
v6: buildfix. Gerd Hoffmann (3): drm: move i915_kick_out_vgacon to vgaarb drm/fb-helper: call vga_remove_vgacon automatically. drm/qxl: remove conflicting framebuffers earlier include/drm/drm_fb_helper.h | 14 +--- include/linux/vgaarb.h | 2 ++ drivers/gpu/drm/i915/i915_drv.c | 35 +- drivers/gpu/drm/qxl/qxl_drv.c | 5 - drivers/gpu/vga/vgaarb.c| 48 + 5 files changed, 66 insertions(+), 38 deletions(-) -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/3] drm: move i915_kick_out_vgacon to vgaarb
Also rename it to vga_remove_vgacon and add kerneldoc text.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
include/linux/vgaarb.h | 2 ++
drivers/gpu/drm/i915/i915_drv.c | 35 +-
drivers/gpu/vga/vgaarb.c| 48 +
3 files changed, 51 insertions(+), 34 deletions(-)
diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h
index ee162e3e879b..553b34c8b5f7 100644
--- a/include/linux/vgaarb.h
+++ b/include/linux/vgaarb.h
@@ -125,9 +125,11 @@ extern void vga_put(struct pci_dev *pdev, unsigned int
rsrc);
#ifdef CONFIG_VGA_ARB
extern struct pci_dev *vga_default_device(void);
extern void vga_set_default_device(struct pci_dev *pdev);
+extern int vga_remove_vgacon(struct pci_dev *pdev);
#else
static inline struct pci_dev *vga_default_device(void) { return NULL; };
static inline void vga_set_default_device(struct pci_dev *pdev) { };
+static inline int vga_remove_vgacon(struct pci_dev *pdev) { return 0; };
#endif
/*
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6630212f2faf..9df65d386d11 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -757,39 +757,6 @@ static int i915_kick_out_firmware_fb(struct
drm_i915_private *dev_priv)
return ret;
}
-#if !defined(CONFIG_VGA_CONSOLE)
-static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
-{
- return 0;
-}
-#elif !defined(CONFIG_DUMMY_CONSOLE)
-static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
-{
- return -ENODEV;
-}
-#else
-static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
-{
- int ret = 0;
-
- DRM_INFO("Replacing VGA console driver\n");
-
- console_lock();
- if (con_is_bound(&vga_con))
- ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1,
1);
- if (ret == 0) {
- ret = do_unregister_con_driver(&vga_con);
-
- /* Ignore "already unregistered". */
- if (ret == -ENODEV)
- ret = 0;
- }
- console_unlock();
-
- return ret;
-}
-#endif
-
static void intel_init_dpio(struct drm_i915_private *dev_priv)
{
/*
@@ -1420,7 +1387,7 @@ static int i915_driver_init_hw(struct drm_i915_private
*dev_priv)
goto err_ggtt;
}
- ret = i915_kick_out_vgacon(dev_priv);
+ ret = vga_remove_vgacon(pdev);
if (ret) {
DRM_ERROR("failed to remove conflicting VGA console\n");
goto err_ggtt;
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index dc8e039bfab5..dc817104e424 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -48,6 +48,8 @@
#include
#include
#include
+#include
+#include
#include
@@ -168,6 +170,52 @@ void vga_set_default_device(struct pci_dev *pdev)
vga_default = pci_dev_get(pdev);
}
+/**
+ * vga_remove_vgacon - deactivete vga console
+ *
+ * Unbind and unregister vgacon in case pdev is the default vga
+ * device. Can be called by gpu drivers on initialization to make
+ * sure vga register access done by vgacon will not disturb the
+ * device.
+ *
+ * @pdev: pci device.
+ */
+#if !defined(CONFIG_VGA_CONSOLE)
+int vga_remove_vgacon(struct pci_dev *pdev)
+{
+return 0;
+}
+#elif !defined(CONFIG_DUMMY_CONSOLE)
+int vga_remove_vgacon(struct pci_dev *pdev)
+{
+return -ENODEV;
+}
+#else
+int vga_remove_vgacon(struct pci_dev *pdev)
+{
+int ret = 0;
+
+ if (pdev != vga_default)
+ return 0;
+ vgaarb_info(&pdev->dev, "deactivate vga console\n");
+
+console_lock();
+if (con_is_bound(&vga_con))
+ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1,
1);
+if (ret == 0) {
+ret = do_unregister_con_driver(&vga_con);
+
+/* Ignore "already unregistered". */
+if (ret == -ENODEV)
+ret = 0;
+}
+console_unlock();
+
+return ret;
+}
+#endif
+EXPORT_SYMBOL(vga_remove_vgacon);
+
static inline void vga_irq_set_state(struct vga_device *vgadev, bool state)
{
if (vgadev->irq_set_state)
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] drm: move i915_kick_out_vgacon to vgaarb
On Fri, Feb 22, 2019 at 06:20:11PM +0100, Daniel Vetter wrote: > On Fri, Feb 22, 2019 at 12:03 PM Gerd Hoffmann wrote: > > > > Hi, > > > > > > - /* > > > > -* WARNING: Apparently we must kick fbdev drivers before vgacon, > > > > -* otherwise the vga fbdev driver falls over. > > > > -*/ > > > > ret = i915_kick_out_firmware_fb(dev_priv); > > > > > > This needs to be replaced with a call to > > > drm_fb_helper_remove_conflicting_pci_framebuffers, because the above > > > wrapper hasn't been converted yet. Otherwise you end up removing the > > > vgacon unbind from i915. > > > > Ah, little but important difference I didn't notice on the first look. > > That wrapper calls the non-pci version. But seems it isn't that easy > > to switch over because the framebuffer is in stolen memory instead of a > > pci bar ... > > stolen memory is where the fb physically resides. the pci bar is how > you access it (as long as you take all the pci bars). From a quick > look i915 and pci version of remove_conflicting_fb matched. Well, it is ap->ranges[0].base = ggtt->gmadr.start; ap->ranges[0].size = ggtt->mappable_end; vs. ap->ranges[0].base = pci_resource_start(pdev, res_id); ap->ranges[0].size = pci_resource_len(pdev, res_id); So not obvious that they are the same. At least to me, maybe it is a different story for someone knowing the i915 driver better. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: INFO: trying to register non-static key in __flush_work
On Sun, Feb 24, 2019 at 12:40:19PM -0800, David Rientjes wrote: > On Sat, 29 Dec 2018, syzbot wrote: > > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit:5694cecdb092 Merge tag 'arm64-upstream' of git://git.kerne.. > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=124eebc740 > > kernel config: https://syzkaller.appspot.com/x/.config?x=91a256823ef17263 > > dashboard link: https://syzkaller.appspot.com/bug?extid=12f1b031b6da017e34f8 > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1174a1dd40 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1336e38b40 > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+12f1b031b6da017e3...@syzkaller.appspotmail.com > > > > INFO: trying to register non-static key. > > the code is fine but needs lockdep annotation. > > turning off the locking correctness validator. > > CPU: 0 PID: 8039 Comm: syz-executor964 Not tainted 4.20.0+ #389 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > Google > > 01/01/2011 > > Call Trace: > > __dump_stack lib/dump_stack.c:77 [inline] > > dump_stack+0x1d3/0x2c6 lib/dump_stack.c:113 > > assign_lock_key kernel/locking/lockdep.c:727 [inline] > > register_lock_class+0x21c5/0x29d0 kernel/locking/lockdep.c:753 > > __lock_acquire+0x184/0x4c20 kernel/locking/lockdep.c:3227 > > lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844 > > __flush_work+0x752/0x9b0 kernel/workqueue.c:2912 > > flush_work+0x17/0x20 kernel/workqueue.c:2938 > > vkms_atomic_crtc_destroy_state+0x2b/0x40 > > drivers/gpu/drm/vkms/vkms_crtc.c:139 > > drm_atomic_state_default_clear+0x37c/0xda0 drivers/gpu/drm/drm_atomic.c:171 > > drm_atomic_state_clear+0x9f/0xd0 drivers/gpu/drm/drm_atomic.c:240 > > __drm_atomic_state_free+0x3a/0xf0 drivers/gpu/drm/drm_atomic.c:256 > > kref_put include/linux/kref.h:70 [inline] > > drm_atomic_state_put include/drm/drm_atomic.h:385 [inline] > > drm_atomic_helper_set_config+0xe6/0x160 > > drivers/gpu/drm/drm_atomic_helper.c:2947 > > drm_mode_setcrtc+0x767/0x1890 drivers/gpu/drm/drm_crtc.c:748 > > drm_ioctl_kernel+0x278/0x330 drivers/gpu/drm/drm_ioctl.c:758 > > drm_ioctl+0x58f/0xb90 drivers/gpu/drm/drm_ioctl.c:858 > > vfs_ioctl fs/ioctl.c:46 [inline] > > file_ioctl fs/ioctl.c:509 [inline] > > do_vfs_ioctl+0x1de/0x1790 fs/ioctl.c:696 > > ksys_ioctl+0xa9/0xd0 fs/ioctl.c:713 > > __do_sys_ioctl fs/ioctl.c:720 [inline] > > __se_sys_ioctl fs/ioctl.c:718 [inline] > > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 > > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > RIP: 0033:0x443e59 > > Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 > > 48 > > 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f > > 83 7b d8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > > RSP: 002b:7fff2bc037c8 EFLAGS: 0213 ORIG_RAX: 0010 > > RAX: ffda RBX: 004002e0 RCX: 00443e59 > > RDX: 2100 RSI: c06864a2 RDI: 0003 > > RBP: 006ce018 R08: R09: 004002e0 > > R10: 000f R11: 0213 R12: 00401b60 > > R13: 00401bf0 R14: R15: 0 > > > > This is reproducible up to at least > > commit e60b5f79bd7529e76b13cf1e85823abbd0e33634 > Merge: 6089a91fc02e 8f5b27347e88 > Author: Linus Torvalds > Date: Sat Feb 23 11:13:50 2019 -0800 > > Merge tag 'powerpc-5.0-6' of > git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux > > and my theory is that it's due to this: > > commit dfb9f5cabfe31b8e936b725b5de8f787f7c18b0f > Author: Haneen Mohammed > Date: Tue Jul 24 19:31:05 2018 +0300 > > drm/vkms: subclass CRTC state > > in 4.20-rc1. We aren't doing INIT_WORK() for the workqueue that is being > flushed. > > Don't we need to do INIT_WORK() in vkms_atomic_crtc_reset() too? Patch is in linux-next: commit b30b61ff6b1dc37f276cf56a8328b80086a3ffca Author: Tetsuo Handa Date: Sat Jan 19 01:43:43 2019 +0900 drm/vkms: Fix flush_work() without INIT_WORK() Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/2] dt-bindings: drm: panel: Add Samsung s6e63m0 panel documentation
From: Jonathan Bakker
This commit adds documentation for Samsung s6e63m0 AMOLED LCD panel
driver.
Signed-off-by: Jonathan Bakker
Signed-off-by: Paweł Chmiel
Reviewed-by: Rob Herring
---
Changes from v2:
- Added Reviewed-by
Changes from v1:
- Add missing subject prefix
- Rename reset-gpio to reset-gpios
- Add link to spi properites documentation. They're required
for driver to work
- Removed delay properties, which are now hardcoded in driver
- Removed display timings, which are now hardcoded in driver
---
.../display/panel/samsung,s6e63m0.txt | 33 +++
1 file changed, 33 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt
b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt
new file mode 100644
index ..9fb9ebeef8e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt
@@ -0,0 +1,33 @@
+Samsung s6e63m0 AMOLED LCD panel
+
+Required properties:
+ - compatible: "samsung,s6e63m0"
+ - reset-gpios: GPIO spec for reset pin
+ - vdd3-supply: VDD regulator
+ - vci-supply: VCI regulator
+
+The panel must obey rules for SPI slave device specified in document [1].
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [2]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/spi/spi-bus.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ s6e63m0: display@0 {
+ compatible = "samsung,s6e63m0";
+ reg = <0>;
+ reset-gpio = <&mp05 5 1>;
+ vdd3-supply = <&ldo12_reg>;
+ vci-supply = <&ldo11_reg>;
+ spi-max-frequency = <120>;
+
+ port {
+ lcd_ep: endpoint {
+ remote-endpoint = <&fimd_ep>;
+ };
+ };
+ };
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1] drm/tegra: plane: Remove format-modifier checking
Tiling modifier can't be applied to YV12 video overlay because all tiling
modifiers are filtered out for multi-plane formats. AFAIK, all modifiers
should work with all of formats, hence the checking is incorrect and
simply not needed.
Fixes: e90124cb46bdb ("drm/tegra: plane: Support format modifiers")
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/plane.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/gpu/drm/tegra/plane.c b/drivers/gpu/drm/tegra/plane.c
index d068e8aa3553..5a8a3387f5ee 100644
--- a/drivers/gpu/drm/tegra/plane.c
+++ b/drivers/gpu/drm/tegra/plane.c
@@ -72,21 +72,6 @@ static void tegra_plane_atomic_destroy_state(struct
drm_plane *plane,
kfree(state);
}
-static bool tegra_plane_format_mod_supported(struct drm_plane *plane,
-uint32_t format,
-uint64_t modifier)
-{
- const struct drm_format_info *info = drm_format_info(format);
-
- if (modifier == DRM_FORMAT_MOD_LINEAR)
- return true;
-
- if (info->num_planes == 1)
- return true;
-
- return false;
-}
-
const struct drm_plane_funcs tegra_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
@@ -94,7 +79,6 @@ const struct drm_plane_funcs tegra_plane_funcs = {
.reset = tegra_plane_reset,
.atomic_duplicate_state = tegra_plane_atomic_duplicate_state,
.atomic_destroy_state = tegra_plane_atomic_destroy_state,
- .format_mod_supported = tegra_plane_format_mod_supported,
};
int tegra_plane_state_add(struct tegra_plane *plane,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
MGA G200 Driver fatal error during GPU init
Hi Dave, On kernel versions 4.20 and greater, the MGA G200 driver has a fatal error during GPU init and the KVM console I use hangs. I still can ssh into the machine, however. The log and some basic info is below. This error is 100% reproducible for me, on different machines. With kernel 4.19, I don't see any error and the KVM console works correctly. Please let me know if you need any more information. (Also, I wasn't sure which email to use, the DRM drivers maintainer email is the linux.ie one and the mgag200 maintainer email is the redhat.com one, so I sent it to both). Thanks, Oliver [2.297347] pstore: Unknown compression: deflate [2.297362] fbcon: Taking over console [2.297465] Console: switching to colour frame buffer device 128x48 [snip] [3.053910] fb0: switching to mgag200drmfb from simple [3.053946] Console: switching to colour dummy device 80x25 [3.054377] [drm:mgag200_driver_load [mgag200]] *ERROR* can't reserve VRAM [3.054383] mgag200 :03:00.0: Fatal error during GPU init: -6 # lspci | grep -i vga 03:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 42) # modinfo mgag200 filename: /lib/modules/5.0.0-rc7-next-20190220+/kernel/drivers/gpu/drm/mgag200/mgag200.ko license:GPL description:MGA G200 SE author: Matthew Garrett srcversion: B5EC0E424CE53736E84252D alias: pci:v102Bd0538sv*sd*bc*sc*i* alias: pci:v102Bd0536sv*sd*bc*sc*i* alias: pci:v102Bd0534sv*sd*bc*sc*i* alias: pci:v102Bd0533sv*sd*bc*sc*i* alias: pci:v102Bd0532sv*sd*bc*sc*i* alias: pci:v102Bd0530sv*sd*bc*sc*i* alias: pci:v102Bd0524sv*sd*bc*sc*i* alias: pci:v102Bd0522sv*sd*bc*sc*i* depends:drm,drm_kms_helper,ttm,i2c-algo-bit retpoline: Y intree: Y name: mgag200 vermagic: 5.0.0-rc7-next-20190220+ SMP mod_unload modversions parm: modeset:Disable/Enable modesetting (int) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 4/9] mm/mmu_notifier: contextual information for event enums
On 2/19/19 12:04 PM, jgli...@redhat.com wrote:
From: Jérôme Glisse
CPU page table update can happens for many reasons, not only as a result
s/update/updates
s/happens/happen
of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
as a result of kernel activities (memory compression, reclaim, migration,
...).
This patch introduce a set of enums that can be associated with each of
s/introduce/introduces
the events triggering a mmu notifier. Latter patches take advantages of
those enum values.
s/advantages/advantage
- UNMAP: munmap() or mremap()
- CLEAR: page table is cleared (migration, compaction, reclaim, ...)
- PROTECTION_VMA: change in access protections for the range
- PROTECTION_PAGE: change in access protections for page in the range
- SOFT_DIRTY: soft dirtyness tracking
s/dirtyness/dirtiness
Being able to identify munmap() and mremap() from other reasons why the
page table is cleared is important to allow user of mmu notifier to
update their own internal tracking structure accordingly (on munmap or
mremap it is not longer needed to track range of virtual address as it
becomes invalid).
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Jan Kara
Cc: Andrea Arcangeli
Cc: Peter Xu
Cc: Felix Kuehling
Cc: Jason Gunthorpe
Cc: Ross Zwisler
Cc: Dan Williams
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Michal Hocko
Cc: Christian Koenig
Cc: Ralph Campbell
Cc: John Hubbard
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: Arnd Bergmann
---
include/linux/mmu_notifier.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index c8672c366f67..2386e71ac1b8 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -10,6 +10,36 @@
struct mmu_notifier;
struct mmu_notifier_ops;
+/**
+ * enum mmu_notifier_event - reason for the mmu notifier callback
+ * @MMU_NOTIFY_UNMAP: either munmap() that unmap the range or a mremap() that
+ * move the range
I would say something about the VMA for the notifier range
is being deleted.
MMU notifier clients can then use this case to remove any policy or
access counts associated with the range.
Just changing the PTE to "no access" as in the CLEAR case
doesn't mean a policy which prefers device private memory
over system memory should be cleared.
+ *
+ * @MMU_NOTIFY_CLEAR: clear page table entry (many reasons for this like
+ * madvise() or replacing a page by another one, ...).
+ *
+ * @MMU_NOTIFY_PROTECTION_VMA: update is due to protection change for the range
+ * ie using the vma access permission (vm_page_prot) to update the whole range
+ * is enough no need to inspect changes to the CPU page table (mprotect()
+ * syscall)
+ *
+ * @MMU_NOTIFY_PROTECTION_PAGE: update is due to change in read/write flag for
+ * pages in the range so to mirror those changes the user must inspect the CPU
+ * page table (from the end callback).
+ *
+ * @MMU_NOTIFY_SOFT_DIRTY: soft dirty accounting (still same page and same
+ * access flags). User should soft dirty the page in the end callback to make
+ * sure that anyone relying on soft dirtyness catch pages that might be written
+ * through non CPU mappings.
+ */
+enum mmu_notifier_event {
+ MMU_NOTIFY_UNMAP = 0,
+ MMU_NOTIFY_CLEAR,
+ MMU_NOTIFY_PROTECTION_VMA,
+ MMU_NOTIFY_PROTECTION_PAGE,
+ MMU_NOTIFY_SOFT_DIRTY,
+};
+
#ifdef CONFIG_MMU_NOTIFIER
/*
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/34] drm: Convert crtc_idr to XArray
On Fri, Feb 22, 2019 at 10:40:14AM +0100, Daniel Vetter wrote: > On Thu, Feb 21, 2019 at 10:41:41AM -0800, Matthew Wilcox wrote: > > - Rename it to 'objects', as requested in todo.rst > > Yay, thanks! > > > - Also convert leases IDR to XArray as the two are occasionally used by > >the same code (see drm_mode_get_lease_ioctl()) > > - Refactor drm_mode_create_lease_ioctl() to create the new drm_master > >early to avoid creating an XArray on the stack and reparenting it > >afterwards. > > All lgtm, also the idr_replace replacement. > > One thing I wonder: For the lesse object xa, we really only store 0/1 in > there, and I don't think that'll change. There was once the idea that we'd > look up objects for a lease directly, bypassing the main object idr. But > that doesn't work due to unregister/hotunplug rules, or at least it would > be pain not worth having. Might be worth it to a lookup structure > optimized for that. Or does XA already autocompress that for us? The > object id are likely fairly compressed, good chance all the ones you need > for a lease will fit into the first 64 id. The XArray doesn't compress the contents of the user pointers. It might be worth augmenting the IDA to have all the functionality you need (there's no ida_test() today, for example). I didn't want to take that on as part of this project, and it's certainly no worse than the IDR. But it's on my radar along with a couple of other places in the kernel that could benefit from the IDA if only it had a couple of extra features (eg the fd table would like to an ida_for_each()). It'd involve changing drm_mode_get_lease_ioctl() and maybe a couple of other places where we use config.objects and leases interchangably, so I wasn't entirely convinced it'd be worth it. > > +++ b/drivers/gpu/drm/drm_auth.c > > @@ -110,7 +110,7 @@ struct drm_master *drm_master_create(struct drm_device > > *dev) > > /* initialize the tree of output resource lessees */ > > master->lessor = NULL; > > master->lessee_id = 0; > > - idr_init(&master->leases); > > + xa_init(&master->leases); > > XA_FALGS_ALLOC1, for safety to make sure we never store 0 (considered > invalid id throughout at least modern drm)? This xarray turns out not to be an allocating XArray, it's just one we store pointers in at a predetermined ID. Marking it as allocating wouldn't be terribly harmful, just slightly inefficient. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 1/3] drm/i2c: tda998x: implement different I2S flavours
Add support for the left and right justified I2S formats as well as the
more tranditional "Philips" I2S format.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 57 ++-
include/drm/i2c/tda998x.h | 11 +---
2 files changed, 47 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index a7c39f39793f..645d884fb9e8 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -242,7 +242,9 @@ struct tda998x_priv {
# define HVF_CNTRL_1_SEMI_PLANAR (1 << 6)
#define REG_RPT_CNTRL REG(0x00, 0xf0) /* write */
#define REG_I2S_FORMATREG(0x00, 0xfc) /* read/write */
-# define I2S_FORMAT(x)(((x) & 3) << 0)
+# define I2S_FORMAT_PHILIPS (0 << 0)
+# define I2S_FORMAT_LEFT_J(2 << 0)
+# define I2S_FORMAT_RIGHT_J (3 << 0)
#define REG_AIP_CLKSELREG(0x00, 0xfd) /* write */
# define AIP_CLKSEL_AIP_SPDIF(0 << 3)
# define AIP_CLKSEL_AIP_I2S (1 << 3)
@@ -872,14 +874,14 @@ static int
tda998x_configure_audio(struct tda998x_priv *priv,
struct tda998x_audio_params *params)
{
- u8 buf[6], clksel_aip, clksel_fs, cts_n, adiv;
+ u8 buf[6], clksel_aip, clksel_fs, cts_n, adiv, i2s_fmt;
u32 n;
/* Enable audio ports */
reg_write(priv, REG_ENA_AP, params->config);
/* Set audio input source */
- switch (params->format) {
+ switch (params->format & AFMT_MASK) {
case AFMT_SPDIF:
reg_write(priv, REG_ENA_ACLK, 0);
reg_write(priv, REG_MUX_AP, MUX_AP_SELECT_SPDIF);
@@ -907,6 +909,19 @@ tda998x_configure_audio(struct tda998x_priv *priv,
cts_n = CTS_N_M(3) | CTS_N_K(3);
break;
}
+
+ switch (params->format & AFMT_I2S_MASK) {
+ case AFMT_I2S_LEFT_J:
+ i2s_fmt = I2S_FORMAT_LEFT_J;
+ break;
+ case AFMT_I2S_RIGHT_J:
+ i2s_fmt = I2S_FORMAT_RIGHT_J;
+ break;
+ default:
+ i2s_fmt = I2S_FORMAT_PHILIPS;
+ break;
+ }
+ reg_write(priv, REG_I2S_FORMAT, i2s_fmt);
break;
default:
@@ -992,23 +1007,15 @@ static int tda998x_audio_hw_params(struct device *dev,
void *data,
switch (daifmt->fmt) {
case HDMI_I2S:
- if (daifmt->bit_clk_inv || daifmt->frame_clk_inv ||
- daifmt->bit_clk_master || daifmt->frame_clk_master) {
- dev_err(dev, "%s: Bad flags %d %d %d %d\n", __func__,
- daifmt->bit_clk_inv, daifmt->frame_clk_inv,
- daifmt->bit_clk_master,
- daifmt->frame_clk_master);
- return -EINVAL;
- }
- for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++)
- if (priv->audio_port[i].format == AFMT_I2S)
- audio.config = priv->audio_port[i].config;
- audio.format = AFMT_I2S;
+ audio.format = AFMT_I2S | AFMT_I2S_PHILIPS;
+ break;
+ case HDMI_LEFT_J:
+ audio.format = AFMT_I2S | AFMT_I2S_LEFT_J;
+ break;
+ case HDMI_RIGHT_J:
+ audio.format = AFMT_I2S | AFMT_I2S_RIGHT_J;
break;
case HDMI_SPDIF:
- for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++)
- if (priv->audio_port[i].format == AFMT_SPDIF)
- audio.config = priv->audio_port[i].config;
audio.format = AFMT_SPDIF;
break;
default:
@@ -1016,11 +1023,25 @@ static int tda998x_audio_hw_params(struct device *dev,
void *data,
return -EINVAL;
}
+ for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++)
+ if (priv->audio_port[i].format == (audio.format & AFMT_MASK))
+ audio.config = priv->audio_port[i].config;
+
if (audio.config == 0) {
dev_err(dev, "%s: No audio configuration found\n", __func__);
return -EINVAL;
}
+ if ((audio.format & AFMT_MASK) == HDMI_I2S &&
+ (daifmt->bit_clk_inv || daifmt->frame_clk_inv ||
+daifmt->bit_clk_master || daifmt->frame_clk_master)) {
+ dev_err(dev, "%s: Bad flags %d %d %d %d\n", __func__,
+ daifmt->bit_clk_inv, daifmt->frame_clk_inv,
+ daifmt->bit_clk_master,
+ daifmt->frame_clk_master);
+ return -EINVAL;
+ }
+
mutex_lock(&priv->audio_mutex);
if (priv->supports_infoframes && priv->sink_has_audio)
Re: [PATCH v5 3/9] mm/mmu_notifier: convert mmu_notifier_range->blockable to a flags
On 2/19/19 12:04 PM, jgli...@redhat.com wrote:
From: Jérôme Glisse
Use an unsigned field for flags other than blockable and convert
the blockable field to be one of those flags.
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Jan Kara
Cc: Andrea Arcangeli
Cc: Peter Xu
Cc: Felix Kuehling
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: Ross Zwisler
Cc: Dan Williams
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Michal Hocko
Cc: Christian Koenig
Cc: Ralph Campbell
Cc: John Hubbard
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: Arnd Bergmann
---
include/linux/mmu_notifier.h | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index e630def131ce..c8672c366f67 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -25,11 +25,13 @@ struct mmu_notifier_mm {
spinlock_t lock;
};
+#define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
+
struct mmu_notifier_range {
struct mm_struct *mm;
unsigned long start;
unsigned long end;
- bool blockable;
+ unsigned flags;
};
struct mmu_notifier_ops {
@@ -229,7 +231,7 @@ extern void __mmu_notifier_invalidate_range(struct
mm_struct *mm,
static inline bool
mmu_notifier_range_blockable(const struct mmu_notifier_range *range)
{
- return range->blockable;
+ return (range->flags & MMU_NOTIFIER_RANGE_BLOCKABLE);
}
static inline void mmu_notifier_release(struct mm_struct *mm)
@@ -275,7 +277,7 @@ static inline void
mmu_notifier_invalidate_range_start(struct mmu_notifier_range *range)
{
if (mm_has_notifiers(range->mm)) {
- range->blockable = true;
+ range->flags |= MMU_NOTIFIER_RANGE_BLOCKABLE;
__mmu_notifier_invalidate_range_start(range);
}
}
@@ -284,7 +286,7 @@ static inline int
mmu_notifier_invalidate_range_start_nonblock(struct mmu_notifier_range *range)
{
if (mm_has_notifiers(range->mm)) {
- range->blockable = false;
+ range->flags &= ~MMU_NOTIFIER_RANGE_BLOCKABLE;
return __mmu_notifier_invalidate_range_start(range);
}
return 0;
@@ -331,6 +333,7 @@ static inline void mmu_notifier_range_init(struct
mmu_notifier_range *range,
range->mm = mm;
range->start = start;
range->end = end;
+ range->flags = 0;
}
#define ptep_clear_flush_young_notify(__vma, __address, __ptep) \
Reviewed-by: Ralph Campbell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V6 3/8] drm/mediatek: using different flags of clk for HDMI phy
From: chunhui dai
The parent rate of hdmi phy had set by DPI driver.
We should not set or change the parent rate of MT2701 hdmi phy,
as a result we should remove the flags of "CLK_SET_RATE_PARENT"
from the clock of MT2701 hdmi phy.
Signed-off-by: chunhui dai
Signed-off-by: wangyan wang
---
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 13 +
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 1 +
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 1 +
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 1 +
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 13c5e65b9ead..370309d684ec 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -107,13 +107,11 @@ mtk_hdmi_phy_dev_get_ops(const struct mtk_hdmi_phy
*hdmi_phy)
return NULL;
}
-static void mtk_hdmi_phy_clk_get_ops(struct mtk_hdmi_phy *hdmi_phy,
-const struct clk_ops **ops)
+static void mtk_hdmi_phy_clk_get_data(struct mtk_hdmi_phy *hdmi_phy,
+struct clk_init_data *clk_init)
{
- if (hdmi_phy && hdmi_phy->conf && hdmi_phy->conf->hdmi_phy_clk_ops)
- *ops = hdmi_phy->conf->hdmi_phy_clk_ops;
- else
- dev_err(hdmi_phy->dev, "Failed to get clk ops of phy\n");
+ clk_init->flags = hdmi_phy->conf->flags;
+ clk_init->ops = hdmi_phy->conf->hdmi_phy_clk_ops;
}
static int mtk_hdmi_phy_probe(struct platform_device *pdev)
@@ -126,7 +124,6 @@ static int mtk_hdmi_phy_probe(struct platform_device *pdev)
struct clk_init_data clk_init = {
.num_parents = 1,
.parent_names = (const char * const *)&ref_clk_name,
- .flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_GATE,
};
struct phy *phy;
@@ -164,7 +161,7 @@ static int mtk_hdmi_phy_probe(struct platform_device *pdev)
hdmi_phy->dev = dev;
hdmi_phy->conf =
(struct mtk_hdmi_phy_conf *)of_device_get_match_data(dev);
- mtk_hdmi_phy_clk_get_ops(hdmi_phy, &clk_init.ops);
+ mtk_hdmi_phy_clk_get_data(hdmi_phy, &clk_init);
hdmi_phy->pll_hw.init = &clk_init;
hdmi_phy->pll = devm_clk_register(dev, &hdmi_phy->pll_hw);
if (IS_ERR(hdmi_phy->pll)) {
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index fdad8b17a915..446e2acd1926 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -21,6 +21,7 @@ struct mtk_hdmi_phy;
struct mtk_hdmi_phy_conf {
bool tz_disabled;
+ unsigned long flags;
const struct clk_ops *hdmi_phy_clk_ops;
void (*hdmi_phy_enable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
void (*hdmi_phy_disable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index b26fb7dbdb28..43bc058d5528 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -234,6 +234,7 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy
*hdmi_phy)
struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf = {
.tz_disabled = true,
+ .flags = CLK_SET_RATE_NO_REPARENT | CLK_SET_RATE_GATE,
.hdmi_phy_clk_ops = &mtk_hdmi_phy_pll_ops,
.hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
.hdmi_phy_disable_tmds = mtk_hdmi_phy_disable_tmds,
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index cb23c1e4692a..63dde42521b8 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -317,6 +317,7 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy
*hdmi_phy)
}
struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf = {
+ .flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_GATE,
.hdmi_phy_clk_ops = &mtk_hdmi_phy_pll_ops,
.hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
.hdmi_phy_disable_tmds = mtk_hdmi_phy_disable_tmds,
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/i2c: tda998x: adjust CTS_N audio pre-divider calculation
Russell, thank you so much for your patience, help and explanation, I really
appreciate it !
On Fri, Feb 22, 2019 at 3:16 PM Russell King - ARM Linux admin
wrote:
>
> A possible solution to that would be for hdmi-codec to default that to
> zero unless it's been definitively provided by the ASoC "card", which
> would allow the old behaviour of selecting the CTS_N M/K values
> depending on the sample width, which we know works for some people.
>
Yes, that would keep the current users in business without them having to
change anything.
Of course, poor souls like myself would have to patch, say, simple-card so we
could provide a bclk ratio in the devicetree. Which would then propagate down
to the tda998x via hdmi-codec. Which is fine by me.
Combining your two previous suggestions, I get the following. Now sample_width
can be removed from tda998x_audio_params, as it's no longer used.
Would this be a good start?
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index a7c39f39793f..a306994ecc79 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -893,19 +893,25 @@ tda998x_configure_audio(struct tda998x_priv *priv,
reg_write(priv, REG_MUX_AP, MUX_AP_SELECT_I2S);
clksel_aip = AIP_CLKSEL_AIP_I2S;
clksel_fs = AIP_CLKSEL_FS_ACLK;
- switch (params->sample_width) {
+ switch (params->bclk_ratio) {
case 16:
+ cts_n = CTS_N_M(3) | CTS_N_K(0);
+ break;
+ case 32:
cts_n = CTS_N_M(3) | CTS_N_K(1);
break;
- case 18:
- case 20:
- case 24:
+ case 48:
cts_n = CTS_N_M(3) | CTS_N_K(2);
break;
- default:
- case 32:
+ case 64:
cts_n = CTS_N_M(3) | CTS_N_K(3);
break;
+ case 128:
+ cts_n = CTS_N_M(0) | CTS_N_K(0);
+ break;
+ default:
+ dev_err(&priv->hdmi->dev, "unsupported I2S bclk
ratio\n");
+ return -EINVAL;
}
break;
@@ -982,7 +988,7 @@ static int tda998x_audio_hw_params(struct device *dev, void
*data,
struct tda998x_priv *priv = dev_get_drvdata(dev);
int i, ret;
struct tda998x_audio_params audio = {
- .sample_width = params->sample_width,
+ .bclk_ratio = daifmt->bclk_ratio,
.sample_rate = params->sample_rate,
.cea = params->cea,
};
@@ -1004,6 +1010,23 @@ static int tda998x_audio_hw_params(struct device *dev,
void *data,
if (priv->audio_port[i].format == AFMT_I2S)
audio.config = priv->audio_port[i].config;
audio.format = AFMT_I2S;
+ if (!audio.bclk_ratio) {
+ /* compatibility */
+ switch (params->sample_width) {
+ case 16:
+ audio.bclk_ratio = 32;
+ break;
+ case 18:
+ case 20:
+ case 24:
+ audio.bclk_ratio = 48;
+ break;
+ default:
+ case 32:
+ audio.bclk_ratio = 64;
+ break;
+ }
+ }
break;
case HDMI_SPDIF:
for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++)
diff --git a/include/drm/i2c/tda998x.h b/include/drm/i2c/tda998x.h
index 3cb25ccbe5e6..039e1d9af2e0 100644
--- a/include/drm/i2c/tda998x.h
+++ b/include/drm/i2c/tda998x.h
@@ -14,7 +14,7 @@ enum {
struct tda998x_audio_params {
u8 config;
u8 format;
- unsigned sample_width;
+ u8 bclk_ratio;
unsigned sample_rate;
struct hdmi_audio_infoframe cea;
u8 status[5];
diff --git a/include/sound/hdmi-codec.h b/include/sound/hdmi-codec.h
index 9483c55f871b..0fca69880dc3 100644
--- a/include/sound/hdmi-codec.h
+++ b/include/sound/hdmi-codec.h
@@ -42,6 +42,7 @@ struct hdmi_codec_daifmt {
unsigned int frame_clk_inv:1;
unsigned int bit_clk_master:1;
unsigned int frame_clk_master:1;
+ unsigned int bclk_ratio;
};
/*
diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index d00734d31e04..d82f26854c90 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -524,6 +524,17 @@ static int hdmi_codec_hw_params(struct snd_pcm_substream
*substream,
&hcp->daifmt[dai->id], &hp);
}
+static int hdmi_codec_set_bclk_ratio(stru
Re: [PATCH] drm/amd/display: Pass app_tf by value rather than by reference
On Mon, Dec 10, 2018 at 04:42:01PM -0700, Nathan Chancellor wrote:
> Clang warns when an expression that equals zero is used as a null
> pointer constant (in lieu of NULL):
>
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4435:3:
> warning: expression which evaluates to zero treated as a null pointer
> constant of type 'const enum color_transfer_func *'
> [-Wnon-literal-null-conversion]
> TRANSFER_FUNC_UNKNOWN,
> ^
> 1 warning generated.
>
> This warning is caused by commit bb47de736661 ("drm/amdgpu: Set FreeSync
> state using drm VRR properties") and it could be solved by using NULL
> instead of TRANSFER_FUNC_UNKNOWN or casting TRANSFER_FUNC_UNKNOWN as a
> pointer. However, after looking into it, there doesn't appear to be a
> good reason to pass app_tf by reference as it is never mutated along the
> way. This is the only code path in which app_tf is used:
>
> mod_freesync_build_vrr_infopacket ->
> build_vrr_infopacket_v2 ->
> build_vrr_infopacket_fs2_data
>
> Neither mod_freesync_build_vrr_infopacket or build_vrr_infopacket_v2
> modify app_tf's value and build_vrr_infopacket_fs2_data expects just
> the value so we can avoid dereferencing anything by just passing in
> app_tf's value to mod_freesync_build_vrr_infopacket and
> build_vrr_infopacket_v2.
>
> There is no functional change because build_vrr_infopacket_fs2_data
> doesn't do anything if TRANSFER_FUNC_UNKNOWN is passed to it, the same
> as not calling build_vrr_infopacket_fs2_data at all like before this
> change when NULL was used for app_tf.
>
> Signed-off-by: Nathan Chancellor
> ---
> drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 7 +++
> drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h | 2 +-
> 2 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> index 620a171620ee..520665a9d81a 100644
> --- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> +++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> @@ -656,7 +656,7 @@ static void build_vrr_infopacket_v1(enum signal_type
> signal,
>
> static void build_vrr_infopacket_v2(enum signal_type signal,
> const struct mod_vrr_params *vrr,
> - const enum color_transfer_func *app_tf,
> + enum color_transfer_func app_tf,
> struct dc_info_packet *infopacket)
> {
> unsigned int payload_size = 0;
> @@ -664,8 +664,7 @@ static void build_vrr_infopacket_v2(enum signal_type
> signal,
> build_vrr_infopacket_header_v2(signal, infopacket, &payload_size);
> build_vrr_infopacket_data(vrr, infopacket);
>
> - if (app_tf != NULL)
> - build_vrr_infopacket_fs2_data(*app_tf, infopacket);
> + build_vrr_infopacket_fs2_data(app_tf, infopacket);
>
> build_vrr_infopacket_checksum(&payload_size, infopacket);
>
> @@ -676,7 +675,7 @@ void mod_freesync_build_vrr_infopacket(struct
> mod_freesync *mod_freesync,
> const struct dc_stream_state *stream,
> const struct mod_vrr_params *vrr,
> enum vrr_packet_type packet_type,
> - const enum color_transfer_func *app_tf,
> + enum color_transfer_func app_tf,
> struct dc_info_packet *infopacket)
> {
> /* SPD info packet for FreeSync */
> diff --git a/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
> b/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
> index 949a8b62aa98..063af6258fd9 100644
> --- a/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
> +++ b/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
> @@ -145,7 +145,7 @@ void mod_freesync_build_vrr_infopacket(struct
> mod_freesync *mod_freesync,
> const struct dc_stream_state *stream,
> const struct mod_vrr_params *vrr,
> enum vrr_packet_type packet_type,
> - const enum color_transfer_func *app_tf,
> + enum color_transfer_func app_tf,
> struct dc_info_packet *infopacket);
>
> void mod_freesync_build_vrr_params(struct mod_freesync *mod_freesync,
> --
> 2.20.0
>
Gentle ping on this patch, it would be nice to get this fixed and into
5.1!
Thanks,
Nathan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/34] drm: Convert drm_minors_idr to XArray
On Fri, Feb 22, 2019 at 10:11:14AM +0100, Daniel Vetter wrote: > On Thu, Feb 21, 2019 at 10:41:21AM -0800, Matthew Wilcox wrote: > > Divide all the indices by 64 to save memory. > > > > Signed-off-by: Matthew Wilcox > > Pretty sure this goes boom. Our char device minor allocation scheme is > > device 0: card0=0, renderD0=64 > device 1: card1=1, renderD1=65 > ... > > I think your scheme aliases all devices with the first one. > > And yes the minor(cardX) + 64 == minor(renderDX) is uapi :-) > > If you want to save space we'd need to move the minor allocation from > drm_minor to drm_device (with a very strange allocation scheme of blocks > of 64 entries, every 128 entries). That would also solve the issue with > the current scheme potentially racing if you load multiple drivers at the > same time (except for drm_global_mutex, but that's more an accident than > intention). Not sure if worth the bother. > > Or maybe coffee hasn't kicked in yet over here and I'm missing something? I'm the one who needed moar coffee. I misread: > > - r = idr_alloc(&drm_minors_idr, > > - NULL, > > - 64 * type, > > - 64 * (type + 1), > > - GFP_NOWAIT); As (64 * type) + 1. So I'll redo this patch. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 9/9] mm/mmu_notifier: set MMU_NOTIFIER_USE_CHANGE_PTE flag where appropriate v2
On 2/19/19 12:04 PM, jgli...@redhat.com wrote:
From: Jérôme Glisse
When notifying change for a range use MMU_NOTIFIER_USE_CHANGE_PTE flag
for page table update that use set_pte_at_notify() and where the we are
going either from read and write to read only with same pfn or read only
to read and write with new pfn.
Note that set_pte_at_notify() itself should only be use in rare cases
ie we do not want to use it when we are updating a significant range of
virtual addresses and thus a significant number of pte. Instead for
those cases the event provided to mmu notifer invalidate_range_start()
callback should be use for optimization.
Changes since v1:
- Use the new unsigned flags field in struct mmu_notifier_range
- Use the new flags parameter to mmu_notifier_range_init()
- Explicitly list all the patterns where we can use change_pte()
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Jan Kara
Cc: Andrea Arcangeli
Cc: Peter Xu
Cc: Felix Kuehling
Cc: Jason Gunthorpe
Cc: Ross Zwisler
Cc: Dan Williams
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Michal Hocko
Cc: Christian Koenig
Cc: Ralph Campbell
Cc: John Hubbard
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: Arnd Bergmann
---
include/linux/mmu_notifier.h | 34 --
mm/ksm.c | 11 ++-
mm/memory.c | 5 +++--
3 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index b6c004bd9f6a..0230a4b06b46 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -40,6 +40,26 @@ enum mmu_notifier_event {
MMU_NOTIFY_SOFT_DIRTY,
};
+/*
+ * @MMU_NOTIFIER_RANGE_BLOCKABLE: can the mmu notifier range_start/range_end
+ * callback block or not ? If set then the callback can block.
+ *
+ * @MMU_NOTIFIER_USE_CHANGE_PTE: only set when the page table it updated with
+ * the set_pte_at_notify() the valid patterns for this are:
+ * - pte read and write to read only same pfn
+ * - pte read only to read and write (pfn can change or stay the same)
+ * - pte read only to read only with different pfn
+ * It is illegal to set in any other circumstances.
+ *
+ * Note that set_pte_at_notify() should not be use outside of the above cases.
+ * When updating a range in batch (like write protecting a range) it is better
+ * to rely on invalidate_range_start() and struct mmu_notifier_range to infer
+ * the kind of update that is happening (as an example you can look at the
+ * mmu_notifier_range_update_to_read_only() function).
+ */
+#define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
+#define MMU_NOTIFIER_USE_CHANGE_PTE (1 << 1)
+
#ifdef CONFIG_MMU_NOTIFIER
/*
@@ -55,8 +75,6 @@ struct mmu_notifier_mm {
spinlock_t lock;
};
-#define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
-
struct mmu_notifier_range {
struct vm_area_struct *vma;
struct mm_struct *mm;
@@ -268,6 +286,12 @@ mmu_notifier_range_blockable(const struct
mmu_notifier_range *range)
return (range->flags & MMU_NOTIFIER_RANGE_BLOCKABLE);
}
+static inline bool
+mmu_notifier_range_use_change_pte(const struct mmu_notifier_range *range)
+{
+ return (range->flags & MMU_NOTIFIER_USE_CHANGE_PTE);
+}
+
static inline void mmu_notifier_release(struct mm_struct *mm)
{
if (mm_has_notifiers(mm))
@@ -509,6 +533,12 @@ mmu_notifier_range_blockable(const struct
mmu_notifier_range *range)
return true;
}
+static inline bool
+mmu_notifier_range_use_change_pte(const struct mmu_notifier_range *range)
+{
+ return false;
+}
+
static inline int mm_has_notifiers(struct mm_struct *mm)
{
return 0;
diff --git a/mm/ksm.c b/mm/ksm.c
index b782fadade8f..41e51882f999 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -1066,9 +1066,9 @@ static int write_protect_page(struct vm_area_struct *vma,
struct page *page,
BUG_ON(PageTransCompound(page));
- mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, mm,
- pvmw.address,
- pvmw.address + PAGE_SIZE);
+ mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR,
+ MMU_NOTIFIER_USE_CHANGE_PTE, vma, mm,
+ pvmw.address, pvmw.address + PAGE_SIZE);
mmu_notifier_invalidate_range_start(&range);
if (!page_vma_mapped_walk(&pvmw))
@@ -1155,8 +1155,9 @@ static int replace_page(struct vm_area_struct *vma,
struct page *page,
if (!pmd)
goto out;
- mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, mm, addr,
- addr + PAGE_SIZE);
+ mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR,
+ MMU_NOTIFIER_USE_CHANGE_PTE,
+ vma, mm, addr, addr + PAGE_SIZE);
mmu_
Re: [PATCH v5 6/9] mm/mmu_notifier: use correct mmu_notifier events for each invalidation
On 2/19/19 12:04 PM, jgli...@redhat.com wrote: From: Jérôme Glisse This update each existing invalidation to use the correct mmu notifier event that represent what is happening to the CPU page table. See the patch which introduced the events to see the rational behind this. Signed-off-by: Jérôme Glisse Cc: Christian König Cc: Joonas Lahtinen Cc: Jani Nikula Cc: Rodrigo Vivi Cc: Jan Kara Cc: Andrea Arcangeli Cc: Peter Xu Cc: Felix Kuehling Cc: Jason Gunthorpe Cc: Ross Zwisler Cc: Dan Williams Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Michal Hocko Cc: Christian Koenig Cc: Ralph Campbell Cc: John Hubbard Cc: k...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux-r...@vger.kernel.org Cc: Arnd Bergmann --- fs/proc/task_mmu.c | 4 ++-- kernel/events/uprobes.c | 2 +- mm/huge_memory.c| 14 ++ mm/hugetlb.c| 8 mm/khugepaged.c | 2 +- mm/ksm.c| 4 ++-- mm/madvise.c| 2 +- mm/memory.c | 14 +++--- mm/migrate.c| 4 ++-- mm/mprotect.c | 5 +++-- mm/rmap.c | 6 +++--- 11 files changed, 32 insertions(+), 33 deletions(-) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index fcbd0e574917..3b93ce496dd4 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -1151,8 +1151,8 @@ static ssize_t clear_refs_write(struct file *file, const char __user *buf, break; } - mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, - NULL, mm, 0, -1UL); + mmu_notifier_range_init(&range, MMU_NOTIFY_SOFT_DIRTY, + 0, NULL, mm, 0, -1UL); mmu_notifier_invalidate_range_start(&range); } walk_page_range(0, mm->highest_vm_end, &clear_refs_walk); diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c index 46f546bdba00..8e8342080013 100644 --- a/kernel/events/uprobes.c +++ b/kernel/events/uprobes.c @@ -161,7 +161,7 @@ static int __replace_page(struct vm_area_struct *vma, unsigned long addr, struct mmu_notifier_range range; struct mem_cgroup *memcg; - mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, mm, addr, + mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, mm, addr, addr + PAGE_SIZE); VM_BUG_ON_PAGE(PageTransHuge(old_page), old_page); diff --git a/mm/huge_memory.c b/mm/huge_memory.c index c9d638f1b34e..1da6ca0f0f6d 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1184,9 +1184,8 @@ static vm_fault_t do_huge_pmd_wp_page_fallback(struct vm_fault *vmf, cond_resched(); } - mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, vma->vm_mm, - haddr, - haddr + HPAGE_PMD_SIZE); + mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm, + haddr, haddr + HPAGE_PMD_SIZE); mmu_notifier_invalidate_range_start(&range); vmf->ptl = pmd_lock(vma->vm_mm, vmf->pmd); @@ -1349,9 +1348,8 @@ vm_fault_t do_huge_pmd_wp_page(struct vm_fault *vmf, pmd_t orig_pmd) vma, HPAGE_PMD_NR); __SetPageUptodate(new_page); - mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, vma->vm_mm, - haddr, - haddr + HPAGE_PMD_SIZE); + mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm, + haddr, haddr + HPAGE_PMD_SIZE); mmu_notifier_invalidate_range_start(&range); spin_lock(vmf->ptl); @@ -2028,7 +2026,7 @@ void __split_huge_pud(struct vm_area_struct *vma, pud_t *pud, spinlock_t *ptl; struct mmu_notifier_range range; - mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, vma->vm_mm, + mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm, address & HPAGE_PUD_MASK, (address & HPAGE_PUD_MASK) + HPAGE_PUD_SIZE); mmu_notifier_invalidate_range_start(&range); @@ -2247,7 +2245,7 @@ void __split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd, spinlock_t *ptl; struct mmu_notifier_range range; - mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, vma->vm_mm, + mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm, address & HPAGE_PMD_MASK, (address & HPAGE_PMD_MASK) + HPAGE_PMD_SIZE); mmu_notifier_invalidate_range_start(&range); diff --git a/mm/hugetlb.c b/mm/hugetlb.c index d9e5c5a4c004..a58115c6b0a3 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -3250,7 +3250,7 @@ int copy_hugetlb_page_range(struct mm_struct *dst
[PATCH v4 2/2] drm/panel: Add driver for Samsung S6E63M0 panel
This patch adds Samsung S6E63M0 AMOLED LCD panel driver, connected over spi. It's based on already removed, non dt s6e63m0 driver and panel-samsung-ld9040. It can be found for example in some of Samsung Aries based phones. Signed-off-by: Paweł Chmiel Reviewed-by: Sam Ravnborg Reviewed-by: Andrzej Hajda --- Changes from v3: - Squash s6e63m0_brightness_set into s6e63m0_set_brightness - In power_on assert reset gpio after regulators, like it was done in vendor sources - In power_off assert reset gpio before regulators, like it was done in vendor sources - Add reviewed by - Match MCS command names (taken from other samsung panels) Changes from v2: - VIDEOMODE_HELPERS is not needed in Kconfig - Added help text to Kconfig - Remove unneeded videomode includes/fields - Add sentinel comment in s6e63m0_of_match struct - Handle errors during registration of backlight device. We shouldn't register panel if we fail to register backlight device - Added Reviewed-by Changes from v1: - Correct order of Kconfig/Makefile entry - Fix SPDX tag, so it matches value of MODULE_LICENSE - Remove inclusion of drmP.h - Fix code formatting - Use DRM_DEV_ERROR/DEBUG - Extract hardcoded values - Remove possibility to change gamma through sysfs, leaving only one gamma table values - Fix reset_gpio handling, so it'll be asserted in power_on and deasserted in power_off. Also do it before turning voltage on. - Disable backlight and enter sleep mode in disable callback. Previously it was done in unprepare - Enable display and backlight in enable callback. Previously it was done in prepare - Hardcode display timings and delays. Previously they were readed from device tree - We're using SPDX, so we don't need to have license body - Use MIPI_DCS_EXIT_SLEEP_MODE and MIPI_DCS_SET_DISPLAY_ON - Rename MAX_GAMMA_LEVEL to NUM_GAMMA_LEVELS - Ommit get_brightness callback - Use backlight_enable/disable API, like it's done in other panel drivers (for example panel-simple) - Make set_brightness called only from backlight api, like it's done in other panel drivers (for example panel-simple). - Reset gpio should be set to GPIOD_OUT_HIGH. It's declared as active low in device tree - Don't call power_off in remove callback --- drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 514 ++ 3 files changed, 524 insertions(+) create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63m0.c diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index 3f3537719beb..45e9ab4b7857 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -158,6 +158,15 @@ config DRM_PANEL_SAMSUNG_S6E63J0X03 depends on BACKLIGHT_CLASS_DEVICE select VIDEOMODE_HELPERS +config DRM_PANEL_SAMSUNG_S6E63M0 + tristate "Samsung S6E63M0 RGB/SPI panel" + depends on OF + depends on SPI + depends on BACKLIGHT_CLASS_DEVICE + help + Say Y here if you want to enable support for Samsung s6e63m0 + AMOLED LCD panel. + config DRM_PANEL_SAMSUNG_S6E8AA0 tristate "Samsung S6E8AA0 DSI video mode panel" depends on OF diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile index 4396658a7996..4507a2d253ac 100644 --- a/drivers/gpu/drm/panel/Makefile +++ b/drivers/gpu/drm/panel/Makefile @@ -16,6 +16,7 @@ obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6D16D0) += panel-samsung-s6d16d0.o obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o +obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63M0) += panel-samsung-s6e63m0.o obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c new file mode 100644 index ..142d395ea512 --- /dev/null +++ b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c @@ -0,0 +1,514 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * S6E63M0 AMOLED LCD drm_panel driver. + * + * Copyright (C) 2019 Paweł Chmiel + * Derived from drivers/gpu/drm/panel-samsung-ld9040.c + * + * Andrzej Hajda + */ + +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#include + +/* Manufacturer Command Set */ +#define MCS_ELVSS_ON0xb1 +#define MCS_MIECTL10xc0 +#define MCS_BCMODE 0xc1 +#define MCS_DISCTL 0xf2 +#define MCS_SRCCTL 0xf6 +#define MCS_IFCTL 0xf7 +#define MCS_PANELCTL 0xF8 +#define MCS_PGAMMACTL
[PATCH v6 1/8] drm/mediatek: recalculate hdmi phy clock of MT2701 by querying hardware
From: chunhui dai
Recalculate the rate of this clock, by querying hardware.
Signed-off-by: chunhui dai
Signed-off-by: wangyan wang
---
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 7 ++
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 3 +--
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 35 ++
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 8 ++
4 files changed, 46 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 4ef9c57ffd44..13c5e65b9ead 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -29,12 +29,9 @@ long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned
long rate,
return rate;
}
-unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
- unsigned long parent_rate)
+u32 mtk_hdmi_phy_read(struct mtk_hdmi_phy *hdmi_phy, u32 offset)
{
- struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
-
- return hdmi_phy->pll_rate;
+ return readl(hdmi_phy->regs + offset);
}
void mtk_hdmi_phy_clear_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index f39b1fc66612..fdad8b17a915 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -41,6 +41,7 @@ struct mtk_hdmi_phy {
unsigned int ibias_up;
};
+u32 mtk_hdmi_phy_read(struct mtk_hdmi_phy *hdmi_phy, u32 offset);
void mtk_hdmi_phy_clear_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
u32 bits);
void mtk_hdmi_phy_set_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
@@ -50,8 +51,6 @@ void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32
offset,
struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *parent_rate);
-unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
- unsigned long parent_rate);
extern struct platform_driver mtk_hdmi_phy_driver;
extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index fcc42dc6ea7f..b25c9dfc432a 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -153,6 +153,41 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
RG_HDMITX_DRV_IBIAS_MASK);
return 0;
}
+static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
+ unsigned long out_rate, val;
+
+ val = (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON6)
+ & RG_HTPLL_PREDIV_MASK) >> RG_HTPLL_PREDIV;
+ switch (val) {
+ case 0x00:
+ out_rate = parent_rate;
+ break;
+ case 0x01:
+ out_rate = parent_rate / 2;
+ break;
+ default:
+ out_rate = parent_rate / 4;
+ break;
+ }
+
+ val = (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON6)
+ & RG_HTPLL_FBKDIV_MASK) >> RG_HTPLL_FBKDIV;
+ out_rate *= (val + 1) * 2;
+ val = (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON2)
+ & RG_HDMITX_TX_POSDIV_MASK);
+
+ out_rate >>= (val >> RG_HDMITX_TX_POSDIV);
+
+ if (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON2) & RG_HDMITX_EN_TX_POSDIV)
+ out_rate = out_rate / 5;
+
+ hdmi_phy->pll_rate = out_rate;
+
+ return hdmi_phy->pll_rate;
+}
static const struct clk_ops mtk_hdmi_phy_pll_ops = {
.prepare = mtk_hdmi_pll_prepare,
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index ed5916b27658..cb23c1e4692a 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -285,6 +285,14 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
return 0;
}
+static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
+
+ return hdmi_phy->pll_rate;
+}
+
static const struct clk_ops mtk_hdmi_phy_pll_ops = {
.prepare = mtk_hdmi_pll_prepare,
.unprepare = mtk_hdmi_pll_unprepare,
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 7/9] mm/mmu_notifier: pass down vma and reasons why mmu notifier is happening v2
On 2/19/19 12:04 PM, jgli...@redhat.com wrote:
From: Jérôme Glisse
CPU page table update can happens for many reasons, not only as a result
of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
as a result of kernel activities (memory compression, reclaim, migration,
...).
Users of mmu notifier API track changes to the CPU page table and take
specific action for them. While current API only provide range of virtual
address affected by the change, not why the changes is happening
This patch is just passing down the new informations by adding it to the
mmu_notifier_range structure.
Changes since v1:
- Initialize flags field from mmu_notifier_range_init() arguments
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Jan Kara
Cc: Andrea Arcangeli
Cc: Peter Xu
Cc: Felix Kuehling
Cc: Jason Gunthorpe
Cc: Ross Zwisler
Cc: Dan Williams
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Michal Hocko
Cc: Christian Koenig
Cc: Ralph Campbell
Cc: John Hubbard
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: Arnd Bergmann
---
include/linux/mmu_notifier.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index 62f94cd85455..0379956fff23 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -58,10 +58,12 @@ struct mmu_notifier_mm {
#define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
struct mmu_notifier_range {
+ struct vm_area_struct *vma;
struct mm_struct *mm;
unsigned long start;
unsigned long end;
unsigned flags;
+ enum mmu_notifier_event event;
};
struct mmu_notifier_ops {
@@ -363,10 +365,12 @@ static inline void mmu_notifier_range_init(struct
mmu_notifier_range *range,
unsigned long start,
unsigned long end)
{
+ range->vma = vma;
+ range->event = event;
range->mm = mm;
range->start = start;
range->end = end;
- range->flags = 0;
+ range->flags = flags;
}
#define ptep_clear_flush_young_notify(__vma, __address, __ptep) \
Reviewed-by: Ralph Campbell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 8/9] mm/mmu_notifier: mmu_notifier_range_update_to_read_only() helper
On 2/19/19 12:04 PM, jgli...@redhat.com wrote:
From: Jérôme Glisse
Helper to test if a range is updated to read only (it is still valid
to read from the range). This is useful for device driver or anyone
who wish to optimize out update when they know that they already have
the range map read only.
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Jan Kara
Cc: Andrea Arcangeli
Cc: Peter Xu
Cc: Felix Kuehling
Cc: Jason Gunthorpe
Cc: Ross Zwisler
Cc: Dan Williams
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Michal Hocko
Cc: Christian Koenig
Cc: Ralph Campbell
Cc: John Hubbard
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: Arnd Bergmann
---
include/linux/mmu_notifier.h | 4
mm/mmu_notifier.c| 10 ++
2 files changed, 14 insertions(+)
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index 0379956fff23..b6c004bd9f6a 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -259,6 +259,8 @@ extern void __mmu_notifier_invalidate_range_end(struct
mmu_notifier_range *r,
bool only_end);
extern void __mmu_notifier_invalidate_range(struct mm_struct *mm,
unsigned long start, unsigned long end);
+extern bool
+mmu_notifier_range_update_to_read_only(const struct mmu_notifier_range *range);
static inline bool
mmu_notifier_range_blockable(const struct mmu_notifier_range *range)
@@ -568,6 +570,8 @@ static inline void mmu_notifier_mm_destroy(struct mm_struct
*mm)
{
}
+#define mmu_notifier_range_update_to_read_only(r) false
+
#define ptep_clear_flush_young_notify ptep_clear_flush_young
#define pmdp_clear_flush_young_notify pmdp_clear_flush_young
#define ptep_clear_young_notify ptep_test_and_clear_young
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index abd88c466eb2..ee36068077b6 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -395,3 +395,13 @@ void mmu_notifier_unregister_no_release(struct
mmu_notifier *mn,
mmdrop(mm);
}
EXPORT_SYMBOL_GPL(mmu_notifier_unregister_no_release);
+
+bool
+mmu_notifier_range_update_to_read_only(const struct mmu_notifier_range *range)
+{
+ if (!range->vma || range->event != MMU_NOTIFY_PROTECTION_VMA)
+ return false;
+ /* Return true if the vma still have the read flag set. */
+ return range->vma->vm_flags & VM_READ;
+}
+EXPORT_SYMBOL_GPL(mmu_notifier_range_update_to_read_only);
Don't you have to check for !WRITE & READ?
mprotect() can change the permissions from R/O to RW and
end up calling mmu_notifier_range_init() and
mmu_notifier_invalidate_range_start()/end().
I'm not sure how useful this is since only applies to the
MMU_NOTIFY_PROTECTION_VMA case.
Anyway, you can add
Reviewed-by: Ralph Campbell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND] drm: panel-orientation-quirks: Add quirk for Lenovo Ideapad D330
Lenovo Ideapad D330 Pentium CPU version has 1920x1200 LCD.
Console output gets rotated at boot as Miix 310.
Signed-off-by: David Santamaría Rogado
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 52e445bb1aa5..521aff99b08a 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -80,6 +80,12 @@ static const struct drm_dmi_panel_orientation_data
lcd800x1280_rightside_up = {
.orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
};
+static const struct drm_dmi_panel_orientation_data lcd1200x1920_rightside_up =
{
+ .width = 1200,
+ .height = 1920,
+ .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
static const struct dmi_system_id orientation_data[] = {
{ /* Acer One 10 (S1003) */
.matches = {
@@ -148,6 +154,13 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo MIIX 320-10ICR"),
},
.driver_data = (void *)&lcd800x1280_rightside_up,
+ }, {/* Lenovo Ideapad D330 */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "81H3"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
D330-10IGM"),
+ },
+ .driver_data = (void *)&lcd1200x1920_rightside_up,
}, {/* VIOS LTH17 */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "VIOS"),
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bochs: Fix the ID mismatch error
On Thu, Feb 21, 2019 at 9:37 PM kra...@redhat.com wrote: > > On Thu, Feb 21, 2019 at 10:44:06AM -0800, Alistair Francis wrote: > > On Thu, Feb 21, 2019 at 3:52 AM kra...@redhat.com wrote: > > > > > > On Thu, Feb 21, 2019 at 12:33:03AM +, Alistair Francis wrote: > > > > When running RISC-V QEMU with the Bochs device attached via PCIe the > > > > probe of the Bochs device fails with: > > > > [drm:bochs_hw_init] *ERROR* ID mismatch > > > > > > > > This was introduced by this commit: > > > > 7780eb9ce8 bochs: convert to drm_dev_register > > > > > > > > To fix the error we ensure that pci_enable_device() is called before > > > > bochs_load(). > > > > > > > > Signed-off-by: Alistair Francis > > > > Reported-by: David Abdurachmanov > > > > > > Pushed to drm-misc-fixes. > > > > Thanks. Any chance this will make it into 5.0? > > Hmm, we are damn close to the release, not sure there will be one more > drm-fixes pull req. But I've added a proper Fixes: tag, so even if the > patch misses the boat it should land in the stable branches shortly > thereafter. Landing in the stable branches is probably enough. If you do end up sending another pull request it would be great if this gets in. It would be nice to have this fixed in the official 5.0 tag. Alistair > > cheers, > Gerd > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
Frank Rowand writes: > On 2/19/19 10:34 PM, Brendan Higgins wrote: >> On Mon, Feb 18, 2019 at 12:02 PM Frank Rowand wrote: >> >>> I have not read through the patches in any detail. I have read some of >>> the code to try to understand the patches to the devicetree unit tests. >>> So that may limit how valid my comments below are. >> >> No problem. >> >>> >>> I found the code difficult to read in places where it should have been >>> much simpler to read. Structuring the code in a pseudo object oriented >>> style meant that everywhere in a code path that I encountered a dynamic >>> function call, I had to go find where that dynamic function call was >>> initialized (and being the cautious person that I am, verify that >>> no where else was the value of that dynamic function call). With >>> primitive vi and tags, that search would have instead just been a >>> simple key press (or at worst a few keys) if hard coded function >>> calls were done instead of dynamic function calls. In the code paths >>> that I looked at, I did not see any case of a dynamic function being >>> anything other than the value it was originally initialized as. >>> There may be such cases, I did not read the entire patch set. There >>> may also be cases envisioned in the architects mind of how this >>> flexibility may be of future value. Dunno. >> >> Yeah, a lot of it is intended to make architecture specific >> implementations and some other future work easier. Some of it is also >> for testing purposes. Admittedly some is for neither reason, but given >> the heavy usage elsewhere, I figured there was no harm since it was >> all private internal usage anyway. >> > > Increasing the cost for me (and all the other potential code readers) > to read the code is harm. Dynamic function calls aren't necessary for arch-specific implementations either. See for example arch_kexec_image_load() in kernel/kexec_file.c, which uses a weak symbol that is overriden by arch-specific code. Not everybody likes weak symbols, so another alternative (which admitedly not everybody likes either) is to use a macro with the name of the arch-specific function, as used by arch_kexec_post_alloc_pages() in for instance. -- Thiago Jung Bauermann IBM Linux Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V6 0/8] make mt7623 clock of hdmi stable
From: Wangyan Wang V6 adopt maintainer's suggestion. Here is the change list between V5 & V6 1. change "unsigned char mux_flags;" to "u8 mux_flags;" to match with the struct in " clk: mediatek: add MUX_GATE_FLAGS_2". chunhui dai (8): drm/mediatek: recalculate hdmi phy clock of MT2701 by querying hardware drm/mediatek: move the setting of fixed divider drm/mediatek: using different flags of clk for HDMI phy drm/mediatek: fix the rate and divder of hdmi phy for MT2701 clk: mediatek: add MUX_GATE_FLAGS_2 clk: mediatek: using CLK_MUX_ROUND_CLOSEST for the clock of dpi1_sel drm/mediatek: using new factor for tvdpll in MT2701 drm/mediatek: fix the rate of parent for hdmi phy in MT2701 drivers/clk/mediatek/clk-mt2701.c | 4 +- drivers/clk/mediatek/clk-mtk.c | 2 +- drivers/clk/mediatek/clk-mtk.h | 20 ++--- drivers/gpu/drm/mediatek/mtk_dpi.c | 8 ++-- drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 34 drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 7 +--- drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 56 +++--- drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 23 +++ 8 files changed, 102 insertions(+), 52 deletions(-) -- 2.14.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V6 8/8] drm/mediatek: fix the rate of parent for hdmi phy in MT2701
From: chunhui dai
We should not change the rate of parent for hdmi phy when
doing round_rate for this clock. The parent clock of hdmi
phy must be the same as it. We change it when doing set_rate
only.
Signed-off-by: chunhui dai
Signed-off-by: wangyan wang
---
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 14 --
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 3 ---
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 11 +++
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 14 ++
4 files changed, 25 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 370309d684ec..ca8bc1489f37 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -15,20 +15,6 @@ static const struct phy_ops mtk_hdmi_phy_dev_ops = {
.owner = THIS_MODULE,
};
-long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
-unsigned long *parent_rate)
-{
- struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
-
- hdmi_phy->pll_rate = rate;
- if (rate <= 7425)
- *parent_rate = rate;
- else
- *parent_rate = rate / 2;
-
- return rate;
-}
-
u32 mtk_hdmi_phy_read(struct mtk_hdmi_phy *hdmi_phy, u32 offset)
{
return readl(hdmi_phy->regs + offset);
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index 446e2acd1926..c6061ad15ff0 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -50,9 +50,6 @@ void mtk_hdmi_phy_set_bits(struct mtk_hdmi_phy *hdmi_phy, u32
offset,
void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
u32 val, u32 mask);
struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
-long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
-unsigned long *parent_rate);
-
extern struct platform_driver mtk_hdmi_phy_driver;
extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf;
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index 88dd9e812ca0..33893a180c2e 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -152,6 +152,17 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
RG_HDMITX_DRV_IBIAS_MASK);
return 0;
}
+
+static long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+unsigned long *parent_rate)
+{
+ struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
+
+ hdmi_phy->pll_rate = rate;
+
+ return rate;
+}
+
static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
unsigned long parent_rate)
{
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index 63dde42521b8..3a339f516613 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -285,6 +285,20 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
return 0;
}
+static long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+unsigned long *parent_rate)
+{
+ struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
+
+ hdmi_phy->pll_rate = rate;
+ if (rate <= 7425)
+ *parent_rate = rate;
+ else
+ *parent_rate = rate / 2;
+
+ return rate;
+}
+
static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
unsigned long parent_rate)
{
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND] drm: panel-orientation-quirks: Add quirk for Lenovo Ideapad D330
Done Jani. I think it's ok now. Don't worry, at least I could get
little familiar with git send-email also with multiple patches :)
El sáb., 23 feb. 2019 a las 22:19, David Santamaría Rogado
() escribió:
>
> Lenovo Ideapad D330 Pentium CPU version has 1920x1200 LCD.
> Console output gets rotated at boot as Miix 310.
>
> Signed-off-by: David Santamaría Rogado
> ---
> drivers/gpu/drm/drm_panel_orientation_quirks.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> index 52e445bb1aa5..521aff99b08a 100644
> --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> @@ -80,6 +80,12 @@ static const struct drm_dmi_panel_orientation_data
> lcd800x1280_rightside_up = {
> .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
> };
>
> +static const struct drm_dmi_panel_orientation_data lcd1200x1920_rightside_up
> = {
> + .width = 1200,
> + .height = 1920,
> + .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
> +};
> +
> static const struct dmi_system_id orientation_data[] = {
> { /* Acer One 10 (S1003) */
> .matches = {
> @@ -148,6 +154,13 @@ static const struct dmi_system_id orientation_data[] = {
> DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo MIIX
> 320-10ICR"),
> },
> .driver_data = (void *)&lcd800x1280_rightside_up,
> + }, {/* Lenovo Ideapad D330 */
> + .matches = {
> + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "81H3"),
> + DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
> D330-10IGM"),
> + },
> + .driver_data = (void *)&lcd1200x1920_rightside_up,
> }, {/* VIOS LTH17 */
> .matches = {
> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "VIOS"),
> --
> 2.20.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/i2c: tda998x: adjust CTS_N audio pre-divider calculation
On Fri, Feb 22, 2019 at 4:36 PM Russell King - ARM Linux admin wrote: > There's actually two threads of conversation going, and I recently had > a reply from the maintainer of hdmi-codec suggesting a way forward - so > I've coded that up as the three RFC patches you should have just > received. Thank you, that's awesome ! > It probably would be better to try and find some generic way to deal > with this. > > After all, the I2S source probably knows which ratios it supports. > Given that many sinks support a limited set of values as well, if > ASoC core knew the supported set at each end of an I2S DAI format > link, it could probably select a working bclk ratio automatically. Agree, possibly the same way the ASoC core auto-matches both sides when they are connected with a dai_link? Pardon my ignorance. Of course the auto-matching should only happen when both sides provide a bclk ratio range - to avoid having to retro-fit every single dai. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/9] mm/mmu_notifier: convert user range->blockable to helper function
On 2/19/19 12:04 PM, jgli...@redhat.com wrote:
From: Jérôme Glisse
Use the mmu_notifier_range_blockable() helper function instead of
directly dereferencing the range->blockable field. This is done to
make it easier to change the mmu_notifier range field.
This patch is the outcome of the following coccinelle patch:
%<---
@@
identifier I1, FN;
@@
FN(..., struct mmu_notifier_range *I1, ...) {
<...
-I1->blockable
+mmu_notifier_range_blockable(I1)
...>
}
--->%
spatch --in-place --sp-file blockable.spatch --dir .
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Jan Kara
Cc: Andrea Arcangeli
Cc: Peter Xu
Cc: Felix Kuehling
Cc: Jason Gunthorpe
Cc: Ross Zwisler
Cc: Dan Williams
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Michal Hocko
Cc: Christian Koenig
Cc: Ralph Campbell
Cc: John Hubbard
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: Arnd Bergmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 8
drivers/gpu/drm/i915/i915_gem_userptr.c | 2 +-
drivers/gpu/drm/radeon/radeon_mn.c | 4 ++--
drivers/infiniband/core/umem_odp.c | 5 +++--
drivers/xen/gntdev.c| 6 +++---
mm/hmm.c| 6 +++---
mm/mmu_notifier.c | 2 +-
virt/kvm/kvm_main.c | 3 ++-
8 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
index 3e6823fdd939..58ed401c5996 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
@@ -256,14 +256,14 @@ static int amdgpu_mn_invalidate_range_start_gfx(struct
mmu_notifier *mn,
/* TODO we should be able to split locking for interval tree and
* amdgpu_mn_invalidate_node
*/
- if (amdgpu_mn_read_lock(amn, range->blockable))
+ if (amdgpu_mn_read_lock(amn, mmu_notifier_range_blockable(range)))
return -EAGAIN;
it = interval_tree_iter_first(&amn->objects, range->start, end);
while (it) {
struct amdgpu_mn_node *node;
- if (!range->blockable) {
+ if (!mmu_notifier_range_blockable(range)) {
amdgpu_mn_read_unlock(amn);
return -EAGAIN;
}
@@ -299,7 +299,7 @@ static int amdgpu_mn_invalidate_range_start_hsa(struct
mmu_notifier *mn,
/* notification is exclusive, but interval is inclusive */
end = range->end - 1;
- if (amdgpu_mn_read_lock(amn, range->blockable))
+ if (amdgpu_mn_read_lock(amn, mmu_notifier_range_blockable(range)))
return -EAGAIN;
it = interval_tree_iter_first(&amn->objects, range->start, end);
@@ -307,7 +307,7 @@ static int amdgpu_mn_invalidate_range_start_hsa(struct
mmu_notifier *mn,
struct amdgpu_mn_node *node;
struct amdgpu_bo *bo;
- if (!range->blockable) {
+ if (!mmu_notifier_range_blockable(range)) {
amdgpu_mn_read_unlock(amn);
return -EAGAIN;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 1d3f9a31ad61..777b3f8727e7 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -122,7 +122,7 @@ userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
while (it) {
struct drm_i915_gem_object *obj;
- if (!range->blockable) {
+ if (!mmu_notifier_range_blockable(range)) {
ret = -EAGAIN;
break;
}
diff --git a/drivers/gpu/drm/radeon/radeon_mn.c
b/drivers/gpu/drm/radeon/radeon_mn.c
index b3019505065a..c9bd1278f573 100644
--- a/drivers/gpu/drm/radeon/radeon_mn.c
+++ b/drivers/gpu/drm/radeon/radeon_mn.c
@@ -133,7 +133,7 @@ static int radeon_mn_invalidate_range_start(struct
mmu_notifier *mn,
/* TODO we should be able to split locking for interval tree and
* the tear down.
*/
- if (range->blockable)
+ if (mmu_notifier_range_blockable(range))
mutex_lock(&rmn->lock);
else if (!mutex_trylock(&rmn->lock))
return -EAGAIN;
@@ -144,7 +144,7 @@ static int radeon_mn_invalidate_range_start(struct
mmu_notifier *mn,
struct radeon_bo *bo;
long r;
- if (!range->blockable) {
+ if (!mmu_notifier_range_blockable(range)) {
ret = -EAGAIN;
goto out_unlock;
}
diff --git a/drivers/infiniband/core/umem_odp.c
b/drivers/infiniband/core/umem_odp.c
index 012044f16d1c..3a3f1538d295 100644
--- a/drivers/infiniband/core/umem_odp.c
[PATCH V6 4/8] drm/mediatek: fix the rate and divder of hdmi phy for MT2701
From: chunhui dai
Due to a clerical error,there is one zero less for 1280.
Fix it for 12800.
Fixes: 0fc721b2968e ("drm/mediatek: add hdmi driver for MT2701 and MT7623")
Reviewed-by: CK Hu
Signed-off-by: chunhui dai
Signed-off-by: wangyan wang
---
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index 43bc058d5528..88dd9e812ca0 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -114,8 +114,8 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
if (rate <= 6400)
pos_div = 3;
- else if (rate <= 1280)
- pos_div = 1;
+ else if (rate <= 12800)
+ pos_div = 2;
else
pos_div = 1;
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V6 2/8] drm/mediatek: move the setting of fixed divider
From: chunhui dai move the setting of fixed divider from enable/disable to the function of setting rate. the patch is for hdmi pll divider, the divder should be configured before clock calculation to ensure the clock is right. Signed-off-by: chunhui dai Signed-off-by: wangyan wang --- drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c index b25c9dfc432a..b26fb7dbdb28 100644 --- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c +++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c @@ -79,7 +79,6 @@ static int mtk_hdmi_pll_prepare(struct clk_hw *hw) mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK); usleep_range(80, 100); mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN); - mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV); mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK); mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK); mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK); @@ -94,7 +93,6 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw) mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK); mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK); mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK); - mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV); mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN); usleep_range(80, 100); mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK); @@ -123,6 +121,7 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, unsigned long rate, mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_PREDIV_MASK); mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_POSDIV_MASK); + mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV); mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6, (0x1 << RG_HTPLL_IC), RG_HTPLL_IC_MASK); mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6, (0x1 << RG_HTPLL_IR), @@ -209,7 +208,6 @@ static void mtk_hdmi_phy_enable_tmds(struct mtk_hdmi_phy *hdmi_phy) mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK); usleep_range(80, 100); mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN); - mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV); mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK); mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK); mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK); @@ -221,7 +219,6 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy *hdmi_phy) mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK); mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK); mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK); - mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV); mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN); usleep_range(80, 100); mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK); -- 2.14.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 3/3] drm/i2c: tda998x: add support for bclk_ratio
It appears that TDA998x derives the CTS value using the supplied I2S
bit clock (BCLK) rather than 128·fs. TDA998x uses two constants named
m and k in the CTS generator such that we have this relationship
between the source BCLK and the sink fs:
128·fs_sink = BCLK·m / k
Where BCLK = bclk_ratio·fs_source.
We have been lucky up to now that all users have scaled their bclk_ratio
to match the sample width - for example, on Beagle Bone Black, with a
16-bit sample width, BCLK = 32·fs, which increases to 64·fs for 32-bit
samples. 24-bit samples are sent as 32-bit.
We are now starting to see users whose I2S blocks send at 64·fs for
16-bit samples, which means TDA998x now breaks.
ASoC has a snd_soc_dai_set_bclk_ratio() call available which sets the
ratio of BCLK to the sample rate. Implement support for this.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 20 +---
include/drm/i2c/tda998x.h | 1 +
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 645d884fb9e8..f2d40235acf9 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -895,21 +895,26 @@ tda998x_configure_audio(struct tda998x_priv *priv,
reg_write(priv, REG_MUX_AP, MUX_AP_SELECT_I2S);
clksel_aip = AIP_CLKSEL_AIP_I2S;
clksel_fs = AIP_CLKSEL_FS_ACLK;
- switch (params->sample_width) {
+ switch (params->bclk_ratio) {
case 16:
+ cts_n = CTS_N_M(3) | CTS_N_K(0);
+ break;
+ case 32:
cts_n = CTS_N_M(3) | CTS_N_K(1);
break;
- case 18:
- case 20:
- case 24:
+ case 48:
cts_n = CTS_N_M(3) | CTS_N_K(2);
break;
- default:
- case 32:
+ case 64:
cts_n = CTS_N_M(3) | CTS_N_K(3);
break;
+ case 128:
+ cts_n = CTS_N_M(0) | CTS_N_K(0);
+ break;
+ default:
+ dev_err(&priv->hdmi->dev, "unsupported I2S bclk
ratio\n");
+ return -EINVAL;
}
-
switch (params->format & AFMT_I2S_MASK) {
case AFMT_I2S_LEFT_J:
i2s_fmt = I2S_FORMAT_LEFT_J;
@@ -997,6 +1002,7 @@ static int tda998x_audio_hw_params(struct device *dev,
void *data,
struct tda998x_priv *priv = dev_get_drvdata(dev);
int i, ret;
struct tda998x_audio_params audio = {
+ .bclk_ratio = daifmt->bclk_ratio,
.sample_width = params->sample_width,
.sample_rate = params->sample_rate,
.cea = params->cea,
diff --git a/include/drm/i2c/tda998x.h b/include/drm/i2c/tda998x.h
index b0864f0be017..4e0f0cd2d428 100644
--- a/include/drm/i2c/tda998x.h
+++ b/include/drm/i2c/tda998x.h
@@ -19,6 +19,7 @@ enum {
struct tda998x_audio_params {
u8 config;
u8 format;
+ u8 bclk_ratio;
unsigned sample_width;
unsigned sample_rate;
struct hdmi_audio_infoframe cea;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V6 5/8] clk: mediatek: add MUX_GATE_FLAGS_2
From: chunhui dai
Add MUX_GATE_FLAGS_2 for the clock which needs to set two falgs.
Such as some mux need to set the flags of "CLK_MUX_ROUND_CLOSEST".
Signed-off-by: chunhui dai
Signed-off-by: wangyan wang
---
drivers/clk/mediatek/clk-mtk.c | 2 +-
drivers/clk/mediatek/clk-mtk.h | 20 ++--
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 9c0ae4278a94..2ed996404804 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -167,7 +167,7 @@ struct clk *mtk_clk_register_composite(const struct
mtk_composite *mc,
mux->mask = BIT(mc->mux_width) - 1;
mux->shift = mc->mux_shift;
mux->lock = lock;
-
+ mux->flags = mc->mux_flags;
mux_hw = &mux->hw;
mux_ops = &clk_mux_ops;
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index f83c2bbb677e..4b88d196d52f 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -81,15 +81,13 @@ struct mtk_composite {
signed char divider_shift;
signed char divider_width;
+ u8 mux_flags;
+
signed char num_parents;
};
-/*
- * In case the rate change propagation to parent clocks is undesirable,
- * this macro allows to specify the clock flags manually.
- */
-#define MUX_GATE_FLAGS(_id, _name, _parents, _reg, _shift, _width, \
- _gate, _flags) {\
+#define MUX_GATE_FLAGS_2(_id, _name, _parents, _reg, _shift, \
+ _width, _gate, _flags, _muxflags) { \
.id = _id, \
.name = _name, \
.mux_reg = _reg,\
@@ -101,8 +99,18 @@ struct mtk_composite {
.parent_names = _parents, \
.num_parents = ARRAY_SIZE(_parents),\
.flags = _flags,\
+ .mux_flags = _muxflags, \
}
+/*
+ * In case the rate change propagation to parent clocks is undesirable,
+ * this macro allows to specify the clock flags manually.
+ */
+#define MUX_GATE_FLAGS(_id, _name, _parents, _reg, _shift, _width, \
+ _gate, _flags) \
+ MUX_GATE_FLAGS_2(_id, _name, _parents, _reg,\
+ _shift, _width, _gate, _flags, 0)
+
/*
* Unless necessary, all MUX_GATE clocks propagate rate changes to their
* parent clock by default.
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] dt-bindings: display: armada: Add display subsystem binding
On Fri, 2019-02-22 at 14:23 -0600, Rob Herring wrote:
> On Wed, Feb 13, 2019 at 4:37 PM Lubomir Rintel wrote:
> > On Mon, 2019-01-21 at 09:35 -0600, Rob Herring wrote:
> > > On Sun, Jan 20, 2019 at 11:26 AM Lubomir Rintel wrote:
> > > > The Marvell Armada DRM master device is a virtual device needed to list
> > > > all
> > > > nodes that comprise the graphics subsystem.
> > > >
> > > > Signed-off-by: Lubomir Rintel
> > > > ---
> > > > .../display/armada/marvell-armada-drm.txt | 24 +++
> > > > 1 file changed, 24 insertions(+)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > >
> > > > b/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > > index de4cca9432c8..3dbfa8047f0b 100644
> > > > ---
> > > > a/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > > +++
> > > > b/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > > @@ -1,3 +1,27 @@
> > > > +Marvell Armada DRM master device
> > > > +
> > > > +
> > > > +The Marvell Armada DRM master device is a virtual device needed to
> > > > list all
> > > > +nodes that comprise the graphics subsystem.
> > > > +
> > > > +Required properties:
> > > > +
> > > > + - compatible: value should be "marvell,dove-display-subsystem",
> > > > + "marvell,armada-display-subsystem"
> > > > + - ports: a list of phandles pointing to display interface ports of
> > > > CRTC
> > > > + devices
> > > > + - memory-region: phandle to a node describing memory to be used for
> > > > the
> > > > + framebuffer
> > > > +
> > > > +Example:
> > > > +
> > > > + display-subsystem {
> > > > + compatible = "marvell,dove-display-subsystem",
> > > > +"marvell,armada-display-subsystem";
> > > > + memory-region = <&display_reserved>;
> > > > + ports = <&lcd0_port>;
> > >
> > > If there is only one device, you don't need this virtual node.
> >
> > Before I follow up on this and submit a version without the virtual
> > node, I'm wondering: is it okay that the bindings for the LCDC and the
> > framebuffer are in the same file, or would it be preferrable if they
> > were separate? Both styles seem to be used for the display bindings.
>
> framebuffer as in the kernel fbdev? Really, that should be the same
> binding. It's the same h/w after all. However, there have been cases
> where things deviated. So I don't have a good answer.
No, not the fbdev device, that one is managed by drmfb and is not
expressed in DT. I meant the reserved-memory node that sets aside
memory for the framebuffers.
See patch "[RFC 03/16] dt-bindings: display: armada: Add framebuffer
reserved-mem binding". Perhaps that part should even go to
Documentation/devicetree/bindings/reserved-memory/.
Lubo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V6 7/8] drm/mediatek: using new factor for tvdpll in MT2701
From: chunhui dai
The factor depends on the divider of DPI in MT2701, therefore,
we should fix this factor to the right and new one.
Signed-off-by: chunhui dai
Signed-off-by: wangyan wang
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 69c6e42dad6b..4a2f4a650494 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -662,13 +662,11 @@ static unsigned int mt8173_calculate_factor(int clock)
static unsigned int mt2701_calculate_factor(int clock)
{
if (clock <= 64000)
- return 16;
- else if (clock <= 128000)
- return 8;
- else if (clock <= 256000)
return 4;
- else
+ else if (clock <= 128000)
return 2;
+ else
+ return 1;
}
static const struct mtk_dpi_conf mt8173_conf = {
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V6 6/8] clk: mediatek: using CLK_MUX_ROUND_CLOSEST for the clock of dpi1_sel
From: chunhui dai
The MUX clock of dpi1_sel should select the closet clock for itself.
We could add this flag to enable this function of MUX in CCF.
Signed-off-by: chunhui dai
Signed-off-by: wangyan wang
---
drivers/clk/mediatek/clk-mt2701.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mt2701.c
b/drivers/clk/mediatek/clk-mt2701.c
index ab6ab07f53e6..905a2316f6a7 100644
--- a/drivers/clk/mediatek/clk-mt2701.c
+++ b/drivers/clk/mediatek/clk-mt2701.c
@@ -535,8 +535,8 @@ static const struct mtk_composite top_muxes[] = {
0x0080, 8, 2, 15),
MUX_GATE(CLK_TOP_DPI0_SEL, "dpi0_sel", dpi0_parents,
0x0080, 16, 3, 23),
- MUX_GATE(CLK_TOP_DPI1_SEL, "dpi1_sel", dpi1_parents,
- 0x0080, 24, 2, 31),
+ MUX_GATE_FLAGS_2(CLK_TOP_DPI1_SEL, "dpi1_sel", dpi1_parents,
+ 0x0080, 24, 2, 31, 0, CLK_MUX_ROUND_CLOSEST),
MUX_GATE(CLK_TOP_TVE_SEL, "tve_sel", tve_parents,
0x0090, 0, 3, 7),
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 5/9] mm/mmu_notifier: contextual information for event triggering invalidation v2
On 2/19/19 12:04 PM, jgli...@redhat.com wrote:
From: Jérôme Glisse
CPU page table update can happens for many reasons, not only as a result
of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
as a result of kernel activities (memory compression, reclaim, migration,
...).
Users of mmu notifier API track changes to the CPU page table and take
specific action for them. While current API only provide range of virtual
address affected by the change, not why the changes is happening.
This patchset do the initial mechanical convertion of all the places that
calls mmu_notifier_range_init to also provide the default MMU_NOTIFY_UNMAP
event as well as the vma if it is know (most invalidation happens against
a given vma). Passing down the vma allows the users of mmu notifier to
inspect the new vma page protection.
The MMU_NOTIFY_UNMAP is always the safe default as users of mmu notifier
should assume that every for the range is going away when that event
happens. A latter patch do convert mm call path to use a more appropriate
events for each call.
Changes since v1:
- add the flags parameter to init range flags
This is done as 2 patches so that no call site is forgotten especialy
as it uses this following coccinelle patch:
%<--
@@
identifier I1, I2, I3, I4;
@@
static inline void mmu_notifier_range_init(struct mmu_notifier_range *I1,
+enum mmu_notifier_event event,
+unsigned flags,
+struct vm_area_struct *vma,
struct mm_struct *I2, unsigned long I3, unsigned long I4) { ... }
@@
@@
-#define mmu_notifier_range_init(range, mm, start, end)
+#define mmu_notifier_range_init(range, event, flags, vma, mm, start, end)
@@
expression E1, E3, E4;
identifier I1;
@@
<...
mmu_notifier_range_init(E1,
+MMU_NOTIFY_UNMAP, 0, I1,
I1->vm_mm, E3, E4)
...>
@@
expression E1, E2, E3, E4;
identifier FN, VMA;
@@
FN(..., struct vm_area_struct *VMA, ...) {
<...
mmu_notifier_range_init(E1,
+MMU_NOTIFY_UNMAP, 0, VMA,
E2, E3, E4)
...> }
@@
expression E1, E2, E3, E4;
identifier FN, VMA;
@@
FN(...) {
struct vm_area_struct *VMA;
<...
mmu_notifier_range_init(E1,
+MMU_NOTIFY_UNMAP, 0, VMA,
E2, E3, E4)
...> }
@@
expression E1, E2, E3, E4;
identifier FN;
@@
FN(...) {
<...
mmu_notifier_range_init(E1,
+MMU_NOTIFY_UNMAP, 0, NULL,
E2, E3, E4)
...> }
-->%
Applied with:
spatch --all-includes --sp-file mmu-notifier.spatch fs/proc/task_mmu.c
--in-place
spatch --sp-file mmu-notifier.spatch --dir kernel/events/ --in-place
spatch --sp-file mmu-notifier.spatch --dir mm --in-place
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Jan Kara
Cc: Andrea Arcangeli
Cc: Peter Xu
Cc: Felix Kuehling
Cc: Jason Gunthorpe
Cc: Ross Zwisler
Cc: Dan Williams
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Michal Hocko
Cc: Christian Koenig
Cc: Ralph Campbell
Cc: John Hubbard
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: Arnd Bergmann
---
Reviewed-by: Ralph Campbell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] tinydrm/mipi-dbi: Use dma-safe buffers for all SPI transfers
On Fri, Feb 22, 2019 at 01:43:29PM +0100, Noralf Trønnes wrote:
> Buffers passed to spi_sync() must be dma-safe even for tiny buffers since
> some SPI controllers use DMA for all transfers.
>
> Example splat with CONFIG_DMA_API_DEBUG enabled:
>
> [ 23.750467] DMA-API: dw_dmac_pci :00:15.0: device driver maps memory
> from stack [probable addr=1e49185d]
> [ 23.750529] WARNING: CPU: 1 PID: 1296 at kernel/dma/debug.c:1161
> check_for_stack+0xb7/0x190
> [ 23.750533] Modules linked in: mmc_block(+) spi_pxa2xx_platform(+)
> pwm_lpss_pci pwm_lpss spi_pxa2xx_pci sdhci_pci cqhci intel_mrfld_pwrbtn
> extcon_intel_mrfld sdhci intel_mrfld_adc led_class mmc_core ili9341 mipi_dbi
> tinydrm backlight ti_ads7950 industrialio_triggered_buffer kfifo_buf
> intel_soc_pmic_mrfld hci_uart btbcm
> [ 23.750599] CPU: 1 PID: 1296 Comm: modprobe Not tainted 5.0.0-rc7+ #236
> [ 23.750605] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS
> 542 2015.01.21:18.19.48
> [ 23.750620] RIP: 0010:check_for_stack+0xb7/0x190
> [ 23.750630] Code: 8b 6d 50 4d 85 ed 75 04 4c 8b 6d 10 48 89 ef e8 2f 8b 44
> 00 48 89 c6 4a 8d 0c 23 4c 89 ea 48 c7 c7 88 d0 82 b4 e8 40 7c f9 ff <0f> 0b
> 8b 05 79 00 4b 01 85 c0 74 07 5b 5d 41 5c 41 5d c3 8b 05 54
> [ 23.750637] RSP: :97bbc0292fa0 EFLAGS: 00010286
> [ 23.750646] RAX: RBX: 97bbc029 RCX:
> 0006
> [ 23.750652] RDX: 0007 RSI: 0002 RDI:
> 94b33e115450
> [ 23.750658] RBP: 94b33c8578b0 R08: 0002 R09:
> 000201c0
> [ 23.750664] R10: 0006ecb0ccc6 R11: 00034f38 R12:
> 316c
> [ 23.750670] R13: 94b33c84b250 R14: 94b33dedd5a0 R15:
> 0001
> [ 23.750679] FS: () GS:94b33e10(0063)
> knlGS:f7faf690
> [ 23.750686] CS: 0010 DS: 002b ES: 002b CR0: 80050033
> [ 23.750691] CR2: f7f54faf CR3: 0722c000 CR4:
> 001006e0
> [ 23.750696] Call Trace:
> [ 23.750713] debug_dma_map_sg+0x100/0x340
> [ 23.750727] ? dma_direct_map_sg+0x3b/0xb0
> [ 23.750739] spi_map_buf+0x25a/0x300
> [ 23.750751] __spi_pump_messages+0x2a4/0x680
> [ 23.750762] __spi_sync+0x1dd/0x1f0
> [ 23.750773] spi_sync+0x26/0x40
> [ 23.750790] mipi_dbi_typec3_command_read+0x14d/0x240 [mipi_dbi]
> [ 23.750802] ? spi_finalize_current_transfer+0x10/0x10
> [ 23.750821] mipi_dbi_typec3_command+0x1bc/0x1d0 [mipi_dbi]
>
After few runs I don't see the warning anymore. So,
Tested-by: Andy Shevchenko
Though I would like to give few more days to monitor the state.
(I believe it's fixed)
> Reported-by: Andy Shevchenko
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/tinydrm/ili9225.c | 6 ++--
> drivers/gpu/drm/tinydrm/mipi-dbi.c | 58 +-
> include/drm/tinydrm/mipi-dbi.h | 5 +--
> 3 files changed, 48 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/tinydrm/ili9225.c
> b/drivers/gpu/drm/tinydrm/ili9225.c
> index 3f59cfbd31ba..a87078667e04 100644
> --- a/drivers/gpu/drm/tinydrm/ili9225.c
> +++ b/drivers/gpu/drm/tinydrm/ili9225.c
> @@ -299,7 +299,7 @@ static void ili9225_pipe_disable(struct
> drm_simple_display_pipe *pipe)
> mipi->enabled = false;
> }
>
> -static int ili9225_dbi_command(struct mipi_dbi *mipi, u8 cmd, u8 *par,
> +static int ili9225_dbi_command(struct mipi_dbi *mipi, u8 *cmd, u8 *par,
> size_t num)
> {
> struct spi_device *spi = mipi->spi;
> @@ -309,11 +309,11 @@ static int ili9225_dbi_command(struct mipi_dbi *mipi,
> u8 cmd, u8 *par,
>
> gpiod_set_value_cansleep(mipi->dc, 0);
> speed_hz = mipi_dbi_spi_cmd_max_speed(spi, 1);
> - ret = tinydrm_spi_transfer(spi, speed_hz, NULL, 8, &cmd, 1);
> + ret = tinydrm_spi_transfer(spi, speed_hz, NULL, 8, cmd, 1);
> if (ret || !num)
> return ret;
>
> - if (cmd == ILI9225_WRITE_DATA_TO_GRAM && !mipi->swap_bytes)
> + if (*cmd == ILI9225_WRITE_DATA_TO_GRAM && !mipi->swap_bytes)
> bpw = 16;
>
> gpiod_set_value_cansleep(mipi->dc, 1);
> diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c
> b/drivers/gpu/drm/tinydrm/mipi-dbi.c
> index 246e708a9ff7..4a4cd7e72938 100644
> --- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
> +++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
> @@ -153,16 +153,42 @@ EXPORT_SYMBOL(mipi_dbi_command_read);
> */
> int mipi_dbi_command_buf(struct mipi_dbi *mipi, u8 cmd, u8 *data, size_t len)
> {
> + u8 *cmdbuf;
> int ret;
>
> + /* SPI requires dma-safe buffers */
> + cmdbuf = kmemdup(&cmd, 1, GFP_KERNEL);
> + if (!cmdbuf)
> + return -ENOMEM;
> +
> mutex_lock(&mipi->cmdlock);
> - ret = mipi->command(mipi, cmd, data, len);
> + ret = mipi->command(mipi, cmdbuf, data, len);
> mutex_unlock(&mipi->cmdlock);
>
> + kfree(cmdbuf);
> +
> return ret;
> }
> EXPORT_SYMBOL(mipi_dbi_comm
Re: [PATCH v5 1/9] mm/mmu_notifier: helper to test if a range invalidation is blockable
On 2/19/19 12:04 PM, jgli...@redhat.com wrote:
From: Jérôme Glisse
Simple helpers to test if range invalidation is blockable. Latter
patches use cocinnelle to convert all direct dereference of range->
blockable to use this function instead so that we can convert the
blockable field to an unsigned for more flags.
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Jan Kara
Cc: Andrea Arcangeli
Cc: Peter Xu
Cc: Felix Kuehling
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: Ross Zwisler
Cc: Dan Williams
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Michal Hocko
Cc: Christian Koenig
Cc: Ralph Campbell
Cc: John Hubbard
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
Cc: Arnd Bergmann
---
include/linux/mmu_notifier.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index 4050ec1c3b45..e630def131ce 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -226,6 +226,12 @@ extern void __mmu_notifier_invalidate_range_end(struct
mmu_notifier_range *r,
extern void __mmu_notifier_invalidate_range(struct mm_struct *mm,
unsigned long start, unsigned long end);
+static inline bool
+mmu_notifier_range_blockable(const struct mmu_notifier_range *range)
+{
+ return range->blockable;
+}
+
static inline void mmu_notifier_release(struct mm_struct *mm)
{
if (mm_has_notifiers(mm))
@@ -455,6 +461,11 @@ static inline void _mmu_notifier_range_init(struct
mmu_notifier_range *range,
#define mmu_notifier_range_init(range, mm, start, end) \
_mmu_notifier_range_init(range, start, end)
+static inline bool
+mmu_notifier_range_blockable(const struct mmu_notifier_range *range)
+{
+ return true;
+}
static inline int mm_has_notifiers(struct mm_struct *mm)
{
Reviewed-by: Ralph Campbell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/i2c: tda998x: adjust CTS_N audio pre-divider calculation
On Fri, Feb 22, 2019 at 8:21 AM Russell King - ARM Linux admin
wrote:
>
> On Thu, Feb 21, 2019 at 01:18:13PM -0500, Sven Van Asbroeck wrote:
>
> > [SNDRV_PCM_FORMAT_S24_LE] = {
> > .width = 24, .phys = 32, .le = 1, .signd = 1,
> > .silence = {},
> > },
>
> The above table describes the memory format, not the wire format.
> Look further down for SNDRV_PCM_FORMAT_S24_3LE, which is 24-bit
> packed into three bytes (see include/uapi/sound/asound.h for
> the comment specifying that.)
>
> ASoC uses DAIFMT to specify the on-wire format in connection with
> the above.
>
Interesting ! So you're saying that currently, nobody strictly defines the
layout of the on-wire format, correct? I'm not sure how this works in practice,
because codec and cpu dai should agree on the on-wire format? Except if the
formats used have enough flexibility so you don't have to care.
If so, we don't seem to have this luxury here :(
>
> This doesn't really help in terms of working out what the correct
> settings should be, and other information I have laying around does not
> provide any further enlightenment.
I have access to the NXP software library shipped with the tda19988.
The library's release notes have the following entry:
. "I2S audio does not work, CTS value is not good"
Check the audio I2S format
CTS is automatically computed by the TDA accordingly to the audio input
so accordingly to the upstream settings (like an OMAP ;)
For example, I2S 16 bits or 32 bits do not produce the same CTS value
The config structure which you need to fill in to init the audio has a
"i2s qualifier" field, where you have the choice between 16 and 32 bits.
This then maps to a "Clock Time Stamp factor x" called CTSX, which maps to
the following CTS_N register settings:
CTSX -> CTS_N (m,k)
---
16 -> (3,0)
32 -> (3,1) (i2s qualifier = 16 bits)
48 -> (3,2)
64 -> (3,3) (i2s qualifier = 32 bits)
128 -> (0,0)
Does this information bring us any closer to our assumption that CTS_N needs
to be calculated off the bclk to sample rate ratio ?
>
> I think what I'd like to see is passing of the Fs value into the driver
> from hdmi-codec, but I suspect that requires a bit of work in multiple
> drivers.
>
I'd love to take a shot at this, but first I'd like to understand what you're
suggesting :)
Currently there is set_bclk_ratio() support, but no-one is actually using it.
If hdmi-codec is to retrieve the ratio, wouldn't we need to add .GET_blk_ratio
to snd_soc_dai_ops ?
I could add this to fsl_ssi in master mode, but what if somebody connects the
tda to a cpu dai for which no-one implemented .GET_bclk_ratio ? Do we guess?
Or just error out?
Also, what would a proposed snd_soc_dai_GET_bclk_ratio() return e.g. on
fsl_ssi in slave mode, where the value arguably doesn't exist because the ssi
will accept pretty much anything you throw at it?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/34] Convert DRM to XArray
On Fri, Feb 22, 2019 at 10:54:21AM +0100, Daniel Vetter wrote: > > - idr_alloc() returned -ENOSPC, radix_tree_insert() returned -EEXIST. > >xa_insert() and xa_alloc() return -EBUSY. > > I think this will upset a few of our tests. Just written some more for > drm-lease at least, and those check for the ENOSPC. Not sure yet what to > do. If there's real userspace (not just a test suite) which actually relies on the exact errno returned, we can change the places which currently just return the errno to something like: if (err == -EBUSY) return -ENOSPC; return err; There are actually a number of places in the kernel which do the opposite translation today, presumably because having a program print out "No space left on device" was confusing. If it's only the test-suite which cares, presumably the test suite can be changed to treat EBUSY and ENOSPC as being equivalent errno values for a given test. > I did at least read the above, I'll leave all the driver patches for > others. At least for now, any leftovers can be smashed into drm-misc. Thanks! I'll resend after -rc1. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/6] R-Car DU DPAD support for D3 and E3
Hi Laurent > > > For your convenience the patches are available from > > > > > > git://linuxtv.org/pinchartl/media.git drm/du/d3e3 > > > > It seems we can't find this branch/tag on your branch > > Is it removed ? or not yet pushed ? > > > > https://git.linuxtv.org/pinchartl/media.git/refs/heads > > The branch has been merged to drm-next (for the DU driver part) and to > Simon's next branch (for the DT part), so I've removed it from my tree. > You can find a merge of those two branches in my repository in the > drm/du/base branch. OK, Thanks. Nice to know Best regards --- Kuninori Morimoto ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202667] amdgpu fails to boot: atombios stuck executing D6A0
https://bugzilla.kernel.org/show_bug.cgi?id=202667 --- Comment #1 from Michel Dänzer (mic...@daenzer.net) --- Please attach the corresponding full output of dmesg. Can you bisect between 4.20.4 and 4.20.5? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109754] util_blitter_generate_mipmap: Assertion `!util_format_has_stencil(desc)' failed
https://bugs.freedesktop.org/show_bug.cgi?id=109754 Michel Dänzer changed: What|Removed |Added Component|DRM/Radeon |Drivers/Gallium/radeonsi Product|DRI |Mesa QA Contact||dri-devel@lists.freedesktop ||.org -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/2] drm/panel: Add driver for Samsung S6E63M0 panel
Hi Paweł, Thierry On Fri, Feb 22, 2019 at 06:51:53PM +0100, Paweł Chmiel wrote: > This patch adds Samsung S6E63M0 AMOLED LCD panel driver, connected over > spi. It's based on already removed, non dt s6e63m0 driver and > panel-samsung-ld9040. It can be found for example in some of Samsung > Aries based phones. > > Signed-off-by: Paweł Chmiel > Reviewed-by: Sam Ravnborg > Reviewed-by: Andrzej Hajda I took a last look at the driver. Everything looks good to me now, and I consider this driver ready to be applied. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108940] QHD bug? drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:1613 core_link_enable_stream+0xc14/0x1040
https://bugs.freedesktop.org/show_bug.cgi?id=108940 --- Comment #17 from Stefan --- Still present in 4.20.12, 5.0rc8 and amd-staging-drm-next-git-b8cd95e15410. What is needed to resolve this? My system remains unstable with frequent/continues crashes. Hard reset is the only option. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107310] intel-gpu-overlay crashes on startup, being aborted
https://bugs.freedesktop.org/show_bug.cgi?id=107310 --- Comment #2 from Petri Latvala --- Does this still happen with a recent kernel? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105359] kms_frontbuffer_tracking - FBC disabled
https://bugs.freedesktop.org/show_bug.cgi?id=105359 Petri Latvala changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Petri Latvala --- *** This bug has been marked as a duplicate of bug 108040 *** -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105915] [IGT] igt@kms_cursor_crc@cursor-128x128-rapid-movement / cursor-256x256-rapid-movement igt-debugfs-WARNING: Warning on condition crc->crc[i] == 0xffffffff in function crc_sanity_checks, f
https://bugs.freedesktop.org/show_bug.cgi?id=105915 Petri Latvala changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Petri Latvala --- *** This bug has been marked as a duplicate of bug 107724 *** -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105915] [IGT] igt@kms_cursor_crc@cursor-128x128-rapid-movement / cursor-256x256-rapid-movement igt-debugfs-WARNING: Warning on condition crc->crc[i] == 0xffffffff in function crc_sanity_checks, f
https://bugs.freedesktop.org/show_bug.cgi?id=105915 --- Comment #2 from Ricardo Perez --- Hi Team, I’ll be OoO starting from the time you read this message. See you in the office WW 9.1 If you need something from me that can't wait, please contact my manager: Ada Cabrales. Regards -Richo -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109768] some bug
https://bugs.freedesktop.org/show_bug.cgi?id=109768 Bug ID: 109768 Summary: some bug Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: minor Priority: medium Component: DRM/AMDgpu-pro Assignee: dri-devel@lists.freedesktop.org Reporter: pallamravi...@cvsr.ac.in some components not functional works -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109769] some bug
https://bugs.freedesktop.org/show_bug.cgi?id=109769 Bug ID: 109769 Summary: some bug Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: minor Priority: medium Component: DRM/AMDgpu-pro Assignee: dri-devel@lists.freedesktop.org Reporter: 16h61a0...@cvsr.ac.in some components not functioning well -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109770] some bug
https://bugs.freedesktop.org/show_bug.cgi?id=109770 Bug ID: 109770 Summary: some bug Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: minor Priority: medium Component: DRM/AMDgpu-pro Assignee: dri-devel@lists.freedesktop.org Reporter: 16h61a0...@cvsr.ac.in some components not functional work -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109770] some bug
https://bugs.freedesktop.org/show_bug.cgi?id=109770 16h61a0...@cvsr.ac.in changed: What|Removed |Added Version|XOrg git|DRI git -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109773] Some bug
https://bugs.freedesktop.org/show_bug.cgi?id=109773 Bug ID: 109773 Summary: Some bug Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu-pro Assignee: dri-devel@lists.freedesktop.org Reporter: 16h61a0...@cvsr.ac.in some comments -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109772] some bug
https://bugs.freedesktop.org/show_bug.cgi?id=109772 Bug ID: 109772 Summary: some bug Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: minor Priority: medium Component: DRM/AMDgpu-pro Assignee: dri-devel@lists.freedesktop.org Reporter: 16h61a0...@cvsr.ac.in it causes disturbance to me -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109774] some bug
https://bugs.freedesktop.org/show_bug.cgi?id=109774 Bug ID: 109774 Summary: some bug Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu-pro Assignee: dri-devel@lists.freedesktop.org Reporter: 16h61a0...@cvsr.ac.in some comment -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109607] [CI][DRMTIP] Time is passing at a different rate between IGT machines and the controller
https://bugs.freedesktop.org/show_bug.cgi?id=109607
--- Comment #6 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- fi-icl-u2, fi-icl-u3: random tests - incomplete -}
{+ fi-icl-u2, fi-icl-u3: random tests - incomplete +}
No new failures caught with the new filter
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: etnaviv: avoid DMA API warning when importing buffers
On Mon, Feb 25, 2019 at 10:51:30AM +, Russell King wrote:
> During boot, I get this kernel warning:
>
> WARNING: CPU: 0 PID: 19001 at kernel/dma/debug.c:1301
> debug_dma_map_sg+0x284/0x3dc
> etnaviv etnaviv: DMA-API: mapping sg segment longer than device claims to
> support [len=3145728] [max=65536]
> Modules linked in: ip6t_REJECT nf_reject_ipv6 ip6t_rpfilter xt_tcpudp
> ipt_REJECT nf_reject_ipv4 xt_conntrack ip_set nfnetlink ebtable_broute
> ebtable_nat ip6table_raw ip6table_nat nf_nat_ipv6 ip6table_mangle iptable_raw
> iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv4 nf_defrag_ipv6
> libcrc32c iptable_mangle ebtable_filter ebtables ip6table_filter ip6_tables
> iptable_filter caam_jr error snd_soc_imx_spdif imx_thermal snd_soc_imx_audmux
> nvmem_imx_ocotp snd_soc_sgtl5000
> caam imx_sdma virt_dma coda rc_cec v4l2_mem2mem snd_soc_fsl_ssi
> snd_soc_fsl_spdif imx_vdoa imx_pcm_dma videobuf2_dma_contig etnaviv
> dw_hdmi_cec gpu_sched dw_hdmi_ahb_audio imx6q_cpufreq nfsd sch_fq_codel
> ip_tables x_tables
> CPU: 0 PID: 19001 Comm: Xorg Not tainted 4.20.0+ #307
> Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x9c/0xd4)
> [] (dump_stack) from [] (__warn+0xf8/0x124)
> [] (__warn) from [] (warn_slowpath_fmt+0x38/0x48)
> [] (warn_slowpath_fmt) from []
> (debug_dma_map_sg+0x284/0x3dc)
> [] (debug_dma_map_sg) from []
> (drm_gem_map_dma_buf+0xc4/0x13c)
> [] (drm_gem_map_dma_buf) from []
> (dma_buf_map_attachment+0x38/0x5c)
> [] (dma_buf_map_attachment) from []
> (drm_gem_prime_import_dev+0x74/0x104)
> [] (drm_gem_prime_import_dev) from []
> (drm_gem_prime_fd_to_handle+0x84/0x17c)
> [] (drm_gem_prime_fd_to_handle) from []
> (drm_prime_fd_to_handle_ioctl+0x38/0x4c)
> [] (drm_prime_fd_to_handle_ioctl) from []
> (drm_ioctl_kernel+0x90/0xc8)
> [] (drm_ioctl_kernel) from [] (drm_ioctl+0x1e0/0x3b0)
> [] (drm_ioctl) from [] (do_vfs_ioctl+0x90/0xa48)
> [] (do_vfs_ioctl) from [] (ksys_ioctl+0x34/0x60)
> [] (ksys_ioctl) from [] (ret_fast_syscall+0x0/0x28)
> Exception stack(0xd81a9fa8 to 0xd81a9ff0)
> 9fa0: b6c69c88 bec613f8 0009 c00c642e bec613f8 b86c4600
> 9fc0: b6c69c88 bec613f8 c00c642e 0036 012762e0 01276348 0300 012d91f8
> 9fe0: b6989f18 bec613dc b697185c b667be5c
> irq event stamp: 47905
> hardirqs last enabled at (47913): [] console_unlock+0x46c/0x680
> hardirqs last disabled at (47922): [] console_unlock+0xb8/0x680
> softirqs last enabled at (47754): [] __do_softirq+0x344/0x540
> softirqs last disabled at (47701): [] irq_exit+0x124/0x144
> ---[ end trace af477747acbcc642 ]---
>
> The reason is the contiguous buffer exceeds the default maximum segment
> size of 64K as specified by dma_get_max_seg_size() in
> linux/dma-mapping.h. Fix this by providing our own segment size, which
> is set to 2GiB to cover the window found in MMUv1 GPUs.
>
> Signed-off-by: Russell King
Fixes: 78c47830a5cb ("dma-debug: check scatterlist segments")
not really that there's a problem with that commit, but it is where the
warning was introduced.
> ---
> Patch against v4.20.
>
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 4
> drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index 4713885012ab..e414f284f424 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -527,6 +527,9 @@ static int etnaviv_bind(struct device *dev)
> }
> drm->dev_private = priv;
>
> + dev->dma_parms = &priv->dma_parms;
> + dma_set_max_seg_size(dev, SZ_2G);
> +
> mutex_init(&priv->gem_lock);
> INIT_LIST_HEAD(&priv->gem_list);
> priv->num_gpus = 0;
> @@ -564,6 +567,7 @@ static void etnaviv_unbind(struct device *dev)
>
> component_unbind_all(dev, drm);
>
> + dev->dma_parms = NULL;
> drm->dev_private = NULL;
> kfree(priv);
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> index 8d02d1b7dcf5..b2930d1fe97c 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> @@ -43,6 +43,7 @@ struct etnaviv_file_private {
>
> struct etnaviv_drm_private {
> int num_gpus;
> + struct device_dma_parameters dma_parms;
> struct etnaviv_gpu *gpu[ETNA_MAX_PIPES];
>
> /* list of GEM objects: */
> --
> 2.7.4
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202667] amdgpu fails to boot: atombios stuck executing D6A0
https://bugzilla.kernel.org/show_bug.cgi?id=202667 --- Comment #2 from Dennis Wagelaar (dwagel...@gmail.com) --- Created attachment 281333 --> https://bugzilla.kernel.org/attachment.cgi?id=281333&action=edit journalctl --no-hostname -k for kernel-4.20.4-100.fc28.x86_64 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202667] amdgpu fails to boot: atombios stuck executing D6A0
https://bugzilla.kernel.org/show_bug.cgi?id=202667 --- Comment #3 from Dennis Wagelaar (dwagel...@gmail.com) --- Created attachment 281335 --> https://bugzilla.kernel.org/attachment.cgi?id=281335&action=edit journalctl --no-hostname -k for kernel-4.20.5-100.fc28.x86_64 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] drm/bridge: sii902x: HDMI-audio support and some fixes
- The bus_flags patch is important for DRM masters that rely on those, but the chage is in no way dependend on HDMI-audio support. - The output mode patch is needed for HDMI-audio to work. - The HDMI-audio implementation supports only i2s-mode. - I do not know if the pixel clock unit change has any effect on the actual functionality. Jyri Sarha (3): drm/bridge: sii902x: Set output mode to HDMI or DVI according to EDID drm/bridge: sii902x: Implement HDMI audio support drm/bridge: sii902x: pixel clock unit is 10kHz instead of 1kHz Tomi Valkeinen (1): drm/bridge: sii902x: add input_bus_flags .../bindings/display/bridge/sii902x.txt | 24 + drivers/gpu/drm/bridge/sii902x.c | 475 +- include/dt-bindings/sound/sii902x-audio.h | 11 + 3 files changed, 503 insertions(+), 7 deletions(-) create mode 100644 include/dt-bindings/sound/sii902x-audio.h -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/bridge: sii902x: add input_bus_flags
From: Tomi Valkeinen
The driver always sets InputBusFmt:EDGE to 0 (falling edge).
Add drm_bridge_timings's input_bus_flags to reflect that the bridge
samples on falling edges.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/bridge/sii902x.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index bfa902013aa4..1afa000141d5 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -459,6 +459,12 @@ static int sii902x_i2c_bypass_deselect(struct i2c_mux_core
*mux, u32 chan_id)
return 0;
}
+static const struct drm_bridge_timings default_sii902x_timings = {
+ .input_bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE
+| DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE
+| DRM_BUS_FLAG_DE_HIGH,
+};
+
static int sii902x_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -529,6 +535,7 @@ static int sii902x_probe(struct i2c_client *client,
sii902x->bridge.funcs = &sii902x_bridge_funcs;
sii902x->bridge.of_node = dev->of_node;
+ sii902x->bridge.timings = &default_sii902x_timings;
drm_bridge_add(&sii902x->bridge);
i2c_set_clientdata(client, sii902x);
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/bridge: sii902x: Implement HDMI audio support
Implement HDMI audio support by using ASoC HDMI codec. The commit
implements the necessary callbacks and configuration for the HDMI
codec and registers a virtual platform device for the codec to attach.
Signed-off-by: Jyri Sarha
---
.../bindings/display/bridge/sii902x.txt | 24 +
drivers/gpu/drm/bridge/sii902x.c | 456 +-
include/dt-bindings/sound/sii902x-audio.h | 11 +
3 files changed, 485 insertions(+), 6 deletions(-)
create mode 100644 include/dt-bindings/sound/sii902x-audio.h
diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
index 72d2dc6c3e6b..a1cff91e4e84 100644
--- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
+++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
@@ -8,6 +8,21 @@ Optional properties:
- interrupts: describe the interrupt line used to inform the host
about hotplug events.
- reset-gpios: OF device-tree gpio specification for RST_N pin.
+ - i2s-fifo-routing: Array of exactly 4 integers indicating i2s
+ pins for audio fifo routing. First integer defines routing to
+ fifo 0 and second to fifo 1, etc. Integers can be filled with
+ definitions from: include/dt-bindings/sound/sii902x-audio.h
+ The available definitions are:
+ - ENABLE_BIT: enable this audio fifo
+ - CONNECT_SD#: route audio input from SD0, SD1, SD2, or SD3 i2s
+data input pin
+ - LEFT_RIGHT_SWAP_BIT: swap i2s input channels for this fifo
+ I2S HDMI audio is configured only if this property is found.
+ - clocks: describes SII902x MCLK input. MCLK is used to produce
+ HDMI audio CTS values. This property is required if
+ "i2s-fifo-routing"-property is present. This property follows
+ Documentation/devicetree/bindings/clock/clock-bindings.txt
+ consumer binding.
Optional subnodes:
- video input: this subnode can contain a video input port node
@@ -21,6 +36,15 @@ Example:
compatible = "sil,sii9022";
reg = <0x39>;
reset-gpios = <&pioA 1 0>;
+
+ i2s-fifo-routing = <
+ (ENABLE_BIT|CONNECT_SD0)
+ 0
+ 0
+ 0
+ >;
+ clocks = <&mclk>;
+
ports {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index 0e21fa419d27..f296a33c57c7 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -27,12 +27,16 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
+#include
+
#define SII902X_TPI_VIDEO_DATA 0x0
#define SII902X_TPI_PIXEL_REPETITION 0x8
@@ -74,6 +78,77 @@
#define SII902X_AVI_POWER_STATE_MSKGENMASK(1, 0)
#define SII902X_AVI_POWER_STATE_D(l) ((l) &
SII902X_AVI_POWER_STATE_MSK)
+/* Audio */
+#define SII902X_TPI_I2S_ENABLE_MAPPING_REG 0x1f
+#define SII902X_TPI_I2S_CONFIG_FIFO0 (0 << 0)
+#define SII902X_TPI_I2S_CONFIG_FIFO1 (1 << 0)
+#define SII902X_TPI_I2S_CONFIG_FIFO2 (2 << 0)
+#define SII902X_TPI_I2S_CONFIG_FIFO3 (3 << 0)
+#define SII902X_TPI_I2S_LEFT_RIGHT_SWAP(1 << 2)
+#define SII902X_TPI_I2S_AUTO_DOWNSAMPLE(1 << 3)
+#define SII902X_TPI_I2S_SELECT_SD0 (0 << 4)
+#define SII902X_TPI_I2S_SELECT_SD1 (1 << 4)
+#define SII902X_TPI_I2S_SELECT_SD2 (2 << 4)
+#define SII902X_TPI_I2S_SELECT_SD3 (3 << 4)
+#define SII902X_TPI_I2S_FIFO_ENABLE(1 << 7)
+
+#define SII902X_TPI_I2S_INPUT_CONFIG_REG 0x20
+#define SII902X_TPI_I2S_FIRST_BIT_SHIFT_YES(0 << 0)
+#define SII902X_TPI_I2S_FIRST_BIT_SHIFT_NO (1 << 0)
+#define SII902X_TPI_I2S_SD_DIRECTION_MSB_FIRST (0 << 1)
+#define SII902X_TPI_I2S_SD_DIRECTION_LSB_FIRST (1 << 1)
+#define SII902X_TPI_I2S_SD_JUSTIFY_LEFT(0 << 2)
+#define SII902X_TPI_I2S_SD_JUSTIFY_RIGHT (1 << 2)
+#define SII902X_TPI_I2S_WS_POLARITY_LOW(0 << 3)
+#define SII902X_TPI_I2S_WS_POLARITY_HIGH (1 << 3)
+#define SII902X_TPI_I2S_MCLK_MULTIPLIER_128(0 << 4)
+#define SII902X_TPI_I2S_MCLK_MULTIPLIER_256(1 << 4)
+#define SII902X_TPI_I2S_MCLK_MULTIPLIER_384(2 << 4)
+#define SII902X_TPI_I2S_MCLK_MULTIPLIER_512(3 << 4)
+#define SII902X_TPI_I2S_MCLK_MULTIPLIER_768(4 << 4)
+#define SII902X_TPI_I2S_MCLK_MULTIPLIER_1024 (5 << 4)
+#define SII902X_TPI_I2S_MCLK_MULTIPLIER_1152
[PATCH 4/4] drm/bridge: sii902x: pixel clock unit is 10kHz instead of 1kHz
The pixel clock unit in the first two registers (0x00 and 0x01) of sii9022 is 10kHz, not 1kHz as in struct drm_display_mode. Division by 10 fixes the issue. Signed-off-by: Jyri Sarha --- drivers/gpu/drm/bridge/sii902x.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c index f296a33c57c7..9cf0dbb6c764 100644 --- a/drivers/gpu/drm/bridge/sii902x.c +++ b/drivers/gpu/drm/bridge/sii902x.c @@ -358,10 +358,11 @@ static void sii902x_bridge_mode_set(struct drm_bridge *bridge, struct regmap *regmap = sii902x->regmap; u8 buf[HDMI_INFOFRAME_SIZE(AVI)]; struct hdmi_avi_infoframe frame; + u16 pixel_clock_10kHz = adj->clock / 10; int ret; - buf[0] = adj->clock; - buf[1] = adj->clock >> 8; + buf[0] = pixel_clock_10kHz & 0xFF; + buf[1] = pixel_clock_10kHz >> 8; buf[2] = adj->vrefresh; buf[3] = 0x00; buf[4] = adj->hdisplay; -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/bridge: sii902x: Set output mode to HDMI or DVI according to EDID
Set output mode to HDMI or DVI according to EDID HDMI signature.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/bridge/sii902x.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index 1afa000141d5..0e21fa419d27 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -181,11 +181,15 @@ static int sii902x_get_modes(struct drm_connector
*connector)
struct sii902x *sii902x = connector_to_sii902x(connector);
u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
struct edid *edid;
+ u8 output_mode = SII902X_SYS_CTRL_OUTPUT_DVI;
int num = 0, ret;
edid = drm_get_edid(connector, sii902x->i2cmux->adapter[0]);
drm_connector_update_edid_property(connector, edid);
if (edid) {
+ if (drm_detect_hdmi_monitor(edid))
+ output_mode = SII902X_SYS_CTRL_OUTPUT_HDMI;
+
num = drm_add_edid_modes(connector, edid);
kfree(edid);
}
@@ -195,6 +199,11 @@ static int sii902x_get_modes(struct drm_connector
*connector)
if (ret)
return ret;
+ ret = regmap_update_bits(sii902x->regmap, SII902X_SYS_CTRL_DATA,
+SII902X_SYS_CTRL_OUTPUT_MODE, output_mode);
+ if (ret)
+ return ret;
+
return num;
}
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202667] amdgpu fails to boot: atombios stuck executing D6A0
https://bugzilla.kernel.org/show_bug.cgi?id=202667 --- Comment #4 from Michel Dänzer (mic...@daenzer.net) --- The attached output from 4.20.4 shows DC being enabled. Does the problem really not happen with 4.20.4 and DC disabled? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202667] amdgpu fails to boot: atombios stuck executing D6A0
https://bugzilla.kernel.org/show_bug.cgi?id=202667 --- Comment #5 from Dennis Wagelaar (dwagel...@gmail.com) --- Created attachment 281337 --> https://bugzilla.kernel.org/attachment.cgi?id=281337&action=edit Active kernel module parameters for 4.20.4 Hmm, I have: options amdgpu dc=0 in /etc/modprobe.d/amdgpu.conf, but my active module parameters say DC is enabled anyway... -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202667] amdgpu fails to boot: atombios stuck executing D6A0
https://bugzilla.kernel.org/show_bug.cgi?id=202667 --- Comment #6 from Dennis Wagelaar (dwagel...@gmail.com) --- Created attachment 281339 --> https://bugzilla.kernel.org/attachment.cgi?id=281339&action=edit journalctl --no-hostname -k for kernel-4.20.8-100.fc28.x86_64 with amdgpu.dc=1 Just found out changing stuff in /etc/modprobe.d/ has no effect until the next run of dracut :$ It turns out I can no longer use amdgpu without DC=1. With that enabled, the newer kernel run as normal. What probably happened is that I saw the flicker once, which is mentioned here: https://wiki.archlinux.org/index.php/AMDGPU : "If you experience flickering add amdgpu.dc=0 to your kernel parameters." That's when trouble began. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202667] amdgpu fails to boot: atombios stuck executing D6A0
https://bugzilla.kernel.org/show_bug.cgi?id=202667 Dennis Wagelaar (dwagel...@gmail.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/bridge: sii902x: add input_bus_flags
On 25.02.2019 12:23, Jyri Sarha wrote:
> From: Tomi Valkeinen
>
> The driver always sets InputBusFmt:EDGE to 0 (falling edge).
>
> Add drm_bridge_timings's input_bus_flags to reflect that the bridge
> samples on falling edges.
>
> Signed-off-by: Tomi Valkeinen
> Signed-off-by: Jyri Sarha
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/gpu/drm/bridge/sii902x.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/sii902x.c
> b/drivers/gpu/drm/bridge/sii902x.c
> index bfa902013aa4..1afa000141d5 100644
> --- a/drivers/gpu/drm/bridge/sii902x.c
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -459,6 +459,12 @@ static int sii902x_i2c_bypass_deselect(struct
> i2c_mux_core *mux, u32 chan_id)
> return 0;
> }
>
> +static const struct drm_bridge_timings default_sii902x_timings = {
> + .input_bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE
> + | DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE
> + | DRM_BUS_FLAG_DE_HIGH,
> +};
> +
> static int sii902x_probe(struct i2c_client *client,
>const struct i2c_device_id *id)
> {
> @@ -529,6 +535,7 @@ static int sii902x_probe(struct i2c_client *client,
>
> sii902x->bridge.funcs = &sii902x_bridge_funcs;
> sii902x->bridge.of_node = dev->of_node;
> + sii902x->bridge.timings = &default_sii902x_timings;
> drm_bridge_add(&sii902x->bridge);
>
> i2c_set_clientdata(client, sii902x);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm/bridge: sii902x: Set output mode to HDMI or DVI according to EDID
On 25.02.2019 12:23, Jyri Sarha wrote:
> Set output mode to HDMI or DVI according to EDID HDMI signature.
>
> Signed-off-by: Jyri Sarha
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/gpu/drm/bridge/sii902x.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/sii902x.c
> b/drivers/gpu/drm/bridge/sii902x.c
> index 1afa000141d5..0e21fa419d27 100644
> --- a/drivers/gpu/drm/bridge/sii902x.c
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -181,11 +181,15 @@ static int sii902x_get_modes(struct drm_connector
> *connector)
> struct sii902x *sii902x = connector_to_sii902x(connector);
> u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
> struct edid *edid;
> + u8 output_mode = SII902X_SYS_CTRL_OUTPUT_DVI;
> int num = 0, ret;
>
> edid = drm_get_edid(connector, sii902x->i2cmux->adapter[0]);
> drm_connector_update_edid_property(connector, edid);
> if (edid) {
> + if (drm_detect_hdmi_monitor(edid))
> + output_mode = SII902X_SYS_CTRL_OUTPUT_HDMI;
> +
> num = drm_add_edid_modes(connector, edid);
> kfree(edid);
> }
> @@ -195,6 +199,11 @@ static int sii902x_get_modes(struct drm_connector
> *connector)
> if (ret)
> return ret;
>
> + ret = regmap_update_bits(sii902x->regmap, SII902X_SYS_CTRL_DATA,
> + SII902X_SYS_CTRL_OUTPUT_MODE, output_mode);
> + if (ret)
> + return ret;
> +
> return num;
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/bridge: sii902x: pixel clock unit is 10kHz instead of 1kHz
On 25.02.2019 12:23, Jyri Sarha wrote: > The pixel clock unit in the first two registers (0x00 and 0x01) of > sii9022 is 10kHz, not 1kHz as in struct drm_display_mode. Division by > 10 fixes the issue. > > Signed-off-by: Jyri Sarha Reviewed-by: Andrzej Hajda -- Regards Andrzej > --- > drivers/gpu/drm/bridge/sii902x.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/sii902x.c > b/drivers/gpu/drm/bridge/sii902x.c > index f296a33c57c7..9cf0dbb6c764 100644 > --- a/drivers/gpu/drm/bridge/sii902x.c > +++ b/drivers/gpu/drm/bridge/sii902x.c > @@ -358,10 +358,11 @@ static void sii902x_bridge_mode_set(struct drm_bridge > *bridge, > struct regmap *regmap = sii902x->regmap; > u8 buf[HDMI_INFOFRAME_SIZE(AVI)]; > struct hdmi_avi_infoframe frame; > + u16 pixel_clock_10kHz = adj->clock / 10; > int ret; > > - buf[0] = adj->clock; > - buf[1] = adj->clock >> 8; > + buf[0] = pixel_clock_10kHz & 0xFF; > + buf[1] = pixel_clock_10kHz >> 8; > buf[2] = adj->vrefresh; > buf[3] = 0x00; > buf[4] = adj->hdisplay; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] libdrm: Fix issue about differrent domainID but same BDF
Hi all,
This patch causes unnecessary round trip by openning the nodes. As
mentioned previously this could be trivially fixed [1].
Even Emily acknowledged that [1], yet the sub-par fix was merged. Can
we revert+fixup this properly?
Thanks
Emil
[1] https://lists.freedesktop.org/archives/amd-gfx/2019-February/031573.html
On Fri, 22 Feb 2019 at 21:05, Alex Deucher wrote:
>
> Pushed. Thanks!
>
> Alex
>
> On Thu, Feb 21, 2019 at 9:36 PM Deng, Emily wrote:
> >
> > Hi Alex,
> > Please help, thanks.
> >
> > Best wishes
> > Emily Deng
> >
> >
> >
> > >-Original Message-
> > >From: Alex Deucher
> > >Sent: Friday, February 22, 2019 12:13 AM
> > >To: Deng, Emily ; Maling list - DRI developers > >de...@lists.freedesktop.org>
> > >Cc: amd-gfx list
> > >Subject: Re: [PATCH libdrm] libdrm: Fix issue about differrent domainID
> > >but same
> > >BDF
> > >
> > >On Thu, Feb 14, 2019 at 2:53 AM Emily Deng wrote:
> > >>
> > >> For multiple GPUs which has the same BDF, but has different domain ID,
> > >> the drmOpenByBusid will return the wrong fd when startx.
> > >>
> > >> The reproduce sequence as below:
> > >> 1. Call drmOpenByBusid to open Card0, then will return the right fd0,
> > >> and the
> > >> fd0 is master privilege;
> > >> 2. Call drmOpenByBusid to open Card1. In function drmOpenByBusid, it
> > >> will open Card0 first, this time, the fd1 for opening Card0 is not
> > >> master privilege, and will call drmSetInterfaceVersion to identify the
> > >> domain ID feature, as the fd1 is not master privilege, then
> > >> drmSetInterfaceVersion will fail, and then won't compare domain ID, then
> > >return the wrong fd for Card1.
> > >>
> > >> Solution:
> > >> First loop search the best match fd about drm 1.4.
> > >>
> > >> Signed-off-by: Emily Deng
> > >
> > >Reviewed-by: Alex Deucher
> > >
> > >Do you need someone to commit this for you?
> > >
> > >Alex
> > >
> > >> ---
> > >> xf86drm.c | 23 +++
> > >> 1 file changed, 23 insertions(+)
> > >>
> > >> diff --git a/xf86drm.c b/xf86drm.c
> > >> index 336d64d..b60e029 100644
> > >> --- a/xf86drm.c
> > >> +++ b/xf86drm.c
> > >> @@ -584,11 +584,34 @@ static int drmOpenByBusid(const char *busid, int
> > >type)
> > >> if (base < 0)
> > >> return -1;
> > >>
> > >> +/* We need to try for 1.4 first for proper PCI domain support */
> > >> drmMsg("drmOpenByBusid: Searching for BusID %s\n", busid);
> > >> for (i = base; i < base + DRM_MAX_MINOR; i++) {
> > >> fd = drmOpenMinor(i, 1, type);
> > >> drmMsg("drmOpenByBusid: drmOpenMinor returns %d\n", fd);
> > >> if (fd >= 0) {
> > >> +sv.drm_di_major = 1;
> > >> +sv.drm_di_minor = 4;
> > >> +sv.drm_dd_major = -1;/* Don't care */
> > >> +sv.drm_dd_minor = -1;/* Don't care */
> > >> +if (!drmSetInterfaceVersion(fd, &sv)) {
> > >> +buf = drmGetBusid(fd);
> > >> +drmMsg("drmOpenByBusid: drmGetBusid reports %s\n", buf);
> > >> +if (buf && drmMatchBusID(buf, busid, 1)) {
> > >> +drmFreeBusid(buf);
> > >> +return fd;
> > >> +}
> > >> +if (buf)
> > >> +drmFreeBusid(buf);
> > >> +}
> > >> +close(fd);
> > >> +}
> > >> +}
> > >> +
> > >> + for (i = base; i < base + DRM_MAX_MINOR; i++) {
> > >> +fd = drmOpenMinor(i, 1, type);
> > >> +drmMsg("drmOpenByBusid: drmOpenMinor returns %d\n", fd);
> > >> +if (fd >= 0) {
> > >> /* We need to try for 1.4 first for proper PCI domain
> > >> support
> > >> * and if that fails, we know the kernel is busted
> > >> */
> > >> --
> > >> 2.7.4
> > >>
> > >> ___
> > >> amd-gfx mailing list
> > >> amd-...@lists.freedesktop.org
> > >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] Propagate DP-over-Type-C hotplug events from Type-C subsys to drm-drivers
Hi All, On some Cherry Trail devices, DisplayPort over Type-C is supported through a USB-PD microcontroller (e.g. a fusb302) + a mux to switch the superspeed datalines between USB-3 and DP (e.g. a pi3usb30532). The kernel in this case does the PD/alt-mode negotiation itself, rather then everything being handled in firmware. So the kernel itself picks an alt-mode, tells the Type-C "dongle" to switch to DP mode and sets the mux accordingly. In this setup the HPD pin is not connected, so the i915 driver needs to respond to a software event and scan the DP port for changes manually. Thanks to Heikki's great work on the DisplayPort altmode support in the typec subsys, we now correctly tell the dongle to switch to DP altmode and we correctly set the mux and orientation switches to connect the DP lines to the Type-C connector. This just leaves sending an out-of-band hotplug event from the Type-C subsystem to the i915 driver and then we've fully working DP over Type-C on these devices. This series implements this. The first patch adds a generic mechanism for oob hotplug events to be send to the drm subsys, the second patch adds support for this mechanism to the i915 driver and the third patch makes the typec displayport_altmode driver send these events. The commit message of the first patch explains why I've chosen to things the way these patches do them. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm: Add support for out-of-band hotplug notification
On some hardware a hotplug event notification may come from outside the
display driver / device.
One example of this is laptops with hybrid graphics where one or more
outputs are connected to the discrete GPU only. In this case if the
discrete GPU is fully powered down to save power, a hotplug to one of
these outputs will not be noticed through normal means. These laptops
have another mechanism to detect the hotplug which will typically raise
an event on the ACPI video bus.
Another example of this is some USB Type-C setups where the hardware
muxes the DisplayPort data and aux-lines but does not pass the altmode
HPD status bit to the GPUs DP HPD pin.
This commit adds a loose coupling to the drm subsys allowing event-sources
to notify drm-drivers of such events without needing a reference to a
drm-device or a drm-connector.
This loose coupling is implemented through a blocking notifier. drm-drivers
interested in oob hotplug events can register themselves to receive
notifations and event-sources call drm_kms_call_oob_hotplug_notifier_chain
to let any listeners know about events.
An earlier attempt has been done to implement this functionality with a
tight coupling, where the event-source would somehow figure out the right
drm-connector to deliver the event to and then send it directly to that
drm-connector. Such a tight coupling approach has several issues with
lifetime management of the coupled objects as well as introducing several
probe-ordering issues. Therefor the tight coupling approach has been
abandoned.
Note for now drm_kms_call_oob_hotplug_notifier_chain's event parameter can
only have 1 value: DRM_OOB_HOTPLUG_TYPE_C_DP. The ACPI videobus hotplug
event case is currently already supported in the nouveau driver by
registering a generic acpi event notifier.
Signed-off-by: Hans de Goede
---
Documentation/gpu/drm-kms-helpers.rst | 1 +
drivers/gpu/drm/drm_probe_helper.c| 67 +++
include/drm/drm_probe_helper.h| 12 +
3 files changed, 80 insertions(+)
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index b422eb8edf16..f144d68f8e7a 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -249,6 +249,7 @@ Output Probing Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_probe_helper.c
:doc: output probing helper overview
+ :doc: out-of-band hotplug event helper overview
.. kernel-doc:: drivers/gpu/drm/drm_probe_helper.c
:export:
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 6fd08e04b323..4f0b421514ef 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -31,6 +31,7 @@
#include
#include
+#include
#include
#include
@@ -792,3 +793,69 @@ bool drm_helper_hpd_irq_event(struct drm_device *dev)
return changed;
}
EXPORT_SYMBOL(drm_helper_hpd_irq_event);
+
+/**
+ * DOC: out-of-band hotplug event helper overview
+ *
+ * On some hardware a hotplug event notification may come from outside
+ * the display driver / device.
+ *
+ * One example of this is laptops with hybrid graphics where one or more
+ * outputs are connected to the discrete GPU only. In this case if the discrete
+ * GPU is fully powered down to save power, a hotplug to one of these outputs
+ * will not be noticed through normal means. These laptops have another
+ * mechanism to detect the hotplug which will typically raise an event on the
+ * ACPI video bus.
+ *
+ * Another example of this is some USB Type-C setups where the hardware
+ * muxes the DisplayPort data and aux-lines but does not pass the altmode
+ * HPD status bit to the GPUs DP HPD pin.
+ *
+ * The oob hotplug helper functions allow a drm display driver to listen
+ * for such oob events and allow other subsystems to notify listeners of
+ * these events.
+ */
+
+static BLOCKING_NOTIFIER_HEAD(drm_kms_oob_hotplug_notifier_head);
+
+/**
+ * drm_kms_register_oob_hotplug_notifier - register an oob hotplug notifier
+ * @nb: notifier_block to register
+ *
+ * Drivers can use this helper function to register a notifier for
+ * out-of-band hotplug events.
+ */
+int drm_kms_register_oob_hotplug_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_register(
+ &drm_kms_oob_hotplug_notifier_head, nb);
+}
+EXPORT_SYMBOL(drm_kms_register_oob_hotplug_notifier);
+
+/**
+ * drm_kms_unregister_oob_hotplug_notifier - unregister an oob hotplug notifier
+ * @nb: notifier_block to register
+ *
+ * Drivers can use this helper function to unregister a notifier for
+ * out-of-band hotplug events.
+ */
+int drm_kms_unregister_oob_hotplug_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_unregister(
+ &drm_kms_oob_hotplug_notifier_head, nb);
+}
+EXPORT_SYMBOL(drm_kms_unregister_oob_hotplug_notifier);
+
+/**
+ * drm_kms_call_oob_hotplug_notifier
[PATCH 3/3] usb: typec: altmodes/displayport: Notify drm subsys of hotplug events
Use the new drm_kms_call_oob_hotplug_notifier_chain() function to load
drm/kms drivers know about DisplayPort over Type-C hotplug events.
Signed-off-by: Hans de Goede
---
drivers/usb/typec/altmodes/displayport.c | 34
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/typec/altmodes/displayport.c
b/drivers/usb/typec/altmodes/displayport.c
index 35161594e368..87760ea252d6 100644
--- a/drivers/usb/typec/altmodes/displayport.c
+++ b/drivers/usb/typec/altmodes/displayport.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#define DP_HEADER(cmd) (VDO(USB_TYPEC_DP_SID, 1, cmd) | \
VDO_OPOS(USB_TYPEC_DP_MODE))
@@ -67,12 +68,23 @@ struct dp_altmode {
const struct typec_altmode *port;
};
-static int dp_altmode_notify(struct dp_altmode *dp)
+static int dp_altmode_notify(struct dp_altmode *dp, unsigned long conf)
+{
+ int ret;
+
+ ret = typec_altmode_notify(dp->alt, conf, &dp->data);
+ if (ret)
+ return ret;
+
+ drm_kms_call_oob_hotplug_notifier_chain(DRM_OOB_HOTPLUG_TYPE_C_DP);
+ return 0;
+}
+
+static int dp_altmode_notify_dp(struct dp_altmode *dp)
{
u8 state = get_count_order(DP_CONF_GET_PIN_ASSIGN(dp->data.conf));
- return typec_altmode_notify(dp->alt, TYPEC_MODAL_STATE(state),
- &dp->data);
+ return dp_altmode_notify(dp, TYPEC_MODAL_STATE(state));
}
static int dp_altmode_configure(struct dp_altmode *dp, u8 con)
@@ -145,10 +157,9 @@ static int dp_altmode_configured(struct dp_altmode *dp)
sysfs_notify(&dp->alt->dev.kobj, "displayport", "configuration");
if (!dp->data.conf)
- return typec_altmode_notify(dp->alt, TYPEC_STATE_USB,
- &dp->data);
+ return dp_altmode_notify(dp, TYPEC_STATE_USB);
- ret = dp_altmode_notify(dp);
+ ret = dp_altmode_notify_dp(dp);
if (ret)
return ret;
@@ -162,7 +173,7 @@ static int dp_altmode_configure_vdm(struct dp_altmode *dp,
u32 conf)
u32 header = DP_HEADER(DP_CMD_CONFIGURE);
int ret;
- ret = typec_altmode_notify(dp->alt, TYPEC_STATE_SAFE, &dp->data);
+ ret = dp_altmode_notify(dp, TYPEC_STATE_SAFE);
if (ret) {
dev_err(&dp->alt->dev,
"unable to put to connector to safe mode\n");
@@ -172,10 +183,9 @@ static int dp_altmode_configure_vdm(struct dp_altmode *dp,
u32 conf)
ret = typec_altmode_vdm(dp->alt, header, &conf, 2);
if (ret) {
if (DP_CONF_GET_PIN_ASSIGN(dp->data.conf))
- dp_altmode_notify(dp);
+ dp_altmode_notify_dp(dp);
else
- typec_altmode_notify(dp->alt, TYPEC_STATE_USB,
-&dp->data);
+ dp_altmode_notify(dp, TYPEC_STATE_USB);
}
return ret;
@@ -241,7 +251,7 @@ static void dp_altmode_attention(struct typec_altmode *alt,
const u32 vdo)
if (dp_altmode_status_update(dp))
dev_warn(&alt->dev, "%s: status update failed\n", __func__);
- if (dp_altmode_notify(dp))
+ if (dp_altmode_notify_dp(dp))
dev_err(&alt->dev, "%s: notification failed\n", __func__);
if (old_state == DP_STATE_IDLE && dp->state != DP_STATE_IDLE)
@@ -556,6 +566,8 @@ static void dp_altmode_remove(struct typec_altmode *alt)
sysfs_remove_group(&alt->dev.kobj, &dp_altmode_group);
cancel_work_sync(&dp->work);
+
+ drm_kms_call_oob_hotplug_notifier_chain(DRM_OOB_HOTPLUG_TYPE_C_DP);
}
static const struct typec_device_id dp_typec_id[] = {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] i915: Add support for out-of-bound hotplug events
On some Cherry Trail devices, DisplayPort over Type-C is supported through
a USB-PD microcontroller (e.g. a fusb302) + a mux to switch the superspeed
datalines between USB-3 and DP (e.g. a pi3usb30532). The kernel in this
case does the PD/alt-mode negotiation itself, rather then everything being
handled in firmware.
So the kernel itself picks an alt-mode, tells the Type-C "dongle" to switch
to DP mode and sets the mux accordingly. In this setup the HPD pin is not
connected, so the i915 driver needs to respond to a software event and scan
the DP port for changes manually.
This commit adds support for this. Together with the recent addition of
DP alt-mode support to the Type-C subsystem this makes DP over Type-C
work on these devices.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_irq.c | 2 ++
drivers/gpu/drm/i915/intel_hotplug.c | 38
3 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b1c31967194b..5d8c585ddbf7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -153,6 +153,7 @@ enum hpd_pin {
struct i915_hotplug {
struct work_struct hotplug_work;
+ struct notifier_block oob_notifier;
struct {
unsigned long last_jiffies;
@@ -2632,6 +2633,7 @@ void intel_hpd_irq_handler(struct drm_i915_private
*dev_priv,
u32 pin_mask, u32 long_mask);
void intel_hpd_init(struct drm_i915_private *dev_priv);
void intel_hpd_init_work(struct drm_i915_private *dev_priv);
+void intel_hpd_fini_work(struct drm_i915_private *dev_priv);
void intel_hpd_cancel_work(struct drm_i915_private *dev_priv);
enum hpd_pin intel_hpd_pin_default(struct drm_i915_private *dev_priv,
enum port port);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8211045a981b..14f3323b721b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4965,6 +4965,8 @@ void intel_irq_fini(struct drm_i915_private *i915)
for (i = 0; i < MAX_L3_SLICES; ++i)
kfree(i915->l3_parity.remap_info[i]);
+
+ intel_hpd_fini_work(i915);
}
/**
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
b/drivers/gpu/drm/i915/intel_hotplug.c
index e24174d08fed..221878fa26af 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -518,6 +518,36 @@ void intel_hpd_irq_handler(struct drm_i915_private
*dev_priv,
schedule_work(&dev_priv->hotplug.hotplug_work);
}
+static int intel_hpd_oob_notifier(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct drm_i915_private *dev_priv =
+ container_of(nb, struct drm_i915_private, hotplug.oob_notifier);
+ struct intel_encoder *encoder;
+ u32 bits = 0;
+
+ /* We only support DP over Type-C notifications */
+ if (event != DRM_OOB_HOTPLUG_TYPE_C_DP)
+ return NOTIFY_DONE;
+
+ /* Schedule a hotplug check for each DP encoder, except for EDP ones */
+ for_each_intel_dp(&dev_priv->drm, encoder) {
+ if (encoder->type == INTEL_OUTPUT_EDP)
+ continue;
+
+ bits |= BIT(encoder->hpd_pin);
+ }
+
+ if (bits) {
+ spin_lock_irq(&dev_priv->irq_lock);
+ dev_priv->hotplug.event_bits |= bits;
+ spin_unlock_irq(&dev_priv->irq_lock);
+ schedule_work(&dev_priv->hotplug.hotplug_work);
+ }
+
+ return NOTIFY_DONE;
+}
+
/**
* intel_hpd_init - initializes and enables hpd support
* @dev_priv: i915 device instance
@@ -640,6 +670,14 @@ void intel_hpd_init_work(struct drm_i915_private *dev_priv)
INIT_WORK(&dev_priv->hotplug.poll_init_work, i915_hpd_poll_init_work);
INIT_DELAYED_WORK(&dev_priv->hotplug.reenable_work,
intel_hpd_irq_storm_reenable_work);
+ dev_priv->hotplug.oob_notifier.notifier_call = intel_hpd_oob_notifier;
+ drm_kms_register_oob_hotplug_notifier(&dev_priv->hotplug.oob_notifier);
+}
+
+void intel_hpd_fini_work(struct drm_i915_private *dev_priv)
+{
+ drm_kms_unregister_oob_hotplug_notifier(
+ &dev_priv->hotplug.oob_notifier);
}
void intel_hpd_cancel_work(struct drm_i915_private *dev_priv)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109607] [CI][DRMTIP] Time is passing at a different rate between IGT machines and the controller
https://bugs.freedesktop.org/show_bug.cgi?id=109607
--- Comment #7 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- fi-icl-u2, fi-icl-u3: random tests - incomplete -}
{+ fi-icl-u2, fi-icl-u3: random tests - incomplete +}
No new failures caught with the new filter
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109607] [CI][DRMTIP] Time is passing at a different rate between IGT machines and the controller
https://bugs.freedesktop.org/show_bug.cgi?id=109607
--- Comment #8 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- fi-icl-u2, fi-icl-u3: random tests - incomplete -}
{+ fi-kbl-7560u fi-icl-u2, fi-icl-u3: random tests - incomplete +}
New failures caught by the filter:
*
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_228/fi-kbl-7560u/igt@kms_pl...@pixel-format-pipe-c-planes-source-clamping.html
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 1/3] drm/i2c: tda998x: implement different I2S flavours
On 22/02/2019 23:27, Russell King wrote:
> Add support for the left and right justified I2S formats as well as the
> more tranditional "Philips" I2S format.
>
> Signed-off-by: Russell King
I do not have a spec to check REG_I2S_FORMAT bits, but at least philips
and left justified formats work on BBB (McASP does not support right
justified format). With the above conditions:
Reviewed-by: Jyri Sarha
Tested-by: Jyri Sarha
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c | 57
> ++-
> include/drm/i2c/tda998x.h | 11 +---
> 2 files changed, 47 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index a7c39f39793f..645d884fb9e8 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -242,7 +242,9 @@ struct tda998x_priv {
> # define HVF_CNTRL_1_SEMI_PLANAR (1 << 6)
> #define REG_RPT_CNTRL REG(0x00, 0xf0) /* write */
> #define REG_I2S_FORMATREG(0x00, 0xfc) /* read/write */
> -# define I2S_FORMAT(x)(((x) & 3) << 0)
> +# define I2S_FORMAT_PHILIPS (0 << 0)
> +# define I2S_FORMAT_LEFT_J(2 << 0)
> +# define I2S_FORMAT_RIGHT_J (3 << 0)
> #define REG_AIP_CLKSELREG(0x00, 0xfd) /* write */
> # define AIP_CLKSEL_AIP_SPDIF (0 << 3)
> # define AIP_CLKSEL_AIP_I2S(1 << 3)
> @@ -872,14 +874,14 @@ static int
> tda998x_configure_audio(struct tda998x_priv *priv,
> struct tda998x_audio_params *params)
> {
> - u8 buf[6], clksel_aip, clksel_fs, cts_n, adiv;
> + u8 buf[6], clksel_aip, clksel_fs, cts_n, adiv, i2s_fmt;
> u32 n;
>
> /* Enable audio ports */
> reg_write(priv, REG_ENA_AP, params->config);
>
> /* Set audio input source */
> - switch (params->format) {
> + switch (params->format & AFMT_MASK) {
> case AFMT_SPDIF:
> reg_write(priv, REG_ENA_ACLK, 0);
> reg_write(priv, REG_MUX_AP, MUX_AP_SELECT_SPDIF);
> @@ -907,6 +909,19 @@ tda998x_configure_audio(struct tda998x_priv *priv,
> cts_n = CTS_N_M(3) | CTS_N_K(3);
> break;
> }
> +
> + switch (params->format & AFMT_I2S_MASK) {
> + case AFMT_I2S_LEFT_J:
> + i2s_fmt = I2S_FORMAT_LEFT_J;
> + break;
> + case AFMT_I2S_RIGHT_J:
> + i2s_fmt = I2S_FORMAT_RIGHT_J;
> + break;
> + default:
> + i2s_fmt = I2S_FORMAT_PHILIPS;
> + break;
> + }
> + reg_write(priv, REG_I2S_FORMAT, i2s_fmt);
> break;
>
> default:
> @@ -992,23 +1007,15 @@ static int tda998x_audio_hw_params(struct device *dev,
> void *data,
>
> switch (daifmt->fmt) {
> case HDMI_I2S:
> - if (daifmt->bit_clk_inv || daifmt->frame_clk_inv ||
> - daifmt->bit_clk_master || daifmt->frame_clk_master) {
> - dev_err(dev, "%s: Bad flags %d %d %d %d\n", __func__,
> - daifmt->bit_clk_inv, daifmt->frame_clk_inv,
> - daifmt->bit_clk_master,
> - daifmt->frame_clk_master);
> - return -EINVAL;
> - }
> - for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++)
> - if (priv->audio_port[i].format == AFMT_I2S)
> - audio.config = priv->audio_port[i].config;
> - audio.format = AFMT_I2S;
> + audio.format = AFMT_I2S | AFMT_I2S_PHILIPS;
> + break;
> + case HDMI_LEFT_J:
> + audio.format = AFMT_I2S | AFMT_I2S_LEFT_J;
> + break;
> + case HDMI_RIGHT_J:
> + audio.format = AFMT_I2S | AFMT_I2S_RIGHT_J;
> break;
> case HDMI_SPDIF:
> - for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++)
> - if (priv->audio_port[i].format == AFMT_SPDIF)
> - audio.config = priv->audio_port[i].config;
> audio.format = AFMT_SPDIF;
> break;
> default:
> @@ -1016,11 +1023,25 @@ static int tda998x_audio_hw_params(struct device
> *dev, void *data,
> return -EINVAL;
> }
>
> + for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++)
> + if (priv->audio_port[i].format == (audio.format & AFMT_MASK))
> + audio.config = priv->audio_port[i].config;
> +
> if (audio.config == 0) {
> dev_err(dev, "%s: No audio configuration found\n", __func__);
> return -EINVAL;
> }
>
> + if ((audio.format & AFMT_MASK) == HDMI_I2S &&
> + (daifmt->bit_clk_inv || daifmt->frame_clk_inv ||
> + daifmt->bit_clk_master || daifmt->frame_clk_master)) {
> + dev_err(
Re: [PATCH RFC 1/3] drm/i2c: tda998x: implement different I2S flavours
hi Russell,
On 22/02/2019 23.27, Russell King wrote:
> Add support for the left and right justified I2S formats as well as the
> more tranditional "Philips" I2S format.
First of all, thank you for the patch, it works.
Tested-by: Peter Ujfalusi
There is however one thing I'm not sure about.
the 3.8 kernel configured the page0:0xfc register [1]:
/* select I2S format, and datasize */
reg_write(encoder, REG_I2S_FORMAT, 0x0a);
In theory this should select left_j and set bit3 which does something.
It looks like that the McASP is configured to I2S mode in 3.8 kernel
which would result channel swap at least there (I2S vs left_j).
Do you know what the bit3 is configuring and to what?
[1]
https://github.com/beagleboard/linux/blob/1f2f3402a6e4b8c90148c0ca2fd3acba91738eb3/drivers/gpu/drm/i2c/tda998x_drv.c#L851
>
> Signed-off-by: Russell King
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c | 57
> ++-
> include/drm/i2c/tda998x.h | 11 +---
> 2 files changed, 47 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index a7c39f39793f..645d884fb9e8 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -242,7 +242,9 @@ struct tda998x_priv {
> # define HVF_CNTRL_1_SEMI_PLANAR (1 << 6)
> #define REG_RPT_CNTRL REG(0x00, 0xf0) /* write */
> #define REG_I2S_FORMATREG(0x00, 0xfc) /* read/write */
> -# define I2S_FORMAT(x)(((x) & 3) << 0)
> +# define I2S_FORMAT_PHILIPS (0 << 0)
> +# define I2S_FORMAT_LEFT_J(2 << 0)
> +# define I2S_FORMAT_RIGHT_J (3 << 0)
> #define REG_AIP_CLKSELREG(0x00, 0xfd) /* write */
> # define AIP_CLKSEL_AIP_SPDIF (0 << 3)
> # define AIP_CLKSEL_AIP_I2S(1 << 3)
> @@ -872,14 +874,14 @@ static int
> tda998x_configure_audio(struct tda998x_priv *priv,
> struct tda998x_audio_params *params)
> {
> - u8 buf[6], clksel_aip, clksel_fs, cts_n, adiv;
> + u8 buf[6], clksel_aip, clksel_fs, cts_n, adiv, i2s_fmt;
> u32 n;
>
> /* Enable audio ports */
> reg_write(priv, REG_ENA_AP, params->config);
>
> /* Set audio input source */
> - switch (params->format) {
> + switch (params->format & AFMT_MASK) {
> case AFMT_SPDIF:
> reg_write(priv, REG_ENA_ACLK, 0);
> reg_write(priv, REG_MUX_AP, MUX_AP_SELECT_SPDIF);
> @@ -907,6 +909,19 @@ tda998x_configure_audio(struct tda998x_priv *priv,
> cts_n = CTS_N_M(3) | CTS_N_K(3);
> break;
> }
> +
> + switch (params->format & AFMT_I2S_MASK) {
> + case AFMT_I2S_LEFT_J:
> + i2s_fmt = I2S_FORMAT_LEFT_J;
> + break;
> + case AFMT_I2S_RIGHT_J:
> + i2s_fmt = I2S_FORMAT_RIGHT_J;
> + break;
> + default:
> + i2s_fmt = I2S_FORMAT_PHILIPS;
> + break;
> + }
> + reg_write(priv, REG_I2S_FORMAT, i2s_fmt);
> break;
>
> default:
> @@ -992,23 +1007,15 @@ static int tda998x_audio_hw_params(struct device *dev,
> void *data,
>
> switch (daifmt->fmt) {
> case HDMI_I2S:
> - if (daifmt->bit_clk_inv || daifmt->frame_clk_inv ||
> - daifmt->bit_clk_master || daifmt->frame_clk_master) {
> - dev_err(dev, "%s: Bad flags %d %d %d %d\n", __func__,
> - daifmt->bit_clk_inv, daifmt->frame_clk_inv,
> - daifmt->bit_clk_master,
> - daifmt->frame_clk_master);
> - return -EINVAL;
> - }
> - for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++)
> - if (priv->audio_port[i].format == AFMT_I2S)
> - audio.config = priv->audio_port[i].config;
> - audio.format = AFMT_I2S;
> + audio.format = AFMT_I2S | AFMT_I2S_PHILIPS;
> + break;
> + case HDMI_LEFT_J:
> + audio.format = AFMT_I2S | AFMT_I2S_LEFT_J;
> + break;
> + case HDMI_RIGHT_J:
> + audio.format = AFMT_I2S | AFMT_I2S_RIGHT_J;
> break;
> case HDMI_SPDIF:
> - for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++)
> - if (priv->audio_port[i].format == AFMT_SPDIF)
> - audio.config = priv->audio_port[i].config;
> audio.format = AFMT_SPDIF;
> break;
> default:
> @@ -1016,11 +1023,25 @@ static int tda998x_audio_hw_params(struct device
> *dev, void *data,
> return -EINVAL;
> }
>
> + for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++)
> + if (priv->audio_port[i].format == (audio.format & AFMT_MASK))
> +
Re: [PATCH RFC 1/3] drm/i2c: tda998x: implement different I2S flavours
On Mon, Feb 25, 2019 at 03:28:51PM +0200, Peter Ujfalusi wrote: > hi Russell, > > On 22/02/2019 23.27, Russell King wrote: > > Add support for the left and right justified I2S formats as well as the > > more tranditional "Philips" I2S format. > > First of all, thank you for the patch, it works. > > Tested-by: Peter Ujfalusi > > There is however one thing I'm not sure about. > the 3.8 kernel configured the page0:0xfc register [1]: > /* select I2S format, and datasize */ > reg_write(encoder, REG_I2S_FORMAT, 0x0a); > > In theory this should select left_j and set bit3 which does something. > It looks like that the McASP is configured to I2S mode in 3.8 kernel > which would result channel swap at least there (I2S vs left_j). > > Do you know what the bit3 is configuring and to what? Bits 2 and 3 are something to do with "data size" which is as much information as I have on those two bits. Maybe they apply to the right justified mode as that would certainly need to know the width of the supplied I2S sample data. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 3/3] drm/i2c: tda998x: add support for bclk_ratio
On 22/02/2019 23:27, Russell King wrote:
> It appears that TDA998x derives the CTS value using the supplied I2S
> bit clock (BCLK) rather than 128·fs. TDA998x uses two constants named
> m and k in the CTS generator such that we have this relationship
> between the source BCLK and the sink fs:
>
> 128·fs_sink = BCLK·m / k
>
> Where BCLK = bclk_ratio·fs_source.
>
> We have been lucky up to now that all users have scaled their bclk_ratio
> to match the sample width - for example, on Beagle Bone Black, with a
> 16-bit sample width, BCLK = 32·fs, which increases to 64·fs for 32-bit
> samples. 24-bit samples are sent as 32-bit.
>
> We are now starting to see users whose I2S blocks send at 64·fs for
> 16-bit samples, which means TDA998x now breaks.
>
> ASoC has a snd_soc_dai_set_bclk_ratio() call available which sets the
> ratio of BCLK to the sample rate. Implement support for this.
>
> Signed-off-by: Russell King
Works at least on Beaglebone-black.
Tested-by: Jyri Sarha
Reviewed-by: Jyri Sarha
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c | 20 +---
> include/drm/i2c/tda998x.h | 1 +
> 2 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 645d884fb9e8..f2d40235acf9 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -895,21 +895,26 @@ tda998x_configure_audio(struct tda998x_priv *priv,
> reg_write(priv, REG_MUX_AP, MUX_AP_SELECT_I2S);
> clksel_aip = AIP_CLKSEL_AIP_I2S;
> clksel_fs = AIP_CLKSEL_FS_ACLK;
> - switch (params->sample_width) {
> + switch (params->bclk_ratio) {
> case 16:
> + cts_n = CTS_N_M(3) | CTS_N_K(0);
> + break;
> + case 32:
> cts_n = CTS_N_M(3) | CTS_N_K(1);
> break;
> - case 18:
> - case 20:
> - case 24:
> + case 48:
> cts_n = CTS_N_M(3) | CTS_N_K(2);
> break;
> - default:
> - case 32:
> + case 64:
> cts_n = CTS_N_M(3) | CTS_N_K(3);
> break;
> + case 128:
> + cts_n = CTS_N_M(0) | CTS_N_K(0);
> + break;
> + default:
> + dev_err(&priv->hdmi->dev, "unsupported I2S bclk
> ratio\n");
> + return -EINVAL;
> }
> -
> switch (params->format & AFMT_I2S_MASK) {
> case AFMT_I2S_LEFT_J:
> i2s_fmt = I2S_FORMAT_LEFT_J;
> @@ -997,6 +1002,7 @@ static int tda998x_audio_hw_params(struct device *dev,
> void *data,
> struct tda998x_priv *priv = dev_get_drvdata(dev);
> int i, ret;
> struct tda998x_audio_params audio = {
> + .bclk_ratio = daifmt->bclk_ratio,
> .sample_width = params->sample_width,
> .sample_rate = params->sample_rate,
> .cea = params->cea,
> diff --git a/include/drm/i2c/tda998x.h b/include/drm/i2c/tda998x.h
> index b0864f0be017..4e0f0cd2d428 100644
> --- a/include/drm/i2c/tda998x.h
> +++ b/include/drm/i2c/tda998x.h
> @@ -19,6 +19,7 @@ enum {
> struct tda998x_audio_params {
> u8 config;
> u8 format;
> + u8 bclk_ratio;
> unsigned sample_width;
> unsigned sample_rate;
> struct hdmi_audio_infoframe cea;
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND] drm/i2c: tda998x: Reset the I2S_FORMAT (Page0, Reg 0xfc) to it's default
Hi Russell, On 22/02/2019 17.27, Russell King - ARM Linux admin wrote: >> On BBB McASP is the clock master and as I recall I have tested 44.1, 48 >> KHz at least with 16 and 24 bits. > > Sorry, I wasn't clear enough... is the bus clocked at 32Fs for 16bit > samples and 64Fs for 24bit samples, or is it 64Fs for both? Now that I have dug out the board: Playback of the following formats works w/o plughw conversion: 32KHz/48KHz/96KHz, stereo, 16bit (32fs on bus) 32KHz/48KHz/96KHz, stereo, 24bit (S24_LE or S24_3LE - 48fs on bus) McASP is only putting the needed amount of bclk on the bus for the given format - uses params_width() for divider calculation. Signed-off-by: Peter Ujfalusi --- drivers/gpu/drm/i2c/tda998x_drv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c index 7f34601bb515..72f93802d209 100644 --- a/drivers/gpu/drm/i2c/tda998x_drv.c +++ b/drivers/gpu/drm/i2c/tda998x_drv.c @@ -722,6 +722,9 @@ tda998x_reset(struct tda998x_priv *priv) /* Write the default value MUX register */ reg_write(priv, REG_MUX_VP_VIP_OUT, 0x24); + + /* Write the default to I2S_FORMAT register */ + reg_write(priv, REG_I2S_FORMAT, 0x00); } /* -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki >>> >> >> - Péter >> >> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. >> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki >> > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107310] intel-gpu-overlay crashes on startup, being aborted
https://bugs.freedesktop.org/show_bug.cgi?id=107310 --- Comment #3 from leozinho29...@hotmail.com --- Using latest kernels (5.0-rc) and latest intel-gpu-overlay it works correctly. It is only failing when older kernels, as 4.18.0-15, are used. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/bridge: sii902x: Implement HDMI audio support
On 25.02.2019 12:23, Jyri Sarha wrote:
> Implement HDMI audio support by using ASoC HDMI codec. The commit
> implements the necessary callbacks and configuration for the HDMI
> codec and registers a virtual platform device for the codec to attach.
>
> Signed-off-by: Jyri Sarha
> ---
> .../bindings/display/bridge/sii902x.txt | 24 +
> drivers/gpu/drm/bridge/sii902x.c | 456 +-
> include/dt-bindings/sound/sii902x-audio.h | 11 +
> 3 files changed, 485 insertions(+), 6 deletions(-)
> create mode 100644 include/dt-bindings/sound/sii902x-audio.h
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> index 72d2dc6c3e6b..a1cff91e4e84 100644
> --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> @@ -8,6 +8,21 @@ Optional properties:
> - interrupts: describe the interrupt line used to inform the host
> about hotplug events.
> - reset-gpios: OF device-tree gpio specification for RST_N pin.
> + - i2s-fifo-routing: Array of exactly 4 integers indicating i2s
> + pins for audio fifo routing. First integer defines routing to
> + fifo 0 and second to fifo 1, etc. Integers can be filled with
> + definitions from: include/dt-bindings/sound/sii902x-audio.h
> + The available definitions are:
> + - ENABLE_BIT: enable this audio fifo
> + - CONNECT_SD#: route audio input from SD0, SD1, SD2, or SD3 i2s
> + data input pin
> + - LEFT_RIGHT_SWAP_BIT: swap i2s input channels for this fifo
> + I2S HDMI audio is configured only if this property is found.
> + - clocks: describes SII902x MCLK input. MCLK is used to produce
> + HDMI audio CTS values. This property is required if
> + "i2s-fifo-routing"-property is present. This property follows
> + Documentation/devicetree/bindings/clock/clock-bindings.txt
> + consumer binding.
I wonder if it wouldn't be better to use of_graph to show connections
between audio producer (A/V media processor) and the transmitter,
i2s-fifo-routing value should be then derived from these bindings.
>
> Optional subnodes:
> - video input: this subnode can contain a video input port node
> @@ -21,6 +36,15 @@ Example:
> compatible = "sil,sii9022";
> reg = <0x39>;
> reset-gpios = <&pioA 1 0>;
> +
> + i2s-fifo-routing = <
> + (ENABLE_BIT|CONNECT_SD0)
> + 0
> + 0
> + 0
> + >;
> + clocks = <&mclk>;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> diff --git a/drivers/gpu/drm/bridge/sii902x.c
> b/drivers/gpu/drm/bridge/sii902x.c
> index 0e21fa419d27..f296a33c57c7 100644
> --- a/drivers/gpu/drm/bridge/sii902x.c
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -27,12 +27,16 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> #include
> #include
>
> +#include
> +#include
> +
> #define SII902X_TPI_VIDEO_DATA 0x0
>
> #define SII902X_TPI_PIXEL_REPETITION 0x8
> @@ -74,6 +78,77 @@
> #define SII902X_AVI_POWER_STATE_MSK GENMASK(1, 0)
> #define SII902X_AVI_POWER_STATE_D(l) ((l) &
> SII902X_AVI_POWER_STATE_MSK)
>
> +/* Audio */
> +#define SII902X_TPI_I2S_ENABLE_MAPPING_REG 0x1f
> +#define SII902X_TPI_I2S_CONFIG_FIFO0 (0 << 0)
> +#define SII902X_TPI_I2S_CONFIG_FIFO1 (1 << 0)
> +#define SII902X_TPI_I2S_CONFIG_FIFO2 (2 << 0)
> +#define SII902X_TPI_I2S_CONFIG_FIFO3 (3 << 0)
> +#define SII902X_TPI_I2S_LEFT_RIGHT_SWAP (1 << 2)
> +#define SII902X_TPI_I2S_AUTO_DOWNSAMPLE (1 << 3)
> +#define SII902X_TPI_I2S_SELECT_SD0 (0 << 4)
> +#define SII902X_TPI_I2S_SELECT_SD1 (1 << 4)
> +#define SII902X_TPI_I2S_SELECT_SD2 (2 << 4)
> +#define SII902X_TPI_I2S_SELECT_SD3 (3 << 4)
> +#define SII902X_TPI_I2S_FIFO_ENABLE (1 << 7)
> +
> +#define SII902X_TPI_I2S_INPUT_CONFIG_REG 0x20
> +#define SII902X_TPI_I2S_FIRST_BIT_SHIFT_YES (0 << 0)
> +#define SII902X_TPI_I2S_FIRST_BIT_SHIFT_NO (1 << 0)
> +#define SII902X_TPI_I2S_SD_DIRECTION_MSB_FIRST (0 << 1)
> +#define SII902X_TPI_I2S_SD_DIRECTION_LSB_FIRST (1 << 1)
> +#define SII902X_TPI_I2S_SD_JUSTIFY_LEFT (0 << 2)
> +#define SII902X_TPI_I2S_SD_JUSTIFY_RIGHT (1 << 2)
> +#define SII902X_TPI_I2S_WS_POLARITY_LOW (0 << 3)
> +#define SII902X_TPI_I2S_WS_POLARITY_HIGH (1 << 3)
> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_128 (0 << 4)
> +#d
Re: [PATCH 3/3] usb: typec: altmodes/displayport: Notify drm subsys of hotplug events
On Mon, Feb 25, 2019 at 02:20:37PM +0100, Hans de Goede wrote:
> Use the new drm_kms_call_oob_hotplug_notifier_chain() function to load
> drm/kms drivers know about DisplayPort over Type-C hotplug events.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/usb/typec/altmodes/displayport.c | 34
> 1 file changed, 23 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/usb/typec/altmodes/displayport.c
> b/drivers/usb/typec/altmodes/displayport.c
> index 35161594e368..87760ea252d6 100644
> --- a/drivers/usb/typec/altmodes/displayport.c
> +++ b/drivers/usb/typec/altmodes/displayport.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
>
> #define DP_HEADER(cmd) (VDO(USB_TYPEC_DP_SID, 1, cmd)
> | \
>VDO_OPOS(USB_TYPEC_DP_MODE))
> @@ -67,12 +68,23 @@ struct dp_altmode {
> const struct typec_altmode *port;
> };
>
> -static int dp_altmode_notify(struct dp_altmode *dp)
> +static int dp_altmode_notify(struct dp_altmode *dp, unsigned long conf)
> +{
> + int ret;
> +
> + ret = typec_altmode_notify(dp->alt, conf, &dp->data);
> + if (ret)
> + return ret;
> +
> + drm_kms_call_oob_hotplug_notifier_chain(DRM_OOB_HOTPLUG_TYPE_C_DP);
Is this causing a build/run-time dependancy of the USB code on DRM now?
What about typec systems without DRM, is that a thing?
I have no objection to this if the DRM people like this type of api
(personally I hate notifier chains), just curious about the dependancy
issues involved.
thanks,
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/2] Lima DRM driver
Kernel DRM driver for ARM Mali 400/450 GPUs. This patch serial is based on 5.0-rc7 with Rob Herring's recent drm_gem_object change: https://patchwork.kernel.org/cover/10794421/ All lima commits are squashed. For whole history of this driver's development, see: https://gitlab.freedesktop.org/lima/linux/commits/lima-5.0-rc7 https://gitlab.freedesktop.org/lima/linux/commits/lima-5.0-rc6 https://gitlab.freedesktop.org/lima/linux/commits/lima-5.0-rc5 https://gitlab.freedesktop.org/lima/linux/commits/lima-4.17-rc4 Mesa driver is still in development and not ready for daily usage, but can run some simple tests like kmscube and glamrk2, and some single full screen application like kodi-gbm, see: https://gitlab.freedesktop.org/lima/mesa [v1] https://lists.freedesktop.org/archives/dri-devel/2019-February/206260.html [rfc] https://lists.freedesktop.org/archives/dri-devel/2018-May/177314.html Cc: Andreas Baierl Cc: Erico Nunes Cc: Heiko Stuebner Cc: Marek Vasut Cc: Neil Armstrong Cc: Simon Shields Cc: Vasily Khoruzhick Cc: Rob Herring Qiang Yu (2): drm: export drm_timeout_abs_to_jiffies drm/lima: driver for ARM Mali4xx GPUs drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_syncobj.c | 3 +- drivers/gpu/drm/lima/Kconfig | 9 + drivers/gpu/drm/lima/Makefile | 21 ++ drivers/gpu/drm/lima/lima_bcast.c | 46 +++ drivers/gpu/drm/lima/lima_bcast.h | 14 + drivers/gpu/drm/lima/lima_ctx.c | 105 +++ drivers/gpu/drm/lima/lima_ctx.h | 30 ++ drivers/gpu/drm/lima/lima_device.c| 376 +++ drivers/gpu/drm/lima/lima_device.h| 129 drivers/gpu/drm/lima/lima_dlbu.c | 56 drivers/gpu/drm/lima/lima_dlbu.h | 18 ++ drivers/gpu/drm/lima/lima_drv.c | 353 + drivers/gpu/drm/lima/lima_drv.h | 46 +++ drivers/gpu/drm/lima/lima_gem.c | 379 +++ drivers/gpu/drm/lima/lima_gem.h | 25 ++ drivers/gpu/drm/lima/lima_gem_prime.c | 47 +++ drivers/gpu/drm/lima/lima_gem_prime.h | 13 + drivers/gpu/drm/lima/lima_gp.c| 282 + drivers/gpu/drm/lima/lima_gp.h| 16 + drivers/gpu/drm/lima/lima_l2_cache.c | 80 + drivers/gpu/drm/lima/lima_l2_cache.h | 14 + drivers/gpu/drm/lima/lima_mmu.c | 142 + drivers/gpu/drm/lima/lima_mmu.h | 16 + drivers/gpu/drm/lima/lima_object.c| 128 drivers/gpu/drm/lima/lima_object.h| 36 +++ drivers/gpu/drm/lima/lima_pmu.c | 59 drivers/gpu/drm/lima/lima_pmu.h | 12 + drivers/gpu/drm/lima/lima_pp.c| 423 ++ drivers/gpu/drm/lima/lima_pp.h| 19 ++ drivers/gpu/drm/lima/lima_regs.h | 298 ++ drivers/gpu/drm/lima/lima_sched.c | 403 drivers/gpu/drm/lima/lima_sched.h | 104 +++ drivers/gpu/drm/lima/lima_vm.c| 280 + drivers/gpu/drm/lima/lima_vm.h| 62 include/drm/drm_utils.h | 4 + include/uapi/drm/lima_drm.h | 126 38 files changed, 4176 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/lima/Kconfig create mode 100644 drivers/gpu/drm/lima/Makefile create mode 100644 drivers/gpu/drm/lima/lima_bcast.c create mode 100644 drivers/gpu/drm/lima/lima_bcast.h create mode 100644 drivers/gpu/drm/lima/lima_ctx.c create mode 100644 drivers/gpu/drm/lima/lima_ctx.h create mode 100644 drivers/gpu/drm/lima/lima_device.c create mode 100644 drivers/gpu/drm/lima/lima_device.h create mode 100644 drivers/gpu/drm/lima/lima_dlbu.c create mode 100644 drivers/gpu/drm/lima/lima_dlbu.h create mode 100644 drivers/gpu/drm/lima/lima_drv.c create mode 100644 drivers/gpu/drm/lima/lima_drv.h create mode 100644 drivers/gpu/drm/lima/lima_gem.c create mode 100644 drivers/gpu/drm/lima/lima_gem.h create mode 100644 drivers/gpu/drm/lima/lima_gem_prime.c create mode 100644 drivers/gpu/drm/lima/lima_gem_prime.h create mode 100644 drivers/gpu/drm/lima/lima_gp.c create mode 100644 drivers/gpu/drm/lima/lima_gp.h create mode 100644 drivers/gpu/drm/lima/lima_l2_cache.c create mode 100644 drivers/gpu/drm/lima/lima_l2_cache.h create mode 100644 drivers/gpu/drm/lima/lima_mmu.c create mode 100644 drivers/gpu/drm/lima/lima_mmu.h create mode 100644 drivers/gpu/drm/lima/lima_object.c create mode 100644 drivers/gpu/drm/lima/lima_object.h create mode 100644 drivers/gpu/drm/lima/lima_pmu.c create mode 100644 drivers/gpu/drm/lima/lima_pmu.h create mode 100644 drivers/gpu/drm/lima/lima_pp.c create mode 100644 drivers/gpu/drm/lima/lima_pp.h create mode 100644 drivers/gpu/drm/lima/lima_regs.h create mode 100644 drivers/gpu/drm/lima/lima_sched.c create mode 100644 drivers/gpu/drm/lima/lima_sched.h create mode 100644 drivers/gpu/drm/lima/lima_vm.c create mode 100644 drivers/gpu/drm/lima/lima_vm.h create mode 100644 include/uap
[PATCH v2 1/2] drm: export drm_timeout_abs_to_jiffies
For other driver like lima usage.
Cc: Rob Herring
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/drm_syncobj.c | 3 ++-
include/drm/drm_utils.h | 4
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index db30a0e89db8..23fb1a5e4fda 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -762,7 +762,7 @@ static signed long drm_syncobj_array_wait_timeout(struct
drm_syncobj **syncobjs,
*
* Calculate the timeout in jiffies from an absolute time in sec/nsec.
*/
-static signed long drm_timeout_abs_to_jiffies(int64_t timeout_nsec)
+signed long drm_timeout_abs_to_jiffies(int64_t timeout_nsec)
{
ktime_t abs_timeout, now;
u64 timeout_ns, timeout_jiffies64;
@@ -786,6 +786,7 @@ static signed long drm_timeout_abs_to_jiffies(int64_t
timeout_nsec)
return timeout_jiffies64 + 1;
}
+EXPORT_SYMBOL(drm_timeout_abs_to_jiffies);
static int drm_syncobj_array_wait(struct drm_device *dev,
struct drm_file *file_private,
diff --git a/include/drm/drm_utils.h b/include/drm/drm_utils.h
index a803988d8579..70775748d243 100644
--- a/include/drm/drm_utils.h
+++ b/include/drm/drm_utils.h
@@ -10,6 +10,10 @@
#ifndef __DRM_UTILS_H__
#define __DRM_UTILS_H__
+#include
+
int drm_get_panel_orientation_quirk(int width, int height);
+signed long drm_timeout_abs_to_jiffies(int64_t timeout_nsec);
+
#endif
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/ttm: Account for kernel allocations in kernel zone only
Am 23.02.19 um 00:19 schrieb Kuehling, Felix:
> Don't account for them in other zones such as dma32. The kernel page
> allocator has its own heuristics to avoid exhausting special zones
> for regular kernel allocations.
>
> Signed-off-by: Felix Kuehling
> CC: thellst...@vmware.com
> CC: christian.koe...@amd.com
Reviewed-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_memory.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
> b/drivers/gpu/drm/ttm/ttm_memory.c
> index f1567c3..90d1e24 100644
> --- a/drivers/gpu/drm/ttm/ttm_memory.c
> +++ b/drivers/gpu/drm/ttm/ttm_memory.c
> @@ -522,7 +522,7 @@ static void ttm_mem_global_free_zone(struct
> ttm_mem_global *glob,
> void ttm_mem_global_free(struct ttm_mem_global *glob,
>uint64_t amount)
> {
> - return ttm_mem_global_free_zone(glob, NULL, amount);
> + return ttm_mem_global_free_zone(glob, glob->zone_kernel, amount);
> }
> EXPORT_SYMBOL(ttm_mem_global_free);
>
> @@ -621,10 +621,10 @@ int ttm_mem_global_alloc(struct ttm_mem_global *glob,
> uint64_t memory,
> {
> /**
>* Normal allocations of kernel memory are registered in
> - * all zones.
> + * the kernel zone.
>*/
>
> - return ttm_mem_global_alloc_zone(glob, NULL, memory, ctx);
> + return ttm_mem_global_alloc_zone(glob, glob->zone_kernel, memory, ctx);
> }
> EXPORT_SYMBOL(ttm_mem_global_alloc);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vkms: Solve bug on kms_crc_cursor tests
vkms_crc_work_handle needs the value of the actual frame to
schedule the workqueue that calls periodically the vblank
handler and the destroy state functions. However, the frame
value returned from vkms_vblank_simulate is updated and
diminished in vblank_get_timestamp because it is not in a
vblank interrupt, and return an inaccurate value.
Solve this getting the actual vblank frame directly from the
vblank->count inside the `struct drm_crtc`, instead of using
the `drm_accurate_vblank_count` function.
Signed-off-by: Shayenne Moura
---
drivers/gpu/drm/vkms/vkms_crc.c | 4 +++-
drivers/gpu/drm/vkms/vkms_crtc.c | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_crc.c b/drivers/gpu/drm/vkms/vkms_crc.c
index d7b409a3c0f8..09a8b00ef1f1 100644
--- a/drivers/gpu/drm/vkms/vkms_crc.c
+++ b/drivers/gpu/drm/vkms/vkms_crc.c
@@ -161,6 +161,8 @@ void vkms_crc_work_handle(struct work_struct *work)
struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
struct vkms_device *vdev = container_of(out, struct vkms_device,
output);
+ unsigned int pipe = drm_crtc_index(crtc);
+ struct drm_vblank_crtc *vblank = &crtc->dev->vblank[pipe];
struct vkms_crc_data *primary_crc = NULL;
struct vkms_crc_data *cursor_crc = NULL;
struct drm_plane *plane;
@@ -196,7 +198,7 @@ void vkms_crc_work_handle(struct work_struct *work)
if (primary_crc)
crc32 = _vkms_get_crc(primary_crc, cursor_crc);
- frame_end = drm_crtc_accurate_vblank_count(crtc);
+ frame_end = vblank->count;
/* queue_work can fail to schedule crc_work; add crc for
* missing frames
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index 8a9aeb0a9ea8..9bf3268e2e92 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -10,6 +10,8 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
hrtimer *timer)
vblank_hrtimer);
struct drm_crtc *crtc = &output->crtc;
struct vkms_crtc_state *state = to_vkms_crtc_state(crtc->state);
+ unsigned int pipe = drm_crtc_index(crtc);
+ struct drm_vblank_crtc *vblank = &crtc->dev->vblank[pipe];
u64 ret_overrun;
bool ret;
@@ -20,7 +22,7 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
hrtimer *timer)
DRM_ERROR("vkms failure on handling vblank");
if (state && output->crc_enabled) {
- u64 frame = drm_crtc_accurate_vblank_count(crtc);
+ u64 frame = vblank->count;
/* update frame_start only if a queued vkms_crc_work_handle()
* has read the data
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework
This framework allows a unified userspace interface for dma-buf exporters, allowing userland to allocate specific types of memory for use in dma-buf sharing. Each heap is given its own device node, which a user can allocate a dma-buf fd from using the DMA_HEAP_IOC_ALLOC. Signed-off-by: Andrew F. Davis --- Hello all, I had a little less time over the weekend than I thought I would to clean this up more and finish the first set of user heaps, but wanted to get this out anyway. ION in its current form assumes a lot about the memory it exports and these assumptions lead to restrictions on the full range of operations dma-buf's can produce. Due to this if we are to add this as an extension of the core dma-buf then it should only be the user-space advertisement and allocation front-end. All dma-buf exporting and operation need to be placed in the control of the exporting heap. The core becomes rather small, just a few hundred lines you see here. This is not to say we should not provide helpers to make the heap exporters more simple, but they should only be helpers and not enforced by the core framework. Basic use model here is an exporter (dedicated heap memory driver, CMA, System, etc.) registers with the framework by providing a struct dma_heap_info which gives us the needed info to export this heap to userspace as a device node. Next a user will request an allocation, the IOCTL is parsed and the request made to a heap provided alloc() op. The heap should return the filled out struct dma_heap_buffer, including exporting the buffer as a dma-buf. This dma-buf we then return to the user as a fd. Buffer free is still a bit open as we need to update some stats and free some memory, but the release operation is controlled by the heap exporter, so some hook will have to be created. It all needs a bit more work, and I'm sure I'll find missing parts when I add some more heaps, but hopefully this framework is simple enough that it does not impede the implementation of all functionality once provided by ION (shrinker, delayed free), nor any new functionality needed for future heap exporting devices. Thanks, Andrew drivers/dma-buf/Kconfig | 12 ++ drivers/dma-buf/Makefile | 1 + drivers/dma-buf/dma-heap.c| 268 ++ include/linux/dma-heap.h | 57 include/uapi/linux/dma-heap.h | 54 +++ 5 files changed, 392 insertions(+) create mode 100644 drivers/dma-buf/dma-heap.c create mode 100644 include/linux/dma-heap.h create mode 100644 include/uapi/linux/dma-heap.h diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig index 2e5a0faa2cb1..30b0d7c83945 100644 --- a/drivers/dma-buf/Kconfig +++ b/drivers/dma-buf/Kconfig @@ -39,4 +39,16 @@ config UDMABUF A driver to let userspace turn memfd regions into dma-bufs. Qemu can use this to create host dmabufs for guest framebuffers. +menuconfig DMABUF_HEAPS + bool "DMA-BUF Userland Memory Heaps" + depends on HAS_DMA && MMU + select GENERIC_ALLOCATOR + select DMA_SHARED_BUFFER + help + Choose this option to enable the DMA-BUF userland memory heaps, + this allows userspace to allocate dma-bufs that can be shared between + drivers. + +source "drivers/dma-buf/heaps/Kconfig" + endmenu diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile index 0913a6ccab5a..b0332f143413 100644 --- a/drivers/dma-buf/Makefile +++ b/drivers/dma-buf/Makefile @@ -1,4 +1,5 @@ obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o +obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o obj-$(CONFIG_SYNC_FILE)+= sync_file.o obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o obj-$(CONFIG_UDMABUF) += udmabuf.o diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c new file mode 100644 index ..72ed225fa892 --- /dev/null +++ b/drivers/dma-buf/dma-heap.c @@ -0,0 +1,268 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Framework for userspace DMA-BUF allocations + * + * Copyright (C) 2011 Google, Inc. + * Copyright (C) 2019 Linaro Ltd. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#define DEVNAME "dma_heap" + +#define NUM_HEAP_MINORS 128 +static DEFINE_IDR(dma_heap_idr); +static DEFINE_MUTEX(minor_lock); /* Protect idr accesses */ + +dev_t dma_heap_devt; +struct class *dma_heap_class; +struct list_head dma_heap_list; +struct dentry *dma_heap_debug_root; + +/** + * struct dma_heap - represents a dmabuf heap in the system + * @name: used for debugging/device-node name + * @ops: ops struct for this heap + * @minor minor number of this heap device + * @heap_devt heap device node + * @heap_cdev heap char device + * @num_of_buffers the number of currently allocated buffers + * @num_of_alloc_bytes the number of allocated bytes + * @alloc_byt
Re: [PATCH v2 4/4] drm/panel: Add OSD101T2587-53TS driver
Hi Sam,
On 23/02/2019 21.38, Sam Ravnborg wrote:
> Hi Peter.
>
> Driver looks to be in good shape now.
> With the few comments below addressed you can add my:
> Reviewed-by: Sam Ravnborg
>
> Sam
>
> On Fri, Feb 22, 2019 at 03:16:18PM +0200, Peter Ujfalusi wrote:
>> The panel is similar to OSD101T2045-53TS (which is handled by panel-simple)
>> with one big difference: osd101t2587-53ts needs MIPI_DSI_TURN_ON_PERIPHERAL
>> message to be sent from the host to be operational and thus can not be
>> handled by panel-simple.
>>
>> Signed-off-by: Peter Ujfalusi
>> ---
>> drivers/gpu/drm/panel/Kconfig | 6 +
>> drivers/gpu/drm/panel/Makefile| 1 +
>> .../drm/panel/panel-osd-osd101t2587-53ts.c| 254 ++
>> 3 files changed, 261 insertions(+)
>> create mode 100644 drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c
>>
>> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
>> index 3e070153ef21..351661920838 100644
>> --- a/drivers/gpu/drm/panel/Kconfig
>> +++ b/drivers/gpu/drm/panel/Kconfig
>> @@ -122,6 +122,12 @@ config DRM_PANEL_ORISETECH_OTM8009A
>>Say Y here if you want to enable support for Orise Technology
>>otm8009a 480x800 dsi 2dl panel.
>>
>> +config DRM_PANEL_OSD_OSD101T2587_53TS
>> +tristate "OSD OSD101T2587-53TS DSI 1920x1200 video mode panel"
>> +depends on OF
>> +depends on DRM_MIPI_DSI
>> +depends on BACKLIGHT_CLASS_DEVICE
> Please add a help-text
Sure, I forgot this.
>> +
>> +static int osd101t2587_panel_unprepare(struct drm_panel *panel)
>> +{
>> +struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel);
>> +
>> +if (!osd101t2587->prepared)
>> +return 0;
>> +
>> +regulator_disable(osd101t2587->supply);
>> +osd101t2587->prepared = false;
>> +
>> +return 0;
>> +}
>> +
>> +static int osd101t2587_panel_prepare(struct drm_panel *panel)
>> +{
>> +struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel);
>> +int ret;
>> +
>> +if (osd101t2587->prepared)
>> +return 0;
>> +
>> +ret = regulator_enable(osd101t2587->supply);
>> +if (!ret)
>> +osd101t2587->prepared = true;
>
> Logic is wrong here. regulator_enable() will return a negative value on error
> and 0 in the good case.
> So osd101t2587->prepared is set to true only in the error case, not in the
> good case.
It is good as it is:
'if (!0)' == 'if (1)'
'if (!-X)' == 'if (0)'
>> +
>> +ret = mipi_dsi_attach(dsi);
>> +if (ret)
>> +drm_panel_remove(&osd101t2587->base);
>
> I do not see panel-simple.c do a drm_panel_remove() if mipi_dsi_attach()
> fails.
> Maybe the driver core will call remove() is probe fails?
> Or maybe panel-simple() should call drm_panel_remove()
>
> Keep the above as is - I just wanted to express that this looks different
> from the panle-simple() driver.
I have a patch for panel-simple as well with the following commit message:
"drm/panel: simple: Fix panel_simple_dsi_probe
In case mipi_dsi_attach() fails remove the registered panel to avoid
added panel without corresponding device."
It has the same bug.
>> +static int osd101t2587_panel_remove(struct mipi_dsi_device *dsi)
>> +{
>> +struct osd101t2587_panel *osd101t2587 = mipi_dsi_get_drvdata(dsi);
>> +int ret;
>> +
>> +ret = osd101t2587_panel_disable(&osd101t2587->base);
>> +if (ret < 0)
>> +dev_warn(&dsi->dev, "failed to disable panel\n");
> This is already warned in lower layers and I think you could
> drop the dev_warn().
I think there is no warning from lower layer, but not sure as I never
hit this case.
>> +
>> +osd101t2587_panel_unprepare(&osd101t2587->base);
>> +
>> +drm_panel_remove(&osd101t2587->base);
>> +
>> +ret = mipi_dsi_detach(dsi);
>> +if (ret < 0)
>> +dev_warn(&dsi->dev, "failed to detach from DSI host\n");
> Add error code in logging.
OK
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: hdlcd: Stop failing atomic disable check
When __drm_atomic_helper_disable_all() tries to commit the disabled
state, we end up in hdlcd_crtc_atomic_check() with a mode clock rate
of 0. If the input clock has a nonzero minimum rate, this fails the
clk_round_rate() check and prevents the CRTC being torn down cleanly.
If we're disabling the output, though, then the clock rate should be
pretty much irrelevant, so skip it in that case. The kerneldoc seems
to imply that we probably shouldn't be looking at the rest of the
state anyway if enable=false.
Signed-off-by: Robin Murphy
---
I'm still occasionally trying to get to the bottom of why the HDLCD on
Juno doesn't work properly with recent upstream EDK2 (the Linux driver
thinks it's initialised and taken over, but the hardware stays stuck
displaying the last contents of the EFI framebuffer). I was hoping that
just unbinding and reprobing the HDLCD/TDA998x drivers might help reset
things hard enough to start working again, but sadly no...
Robin.
drivers/gpu/drm/arm/hdlcd_crtc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index e4d67b70244d..30a0d9570b57 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -193,6 +193,9 @@ static int hdlcd_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_display_mode *mode = &state->adjusted_mode;
long rate, clk_rate = mode->clock * 1000;
+ if (!state->enable)
+ return 0;
+
rate = clk_round_rate(hdlcd->clk, clk_rate);
if (rate != clk_rate) {
/* clock required by mode not supported by hardware */
--
2.20.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/bridge: sii902x: Implement HDMI audio support
On 25/02/2019 15:57, Andrzej Hajda wrote:
> On 25.02.2019 12:23, Jyri Sarha wrote:
>> Implement HDMI audio support by using ASoC HDMI codec. The commit
>> implements the necessary callbacks and configuration for the HDMI
>> codec and registers a virtual platform device for the codec to attach.
>>
>> Signed-off-by: Jyri Sarha
>> ---
>> .../bindings/display/bridge/sii902x.txt | 24 +
>> drivers/gpu/drm/bridge/sii902x.c | 456 +-
>> include/dt-bindings/sound/sii902x-audio.h | 11 +
>> 3 files changed, 485 insertions(+), 6 deletions(-)
>> create mode 100644 include/dt-bindings/sound/sii902x-audio.h
>>
>> diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
>> b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
>> index 72d2dc6c3e6b..a1cff91e4e84 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
>> @@ -8,6 +8,21 @@ Optional properties:
>> - interrupts: describe the interrupt line used to inform the host
>>about hotplug events.
>> - reset-gpios: OF device-tree gpio specification for RST_N pin.
>> +- i2s-fifo-routing: Array of exactly 4 integers indicating i2s
>> + pins for audio fifo routing. First integer defines routing to
>> + fifo 0 and second to fifo 1, etc. Integers can be filled with
>> + definitions from: include/dt-bindings/sound/sii902x-audio.h
>> + The available definitions are:
>> + - ENABLE_BIT: enable this audio fifo
>> + - CONNECT_SD#: route audio input from SD0, SD1, SD2, or SD3 i2s
>> + data input pin
>> + - LEFT_RIGHT_SWAP_BIT: swap i2s input channels for this fifo
>> + I2S HDMI audio is configured only if this property is found.
>> +- clocks: describes SII902x MCLK input. MCLK is used to produce
>> + HDMI audio CTS values. This property is required if
>> + "i2s-fifo-routing"-property is present. This property follows
>> + Documentation/devicetree/bindings/clock/clock-bindings.txt
>> + consumer binding.
>
>
> I wonder if it wouldn't be better to use of_graph to show connections
> between audio producer (A/V media processor) and the transmitter,
> i2s-fifo-routing value should be then derived from these bindings.
>
>
I do not think anybody will come up with a configuration where there
would be more than one audio producer. While there is multiple i2s input
data pins, there is only one i2s-clock-pin. The multiple pins are there
to provide 2, 4, 6, or 8 channel HDMI audio (two channels per wire), not
for multiple audio producers.
AFAIK, no driver describes i2s-wire one by one with of_graphs. However,
there are different kind of ASoC card-drivers pulling the different
ASoC-components, but the codec driver (like the sii902x with configured
audio would be) do not take part in such binding.
Then again we may never need the flexibility provided here. Maybe we
could survive with just the number of wires connected. That would
require that all HW designers will have decency to connect the i2s-wires
in the right order without skipping or crossing the wires.
Adding devicet...@vger.kernel.org to cc, since I forgot it from the
original recipient list.
>>
>> Optional subnodes:
>> - video input: this subnode can contain a video input port node
>> @@ -21,6 +36,15 @@ Example:
>> compatible = "sil,sii9022";
>> reg = <0x39>;
>> reset-gpios = <&pioA 1 0>;
>> +
>> +i2s-fifo-routing = <
>> +(ENABLE_BIT|CONNECT_SD0)
>> +0
>> +0
>> +0
>> +>;
>> +clocks = <&mclk>;
>> +
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> diff --git a/drivers/gpu/drm/bridge/sii902x.c
>> b/drivers/gpu/drm/bridge/sii902x.c
>> index 0e21fa419d27..f296a33c57c7 100644
>> --- a/drivers/gpu/drm/bridge/sii902x.c
>> +++ b/drivers/gpu/drm/bridge/sii902x.c
>> @@ -27,12 +27,16 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> #include
>> #include
>>
>> +#include
>> +#include
>> +
>> #define SII902X_TPI_VIDEO_DATA 0x0
>>
>> #define SII902X_TPI_PIXEL_REPETITION0x8
>> @@ -74,6 +78,77 @@
>> #define SII902X_AVI_POWER_STATE_MSK GENMASK(1, 0)
>> #define SII902X_AVI_POWER_STATE_D(l)((l) &
>> SII902X_AVI_POWER_STATE_MSK)
>>
>> +/* Audio */
>> +#define SII902X_TPI_I2S_ENABLE_MAPPING_REG 0x1f
>> +#define SII902X_TPI_I2S_CONFIG_FIFO0(0 << 0)
>> +#define SII902X_TPI_I2S_CONFIG_FIFO1(1 << 0)
>> +#define SII902X_TPI_I2S_CONFIG_FIFO2(2 << 0)
>> +#define SII902X_TPI_I2S_CONFIG_FIFO3(3 << 0)
>> +#define SII902X_TPI_I2S_LEFT_RIGHT_SWAP
