Re: [PATCH] Revert "ARM: dma-mapping: Set proper DMA ops in arm_iommu_detach_device()"

_iommu_detach_device(), the given device later ignored by >>> arch_setup_dma_ops() and stays with non-IOMMU dma_ops. >>> >>> Reported-by: Tobias Jakobi >>> Fixes: 1874619a7df4 "ARM: dma-mapping: Set proper DMA ops in >>> arm_iommu_detach_device()"

Re: [PATCH 0/6] devfreq: handle suspend/resume

Hey Lukasz, just wanted to say hi and thanks for picking this up. Sadly my work no longer permits me to spend time working on the kernel. Anyway, great that this issue finally gets solved! :) With best wishes, Tobias Lukasz Luba wrote: > Hi all, > > This patch set aims to address the issue

Re: [PATCH 0/6] devfreq: handle suspend/resume

Hey Lukasz, just wanted to say hi and thanks for picking this up. Sadly my work no longer permits me to spend time working on the kernel. Anyway, great that this issue finally gets solved! :) With best wishes, Tobias Lukasz Luba wrote: > Hi all, > > This patch set aims to address the issue

Re: [PATCH] clk: samsung: Remove unused mout_user_aclk400_mcuisp_p4x12 variable

Speaking of the ISP clocks driver, I wonder why this one was never merged? https://patches.linaro.org/patch/115531/ - Tobias Krzysztof Kozlowski wrote: > Remove unused 'mout_user_aclk400_mcuisp_p4x12' variable to fix GCC warning: > > drivers/clk/samsung/clk-exynos4412-isp.c:40:27: warning:

Re: [PATCH] clk: samsung: Remove unused mout_user_aclk400_mcuisp_p4x12 variable

Speaking of the ISP clocks driver, I wonder why this one was never merged? https://patches.linaro.org/patch/115531/ - Tobias Krzysztof Kozlowski wrote: > Remove unused 'mout_user_aclk400_mcuisp_p4x12' variable to fix GCC warning: > > drivers/clk/samsung/clk-exynos4412-isp.c:40:27: warning:

Re: [PATCH] [v2] drm/exynos: g2d: use monotonic timestamps

Hey Arnd, looks good to me! Reviewed-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de> - Tobias Arnd Bergmann wrote: > The exynos DRM driver uses real-time 'struct timeval' values > for exporting its timestamps to user space. This has multiple > problems: > > 1. si

Re: [PATCH] [v2] drm/exynos: g2d: use monotonic timestamps

Hey Arnd, looks good to me! Reviewed-by: Tobias Jakobi - Tobias Arnd Bergmann wrote: > The exynos DRM driver uses real-time 'struct timeval' values > for exporting its timestamps to user space. This has multiple > problems: > > 1. signed seconds overflow in y2038 > 2. t

Re: [PATCH] ARM: exynos: add machine description for ODROID-XU3/4

I don't think this approach scales at all. DietPi can just read the devicetree through sysfs and retrieve the compatible and/or model of the base node. - Tobias Dongjin Kim wrote: > This patch is to add the machine descriptions for ODROID-XU3/4 boards > in order to present the hardware name at

Re: [PATCH] ARM: exynos: add machine description for ODROID-XU3/4

I don't think this approach scales at all. DietPi can just read the devicetree through sysfs and retrieve the compatible and/or model of the base node. - Tobias Dongjin Kim wrote: > This patch is to add the machine descriptions for ODROID-XU3/4 boards > in order to present the hardware name at

Re: [PATCH] exynos: drm: use monotonic timestamps

Hello Arnd, I guess you could coordinate the IPP changes with Marek, who is rewriting the IPP subsystem anyway (added Marek to Cc). Here is the most recent IPPv2 series: https://www.spinics.net/lists/linux-samsung-soc/msg61066.html Concerning the G2D changes, I don't think anything in userspace

Re: [PATCH] exynos: drm: use monotonic timestamps

Hello Arnd, I guess you could coordinate the IPP changes with Marek, who is rewriting the IPP subsystem anyway (added Marek to Cc). Here is the most recent IPPv2 series: https://www.spinics.net/lists/linux-samsung-soc/msg61066.html Concerning the G2D changes, I don't think anything in userspace

Re: [PATCH v2] drm/exynos/dsi: Remove error handling for bridge_node DT parsing

Hello Hoegeun, my last question (does this regress the case "node required, but absent") still stands. Hoegeun Kwon wrote: > Remove the error handling of bridge_node because the bridge_node is > required optionally. I don't think a construction like that exists. Either it's required, or it's

Re: [PATCH v2] drm/exynos/dsi: Remove error handling for bridge_node DT parsing

Hello Hoegeun, my last question (does this regress the case "node required, but absent") still stands. Hoegeun Kwon wrote: > Remove the error handling of bridge_node because the bridge_node is > required optionally. I don't think a construction like that exists. Either it's required, or it's

