[PATCH 0/1] Regression in analogix_anx78xx
commit ff1e8fb68ea0 ("drm/bridge: analogix-anx78xx: Avoid drm_dp_link helpers")
stores the max link rate in a u8, overflowing it.
This will probably prevent the link training from working properly.
I've not tested this patch beyond a simple compile test since I do not own
any devices containing an anx78xx. So please test!
Tobias
Tobias Schramm (1):
drm/bridge: anx78xx: fix integer type used for storing dp link rate
drivers/gpu/drm/bridge/analogix-anx78xx.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] drm/bridge: anx78xx: fix integer type used for storing dp link rate
commit ff1e8fb68ea0 ("drm/bridge: analogix-anx78xx: Avoid drm_dp_link helpers")
changed the link training logic to remove use of drm_dp_link helpers. However
the new logic stores the maximum link rate in a u8, overflowing it.
This commit changes the logic to store the max link rate in a unsigned int
instead.
Signed-off-by: Tobias Schramm
---
drivers/gpu/drm/bridge/analogix-anx78xx.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index 274989f96a91..0f38b8c40dff 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -748,6 +748,7 @@ static int anx78xx_init_pdata(struct anx78xx *anx78xx)
static int anx78xx_dp_link_training(struct anx78xx *anx78xx)
{
u8 dp_bw, dpcd[2];
+ unsigned int max_link_rate;
int err;
err = regmap_write(anx78xx->map[I2C_IDX_RX_P0], SP_HDMI_MUTE_CTRL_REG,
@@ -866,8 +867,8 @@ static int anx78xx_dp_link_training(struct anx78xx *anx78xx)
if (err)
return err;
- dpcd[0] = drm_dp_max_link_rate(anx78xx->dpcd);
- dpcd[0] = drm_dp_link_rate_to_bw_code(dpcd[0]);
+ max_link_rate = drm_dp_max_link_rate(anx78xx->dpcd);
+ dpcd[0] = drm_dp_link_rate_to_bw_code(max_link_rate);
err = regmap_write(anx78xx->map[I2C_IDX_TX_P0],
SP_DP_MAIN_LINK_BW_SET_REG, dpcd[0]);
if (err)
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/7] Add dts for mt8183 GPU (and misc panfrost patches)
On Wed, Jan 8, 2020 at 1:23 PM Nicolas Boichat wrote: > > Hi! > > Sorry for the long delay since https://patchwork.kernel.org/patch/11132381/, > finally got around to give this a real try. > > The main purpose of this series is to upstream the dts change and the binding > document, but I wanted to see how far I could probe the GPU, to check that the > binding is indeed correct. The rest of the patches are RFC/work-in-progress, > but > I think some of them could already be picked up. > > So this is tested on MT8183 with a chromeos-4.19 kernel, and a ton of > backports to get the latest panfrost driver (I should probably try on > linux-next at some point but this was the path of least resistance). > > I tested it as a module as it's more challenging (originally probing would > work built-in, on boot, but not as a module, as I didn't have the power > domain changes, and all power domains are on by default during boot). > > Probing logs looks like this, currently: > [ 221.867726] panfrost 1304.gpu: clock rate = 51170 > [ 221.867929] panfrost 1304.gpu: Linked as a consumer to regulator.14 > [ 221.868600] panfrost 1304.gpu: Linked as a consumer to regulator.31 > [ 221.870586] panfrost 1304.gpu: Linked as a consumer to > genpd:0:1304.gpu > [ 221.871492] panfrost 1304.gpu: Linked as a consumer to > genpd:1:1304.gpu > [ 221.871866] panfrost 1304.gpu: Linked as a consumer to > genpd:2:1304.gpu > [ 221.872427] panfrost 1304.gpu: mali-g72 id 0x6221 major 0x0 minor 0x3 > status 0x0 > [ 221.872439] panfrost 1304.gpu: features: ,13de77ff, issues: > ,0400 > [ 221.872445] panfrost 1304.gpu: Features: L2:0x07120206 > Shader:0x Tiler:0x0809 Mem:0x1 MMU:0x2830 AS:0xff JS:0x7 > [ 221.872449] panfrost 1304.gpu: shader_present=0x7 l2_present=0x1 > [ 221.873526] panfrost 1304.gpu: error powering up gpu stack > [ 221.878088] [drm] Initialized panfrost 1.1.0 20180908 for 1304.gpu on > minor 2 > [ 221.940817] panfrost 1304.gpu: error powering up gpu stack > [ 222.018233] panfrost 1304.gpu: error powering up gpu stack > (repeated) > > So the GPU is probed, but there's an issue when powering up the STACK, not > quite sure why, I'll try to have a deeper look, at some point. Just as a follow-up to that one. stack_present=0x0007 on my GPU. However, the ARM-provided driver I use on this platform doesn't have CONFIG_MALI_CORESTACK enabled so the "stack" is never turned on. https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/drivers/gpu/arm/midgard/Kconfig#101 . So possibly this does not need to be done on Bifrost GPUs (and the error should be harmless). > Thanks! > > Nicolas > > v2: > - Use sram instead of mali_sram as SRAM supply name. > - Rename mali@ to gpu@. > - Add dt-bindings changes > - Stacking patches after the device tree change that allow basic >probing (still incomplete and broken). > > Nicolas Boichat (7): > dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183 > arm64: dts: mt8183: Add node for the Mali GPU > drm/panfrost: Improve error reporting in panfrost_gpu_power_on > drm/panfrost: Add support for a second regulator for the GPU > drm/panfrost: Add support for multiple power domain support > RFC: drm/panfrost: Add bifrost compatible string > RFC: drm/panfrost: devfreq: Add support for 2 regulators > > .../bindings/gpu/arm,mali-bifrost.yaml| 20 > arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 7 ++ > arch/arm64/boot/dts/mediatek/mt8183.dtsi | 104 + > drivers/gpu/drm/panfrost/panfrost_devfreq.c | 18 +++ > drivers/gpu/drm/panfrost/panfrost_device.c| 108 -- > drivers/gpu/drm/panfrost/panfrost_device.h| 7 ++ > drivers/gpu/drm/panfrost/panfrost_drv.c | 1 + > drivers/gpu/drm/panfrost/panfrost_gpu.c | 15 ++- > 8 files changed, 267 insertions(+), 13 deletions(-) > > -- > 2.24.1.735.g03f4e72817-goog > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH for-5.6 0/2] drm/bridge: dw-hdmi: PCM API updates
On Tue, 10 Dec 2019 16:45:34 +0100, Takashi Iwai wrote: > > Hi, > > this is a patch set for updating ALSA PCM API usages in dw-hdmi > driver. I already tried to "fix" the driver some time ago but it was > utterly wrong. So this is a combination of the revised patch and > another cleanup patch. > > The first one is to change the buffer allocation mechanism in the > driver to the manual allocation of the h/w buffer and the automatic > allocation of PCM stream buffers via the new standard API. The > significant change is that size of the h/w buffer isn't no longer > controlled via ALSA preallocation proc file but rather via the new > module option (if any). > > The second one is a oneliner patch just to remove the superfluous PCM > ops. > > Both need the ALSA PCM core changes in 5.5-rc1, so please apply them > on top of 5.5-rc1 or later. Or, just let me know if I should apply > them through sound git tree. > > > thanks, > > Takashi > > === > > Takashi Iwai (2): > drm/bridge: dw-hdmi: Follow the standard ALSA memalloc way > drm/bridge: dw-hdmi: Drop superfluous ioctl PCM ops Any chance for reviewing these patches? Since this driver is the only one who is still using the old ALSA vmalloc API, I'd like to change it and drop the old API in 5.6. thanks, Takashi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206141] New: VCE UVD ring test failed -110
https://bugzilla.kernel.org/show_bug.cgi?id=206141 Bug ID: 206141 Summary: VCE UVD ring test failed -110 Product: Drivers Version: 2.5 Kernel Version: 5.4.6 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: low Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: janpieter.sol...@dommel.be Regression: No Created attachment 286705 --> https://bugzilla.kernel.org/attachment.cgi?id=286705&action=edit part of DMESG that looks relevant while booting my PC, amdgpu complains it cannot execute UVD and VCE ring tests on Fiji GPU (R9 Nano). The error code -110 points to a timeout. Maybe R9 Nano needs more time to initialize the UVD decoder in UEFI mode? --- [7.270335] amdgpu :0a:00.0: [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* IB test failed on uvd (-110). [8.063987] Generic FE-GE Realtek PHY r8169-500:00: attached PHY driver [Generic FE-GE Realtek PHY] (mii_bus:phy_addr=r8169-500:00, irq=IGNORE) [8.211306] r8169 :05:00.0 eth0: Link is Down [8.400079] amdgpu :0a:00.0: [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* IB test failed on vce0 (-110). [8.400084] [drm:process_one_work] *ERROR* ib ring test failed (-110). Please note that this is not critical to me at all: I only use this card to perform OpenCL calculations via RoCm, so couldn't care less, but I still think it's worth to have a look at. -- 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 2/3] drm/i915/gvt: make gvt oblivious of kvmgt data structures
On Wed, 08 Jan 2020, Julian Stecklina wrote: > On Wed, 2020-01-08 at 12:24 +0200, Jani Nikula wrote: >> On Mon, 06 Jan 2020, Julian Stecklina >> >> wrote: > [...] >> > + /* Hypervisor-specific device state. */ >> > + void *vdev; >> >> I have no clue about the relative merits of the patch, but you can use >> the actual type for the pointer with a forward declaration. You don't >> need the definition for that. >> >> i.e. >> >> struct kvmgt_vdev; >> ... >> struct kvmgt_vdev *vdev; > > The goal here is to make the GVT code independent of the hypervisor backend. > Different hypervisor backends need to keep different per-device state, so > using > the KVM type here defeats the purpose. > > I assume this is not only useful for us, but also for other hypervisor > backends, > such as Xen or 3rd-party hypervisors. Right, carry on, sorry for the noise. ;) BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] xf86drm: only include for FreeBSD build case
The header is only required FreeBSD and GNU libc 2.30 starts to warn about Linux specific header deprecation. Only include for FreeBSD. Signed-off-by: Seung-Woo Kim --- xf86drmMode.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/xf86drmMode.c b/xf86drmMode.c index 207d7be..ff1d31d 100644 --- a/xf86drmMode.c +++ b/xf86drmMode.c @@ -42,9 +42,11 @@ #include #include #include +#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__) #ifdef HAVE_SYS_SYSCTL_H #include #endif +#endif /* defined (__FreeBSD__) || defined (__FreeBSD_kernel__) */ #include #include -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/4] dt-bindings: display: Convert Allwinner display pipeline to schemas
Hi Rob, On Fri, Jan 03, 2020 at 04:27:58PM +0100, Maxime Ripard wrote: > The Allwinner SoCs have a display engine composed of several controllers > assembled differently depending on the SoC, the number and type of output > they have, and the additional features they provide. A number of those are > supported in Linux, with the matching bindings. > > Now that we have the DT validation in place, let's split into separate file > and convert the device tree bindings for those controllers to schemas. > > Signed-off-by: Maxime Ripard > > --- > > Changes from v2: > - Changed a number of maxItems to minItems to make more sense > - Fixed a few enum that were improperly declared. This raised a bunch of > warnings that were unnoticed before. Fixed them. > - Added an if clause to the HDMI PHY binding to check the number of clocks > > Changes from v1: > - Declare the ports in the bindings Does that new version address your comments? As you know, this is the final schema patch for the Allwinner SoCs, so I'd like to get this merged in 5.6 to close this off. Thanks! Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] drm/radeon: have the callers of set_memory_*() check the return value
Am 08.01.20 um 18:51 schrieb Alex Deucher: On Wed, Jan 8, 2020 at 12:39 PM Kees Cook wrote: On Wed, Jan 08, 2020 at 01:56:47PM +0100, Christian König wrote: Am 07.01.20 um 20:25 schrieb Tianlin Li: Right now several architectures allow their set_memory_*() family of functions to fail, but callers may not be checking the return values. If set_memory_*() returns with an error, call-site assumptions may be infact wrong to assume that it would either succeed or not succeed at all. Ideally, the failure of set_memory_*() should be passed up the call stack, and callers should examine the failure and deal with it. Need to fix the callers and add the __must_check attribute. They also may not provide any level of atomicity, in the sense that the memory protections may be left incomplete on failure. This issue likely has a few steps on effects architectures: 1)Have all callers of set_memory_*() helpers check the return value. 2)Add __must_check to all set_memory_*() helpers so that new uses do not ignore the return value. 3)Add atomicity to the calls so that the memory protections aren't left in a partial state. This series is part of step 1. Make drm/radeon check the return value of set_memory_*(). I'm a little hesitate merge that. This hardware is >15 years old and nobody of the developers have any system left to test this change on. If that's true it should be removed from the tree. We need to be able to correctly make these kinds of changes in the kernel. This driver supports about 15 years of hardware generations. Newer cards are still prevalent, but the older stuff is less so. It still works and people use it based on feedback I've seen, but the older stuff has no active development at this point. This change just happens to target those older chips. Just a few weeks back we've got a mail from somebody using an integrated R128 in a laptop. After a few mails back and force we figured out that his nearly 20 years old hardware was finally failing. Up till that he was still successfully updating his kernel from time to time and the driver still worked. I find that pretty impressive. Alex Would it be to much of a problem to just add something like: r = set_memory_*(); (void)r; /* Intentionally ignored */. This seems like a bad idea -- we shouldn't be papering over failures like this when there is logic available to deal with it. Well I certainly agree to that, but we are talking about a call which happens only once during driver load/unload. If necessary we could also print an error when something goes wrong, but please no larger refactoring of return values and call paths. It is perfectly possible that this call actually failed on somebodies hardware, but we never noticed because the driver still works fine. If we now handle the error it is possible that the module never loads and the user gets a black screen instead. Regards, Christian. Apart from that certainly a good idea to add __must_check to the functions. Agreed! -Kees -- Kees Cook ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cchristian.koenig%40amd.com%7Ca542d384d54040b5b0b708d794636df1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637141027080080147&sdata=EHFl6YOHmNp7gOqWsVmfoeD0jNirBTOGHcCP4efC%2FvE%3D&reserved=0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH for-5.6 0/2] drm/bridge: dw-hdmi: PCM API updates
Hi, On 09/01/2020 10:10, Takashi Iwai wrote: > On Tue, 10 Dec 2019 16:45:34 +0100, > Takashi Iwai wrote: >> >> Hi, >> >> this is a patch set for updating ALSA PCM API usages in dw-hdmi >> driver. I already tried to "fix" the driver some time ago but it was >> utterly wrong. So this is a combination of the revised patch and >> another cleanup patch. >> >> The first one is to change the buffer allocation mechanism in the >> driver to the manual allocation of the h/w buffer and the automatic >> allocation of PCM stream buffers via the new standard API. The >> significant change is that size of the h/w buffer isn't no longer >> controlled via ALSA preallocation proc file but rather via the new >> module option (if any). >> >> The second one is a oneliner patch just to remove the superfluous PCM >> ops. >> >> Both need the ALSA PCM core changes in 5.5-rc1, so please apply them >> on top of 5.5-rc1 or later. Or, just let me know if I should apply >> them through sound git tree. >> >> >> thanks, >> >> Takashi >> >> === >> >> Takashi Iwai (2): >> drm/bridge: dw-hdmi: Follow the standard ALSA memalloc way >> drm/bridge: dw-hdmi: Drop superfluous ioctl PCM ops > > Any chance for reviewing these patches? > > Since this driver is the only one who is still using the old ALSA > vmalloc API, I'd like to change it and drop the old API in 5.6. Ping Russel since you reviewed the previous attempt. Neil > > > thanks, > > Takashi > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH for-5.6 0/2] drm/bridge: dw-hdmi: PCM API updates
On Thu, Jan 09, 2020 at 10:10:09AM +0100, Takashi Iwai wrote: > On Tue, 10 Dec 2019 16:45:34 +0100, > Takashi Iwai wrote: > > > > Hi, > > > > this is a patch set for updating ALSA PCM API usages in dw-hdmi > > driver. I already tried to "fix" the driver some time ago but it was > > utterly wrong. So this is a combination of the revised patch and > > another cleanup patch. > > > > The first one is to change the buffer allocation mechanism in the > > driver to the manual allocation of the h/w buffer and the automatic > > allocation of PCM stream buffers via the new standard API. The > > significant change is that size of the h/w buffer isn't no longer > > controlled via ALSA preallocation proc file but rather via the new > > module option (if any). > > > > The second one is a oneliner patch just to remove the superfluous PCM > > ops. > > > > Both need the ALSA PCM core changes in 5.5-rc1, so please apply them > > on top of 5.5-rc1 or later. Or, just let me know if I should apply > > them through sound git tree. > > > > > > thanks, > > > > Takashi > > > > === > > > > Takashi Iwai (2): > > drm/bridge: dw-hdmi: Follow the standard ALSA memalloc way > > drm/bridge: dw-hdmi: Drop superfluous ioctl PCM ops > > Any chance for reviewing these patches? > > Since this driver is the only one who is still using the old ALSA > vmalloc API, I'd like to change it and drop the old API in 5.6. It isn't something I can even test at the moment; I have the platforms but no TV to connect them to. -- 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 0/2] drm/radeon: have the callers of set_memory_*() check the return value
Hi Am 09.01.20 um 11:15 schrieb Christian König: > Am 08.01.20 um 18:51 schrieb Alex Deucher: >> On Wed, Jan 8, 2020 at 12:39 PM Kees Cook wrote: >>> On Wed, Jan 08, 2020 at 01:56:47PM +0100, Christian König wrote: Am 07.01.20 um 20:25 schrieb Tianlin Li: > Right now several architectures allow their set_memory_*() family of > functions to fail, but callers may not be checking the return values. > If set_memory_*() returns with an error, call-site assumptions may be > infact wrong to assume that it would either succeed or not succeed at > all. Ideally, the failure of set_memory_*() should be passed up the > call stack, and callers should examine the failure and deal with it. > > Need to fix the callers and add the __must_check attribute. They also > may not provide any level of atomicity, in the sense that the memory > protections may be left incomplete on failure. This issue likely has a > few steps on effects architectures: > 1)Have all callers of set_memory_*() helpers check the return value. > 2)Add __must_check to all set_memory_*() helpers so that new uses do > not ignore the return value. > 3)Add atomicity to the calls so that the memory protections aren't > left > in a partial state. > > This series is part of step 1. Make drm/radeon check the return > value of > set_memory_*(). I'm a little hesitate merge that. This hardware is >15 years old and nobody of the developers have any system left to test this change on. >>> If that's true it should be removed from the tree. We need to be able to >>> correctly make these kinds of changes in the kernel. >> This driver supports about 15 years of hardware generations. Newer >> cards are still prevalent, but the older stuff is less so. It still >> works and people use it based on feedback I've seen, but the older >> stuff has no active development at this point. This change just >> happens to target those older chips. > > Just a few weeks back we've got a mail from somebody using an integrated > R128 in a laptop. > > After a few mails back and force we figured out that his nearly 20 years > old hardware was finally failing. > > Up till that he was still successfully updating his kernel from time to > time and the driver still worked. I find that pretty impressive. > >> >> Alex >> Would it be to much of a problem to just add something like: r = set_memory_*(); (void)r; /* Intentionally ignored */. >>> This seems like a bad idea -- we shouldn't be papering over failures >>> like this when there is logic available to deal with it. > > Well I certainly agree to that, but we are talking about a call which > happens only once during driver load/unload. If necessary we could also > print an error when something goes wrong, but please no larger > refactoring of return values and call paths. > IMHO radeon should be marked as orphaned or obsolete then. Best regards Thomas > It is perfectly possible that this call actually failed on somebodies > hardware, but we never noticed because the driver still works fine. If > we now handle the error it is possible that the module never loads and > the user gets a black screen instead. > > Regards, > Christian. > >>> Apart from that certainly a good idea to add __must_check to the functions. >>> Agreed! >>> >>> -Kees >>> >>> -- >>> Kees Cook >>> ___ >>> dri-devel mailing list >>> dri-devel@lists.freedesktop.org >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cchristian.koenig%40amd.com%7Ca542d384d54040b5b0b708d794636df1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637141027080080147&sdata=EHFl6YOHmNp7gOqWsVmfoeD0jNirBTOGHcCP4efC%2FvE%3D&reserved=0 >>> > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 194731] drm general protection fault in drm_atomic_init
https://bugzilla.kernel.org/show_bug.cgi?id=194731 Janpieter Sollie (janpieter.sol...@dommel.be) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |OBSOLETE -- 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: [Intel-gfx] [RFC 5/7] drm/i915: Make WARN* device specific where drm_priv ptr is available
On Wed, Jan 08, 2020 at 02:52:02PM +0200, Jani Nikula wrote:
> On Mon, 06 Jan 2020, Pankaj Bharadiya
> wrote:
> > Device specific WARN* calls include device information in the
> > backtrace, so we know what device the warnings originate from.
> >
> > Covert all the calls of WARN* with device specific dev_WARN*
> > variants in functions where drm_i915_private struct pointer is readily
> > available.
> >
> > The conversion was done automatically with below coccinelle semantic
> > patch. checkpatch errors/warnings are fixed manually.
> >
> > @rule1@
> > identifier func, T;
> > @@
> > func(...) {
> > ...
> > struct drm_i915_private *T = ...;
> > +struct device *dev = i915_to_dev(T);
> > <+...
> > (
> > -WARN(
> > +dev_WARN(dev,
> > ...)
> > |
> > -WARN_ON(
> > +dev_WARN_ON(dev,
> > ...)
> > |
> > -WARN_ONCE(
> > +dev_WARN_ONCE(dev,
> > ...)
> > |
> > -WARN_ON_ONCE(
> > +dev_WARN_ON_ONCE(dev,
> > ...)
> > )
> > ...+>
> > }
> >
> > @rule2@
> > identifier func, T;
> > @@
> > func(struct drm_i915_private *T,...) {
> > +struct device *dev = i915_to_dev(T);
> > <+...
> > (
> > -WARN(
> > +dev_WARN(dev,
> > ...)
> > |
> > -WARN_ON(
> > +dev_WARN_ON(dev,
> > ...)
> > |
> > -WARN_ONCE(
> > +dev_WARN_ONCE(dev,
> > ...)
> > |
> > -WARN_ON_ONCE(
> > +dev_WARN_ON_ONCE(dev,
> > ...)
> > )
> > ...+>
> > }
> >
> > command: spatch --sp-file
[RESEND 0/1] Add support for BOE NV140FHM-N49 panel to panel-simple
This patch adds support for the 14 inch BOE NV140FHM-N49 eDP panel to the panel-simple driver. The panel is used by the Pinebook Pro. Resending with changed CCs due to lack of feedback. Tobias Schramm (1): drm/panel: Add support for BOE NV140FHM-N49 panel to panel-simple drivers/gpu/drm/panel/panel-simple.c | 35 1 file changed, 35 insertions(+) -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND 1/1] drm/panel: Add support for BOE NV140FHM-N49 panel to panel-simple
This patch adds support for the BOE NV140FHM-N49 panel to the panel-simple
driver. The panel is used by the pine64 Pinebook Pro.
Signed-off-by: Tobias Schramm
---
drivers/gpu/drm/panel/panel-simple.c | 35
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 5d487686d25c..6320df9765f3 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1036,6 +1036,38 @@ static const struct panel_desc boe_nv101wxmn51 = {
},
};
+static const struct drm_display_mode boe_nv140fhmn49_modes[] = {
+ {
+ .clock = 148500,
+ .hdisplay = 1920,
+ .hsync_start = 1920 + 48,
+ .hsync_end = 1920 + 48 + 32,
+ .htotal = 2200,
+ .vdisplay = 1080,
+ .vsync_start = 1080 + 3,
+ .vsync_end = 1080 + 3 + 5,
+ .vtotal = 1125,
+ .vrefresh = 60,
+ },
+};
+
+static const struct panel_desc boe_nv140fhmn49 = {
+ .modes = boe_nv140fhmn49_modes,
+ .num_modes = ARRAY_SIZE(boe_nv140fhmn49_modes),
+ .bpc = 6,
+ .size = {
+ .width = 309,
+ .height = 174,
+ },
+ .delay = {
+ .prepare = 210,
+ .enable = 50,
+ .unprepare = 160,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .connector_type = DRM_MODE_CONNECTOR_eDP,
+};
+
static const struct drm_display_mode cdtech_s043wq26h_ct7_mode = {
.clock = 9000,
.hdisplay = 480,
@@ -3161,6 +3193,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "boe,nv101wxmn51",
.data = &boe_nv101wxmn51,
+ }, {
+ .compatible = "boe,nv140fhmn49",
+ .data = &boe_nv140fhmn49,
}, {
.compatible = "cdtech,s043wq26h-ct7",
.data = &cdtech_s043wq26h_ct7,
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFT v1 2/3] drm/panfrost: call dev_pm_opp_of_remove_table() in all error-paths
On 07/01/2020 23:06, Martin Blumenstingl wrote:
> If devfreq_recommended_opp() fails we need to undo
> dev_pm_opp_of_add_table() by calling dev_pm_opp_of_remove_table() (just
> like we do it in the other error-path below).
>
> Fixes: f3ba91228e8e91 ("drm/panfrost: Add initial panfrost driver")
> Signed-off-by: Martin Blumenstingl
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> index 1471588763ce..170f6c8c9651 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> @@ -93,8 +93,10 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
> cur_freq = clk_get_rate(pfdev->clock);
>
> opp = devfreq_recommended_opp(dev, &cur_freq, 0);
> - if (IS_ERR(opp))
> + if (IS_ERR(opp)) {
> + dev_pm_opp_of_remove_table(dev);
> return PTR_ERR(opp);
> + }
>
> panfrost_devfreq_profile.initial_freq = cur_freq;
> dev_pm_opp_put(opp);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFT v1 3/3] drm/panfrost: Use the mali-supply regulator for control again
On 07/01/2020 23:06, Martin Blumenstingl wrote:
> dev_pm_opp_set_rate() needs a reference to the regulator which should be
> updated when updating the GPU frequency. The name of the regulator has
> to be passed at initialization-time using dev_pm_opp_set_regulators().
> Add the call to dev_pm_opp_set_regulators() so dev_pm_opp_set_rate()
> will update the GPU regulator when updating the frequency (just like
> we did this manually before when we open-coded dev_pm_opp_set_rate()).
This patch causes a warning from debugfs on my firefly (RK3288) board:
debugfs: Directory 'ffa3.gpu-mali' with parent 'vdd_gpu' already
present!
So it looks like the regulator is being added twice - but I haven't
investigated further.
> Fixes: 221bc77914cbcc ("drm/panfrost: Use generic code for devfreq")
> Reported-by: Robin Murphy
> Signed-off-by: Martin Blumenstingl
> ---
> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 22 -
> drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
> 2 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> index 170f6c8c9651..4f7999c7b44c 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> @@ -74,6 +74,7 @@ static struct devfreq_dev_profile panfrost_devfreq_profile
> = {
> int panfrost_devfreq_init(struct panfrost_device *pfdev)
> {
> int ret;
> + struct opp_table *opp_table;
> struct dev_pm_opp *opp;
> unsigned long cur_freq;
> struct device *dev = &pfdev->pdev->dev;
> @@ -84,9 +85,24 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
> /* Optional, continue without devfreq */
> return 0;
>
> + opp_table = dev_pm_opp_set_regulators(dev,
> + (const char *[]){ "mali" },
> + 1);
> + if (IS_ERR(opp_table)) {
> + ret = PTR_ERR(opp_table);
> +
> + /* Continue if the optional regulator is missing */
> + if (ret != -ENODEV)
> + return ret;
> + } else {
> + pfdev->devfreq.regulators_opp_table = opp_table;
> + }
> +
> ret = dev_pm_opp_of_add_table(dev);
> - if (ret)
> + if (ret) {
> + dev_pm_opp_put_regulators(pfdev->devfreq.regulators_opp_table);
If we don't have a regulator then regulators_opp_table will be NULL and
sadly dev_pm_opp_put_regulators() doesn't handle a NULL argument. The
same applies to the two below calls obviously.
Steve
> return ret;
> + }
>
> panfrost_devfreq_reset(pfdev);
>
> @@ -95,6 +111,7 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
> opp = devfreq_recommended_opp(dev, &cur_freq, 0);
> if (IS_ERR(opp)) {
> dev_pm_opp_of_remove_table(dev);
> + dev_pm_opp_put_regulators(pfdev->devfreq.regulators_opp_table);
> return PTR_ERR(opp);
> }
>
> @@ -106,6 +123,7 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
> if (IS_ERR(devfreq)) {
> DRM_DEV_ERROR(dev, "Couldn't initialize GPU devfreq\n");
> dev_pm_opp_of_remove_table(dev);
> + dev_pm_opp_put_regulators(pfdev->devfreq.regulators_opp_table);
> return PTR_ERR(devfreq);
> }
> pfdev->devfreq.devfreq = devfreq;
> @@ -124,6 +142,8 @@ void panfrost_devfreq_fini(struct panfrost_device *pfdev)
> if (pfdev->devfreq.cooling)
> devfreq_cooling_unregister(pfdev->devfreq.cooling);
> dev_pm_opp_of_remove_table(&pfdev->pdev->dev);
> + if (pfdev->devfreq.regulators_opp_table)
> + dev_pm_opp_put_regulators(pfdev->devfreq.regulators_opp_table);
> }
>
> void panfrost_devfreq_resume(struct panfrost_device *pfdev)
> diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
> b/drivers/gpu/drm/panfrost/panfrost_device.h
> index 06713811b92c..4878b239e301 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_device.h
> +++ b/drivers/gpu/drm/panfrost/panfrost_device.h
> @@ -85,6 +85,7 @@ struct panfrost_device {
>
> struct {
> struct devfreq *devfreq;
> + struct opp_table *regulators_opp_table;
> struct thermal_cooling_device *cooling;
> ktime_t busy_time;
> ktime_t idle_time;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/9] iomap: Constify ioreadX() iomem argument (as in generic implementation)
On Wed, Jan 8, 2020 at 9:05 PM Krzysztof Kozlowski wrote:
> The ioreadX() and ioreadX_rep() helpers have inconsistent interface. On
> some architectures void *__iomem address argument is a pointer to const,
> on some not.
>
> Implementations of ioreadX() do not modify the memory under the address
> so they can be converted to a "const" version for const-safety and
> consistency among architectures.
>
> Suggested-by: Geert Uytterhoeven
> Signed-off-by: Krzysztof Kozlowski
> Reviewed-by: Geert Uytterhoeven
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/7] Add dts for mt8183 GPU (and misc panfrost patches)
On 08/01/2020 05:23, Nicolas Boichat wrote: Hi! Sorry for the long delay since https://patchwork.kernel.org/patch/11132381/, finally got around to give this a real try. The main purpose of this series is to upstream the dts change and the binding document, but I wanted to see how far I could probe the GPU, to check that the binding is indeed correct. The rest of the patches are RFC/work-in-progress, but I think some of them could already be picked up. So this is tested on MT8183 with a chromeos-4.19 kernel, and a ton of backports to get the latest panfrost driver (I should probably try on linux-next at some point but this was the path of least resistance). I tested it as a module as it's more challenging (originally probing would work built-in, on boot, but not as a module, as I didn't have the power domain changes, and all power domains are on by default during boot). Probing logs looks like this, currently: [ 221.867726] panfrost 1304.gpu: clock rate = 51170 [ 221.867929] panfrost 1304.gpu: Linked as a consumer to regulator.14 [ 221.868600] panfrost 1304.gpu: Linked as a consumer to regulator.31 [ 221.870586] panfrost 1304.gpu: Linked as a consumer to genpd:0:1304.gpu [ 221.871492] panfrost 1304.gpu: Linked as a consumer to genpd:1:1304.gpu [ 221.871866] panfrost 1304.gpu: Linked as a consumer to genpd:2:1304.gpu [ 221.872427] panfrost 1304.gpu: mali-g72 id 0x6221 major 0x0 minor 0x3 status 0x0 [ 221.872439] panfrost 1304.gpu: features: ,13de77ff, issues: ,0400 [ 221.872445] panfrost 1304.gpu: Features: L2:0x07120206 Shader:0x Tiler:0x0809 Mem:0x1 MMU:0x2830 AS:0xff JS:0x7 [ 221.872449] panfrost 1304.gpu: shader_present=0x7 l2_present=0x1 [ 221.873526] panfrost 1304.gpu: error powering up gpu stack [ 221.878088] [drm] Initialized panfrost 1.1.0 20180908 for 1304.gpu on minor 2 [ 221.940817] panfrost 1304.gpu: error powering up gpu stack [ 222.018233] panfrost 1304.gpu: error powering up gpu stack (repeated) It's interesting that it's only the stack that is failing. In hardware there's a dependency: L2->stack->shader - so in theory the shader cores shouldn't be able to power up either. There are some known hardware bugs here though[1]: MODULE_PARM_DESC(corestack_driver_control, "Let the driver power on/off the GPU core stack independently " "without involving the Power Domain Controller. This should " "only be enabled on platforms for which integration of the PDC " "to the Mali GPU is known to be problematic."); [1] https://github.com/ianmacd/d2s/blob/master/drivers/gpu/arm/b_r16p0/backend/gpu/mali_kbase_pm_driver.c#L57 It might be worth just dropping the code for powering up/down stacks and let the GPU's own dependency management handle it. Steve So the GPU is probed, but there's an issue when powering up the STACK, not quite sure why, I'll try to have a deeper look, at some point. Thanks! Nicolas v2: - Use sram instead of mali_sram as SRAM supply name. - Rename mali@ to gpu@. - Add dt-bindings changes - Stacking patches after the device tree change that allow basic probing (still incomplete and broken). Nicolas Boichat (7): dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183 arm64: dts: mt8183: Add node for the Mali GPU drm/panfrost: Improve error reporting in panfrost_gpu_power_on drm/panfrost: Add support for a second regulator for the GPU drm/panfrost: Add support for multiple power domain support RFC: drm/panfrost: Add bifrost compatible string RFC: drm/panfrost: devfreq: Add support for 2 regulators .../bindings/gpu/arm,mali-bifrost.yaml| 20 arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 7 ++ arch/arm64/boot/dts/mediatek/mt8183.dtsi | 104 + drivers/gpu/drm/panfrost/panfrost_devfreq.c | 18 +++ drivers/gpu/drm/panfrost/panfrost_device.c| 108 -- drivers/gpu/drm/panfrost/panfrost_device.h| 7 ++ drivers/gpu/drm/panfrost/panfrost_drv.c | 1 + drivers/gpu/drm/panfrost/panfrost_gpu.c | 15 ++- 8 files changed, 267 insertions(+), 13 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/7] drm/panfrost: Improve error reporting in panfrost_gpu_power_on
On 08/01/2020 05:23, Nicolas Boichat wrote: It is useful to know which component cannot be powered on. Signed-off-by: Nicolas Boichat Looks like helpful error reporting. Reviewed-by: Steven Price --- Was useful when trying to probe bifrost GPU, to understand what issue we are facing. --- drivers/gpu/drm/panfrost/panfrost_gpu.c | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c b/drivers/gpu/drm/panfrost/panfrost_gpu.c index 8822ec13a0d619f..ba02bbfcf28c011 100644 --- a/drivers/gpu/drm/panfrost/panfrost_gpu.c +++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c @@ -308,21 +308,26 @@ void panfrost_gpu_power_on(struct panfrost_device *pfdev) gpu_write(pfdev, L2_PWRON_LO, pfdev->features.l2_present); ret = readl_relaxed_poll_timeout(pfdev->iomem + L2_READY_LO, val, val == pfdev->features.l2_present, 100, 1000); + if (ret) + dev_err(pfdev->dev, "error powering up gpu L2"); gpu_write(pfdev, STACK_PWRON_LO, pfdev->features.stack_present); - ret |= readl_relaxed_poll_timeout(pfdev->iomem + STACK_READY_LO, + ret = readl_relaxed_poll_timeout(pfdev->iomem + STACK_READY_LO, val, val == pfdev->features.stack_present, 100, 1000); + if (ret) + dev_err(pfdev->dev, "error powering up gpu stack"); As mentioned in my previous email - we could just drop this entire section dealing with the core stacks and let the GPU's own dependency management code handle it. Of course there might be a GPU out there for which that is broken... in which case some sort of quirk handling will be needed :( Steve gpu_write(pfdev, SHADER_PWRON_LO, pfdev->features.shader_present); - ret |= readl_relaxed_poll_timeout(pfdev->iomem + SHADER_READY_LO, + ret = readl_relaxed_poll_timeout(pfdev->iomem + SHADER_READY_LO, val, val == pfdev->features.shader_present, 100, 1000); + if (ret) + dev_err(pfdev->dev, "error powering up gpu shader"); gpu_write(pfdev, TILER_PWRON_LO, pfdev->features.tiler_present); - ret |= readl_relaxed_poll_timeout(pfdev->iomem + TILER_READY_LO, + ret = readl_relaxed_poll_timeout(pfdev->iomem + TILER_READY_LO, val, val == pfdev->features.tiler_present, 100, 1000); - if (ret) - dev_err(pfdev->dev, "error powering up gpu"); + dev_err(pfdev->dev, "error powering up gpu tiler"); } void panfrost_gpu_power_off(struct panfrost_device *pfdev) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/dp: Add function to parse EDID descriptors for adaptive sync limits
On Tue, Jan 07, 2020 at 04:32:08PM -0800, Manasi Navare wrote:
> Adaptive Sync is a VESA feature so add a DRM core helper to parse
> the EDID's detailed descritors to obtain the adaptive sync monitor range.
> Store this info as part fo drm_display_info so it can be used
> across all drivers.
> This part of the code is stripped out of amdgpu's function
> amdgpu_dm_update_freesync_caps() to make it generic and be used
> across all DRM drivers
>
> v2:
> * Change vmin and vmax to use u8 (Ville)
> * Dont store pixel clock since that is just a max dotclock
> and not related to VRR mode (Manasi)
>
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Clinton A Taylor
> Cc: Nicholas Kazlauskas
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/drm_edid.c | 51 +
> include/drm/drm_connector.h | 22
> include/drm/drm_edid.h | 2 ++
> 3 files changed, 75 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 99769d6c9f84..52781a0e708b 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4880,6 +4880,54 @@ static void drm_parse_cea_ext(struct drm_connector
> *connector,
> }
> }
>
> +void drm_get_adaptive_sync_limits(struct drm_connector *connector,
> + const struct edid *edid)
> +{
> + struct drm_display_info *info = &connector->display_info;
> + const struct detailed_timing *timing;
> + const struct detailed_non_pixel *data;
> + const struct detailed_data_monitor_range *range;
Needlessly wide scope for everything above.
> + int i;
> +
> + /*
> + * Restrict Adaptive Sync only for dp and edp
> + */
> + if (connector->connector_type != DRM_MODE_CONNECTOR_DisplayPort &&
> + connector->connector_type != DRM_MODE_CONNECTOR_eDP)
> + return;
> +
> + if (edid->version <= 1 && !(edid->version == 1 && edid->revision > 1))
> + return;
if (!version_greater(...))
return;
> +
> + for (i = 0; i < 4; i++) {
This should probably use for_each_detailed_block()
> + timing = &edid->detailed_timings[i];
> + data= &timing->data.other_data;
> + range = &data->data.range;
> + /*
> + * Check if monitor has continuous frequency mode
> + */
> + if (data->type != EDID_DETAIL_MONITOR_RANGE)
> + continue;
> + /*
> + * Check for flag range limits only. If flag == 1 then
> + * no additional timing information provided.
> + * Default GTF, GTF Secondary curve and CVT are not
> + * supported
> + */
> + if (range->flags != 1)
> + continue;
> +
> + info->adaptive_sync.min_vfreq = range->min_vfreq;
> + info->adaptive_sync.max_vfreq = range->max_vfreq;
> +
> + DRM_DEBUG_KMS("Adaptive Sync refresh rate range is %d Hz - %d
> Hz\n",
> + info->adaptive_sync.min_vfreq,
> + info->adaptive_sync.max_vfreq);
> + break;
> + }
> +}
> +EXPORT_SYMBOL(drm_get_adaptive_sync_limits);
> +
> /* A connector has no EDID information, so we've got no EDID to compute
> quirks from. Reset
> * all of the values which would have been set from EDID
> */
> @@ -4901,6 +4949,7 @@ drm_reset_display_info(struct drm_connector *connector)
> memset(&info->hdmi, 0, sizeof(info->hdmi));
>
> info->non_desktop = 0;
> + memset(&info->adaptive_sync, 0, sizeof(info->adaptive_sync));
> }
>
> u32 drm_add_display_info(struct drm_connector *connector, const struct edid
> *edid)
> @@ -4916,6 +4965,8 @@ u32 drm_add_display_info(struct drm_connector
> *connector, const struct edid *edi
>
> info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
>
> + drm_get_adaptive_sync_limits(connector, edid);
> +
> DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);
>
> if (edid->revision < 3)
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 221910948b37..77df404a2e01 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -254,6 +254,23 @@ enum drm_panel_orientation {
> DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
> };
>
> +/**
> + * struct drm_adaptive_sync_info - Panel's Adaptive Sync capabilities for
> + * &drm_display_info
> + *
> + * This struct is used to store a Panel's Adaptive Sync capabilities
> + * as parsed from EDID's detailed monitor range descriptor block.
> + *
> + * @min_vfreq: This is the min supported refresh rate in Hz from
> + * EDID's detailed monitor range.
> + * @max_vfreq: This is the max supported refresh rate in Hz from
> + * EDID's detailed monitor range
> + */
> +struct drm_adaptive_sync_info {
> + u8 min_vfreq;
> + u8 max_vfreq;
> +};
> +
> /*
>
Re: [PATCH v2 0/7] Add dts for mt8183 GPU (and misc panfrost patches)
On 09/01/2020 12:01 pm, Steven Price wrote: On 08/01/2020 05:23, Nicolas Boichat wrote: Hi! Sorry for the long delay since https://patchwork.kernel.org/patch/11132381/, finally got around to give this a real try. The main purpose of this series is to upstream the dts change and the binding document, but I wanted to see how far I could probe the GPU, to check that the binding is indeed correct. The rest of the patches are RFC/work-in-progress, but I think some of them could already be picked up. So this is tested on MT8183 with a chromeos-4.19 kernel, and a ton of backports to get the latest panfrost driver (I should probably try on linux-next at some point but this was the path of least resistance). I tested it as a module as it's more challenging (originally probing would work built-in, on boot, but not as a module, as I didn't have the power domain changes, and all power domains are on by default during boot). Probing logs looks like this, currently: [ 221.867726] panfrost 1304.gpu: clock rate = 51170 [ 221.867929] panfrost 1304.gpu: Linked as a consumer to regulator.14 [ 221.868600] panfrost 1304.gpu: Linked as a consumer to regulator.31 [ 221.870586] panfrost 1304.gpu: Linked as a consumer to genpd:0:1304.gpu [ 221.871492] panfrost 1304.gpu: Linked as a consumer to genpd:1:1304.gpu [ 221.871866] panfrost 1304.gpu: Linked as a consumer to genpd:2:1304.gpu [ 221.872427] panfrost 1304.gpu: mali-g72 id 0x6221 major 0x0 minor 0x3 status 0x0 [ 221.872439] panfrost 1304.gpu: features: ,13de77ff, issues: ,0400 [ 221.872445] panfrost 1304.gpu: Features: L2:0x07120206 Shader:0x Tiler:0x0809 Mem:0x1 MMU:0x2830 AS:0xff JS:0x7 [ 221.872449] panfrost 1304.gpu: shader_present=0x7 l2_present=0x1 [ 221.873526] panfrost 1304.gpu: error powering up gpu stack [ 221.878088] [drm] Initialized panfrost 1.1.0 20180908 for 1304.gpu on minor 2 [ 221.940817] panfrost 1304.gpu: error powering up gpu stack [ 222.018233] panfrost 1304.gpu: error powering up gpu stack (repeated) It's interesting that it's only the stack that is failing. In hardware there's a dependency: L2->stack->shader - so in theory the shader cores shouldn't be able to power up either. There are some known hardware bugs here though[1]: MODULE_PARM_DESC(corestack_driver_control, "Let the driver power on/off the GPU core stack independently " "without involving the Power Domain Controller. This should " "only be enabled on platforms for which integration of the PDC " "to the Mali GPU is known to be problematic."); [1] https://github.com/ianmacd/d2s/blob/master/drivers/gpu/arm/b_r16p0/backend/gpu/mali_kbase_pm_driver.c#L57 It might be worth just dropping the code for powering up/down stacks and let the GPU's own dependency management handle it. FWIW I remember digging into that same message a while back (although I've forgotten which particular GPU I was playing with at the time), and concluded that the STACK_PWRON/STACK_READY registers might just not be implemented on some GPUs, and/or this easy-to-overlook register bit could be some kind of enable for the functionality: https://github.com/ianmacd/d2s/blob/master/drivers/gpu/arm/b_r16p0/backend/gpu/mali_kbase_pm_driver.c#L1631 Since even in kbase this is all behind an 'expert' config option, I'm inclined to agree that just dropping it from panfrost unless and until it proves necessary is probably preferable to adding more logic and inscrutable register-magic. Robin. Steve So the GPU is probed, but there's an issue when powering up the STACK, not quite sure why, I'll try to have a deeper look, at some point. Thanks! Nicolas v2: - Use sram instead of mali_sram as SRAM supply name. - Rename mali@ to gpu@. - Add dt-bindings changes - Stacking patches after the device tree change that allow basic probing (still incomplete and broken). Nicolas Boichat (7): dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183 arm64: dts: mt8183: Add node for the Mali GPU drm/panfrost: Improve error reporting in panfrost_gpu_power_on drm/panfrost: Add support for a second regulator for the GPU drm/panfrost: Add support for multiple power domain support RFC: drm/panfrost: Add bifrost compatible string RFC: drm/panfrost: devfreq: Add support for 2 regulators .../bindings/gpu/arm,mali-bifrost.yaml | 20 arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 7 ++ arch/arm64/boot/dts/mediatek/mt8183.dtsi | 104 + drivers/gpu/drm/panfrost/panfrost_devfreq.c | 18 +++ drivers/gpu/drm/panfrost/panfrost_device.c | 108 -- drivers/gpu/drm/panfrost/panfrost_device.h | 7 ++ drivers/gpu/drm/panfrost/panfrost_drv.c | 1 + drivers/gpu/drm/panfrost/panfrost_gpu.c | 15 ++- 8 files changed, 267 i
Re: [PATCH v2 0/7] Add dts for mt8183 GPU (and misc panfrost patches)
On Thu, Jan 09, 2020 at 01:10:33PM +, Robin Murphy wrote: > On 09/01/2020 12:01 pm, Steven Price wrote: > > On 08/01/2020 05:23, Nicolas Boichat wrote: > >> Hi! > >> > >> Sorry for the long delay since > >> https://patchwork.kernel.org/patch/11132381/, > >> finally got around to give this a real try. > >> > >> The main purpose of this series is to upstream the dts change and the > >> binding > >> document, but I wanted to see how far I could probe the GPU, to check > >> that the > >> binding is indeed correct. The rest of the patches are > >> RFC/work-in-progress, but > >> I think some of them could already be picked up. > >> > >> So this is tested on MT8183 with a chromeos-4.19 kernel, and a ton of > >> backports to get the latest panfrost driver (I should probably try on > >> linux-next at some point but this was the path of least resistance). > >> > >> I tested it as a module as it's more challenging (originally probing > >> would > >> work built-in, on boot, but not as a module, as I didn't have the power > >> domain changes, and all power domains are on by default during boot). > >> > >> Probing logs looks like this, currently: > >> [ 221.867726] panfrost 1304.gpu: clock rate = 51170 > >> [ 221.867929] panfrost 1304.gpu: Linked as a consumer to > >> regulator.14 > >> [ 221.868600] panfrost 1304.gpu: Linked as a consumer to > >> regulator.31 > >> [ 221.870586] panfrost 1304.gpu: Linked as a consumer to > >> genpd:0:1304.gpu > >> [ 221.871492] panfrost 1304.gpu: Linked as a consumer to > >> genpd:1:1304.gpu > >> [ 221.871866] panfrost 1304.gpu: Linked as a consumer to > >> genpd:2:1304.gpu > >> [ 221.872427] panfrost 1304.gpu: mali-g72 id 0x6221 major 0x0 > >> minor 0x3 status 0x0 > >> [ 221.872439] panfrost 1304.gpu: features: ,13de77ff, > >> issues: ,0400 > >> [ 221.872445] panfrost 1304.gpu: Features: L2:0x07120206 > >> Shader:0x Tiler:0x0809 Mem:0x1 MMU:0x2830 AS:0xff JS:0x7 > >> [ 221.872449] panfrost 1304.gpu: shader_present=0x7 l2_present=0x1 > >> [ 221.873526] panfrost 1304.gpu: error powering up gpu stack > >> [ 221.878088] [drm] Initialized panfrost 1.1.0 20180908 for > >> 1304.gpu on minor 2 > >> [ 221.940817] panfrost 1304.gpu: error powering up gpu stack > >> [ 222.018233] panfrost 1304.gpu: error powering up gpu stack > >> (repeated) > > > > It's interesting that it's only the stack that is failing. In hardware > > there's a dependency: L2->stack->shader - so in theory the shader cores > > shouldn't be able to power up either. There are some known hardware bugs > > here though[1]: > > > > MODULE_PARM_DESC(corestack_driver_control, > > "Let the driver power on/off the GPU core stack > > independently " > > "without involving the Power Domain Controller. This should " > > "only be enabled on platforms for which integration of the > > PDC " > > "to the Mali GPU is known to be problematic."); > > > > [1] > > https://github.com/ianmacd/d2s/blob/master/drivers/gpu/arm/b_r16p0/backend/gpu/mali_kbase_pm_driver.c#L57 > > > > > > > > It might be worth just dropping the code for powering up/down stacks and > > let the GPU's own dependency management handle it. > > FWIW I remember digging into that same message a while back (although > I've forgotten which particular GPU I was playing with at the time), and > concluded that the STACK_PWRON/STACK_READY registers might just not be > implemented on some GPUs, They are indeed not implemented on some GPUs. Specifically none of the Midgard GPUs. I believe G71 also doesn't have it. However the register addresses were picked so that on these older GPUs they should read-as-zero and write-ignore so this shouldn't actually cause any problems. > and/or this easy-to-overlook register bit > could be some kind of enable for the functionality: > > https://github.com/ianmacd/d2s/blob/master/drivers/gpu/arm/b_r16p0/backend/gpu/mali_kbase_pm_driver.c#L1631 > > Since even in kbase this is all behind an 'expert' config option, I'm > inclined to agree that just dropping it from panfrost unless and until > it proves necessary is probably preferable to adding more logic and > inscrutable register-magic. Indeed - I'll post a patch removing it. Thanks, Steve > Robin. > > > > > Steve > > > >> > >> So the GPU is probed, but there's an issue when powering up the STACK, > >> not > >> quite sure why, I'll try to have a deeper look, at some point. > >> > >> Thanks! > >> > >> Nicolas > >> > >> v2: > >> - Use sram instead of mali_sram as SRAM supply name. > >> - Rename mali@ to gpu@. > >> - Add dt-bindings changes > >> - Stacking patches after the device tree change that allow basic > >> probing (still incomplete and broken). > >> > >> Nicolas Boichat (7): > >> dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183 > >> arm64: dts: mt8183: Add
[PATCH] drm/panfrost: Remove core stack power management
Explict management of the GPU's core stacks is only necessary in the
case of a broken integration with the PDC. Since there are no known
platforms which have such a broken integration let's remove the explict
control from the driver since this apparently causes problems on other
platforms and will have a small performance penality.
The out of tree mali_kbase driver contains this text regarding
controlling the core stack (CONFIGMALI_CORESTACK):
Enabling this feature on supported GPUs will let the driver powering
on/off the GPU core stack independently without involving the Power
Domain Controller. This should only be enabled on platforms which
integration of the PDC to the Mali GPU is known to be problematic.
This feature is currently only supported on t-Six and t-HEx GPUs.
If unsure, say N.
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_gpu.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index 8822ec13a0d6..460fc190de6e 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
@@ -309,10 +309,6 @@ void panfrost_gpu_power_on(struct panfrost_device *pfdev)
ret = readl_relaxed_poll_timeout(pfdev->iomem + L2_READY_LO,
val, val == pfdev->features.l2_present, 100, 1000);
- gpu_write(pfdev, STACK_PWRON_LO, pfdev->features.stack_present);
- ret |= readl_relaxed_poll_timeout(pfdev->iomem + STACK_READY_LO,
- val, val == pfdev->features.stack_present, 100, 1000);
-
gpu_write(pfdev, SHADER_PWRON_LO, pfdev->features.shader_present);
ret |= readl_relaxed_poll_timeout(pfdev->iomem + SHADER_READY_LO,
val, val == pfdev->features.shader_present, 100, 1000);
@@ -329,7 +325,6 @@ void panfrost_gpu_power_off(struct panfrost_device *pfdev)
{
gpu_write(pfdev, TILER_PWROFF_LO, 0);
gpu_write(pfdev, SHADER_PWROFF_LO, 0);
- gpu_write(pfdev, STACK_PWROFF_LO, 0);
gpu_write(pfdev, L2_PWROFF_LO, 0);
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave & Daniel,
Happy New Year, now back from the holiday break.
A bunch of important fixes. Further fixes for the power/perf
regressions caused by the past security fixes. Then fix for
user reported GPU hang regression. Revert to avoid screen flicker
caused by HDA audio. Then missing two W/A and uninitialized uAPI
variable fix.
There's one further fix which I didn't include in this PR as the
CI results won't make it in time. So at least that will be in next
weeks PR.
Regards, Joonas
***
drm-intel-fixes-2020-01-09-1:
- Fix GitLab issue #446 causing GPU hangs: Do not restore invalid RS state
- Fix GitLab issue #846: Restore coarse power gating that was disabled
by initial RC66 context corruption security fixes.
- Revert f6ec9483091f ("drm/i915: extend audio CDCLK>=2*BCLK constraint to more
platforms")
to avoid screen flicker
- Fix to fill in unitialized uabi_instance in virtual engine uAPI
- Add two missing W/As for ICL and EHL
The following changes since commit c79f46a282390e0f5b306007bf7b11a46d529538:
Linux 5.5-rc5 (2020-01-05 14:23:27 -0800)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2020-01-09-1
for you to fetch changes up to 2b2c4a83d69dc9f2b46b8e791f5b8c2451c267bd:
drm/i915/dp: Disable Port sync mode correctly on teardown (2020-01-07
15:11:40 +0200)
- Fix GitLab issue #446 causing GPU hangs: Do not restore invalid RS state
- Fix GitLab issue #846: Restore coarse power gating that was disabled
by initial RC66 context corruption security fixes.
- Revert f6ec9483091f ("drm/i915: extend audio CDCLK>=2*BCLK constraint to more
platforms")
to avoid screen flicker
- Fix to fill in unitialized uabi_instance in virtual engine uAPI
- Add two missing W/As for ICL and EHL
Chris Wilson (3):
drm/i915/gt: Mark up virtual engine uabi_instance
drm/i915/gt: Do not restore invalid RS state
drm/i915/gt: Restore coarse power gating
Kai Vehmanen (1):
drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
Manasi Navare (1):
drm/i915/dp: Disable Port sync mode correctly on teardown
Matt Roper (2):
drm/i915: Add Wa_1408615072 and Wa_1407596294 to icl,ehl
drm/i915: Add Wa_1407352427:icl,ehl
drivers/gpu/drm/i915/display/intel_audio.c | 4 ++--
drivers/gpu/drm/i915/display/intel_display.c| 7 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 ++
drivers/gpu/drm/i915/gt/intel_ring_submission.c | 31 +
drivers/gpu/drm/i915/i915_drv.h | 6 +++--
drivers/gpu/drm/i915/i915_reg.h | 8 ++-
drivers/gpu/drm/i915/intel_pm.c | 11 +
7 files changed, 38 insertions(+), 31 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] drm-intel-fixes
Quoting Joonas Lahtinen (2020-01-09 15:34:58) > Hi Dave & Daniel, > > Happy New Year, now back from the holiday break. > > A bunch of important fixes. Further fixes for the power/perf > regressions caused by the past security fixes. Then fix for > user reported GPU hang regression. Revert to avoid screen flicker > caused by HDA audio. Then missing two W/A and uninitialized uAPI > variable fix. Forgot to mention: Fix for GitLab issue #5: Avoid multiple WARN_ON on 2p2c display teardown Regards, Joonas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/dp_mst: fix documentation of drm_dp_mst_add_affected_dsc_crtcs
Thank you, Reviewed-by: Mikita Lipski On 1/8/20 10:24 PM, Alex Deucher wrote: the parameter is the mst manager, not the port. Signed-off-by: Alex Deucher --- drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 7e9b9b7e50cf..a4be2f825899 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -4781,7 +4781,7 @@ drm_dp_mst_atomic_check_vcpi_alloc_limit(struct drm_dp_mst_topology_mgr *mgr, /** * drm_dp_mst_add_affected_dsc_crtcs * @state: Pointer to the new struct drm_dp_mst_topology_state - * @port: Port pointer of connector with new state + * @mgr: MST topology manager * * Whenever there is a change in mst topology * DSC configuration would have to be recalculated -- Thanks, Mikita Lipski Software Engineer, AMD mikita.lip...@amd.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND 0/1] Add support for BOE NV140FHM-N49 panel to panel-simple
Hi Tobias. We need binding schema before we can apply this patch. See patch below. Please review/ack the patch, then we can process your panel-simple patch. Sam On Thu, Jan 09, 2020 at 12:29:51PM +0100, Tobias Schramm wrote: > This patch adds support for the 14 inch BOE NV140FHM-N49 eDP panel to > the panel-simple driver. The panel is used by the Pinebook Pro. > > Resending with changed CCs due to lack of feedback. > > Tobias Schramm (1): > drm/panel: Add support for BOE NV140FHM-N49 panel to panel-simple > > drivers/gpu/drm/panel/panel-simple.c | 35 > 1 file changed, 35 insertions(+) > >From ad19c4636475bb05ba5c0b6cec2bee85045d628e Mon Sep 17 00:00:00 2001 From: Sam Ravnborg Date: Thu, 9 Jan 2020 14:48:41 +0100 Subject: [PATCH] dt-bindings: display: add BOE 14" panel Add bindings for the BOE NV140FHM-N49 14" 1920x1080 panel. The panel is used by the pine64 Pinebook Pro. Signed-off-by: Sam Ravnborg Cc: Thierry Reding Cc: Tobias Schramm --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index ddc00480b6fe..6c098a0b6e1e 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -35,6 +35,8 @@ properties: - ampire,am800480r3tmqwa1h # AUO B116XAK01 eDP TFT LCD panel - auo,b116xa01 +# BOE NV140FHM-N49 14.0" FHD a-Si FT panel + - boe,nv140fhmn49 # GiantPlus GPM940B0 3.0" QVGA TFT LCD panel - giantplus,gpm940b0 # Sharp LS020B1DD01D 2.0" HQVGA TFT LCD panel -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/7] drm/panfrost: Add support for multiple power domain support
On 08/01/2020 05:23, Nicolas Boichat wrote:
When there is a single power domain per device, the core will
ensure the power domains are all switched on.
However, when there are multiple ones, as in MT8183 Bifrost GPU,
we need to handle them in driver code.
Signed-off-by: Nicolas Boichat
---
The downstream driver we use on chromeos-4.19 currently uses 2
additional devices in device tree to accomodate for this [1], but
I believe this solution is cleaner.
I'm not sure what is best, but it seems odd to encode this into the Panfrost
driver itself - it doesn't have any knowledge of what to do with these power
domains. The naming of the domains looks suspiciously like someone thought that
e.g. only half of the cores could be powered, but it doesn't look like that was
implemented in the chromeos driver linked and anyway that is *meant* to be
automatic in the hardware! (I.e. if you only power up one cores in one core
stack then the PDC should only enable the power domain for that set of cores).
Steve
[1]
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/chromeos-4.19/drivers/gpu/arm/midgard/platform/mediatek/mali_kbase_runtime_pm.c#31
drivers/gpu/drm/panfrost/panfrost_device.c | 87 --
drivers/gpu/drm/panfrost/panfrost_device.h | 4 +
2 files changed, 83 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c
b/drivers/gpu/drm/panfrost/panfrost_device.c
index a0b0a6fef8b4e63..c6e9e059de94a4d 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#include "panfrost_device.h"
@@ -131,6 +132,67 @@ static void panfrost_regulator_fini(struct panfrost_device
*pfdev)
regulator_disable(pfdev->regulator_sram);
}
+static void panfrost_pm_domain_fini(struct panfrost_device *pfdev)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(pfdev->pm_domain_devs); i++) {
+ if (!pfdev->pm_domain_devs[i])
+ break;
+
+ if (pfdev->pm_domain_links[i])
+ device_link_del(pfdev->pm_domain_links[i]);
+
+ dev_pm_domain_detach(pfdev->pm_domain_devs[i], true);
+ }
+}
+
+static int panfrost_pm_domain_init(struct panfrost_device *pfdev)
+{
+ int err;
+ int i, num_domains;
+
+ num_domains = of_count_phandle_with_args(pfdev->dev->of_node,
+"power-domains",
+"#power-domain-cells");
+ /* Single domains are handled by the core. */
+ if (num_domains < 2)
+ return 0;
+
+ if (num_domains > ARRAY_SIZE(pfdev->pm_domain_devs)) {
+ dev_err(pfdev->dev, "Too many pm-domains: %d\n", num_domains);
+ return -EINVAL;
+ }
+
+ for (i = 0; i < num_domains; i++) {
+ pfdev->pm_domain_devs[i] =
+ dev_pm_domain_attach_by_id(pfdev->dev, i);
+ if (IS_ERR(pfdev->pm_domain_devs[i])) {
+ err = PTR_ERR(pfdev->pm_domain_devs[i]);
+ pfdev->pm_domain_devs[i] = NULL;
+ dev_err(pfdev->dev,
+ "failed to get pm-domain %d: %d\n", i, err);
+ goto err;
+ }
+
+ pfdev->pm_domain_links[i] = device_link_add(pfdev->dev,
+ pfdev->pm_domain_devs[i], DL_FLAG_PM_RUNTIME |
+ DL_FLAG_STATELESS | DL_FLAG_RPM_ACTIVE);
+ if (!pfdev->pm_domain_links[i]) {
+ dev_err(pfdev->pm_domain_devs[i],
+ "adding device link failed!\n");
+ err = -ENODEV;
+ goto err;
+ }
+ }
+
+ return 0;
+
+err:
+ panfrost_pm_domain_fini(pfdev);
+ return err;
+}
+
int panfrost_device_init(struct panfrost_device *pfdev)
{
int err;
@@ -161,37 +223,45 @@ int panfrost_device_init(struct panfrost_device *pfdev)
goto err_out1;
}
+ err = panfrost_pm_domain_init(pfdev);
+ if (err) {
+ dev_err(pfdev->dev, "pm_domain init failed %d\n", err);
+ goto err_out2;
+ }
+
res = platform_get_resource(pfdev->pdev, IORESOURCE_MEM, 0);
pfdev->iomem = devm_ioremap_resource(pfdev->dev, res);
if (IS_ERR(pfdev->iomem)) {
dev_err(pfdev->dev, "failed to ioremap iomem\n");
err = PTR_ERR(pfdev->iomem);
- goto err_out2;
+ goto err_out3;
}
err = panfrost_gpu_init(pfdev);
if (err)
- goto err_out2;
+ goto err_out3;
err = panfrost_mmu_init(pfdev);
if (err)
- goto err_out3;
+ goto err_out4;
err
Re: [PATCH v2 6/7, RFC] drm/panfrost: Add bifrost compatible string
On 08/01/2020 05:23, Nicolas Boichat wrote:
For testing only, the driver doesn't really work yet, AFAICT.
Signed-off-by: Nicolas Boichat
It does work (at least on the Hikey960), we just don't have any public user
space driver for it... ;)
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 48e3c4165247cea..f3a4d77266ba961 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -591,6 +591,7 @@ static const struct of_device_id dt_match[] = {
{ .compatible = "arm,mali-t830" },
{ .compatible = "arm,mali-t860" },
{ .compatible = "arm,mali-t880" },
+ { .compatible = "arm,mali-bifrost" },
{}
};
MODULE_DEVICE_TABLE(of, dt_match);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/7] drm/panfrost: Add support for a second regulator for the GPU
On 08/01/2020 22:52, Nicolas Boichat wrote:
On Wed, Jan 8, 2020 at 9:23 PM Mark Brown wrote:
On Wed, Jan 08, 2020 at 01:23:34PM +0800, Nicolas Boichat wrote:
Some GPUs, namely, the bifrost/g72 part on MT8183, have a second
regulator for their SRAM, let's add support for that.
+ pfdev->regulator_sram = devm_regulator_get_optional(pfdev->dev, "sram");
+ if (IS_ERR(pfdev->regulator_sram)) {
This supply is required for the devices that need it so I'd therefore
expect the driver to request the supply non-optionally based on the
compatible string rather than just hoping that a missing regulator isn't
important.
That'd be a bit awkward to match, though... Currently all bifrost
share the same compatible "arm,mali-bifrost", and it'd seem
weird/wrong to match "mediatek,mt8183-mali" in this driver? I have no
idea if any other Mali implementation will require a second regulator,
but with the MT8183 we do need it, see below.
Though I do have to wonder given the lack of any active
management of the supply if this is *really* part of the GPU or if it's
more of a SoC thing, it's not clear what exactly adding this code is
achieving.
Well if devfreq was working (see patch 7
https://patchwork.kernel.org/patch/11322851/ for a partial
implementation), it would adjust both mali and sram regulators, see
the OPP table in patch 2
(https://patchwork.kernel.org/patch/11322825/): SRAM voltage needs to
be increased for frequencies >=698Mhz.
Now if you have some better idea how to implement this, I'm all ears!
I'm not sure if it's better, but could we just encode the list of regulators into device
tree. I'm a bit worried about special casing an "sram" regulator given that
other platforms might have a similar situation but call the second regulator a different
name.
Steve
Thanks.
___
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
Re: [PATCH v8] drm/panel: Add driver for Sony ACX424AKP panel
Hi Linus. On Thu, Jan 09, 2020 at 08:28:15AM +0100, Linus Walleij wrote: > The Sony ACX424AKP is a command/videomode DSI panel for > mobile devices. It is used on the ST-Ericsson HREF520 > reference design. We support video mode by default, but > it is possible to switch the panel into command mode > by using the bool property "dsi-command-mode". > > Cc: Stephan Gerhold > Signed-off-by: Linus Walleij Applied to drm-misc-next. Thanks, Sam > --- > ChangeLog v7->v8: > - Fix some compilation problems due to the connector refactoring > that went in recently so all builds fine now. > - Add a MAINTAINERS entry for the driver. > - Convert some msleep() to usleep_range(): it's fine to sleep some > more so make this explicit. > ChangeLog v6->v7: > - Add some Kconfig help text. > - Sort includes alphabetically. > - Move the struct drm_panel first in the state container > struct since we are subclassing the panel class. > - Put an explicit /* sentinel */ text in the NULL entry > for compatible. > - Move MTP ID readout to the .prepare() callback. > - Add a verbose comment about the MDDI setting so others > understand what may be going on. > - Explain why the backlight follows the display and cannot > be turned on/off > ChangeLog v5->v6: > - Move the "set MDDI" command back to this file. It is a > local pecularity, we suspect there is a Novatek controller > inside this display. > ChangeLog v4->v5: > - Bindings were iterated separately so a jump in versioning. > - Add Stephan as reviewer. > ChangeLog v3->v4: > - No changes just resending with the new binding updates. > ChangeLog v2->v3: > - No changes just resending with the new binding updates. > ChangeLog v1->v2: > - Fix up the ID read function to split into reading header, > version and ID, store the version in the struct. > - Get rid of a surplus semicolon found by the build robot > while rewriting the above code. > - Use unsigned int in probe() loop. > - Set vrefresh to 60Hz, as good as any, the measured vrefresh > in continous command mode is ~117 Hz. > - Use a different for() idiom while retrying to read ID > 5 times. > - Drop the sync pulse setting, we are not using this, this > panel uses an event. > - Use the generic "enforce-video-mode" for video mode > enforcement. > --- > MAINTAINERS | 6 + > drivers/gpu/drm/panel/Kconfig| 11 + > drivers/gpu/drm/panel/Makefile | 1 + > drivers/gpu/drm/panel/panel-sony-acx424akp.c | 550 +++ > 4 files changed, 568 insertions(+) > create mode 100644 drivers/gpu/drm/panel/panel-sony-acx424akp.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 4118dfe61867..3d5cbbaee117 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5368,6 +5368,12 @@ S: Maintained > F: drivers/gpu/drm/tiny/st7735r.c > F: Documentation/devicetree/bindings/display/sitronix,st7735r.txt > > +DRM DRIVER FOR SONY ACX424AKP PANELS > +M: Linus Walleij > +T: git git://anongit.freedesktop.org/drm/drm-misc > +S: Maintained > +F: drivers/gpu/drm/panel/panel-sony-acx424akp.c > + > DRM DRIVER FOR ST-ERICSSON MCDE > M: Linus Walleij > T: git git://anongit.freedesktop.org/drm/drm-misc > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig > index 41f796b28dd5..ae44ac2ec106 100644 > --- a/drivers/gpu/drm/panel/Kconfig > +++ b/drivers/gpu/drm/panel/Kconfig > @@ -338,6 +338,17 @@ config DRM_PANEL_SITRONIX_ST7789V > Say Y here if you want to enable support for the Sitronix > ST7789V controller for 240x320 LCD panels > > +config DRM_PANEL_SONY_ACX424AKP > + tristate "Sony ACX424AKP DSI command mode panel" > + depends on OF > + depends on DRM_MIPI_DSI > + depends on BACKLIGHT_CLASS_DEVICE > + select VIDEOMODE_HELPERS > + help > + Say Y here if you want to enable the Sony ACX424 display > + panel. This panel supports DSI in both command and video > + mode. > + > config DRM_PANEL_SONY_ACX565AKM > tristate "Sony ACX565AKM panel" > depends on GPIOLIB && OF && SPI > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile > index 4dc7acff21b9..7c4d3c581fd4 100644 > --- a/drivers/gpu/drm/panel/Makefile > +++ b/drivers/gpu/drm/panel/Makefile > @@ -35,6 +35,7 @@ obj-$(CONFIG_DRM_PANEL_SHARP_LS037V7DW01) += > panel-sharp-ls037v7dw01.o > obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o > obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o > obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o > +obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o > obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o > obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o > obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o > diff --git a/drivers/gpu/drm/panel/panel-sony-acx424akp.c > b/drivers/gpu/drm/panel/panel-sony-ac
[PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.
If the current eDP link rate, as read from hw, provides a
higher bandwidth than the standard link rates, then add the
current link rate to the link_rates array for consideration
in future mode-sets.
These initial current eDP link settings have been set up by
firmware during boot, so they should work on the eDP panel.
Therefore use them if the firmware thinks they are good and
they provide higher link bandwidth, e.g., to enable higher
resolutions / color depths.
This fixes a problem found on the MacBookPro 2017 Retina panel:
The panel reports 10 bpc color depth in its EDID, and the UEFI
firmware chooses link settings at boot which support enough
bandwidth for 10 bpc (324000 kbit/sec to be precise), but the
DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible,
so intel_dp_set_sink_rates() would cap at that. This restricts
achievable color depth to 8 bpc, not providing the full color
depth of the panel. With this commit, we can use firmware setting
and get the full 10 bpc advertised by the Retina panel.
Signed-off-by: Mario Kleiner
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/display/intel_dp.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 2f31d226c6eb..aa3e0b5108c6 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4368,6 +4368,8 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
{
struct drm_i915_private *dev_priv =
to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
+ int max_rate;
+ u8 link_bw;
/* this function is meant to be called only once */
WARN_ON(intel_dp->dpcd[DP_DPCD_REV] != 0);
@@ -4433,6 +4435,27 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
else
intel_dp_set_sink_rates(intel_dp);
+ /*
+* If the firmware programmed a rate higher than the standard sink rates
+* during boot, then add that rate as a valid sink rate, as fw knows
+* this is a good rate and we get extra bandwidth.
+*
+* Helps, e.g., on the Apple MacBookPro 2017 Retina panel, which is only
+* eDP 1.1, but supports the unusual rate of 324000 kHz at bootup, for
+* 10 bpc / 30 bit color depth.
+*/
+ if (!intel_dp->use_rate_select &&
+ (drm_dp_dpcd_read(&intel_dp->aux, DP_LINK_BW_SET, &link_bw, 1) ==
1) &&
+ (link_bw > 0) && (intel_dp->num_sink_rates <
DP_MAX_SUPPORTED_RATES)) {
+ max_rate = drm_dp_bw_code_to_link_rate(link_bw);
+ if (max_rate > intel_dp->sink_rates[intel_dp->num_sink_rates -
1]) {
+ intel_dp->sink_rates[intel_dp->num_sink_rates] =
max_rate;
+ intel_dp->num_sink_rates++;
+ DRM_DEBUG_KMS("Adding max bandwidth eDP rate %d kHz.\n",
+ max_rate);
+ }
+ }
+
intel_dp_set_common_rates(intel_dp);
/* Read the eDP DSC DPCD registers */
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression in 5.4 kernel on 32-bit Radeon IBM T40
Hi Christoph, Am 09.01.20 um 15:14 schrieb Christoph Hellwig: Hi Woody, sorry for the late reply, I've been off to a vacation over the holidays. On Sat, Dec 14, 2019 at 10:17:15PM -0500, Woody Suwalski wrote: Regression in 5.4 kernel on 32-bit Radeon IBM T40 triggered by commit 33b3ad3788aba846fc8b9a065fe2685a0b64f713 Author: Christoph Hellwig Date: Thu Aug 15 09:27:00 2019 +0200 Howdy, The above patch has triggered a display problem on IBM Thinkpad T40, where the screen is covered with a lots of random short black horizontal lines, or distorted letters in X terms. The culprit seems to be that the dma_get_required_mask() is returning a value 0x3fff which is smaller than dma_get_mask()0x.That results in dma_addressing_limited()==0 in ttm_bo_device(), and using 40-bits dma instead of 32-bits. Which is the intended behavior assuming your system has 1GB of memory. Does it? Assuming the system doesn't have the 1GB split up somehow crazy over the address space that should indeed work as intended. If I hardcode "1" as the last parameter to ttm_bo_device_init() in place of a call to dma_addressing_limited(),the problem goes away. I'll need some help from the drm / radeon / TTM maintainers if there are any other side effects from not passing the need_dma32 paramters. Obviously if the device doesn't have more than 32-bits worth of dram and no DMA offset we can't feed unaddressable memory to the device. Unfortunately I have a very hard time following the implementation of the TTM pool if it does anything else in this case. The only other thing which comes to mind is using huge pages. Can you try a kernel with CONFIG_TRANSPARENT_HUGEPAGE disabled? Thanks, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] xf86drm: only include for FreeBSD build case
On Thu, 09 Jan 2020, Seung-Woo Kim wrote: > The header is only required FreeBSD and GNU libc > 2.30 starts to warn about Linux specific header > deprecation. Only include for FreeBSD. > > Signed-off-by: Seung-Woo Kim > --- > xf86drmMode.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/xf86drmMode.c b/xf86drmMode.c > index 207d7be..ff1d31d 100644 > --- a/xf86drmMode.c > +++ b/xf86drmMode.c > @@ -42,9 +42,11 @@ > #include > #include > #include > +#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__) > #ifdef HAVE_SYS_SYSCTL_H Not that I know anything about this, but shouldn't you instead fix HAVE_SYS_SYSCTL_H definition in configure stage to only be enabled on FreeBSD? BR, Jani. > #include > #endif > +#endif /* defined (__FreeBSD__) || defined (__FreeBSD_kernel__) */ > #include > #include -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/amd/display: Reorder detect_edp_sink_caps before link settings read.
read_current_link_settings_on_detect() on eDP 1.4+ may use the
edp_supported_link_rates table which is set up by
detect_edp_sink_caps(), so that function needs to be called first.
Signed-off-by: Mario Kleiner
Cc: Martin Leung
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index cef8c1ba9797..5ea4a1675259 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -817,8 +817,8 @@ static bool dc_link_detect_helper(struct dc_link *link,
}
case SIGNAL_TYPE_EDP: {
- read_current_link_settings_on_detect(link);
detect_edp_sink_caps(link);
+ read_current_link_settings_on_detect(link);
sink_caps.transaction_type =
DDC_TRANSACTION_TYPE_I2C_OVER_AUX;
sink_caps.signal = SIGNAL_TYPE_EDP;
break;
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/amd/display: Allow current eDP link settings to override verified ones.
If the current eDP link settings, as read from hw, provide a higher
bandwidth than the verified_link_cap ones (= reported_link_cap), then
override verified_link_cap with current settings.
These initial current eDP link settings have been set up by
firmware during boot, so they should work on the eDP panel.
Therefore use them if the firmware thinks they are good and
they provide higher link bandwidth, e.g., to enable higher
resolutions / color depths.
This fixes a problem found on the MacBookPro 2017 Retina panel:
The panel reports 10 bpc color depth in its EDID, and the
firmware chooses link settings at boot which support enough
bandwidth for 10 bpc (324000 kbit/sec aka LINK_RATE_RBR2),
but the DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps
as possible, so verified_link_cap is only good for 2.7 Gbps
and 8 bpc, not providing the full color depth of the panel.
Signed-off-by: Mario Kleiner
Cc: Alex Deucher
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 21 +++
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 5ea4a1675259..f3acdb8fead5 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -819,6 +819,27 @@ static bool dc_link_detect_helper(struct dc_link *link,
case SIGNAL_TYPE_EDP: {
detect_edp_sink_caps(link);
read_current_link_settings_on_detect(link);
+
+ /* If cur_link_settings provides higher bandwidth than
+* verified_link_cap, then use cur_link_settings as new
+* verified_link_cap, as it obviously works according to
+* firmware boot setup.
+*
+* This has been observed on the Apple MacBookPro 2017
+* Retina panel, which boots with a link setting higher
+* than what dpcd[DP_MAX_LINK_RATE] claims as possible.
+* Overriding allows to run the panel at 10 bpc / 30
bit.
+*/
+ if (dc_link_bandwidth_kbps(link,
&link->cur_link_settings) >
+ dc_link_bandwidth_kbps(link,
&link->verified_link_cap)) {
+ DC_LOG_DETECTION_DP_CAPS(
+ "eDP current link setting bw %d kbps >
verified_link_cap %d kbps. Override.",
+ dc_link_bandwidth_kbps(link,
&link->cur_link_settings),
+ dc_link_bandwidth_kbps(link,
&link->verified_link_cap));
+
+ link->verified_link_cap =
link->cur_link_settings;
+ }
+
sink_caps.transaction_type =
DDC_TRANSACTION_TYPE_I2C_OVER_AUX;
sink_caps.signal = SIGNAL_TYPE_EDP;
break;
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Some eDP fixes/improvements.
Hi and happy new year! Since i now have a MBP 2017 to play with, with a 10 bit Retina panel, and Polaris gpu, i'm trying to get it to get 10 bits, and found one small bug [fix: patch1], and a quirk of Apples Retina eDP sink, for which i propose patch2 as solution. I sent a similar patch to i915 to make 10 bit Retina work with the Intel Kabylake igp on that machine. If these make sense, it would be cool to still get them into drm-fixes for Linux 5.5, so users of spring distro updates like Ubuntu 20.04 LTS can get a more colorful new year. thanks, -mario ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/dp: Add function to parse EDID descriptors for adaptive sync limits
On Tue, 07 Jan 2020, Manasi Navare wrote:
> Adaptive Sync is a VESA feature so add a DRM core helper to parse
> the EDID's detailed descritors to obtain the adaptive sync monitor range.
> Store this info as part fo drm_display_info so it can be used
> across all drivers.
> This part of the code is stripped out of amdgpu's function
> amdgpu_dm_update_freesync_caps() to make it generic and be used
> across all DRM drivers
>
> v2:
> * Change vmin and vmax to use u8 (Ville)
> * Dont store pixel clock since that is just a max dotclock
> and not related to VRR mode (Manasi)
>
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Clinton A Taylor
> Cc: Nicholas Kazlauskas
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/drm_edid.c | 51 +
> include/drm/drm_connector.h | 22
> include/drm/drm_edid.h | 2 ++
> 3 files changed, 75 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 99769d6c9f84..52781a0e708b 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4880,6 +4880,54 @@ static void drm_parse_cea_ext(struct drm_connector
> *connector,
> }
> }
>
> +void drm_get_adaptive_sync_limits(struct drm_connector *connector,
> + const struct edid *edid)
> +{
> + struct drm_display_info *info = &connector->display_info;
> + const struct detailed_timing *timing;
> + const struct detailed_non_pixel *data;
> + const struct detailed_data_monitor_range *range;
> + int i;
> +
> + /*
> + * Restrict Adaptive Sync only for dp and edp
> + */
> + if (connector->connector_type != DRM_MODE_CONNECTOR_DisplayPort &&
> + connector->connector_type != DRM_MODE_CONNECTOR_eDP)
> + return;
> +
> + if (edid->version <= 1 && !(edid->version == 1 && edid->revision > 1))
> + return;
> +
> + for (i = 0; i < 4; i++) {
> + timing = &edid->detailed_timings[i];
> + data= &timing->data.other_data;
> + range = &data->data.range;
> + /*
> + * Check if monitor has continuous frequency mode
> + */
> + if (data->type != EDID_DETAIL_MONITOR_RANGE)
> + continue;
> + /*
> + * Check for flag range limits only. If flag == 1 then
> + * no additional timing information provided.
> + * Default GTF, GTF Secondary curve and CVT are not
> + * supported
> + */
> + if (range->flags != 1)
> + continue;
> +
> + info->adaptive_sync.min_vfreq = range->min_vfreq;
> + info->adaptive_sync.max_vfreq = range->max_vfreq;
> +
> + DRM_DEBUG_KMS("Adaptive Sync refresh rate range is %d Hz - %d
> Hz\n",
> + info->adaptive_sync.min_vfreq,
> + info->adaptive_sync.max_vfreq);
> + break;
> + }
> +}
> +EXPORT_SYMBOL(drm_get_adaptive_sync_limits);
Why the export? Rather, why is this not static?
BR,
Jani.
> +
> /* A connector has no EDID information, so we've got no EDID to compute
> quirks from. Reset
> * all of the values which would have been set from EDID
> */
> @@ -4901,6 +4949,7 @@ drm_reset_display_info(struct drm_connector *connector)
> memset(&info->hdmi, 0, sizeof(info->hdmi));
>
> info->non_desktop = 0;
> + memset(&info->adaptive_sync, 0, sizeof(info->adaptive_sync));
> }
>
> u32 drm_add_display_info(struct drm_connector *connector, const struct edid
> *edid)
> @@ -4916,6 +4965,8 @@ u32 drm_add_display_info(struct drm_connector
> *connector, const struct edid *edi
>
> info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
>
> + drm_get_adaptive_sync_limits(connector, edid);
> +
> DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);
>
> if (edid->revision < 3)
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 221910948b37..77df404a2e01 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -254,6 +254,23 @@ enum drm_panel_orientation {
> DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
> };
>
> +/**
> + * struct drm_adaptive_sync_info - Panel's Adaptive Sync capabilities for
> + * &drm_display_info
> + *
> + * This struct is used to store a Panel's Adaptive Sync capabilities
> + * as parsed from EDID's detailed monitor range descriptor block.
> + *
> + * @min_vfreq: This is the min supported refresh rate in Hz from
> + * EDID's detailed monitor range.
> + * @max_vfreq: This is the max supported refresh rate in Hz from
> + * EDID's detailed monitor range
> + */
> +struct drm_adaptive_sync_info {
> + u8 min_vfreq;
> + u8 max_vfreq;
> +};
> +
> /*
> * This is a consolidated colorimetry list supported by HDMI and
> * DP protocol standard. The respect
Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.
On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> If the current eDP link rate, as read from hw, provides a
> higher bandwidth than the standard link rates, then add the
> current link rate to the link_rates array for consideration
> in future mode-sets.
>
> These initial current eDP link settings have been set up by
> firmware during boot, so they should work on the eDP panel.
> Therefore use them if the firmware thinks they are good and
> they provide higher link bandwidth, e.g., to enable higher
> resolutions / color depths.
>
> This fixes a problem found on the MacBookPro 2017 Retina panel:
>
> The panel reports 10 bpc color depth in its EDID, and the UEFI
> firmware chooses link settings at boot which support enough
> bandwidth for 10 bpc (324000 kbit/sec to be precise), but the
> DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible,
> so intel_dp_set_sink_rates() would cap at that. This restricts
> achievable color depth to 8 bpc, not providing the full color
> depth of the panel. With this commit, we can use firmware setting
> and get the full 10 bpc advertised by the Retina panel.
>
> Signed-off-by: Mario Kleiner
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 2f31d226c6eb..aa3e0b5108c6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4368,6 +4368,8 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> {
> struct drm_i915_private *dev_priv =
> to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
> + int max_rate;
> + u8 link_bw;
>
> /* this function is meant to be called only once */
> WARN_ON(intel_dp->dpcd[DP_DPCD_REV] != 0);
> @@ -4433,6 +4435,27 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> else
> intel_dp_set_sink_rates(intel_dp);
>
> + /*
> + * If the firmware programmed a rate higher than the standard sink rates
> + * during boot, then add that rate as a valid sink rate, as fw knows
> + * this is a good rate and we get extra bandwidth.
> + *
> + * Helps, e.g., on the Apple MacBookPro 2017 Retina panel, which is only
> + * eDP 1.1, but supports the unusual rate of 324000 kHz at bootup, for
> + * 10 bpc / 30 bit color depth.
> + */
> + if (!intel_dp->use_rate_select &&
> + (drm_dp_dpcd_read(&intel_dp->aux, DP_LINK_BW_SET, &link_bw, 1) ==
> 1) &&
> + (link_bw > 0) && (intel_dp->num_sink_rates <
> DP_MAX_SUPPORTED_RATES)) {
> + max_rate = drm_dp_bw_code_to_link_rate(link_bw);
> + if (max_rate > intel_dp->sink_rates[intel_dp->num_sink_rates -
> 1]) {
> + intel_dp->sink_rates[intel_dp->num_sink_rates] =
> max_rate;
> + intel_dp->num_sink_rates++;
> + DRM_DEBUG_KMS("Adding max bandwidth eDP rate %d kHz.\n",
> + max_rate);
> + }
Hmm. I guess we could do this. But plese put it into a separate
function so we don't end up with that super ugly if condition.
The debug message should probably be a bit more explicit. Eg.
something like:
"Firmware using non-standard link rate %d kHz. Including it in sink rates.\n"
I'm also wondering if we shouldn't just add the link rate to the sink
rates regradless of whether it's the highest rate or not...
> + }
> +
> intel_dp_set_common_rates(intel_dp);
>
> /* Read the eDP DSC DPCD registers */
> --
> 2.24.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND 0/1] Add support for BOE NV140FHM-N49 panel to panel-simple
Hi Tobias. We need binding schema before we can apply this patch. Knew I forgot something See patch below. Please review/ack the patch, then we can process your panel-simple patch. LGTM, thanks! Sam On Thu, Jan 09, 2020 at 12:29:51PM +0100, Tobias Schramm wrote: This patch adds support for the 14 inch BOE NV140FHM-N49 eDP panel to the panel-simple driver. The panel is used by the Pinebook Pro. Resending with changed CCs due to lack of feedback. Tobias Schramm (1): drm/panel: Add support for BOE NV140FHM-N49 panel to panel-simple drivers/gpu/drm/panel/panel-simple.c | 35 1 file changed, 35 insertions(+) From ad19c4636475bb05ba5c0b6cec2bee85045d628e Mon Sep 17 00:00:00 2001 From: Sam Ravnborg Date: Thu, 9 Jan 2020 14:48:41 +0100 Subject: [PATCH] dt-bindings: display: add BOE 14" panel Add bindings for the BOE NV140FHM-N49 14" 1920x1080 panel. The panel is used by the pine64 Pinebook Pro. Signed-off-by: Sam Ravnborg Cc: Thierry Reding Cc: Tobias Schramm --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index ddc00480b6fe..6c098a0b6e1e 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -35,6 +35,8 @@ properties: - ampire,am800480r3tmqwa1h # AUO B116XAK01 eDP TFT LCD panel - auo,b116xa01 +# BOE NV140FHM-N49 14.0" FHD a-Si FT panel + - boe,nv140fhmn49 # GiantPlus GPM940B0 3.0" QVGA TFT LCD panel - giantplus,gpm940b0 # Sharp LS020B1DD01D 2.0" HQVGA TFT LCD panel Reviewed-by: Tobias Schramm ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.
On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > If the current eDP link rate, as read from hw, provides a
> > higher bandwidth than the standard link rates, then add the
> > current link rate to the link_rates array for consideration
> > in future mode-sets.
> >
> > These initial current eDP link settings have been set up by
> > firmware during boot, so they should work on the eDP panel.
> > Therefore use them if the firmware thinks they are good and
> > they provide higher link bandwidth, e.g., to enable higher
> > resolutions / color depths.
> >
> > This fixes a problem found on the MacBookPro 2017 Retina panel:
> >
> > The panel reports 10 bpc color depth in its EDID, and the UEFI
> > firmware chooses link settings at boot which support enough
> > bandwidth for 10 bpc (324000 kbit/sec to be precise), but the
> > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible,
Does it actually or do we just ignore the fact that it reports 3.24Gbps?
If it really reports 3.24 then we should be able to just add that to
dp_rates[] in intel_dp_set_sink_rates() and be done with it.
Although we'd likely want to skip 3.24 unless it really is reported
as the max so as to not use that non-standard rate on other displays.
So would require a bit fancier logic for that.
> > so intel_dp_set_sink_rates() would cap at that. This restricts
> > achievable color depth to 8 bpc, not providing the full color
> > depth of the panel. With this commit, we can use firmware setting
> > and get the full 10 bpc advertised by the Retina panel.
> >
> > Signed-off-by: Mario Kleiner
> > Cc: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 23 +++
> > 1 file changed, 23 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 2f31d226c6eb..aa3e0b5108c6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4368,6 +4368,8 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > {
> > struct drm_i915_private *dev_priv =
> > to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
> > + int max_rate;
> > + u8 link_bw;
> >
> > /* this function is meant to be called only once */
> > WARN_ON(intel_dp->dpcd[DP_DPCD_REV] != 0);
> > @@ -4433,6 +4435,27 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > else
> > intel_dp_set_sink_rates(intel_dp);
> >
> > + /*
> > +* If the firmware programmed a rate higher than the standard sink rates
> > +* during boot, then add that rate as a valid sink rate, as fw knows
> > +* this is a good rate and we get extra bandwidth.
> > +*
> > +* Helps, e.g., on the Apple MacBookPro 2017 Retina panel, which is only
> > +* eDP 1.1, but supports the unusual rate of 324000 kHz at bootup, for
> > +* 10 bpc / 30 bit color depth.
> > +*/
> > + if (!intel_dp->use_rate_select &&
> > + (drm_dp_dpcd_read(&intel_dp->aux, DP_LINK_BW_SET, &link_bw, 1) ==
> > 1) &&
> > + (link_bw > 0) && (intel_dp->num_sink_rates <
> > DP_MAX_SUPPORTED_RATES)) {
> > + max_rate = drm_dp_bw_code_to_link_rate(link_bw);
> > + if (max_rate > intel_dp->sink_rates[intel_dp->num_sink_rates -
> > 1]) {
> > + intel_dp->sink_rates[intel_dp->num_sink_rates] =
> > max_rate;
> > + intel_dp->num_sink_rates++;
> > + DRM_DEBUG_KMS("Adding max bandwidth eDP rate %d kHz.\n",
> > + max_rate);
> > + }
>
> Hmm. I guess we could do this. But plese put it into a separate
> function so we don't end up with that super ugly if condition.
>
> The debug message should probably be a bit more explicit. Eg.
> something like:
> "Firmware using non-standard link rate %d kHz. Including it in sink rates.\n"
>
> I'm also wondering if we shouldn't just add the link rate to the sink
> rates regradless of whether it's the highest rate or not...
>
> > + }
> > +
> > intel_dp_set_common_rates(intel_dp);
> >
> > /* Read the eDP DSC DPCD registers */
> > --
> > 2.24.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.
On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
wrote:
>
> If the current eDP link rate, as read from hw, provides a
> higher bandwidth than the standard link rates, then add the
> current link rate to the link_rates array for consideration
> in future mode-sets.
>
> These initial current eDP link settings have been set up by
> firmware during boot, so they should work on the eDP panel.
> Therefore use them if the firmware thinks they are good and
> they provide higher link bandwidth, e.g., to enable higher
> resolutions / color depths.
>
> This fixes a problem found on the MacBookPro 2017 Retina panel:
>
> The panel reports 10 bpc color depth in its EDID, and the UEFI
> firmware chooses link settings at boot which support enough
> bandwidth for 10 bpc (324000 kbit/sec to be precise), but the
> DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible,
> so intel_dp_set_sink_rates() would cap at that. This restricts
> achievable color depth to 8 bpc, not providing the full color
> depth of the panel. With this commit, we can use firmware setting
> and get the full 10 bpc advertised by the Retina panel.
Would it make more sense to just add a quirk for this particular
panel? Would there be cases where the link was programmed wrong and
then we end up using that additional link speed as supported?
Alex
>
> Signed-off-by: Mario Kleiner
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 2f31d226c6eb..aa3e0b5108c6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4368,6 +4368,8 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> {
> struct drm_i915_private *dev_priv =
> to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
> + int max_rate;
> + u8 link_bw;
>
> /* this function is meant to be called only once */
> WARN_ON(intel_dp->dpcd[DP_DPCD_REV] != 0);
> @@ -4433,6 +4435,27 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> else
> intel_dp_set_sink_rates(intel_dp);
>
> + /*
> +* If the firmware programmed a rate higher than the standard sink
> rates
> +* during boot, then add that rate as a valid sink rate, as fw knows
> +* this is a good rate and we get extra bandwidth.
> +*
> +* Helps, e.g., on the Apple MacBookPro 2017 Retina panel, which is
> only
> +* eDP 1.1, but supports the unusual rate of 324000 kHz at bootup, for
> +* 10 bpc / 30 bit color depth.
> +*/
> + if (!intel_dp->use_rate_select &&
> + (drm_dp_dpcd_read(&intel_dp->aux, DP_LINK_BW_SET, &link_bw, 1) ==
> 1) &&
> + (link_bw > 0) && (intel_dp->num_sink_rates <
> DP_MAX_SUPPORTED_RATES)) {
> + max_rate = drm_dp_bw_code_to_link_rate(link_bw);
> + if (max_rate > intel_dp->sink_rates[intel_dp->num_sink_rates
> - 1]) {
> + intel_dp->sink_rates[intel_dp->num_sink_rates] =
> max_rate;
> + intel_dp->num_sink_rates++;
> + DRM_DEBUG_KMS("Adding max bandwidth eDP rate %d
> kHz.\n",
> + max_rate);
> + }
> + }
> +
> intel_dp_set_common_rates(intel_dp);
>
> /* Read the eDP DSC DPCD registers */
> --
> 2.24.0
>
> ___
> 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
Re: [RESEND 1/1] drm/panel: Add support for BOE NV140FHM-N49 panel to panel-simple
Hi Tobias.
On Thu, Jan 09, 2020 at 12:29:52PM +0100, Tobias Schramm wrote:
> This patch adds support for the BOE NV140FHM-N49 panel to the panel-simple
> driver. The panel is used by the pine64 Pinebook Pro.
>
> Signed-off-by: Tobias Schramm
Applied to drm-misc-next togher with the bindings patch.
Thanks for the quick r-b.
Sam
> ---
> drivers/gpu/drm/panel/panel-simple.c | 35
> 1 file changed, 35 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 5d487686d25c..6320df9765f3 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1036,6 +1036,38 @@ static const struct panel_desc boe_nv101wxmn51 = {
> },
> };
>
> +static const struct drm_display_mode boe_nv140fhmn49_modes[] = {
> + {
> + .clock = 148500,
> + .hdisplay = 1920,
> + .hsync_start = 1920 + 48,
> + .hsync_end = 1920 + 48 + 32,
> + .htotal = 2200,
> + .vdisplay = 1080,
> + .vsync_start = 1080 + 3,
> + .vsync_end = 1080 + 3 + 5,
> + .vtotal = 1125,
> + .vrefresh = 60,
> + },
> +};
> +
> +static const struct panel_desc boe_nv140fhmn49 = {
> + .modes = boe_nv140fhmn49_modes,
> + .num_modes = ARRAY_SIZE(boe_nv140fhmn49_modes),
> + .bpc = 6,
> + .size = {
> + .width = 309,
> + .height = 174,
> + },
> + .delay = {
> + .prepare = 210,
> + .enable = 50,
> + .unprepare = 160,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> + .connector_type = DRM_MODE_CONNECTOR_eDP,
> +};
> +
> static const struct drm_display_mode cdtech_s043wq26h_ct7_mode = {
> .clock = 9000,
> .hdisplay = 480,
> @@ -3161,6 +3193,9 @@ static const struct of_device_id platform_of_match[] = {
> }, {
> .compatible = "boe,nv101wxmn51",
> .data = &boe_nv101wxmn51,
> + }, {
> + .compatible = "boe,nv140fhmn49",
> + .data = &boe_nv140fhmn49,
> }, {
> .compatible = "cdtech,s043wq26h-ct7",
> .data = &cdtech_s043wq26h_ct7,
> --
> 2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.
On Thu, Jan 9, 2020 at 4:27 PM Ville Syrjälä
wrote:
> On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > If the current eDP link rate, as read from hw, provides a
> > higher bandwidth than the standard link rates, then add the
> > current link rate to the link_rates array for consideration
> > in future mode-sets.
> >
> > These initial current eDP link settings have been set up by
> > firmware during boot, so they should work on the eDP panel.
> > Therefore use them if the firmware thinks they are good and
> > they provide higher link bandwidth, e.g., to enable higher
> > resolutions / color depths.
> >
> > This fixes a problem found on the MacBookPro 2017 Retina panel:
> >
> > The panel reports 10 bpc color depth in its EDID, and the UEFI
> > firmware chooses link settings at boot which support enough
> > bandwidth for 10 bpc (324000 kbit/sec to be precise), but the
> > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible,
> > so intel_dp_set_sink_rates() would cap at that. This restricts
> > achievable color depth to 8 bpc, not providing the full color
> > depth of the panel. With this commit, we can use firmware setting
> > and get the full 10 bpc advertised by the Retina panel.
> >
> > Signed-off-by: Mario Kleiner
> > Cc: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 23 +++
> > 1 file changed, 23 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 2f31d226c6eb..aa3e0b5108c6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4368,6 +4368,8 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > {
> > struct drm_i915_private *dev_priv =
> > to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
> > + int max_rate;
> > + u8 link_bw;
> >
> > /* this function is meant to be called only once */
> > WARN_ON(intel_dp->dpcd[DP_DPCD_REV] != 0);
> > @@ -4433,6 +4435,27 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > else
> > intel_dp_set_sink_rates(intel_dp);
> >
> > + /*
> > + * If the firmware programmed a rate higher than the standard sink
> rates
> > + * during boot, then add that rate as a valid sink rate, as fw
> knows
> > + * this is a good rate and we get extra bandwidth.
> > + *
> > + * Helps, e.g., on the Apple MacBookPro 2017 Retina panel, which
> is only
> > + * eDP 1.1, but supports the unusual rate of 324000 kHz at bootup,
> for
> > + * 10 bpc / 30 bit color depth.
> > + */
> > + if (!intel_dp->use_rate_select &&
> > + (drm_dp_dpcd_read(&intel_dp->aux, DP_LINK_BW_SET, &link_bw, 1)
> == 1) &&
> > + (link_bw > 0) && (intel_dp->num_sink_rates <
> DP_MAX_SUPPORTED_RATES)) {
> > + max_rate = drm_dp_bw_code_to_link_rate(link_bw);
> > + if (max_rate >
> intel_dp->sink_rates[intel_dp->num_sink_rates - 1]) {
> > + intel_dp->sink_rates[intel_dp->num_sink_rates] =
> max_rate;
> > + intel_dp->num_sink_rates++;
> > + DRM_DEBUG_KMS("Adding max bandwidth eDP rate %d
> kHz.\n",
> > + max_rate);
> > + }
>
> Hmm. I guess we could do this. But plese put it into a separate
> function so we don't end up with that super ugly if condition.
>
>
Ok. Does static void intel_edp_add_bootup_rate() good to you? Or
intel_edp_add_fw_rate()?
The debug message should probably be a bit more explicit. Eg.
> something like:
> "Firmware using non-standard link rate %d kHz. Including it in sink
> rates.\n"
>
Ok.
> I'm also wondering if we shouldn't just add the link rate to the sink
> rates regradless of whether it's the highest rate or not...
>
>
I tried to be conservative, and simple, but yes, one could add it anyway.
Would need to preserve the order in the sink_rates[] array.
Your choice, your're the expert :)
> > + }
> > +
> > intel_dp_set_common_rates(intel_dp);
> >
> > /* Read the eDP DSC DPCD registers */
> > --
> > 2.24.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/7] drm/panfrost: Add support for a second regulator for the GPU
On Thu, Jan 09, 2020 at 02:14:42PM +, Steven Price wrote: > On 08/01/2020 22:52, Nicolas Boichat wrote: > > That'd be a bit awkward to match, though... Currently all bifrost > > share the same compatible "arm,mali-bifrost", and it'd seem > > weird/wrong to match "mediatek,mt8183-mali" in this driver? I have no > > idea if any other Mali implementation will require a second regulator, > > but with the MT8183 we do need it, see below. This doesn't sound particularly hard, just new. Plenty of other devices have quirks done based on the SoC they're in or the IP revision, this would just be another of those quirks. > > Well if devfreq was working (see patch 7 > > https://patchwork.kernel.org/patch/11322851/ for a partial > > implementation), it would adjust both mali and sram regulators, see > > the OPP table in patch 2 > > (https://patchwork.kernel.org/patch/11322825/): SRAM voltage needs to > > be increased for frequencies >=698Mhz. > > Now if you have some better idea how to implement this, I'm all ears! Set a flag based on the compatible, then base runtime decisions off that. > I'm not sure if it's better, but could we just encode the list of > regulators into device tree. I'm a bit worried about special casing an > "sram" regulator given that other platforms might have a similar > situation but call the second regulator a different name. Obviously the list of regulators bound on a given platform is encoded in the device tree but you shouldn't really be relying on that to figure out what to request in the driver - the driver should know what it's expecting. Bear in mind that getting regulator stuff wrong can result in physical damage to the system so it pays to be careful and to consider that platform integrators have a tendency to rely on things that just happen to work but aren't a good idea or accurate representations of the system. It's certainly *possible* to do something like that, the information is there, but I would not in any way recommend doing things that way as it's likely to not be robust. The possibility that the regulator setup may vary on other platforms (which I'd expect TBH) does suggest that just requesting a bunch of supply names optionally and hoping that we got all the ones that are important on a given platform is going to lead to trouble down the line. Steve, please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.
On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä wrote: > On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote: > > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote: > > > The panel reports 10 bpc color depth in its EDID, and the UEFI > > > firmware chooses link settings at boot which support enough > > > bandwidth for 10 bpc (324000 kbit/sec to be precise), but the > > > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible, > > Does it actually or do we just ignore the fact that it reports 3.24Gbps? > > If it really reports 3.24 then we should be able to just add that to > dp_rates[] in intel_dp_set_sink_rates() and be done with it. > > Although we'd likely want to skip 3.24 unless it really is reported > as the max so as to not use that non-standard rate on other displays. > So would require a bit fancier logic for that. > > Was also my initial thought, but the DP_MAX_LINK_RATE reg reports 2.7 Gbps as maximum. -mario ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.
On Thu, Jan 09, 2020 at 05:38:15PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > > If the current eDP link rate, as read from hw, provides a
> > > higher bandwidth than the standard link rates, then add the
> > > current link rate to the link_rates array for consideration
> > > in future mode-sets.
> > >
> > > These initial current eDP link settings have been set up by
> > > firmware during boot, so they should work on the eDP panel.
> > > Therefore use them if the firmware thinks they are good and
> > > they provide higher link bandwidth, e.g., to enable higher
> > > resolutions / color depths.
> > >
> > > This fixes a problem found on the MacBookPro 2017 Retina panel:
> > >
> > > The panel reports 10 bpc color depth in its EDID, and the UEFI
> > > firmware chooses link settings at boot which support enough
> > > bandwidth for 10 bpc (324000 kbit/sec to be precise), but the
> > > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible,
>
> Does it actually or do we just ignore the fact that it reports 3.24Gbps?
>
> If it really reports 3.24 then we should be able to just add that to
> dp_rates[] in intel_dp_set_sink_rates() and be done with it.
>
> Although we'd likely want to skip 3.24 unless it really is reported
> as the max so as to not use that non-standard rate on other displays.
> So would require a bit fancier logic for that.
Maybe just something like this?
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -177,6 +177,12 @@ static void intel_dp_set_sink_rates(struct intel_dp
*intel_dp)
intel_dp->sink_rates[i] = dp_rates[i];
}
+ /* blah */
+ if (max_rate > intel_dp->sink_rates[i - 1]) {
+ DRM_DEBUG_KMS(...);
+ intel_dp->sink_rates[i++] = max_rate;
+ }
+
intel_dp->num_sink_rates = i;
>
> > > so intel_dp_set_sink_rates() would cap at that. This restricts
> > > achievable color depth to 8 bpc, not providing the full color
> > > depth of the panel. With this commit, we can use firmware setting
> > > and get the full 10 bpc advertised by the Retina panel.
> > >
> > > Signed-off-by: Mario Kleiner
> > > Cc: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp.c | 23 +++
> > > 1 file changed, 23 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 2f31d226c6eb..aa3e0b5108c6 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -4368,6 +4368,8 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > > {
> > > struct drm_i915_private *dev_priv =
> > > to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
> > > + int max_rate;
> > > + u8 link_bw;
> > >
> > > /* this function is meant to be called only once */
> > > WARN_ON(intel_dp->dpcd[DP_DPCD_REV] != 0);
> > > @@ -4433,6 +4435,27 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > > else
> > > intel_dp_set_sink_rates(intel_dp);
> > >
> > > + /*
> > > + * If the firmware programmed a rate higher than the standard sink rates
> > > + * during boot, then add that rate as a valid sink rate, as fw knows
> > > + * this is a good rate and we get extra bandwidth.
> > > + *
> > > + * Helps, e.g., on the Apple MacBookPro 2017 Retina panel, which is only
> > > + * eDP 1.1, but supports the unusual rate of 324000 kHz at bootup, for
> > > + * 10 bpc / 30 bit color depth.
> > > + */
> > > + if (!intel_dp->use_rate_select &&
> > > + (drm_dp_dpcd_read(&intel_dp->aux, DP_LINK_BW_SET, &link_bw, 1) ==
> > > 1) &&
> > > + (link_bw > 0) && (intel_dp->num_sink_rates <
> > > DP_MAX_SUPPORTED_RATES)) {
> > > + max_rate = drm_dp_bw_code_to_link_rate(link_bw);
> > > + if (max_rate > intel_dp->sink_rates[intel_dp->num_sink_rates -
> > > 1]) {
> > > + intel_dp->sink_rates[intel_dp->num_sink_rates] =
> > > max_rate;
> > > + intel_dp->num_sink_rates++;
> > > + DRM_DEBUG_KMS("Adding max bandwidth eDP rate %d kHz.\n",
> > > + max_rate);
> > > + }
> >
> > Hmm. I guess we could do this. But plese put it into a separate
> > function so we don't end up with that super ugly if condition.
> >
> > The debug message should probably be a bit more explicit. Eg.
> > something like:
> > "Firmware using non-standard link rate %d kHz. Including it in sink
> > rates.\n"
> >
> > I'm also wondering if we shouldn't just add the link rate to the sink
> > rates regradless of whether it's the highest rate or not...
> >
> > > + }
> > > +
> > > intel_dp_set_common_rates(intel_dp);
> > >
> > > /* Read the eDP DSC DPCD registers */
> > > --
> > > 2.24.0
> > >
> > > __
Re: [PATCH] drm/fb-cma-helpers: Fix include issue
Le jeu. 9 janv. 2020 à 17:29, Benjamin GAIGNARD a écrit : > > > On 12/3/19 5:49 PM, Benjamin Gaignard wrote: > > Le mer. 20 nov. 2019 à 00:28, Benjamin Gaignard > > a écrit : > >> Exported functions prototypes are missing in drm_fb_cma_helper.c > >> Include drm_fb_cma_helper to fix that issue. > >> > > Gentle ping to reviewers. > > Thanks, > > Benjamin > > I know that removing warnings is not a sexy task, but reviewers are welcome. Applied on drm-misc-next, with Thomas ack even if dri patchwork doesn't show it. Thanks Benjamin > > Thanks, > > Benjamin > > > > >> Signed-off-by: Benjamin Gaignard > >> --- > >> drivers/gpu/drm/drm_fb_cma_helper.c | 1 + > >> include/drm/drm_fb_cma_helper.h | 2 ++ > >> 2 files changed, 3 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c > >> b/drivers/gpu/drm/drm_fb_cma_helper.c > >> index c0b0f603af63..9801c0333eca 100644 > >> --- a/drivers/gpu/drm/drm_fb_cma_helper.c > >> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c > >> @@ -9,6 +9,7 @@ > >>* Copyright (C) 2012 Red Hat > >>*/ > >> > >> +#include > >> #include > >> #include > >> #include > >> diff --git a/include/drm/drm_fb_cma_helper.h > >> b/include/drm/drm_fb_cma_helper.h > >> index 4becb09975a4..795aea1d0a25 100644 > >> --- a/include/drm/drm_fb_cma_helper.h > >> +++ b/include/drm/drm_fb_cma_helper.h > >> @@ -2,6 +2,8 @@ > >> #ifndef __DRM_FB_CMA_HELPER_H__ > >> #define __DRM_FB_CMA_HELPER_H__ > >> > >> +#include > >> + > >> struct drm_framebuffer; > >> struct drm_plane_state; > >> > >> -- > >> 2.15.0 > >> > >> ___ > >> 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
Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.
On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kleiner wrote: > On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä > wrote: > > > On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote: > > > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote: > > > > The panel reports 10 bpc color depth in its EDID, and the UEFI > > > > firmware chooses link settings at boot which support enough > > > > bandwidth for 10 bpc (324000 kbit/sec to be precise), but the > > > > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible, > > > > Does it actually or do we just ignore the fact that it reports 3.24Gbps? > > > > If it really reports 3.24 then we should be able to just add that to > > dp_rates[] in intel_dp_set_sink_rates() and be done with it. > > > > Although we'd likely want to skip 3.24 unless it really is reported > > as the max so as to not use that non-standard rate on other displays. > > So would require a bit fancier logic for that. > > > > > Was also my initial thought, but the DP_MAX_LINK_RATE reg reports 2.7 Gbps > as maximum. So dpcd[0x1] == 0xa ? What about the magic second version of DP_MAX_LINK_RATE at 0x2201 ? Hmm. I guess we should already be reading that via intel_dp_extended_receiver_capabilities(). -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.
On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher wrote:
> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
> wrote:
> >
> > If the current eDP link rate, as read from hw, provides a
> > higher bandwidth than the standard link rates, then add the
> > current link rate to the link_rates array for consideration
> > in future mode-sets.
> >
> > These initial current eDP link settings have been set up by
> > firmware during boot, so they should work on the eDP panel.
> > Therefore use them if the firmware thinks they are good and
> > they provide higher link bandwidth, e.g., to enable higher
> > resolutions / color depths.
> >
> > This fixes a problem found on the MacBookPro 2017 Retina panel:
> >
> > The panel reports 10 bpc color depth in its EDID, and the UEFI
> > firmware chooses link settings at boot which support enough
> > bandwidth for 10 bpc (324000 kbit/sec to be precise), but the
> > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible,
> > so intel_dp_set_sink_rates() would cap at that. This restricts
> > achievable color depth to 8 bpc, not providing the full color
> > depth of the panel. With this commit, we can use firmware setting
> > and get the full 10 bpc advertised by the Retina panel.
>
> Would it make more sense to just add a quirk for this particular
> panel? Would there be cases where the link was programmed wrong and
> then we end up using that additional link speed as supported?
>
> Alex
>
>
Not sure. This MBP 2017 is the only non-ancient laptop i now have. I'd
assume many other Apple Retina panels would behave similar. The panels dpcd
regs report DP 1.1 and eDP 1.3, so the flexible table with additional modes
from eDP1.4+ does not exist. According to Wikipedia, eDP 1.4 was introduced
in february 2013 and this is a mid 2017 machine, so Apple seems to be quite
behind. Therefore i assume we'd need a lot of quirks over time.
That said:
1. The logic in amdgpu's DC for the same purpose is a bit different than on
the intel side.
2. DC allows overriding DP link settings, that's how i initially tested
this, so one could do the "quirk" via something like that in a bootup
script. So on AMD one could work around the lack of the patch and of quirks.
3. I spent a lot of time with a photo-meter, testing the quality of the 10
bit: It turns out that running the panel at 8 bit + AMD's spatial dithering
that kicks in gives better results than running the panel in native 10 bit.
Maybe the panel is not really a 10 bit one, but just pretends to be and
then uses its own dithering to achieve 10 bit. So at least on AMD one is
better off precision-wise with the 8 bit panel default with this specific
panel.
On Intel however, we don't do dithering for > 6 bpc panels atm., so using
the panel at 10 bpc is the only way to get 10 bit display atm. Adn we don't
use dithering on Intel at > 6 bpc panels atm., because there are some
oddities in the way Intel hw dithers at higher bit depths - it also dithers
pixel values where it shouldn't. That makes it impossible to get an
identity passthrough of a 8 bpc framebuffer to the outputs, which kills all
kind of special display equipment that needs that identity passthrough to
work.
-mario
>
> > Signed-off-by: Mario Kleiner
> > Cc: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 23 +++
> > 1 file changed, 23 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 2f31d226c6eb..aa3e0b5108c6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4368,6 +4368,8 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > {
> > struct drm_i915_private *dev_priv =
> > to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
> > + int max_rate;
> > + u8 link_bw;
> >
> > /* this function is meant to be called only once */
> > WARN_ON(intel_dp->dpcd[DP_DPCD_REV] != 0);
> > @@ -4433,6 +4435,27 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > else
> > intel_dp_set_sink_rates(intel_dp);
> >
> > + /*
> > +* If the firmware programmed a rate higher than the standard
> sink rates
> > +* during boot, then add that rate as a valid sink rate, as fw
> knows
> > +* this is a good rate and we get extra bandwidth.
> > +*
> > +* Helps, e.g., on the Apple MacBookPro 2017 Retina panel, which
> is only
> > +* eDP 1.1, but supports the unusual rate of 324000 kHz at
> bootup, for
> > +* 10 bpc / 30 bit color depth.
> > +*/
> > + if (!intel_dp->use_rate_select &&
> > + (drm_dp_dpcd_read(&intel_dp->aux, DP_LINK_BW_SET, &link_bw,
> 1) == 1) &&
> > + (link_bw > 0) && (intel_dp->num_sink_rates <
> DP_MAX_SUPPORTED_RATES)) {
> > + max_rate = drm_dp_bw_code_to_link_rate(link_bw);
> > + if (max_rate >
> intel_dp->sink_rates[intel_dp-
Re: [PATCH v2 4/7] drm/panfrost: Add support for a second regulator for the GPU
On 09/01/2020 16:28, Mark Brown wrote: On Thu, Jan 09, 2020 at 02:14:42PM +, Steven Price wrote: On 08/01/2020 22:52, Nicolas Boichat wrote: That'd be a bit awkward to match, though... Currently all bifrost share the same compatible "arm,mali-bifrost", and it'd seem weird/wrong to match "mediatek,mt8183-mali" in this driver? I have no idea if any other Mali implementation will require a second regulator, but with the MT8183 we do need it, see below. This doesn't sound particularly hard, just new. Plenty of other devices have quirks done based on the SoC they're in or the IP revision, this would just be another of those quirks. Well if devfreq was working (see patch 7 https://patchwork.kernel.org/patch/11322851/ for a partial implementation), it would adjust both mali and sram regulators, see the OPP table in patch 2 (https://patchwork.kernel.org/patch/11322825/): SRAM voltage needs to be increased for frequencies >=698Mhz. Now if you have some better idea how to implement this, I'm all ears! Set a flag based on the compatible, then base runtime decisions off that. I'm not sure if it's better, but could we just encode the list of regulators into device tree. I'm a bit worried about special casing an "sram" regulator given that other platforms might have a similar situation but call the second regulator a different name. Obviously the list of regulators bound on a given platform is encoded in the device tree but you shouldn't really be relying on that to figure out what to request in the driver - the driver should know what it's expecting. From a driver perspective we don't expect to have to worry about power domains/multiple regulators - the hardware provides a bunch of power registers to turn on/off various parts of the hardware and this should be linked (in hardware) to a PDC which sorts it out. The GPU/PDC handles the required sequencing. So it *should* be a case of turn power/clocks on and go. However certain integrations may have quirks such that there are physically multiple supplies. These are expected to all be turned on before using the GPU. Quite how this is best represented is something I'm not sure about. Bear in mind that getting regulator stuff wrong can result in physical damage to the system so it pays to be careful and to consider that platform integrators have a tendency to rely on things that just happen to work but aren't a good idea or accurate representations of the system. It's certainly *possible* to do something like that, the information is there, but I would not in any way recommend doing things that way as it's likely to not be robust. The possibility that the regulator setup may vary on other platforms (which I'd expect TBH) does suggest that just requesting a bunch of supply names optionally and hoping that we got all the ones that are important on a given platform is going to lead to trouble down the line. Certainly if we miss a regulator the GPU isn't going to work properly (some cores won't be able to power up successfully). However at the moment the driver will happily do this if someone provides it with a DT which includes regulators that it doesn't know about. So I'm not sure how adding special case code for a SoC would help here. Steve, please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to. Sorry about that - I switched to my laptop to escape the noisy work going on outside the office, and apparently that was misconfigured. Hopefully fixed now, thanks for letting me know! Steve ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/7] drm/panfrost: Add support for a second regulator for the GPU
On Wed, Jan 8, 2020 at 4:52 PM Nicolas Boichat wrote:
>
> On Wed, Jan 8, 2020 at 9:23 PM Mark Brown wrote:
> >
> > On Wed, Jan 08, 2020 at 01:23:34PM +0800, Nicolas Boichat wrote:
> >
> > > Some GPUs, namely, the bifrost/g72 part on MT8183, have a second
> > > regulator for their SRAM, let's add support for that.
> >
> > > + pfdev->regulator_sram = devm_regulator_get_optional(pfdev->dev,
> > > "sram");
> > > + if (IS_ERR(pfdev->regulator_sram)) {
> >
> > This supply is required for the devices that need it so I'd therefore
> > expect the driver to request the supply non-optionally based on the
> > compatible string rather than just hoping that a missing regulator isn't
> > important.
>
> That'd be a bit awkward to match, though... Currently all bifrost
> share the same compatible "arm,mali-bifrost", and it'd seem
> weird/wrong to match "mediatek,mt8183-mali" in this driver? I have no
> idea if any other Mali implementation will require a second regulator,
> but with the MT8183 we do need it, see below.
The current number of supported bifrost platforms is 0. It's only a
matter of time until SoC specific compatibles need to be used in the
driver. This is why we require them.
It could very well be that all bifrost implementations need 2
supplies. On chip RAMs are very frequently a separate thing which are
synthesized differently from logic. At least within a specific IP
model, I somewhat doubt there's a variable number of supplies. It
could be possible to connect both to the same supply, but the correct
way to handle that is both -supply properties point to the same
regulator.
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 1/4] drm/i915/gvt: make gvt oblivious of kvmgt data structures
Instead of defining KVMGT per-device state in struct intel_vgpu
directly, add an indirection. This makes the GVT code oblivious of
what state KVMGT needs to keep.
The intention here is to eventually make it possible to build
hypervisor backends for the mediator, without having to touch the
mediator itself. This is a first step.
Cc: Zhenyu Wang
Signed-off-by: Julian Stecklina
---
drivers/gpu/drm/i915/gvt/gvt.h | 32 +---
drivers/gpu/drm/i915/gvt/kvmgt.c | 287 +++
2 files changed, 184 insertions(+), 135 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 0081b051d3e0..2604739e5680 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -196,31 +196,8 @@ struct intel_vgpu {
struct dentry *debugfs;
-#if IS_ENABLED(CONFIG_DRM_I915_GVT_KVMGT)
- struct {
- struct mdev_device *mdev;
- struct vfio_region *region;
- int num_regions;
- struct eventfd_ctx *intx_trigger;
- struct eventfd_ctx *msi_trigger;
-
- /*
-* Two caches are used to avoid mapping duplicated pages (eg.
-* scratch pages). This help to reduce dma setup overhead.
-*/
- struct rb_root gfn_cache;
- struct rb_root dma_addr_cache;
- unsigned long nr_cache_entries;
- struct mutex cache_lock;
-
- struct notifier_block iommu_notifier;
- struct notifier_block group_notifier;
- struct kvm *kvm;
- struct work_struct release_work;
- atomic_t released;
- struct vfio_device *vfio_device;
- } vdev;
-#endif
+ /* Hypervisor-specific device state. */
+ void *vdev;
struct list_head dmabuf_obj_list_head;
struct mutex dmabuf_lock;
@@ -231,6 +208,11 @@ struct intel_vgpu {
u32 scan_nonprivbb;
};
+static inline void *intel_vgpu_vdev(struct intel_vgpu *vgpu)
+{
+ return vgpu->vdev;
+}
+
/* validating GM healthy status*/
#define vgpu_is_vm_unhealthy(ret_val) \
(((ret_val) == -EBADRQC) || ((ret_val) == -EFAULT))
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index bd79a9718cc7..d725a4fb94b9 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -108,6 +108,36 @@ struct gvt_dma {
struct kref ref;
};
+struct kvmgt_vdev {
+ struct intel_vgpu *vgpu;
+ struct mdev_device *mdev;
+ struct vfio_region *region;
+ int num_regions;
+ struct eventfd_ctx *intx_trigger;
+ struct eventfd_ctx *msi_trigger;
+
+ /*
+* Two caches are used to avoid mapping duplicated pages (eg.
+* scratch pages). This help to reduce dma setup overhead.
+*/
+ struct rb_root gfn_cache;
+ struct rb_root dma_addr_cache;
+ unsigned long nr_cache_entries;
+ struct mutex cache_lock;
+
+ struct notifier_block iommu_notifier;
+ struct notifier_block group_notifier;
+ struct kvm *kvm;
+ struct work_struct release_work;
+ atomic_t released;
+ struct vfio_device *vfio_device;
+};
+
+static inline struct kvmgt_vdev *kvmgt_vdev(struct intel_vgpu *vgpu)
+{
+ return intel_vgpu_vdev(vgpu);
+}
+
static inline bool handle_valid(unsigned long handle)
{
return !!(handle & ~0xff);
@@ -129,7 +159,7 @@ static void gvt_unpin_guest_page(struct intel_vgpu *vgpu,
unsigned long gfn,
for (npage = 0; npage < total_pages; npage++) {
unsigned long cur_gfn = gfn + npage;
- ret = vfio_unpin_pages(mdev_dev(vgpu->vdev.mdev), &cur_gfn, 1);
+ ret = vfio_unpin_pages(mdev_dev(kvmgt_vdev(vgpu)->mdev),
&cur_gfn, 1);
WARN_ON(ret != 1);
}
}
@@ -152,7 +182,7 @@ static int gvt_pin_guest_page(struct intel_vgpu *vgpu,
unsigned long gfn,
unsigned long cur_gfn = gfn + npage;
unsigned long pfn;
- ret = vfio_pin_pages(mdev_dev(vgpu->vdev.mdev), &cur_gfn, 1,
+ ret = vfio_pin_pages(mdev_dev(kvmgt_vdev(vgpu)->mdev),
&cur_gfn, 1,
IOMMU_READ | IOMMU_WRITE, &pfn);
if (ret != 1) {
gvt_vgpu_err("vfio_pin_pages failed for gfn 0x%lx, ret
%d\n",
@@ -219,7 +249,7 @@ static void gvt_dma_unmap_page(struct intel_vgpu *vgpu,
unsigned long gfn,
static struct gvt_dma *__gvt_cache_find_dma_addr(struct intel_vgpu *vgpu,
dma_addr_t dma_addr)
{
- struct rb_node *node = vgpu->vdev.dma_addr_cache.rb_node;
+ struct rb_node *node = kvmgt_vdev(vgpu)->dma_addr_cache.rb_node;
struct gvt_dma *itr;
while (node) {
@@ -237,7 +267,7 @@ static struct gvt_dma *__gvt_cache_find_dma_addr(struct
intel_vgpu *vgpu,
static struct gvt_dma *__gvt_cache_find_gfn(struc
[RFC PATCH 3/4] drm/i915/gvt: define a public interface to gvt
So far, the KVMGT code just included the whole i915 driver and GVT
internals to do its job. Change this to have a single public header
that defines the interface via accessor functions.
Some ugly things:
a) The handle member of intel_vgpu should be in kvmgt_vdev and the
generic code should just pass the vgpu pointer around.
b) The "public" API is rather ugly, because I tried to limit the
changes I do to KVMGT and have a mechanical 1:1 conversion. Future
patches will need to simplify this to something sane.
v2:
- Remove edid and display constants from public API
Cc: Zhenyu Wang
Signed-off-by: Julian Stecklina
---
drivers/gpu/drm/i915/gvt/Makefile | 2 +-
drivers/gpu/drm/i915/gvt/debug.h | 2 +-
drivers/gpu/drm/i915/gvt/display.c| 26 +
drivers/gpu/drm/i915/gvt/display.h| 27 -
drivers/gpu/drm/i915/gvt/gtt.h| 2 -
drivers/gpu/drm/i915/gvt/gvt.h| 40 +--
drivers/gpu/drm/i915/gvt/gvt_public.c | 154 ++
drivers/gpu/drm/i915/gvt/gvt_public.h | 104 +
drivers/gpu/drm/i915/gvt/hypercall.h | 3 +
drivers/gpu/drm/i915/gvt/kvmgt.c | 130 +++---
drivers/gpu/drm/i915/gvt/mpt.h| 3 -
drivers/gpu/drm/i915/gvt/reg.h| 2 -
12 files changed, 354 insertions(+), 141 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gvt/gvt_public.c
create mode 100644 drivers/gpu/drm/i915/gvt/gvt_public.h
diff --git a/drivers/gpu/drm/i915/gvt/Makefile
b/drivers/gpu/drm/i915/gvt/Makefile
index ea8324abc784..183827c4f917 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -3,7 +3,7 @@ GVT_DIR := gvt
GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \
interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o
debugfs.o \
- fb_decoder.o dmabuf.o page_track.o
+ fb_decoder.o dmabuf.o page_track.o gvt_public.o
ccflags-y += -I $(srctree)/$(src) -I
$(srctree)/$(src)/$(GVT_DIR)/
i915-y += $(addprefix $(GVT_DIR)/,
$(GVT_SOURCE))
diff --git a/drivers/gpu/drm/i915/gvt/debug.h b/drivers/gpu/drm/i915/gvt/debug.h
index c6027125c1ec..8270f34cfa43 100644
--- a/drivers/gpu/drm/i915/gvt/debug.h
+++ b/drivers/gpu/drm/i915/gvt/debug.h
@@ -32,7 +32,7 @@ do {
\
if (IS_ERR_OR_NULL(vgpu)) \
pr_err("gvt: "fmt, ##args); \
else\
- pr_err("gvt: vgpu %d: "fmt, vgpu->id, ##args);\
+ pr_err("gvt: vgpu %d: "fmt, intel_vgpu_id(vgpu), ##args);
\
} while (0)
#define gvt_dbg_core(fmt, args...) \
diff --git a/drivers/gpu/drm/i915/gvt/display.c
b/drivers/gpu/drm/i915/gvt/display.c
index e1c313da6c00..08636fa15c46 100644
--- a/drivers/gpu/drm/i915/gvt/display.c
+++ b/drivers/gpu/drm/i915/gvt/display.c
@@ -529,3 +529,29 @@ void intel_vgpu_reset_display(struct intel_vgpu *vgpu)
{
emulate_monitor_status_change(vgpu);
}
+
+unsigned int vgpu_edid_xres(struct intel_vgpu_port *port)
+{
+ switch (port->id) {
+ case GVT_EDID_1024_768:
+ return 1024;
+ case GVT_EDID_1920_1200:
+ return 1920;
+ default:
+ return 0;
+ }
+}
+EXPORT_SYMBOL_GPL(vgpu_edid_xres);
+
+unsigned int vgpu_edid_yres(struct intel_vgpu_port *port)
+{
+ switch (port->id) {
+ case GVT_EDID_1024_768:
+ return 768;
+ case GVT_EDID_1920_1200:
+ return 1200;
+ default:
+ return 0;
+ }
+}
+EXPORT_SYMBOL_GPL(vgpu_edid_yres);
diff --git a/drivers/gpu/drm/i915/gvt/display.h
b/drivers/gpu/drm/i915/gvt/display.h
index b59b34046e1e..6cdfc28b1070 100644
--- a/drivers/gpu/drm/i915/gvt/display.h
+++ b/drivers/gpu/drm/i915/gvt/display.h
@@ -43,9 +43,6 @@ struct intel_vgpu;
#define SBI_REG_MAX20
#define DPCD_SIZE 0x700
-#define intel_vgpu_port(vgpu, port) \
- (&(vgpu->display.ports[port]))
-
#define intel_vgpu_has_monitor_on_port(vgpu, port) \
(intel_vgpu_port(vgpu, port)->edid && \
intel_vgpu_port(vgpu, port)->edid->data_valid)
@@ -178,30 +175,6 @@ static inline char *vgpu_edid_str(enum intel_vgpu_edid id)
}
}
-static inline unsigned int vgpu_edid_xres(enum intel_vgpu_edid id)
-{
- switch (id) {
- case GVT_EDID_1024_768:
- return 1024;
- case GVT_EDID_1920_1200:
- return 1920;
- default:
- return 0;
- }
-}
-
-static inline unsigned int vgpu_edid_yres(enum intel_vgpu_edid id)
-{
- switch (id) {
- case GVT_EDID_1024_768:
- return 768;
- case GVT_EDID_1920_1200:
- return 1200;
- def
[RFC PATCH 4/4] drm/i915/gvt: move public gvt headers out into global include
Now that the GVT interface to hypervisors does not depend on i915/GVT internals anymore, we can move the headers to the global include/. This makes out-of-tree modules for hypervisor integration possible. Cc: Zhenyu Wang Signed-off-by: Julian Stecklina --- drivers/gpu/drm/i915/gvt/gvt.h | 3 +-- drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +- .../i915/gvt/gvt_public.h => include/drm/i915_gvt.h| 8 .../hypercall.h => include/drm/i915_gvt_hypercall.h| 10 +++--- 4 files changed, 13 insertions(+), 10 deletions(-) rename drivers/gpu/drm/i915/gvt/gvt_public.h => include/drm/i915_gvt.h (97%) rename drivers/gpu/drm/i915/gvt/hypercall.h => include/drm/i915_gvt_hypercall.h (95%) diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h index f9693c44e342..d09374aa7710 100644 --- a/drivers/gpu/drm/i915/gvt/gvt.h +++ b/drivers/gpu/drm/i915/gvt/gvt.h @@ -33,9 +33,8 @@ #ifndef _GVT_H_ #define _GVT_H_ -#include "gvt_public.h" +#include #include "debug.h" -#include "hypercall.h" #include "mmio.h" #include "reg.h" #include "interrupt.h" diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c index f5157211d45f..280d69ca964b 100644 --- a/drivers/gpu/drm/i915/gvt/kvmgt.c +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c @@ -28,6 +28,7 @@ *Xiaoguang Chen */ +#include #include #include #include @@ -52,7 +53,6 @@ #include #include "debug.h" -#include "gvt_public.h" static const struct intel_gvt_ops *intel_gvt_ops; diff --git a/drivers/gpu/drm/i915/gvt/gvt_public.h b/include/drm/i915_gvt.h similarity index 97% rename from drivers/gpu/drm/i915/gvt/gvt_public.h rename to include/drm/i915_gvt.h index 23bf1235e1a1..3926ca32f773 100644 --- a/drivers/gpu/drm/i915/gvt/gvt_public.h +++ b/include/drm/i915_gvt.h @@ -21,10 +21,10 @@ * SOFTWARE. */ -#ifndef _GVT_PUBLIC_H_ -#define _GVT_PUBLIC_H_ +#ifndef _I915_GVT_H_ +#define _I915_GVT_H_ -#include "hypercall.h" +#include struct attribute; struct attribute_group; @@ -101,4 +101,4 @@ bool intel_gvt_in_gtt(struct intel_vgpu *vgpu, u64 off); struct dentry *intel_vgpu_debugfs(struct intel_vgpu *vgpu); -#endif /* _GVT_PUBLIC_H_ */ +#endif /* _I915_GVT_H_ */ diff --git a/drivers/gpu/drm/i915/gvt/hypercall.h b/include/drm/i915_gvt_hypercall.h similarity index 95% rename from drivers/gpu/drm/i915/gvt/hypercall.h rename to include/drm/i915_gvt_hypercall.h index 7ed33e4919a3..c26eef7dbdde 100644 --- a/drivers/gpu/drm/i915/gvt/hypercall.h +++ b/include/drm/i915_gvt_hypercall.h @@ -30,8 +30,12 @@ * */ -#ifndef _GVT_HYPERCALL_H_ -#define _GVT_HYPERCALL_H_ +#ifndef _I915_GVT_HYPERCALL_H_ +#define _I915_GVT_HYPERCALL_H_ + +#include + +struct device; #include @@ -84,4 +88,4 @@ extern struct intel_gvt_mpt xengt_mpt; int intel_gvt_register_hypervisor(struct intel_gvt_mpt *); void intel_gvt_unregister_hypervisor(void); -#endif /* _GVT_HYPERCALL_H_ */ +#endif /* _I915_GVT_HYPERCALL_H_ */ -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 2/4] drm/i915/gvt: remove unused vblank_done completion
This variable is used nowhere, so remove it.
Cc: Zhenyu Wang
Signed-off-by: Julian Stecklina
---
drivers/gpu/drm/i915/gvt/gvt.h | 2 --
drivers/gpu/drm/i915/gvt/kvmgt.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 2604739e5680..8cf292a8d6bd 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -203,8 +203,6 @@ struct intel_vgpu {
struct mutex dmabuf_lock;
struct idr object_idr;
- struct completion vblank_done;
-
u32 scan_nonprivbb;
};
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index d725a4fb94b9..9a435bc1a2f0 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1817,8 +1817,6 @@ static int kvmgt_guest_init(struct mdev_device *mdev)
kvmgt_protect_table_init(info);
gvt_cache_init(vgpu);
- init_completion(&vgpu->vblank_done);
-
info->track_node.track_write = kvmgt_page_track_write;
info->track_node.track_flush_slot = kvmgt_page_track_flush_slot;
kvm_page_track_register_notifier(kvm, &info->track_node);
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 0/4] Support for out-of-tree hypervisor modules in i915/gvt
These patch series removes the dependency of i915/gvt hypervisor backends on the driver internals of the i915 driver. Instead, we add a small public API that hypervisor backends can use. This enables out-of-tree hypervisor backends for the Intel graphics virtualization and simplifies development. At the same time, it creates at least a bit of a barrier to including more i915 internals into kvmgt, which is nice in itself. The first two patches are pretty much general cleanup and could be merged without the rest. Any feedback is welcome. Julian Stecklina (4): drm/i915/gvt: make gvt oblivious of kvmgt data structures drm/i915/gvt: remove unused vblank_done completion drm/i915/gvt: define a public interface to gvt drm/i915/gvt: move public gvt headers out into global include drivers/gpu/drm/i915/gvt/Makefile | 2 +- drivers/gpu/drm/i915/gvt/debug.h | 2 +- drivers/gpu/drm/i915/gvt/display.c| 26 ++ drivers/gpu/drm/i915/gvt/display.h| 27 -- drivers/gpu/drm/i915/gvt/gtt.h| 2 - drivers/gpu/drm/i915/gvt/gvt.h| 65 +-- drivers/gpu/drm/i915/gvt/gvt_public.c | 154 +++ drivers/gpu/drm/i915/gvt/kvmgt.c | 413 ++ drivers/gpu/drm/i915/gvt/mpt.h| 3 - drivers/gpu/drm/i915/gvt/reg.h| 2 - include/drm/i915_gvt.h| 104 + .../drm/i915_gvt_hypercall.h | 13 +- 12 files changed, 537 insertions(+), 276 deletions(-) create mode 100644 drivers/gpu/drm/i915/gvt/gvt_public.c create mode 100644 include/drm/i915_gvt.h rename drivers/gpu/drm/i915/gvt/hypercall.h => include/drm/i915_gvt_hypercall.h (92%) -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/4] dt-bindings: display: Convert Allwinner display pipeline to schemas
On Fri, Jan 3, 2020 at 9:28 AM Maxime Ripard wrote: > > The Allwinner SoCs have a display engine composed of several controllers > assembled differently depending on the SoC, the number and type of output > they have, and the additional features they provide. A number of those are > supported in Linux, with the matching bindings. > > Now that we have the DT validation in place, let's split into separate file > and convert the device tree bindings for those controllers to schemas. > > Signed-off-by: Maxime Ripard > > --- > > Changes from v2: > - Changed a number of maxItems to minItems to make more sense > - Fixed a few enum that were improperly declared. This raised a bunch of > warnings that were unnoticed before. Fixed them. > - Added an if clause to the HDMI PHY binding to check the number of clocks > > Changes from v1: > - Declare the ports in the bindings > --- > .../allwinner,sun4i-a10-display-backend.yaml | 291 > .../allwinner,sun4i-a10-display-engine.yaml | 114 +++ > .../allwinner,sun4i-a10-display-frontend.yaml | 138 > .../display/allwinner,sun4i-a10-hdmi.yaml | 183 + > .../display/allwinner,sun4i-a10-tcon.yaml | 676 ++ > .../allwinner,sun4i-a10-tv-encoder.yaml | 62 ++ > .../display/allwinner,sun6i-a31-drc.yaml | 138 > .../allwinner,sun8i-a83t-de2-mixer.yaml | 118 +++ > .../display/allwinner,sun8i-a83t-dw-hdmi.yaml | 273 +++ > .../allwinner,sun8i-a83t-hdmi-phy.yaml| 117 +++ > .../display/allwinner,sun8i-r40-tcon-top.yaml | 382 ++ > .../display/allwinner,sun9i-a80-deu.yaml | 133 > .../bindings/display/sunxi/sun4i-drm.txt | 637 - > 13 files changed, 2625 insertions(+), 637 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-frontend.yaml > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun4i-a10-hdmi.yaml > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tv-encoder.yaml > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun6i-a31-drc.yaml > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun9i-a80-deu.yaml > delete mode 100644 > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFT 00/13] iomap: Constify ioreadX() iomem argument
From: Christophe Leroy > Sent: 08 January 2020 08:49 ... > And as pointed by Arnd, the volatile is really only necessary for the > dereference itself, should the arch use dereferencing. I've had trouble with some versions of gcc and reading of 'volatile unsigned char *'. It tended to follow the memory read with an extra mask with 0xff. (I suspect that internally the value landed into a temporary 'int' variable.) I got better code using memory barriers. So putting an asm barrier for the exact location of the memory read either side of the read should have the desired effect without adding extra instructions. (You might think 'volatile' would mean that - but it doesn't.) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2 5/9] arc: Constify ioreadX() iomem argument (as in generic implementation)
Hi Krzysztof, > The ioreadX() helpers have inconsistent interface. On some architectures > void *__iomem address argument is a pointer to const, on some not. > > Implementations of ioreadX() do not modify the memory under the > address so they can be converted to a "const" version for const-safety > and consistency among architectures. Thanks for this clean-up. Looks good to me, so ... Acked-by: Alexey Brodkin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] dt-bindings: panel-simple: Add compatible for GiantPlus GPM940B0
Add a compatible string for the GiantPlus GPM740B0 3" QVGA TFT LCD panel, and remove the old giantplus,gpm740b0.txt documentation which is now obsolete. Signed-off-by: Paul Cercueil --- .../bindings/display/panel/giantplus,gpm940b0.txt| 12 .../bindings/display/panel/panel-simple.yaml | 2 ++ 2 files changed, 2 insertions(+), 12 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt diff --git a/Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt b/Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt deleted file mode 100644 index 3dab52f92c26.. --- a/Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt +++ /dev/null @@ -1,12 +0,0 @@ -GiantPlus 3.0" (320x240 pixels) 24-bit TFT LCD panel - -Required properties: -- compatible: should be "giantplus,gpm940b0" -- power-supply: as specified in the base binding - -Optional properties: -- backlight: as specified in the base binding -- enable-gpios: as specified in the base binding - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 090866260f4f..c1a77d9105a2 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -33,6 +33,8 @@ properties: - ampire,am-480272h3tmqw-t01h # Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel - ampire,am800480r3tmqwa1h +# GiantPlus GPM940B0 3.0" QVGA TFT LCD panel + - giantplus,gpm940b0 backlight: true enable-gpios: true -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/rockchip: use DIV_ROUND_UP macro for calculations.
Replace the open coded calculation with the more concise and readable
DIV_ROUND_UP macro.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 0b3d18c457b2..cc672620d6e0 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -328,7 +328,7 @@ static inline uint16_t scl_get_bili_dn_vskip(int src_h, int
dst_h,
{
int act_height;
- act_height = (src_h + vskiplines - 1) / vskiplines;
+ act_height = DIV_ROUND_UP(src_h, vskiplines);
if (act_height == dst_h)
return GET_SCL_FT_BILI_DN(src_h, dst_h) / vskiplines;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
答复: [PATCH] drm/hisilicon: add the mode_valid function
Hi Thomas Zimmermann:
I will modify this patch and send v2 as you suggested.
Thank you very much.
Best
-邮件原件-
发件人: Thomas Zimmermann [mailto:tzimmerm...@suse.de]
发送时间: 2020年1月8日 16:49
收件人: tiantao (H) ; Chenfeng (puck)
; airl...@linux.ie; dan...@ffwll.ch;
kra...@redhat.com; alexander.deuc...@amd.com; t...@linutronix.de;
dri-devel@lists.freedesktop.org; xinliang@linaro.org;
linux-ker...@vger.kernel.org
抄送: Linuxarm
主题: Re: [PATCH] drm/hisilicon: add the mode_valid function
Hi,
here are a few more nits to fix.
Am 08.01.20 um 09:19 schrieb Tian Tao:
> add mode_valid function, and we can also use it to make suse the
> resolution is valid.
Start with capital 'Add' and make it a simple sentence. Change 'suse' to 'sure'
>
> Signed-off-by: Tian Tao
> Signed-off-by: Gong junjie
> ---
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 20
>
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> index 843d784..6cb7a79 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> @@ -242,6 +242,25 @@ static void hibmc_crtc_atomic_disable(struct drm_crtc
> *crtc,
> hibmc_set_current_gate(priv, reg);
> }
>
> +enum drm_mode_status hibmc_crtc_mode_valid(struct drm_crtc *crtc,
> + const struct drm_display_mode *mode)
Please declare this function as static.
> +{
> + int i = 0;
> + int vrefresh = drm_mode_vrefresh(mode);
> +
> + if (vrefresh < 59 || vrefresh > 61)
> + return MODE_NOMODE;
I'd return MODE_NOCLOCK or MODE_CLOCK_RANGE.
> +
> + for (i = 0; i < ARRAY_SIZE(hibmc_pll_table); i++) {
> + if (hibmc_pll_table[i].hdisplay == mode->hdisplay &&
> + hibmc_pll_table[i].vdisplay == mode->vdisplay)
> + return MODE_OK;
> + }
> +
> + return MODE_NOMODE;
Maybe return MODE_BAD. MODE_NOMODE apparently refers to a descriptive string
for the mode.
> +}
> +
> +
One one empty line please.
With these fixes applied, you can add my
Reviewed-by: Thomas Zimmermann
Best regards
Thomas
> static unsigned int format_pll_reg(void) {
> unsigned int pllreg = 0;
> @@ -510,6 +529,7 @@ static const struct drm_crtc_helper_funcs
> hibmc_crtc_helper_funcs = {
> .atomic_flush = hibmc_crtc_atomic_flush,
> .atomic_enable = hibmc_crtc_atomic_enable,
> .atomic_disable = hibmc_crtc_atomic_disable,
> + .mode_valid = hibmc_crtc_mode_valid,
> };
>
> int hibmc_de_init(struct hibmc_drm_private *priv)
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/i915: conversion to new logging macros in i915/intel_device_info.c
This replaces the printk and struct device based logging macros with the
new struct drm_device style based logging macros i915/intel_device_info.c.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/intel_device_info.c | 25 +---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 6670a0763be2..fcdacd6d4aa5 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -974,10 +974,11 @@ void intel_device_info_runtime_init(struct
drm_i915_private *dev_priv)
sfuse_strap & SFUSE_STRAP_DISPLAY_DISABLED ||
(HAS_PCH_CPT(dev_priv) &&
!(sfuse_strap & SFUSE_STRAP_FUSE_LOCK))) {
- DRM_INFO("Display fused off, disabling\n");
+ drm_info(&dev_priv->drm,
+"Display fused off, disabling\n");
info->pipe_mask = 0;
} else if (fuse_strap & IVB_PIPE_C_DISABLE) {
- DRM_INFO("PipeC fused off\n");
+ drm_info(&dev_priv->drm, "PipeC fused off\n");
info->pipe_mask &= ~BIT(PIPE_C);
}
} else if (HAS_DISPLAY(dev_priv) && INTEL_GEN(dev_priv) >= 9) {
@@ -1000,8 +1001,9 @@ void intel_device_info_runtime_init(struct
drm_i915_private *dev_priv)
* in the mask.
*/
if (enabled_mask == 0 || !is_power_of_2(enabled_mask + 1))
- DRM_ERROR("invalid pipe fuse configuration:
enabled_mask=0x%x\n",
- enabled_mask);
+ drm_err(&dev_priv->drm,
+ "invalid pipe fuse configuration:
enabled_mask=0x%x\n",
+ enabled_mask);
else
info->pipe_mask = enabled_mask;
@@ -1036,7 +1038,8 @@ void intel_device_info_runtime_init(struct
drm_i915_private *dev_priv)
gen12_sseu_info_init(dev_priv);
if (IS_GEN(dev_priv, 6) && intel_vtd_active()) {
- DRM_INFO("Disabling ppGTT for VT-d support\n");
+ drm_info(&dev_priv->drm,
+"Disabling ppGTT for VT-d support\n");
info->ppgtt_type = INTEL_PPGTT_NONE;
}
@@ -1084,7 +1087,7 @@ void intel_device_info_init_mmio(struct drm_i915_private
*dev_priv)
if (!(BIT(i) & vdbox_mask)) {
info->engine_mask &= ~BIT(_VCS(i));
- DRM_DEBUG_DRIVER("vcs%u fused off\n", i);
+ drm_dbg(&dev_priv->drm, "vcs%u fused off\n", i);
continue;
}
@@ -1096,8 +1099,8 @@ void intel_device_info_init_mmio(struct drm_i915_private
*dev_priv)
if (INTEL_GEN(dev_priv) >= 12 || logical_vdbox++ % 2 == 0)
RUNTIME_INFO(dev_priv)->vdbox_sfc_access |= BIT(i);
}
- DRM_DEBUG_DRIVER("vdbox enable: %04x, instances: %04lx\n",
-vdbox_mask, VDBOX_MASK(dev_priv));
+ drm_dbg(&dev_priv->drm, "vdbox enable: %04x, instances: %04lx\n",
+ vdbox_mask, VDBOX_MASK(dev_priv));
GEM_BUG_ON(vdbox_mask != VDBOX_MASK(dev_priv));
for (i = 0; i < I915_MAX_VECS; i++) {
@@ -1108,10 +,10 @@ void intel_device_info_init_mmio(struct
drm_i915_private *dev_priv)
if (!(BIT(i) & vebox_mask)) {
info->engine_mask &= ~BIT(_VECS(i));
- DRM_DEBUG_DRIVER("vecs%u fused off\n", i);
+ drm_dbg(&dev_priv->drm, "vecs%u fused off\n", i);
}
}
- DRM_DEBUG_DRIVER("vebox enable: %04x, instances: %04lx\n",
-vebox_mask, VEBOX_MASK(dev_priv));
+ drm_dbg(&dev_priv->drm, "vebox enable: %04x, instances: %04lx\n",
+ vebox_mask, VEBOX_MASK(dev_priv));
GEM_BUG_ON(vebox_mask != VEBOX_MASK(dev_priv));
}
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/Kconfig: add missing 'depends on DRM' for DRM_DP_CEC
On 12/6/19 12:26 PM, Hans Verkuil wrote: > Add a missing 'depends on DRM' for the DRM_DP_CEC config > option. Without that enabling DRM_DP_CEC will force CEC_CORE > to =y instead of =m if DRM=m as well. > > Signed-off-by: Hans Verkuil Daniel, can you review this? It's annoying that the cec core is compiled as part of the kernel when it can just be a module. Regards, Hans > --- > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 1168351267fd..e8e478d6da9c 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -163,6 +163,7 @@ config DRM_LOAD_EDID_FIRMWARE > > config DRM_DP_CEC > bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support" > + depends on DRM > select CEC_CORE > help > Choose this option if you want to enable HDMI CEC support for > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFT v1 1/3] drm/panfrost: enable devfreq based the "operating-points-v2" property
Hi Robin, On Wed, Jan 8, 2020 at 12:18 PM Robin Murphy wrote: > > On 07/01/2020 11:06 pm, Martin Blumenstingl wrote: > > Decouple the check to see whether we want to enable devfreq for the GPU > > from dev_pm_opp_set_regulators(). This is preparation work for adding > > back support for regulator control (which means we need to call > > dev_pm_opp_set_regulators() before dev_pm_opp_of_add_table(), which > > means having a check for "is devfreq enabled" that is not tied to > > dev_pm_opp_of_add_table() makes things easier). > > Hmm, what about cases like the SCMI DVFS protocol where the OPPs are > dynamically discovered rather than statically defined in DT? where can I find such an example (Amlogic SoCs use SCPI instead of SCMI, so I don't think that I have any board with SCMI support) or some documentation? (I could only find SCPI clock and CPU DVFS implementations, but no generic "OPPs for any device" implementation) Martin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/msm: use BUG_ON macro for debugging.
As the if statement only checks for the value of the offset_name
variable, it can be replaced by the more conscise BUG_ON macro for error
reporting.
v2: format expression to less than 80 characters for each line.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index c7441fb8313e..d1843abc3ac7 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -315,10 +315,8 @@ OUT_PKT7(struct msm_ringbuffer *ring, uint8_t opcode,
uint16_t cnt)
static inline bool adreno_reg_check(struct adreno_gpu *gpu,
enum adreno_regs offset_name)
{
- if (offset_name >= REG_ADRENO_REGISTER_MAX ||
- !gpu->reg_offsets[offset_name]) {
- BUG();
- }
+ BUG_ON(offset_name >= REG_ADRENO_REGISTER_MAX ||
+ !gpu->reg_offsets[offset_name]);
/*
* REG_SKIP is a special value that tell us that the register in
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/i915: convert to new logging macros in i915/intel_gvt.c
This converts the use of printk based logging macros in i915/intel_gvt.c
with the new struct drm_device based logging macros.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/intel_gvt.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_gvt.c b/drivers/gpu/drm/i915/intel_gvt.c
index 2b6c016387c2..38ebd5562c7c 100644
--- a/drivers/gpu/drm/i915/intel_gvt.c
+++ b/drivers/gpu/drm/i915/intel_gvt.c
@@ -67,12 +67,13 @@ void intel_gvt_sanitize_options(struct drm_i915_private
*dev_priv)
return;
if (intel_vgpu_active(dev_priv)) {
- DRM_INFO("GVT-g is disabled for guest\n");
+ drm_info(&dev_priv->drm, "GVT-g is disabled for guest\n");
goto bail;
}
if (!is_supported_device(dev_priv)) {
- DRM_INFO("Unsupported device. GVT-g is disabled\n");
+ drm_info(&dev_priv->drm,
+"Unsupported device. GVT-g is disabled\n");
goto bail;
}
@@ -99,18 +100,20 @@ int intel_gvt_init(struct drm_i915_private *dev_priv)
return -ENODEV;
if (!i915_modparams.enable_gvt) {
- DRM_DEBUG_DRIVER("GVT-g is disabled by kernel params\n");
+ drm_dbg(&dev_priv->drm,
+ "GVT-g is disabled by kernel params\n");
return 0;
}
if (USES_GUC_SUBMISSION(dev_priv)) {
- DRM_ERROR("i915 GVT-g loading failed due to Graphics
virtualization is not yet supported with GuC submission\n");
+ drm_err(&dev_priv->drm,
+ "i915 GVT-g loading failed due to Graphics
virtualization is not yet supported with GuC submission\n");
return -EIO;
}
ret = intel_gvt_init_device(dev_priv);
if (ret) {
- DRM_DEBUG_DRIVER("Fail to init GVT device\n");
+ drm_dbg(&dev_priv->drm, "Fail to init GVT device\n");
goto bail;
}
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/sun4i: drc: Make sure we enforce the clock rate
On Wed, Jan 08, 2020 at 01:28:34AM +0800, Chen-Yu Tsai wrote: > On Wed, Jan 8, 2020 at 1:00 AM Maxime Ripard wrote: > > > > The DRC needs to run at 300MHz to be functional. This was done so far > > using assigned-clocks in the device tree, but that is easy to forget, and > > dosen't provide any other guarantee than the rate is going to be roughly > > the one requested at probe time. > > > > Therefore it's pretty fragile, so let's just use the exclusive clock API to > > enforce it. > > > > Signed-off-by: Maxime Ripard > > Reviewed-by: Chen-Yu Tsai APplied both, thanks! Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/7] Add dts for mt8183 GPU (and misc panfrost patches)
Patches 1,2,3,6 are: Reviewed-by: Alyssa Rosenzweig The remaining patches in the series are Acked-by. Reportedly the kernel should work on certain Bifrost boards more or less as-is, but I'm not positive about the details. It's possible some of these are G72-specific or MT-specific issues; Robin and Stephen will know more. Very nice work so far! Alyssa On Wed, Jan 08, 2020 at 01:23:30PM +0800, Nicolas Boichat wrote: > Hi! > > Sorry for the long delay since https://patchwork.kernel.org/patch/11132381/, > finally got around to give this a real try. > > The main purpose of this series is to upstream the dts change and the binding > document, but I wanted to see how far I could probe the GPU, to check that the > binding is indeed correct. The rest of the patches are RFC/work-in-progress, > but > I think some of them could already be picked up. > > So this is tested on MT8183 with a chromeos-4.19 kernel, and a ton of > backports to get the latest panfrost driver (I should probably try on > linux-next at some point but this was the path of least resistance). > > I tested it as a module as it's more challenging (originally probing would > work built-in, on boot, but not as a module, as I didn't have the power > domain changes, and all power domains are on by default during boot). > > Probing logs looks like this, currently: > [ 221.867726] panfrost 1304.gpu: clock rate = 51170 > [ 221.867929] panfrost 1304.gpu: Linked as a consumer to regulator.14 > [ 221.868600] panfrost 1304.gpu: Linked as a consumer to regulator.31 > [ 221.870586] panfrost 1304.gpu: Linked as a consumer to > genpd:0:1304.gpu > [ 221.871492] panfrost 1304.gpu: Linked as a consumer to > genpd:1:1304.gpu > [ 221.871866] panfrost 1304.gpu: Linked as a consumer to > genpd:2:1304.gpu > [ 221.872427] panfrost 1304.gpu: mali-g72 id 0x6221 major 0x0 minor 0x3 > status 0x0 > [ 221.872439] panfrost 1304.gpu: features: ,13de77ff, issues: > ,0400 > [ 221.872445] panfrost 1304.gpu: Features: L2:0x07120206 > Shader:0x Tiler:0x0809 Mem:0x1 MMU:0x2830 AS:0xff JS:0x7 > [ 221.872449] panfrost 1304.gpu: shader_present=0x7 l2_present=0x1 > [ 221.873526] panfrost 1304.gpu: error powering up gpu stack > [ 221.878088] [drm] Initialized panfrost 1.1.0 20180908 for 1304.gpu on > minor 2 > [ 221.940817] panfrost 1304.gpu: error powering up gpu stack > [ 222.018233] panfrost 1304.gpu: error powering up gpu stack > (repeated) > > So the GPU is probed, but there's an issue when powering up the STACK, not > quite sure why, I'll try to have a deeper look, at some point. > > Thanks! > > Nicolas > > v2: > - Use sram instead of mali_sram as SRAM supply name. > - Rename mali@ to gpu@. > - Add dt-bindings changes > - Stacking patches after the device tree change that allow basic >probing (still incomplete and broken). > > Nicolas Boichat (7): > dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183 > arm64: dts: mt8183: Add node for the Mali GPU > drm/panfrost: Improve error reporting in panfrost_gpu_power_on > drm/panfrost: Add support for a second regulator for the GPU > drm/panfrost: Add support for multiple power domain support > RFC: drm/panfrost: Add bifrost compatible string > RFC: drm/panfrost: devfreq: Add support for 2 regulators > > .../bindings/gpu/arm,mali-bifrost.yaml| 20 > arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 7 ++ > arch/arm64/boot/dts/mediatek/mt8183.dtsi | 104 + > drivers/gpu/drm/panfrost/panfrost_devfreq.c | 18 +++ > drivers/gpu/drm/panfrost/panfrost_device.c| 108 -- > drivers/gpu/drm/panfrost/panfrost_device.h| 7 ++ > drivers/gpu/drm/panfrost/panfrost_drv.c | 1 + > drivers/gpu/drm/panfrost/panfrost_gpu.c | 15 ++- > 8 files changed, 267 insertions(+), 13 deletions(-) > > -- > 2.24.1.735.g03f4e72817-goog > signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument
Hi Geert, Le 08/01/2020 à 09:43, Geert Uytterhoeven a écrit : Hi Christophe, On Wed, Jan 8, 2020 at 9:35 AM Christophe Leroy wrote: Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit : On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven wrote: On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven wrote: On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski wrote: The ioread8/16/32() and others have inconsistent interface among the architectures: some taking address as const, some not. It seems there is nothing really stopping all of them to take pointer to const. Shouldn't all of them take const volatile __iomem pointers? It seems the "volatile" is missing from all but the implementations in include/asm-generic/io.h. As my "volatile" comment applies to iowrite*(), too, probably that should be done in a separate patch. Hence with patches 1-5 squashed, and for patches 11-13: Reviewed-by: Geert Uytterhoeven I'll add to this one also changes to ioreadX_rep() and add another patch for volatile for reads and writes. I guess your review will be appreciated once more because of ioreadX_rep() volatile should really only be used where deemed necessary: https://www.kernel.org/doc/html/latest/process/volatile-considered-harmful.html It is said: " ... accessor functions might use volatile on architectures where direct I/O memory access does work. Essentially, each accessor call becomes a little critical section on its own and ensures that the access happens as expected by the programmer." That is exactly the use case here: all above are accessor functions. Why would ioreadX() not need volatile, while readY() does? My point was: it might be necessary for some arches and not for others. And as pointed by Arnd, the volatile is really only necessary for the dereference itself, should the arch use dereferencing. So I guess the best would be to go in the other direction: remove volatile keyword wherever possible instead of adding it where it is not needed. Christophe ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panfrost: Remove core stack power management
A-b
On Thu, Jan 09, 2020 at 01:31:04PM +, Steven Price wrote:
> Explict management of the GPU's core stacks is only necessary in the
> case of a broken integration with the PDC. Since there are no known
> platforms which have such a broken integration let's remove the explict
> control from the driver since this apparently causes problems on other
> platforms and will have a small performance penality.
>
> The out of tree mali_kbase driver contains this text regarding
> controlling the core stack (CONFIGMALI_CORESTACK):
>
> Enabling this feature on supported GPUs will let the driver powering
> on/off the GPU core stack independently without involving the Power
> Domain Controller. This should only be enabled on platforms which
> integration of the PDC to the Mali GPU is known to be problematic.
> This feature is currently only supported on t-Six and t-HEx GPUs.
>
> If unsure, say N.
>
> Signed-off-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_gpu.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
> b/drivers/gpu/drm/panfrost/panfrost_gpu.c
> index 8822ec13a0d6..460fc190de6e 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
> @@ -309,10 +309,6 @@ void panfrost_gpu_power_on(struct panfrost_device *pfdev)
> ret = readl_relaxed_poll_timeout(pfdev->iomem + L2_READY_LO,
> val, val == pfdev->features.l2_present, 100, 1000);
>
> - gpu_write(pfdev, STACK_PWRON_LO, pfdev->features.stack_present);
> - ret |= readl_relaxed_poll_timeout(pfdev->iomem + STACK_READY_LO,
> - val, val == pfdev->features.stack_present, 100, 1000);
> -
> gpu_write(pfdev, SHADER_PWRON_LO, pfdev->features.shader_present);
> ret |= readl_relaxed_poll_timeout(pfdev->iomem + SHADER_READY_LO,
> val, val == pfdev->features.shader_present, 100, 1000);
> @@ -329,7 +325,6 @@ void panfrost_gpu_power_off(struct panfrost_device *pfdev)
> {
> gpu_write(pfdev, TILER_PWROFF_LO, 0);
> gpu_write(pfdev, SHADER_PWROFF_LO, 0);
> - gpu_write(pfdev, STACK_PWROFF_LO, 0);
> gpu_write(pfdev, L2_PWROFF_LO, 0);
> }
>
> --
> 2.20.1
>
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mediatek: check for comp->funcs
There might be some comp that doesn't have funcs, eg. hdmi-connector.
Check for comp->funcs otherwise there will be NULL pointer dereference
crash.
Fixes: bd3de8cd782b ("drm/mediatek: Add gamma property according to hardware
capability")
Fixes: 7395eab077f9 ("drm/mediatek: Add ctm property support")
Signed-off-by: Hsin-Yi Wang
---
This patch is based on mediatek's drm branch:
https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-next-5.6
After
https://patchwork.freedesktop.org/patch/344477/?series=63328&rev=59,
there will also be funcs for hdmi-connector.
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index fb142fcfc353..7b392d6c71cc 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -808,11 +808,13 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
mtk_crtc->ddp_comp[i] = comp;
- if (comp->funcs->ctm_set)
- has_ctm = true;
+ if (comp->funcs) {
+ if (comp->funcs->ctm_set)
+ has_ctm = true;
- if (comp->funcs->gamma_set)
- gamma_lut_size = MTK_LUT_SIZE;
+ if (comp->funcs->gamma_set)
+ gamma_lut_size = MTK_LUT_SIZE;
+ }
}
for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
--
2.25.0.rc1.283.g88dfdc4193-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/i915: conversion to new logging macros in i915/i915_vgpu.c
Replace the use of printk based logging macros with the struct
drm_device based macros in i915/i915_vgpu.c
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/i915_vgpu.c | 41 +++-
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 968be26735c5..4afe21662266 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -77,7 +77,8 @@ void i915_detect_vgpu(struct drm_i915_private *dev_priv)
shared_area = pci_iomap_range(pdev, 0, VGT_PVINFO_PAGE,
VGT_PVINFO_SIZE);
if (!shared_area) {
- DRM_ERROR("failed to map MMIO bar to check for VGT\n");
+ drm_err(&dev_priv->drm,
+ "failed to map MMIO bar to check for VGT\n");
return;
}
@@ -87,7 +88,7 @@ void i915_detect_vgpu(struct drm_i915_private *dev_priv)
version_major = readw(shared_area + vgtif_offset(version_major));
if (version_major < VGT_VERSION_MAJOR) {
- DRM_INFO("VGT interface version mismatch!\n");
+ drm_info(&dev_priv->drm, "VGT interface version mismatch!\n");
goto out;
}
@@ -95,7 +96,7 @@ void i915_detect_vgpu(struct drm_i915_private *dev_priv)
dev_priv->vgpu.active = true;
mutex_init(&dev_priv->vgpu.lock);
- DRM_INFO("Virtual GPU for Intel GVT-g detected.\n");
+ drm_info(&dev_priv->drm, "Virtual GPU for Intel GVT-g detected.\n");
out:
pci_iounmap(pdev, shared_area);
@@ -120,13 +121,15 @@ static struct _balloon_info_ bl_info;
static void vgt_deballoon_space(struct i915_ggtt *ggtt,
struct drm_mm_node *node)
{
+ struct drm_i915_private *dev_priv = ggtt->vm.i915;
if (!drm_mm_node_allocated(node))
return;
- DRM_DEBUG_DRIVER("deballoon space: range [0x%llx - 0x%llx] %llu KiB.\n",
-node->start,
-node->start + node->size,
-node->size / 1024);
+ drm_dbg(&dev_priv->drm,
+ "deballoon space: range [0x%llx - 0x%llx] %llu KiB.\n",
+ node->start,
+ node->start + node->size,
+ node->size / 1024);
ggtt->vm.reserved -= node->size;
drm_mm_remove_node(node);
@@ -141,12 +144,13 @@ static void vgt_deballoon_space(struct i915_ggtt *ggtt,
*/
void intel_vgt_deballoon(struct i915_ggtt *ggtt)
{
+ struct drm_i915_private *dev_priv = ggtt->vm.i915;
int i;
if (!intel_vgpu_active(ggtt->vm.i915))
return;
- DRM_DEBUG("VGT deballoon.\n");
+ drm_dbg(&dev_priv->drm, "VGT deballoon.\n");
for (i = 0; i < 4; i++)
vgt_deballoon_space(ggtt, &bl_info.space[i]);
@@ -156,13 +160,15 @@ static int vgt_balloon_space(struct i915_ggtt *ggtt,
struct drm_mm_node *node,
unsigned long start, unsigned long end)
{
+ struct drm_i915_private *dev_priv = ggtt->vm.i915;
unsigned long size = end - start;
int ret;
if (start >= end)
return -EINVAL;
- DRM_INFO("balloon space: range [ 0x%lx - 0x%lx ] %lu KiB.\n",
+ drm_info(&dev_priv->drm,
+"balloon space: range [ 0x%lx - 0x%lx ] %lu KiB.\n",
start, end, size / 1024);
ret = i915_gem_gtt_reserve(&ggtt->vm, node,
size, start, I915_COLOR_UNEVICTABLE,
@@ -219,7 +225,8 @@ static int vgt_balloon_space(struct i915_ggtt *ggtt,
*/
int intel_vgt_balloon(struct i915_ggtt *ggtt)
{
- struct intel_uncore *uncore = &ggtt->vm.i915->uncore;
+ struct drm_i915_private *dev_priv = ggtt->vm.i915;
+ struct intel_uncore *uncore = &dev_priv->uncore;
unsigned long ggtt_end = ggtt->vm.total;
unsigned long mappable_base, mappable_size, mappable_end;
@@ -241,16 +248,18 @@ int intel_vgt_balloon(struct i915_ggtt *ggtt)
mappable_end = mappable_base + mappable_size;
unmappable_end = unmappable_base + unmappable_size;
- DRM_INFO("VGT ballooning configuration:\n");
- DRM_INFO("Mappable graphic memory: base 0x%lx size %ldKiB\n",
+ drm_info(&dev_priv->drm, "VGT ballooning configuration:\n");
+ drm_info(&dev_priv->drm,
+"Mappable graphic memory: base 0x%lx size %ldKiB\n",
mappable_base, mappable_size / 1024);
- DRM_INFO("Unmappable graphic memory: base 0x%lx size %ldKiB\n",
+ drm_info(&dev_priv->drm,
+"Unmappable graphic memory: base 0x%lx size %ldKiB\n",
unmappable_base, unmappable_size / 1024);
if (mappable_end > ggtt->mappable_end ||
unmappable_base < ggtt->mappable_end ||
unmappable_end > ggtt_end) {
- DRM_ERROR("Invalid ballooning configuration!\n");
[PATCH] drm/hisilicon: add the mode_valid function
add mode_valid function, and we can also use it to make suse the resolution
is valid.
Signed-off-by: Tian Tao
Signed-off-by: Gong junjie
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index 843d784..6cb7a79 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -242,6 +242,25 @@ static void hibmc_crtc_atomic_disable(struct drm_crtc
*crtc,
hibmc_set_current_gate(priv, reg);
}
+enum drm_mode_status hibmc_crtc_mode_valid(struct drm_crtc *crtc,
+ const struct drm_display_mode *mode)
+{
+ int i = 0;
+ int vrefresh = drm_mode_vrefresh(mode);
+
+ if (vrefresh < 59 || vrefresh > 61)
+ return MODE_NOMODE;
+
+ for (i = 0; i < ARRAY_SIZE(hibmc_pll_table); i++) {
+ if (hibmc_pll_table[i].hdisplay == mode->hdisplay &&
+ hibmc_pll_table[i].vdisplay == mode->vdisplay)
+ return MODE_OK;
+ }
+
+ return MODE_NOMODE;
+}
+
+
static unsigned int format_pll_reg(void)
{
unsigned int pllreg = 0;
@@ -510,6 +529,7 @@ static const struct drm_crtc_helper_funcs
hibmc_crtc_helper_funcs = {
.atomic_flush = hibmc_crtc_atomic_flush,
.atomic_enable = hibmc_crtc_atomic_enable,
.atomic_disable = hibmc_crtc_atomic_disable,
+ .mode_valid = hibmc_crtc_mode_valid,
};
int hibmc_de_init(struct hibmc_drm_private *priv)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] xf86drm: only include for FreeBSD build case
On 2020-01-09 16:18, Jani Nikula wrote: On Thu, 09 Jan 2020, Seung-Woo Kim wrote: The header is only required FreeBSD and GNU libc 2.30 starts to warn about Linux specific header deprecation. Only include for FreeBSD. Signed-off-by: Seung-Woo Kim --- xf86drmMode.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/xf86drmMode.c b/xf86drmMode.c index 207d7be..ff1d31d 100644 --- a/xf86drmMode.c +++ b/xf86drmMode.c @@ -42,9 +42,11 @@ #include #include #include +#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__) #ifdef HAVE_SYS_SYSCTL_H Not that I know anything about this, but shouldn't you instead fix HAVE_SYS_SYSCTL_H definition in configure stage to only be enabled on FreeBSD? BR, Jani. #include #endif +#endif /* defined (__FreeBSD__) || defined (__FreeBSD_kernel__) */ #include #include Hi! This fix looks OK on FreeBSD (I haven't had time to test), however, as has been pointed out, perhaps the change should go into the meson build script or configure instead. I don't know if other OSes (other BSDs primarily) need this as well. I'm pretty sure it's needed on DragonflyBSD at least. Perhaps keep the include for everything except Linux for the time being? Regards -- Niclas Zeising ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/i915: conversion to new logging macros in i915/intel_csr.c
Replace the use of printk and struct device based logging macros with
the new struct drm_device based logging macros in i915/intel_csr.c
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/intel_csr.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 09870a31b4f0..85e41db7dc0e 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -298,12 +298,14 @@ void intel_csr_load_program(struct drm_i915_private
*dev_priv)
u32 i, fw_size;
if (!HAS_CSR(dev_priv)) {
- DRM_ERROR("No CSR support available for this platform\n");
+ drm_err(&dev_priv->drm,
+ "No CSR support available for this platform\n");
return;
}
if (!dev_priv->csr.dmc_payload) {
- DRM_ERROR("Tried to program CSR with empty payload\n");
+ drm_err(&dev_priv->drm,
+ "Tried to program CSR with empty payload\n");
return;
}
@@ -636,16 +638,16 @@ static void csr_load_work_fn(struct work_struct *work)
intel_csr_load_program(dev_priv);
intel_csr_runtime_pm_put(dev_priv);
- DRM_INFO("Finished loading DMC firmware %s (v%u.%u)\n",
-dev_priv->csr.fw_path,
-CSR_VERSION_MAJOR(csr->version),
+ drm_info(&dev_priv->drm,
+"Finished loading DMC firmware %s (v%u.%u)\n",
+dev_priv->csr.fw_path, CSR_VERSION_MAJOR(csr->version),
CSR_VERSION_MINOR(csr->version));
} else {
- dev_notice(dev_priv->drm.dev,
+ drm_notice(&dev_priv->drm,
"Failed to load DMC firmware %s."
" Disabling runtime power management.\n",
csr->fw_path);
- dev_notice(dev_priv->drm.dev, "DMC firmware homepage: %s",
+ drm_notice(&dev_priv->drm, "DMC firmware homepage: %s",
INTEL_UC_FIRMWARE_URL);
}
@@ -712,7 +714,8 @@ void intel_csr_ucode_init(struct drm_i915_private *dev_priv)
if (i915_modparams.dmc_firmware_path) {
if (strlen(i915_modparams.dmc_firmware_path) == 0) {
csr->fw_path = NULL;
- DRM_INFO("Disabling CSR firmware and runtime PM\n");
+ drm_info(&dev_priv->drm,
+"Disabling CSR firmware and runtime PM\n");
return;
}
@@ -722,11 +725,12 @@ void intel_csr_ucode_init(struct drm_i915_private
*dev_priv)
}
if (csr->fw_path == NULL) {
- DRM_DEBUG_KMS("No known CSR firmware for platform, disabling
runtime PM\n");
+ drm_dbg_kms(&dev_priv->drm,
+ "No known CSR firmware for platform, disabling
runtime PM\n");
return;
}
- DRM_DEBUG_KMS("Loading %s\n", csr->fw_path);
+ drm_dbg_kms(&dev_priv->drm, "Loading %s\n", csr->fw_path);
schedule_work(&dev_priv->csr.work);
}
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/modes: tag unused variables to avoid warnings
On 1/7/20 2:24 PM, Thomas Zimmermann wrote: > Hi > > Am 10.12.19 um 11:24 schrieb Benjamin Gaignard: >> Some variables are set but never used. To avoid warning when compiling >> with W=1 and keep the algorithm like it is tag theses variables >> with _maybe_unused macro. >> >> Signed-off-by: Benjamin Gaignard > Acked-by: Thomas Zimmermann Applied on drm-misc-next. Thanks, Benjamin > >> --- >> changes in this version: >> - do not modify the code to remove the unused variables >>just prefix them with __maybe_unused macro. >> >> drivers/gpu/drm/drm_modes.c | 9 + >> 1 file changed, 5 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c >> index 88232698d7a0..70aed4e2990d 100644 >> --- a/drivers/gpu/drm/drm_modes.c >> +++ b/drivers/gpu/drm/drm_modes.c >> @@ -233,7 +233,7 @@ struct drm_display_mode *drm_cvt_mode(struct drm_device >> *dev, int hdisplay, >> /* 3) Nominal HSync width (% of line period) - default 8 */ >> #define CVT_HSYNC_PERCENTAGE 8 >> unsigned int hblank_percentage; >> -int vsyncandback_porch, vback_porch, hblank; >> +int vsyncandback_porch, __maybe_unused vback_porch, hblank; >> >> /* estimated the horizontal period */ >> tmp1 = HV_FACTOR * 100 - >> @@ -386,9 +386,10 @@ drm_gtf_mode_complex(struct drm_device *dev, int >> hdisplay, int vdisplay, >> int top_margin, bottom_margin; >> int interlace; >> unsigned int hfreq_est; >> -int vsync_plus_bp, vback_porch; >> -unsigned int vtotal_lines, vfieldrate_est, hperiod; >> -unsigned int vfield_rate, vframe_rate; >> +int vsync_plus_bp, __maybe_unused vback_porch; >> +unsigned int vtotal_lines, __maybe_unused vfieldrate_est; >> +unsigned int __maybe_unused hperiod; >> +unsigned int vfield_rate, __maybe_unused vframe_rate; >> int left_margin, right_margin; >> unsigned int total_active_pixels, ideal_duty_cycle; >> unsigned int hblank, total_pixels, pixel_freq; >> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/i915: convert to new logging macros in i915/intel_memory_region.c
Replace the use of printk based logging macros with the new struct
drm_device based logging macro in i915/intel_memory_region.c.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/intel_memory_region.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_memory_region.c
b/drivers/gpu/drm/i915/intel_memory_region.c
index d0d038b3cd79..6b5e9d88646d 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -265,7 +265,9 @@ int intel_memory_regions_hw_probe(struct drm_i915_private
*i915)
if (IS_ERR(mem)) {
err = PTR_ERR(mem);
- DRM_ERROR("Failed to setup region(%d) type=%d\n", err,
type);
+ drm_err(&i915->drm,
+ "Failed to setup region(%d) type=%d\n",
+ err, type);
goto out_cleanup;
}
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/Kconfig: add missing 'depends on DRM' for DRM_DP_CEC
On 1/8/20 6:42 PM, Daniel Vetter wrote: > On Wed, Jan 08, 2020 at 01:08:47PM +0100, Hans Verkuil wrote: >> On 12/6/19 12:26 PM, Hans Verkuil wrote: >>> Add a missing 'depends on DRM' for the DRM_DP_CEC config >>> option. Without that enabling DRM_DP_CEC will force CEC_CORE >>> to =y instead of =m if DRM=m as well. >>> >>> Signed-off-by: Hans Verkuil >> >> Daniel, can you review this? It's annoying that the cec core is >> compiled as part of the kernel when it can just be a module. > > Why did we even make this optional? Really worth it to compile out 4 > functions and some change? It's not about those few functions, it's because this enables the CEC framework as well (drivers/media/cec). If CEC is not needed, then disabling this saves a lot more code than the few functions in drm_dp_cec.c. CEC is an optional HDMI feature, so CEC support for HDMI input/output drivers is optional as well in the kernel config. Regards, Hans > > Anyway the one you really want here is CONFIG_DRM_KMS_HELPER, but that is > a selected variable, and you can't mix select and depends on because that > breaks Kconfig in hilarious ways. Or so I thought, but other public > symbols like this (e.g. DRM_FBDEV_EMULATION) do the same trick. So I guess > > Reviewed-by: Daniel Vetter > > But really, is all this complexity? > -Daniel > >> >> Regards, >> >> Hans >> >>> --- >>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig >>> index 1168351267fd..e8e478d6da9c 100644 >>> --- a/drivers/gpu/drm/Kconfig >>> +++ b/drivers/gpu/drm/Kconfig >>> @@ -163,6 +163,7 @@ config DRM_LOAD_EDID_FIRMWARE >>> >>> config DRM_DP_CEC >>> bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support" >>> + depends on DRM >>> select CEC_CORE >>> help >>> Choose this option if you want to enable HDMI CEC support for >>> >> > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] drm/radeon: have the callers of set_memory_*() check the return value
> On Jan 8, 2020, at 6:56 AM, Christian König wrote: > > Am 07.01.20 um 20:25 schrieb Tianlin Li: >> Right now several architectures allow their set_memory_*() family of >> functions to fail, but callers may not be checking the return values. >> If set_memory_*() returns with an error, call-site assumptions may be >> infact wrong to assume that it would either succeed or not succeed at >> all. Ideally, the failure of set_memory_*() should be passed up the >> call stack, and callers should examine the failure and deal with it. >> >> Need to fix the callers and add the __must_check attribute. They also >> may not provide any level of atomicity, in the sense that the memory >> protections may be left incomplete on failure. This issue likely has a >> few steps on effects architectures: >> 1)Have all callers of set_memory_*() helpers check the return value. >> 2)Add __must_check to all set_memory_*() helpers so that new uses do >> not ignore the return value. >> 3)Add atomicity to the calls so that the memory protections aren't left >> in a partial state. >> >> This series is part of step 1. Make drm/radeon check the return value of >> set_memory_*(). > > I'm a little hesitate merge that. This hardware is >15 years old and nobody > of the developers have any system left to test this change on. > > Would it be to much of a problem to just add something like: r = > set_memory_*(); (void)r; /* Intentionally ignored */. Thank you. I will fix that in patch 1 and remove patch 2 (since no need to fix the call sites to handle the retval). Best regards, Tianlin > Apart from that certainly a good idea to add __must_check to the functions. > > Regards, > Christian. > >> >> Tianlin Li (2): >> drm/radeon: have the callers of set_memory_*() check the return value >> drm/radeon: change call sites to handle return value properly. >> >> drivers/gpu/drm/radeon/r100.c| 3 ++- >> drivers/gpu/drm/radeon/radeon.h | 2 +- >> drivers/gpu/drm/radeon/radeon_gart.c | 22 ++ >> drivers/gpu/drm/radeon/rs400.c | 3 ++- >> 4 files changed, 23 insertions(+), 7 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH next] drm/i915/gtt: add missing include file asm/smp.h
Fix build error: lib/crypto/chacha.c: In function chacha_permute: lib/crypto/chacha.c:65:1: warning: the frame size of 3384 bytes is larger than 2048 bytes [-Wframe-larger-than=] } ^ Reported-by: Hulk Robot Signed-off-by: Chen Zhou --- drivers/gpu/drm/i915/gt/intel_ggtt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c b/drivers/gpu/drm/i915/gt/intel_ggtt.c index 1a2b5dc..9ef8ed8 100644 --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c @@ -6,6 +6,7 @@ #include #include +#include #include "intel_gt.h" #include "i915_drv.h" -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/msm: support firmware-name for zap fw
On Wed 08 Jan 10:48 PST 2020, Jordan Crouse wrote:
> On Tue, Jan 07, 2020 at 05:38:42PM -0800, Rob Clark wrote:
> > From: Rob Clark
> >
> > Since zap firmware can be device specific, allow for a firmware-name
> > property in the zap node to specify which firmware to load, similarly to
> > the scheme used for dsp/wifi/etc.
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/msm/adreno/adreno_gpu.c | 32 ++---
> > 1 file changed, 29 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > index 112e8b8a261e..aa8737bd58db 100644
> > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > @@ -26,6 +26,7 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const
> > char *fwname,
> > {
> > struct device *dev = &gpu->pdev->dev;
> > const struct firmware *fw;
> > + const char *signed_fwname = NULL;
> > struct device_node *np, *mem_np;
> > struct resource r;
> > phys_addr_t mem_phys;
> > @@ -58,8 +59,33 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu,
> > const char *fwname,
> >
> > mem_phys = r.start;
> >
> > - /* Request the MDT file for the firmware */
> > - fw = adreno_request_fw(to_adreno_gpu(gpu), fwname);
> > + /*
> > +* Check for a firmware-name property. This is the new scheme
> > +* to handle firmware that may be signed with device specific
> > +* keys, allowing us to have a different zap fw path for different
> > +* devices.
> > +*
> > +* If the firmware-name property is found, we bypass the
> > +* adreno_request_fw() mechanism, because we don't need to handle
> > +* the /lib/firmware/qcom/* vs /lib/firmware/* case.
> > +*
> > +* If the firmware-name property is not found, for backwards
> > +* compatibility we fall back to the fwname from the gpulist
> > +* table.
> > +*/
> > + of_property_read_string_index(np, "firmware-name", 0, &signed_fwname);
> > + if (signed_fwname) {
> > + fwname = signed_fwname;
> > + ret = request_firmware_direct(&fw, signed_fwname,
> > gpu->dev->dev);
> > + if (ret) {
> > + DRM_DEV_ERROR(dev, "could not load signed zap firmware:
> > %d\n", ret);
> > + fw = ERR_PTR(ret);
> > + }
> > + } else {
> > + /* Request the MDT file for the firmware */
> > + fw = adreno_request_fw(to_adreno_gpu(gpu), fwname);
> > + }
> > +
>
> Since DT seems to be the trend for target specific firmware names I think we
> should plan to quickly deprecate the legacy name and not require new targets
> to
> set it. If a zap node is going to be opt in then it isn't onerous to ask
> the developer to set the additional property for each target platform.
>
For the zap specifically I agree that it would be nice to require this
property, but for non-zap firmware it seems reasonable to continue with
the existing scheme.
Regards,
Bjorn
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH next v2] drm/i915/gtt: add missing include file asm/smp.h
Fix build error: drivers/gpu/drm/i915/gt/intel_ggtt.c: In function ggtt_restore_mappings: drivers/gpu/drm/i915/gt/intel_ggtt.c:1239:3: error: implicit declaration of function wbinvd_on_all_cpus; did you mean wrmsr_on_cpus? [-Werror=implicit-function-declaration] wbinvd_on_all_cpus(); ^~ wrmsr_on_cpus Reported-by: Hulk Robot Signed-off-by: Chen Zhou --- changes in v2: - correct build error messages. --- drivers/gpu/drm/i915/gt/intel_ggtt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c b/drivers/gpu/drm/i915/gt/intel_ggtt.c index 1a2b5dc..9ef8ed8 100644 --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c @@ -6,6 +6,7 @@ #include #include +#include #include "intel_gt.h" #include "i915_drv.h" -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument
Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit : On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven wrote: Hi Krzysztof, On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven wrote: On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski wrote: The ioread8/16/32() and others have inconsistent interface among the architectures: some taking address as const, some not. It seems there is nothing really stopping all of them to take pointer to const. Shouldn't all of them take const volatile __iomem pointers? It seems the "volatile" is missing from all but the implementations in include/asm-generic/io.h. As my "volatile" comment applies to iowrite*(), too, probably that should be done in a separate patch. Hence with patches 1-5 squashed, and for patches 11-13: Reviewed-by: Geert Uytterhoeven I'll add to this one also changes to ioreadX_rep() and add another patch for volatile for reads and writes. I guess your review will be appreciated once more because of ioreadX_rep() volatile should really only be used where deemed necessary: https://www.kernel.org/doc/html/latest/process/volatile-considered-harmful.html It is said: " ... accessor functions might use volatile on architectures where direct I/O memory access does work. Essentially, each accessor call becomes a little critical section on its own and ensures that the access happens as expected by the programmer." Christophe ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fb-cma-helpers: Fix include issue
On 12/3/19 5:49 PM, Benjamin Gaignard wrote: > Le mer. 20 nov. 2019 à 00:28, Benjamin Gaignard > a écrit : >> Exported functions prototypes are missing in drm_fb_cma_helper.c >> Include drm_fb_cma_helper to fix that issue. >> > Gentle ping to reviewers. > Thanks, > Benjamin I know that removing warnings is not a sexy task, but reviewers are welcome. Thanks, Benjamin > >> Signed-off-by: Benjamin Gaignard >> --- >> drivers/gpu/drm/drm_fb_cma_helper.c | 1 + >> include/drm/drm_fb_cma_helper.h | 2 ++ >> 2 files changed, 3 insertions(+) >> >> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c >> b/drivers/gpu/drm/drm_fb_cma_helper.c >> index c0b0f603af63..9801c0333eca 100644 >> --- a/drivers/gpu/drm/drm_fb_cma_helper.c >> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c >> @@ -9,6 +9,7 @@ >>* Copyright (C) 2012 Red Hat >>*/ >> >> +#include >> #include >> #include >> #include >> diff --git a/include/drm/drm_fb_cma_helper.h >> b/include/drm/drm_fb_cma_helper.h >> index 4becb09975a4..795aea1d0a25 100644 >> --- a/include/drm/drm_fb_cma_helper.h >> +++ b/include/drm/drm_fb_cma_helper.h >> @@ -2,6 +2,8 @@ >> #ifndef __DRM_FB_CMA_HELPER_H__ >> #define __DRM_FB_CMA_HELPER_H__ >> >> +#include >> + >> struct drm_framebuffer; >> struct drm_plane_state; >> >> -- >> 2.15.0 >> >> ___ >> 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/5] Use new logging macros in drm/i915
This patchset continues the conversion to using the new struct drm_device based logging macros in drm/i915. Wambui Karuga (5): drm/i915: conversion to new logging macros in i915/i915_vgpu.c drm/i915: conversion to new logging macros in i915/intel_csr.c drm/i915: conversion to new logging macros in i915/intel_device_info.c drm/i915: convert to new logging macros in i915/intel_gvt.c drm/i915: convert to new logging macros in i915/intel_memory_region.c drivers/gpu/drm/i915/i915_vgpu.c | 41 +- drivers/gpu/drm/i915/intel_csr.c | 24 +++-- drivers/gpu/drm/i915/intel_device_info.c | 25 +++-- drivers/gpu/drm/i915/intel_gvt.c | 13 --- drivers/gpu/drm/i915/intel_memory_region.c | 4 ++- 5 files changed, 64 insertions(+), 43 deletions(-) -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/hisilicon: Add the mode_valid function
add mode_valid function, we can make sure the resolution is valid.
Signed-off-by: Tian Tao
Signed-off-by: Gong junjie
Reviewed-by: Thomas Zimmermann
---
v2: declare hibmc_crtc_mode_valid as static.
Modify the return value of hibmc_crtc_mode_valid .
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index 843d784..675d629 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -242,6 +242,24 @@ static void hibmc_crtc_atomic_disable(struct drm_crtc
*crtc,
hibmc_set_current_gate(priv, reg);
}
+static enum drm_mode_status hibmc_crtc_mode_valid(struct drm_crtc *crtc,
+ const struct drm_display_mode *mode)
+{
+ int i = 0;
+ int vrefresh = drm_mode_vrefresh(mode);
+
+ if (vrefresh < 59 || vrefresh > 61)
+ return MODE_NOCLOCK;
+
+ for (i = 0; i < ARRAY_SIZE(hibmc_pll_table); i++) {
+ if (hibmc_pll_table[i].hdisplay == mode->hdisplay &&
+ hibmc_pll_table[i].vdisplay == mode->vdisplay)
+ return MODE_OK;
+ }
+
+ return MODE_BAD;
+}
+
static unsigned int format_pll_reg(void)
{
unsigned int pllreg = 0;
@@ -510,6 +528,7 @@ static const struct drm_crtc_helper_funcs
hibmc_crtc_helper_funcs = {
.atomic_flush = hibmc_crtc_atomic_flush,
.atomic_enable = hibmc_crtc_atomic_enable,
.atomic_disable = hibmc_crtc_atomic_disable,
+ .mode_valid = hibmc_crtc_mode_valid,
};
int hibmc_de_init(struct hibmc_drm_private *priv)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] dt-bindings: panel-simple: Add compatible for Sharp LS020B1DD01D
Add a compatible string for the Sharp LS020B1DD01D 2" HQVGA TFT LCD panel, and remove the old sharp,ls020b1dd01d.txt documentation which is now obsolete. Signed-off-by: Paul Cercueil --- .../bindings/display/panel/panel-simple.yaml | 2 ++ .../bindings/display/panel/sharp,ls020b1dd01d.txt| 12 2 files changed, 2 insertions(+), 12 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/panel/sharp,ls020b1dd01d.txt diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index c1a77d9105a2..f1fba1db382a 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -35,6 +35,8 @@ properties: - ampire,am800480r3tmqwa1h # GiantPlus GPM940B0 3.0" QVGA TFT LCD panel - giantplus,gpm940b0 +# Sharp LS020B1DD01D 2.0" HQVGA TFT LCD panel + - sharp,ls020b1dd01d backlight: true enable-gpios: true diff --git a/Documentation/devicetree/bindings/display/panel/sharp,ls020b1dd01d.txt b/Documentation/devicetree/bindings/display/panel/sharp,ls020b1dd01d.txt deleted file mode 100644 index e45edbc565a3.. --- a/Documentation/devicetree/bindings/display/panel/sharp,ls020b1dd01d.txt +++ /dev/null @@ -1,12 +0,0 @@ -Sharp 2.0" (240x160 pixels) 16-bit TFT LCD panel - -Required properties: -- compatible: should be "sharp,ls020b1dd01d" -- power-supply: as specified in the base binding - -Optional properties: -- backlight: as specified in the base binding -- enable-gpios: as specified in the base binding - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/omap: gem: Fix tearing with BO_TILED
* Matthijs van Duin [200106 10:07]: > On Sun, Jan 05, 2020 at 12:37:04PM -0800, Tony Lindgren wrote: > > 4. The issue I'm seeing with stellarium on droid4 may be a stride > >issue as about one out of 3 or 4 frames is OK and aligning to > >512 also fixes the issue maybe because it happens to make > >multiple frames align to 4096 > > Yeah if your buffers are 960 pixels wide (assuming the droid4's screen > is natively portrait) and 32bpp then 512-byte alignment suffices to > automatically make them 4KB alignment. Hmm sounds like I need to retest this. But doesn't 512-byte alignment only make the 960 pixels case 2KB aligned? > The most obvious thing I can think of that could do wrong is that it > might contiguously map the pages that cover each line, which is what > will happen if they use e.g. for_each_sg_page, but subsequently assume > that the stride in sgx virtual memory is ALIGN( width * cpp, PAGE_SIZE ) > without taking the offset of the buffer inside the mapping into account. OK > If each line is at most 4KB (i.e. 1024 pixels @ 32bpp) but each line > straddles an MMU page boundary, then the result would be that the even > lines of the frame are written to the top half of the buffer, causing it > to be scaled to 50% vertically, while the odd lines are "lost" (written > outside the buffer, either to a different buffer or unmapped tiler > memory). This sounds like what you described on irc? Yes this sounds like what I've been seeing. Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH next] drm/i915/gtt: add missing include file asm/smp.h
On 2020/1/8 21:44, Jani Nikula wrote: > On Wed, 08 Jan 2020, Chen Zhou wrote: >> Fix build error: >> lib/crypto/chacha.c: In function chacha_permute: >> lib/crypto/chacha.c:65:1: warning: the frame size of 3384 bytes is larger >> than 2048 bytes [-Wframe-larger-than=] >> } >> ^ > > IMO this needs a better explanation of why not having the include leads > to the above failure. > > BR, > Jani. > Sorry, i made a mistake. The error is as follows: drivers/gpu/drm/i915/gt/intel_ggtt.c: In function ggtt_restore_mappings: drivers/gpu/drm/i915/gt/intel_ggtt.c:1239:3: error: implicit declaration of function wbinvd_on_all_cpus; did you mean wrmsr_on_cpus? [-Werror=implicit-function-declaration] wbinvd_on_all_cpus(); ^~ wrmsr_on_cpus Thanks, Chen Zhou >> >> Reported-by: Hulk Robot >> Signed-off-by: Chen Zhou >> --- >> drivers/gpu/drm/i915/gt/intel_ggtt.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c >> b/drivers/gpu/drm/i915/gt/intel_ggtt.c >> index 1a2b5dc..9ef8ed8 100644 >> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c >> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c >> @@ -6,6 +6,7 @@ >> #include >> >> #include >> +#include >> >> #include "intel_gt.h" >> #include "i915_drv.h" > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC] ARM: dts: qcom: msm8974: add mdp5 iommu support
This adds preliminary IOMMU support for the MDP5 on msm8974. It appears
that the qcom-iommu driver in upstream can be used on this SoC. I marked
this patch as a RFC since the frame buffer becomes corrupted when I boot
the Nexus 5 phone with this patch:
https://raw.githubusercontent.com/masneyb/nexus-5-upstream/master/images/broken-mdp5-iommu.jpg
A quick note about the ranges of the context banks below: Based on the
downstream sources, I believe that the memory addresses should be mapped
out like this:
mdp_iommu: iommu@fd928000 {
reg = <0xfd928000 0x8000>;
ranges = <0 0xfd93 0x8000>;
...
iommu-ctx@0 {
reg = <0x0 0x1000>;
...
};
iommu-ctx@1000 {
reg = <0x1000 0x1000>;
...
};
iommu-ctx@2000 {
reg = <0x2000 0x1000>;
...
};
};
However, the qcom-iommu driver in upstream expects the first context
bank to exist at address 0x1000, and the address space identifier
(asid) to be greater than 0. See get_asid() and qcom_iommu_of_xlate()
in the upstream qcom-iommu.c driver. I put in the patch below what the
driver expects. I modified the driver in my local tree to allow the
mapping that I have above so that the extra 0x1000 of memory is mapped
into the global address space and still experience the same screen
corruption issue.
Downstream MSM 3.4 IOMMU dts snippet for reference:
https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm-iommu-v1.dtsi#L110
I'm hoping that someone that's more familiar with this hardware has a
suggestion for something to try.
Signed-off-by: Brian Masney
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 44 +
1 file changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 4b161b809dd5..2515a3bd4aa7 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -1305,6 +1305,46 @@ etm3_out: endpoint {
};
};
+ mdp_iommu: iommu@fd928000 {
+ compatible = "qcom,msm8974-iommu",
+"qcom,msm-iommu-v1";
+ reg = <0xfd928000 0x7000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #iommu-cells = <1>;
+ ranges = <0 0xfd92f000 0x9000>;
+
+ clocks = <&mmcc MDSS_AHB_CLK>,
+<&mmcc MDSS_AXI_CLK>;
+ clock-names = "iface",
+ "bus";
+
+ qcom,iommu-secure-id = <1>;
+
+ // mdp_0
+ iommu-ctx@1000 {
+ compatible = "qcom,msm-iommu-v1-ns";
+ reg = <0x1000 0x1000>;
+ interrupts = ;
+ };
+
+ // mdp_1
+ iommu-ctx@2000 {
+ compatible = "qcom,msm-iommu-v1-sec";
+ reg = <0x2000 0x1000>;
+ interrupts = ,
+;
+ };
+
+ // mdp_2
+ iommu-ctx@3000 {
+ compatible = "qcom,msm-iommu-v1-sec";
+ reg = <0x3000 0x1000>;
+ interrupts = ,
+;
+ };
+};
+
ocmem@fdd0 {
compatible = "qcom,msm8974-ocmem";
reg = <0xfdd0 0x2000>,
@@ -1427,6 +1467,10 @@ mdp: mdp@fd90 {
interconnects = <&mmssnoc MNOC_MAS_MDP_PORT0
&bimc BIMC_SLV_EBI_CH0>;
interconnect-names = "mdp0-mem";
+ iommus = <&mdp_iommu 1
+ &mdp_iommu 2
+ &mdp_iommu 3>;
+
ports {
#address-cells = <1>;
#size-cells = <0>;
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFT v1 3/3] drm/panfrost: Use the mali-supply regulator for control again
On Thu, Jan 9, 2020 at 12:31 PM Steven Price wrote:
>
> On 07/01/2020 23:06, Martin Blumenstingl wrote:
> > dev_pm_opp_set_rate() needs a reference to the regulator which should be
> > updated when updating the GPU frequency. The name of the regulator has
> > to be passed at initialization-time using dev_pm_opp_set_regulators().
> > Add the call to dev_pm_opp_set_regulators() so dev_pm_opp_set_rate()
> > will update the GPU regulator when updating the frequency (just like
> > we did this manually before when we open-coded dev_pm_opp_set_rate()).
>
> This patch causes a warning from debugfs on my firefly (RK3288) board:
>
> debugfs: Directory 'ffa3.gpu-mali' with parent 'vdd_gpu' already
> present!
>
> So it looks like the regulator is being added twice - but I haven't
> investigated further.
I *think* it's because the regulator is already fetched by the
panfrost driver itself to enable it
(the devfreq code currently does not support enabling the regulator,
it can only control the voltage)
I'm not sure what to do about this though
[...]
> > ret = dev_pm_opp_of_add_table(dev);
> > - if (ret)
> > + if (ret) {
> > +
> > dev_pm_opp_put_regulators(pfdev->devfreq.regulators_opp_table);
>
> If we don't have a regulator then regulators_opp_table will be NULL and
> sadly dev_pm_opp_put_regulators() doesn't handle a NULL argument. The
> same applies to the two below calls obviously.
good catch, thank you!
are you happy with the general approach here or do you think that
dev_pm_opp_set_regulators is the wrong way to go (for whatever
reason)?
Martin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.
On Thu, Jan 9, 2020 at 5:47 PM Ville Syrjälä wrote: > On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kleiner wrote: > > On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä < > ville.syrj...@linux.intel.com> > > wrote: > > > > > On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote: > > > > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote: > > > > > The panel reports 10 bpc color depth in its EDID, and the UEFI > > > > > firmware chooses link settings at boot which support enough > > > > > bandwidth for 10 bpc (324000 kbit/sec to be precise), but the > > > > > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible, > > > > > > Does it actually or do we just ignore the fact that it reports > 3.24Gbps? > > > > > > If it really reports 3.24 then we should be able to just add that to > > > dp_rates[] in intel_dp_set_sink_rates() and be done with it. > > > > > > Although we'd likely want to skip 3.24 unless it really is reported > > > as the max so as to not use that non-standard rate on other displays. > > > So would require a bit fancier logic for that. > > > > > > > > Was also my initial thought, but the DP_MAX_LINK_RATE reg reports 2.7 > Gbps > > as maximum. > > So dpcd[0x1] == 0xa ? > > Yes. [*] > What about the magic second version of DP_MAX_LINK_RATE at 0x2201 ? > Hmm. I guess we should already be reading that via > intel_dp_extended_receiver_capabilities(). > Yes, you do. [*] Well, i have to recheck on the machine. I started this work on the AMD side and checked what AMD DC gave me, haven't rechecked stuff under i915 that i already knew from AMD. Comparing the implementations, there's some peculiar differences that may matter: intel_dp_extended_receiver_capabilities() is more "paranoid" than AMD DC's retrieve_link_cap() function in deciding if the extended receiver caps are valid. Intels implementation copies only the first 6 Bytes of extended receiver caps into the dpcd[] arrays, whereas AMD copies 16 Bytes. Not sure about the differences, but one of you may wanna check why this is, and if it matters somehow. Btw. your proposed /* blah */ if (max_rate > ...) wouldn't work if dpcd[0x1] == 0xa, which it likely is [*]. AMD DC identified it as DP 1.1, eDP 1.3, and these extended caps seem to be only part of DP 1.3+ if i understand the comments in intel_dp_extended_receiver_capabilities() correctly. -mario > > -- > Ville Syrjälä > Intel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.
On Thu, Jan 09, 2020 at 06:57:14PM +0100, Mario Kleiner wrote: > On Thu, Jan 9, 2020 at 5:47 PM Ville Syrjälä > wrote: > > > On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kleiner wrote: > > > On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä < > > ville.syrj...@linux.intel.com> > > > wrote: > > > > > > > On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote: > > > > > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote: > > > > > > The panel reports 10 bpc color depth in its EDID, and the UEFI > > > > > > firmware chooses link settings at boot which support enough > > > > > > bandwidth for 10 bpc (324000 kbit/sec to be precise), but the > > > > > > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible, > > > > > > > > Does it actually or do we just ignore the fact that it reports > > 3.24Gbps? > > > > > > > > If it really reports 3.24 then we should be able to just add that to > > > > dp_rates[] in intel_dp_set_sink_rates() and be done with it. > > > > > > > > Although we'd likely want to skip 3.24 unless it really is reported > > > > as the max so as to not use that non-standard rate on other displays. > > > > So would require a bit fancier logic for that. > > > > > > > > > > > Was also my initial thought, but the DP_MAX_LINK_RATE reg reports 2.7 > > Gbps > > > as maximum. > > > > So dpcd[0x1] == 0xa ? > > > > > Yes. [*] > > > > What about the magic second version of DP_MAX_LINK_RATE at 0x2201 ? > > Hmm. I guess we should already be reading that via > > intel_dp_extended_receiver_capabilities(). > > > > Yes, you do. > > [*] Well, i have to recheck on the machine. I started this work on the AMD > side and checked what AMD DC gave me, haven't rechecked stuff under i915 > that i already knew from AMD. Comparing the implementations, there's some > peculiar differences that may matter: > > intel_dp_extended_receiver_capabilities() is more "paranoid" than AMD DC's > retrieve_link_cap() function in deciding if the extended receiver caps are > valid. Intels implementation copies only the first 6 Bytes of extended > receiver caps into the dpcd[] arrays, whereas AMD copies 16 Bytes. Not sure > about the differences, but one of you may wanna check why this is, and if > it matters somehow. > > Btw. your proposed > > /* blah */ > if (max_rate > ...) > > wouldn't work if dpcd[0x1] == 0xa, which it likely is [*]. AMD DC > identified it as DP 1.1, eDP 1.3, and these extended caps seem to be only > part of DP 1.3+ if i understand the comments in > intel_dp_extended_receiver_capabilities() correctly. Yeah, but you never know how creative they've been with the DPCD in such a propritary machine. A full DPCD dump from /dev/drm_dp_aux* would be nice. Can you file a bug an attach the DPCD dump there so we have a good reference on what we're talking about (also for future if/when someone eventually starts to wonder why we have such hacks in the code)? -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/amd/display: Reorder detect_edp_sink_caps before link settings read.
On 2020-01-09 10:20 a.m., Mario Kleiner wrote:
> read_current_link_settings_on_detect() on eDP 1.4+ may use the
> edp_supported_link_rates table which is set up by
> detect_edp_sink_caps(), so that function needs to be called first.
>
> Signed-off-by: Mario Kleiner
> Cc: Martin Leung
Reviewed-by: Harry Wentland
This also fixes our assumption that retrieve_link_cap is the first DPCD
reads we perform during detection.
Harry
> ---
> drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> index cef8c1ba9797..5ea4a1675259 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -817,8 +817,8 @@ static bool dc_link_detect_helper(struct dc_link *link,
> }
>
> case SIGNAL_TYPE_EDP: {
> - read_current_link_settings_on_detect(link);
> detect_edp_sink_caps(link);
> + read_current_link_settings_on_detect(link);
> sink_caps.transaction_type =
> DDC_TRANSACTION_TYPE_I2C_OVER_AUX;
> sink_caps.signal = SIGNAL_TYPE_EDP;
> break;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/amd/display: Allow current eDP link settings to override verified ones.
On 2020-01-09 10:20 a.m., Mario Kleiner wrote:
> If the current eDP link settings, as read from hw, provide a higher
> bandwidth than the verified_link_cap ones (= reported_link_cap), then
> override verified_link_cap with current settings.
>
> These initial current eDP link settings have been set up by
> firmware during boot, so they should work on the eDP panel.
> Therefore use them if the firmware thinks they are good and
> they provide higher link bandwidth, e.g., to enable higher
> resolutions / color depths.
>
This only works when taking over from UEFI, so on boot or resume from
hibernate. This wouldn't work on a normal suspend/resume.
Can you check if setting link->dc->config.optimize_edp_link_rate (see
first if statement in detect_edp_sink_caps) fixes this? I imagine we
need to read the reported settings from DP_SUPPORTED_LINK_RATES and fail
to do so.
Thanks,
Harry
> This fixes a problem found on the MacBookPro 2017 Retina panel:
>
> The panel reports 10 bpc color depth in its EDID, and the
> firmware chooses link settings at boot which support enough
> bandwidth for 10 bpc (324000 kbit/sec aka LINK_RATE_RBR2),
> but the DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps
> as possible, so verified_link_cap is only good for 2.7 Gbps
> and 8 bpc, not providing the full color depth of the panel.
>
> Signed-off-by: Mario Kleiner
> Cc: Alex Deucher
> ---
> drivers/gpu/drm/amd/display/dc/core/dc_link.c | 21 +++
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> index 5ea4a1675259..f3acdb8fead5 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -819,6 +819,27 @@ static bool dc_link_detect_helper(struct dc_link *link,
> case SIGNAL_TYPE_EDP: {
> detect_edp_sink_caps(link);
> read_current_link_settings_on_detect(link);
> +
> + /* If cur_link_settings provides higher bandwidth than
> + * verified_link_cap, then use cur_link_settings as new
> + * verified_link_cap, as it obviously works according to
> + * firmware boot setup.
> + *
> + * This has been observed on the Apple MacBookPro 2017
> + * Retina panel, which boots with a link setting higher
> + * than what dpcd[DP_MAX_LINK_RATE] claims as possible.
> + * Overriding allows to run the panel at 10 bpc / 30
> bit.
> + */
> + if (dc_link_bandwidth_kbps(link,
> &link->cur_link_settings) >
> + dc_link_bandwidth_kbps(link,
> &link->verified_link_cap)) {
> + DC_LOG_DETECTION_DP_CAPS(
> + "eDP current link setting bw %d kbps >
> verified_link_cap %d kbps. Override.",
> + dc_link_bandwidth_kbps(link,
> &link->cur_link_settings),
> + dc_link_bandwidth_kbps(link,
> &link->verified_link_cap));
> +
> + link->verified_link_cap =
> link->cur_link_settings;
> + }
> +
> sink_caps.transaction_type =
> DDC_TRANSACTION_TYPE_I2C_OVER_AUX;
> sink_caps.signal = SIGNAL_TYPE_EDP;
> break;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/2] dt-bindings: display: simple: Add Satoz panel
Hi Miquel. On Thu, Jan 09, 2020 at 07:40:36PM +0100, Miquel Raynal wrote: > Satoz is a Chinese TFT manufacturer. > Website: http://www.sat-sz.com/English/index.html > > Add the compatible for its SAT050AT40H12R2 5.0 inch LCD panel. > > Signed-off-by: Miquel Raynal Applied this and the following patch to drm-misc-next. I manually resolved the conflict in panel-simple.yaml. Thanks, Sam > --- > > Changes since v4: > * Drop the satoz,sat050at40h12r2.yaml file in favor of the very new > panel-simple.yaml common file. Just add the compatible there. > > Changes since v3: > * Added the missing ".yaml" suffix in the $id. > * Removed the unnecessary "contains" assertion about the compatible. > * Added a precision : there is no public specification for this panel > (known for the moment). > * Bindings checked with "make dt_binding_check" > > Changes since v2: > * None. > > Changes since v1: > * New patch > > .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > index 090866260f4f..8a9c37640dc0 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > @@ -33,6 +33,8 @@ properties: >- ampire,am-480272h3tmqw-t01h > # Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel >- ampire,am800480r3tmqwa1h > +# Satoz SAT050AT40H12R2 5.0" WVGA TFT LCD panel > + - satoz,sat050at40h12r2 > >backlight: true >enable-gpios: true > -- > 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
