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
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
Hello,
Krzysztof Kozlowski wrote:
> On 28.08.2015 10:48, Jaehoon Chung wrote:
>> On 08/27/2015 09:26 PM, Krzysztof Kozlowski wrote:
>>> W dniu 27.08.2015 o 18:29, Jaehoon Chung pisze:
Currently vmmc's property is wrong.
If it needs to control two supplies, then it has to use vmmc/vqmmc-s
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.
Any chance that you might also take a look at the other hwcrypto stuff
on the SoC ('samsung,exynos4210-secss' compatible)?
With best wishes,
Tobias
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.
>
> Su
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:
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
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 wi
Hello Kamil,
this looks very good. I just tested the patchset on my ODROID-X2
(Exynos4412-based board) and the USB stability issues I mentioned to you
before (with the older patchset) seem to be gone.
All devices on the USB behave normally (mass storage, ethernet and
bluetooth).
With best wishe
|8
> 2 files changed, 39 insertions(+)
Tested-by: Tobias Jakobi
USB PHY was tested on an ODROID-X2 (Exynos4412 SoC) with patches from
Kamil's previous patchset to enable the usage of the new PHY in EHCI and
OCHI.
With best wishes,
Tobias
--
To unsubscribe from this lis
y.h |6 ++
> 2 files changed, 42 insertions(+), 9 deletions(-)
>
Tested-by: Tobias Jakobi
USB PHY was tested on an ODROID-X2 (Exynos4412 SoC) with patches from
Kamil's previous patchset to enable the usage of the new PHY in EHCI and
OCHI.
With best wishes,
Tobias
--
To unsubsc
eate mode 100644 Documentation/phy/samsung-usb2.txt
> create mode 100644 drivers/phy/phy-exynos4210-usb2.c
> create mode 100644 drivers/phy/phy-exynos4x12-usb2.c
> create mode 100644 drivers/phy/phy-samsung-usb2.c
> create mode 100644 drivers/phy/phy-samsung-usb2.h
>
Tested-by: Tobias
anged, 424 insertions(+)
> create mode 100644 drivers/phy/phy-exynos5250-usb2.c
>
Tested-by: Tobias Jakobi
USB PHY was tested on an ODROID-X2 (Exynos4412 SoC) with patches from
Kamil's previous patchset to enable the usage of the new PHY in EHCI and
OCHI.
With best wishes,
Tobia
3 and
> Trats2 boards.
I've tested this series on my Odroid-X2 (also Exynos4412) with
powersave, performance and ondemand governor. Scaling works like
expected, so no issues to report!
Tested-by: Tobias Jakobi
With best wishes,
Tobias
>
> Depends on:
> - next-20150730 branch of
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 to
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
>>
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,
>>>>
>>>&g
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 an
Javier Martinez Canillas wrote:
> Hello Kukjin,
>
> On Thu, May 14, 2015 at 3:00 PM, Kukjin Kim wrote:
>> On 05/14/15 21:15, Krzysztof Kozlowski wrote:
>>> Add Krzysztof Kozlowski as a co-maintainer of Samsung Exynos ARM
>>> architecture to review the patches. Patches will go as usual - picked up
Hello MyungJoo!
On 2015-02-24 02:22, MyungJoo Ham wrote:
Unless you are willing to wait for 2 minutes after the kernal hangs,
you may want to adjust "DEFAULT_HUNG_TASK_TIMEOUT" to shorter value
(120 --> 5 for 5 seconds). It seems that you've cut it off in the
middle
of that "120 sec" wait.
Th
Hello,
I've tested the series on my Odroid-X2 (by adapting the TRATS2 changes),
and so far I haven't seen any issues. With the system being idle one can
see that the 'simple_ondemand' devfreq governor clocks down both memory
busses to the lowest state.
With best wishes,
Tobias
--
To unsubscribe
Hello Chanwoo!
Chanwoo Choi wrote:
> As you thought, when maintaining lower clock of memory bus frequency,
> some issue related to multimedia feature will happen.
>
> Separately, We have to check the miminum lower clock for working of
> multimedia feature.
> and then multimedia or other IP have
Hello again,
Tobias Jakobi wrote
> I've tested the series on my Odroid-X2 (by adapting the TRATS2 changes),
> and so far I haven't seen any issues. With the system being idle one can
> see that the 'simple_ondemand' devfreq governor clocks down both memory
> buss
mmu_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()"
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,
>>
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
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 O
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,
>>>>>
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 driver.
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
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
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
> ---
> drivers/gpu/drm/exyno
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 app
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,
>
> La
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,
Tobia
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}()
>&g
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,
>>>>
>>>&
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월 20일
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 add
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,
>>>
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년
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
fined!
> 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" [driv
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 Lin
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 wondering
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
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 somethin
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.
>>
>
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 kernel
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 full
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 o
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]
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]. Th
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 (Exynos4412)
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 fo
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 w
;>
>> 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 so
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: _add_list_d
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".
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
>> appr
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 sen
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 opt
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 /p
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
64 matches
Mail list logo