Re: s3c24xx: Use devm_kcalloc() in s3c24xx_dma_probe()

SF Markus Elfring wrote: >>> WARNING: Prefer devm_kcalloc over devm_kzalloc with multiply >> For example. Also I just noticed some previous comment by Krzysztof that >> pointed that out already. >> >> My suggestion: One sentence describing that the current situation is. > > Why do you find the

Re: s3c24xx: Use devm_kcalloc() in s3c24xx_dma_probe()

SF Markus Elfring wrote: >>> WARNING: Prefer devm_kcalloc over devm_kzalloc with multiply >> For example. Also I just noticed some previous comment by Krzysztof that >> pointed that out already. >> >> My suggestion: One sentence describing that the current situation is. > > Why do you find the

Re: s3c24xx: Use devm_kcalloc() in s3c24xx_dma_probe()

SF Markus Elfring wrote: >>> * A multiplication for the size determination of a memory allocation >>> indicated that an array data structure should be processed. >>> Thus use the corresponding function "devm_kcalloc". >> I have trouble parsing that sentences. This looks like the typical >>

Re: s3c24xx: Use devm_kcalloc() in s3c24xx_dma_probe()

SF Markus Elfring wrote: >>> * A multiplication for the size determination of a memory allocation >>> indicated that an array data structure should be processed. >>> Thus use the corresponding function "devm_kcalloc". >> I have trouble parsing that sentences. This looks like the typical >>

Re: [PATCH 1/2] dmaengine: s3c24xx: Use devm_kcalloc() in s3c24xx_dma_probe()

Hello Markus, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 22 Apr 2017 23:00:23 +0200 > > * A multiplication for the size determination of a memory allocation > indicated that an array data structure should be processed. > Thus use the

Re: [PATCH 1/2] dmaengine: s3c24xx: Use devm_kcalloc() in s3c24xx_dma_probe()

Hello Markus, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 22 Apr 2017 23:00:23 +0200 > > * A multiplication for the size determination of a memory allocation > indicated that an array data structure should be processed. > Thus use the corresponding function "devm_kcalloc".

Re: [PATCH] drm/exynos: Print kernel pointers in a restricted form

Hello Andrzej, note that i had already pointed Krzysztof to that documentation in my previous mail. - Tobias Andrzej Hajda wrote: > Hi Tobias, > > On 14.03.2017 21:41, Tobias Jakobi wrote: >> Krzysztof Kozlowski wrote: >>> On Tue, Mar 14, 2017 at 08:17:35PM +0

Re: [PATCH] drm/exynos: Print kernel pointers in a restricted form

Hello Andrzej, note that i had already pointed Krzysztof to that documentation in my previous mail. - Tobias Andrzej Hajda wrote: > Hi Tobias, > > On 14.03.2017 21:41, Tobias Jakobi wrote: >> Krzysztof Kozlowski wrote: >>> On Tue, Mar 14, 2017 at 08:17:35PM +0

Re: [PATCH] drm/exynos: Print kernel pointers in a restricted form

Krzysztof Kozlowski wrote: > On Tue, Mar 14, 2017 at 08:17:35PM +0100, Tobias Jakobi wrote: >> Krzysztof Kozlowski wrote: >>> On Tue, Mar 14, 2017 at 08:01:41PM +0100, Tobias Jakobi wrote: >>>> Hello Krzysztof, >>>> >>>> I was

Re: [PATCH] drm/exynos: Print kernel pointers in a restricted form

Krzysztof Kozlowski wrote: > On Tue, Mar 14, 2017 at 08:17:35PM +0100, Tobias Jakobi wrote: >> Krzysztof Kozlowski wrote: >>> On Tue, Mar 14, 2017 at 08:01:41PM +0100, Tobias Jakobi wrote: >>>> Hello Krzysztof, >>>> >>>> I was

Re: [PATCH] drm/exynos: Print kernel pointers in a restricted form

Krzysztof Kozlowski wrote: > On Tue, Mar 14, 2017 at 08:01:41PM +0100, Tobias Jakobi wrote: >> Hello Krzysztof, >> >> I was wondering about the benefit of this. From a quick look these are >> all messages that end up in the kernel log / dmesg. >> >

Re: [PATCH] drm/exynos: Print kernel pointers in a restricted form

Krzysztof Kozlowski wrote: > On Tue, Mar 14, 2017 at 08:01:41PM +0100, Tobias Jakobi wrote: >> Hello Krzysztof, >> >> I was wondering about the benefit of this. From a quick look these are >> all messages that end up in the kernel log / dmesg. >> >

Re: [PATCH] drm/exynos: Print kernel pointers in a restricted form

