Re: etnaviv: PHYS_OFFSET usage
Hi Lucas,
On Wed, 2017-11-15 at 18:56 +0100, Lucas Stach wrote:
> Am Mittwoch, den 15.11.2017, 17:36 + schrieb Alexey Brodkin:
[snip]
> I'm not keen on having a private memory region for the GPU. Normally we
> just use the shared system CMA memory region (and we will point the
> linear memory window there on MC2.0 GPUs), which has the added benefit
> that we can map the contiguous framebuffers allocated by another device
> through the linear window, which is a crucial performance optimization
> for the MMUv1 GPUs.
>
> The only time where we really need to know the start of RAM is on MC1.0
> GPUs which have a hardware bug in the TS unit, so we try to avoid
> moving the linear window at all to work around that. In that case the
> PHYS_OFFSET check is really there to avoid the situation where the
> linear window would not allow any RAM to be reached at all. Then we
> need to move the window, but disable any TS functionality, impacting
> performance a lot.
Thanks a lot fro explanation!
> As MC1.0 GPUs are hopefully on the way out with new designs using MC2.0
> this shouldn't be much of a problem going forward. Maybe we can even
> simply solve this issue by just dropping the check if PHYS_OFFSET isn't
> defined.
I guess something like that should work then:
>8
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index fc9a6a83dfc7..5ad191a605e2 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -678,6 +678,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
goto fail;
}
+#ifdef PHYS_OFFSET
/*
* Set the GPU linear window to be at the end of the DMA window, where
* the CMA area is likely to reside. This ensures that we are able to
@@ -699,6 +700,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
gpu->memory_base = PHYS_OFFSET;
gpu->identity.features &= ~chipFeatures_FAST_CLEAR;
}
+#endif
ret = etnaviv_hw_reset(gpu);
if (ret) {
>8
> At least I hope VeriSilicon didn't sell you a MC1.0 part at
> this time...
Given "chipMinorFeatures0_MC20" bit is set for us I would think that we
indeed have MC2.0 in our chip.
-Alexey
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARC: Force disable IOC if ioc_enable=0
U-Boot enables and uses IOC so if we don't want to use it in the kernel
we need to _disable_ it for real. This is in comparison to what we do
today based on "ioc_enable" flag - if it is set to 0 we just
_dont_enable_ IOC which effectively keeps IOC alive and kicking.
Signed-off-by: Alexey Brodkin
---
arch/arc/mm/cache.c | 47 +++
1 file changed, 27 insertions(+), 20 deletions(-)
diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
index eee924dfffa6..b763c34aa6bc 100644
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -1149,6 +1149,10 @@ noinline void __init arc_ioc_setup(void)
{
unsigned int ioc_base, mem_sz;
+ /* Force disable IOC if it exists but we don't want to use it */
+ if (ioc_exists && !ioc_enable)
+ write_aux_reg(ARC_REG_IO_COH_ENABLE, 0);
+
/* Flush + invalidate + disable L1 dcache */
__dc_disable();
@@ -1156,31 +1160,34 @@ noinline void __init arc_ioc_setup(void)
if (read_aux_reg(ARC_REG_SLC_BCR))
slc_entire_op(OP_FLUSH_N_INV);
- /*
-* currently IOC Aperture covers entire DDR
-* TBD: fix for PGU + 1GB of low mem
-* TBD: fix for PAE
-*/
- mem_sz = arc_get_mem_sz();
+ /* Only setup IOC if we really want to use it */
+ if (ioc_exists && ioc_enable) {
+ /*
+* currently IOC Aperture covers entire DDR
+* TBD: fix for PGU + 1GB of low mem
+* TBD: fix for PAE
+*/
+ mem_sz = arc_get_mem_sz();
- if (!is_power_of_2(mem_sz) || mem_sz < 4096)
- panic("IOC Aperture size must be power of 2 larger than 4KB");
+ if (!is_power_of_2(mem_sz) || mem_sz < 4096)
+ panic("IOC Aperture size must be power of 2 larger than
4KB");
- /*
-* IOC Aperture size decoded as 2 ^ (SIZE + 2) KB,
-* so setting 0x11 implies 512MB, 0x12 implies 1GB...
-*/
- write_aux_reg(ARC_REG_IO_COH_AP0_SIZE, order_base_2(mem_sz >> 10) - 2);
+ /*
+* IOC Aperture size decoded as 2 ^ (SIZE + 2) KB,
+* so setting 0x11 implies 512MB, 0x12 implies 1GB...
+*/
+ write_aux_reg(ARC_REG_IO_COH_AP0_SIZE, order_base_2(mem_sz >>
10) - 2);
- /* for now assume kernel base is start of IOC aperture */
- ioc_base = CONFIG_LINUX_RAM_BASE;
+ /* for now assume kernel base is start of IOC aperture */
+ ioc_base = CONFIG_LINUX_RAM_BASE;
- if (ioc_base % mem_sz != 0)
- panic("IOC Aperture start must be aligned to the size of the
aperture");
+ if (ioc_base % mem_sz != 0)
+ panic("IOC Aperture start must be aligned to the size
of the aperture");
- write_aux_reg(ARC_REG_IO_COH_AP0_BASE, ioc_base >> 12);
- write_aux_reg(ARC_REG_IO_COH_PARTIAL, 1);
- write_aux_reg(ARC_REG_IO_COH_ENABLE, 1);
+ write_aux_reg(ARC_REG_IO_COH_AP0_BASE, ioc_base >> 12);
+ write_aux_reg(ARC_REG_IO_COH_PARTIAL, 1);
+ write_aux_reg(ARC_REG_IO_COH_ENABLE, 1);
+ }
/* Re-enable L1 dcache */
__dc_enable();
--
2.7.5
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARC: [plat-hsdk] Switch DisplayLink driver from fbdev to DRM
Currently there're 2 different implementations of the driver for DisplayLink USB2.0-to-HDMI/DVI adapters: older FBDEV and modern true DRM. We initially decided to use FBDEV version just because with it /dev/fbX is usable from user-space while in DRM version with DRM_FBDEV_EMULATION user-space cannot draw anything on a real screen, for more info read [1]. But today /dev/fbX is not that important as more and more software projects switch to use of DRI (/dev/dri/cardX). But what's even more important DRM driver allows building of complicated graphics processing chains. The most important for us is rendering of 3D on a dedicated GPU while outputting video through a simpler bitstreamer like DisplayLink. So let's use much more future-proof driver from now on. [1] https://lists.freedesktop.org/archives/dri-devel/2017-December/159519.html Signed-off-by: Alexey Brodkin --- arch/arc/configs/hsdk_defconfig | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arc/configs/hsdk_defconfig b/arch/arc/configs/hsdk_defconfig index 7b8f8faf8a24..ac6b0ed8341e 100644 --- a/arch/arc/configs/hsdk_defconfig +++ b/arch/arc/configs/hsdk_defconfig @@ -49,10 +49,11 @@ CONFIG_SERIAL_8250_DW=y CONFIG_SERIAL_OF_PLATFORM=y # CONFIG_HW_RANDOM is not set # CONFIG_HWMON is not set +CONFIG_DRM=y +# CONFIG_DRM_FBDEV_EMULATION is not set +CONFIG_DRM_UDL=y CONFIG_FB=y -CONFIG_FB_UDL=y CONFIG_FRAMEBUFFER_CONSOLE=y -CONFIG_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_HCD_PLATFORM=y CONFIG_USB_OHCI_HCD=y -- 2.7.5 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]
Hi Alexey, On 04-12-2017 17:29, Alexey Brodkin wrote: > > Indeed, in case of kmscube etnaviv is a renderer while UDL > outputs the picture on the screen. Thats nice :) Ok, from your logs I was not able to see anything wrong. X server does not error exit and Prime seems to be working in DRM ... Lets try one more thing: Enable all debug in DRM (drm.debug=0x3f) and try to correlate the log with the actions. i.e. [boot] [log] [x start] [log] [xclock start] [log] [glmark2-es2 start] [log] If that does not give any more info then maybe someone with better understanding of etnaviv, UDL and X can help (maybe cc X devel list also ...) Best Regards, Jose Miguel Abreu ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]
Hi Jose, On Tue, 2017-12-05 at 10:39 +, Jose Abreu wrote: > Hi Alexey, > > On 04-12-2017 17:29, Alexey Brodkin wrote: > > > > > > Indeed, in case of kmscube etnaviv is a renderer while UDL > > outputs the picture on the screen. > > Thats nice :) > > Ok, from your logs I was not able to see anything wrong. X server > does not error exit and Prime seems to be working in DRM ... > > Lets try one more thing: Enable all debug in DRM (drm.debug=0x3f) > and try to correlate the log with the actions. i.e. > > [boot] > [log] > [x start] > [log] > [xclock start] > [log] > [glmark2-es2 start] > [log] I think I have something like that. Below are extracts which show at least one difference I was able to find. And that difference is presence of "[drm:udl_drm_gem_mmap] flags = 0x1" in case of Xserver only. kmscube: -->8--- [drm:drm_crtc_helper_set_config] encoder changed, full mode switch [drm:drm_crtc_helper_set_config] crtc changed, full mode switch [drm:drm_crtc_helper_set_config] [CONNECTOR:30:DVI-I-1] to [CRTC:28:crtc-0] [drm:drm_crtc_helper_set_config] attempting to set mode from userspace [drm:drm_mode_debug_printmodeline] Modeline 44:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5 [drm:drm_crtc_helper_set_mode] [CRTC:28:crtc-0] [drm:drm_crtc_helper_set_mode] [ENCODER:29:TMDS-29] set [MODE:44:1920x1080] [drm] write mode info 153 [drm:drm_crtc_helper_set_config] Setting connector DPMS state to on [drm:drm_crtc_helper_set_config][CONNECTOR:30:DVI-I-1] set DPMS on [drm:udl_attach_dma_buf] [DEV:soc:gpu-subsystem] size:8355840 [drm:udl_map_dma_buf] [DEV:soc:gpu-subsystem] size:8355840 dir=0 etnaviv-gpu f009.gpu: virt 7104 phys 0x free 0x1ec0 stream link to 0x00a8 @ 0x2000 71042000 -->8--- X: -->8--- [drm:udl_drm_gem_mmap] flags = 0x1 [drm:drm_mode_addfb] [FB:43] [drm:drm_mode_setcrtc] [CRTC:28:crtc-0] [drm:drm_mode_setcrtc] [CONNECTOR:30:DVI-I-1] [drm:drm_crtc_helper_set_config] [drm:drm_crtc_helper_set_config] [CRTC:28:crtc-0] [FB:43] #connectors=1 (x y) (0 0) [drm:drm_crtc_helper_set_config] crtc has no fb, full mode set [drm:drm_crtc_helper_set_config] connector dpms not on, full mode switch [drm:drm_crtc_helper_set_config] encoder changed, full mode switch [drm:drm_crtc_helper_set_config] crtc changed, full mode switch [drm:drm_crtc_helper_set_config] [CONNECTOR:30:DVI-I-1] to [CRTC:28:crtc-0] [drm:drm_crtc_helper_set_config] attempting to set mode from userspace [drm:drm_mode_debug_printmodeline] Modeline 44:"" 0 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x0 0x5 [drm:drm_crtc_helper_set_mode] [CRTC:28:crtc-0] [drm:drm_crtc_helper_set_mode] [ENCODER:29:TMDS-29] set [MODE:44:] [drm] write mode info 153 [drm:drm_crtc_helper_set_config] Setting connector DPMS state to on [drm:drm_crtc_helper_set_config][CONNECTOR:30:DVI-I-1] set DPMS on [drm] write mode info 153 [drm:udl_attach_dma_buf] [DEV:soc:gpu-subsystem] size:8298496 [drm:udl_map_dma_buf] [DEV:soc:gpu-subsystem] size:8298496 dir=0 etnaviv-gpu f009.gpu: virt 7104 phys 0x free 0x1ec0 stream link to 0x01e8 @ 0x2000 71042000 -->8--- > If that does not give any more info then maybe someone with > better understanding of etnaviv, UDL and X can help From my note above about udl_drm_gem_mmap() being only used in case of Xserver I barely may conclude anything. Given my lack of knowledge of DRM guts especially when it comes to complicated cases with DMA buffer exports/imports I cannot say immediately if that's just improper implementation of udl_drm_gem_mmap() or not. Even though I do see some differences between implementation of file_operations->mmap() callback in UDL and say exynos_drm_gem_mmap() or qxl_mmap() it's not clear why this and that implementation was done. > (maybe cc X devel list also ...) Well at this point I think its purely a UDL driver problem because if we swap UDL to imx-drm on Wandboard everything works perfectly fine! -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]
On 05-12-2017 11:53, Alexey Brodkin wrote: > > From my note above about udl_drm_gem_mmap() being only used in case of Xserver > I barely may conclude anything. Given my lack of knowledge of DRM guts > especially > when it comes to complicated cases with DMA buffer exports/imports I cannot > say > immediately if that's just improper implementation of > udl_drm_gem_mmap() or not. > Even though I do see some differences between implementation of > file_operations->mmap() > callback in UDL and > say exynos_drm_gem_mmap() or qxl_mmap() it's not clear > why this and that implementation was done. Oh, I've seen this before. This is the same thing that arcpgu used to do in the mmap callback! Please comment out the call to update_vm_cache_attr() in the mmap callback and check if it works. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]
Hi Jose, On Tue, 2017-12-05 at 12:26 +, Jose Abreu wrote: > On 05-12-2017 11:53, Alexey Brodkin wrote: > > > > > > From my note above about udl_drm_gem_mmap() being only used in case of > > Xserver > > I barely may conclude anything. Given my lack of knowledge of DRM guts > > especially > > when it comes to complicated cases with DMA buffer exports/imports I cannot > > say > > immediately if that's just improper implementation of > > udl_drm_gem_mmap() or not. > > Even though I do see some differences between implementation of > > file_operations->mmap() > > callback in UDL and > > say exynos_drm_gem_mmap() or qxl_mmap() it's not clear > > why this and that implementation was done. > > Oh, I've seen this before. This is the same thing that arcpgu > used to do in the mmap callback! Please comment out the call to > update_vm_cache_attr() in the mmap callback and check if it works. Actually I did it as the first thing when I spotted it in udl_drm_gem_mmap(). But that made no difference at all :( -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
rsi_91x: Failed to read status register on failed authentication
Hi Amit,
I'm seeing quite a strange behavior of RedPine module.
It connects perfectly fine to one of access points but fails
to connect to another.
Moreover after that failure RSI driver starts to flood me with
messages saying:
->8
rsi_91x: rsi_sdio_check_buffer_status: Failed to read status register
->8
Below you may find details of my 2 experiments.
Note I use vanilla Linux kernel v4.14.4
Any ideas what could be wrong?
-Alexey
1. Working scenario
==
# cat /etc/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
network={
ssid="YYY"
psk="zzz"
}
# iw wlan0 scan
BSS 80:19:34:1f:5e:50(on wlan0) -- associated
TSF: 248634601 usec (0d, 00:04:08)
freq: 2412
beacon interval: 100 TUs
capability: ESS Privacy ShortSlotTime (0x0411)
signal: -31.00 dBm
last seen: 0 ms ago
Information elements from Probe Response frame:
SSID: YYY
Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
DS Parameter set: channel 1
ERP: Barker_Preamble_Mode
Extended supported rates: 24.0 36.0 48.0 54.0
RSN: * Version: 1
* Group cipher: CCMP
* Pairwise ciphers: CCMP
* Authentication suites: PSK
* Capabilities: 16-PTKSA-RC 1-GTKSA-RC (0x000c)
HT capabilities:
Capabilities: 0x1ec
HT20
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 3839 bytes
No DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 4 usec (0x05)
HT Max RX data rate: 300 Mbps
HT TX/RX MCS rate indexes supported: 0-15
HT operation:
* primary channel: 1
* secondary channel offset: no secondary
* STA channel width: 20 MHz
* RIFS: 0
* HT protection: no
* non-GF present: 1
* OBSS non-GF present: 0
* dual beacon: 0
* dual CTS protection: 0
* STBC beacon: 0
* L-SIG TXOP Prot: 0
* PCO active: 0
* PCO phase: 0
Extended capabilities: Extended Channel Switching, 6
WMM: * Parameter version 1
* BE: CW 15-1023, AIFSN 3
* BK: CW 15-1023, AIFSN 7
* VI: CW 7-15, AIFSN 2, TXOP 2976 usec
* VO: CW 3-7, AIFSN 2, TXOP 1472 usec
WPS: * Version: 1.0
* Wi-Fi Protected Setup State: 2 (Configured)
* Response Type: 3 (AP)
* UUID: 97b29264-d9a5-5551-88f9-62fbdacb7162
* Manufacturer:
* Model:
* Model Number:
* Serial Number:
* Primary Device Type: 0--0
* Device name:
* Config methods: Display, Keypad
* Unknown TLV (0x1049, 6 bytes): 00 37 2a 00 01 20
# ifconfig wlan0 up
rsi_91x: ===> Interface UP <===
rsi_91x: rsi_disable_ps: Cannot accept disable PS in PS_NONE state
IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
# wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant.conf
Successfully initialized wpa_supplicant
rfkill: Cannot open RFKILL control device
# wlan0: authenticate with 80:19:34:1f:5e:50
wlan0: send auth to 80:19:34:1f:5e:50 (try 1/3)
wlan0: authenticated
wlan0: associate with 80:19:34:1f:5e:50 (try 1/3)
wlan0: RX AssocResp from 80:19:34:1f:5e:50 (capab=0x411 status=0 aid=1)
IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
wlan0: associated
rsi_91x: rsi_hal_key_config: Cipher 0xfac04 key_type: 1 key_len: 16
rsi_91x: rsi_mac80211_set_key: RSI set_key
rsi_91x: rsi_hal_key_config: Cipher 0xfac04 key_type: 2 key_len: 16
rsi_91x: rsi_mac80211_set_key: RSI set_key
# udhcpc -i wlan0
udhcpc: started, v1.27.2
udhcpc: sending discover
udhcpc: sending select for 10.42.1.137
udhcpc: lease of 10.42.1.137 obtained, lease time 3600
deleting routers
adding dns 10.42.1.1
# ifconfig
loLink encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
wlan0 Link encap:Ethernet HWaddr 00:23:A7:65:9B:94
inet addr:10.42.1.137 Bcast:10.42.1.255 Mask:255.
Re: rsi_91x: Failed to read status register on failed authentication
On Tue, Dec 5, 2017 at 9:41 PM, Alexey Brodkin wrote: > Hi Amit, > > I'm seeing quite a strange behavior of RedPine module. > It connects perfectly fine to one of access points but fails > to connect to another. > > Moreover after that failure RSI driver starts to flood me with > messages saying: > ->8 > rsi_91x: rsi_sdio_check_buffer_status: Failed to read status register > ->8 > > Below you may find details of my 2 experiments. > Note I use vanilla Linux kernel v4.14.4 > > Any ideas what could be wrong? > Could you enable driver debug zones and share dmesg log for analysis? echo 0x > /sys/kernel/debug/phy0/debug_zone Regards, Amitkumar ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