Hello Krzysztof, I was wondering about the benefit of this. From a quick look these are all messages that end up in the kernel log / dmesg. IIRC %pK does nothing there, since dmest_restrict is supposed to be used to deny an unpriviliged user the access to the kernel log. Or am I missing

Re: [PATCH] drm/exynos: Print kernel pointers in a restricted form

Hello Krzysztof, I was wondering about the benefit of this. From a quick look these are all messages that end up in the kernel log / dmesg. IIRC %pK does nothing there, since dmest_restrict is supposed to be used to deny an unpriviliged user the access to the kernel log. Or am I missing

Re: [PATCH] serial: samsung: Continue to work if DMA request fails

Hello Krzysztof, Krzysztof Kozlowski wrote: > If DMA is not available (even when configured in DeviceTree), the driver > will fail the startup procedure thus making serial console not > available. > > For example this causes boot failure on QEMU ARMv7 (Exynos4210, SMDKC210): > [1.302575]

Re: [PATCH] serial: samsung: Continue to work if DMA request fails

Hello Krzysztof, Krzysztof Kozlowski wrote: > If DMA is not available (even when configured in DeviceTree), the driver > will fail the startup procedure thus making serial console not > available. > > For example this causes boot failure on QEMU ARMv7 (Exynos4210, SMDKC210): > [1.302575]

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

Alexandre Belloni wrote: > On 17/02/2017 at 13:45:44 +0100, Tobias Jakobi wrote: >>> The device tree is a representation of the hardware itself. The state >>> of the driver support doesn't change the hardware you're running on, >>> just like your BIOS/UEFI on x86 won'

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

Alexandre Belloni wrote: > On 17/02/2017 at 13:45:44 +0100, Tobias Jakobi wrote: >>> The device tree is a representation of the hardware itself. The state >>> of the driver support doesn't change the hardware you're running on, >>> just like your BIOS/UEFI on x86 won'

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

Hello Maxime, Maxime Ripard wrote: > Hi, > > On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote: >> I was wondering about the following. Wasn't there some strict >> requirement about code going upstream, which also included that there >> was a fu

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

Hello Maxime, Maxime Ripard wrote: > Hi, > > On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote: >> I was wondering about the following. Wasn't there some strict >> requirement about code going upstream, which also included that there >> was a fu

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

Hello, I was wondering about the following. Wasn't there some strict requirement about code going upstream, which also included that there was a full open-source driver stack for it? I don't see how this is the case for Mali, neither in the kernel, nor in userspace. I'm aware that the Mali

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

Hello, I was wondering about the following. Wasn't there some strict requirement about code going upstream, which also included that there was a full open-source driver stack for it? I don't see how this is the case for Mali, neither in the kernel, nor in userspace. I'm aware that the Mali

Re: [PATCH 2/7] PM / devfreq: exynos-ppmu: Use the regmap interface to handle the registers

Hello Chanwoo, sorry for the late reply. I was staying with my parents over the Christmas days and didn't have access to the board. Also internet connectivity was a bit troublesome *rolleyes* Chanwoo Choi wrote: > 2016-12-20 22:47 GMT+09:00 Tobias Jakobi <tjak...@math.uni-bielefeld.de>

Re: [PATCH 2/7] PM / devfreq: exynos-ppmu: Use the regmap interface to handle the registers

Hello Chanwoo, sorry for the late reply. I was staying with my parents over the Christmas days and didn't have access to the board. Also internet connectivity was a bit troublesome *rolleyes* Chanwoo Choi wrote: > 2016-12-20 22:47 GMT+09:00 Tobias Jakobi : >> Hey Chanwoo, >> >

Re: [PATCH 2/7] PM / devfreq: exynos-ppmu: Use the regmap interface to handle the registers

Hey Chanwoo, Chanwoo Choi wrote: > On 2016년 12월 20일 17:26, Chanwoo Choi wrote: >> On 2016년 12월 20일 17:08, Tobias Jakobi wrote: >>> Hello Chanwoo, >>> >>> >>> Chanwoo Choi wrote: >>>> Hi, >>>> >>>> On 2016년 12월 2

Re: [PATCH 2/7] PM / devfreq: exynos-ppmu: Use the regmap interface to handle the registers

Hey Chanwoo, Chanwoo Choi wrote: > On 2016년 12월 20일 17:26, Chanwoo Choi wrote: >> On 2016년 12월 20일 17:08, Tobias Jakobi wrote: >>> Hello Chanwoo, >>> >>> >>> Chanwoo Choi wrote: >>>> Hi, >>>> >>>> On 2016년 12월 2

Re: [PATCH 2/7] PM / devfreq: exynos-ppmu: Use the regmap interface to handle the registers

Hey Chanwoo, Chanwoo Choi wrote: > On 2016년 12월 20일 17:08, Tobias Jakobi wrote: >> Hello Chanwoo, >> >> >> Chanwoo Choi wrote: >>> Hi, >>> >>> On 2016년 12월 20일 04:47, Tobias Jakobi wrote: >>>> Hello, >>>> >>>&

Re: [PATCH 2/7] PM / devfreq: exynos-ppmu: Use the regmap interface to handle the registers

Hey Chanwoo, Chanwoo Choi wrote: > On 2016년 12월 20일 17:08, Tobias Jakobi wrote: >> Hello Chanwoo, >> >> >> Chanwoo Choi wrote: >>> Hi, >>> >>> On 2016년 12월 20일 04:47, Tobias Jakobi wrote: >>>> Hello, >>>> >>>&

Re: [PATCH 2/7] PM / devfreq: exynos-ppmu: Use the regmap interface to handle the registers

Hello Chanwoo, Chanwoo Choi wrote: > Hi, > > On 2016년 12월 20일 04:47, Tobias Jakobi wrote: >> Hello, >> >> I was just wondering what is improved by moving to regmap. For me this >> looks like it only complicates the code. Lots of regmap_{read,write}() >

Re: [PATCH 2/7] PM / devfreq: exynos-ppmu: Use the regmap interface to handle the registers

Hello Chanwoo, Chanwoo Choi wrote: > Hi, > > On 2016년 12월 20일 04:47, Tobias Jakobi wrote: >> Hello, >> >> I was just wondering what is improved by moving to regmap. For me this >> looks like it only complicates the code. Lots of regmap_{read,write}() >

Re: [PATCH 2/7] PM / devfreq: exynos-ppmu: Use the regmap interface to handle the registers

Hello, I was just wondering what is improved by moving to regmap. For me this looks like it only complicates the code. Lots of regmap_{read,write}() and for each one of these we need to check the return code. Also when exactly did __raw_writel() and friends become legacy? With best wishes,

Re: [PATCH 2/7] PM / devfreq: exynos-ppmu: Use the regmap interface to handle the registers

Hello, I was just wondering what is improved by moving to regmap. For me this looks like it only complicates the code. Lots of regmap_{read,write}() and for each one of these we need to check the return code. Also when exactly did __raw_writel() and friends become legacy? With best wishes,

Re: [PATCH v1 & v6 1/2] PM/devfreq: add suspend frequency support

Hey Chanwoo, Chanwoo Choi wrote: > 2016-12-18 0:13 GMT+09:00 Tobias Jakobi <tjak...@math.uni-bielefeld.de>: >> Hey guys, >> >> Chanwoo Choi wrote: >>> Hi Lin, >>> >>> 2016-11-24 18:54 GMT+09:00 Chanwoo Choi <cw00.c...@samsung.com>:

Re: [PATCH v1 & v6 1/2] PM/devfreq: add suspend frequency support

Hey Chanwoo, Chanwoo Choi wrote: > 2016-12-18 0:13 GMT+09:00 Tobias Jakobi : >> Hey guys, >> >> Chanwoo Choi wrote: >>> Hi Lin, >>> >>> 2016-11-24 18:54 GMT+09:00 Chanwoo Choi : >>>> Hi Lin, >>>> >>>> On 2016년

Re: [PATCH v1 & v6 1/2] PM/devfreq: add suspend frequency support

Hey guys, Chanwoo Choi wrote: > Hi Lin, > > 2016-11-24 18:54 GMT+09:00 Chanwoo Choi : >> Hi Lin, >> >> On 2016년 11월 24일 18:28, Chanwoo Choi wrote: >>> Hi Lin, >>> >>> On 2016년 11월 24일 17:34, hl wrote: Hi Chanwoo Choi, On 2016年11月24日 16:16, Chanwoo Choi

Re: [PATCH v1 & v6 1/2] PM/devfreq: add suspend frequency support

Hey guys, Chanwoo Choi wrote: > Hi Lin, > > 2016-11-24 18:54 GMT+09:00 Chanwoo Choi : >> Hi Lin, >> >> On 2016년 11월 24일 18:28, Chanwoo Choi wrote: >>> Hi Lin, >>> >>> On 2016년 11월 24일 17:34, hl wrote: Hi Chanwoo Choi, On 2016年11月24日 16:16, Chanwoo Choi wrote: > Hi Lin,

Re: commit 4dd1837d7589f468ed109556513f476e7a7f9121 breaks build

Hey Russell, thanks for the quick reply and looking into this! Added Nicolas Pitre to Cc since the ksym trim stuff came from him. Russell King - ARM Linux wrote: > On Sun, Nov 20, 2016 at 12:43:38PM +0100, Tobias Jakobi wrote: >> Hello Russell, >> >> Russell King - ARM

Re: commit 4dd1837d7589f468ed109556513f476e7a7f9121 breaks build

Hey Russell, thanks for the quick reply and looking into this! Added Nicolas Pitre to Cc since the ksym trim stuff came from him. Russell King - ARM Linux wrote: > On Sun, Nov 20, 2016 at 12:43:38PM +0100, Tobias Jakobi wrote: >> Hello Russell, >> >> Russell King - ARM

Re: commit 4dd1837d7589f468ed109556513f476e7a7f9121 breaks build

> ERROR: "_clear_bit" [drivers/gpu/arm/mali/maligpu.ko] undefined! > ERROR: "_test_and_clear_bit" [drivers/bluetooth/btusb.ko] undefined! > ERROR: "_test_and_set_bit" [drivers/bluetooth/btusb.ko] undefined! > ERROR: "_set_bit" [drivers/bluetooth/btusb.

Re: commit 4dd1837d7589f468ed109556513f476e7a7f9121 breaks build

> ERROR: "_clear_bit" [drivers/gpu/arm/mali/maligpu.ko] undefined! > ERROR: "_test_and_clear_bit" [drivers/bluetooth/btusb.ko] undefined! > ERROR: "_test_and_set_bit" [drivers/bluetooth/btusb.ko] undefined! > ERROR: "_set_bit" [drivers/bluetooth/btusb.

commit 4dd1837d7589f468ed109556513f476e7a7f9121 breaks build

Hello, this is a resend of my initial mail, see below, to Al Viro (which sadly was ignored). It's rc5 now, and this issue still remains. Putting some more lists on the Cc now. Reverting the commit still works for me. With best wishes, Tobias Hello Al, compiled a kernel on

commit 4dd1837d7589f468ed109556513f476e7a7f9121 breaks build

Hello, this is a resend of my initial mail, see below, to Al Viro (which sadly was ignored). It's rc5 now, and this issue still remains. Putting some more lists on the Cc now. Reverting the commit still works for me. With best wishes, Tobias Hello Al, compiled a kernel on

Re: [char-misc:char-misc-testing] warning

Hello Robin, I'm afraid I can't help you with that. The series was done as a request by Daniel Vetter, see here for reference: http://www.spinics.net/lists/dri-devel/msg113011.html I don't have any nouveau platform here. With best wishes, Tobias Robin van der Gracht wrote: > Hi Tobias, > >

Re: [char-misc:char-misc-testing] warning

Hello Robin, I'm afraid I can't help you with that. The series was done as a request by Daniel Vetter, see here for reference: http://www.spinics.net/lists/dri-devel/msg113011.html I don't have any nouveau platform here. With best wishes, Tobias Robin van der Gracht wrote: > Hi Tobias, > >

Re: [PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

Hello Shuah, Shuah Khan wrote: > On 10/19/2016 04:27 PM, Shuah Khan wrote: >> On 10/19/2016 08:16 AM, Inki Dae wrote: >>> Hi Shuah, >>> >>> 2016-10-13 8:11 GMT+09:00 Shuah Khan : Hi Inki, On 08/15/2016 10:40 PM, Inki Dae wrote: >> >> okay the

Re: [PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

Hello Shuah, Shuah Khan wrote: > On 10/19/2016 04:27 PM, Shuah Khan wrote: >> On 10/19/2016 08:16 AM, Inki Dae wrote: >>> Hi Shuah, >>> >>> 2016-10-13 8:11 GMT+09:00 Shuah Khan : Hi Inki, On 08/15/2016 10:40 PM, Inki Dae wrote: >> >> okay the very first commit that

Re: exynos-drm: display manager fails to start without IOMMU problem

Hello Shuah, just a short note that more misleading comments about default allocation flags can be found in libdrm. https://cgit.freedesktop.org/mesa/drm/tree/exynos/exynos_drm.c See e.g. the comment for exynos_bo_create(). In my opinion, the whole approach to _set_ a bit to get non-contigious

Re: exynos-drm: display manager fails to start without IOMMU problem

Hello Shuah, just a short note that more misleading comments about default allocation flags can be found in libdrm. https://cgit.freedesktop.org/mesa/drm/tree/exynos/exynos_drm.c See e.g. the comment for exynos_bo_create(). In my opinion, the whole approach to _set_ a bit to get non-contigious

Re: [PATCH v4 0/2] Exynos IOMMU: proper runtime PM support (use device dependencies)

Hello again, Tobias Jakobi wrote: > Hello Marek, > > I have applied the new version onto 4.8.0 but I'm seeing this Oops on > shutdown/reboot. However it only shows up with my non-debug config. sorry for the false alarm. That Oops on reboot was due to some other patch I had applied.

Re: [PATCH v4 0/2] Exynos IOMMU: proper runtime PM support (use device dependencies)

Hello again, Tobias Jakobi wrote: > Hello Marek, > > I have applied the new version onto 4.8.0 but I'm seeing this Oops on > shutdown/reboot. However it only shows up with my non-debug config. sorry for the false alarm. That Oops on reboot was due to some other patch I had applied.

Re: [PATCH] exynos-drm: Fix error messages to print flags and size

Hello, I think this patch was never picked up. So just a short 'ping' from my side. With best wishes, Tobias Shuah Khan wrote: > Fix exynos_drm_gem_create() error messages to include flags and size when > flags and size are invalid. > > Signed-off-by: Shuah Khan >

Re: [PATCH] exynos-drm: Fix error messages to print flags and size

Hello, I think this patch was never picked up. So just a short 'ping' from my side. With best wishes, Tobias Shuah Khan wrote: > Fix exynos_drm_gem_create() error messages to include flags and size when > flags and size are invalid. > > Signed-off-by: Shuah Khan > --- >

Re: [PATCH v4 0/2] Exynos IOMMU: proper runtime PM support (use device dependencies)

Hello Marek, I have applied the new version onto 4.8.0 but I'm seeing this Oops on shutdown/reboot. However it only shows up with my non-debug config. > [ 897.046373] Internal error: Oops: 8005 [#1] PREEMPT SMP ARM > [ 897.046652] Modules linked in: bridge stp llc bnep btrfs xor xor_neon

Re: [PATCH v4 0/2] Exynos IOMMU: proper runtime PM support (use device dependencies)

Hello Marek, I have applied the new version onto 4.8.0 but I'm seeing this Oops on shutdown/reboot. However it only shows up with my non-debug config. > [ 897.046373] Internal error: Oops: 8005 [#1] PREEMPT SMP ARM > [ 897.046652] Modules linked in: bridge stp llc bnep btrfs xor xor_neon

Re: [PATCH v3 0/2] Exynos IOMMU: proper runtime PM support (use device dependencies)

Hello Marek, I did some tests with the new version today. Sadly the reboot/shutdown issues are still present. Here's what appears on the UART last: > [ 399.538147] sd 0:0:0:0: [sda] Synchronizing SCSI cache > [ 404.970649] smsc95xx 1-2.1.1:1.0 eth0: Failed to read reg index > 0x0114: -110

Re: [PATCH v3 0/2] Exynos IOMMU: proper runtime PM support (use device dependencies)

Hello Marek, I did some tests with the new version today. Sadly the reboot/shutdown issues are still present. Here's what appears on the UART last: > [ 399.538147] sd 0:0:0:0: [sda] Synchronizing SCSI cache > [ 404.970649] smsc95xx 1-2.1.1:1.0 eth0: Failed to read reg index > 0x0114: -110

Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)

Hi Marek, Marek Szyprowski wrote: > Hi Tobias > > > On 2016-07-18 18:43, Tobias Jakobi wrote: >> Marek Szyprowski wrote: >>> On 2016-07-18 13:00, Tobias Jakobi wrote: >>>> Marek Szyprowski wrote: >>>>> On 2016-07-15 15:21, Tobias Jakobi

Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)

Hi Marek, Marek Szyprowski wrote: > Hi Tobias > > > On 2016-07-18 18:43, Tobias Jakobi wrote: >> Marek Szyprowski wrote: >>> On 2016-07-18 13:00, Tobias Jakobi wrote: >>>> Marek Szyprowski wrote: >>>>> On 2016-07-15 15:21, Tobias Jakobi

Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)

Hey Marek, Marek Szyprowski wrote: > Dear Tobias > > > On 2016-07-18 13:00, Tobias Jakobi wrote: >> Marek Szyprowski wrote: >>> On 2016-07-15 15:21, Tobias Jakobi wrote: >>>> Tobias Jakobi wrote: >>>>> Hello Marek, >>>>>

Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)

Hey Marek, Marek Szyprowski wrote: > Dear Tobias > > > On 2016-07-18 13:00, Tobias Jakobi wrote: >> Marek Szyprowski wrote: >>> On 2016-07-15 15:21, Tobias Jakobi wrote: >>>> Tobias Jakobi wrote: >>>>> Hello Marek, >>>>>

Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)

Hello Marek, Marek Szyprowski wrote: > Hi Tobias, > > > On 2016-07-15 15:21, Tobias Jakobi wrote: >> Tobias Jakobi wrote: >>> Hello Marek, >>> >>> I've tested the patchset on 4.7-rc7 and noticed that it breaks reboot on >>> my ODROID

Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)

Hello Marek, Marek Szyprowski wrote: > Hi Tobias, > > > On 2016-07-15 15:21, Tobias Jakobi wrote: >> Tobias Jakobi wrote: >>> Hello Marek, >>> >>> I've tested the patchset on 4.7-rc7 and noticed that it breaks reboot on >>> my ODROID

Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)

Tobias Jakobi wrote: > Hello Marek, > > I've tested the patchset on 4.7-rc7 and noticed that it breaks reboot on > my ODROID-X2. > > Going to check where exactly things break. Sadly it's the last patch where everything comes together: "iommu/exynos: Add proper runtime pm

Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)

Tobias Jakobi wrote: > Hello Marek, > > I've tested the patchset on 4.7-rc7 and noticed that it breaks reboot on > my ODROID-X2. > > Going to check where exactly things break. Sadly it's the last patch where everything comes together: "iommu/exynos: Add proper runtime pm

Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)

Hello Marek, I've tested the patchset on 4.7-rc7 and noticed that it breaks reboot on my ODROID-X2. Going to check where exactly things break. With best wishes, Tobias Marek Szyprowski wrote: > Hello, > > This patch series finally implements proper runtime PM support in Exynos > IOMMU

Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)

Hello Marek, I've tested the patchset on 4.7-rc7 and noticed that it breaks reboot on my ODROID-X2. Going to check where exactly things break. With best wishes, Tobias Marek Szyprowski wrote: > Hello, > > This patch series finally implements proper runtime PM support in Exynos > IOMMU

Re: [RFC v4 0/7] extcon: usb-gpio: fixes and improvements

Hello Krzysztof, just wanted to ask on which kernel branch the patchset is based on. At least for me the set doesn't apply cleanly to 4.7-rc4. With best wishes, Tobias Krzysztof Kozlowski wrote: > Hi, > > > Some time ago, Robert tried to add VBUS detection to extcon-usb-gpio > driver [1].

Re: [RFC v4 0/7] extcon: usb-gpio: fixes and improvements

Hello Krzysztof, just wanted to ask on which kernel branch the patchset is based on. At least for me the set doesn't apply cleanly to 4.7-rc4. With best wishes, Tobias Krzysztof Kozlowski wrote: > Hi, > > > Some time ago, Robert tried to add VBUS detection to extcon-usb-gpio > driver [1].

Re: [PATCH 1/2] drm/exynos: g2d: Add support for old S5Pv210 type

Hey Krzysztof, Krzysztof Kozlowski wrote: > On 05/24/2016 06:05 PM, Tobias Jakobi wrote: >> Hello Krzysztof, >> >> >> Krzysztof Kozlowski wrote: >>> On 05/24/2016 03:49 PM, Tobias Jakobi wrote: >>>> Hello Krzysztof, >>>> >>

Re: [PATCH 1/2] drm/exynos: g2d: Add support for old S5Pv210 type

Hey Krzysztof, Krzysztof Kozlowski wrote: > On 05/24/2016 06:05 PM, Tobias Jakobi wrote: >> Hello Krzysztof, >> >> >> Krzysztof Kozlowski wrote: >>> On 05/24/2016 03:49 PM, Tobias Jakobi wrote: >>>> Hello Krzysztof, >>>> >>

Re: [PATCH 1/2] drm/exynos: g2d: Add support for old S5Pv210 type

Hello Krzysztof, Krzysztof Kozlowski wrote: > On 05/24/2016 03:49 PM, Tobias Jakobi wrote: >> Hello Krzysztof, >> >> are you sure that these are the only differences. Because AFAIK there >> are quite a few more: >> - DMA submission of commands >>

Re: [PATCH 1/2] drm/exynos: g2d: Add support for old S5Pv210 type

Hello Krzysztof, Krzysztof Kozlowski wrote: > On 05/24/2016 03:49 PM, Tobias Jakobi wrote: >> Hello Krzysztof, >> >> are you sure that these are the only differences. Because AFAIK there >> are quite a few more: >> - DMA submission of commands >>

Re: [PATCH 1/2] drm/exynos: g2d: Add support for old S5Pv210 type

Hello Krzysztof, are you sure that these are the only differences. Because AFAIK there are quite a few more: - DMA submission of commands - blend mode / rounding - solid fill - YCrCb support - and probably more One would need to add least split the command list parser into a v3 and v41 version

Re: [PATCH 1/2] drm/exynos: g2d: Add support for old S5Pv210 type

Hello Krzysztof, are you sure that these are the only differences. Because AFAIK there are quite a few more: - DMA submission of commands - blend mode / rounding - solid fill - YCrCb support - and probably more One would need to add least split the command list parser into a v3 and v41 version

Re: [PATCH v5 00/21] PM / devferq: Add generic exynos bus frequency driver and new passive governor

On 2016년 03월 24일 13:25, Chanwoo Choi wrote: >>> Dear all, >>> >>> This patchset uses the DEVFREQ_TRANSITION_NOTIFIER notifier to connecth >>> devfreq device using ondemand governor and devfreq device using passive >>> governor. Also I fix the some issue report

Re: [PATCH v5 00/21] PM / devferq: Add generic exynos bus frequency driver and new passive governor

On 2016년 03월 24일 13:25, Chanwoo Choi wrote: >>> Dear all, >>> >>> This patchset uses the DEVFREQ_TRANSITION_NOTIFIER notifier to connecth >>> devfreq device using ondemand governor and devfreq device using passive >>> governor. Also I fix the some issue report

Re: Warnings for invalid VDD (sdhci-s3c)

Hello Krzysztof, I'm seeing a similar problem on my Odroid-X2. I've fixed the issue by letting sdhci_set_power() (in drivers/mmc/host/sdhci.c) handle MMC_VDD_28_29 as well. I'm not sure though what's the rationale behind only handling certain MMC_VDD_x values in the switch statement. With best

Re: Warnings for invalid VDD (sdhci-s3c)

Hello Krzysztof, I'm seeing a similar problem on my Odroid-X2. I've fixed the issue by letting sdhci_set_power() (in drivers/mmc/host/sdhci.c) handle MMC_VDD_28_29 as well. I'm not sure though what's the rationale behind only handling certain MMC_VDD_x values in the switch statement. With best

Re: [RFC PATCH] ARM: exynos_defconfig: Enable Samsung media platform drivers as modules

Hello Javier, I think the G2D and probably also the GSC v4l drivers should be left off, since they use the same resources as their DRM counterparts. With best wishes, Tobias Javier Martinez Canillas wrote: > There are a bunch of media platform drivers under drivers/media/platform/ > that are

Re: [RFC PATCH] ARM: exynos_defconfig: Enable Samsung media platform drivers as modules

Hello Javier, I think the G2D and probably also the GSC v4l drivers should be left off, since they use the same resources as their DRM counterparts. With best wishes, Tobias Javier Martinez Canillas wrote: > There are a bunch of media platform drivers under drivers/media/platform/ > that are

Re: [PATCH 2/2] ARM: dts: exynos: Enable SSS on Trats2

Hello Krzysztof, you can also add the node to the exynos4412-odroid-common dtsi. I have checked that it works properly on an X2. Thanks for patches and fixing that alignment issue! With best wishes, Tobias Krzysztof Kozlowski wrote: > Enable the Security SubSystem (SSS) on Trats2

Re: [PATCH 2/2] ARM: dts: exynos: Enable SSS on Trats2

Hello Krzysztof, you can also add the node to the exynos4412-odroid-common dtsi. I have checked that it works properly on an X2. Thanks for patches and fixing that alignment issue! With best wishes, Tobias Krzysztof Kozlowski wrote: > Enable the Security SubSystem (SSS) on Trats2

Re: [PATCH v4 00/20] PM / devferq: Add generic exynos bus frequency driver and new passive governor

Hello, I've applied the patchset to 4.5-rc4 and I'm now encountering two additional problems. The first related to debugfs entries, the second cocerning RCU locking. Here are the debugfs lines: exynos-bus bus_dmc: device_opp_debug_create_link: Failed to create link exynos-bus bus_dmc:

Re: [PATCH v4 00/20] PM / devferq: Add generic exynos bus frequency driver and new passive governor

Hello, I've applied the patchset to 4.5-rc4 and I'm now encountering two additional problems. The first related to debugfs entries, the second cocerning RCU locking. Here are the debugfs lines: exynos-bus bus_dmc: device_opp_debug_create_link: Failed to create link exynos-bus bus_dmc:

Re: [PATCH v4 00/20] PM / devferq: Add generic exynos bus frequency driver and new passive governor

Hey Chanwoo, Chanwoo Choi wrote: > Hi Tobias, > > On 2016년 01월 19일 18:13, Tobias Jakobi wrote: > Hello, > > I've tested this on my Odroid-X2 but ran into issues. Patch 08/20 > introduces some pr_info() to exynos_bus_probe(). > > In my case both max_state and fre

Re: [PATCH v4 00/20] PM / devferq: Add generic exynos bus frequency driver and new passive governor

Hey Chanwoo, Chanwoo Choi wrote: > Hi Tobias, > > On 2016년 01월 19일 18:13, Tobias Jakobi wrote: > Hello, > > I've tested this on my Odroid-X2 but ran into issues. Patch 08/20 > introduces some pr_info() to exynos_bus_probe(). > > In my case both max_state and fre

Re: [PATCH 0/3] ARM: dts: Enable Exynos RNG module

Hello Krzysztof, Krzysztof Kozlowski wrote: > On 20.10.2015 01:11, Tobias Jakobi wrote: >> Hello Krzysztof, >> >> I can confirm that this also works on a Odroid-X2, so I guess it's safe >> to enable the PRNG for all Exynos4412-based Odroid devices. > > Sure, I

  1   2   >