On Sun, Oct 19, 2014 at 9:32 PM, Chanwoo Choi cw00.c...@samsung.com wrote:
This patch adds the new clock driver of Exynos4415 SoC based on Cortex-A9
using common clock framework. The CMU (Clock Management Unit) of Exynos4415
controls PLLs(Phase Locked Loops) and generates system clocks for CPU,
On Sun, Oct 19, 2014 at 9:32 PM, Chanwoo Choi cw00.c...@samsung.com wrote:
This patch adds new exynos4415.dtsi to support Exynos4415 SoC
based on Cortex-A9 quad cores and includes following dt nodes:
There's a lot in common between your new exynos4415.dtsi and the
existing exynos4.dtsi.
Would
On Fri, Oct 24, 2014 at 7:34 AM, Marek Szyprowski
m.szyprow...@samsung.com wrote:
Well, I also thought about such approach, but there are some fundamental
differences:
interrupt and clock controllers are completely different. Using a common
exynos4.dtsi
and overriding them in every node will
Hi,
Thanks for looking into this.
On Wed, Oct 1, 2014 at 4:55 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
I think that comment is incorrect. If tcmp is written as -1UL then the
LED totally turns off. And there is nothing in the Exynos4412 manual
to suggest that -1UL should be set in the TCMP
On Thu, Oct 2, 2014 at 1:49 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
This is strange. I remember verifying various edge cases with a scope on
an Exynos4210-based Origen board and I don't recall any issues.
Unfortunately I don't have appropriate hardware to recheck this specific
case
On Wed, Oct 1, 2014 at 12:36 AM, Vivek Gautam gautam.vi...@samsung.com wrote:
One reason i doubt why it could be coming is because we are
specifically putting the
child after doing everything with it.
When we are getting the child node using for_each_available_child_of_node(),
which calls
with the following approach:
- as before, samsung_i2s_dai_probe() gates CDCLK by default
(no need for smartq_wm8987 to do this as well)
- platform drivers can gate/ungate CDCLK as necessary
(currently only odroidx2 needs to do this)
- i2s code has no other interaction with CDCLK
Signed-off-by: Daniel
, the machine immediately
reports a maximum temperature of 255C and triggers the thermal subsystem
to shut down the system.
This patch also enables the TMU on the ODROID boards via the appropriate
power supply.
Signed-off-by: Daniel Drake dr...@endlessm.com
---
arch/arm/boot/dts/exynos4412-odroid
Hi,
Booting 3.17-rc6 on ODROID-U2, I see this message:
ERROR: Bad of_node_put() on /ehci@1258/port@1
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc6-00376-g85cd8fd #1031
[c0016418] (unwind_backtrace) from [c0011f00] (show_stack+0x10/0x14)
[c0011f00] (show_stack) from [c08213fc]
On Thu, Sep 25, 2014 at 12:05 PM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
Just curious about the Exynos4x12 situation here.
You set the FIMC clocks as 176MHz, child of MPLL, which works for
ODROID with a divider:
880MHz MPLL / 5 = 176MHz
However, talking of recommended
On Thu, Sep 25, 2014 at 1:44 PM, Daniel Drake dr...@endlessm.com wrote:
AFAIK 880 MHz is recommended MPLL frequency for Exynos4412 EVT2.0, which
is revision of the Exynos4412 SoC the Odroid U3 boards are populated with.
You can read the main/sub revision information from the chip ID register
Hi Sylwester,
On Thu, Jul 10, 2014 at 10:11 AM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
Currently configuration of the CDCLK pad is being overwritten in
the i2s_shutdown() callback in order to gate the SoC output clock.
However if an ASoC machine driver doesn't restore that clock
On Fri, Sep 19, 2014 at 6:58 AM, Andrzej Hajda a.ha...@samsung.com wrote:
The patch replaces legacy functions
drm_plane_init() / drm_crtc_init() with
drm_universal_plane_init() and drm_crtc_init_with_planes().
It allows to replace fake primary plane with the real one.
Additionally the patch
On Thu, Sep 18, 2014 at 12:39 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Sep 17, 2014 at 6:41 PM, Daniel Drake dr...@endlessm.com wrote:
2. drm_mode_rmfb then calls drm_framebuffer_remove, which calls
drm_mode_set_config_internal() in order to turn off the CRTC, dropping
another
Hi Sylwester,
On Wed, Sep 10, 2014 at 10:37 AM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
The default mux and divider clocks are specified in device tree
so that the FIMC devices in Exynos4210 and Exynos4x12 SoCs are
clocked from recommended clock source and with maximum supported
On Wed, Sep 10, 2014 at 10:37 AM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
The default mux and divider clocks are specified in device tree
so that the FIMC devices in Exynos4210 and Exynos4x12 SoCs are
clocked from recommended clock source and with maximum supported
frequency. If
On Wed, Sep 17, 2014 at 1:44 AM, Joonyoung Shim jy0922.s...@samsung.com wrote:
It's problem to add this from commit 25c8b5c3048cb6c98d402ca8d4735ccf910f727c.
My patch moves that drm_framebuffer_reference() call to the plane
function which is called from crtc_mode_set context (and also called
in
On Wed, Sep 17, 2014 at 7:45 AM, Daniel Vetter dan...@ffwll.ch wrote:
I think fb refcounting in exynos is just plain busted. If you look at
other drivers the only place the refcount framebuffers or backing
storage objects is for pageflips to make sure the memory doesn't go
away while the hw is
Hi,
I'm using pwm-samsung on Exynos4412 for a variable-brightness LED.
When the LED is set to maximum brightness via the pwm-leds driver, we
arrive at pwm_samsung_config with duty_ns = period_ns, i.e. 100% duty
cycle.
This function does:
/* -1UL will give 100% duty. */
--tcmp;
On Tue, Sep 16, 2014 at 7:48 AM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
Clock list for s3c-rtc device:
- rtc : CLK_RTC of CLK_GATE_IP_PERIR is gate clock for RTC.
- rtc_src : XrtcXTI is 32.768.kHz source clock for RTC.
Is this RTC source clock needed for all Exynos SoCs?
It is
are not taken directly in crtc mode_set context,
but rather in the context of updating the plane, which also covers
flips. Like omapdrm we also unreference the old framebuffer here.
Signed-off-by: Daniel Drake dr...@endlessm.com
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 12 ++--
drivers
On Wed, Aug 20, 2014 at 8:18 AM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
More importantly I wonder if a design where a IRQ line is not
connected to the max77686 PMIC makes even sense. If such a design is
possible then the interrupt property should be optional but if not
then I
On Tue, Aug 19, 2014 at 8:40 PM, Olof Johansson o...@lixom.net wrote:
ODROID-U3 has been broken in mainline for quite a while. Have patches
been posted for this already?
http://arm-soc.lixom.net/bootlogs/mainline/v3.17-rc1/odroidu3-arm-exynos_defconfig.html
for one of the latest boots that
On Wed, Jul 9, 2014 at 2:23 PM, One Thousand Gnomes
gno...@lxorguk.ukuu.org.uk wrote:
I like the sound of going to the standard ttyS notation and only
providing ports for ones that exist, but is this userspace-visible
ttyS is 8250 compatible UARTS.
If the Samsung is not an 8250 compatible
On Fri, Jul 18, 2014 at 5:00 PM, Bartlomiej Zolnierkiewicz
b.zolnier...@samsung.com wrote:
Recent patch by Tomasz Figa (irqchip: gic: Fix core ID calculation
when topology is read from DT) fixed GIC driver to filter cluster ID
from values returned by cpu_logical_map() for SoCs having registers
the power usage, but the system seems as stable as before.
Tested-by: Daniel Drake dr...@endlessm.com
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Olof,
Thanks for joining the party here :)
On Fri, Jul 18, 2014 at 6:56 AM, Olof Johansson o...@lixom.net wrote:
Anyone got a simple writeup on the steps needed to boot, bl1/2 needed,
expected offset into eMMC for where it goes, etc?
on PMIC, otherwise the i2c
controller never sees an ACK. Strangely the other PMIC i2c slave (the
main one) works fine even without this delay. I Chose value 100 to
match the vendor kernel.
Signed-off-by: Daniel Drake dr...@endlessm.com
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 2 ++
1 file
The ODROID kernel shows that the PMIC interrupt line is hooked up
to pin GPX3-2.
This is needed for the max77686-irq driver to create the PMIC IRQ
domain, which is needed by max77686-rtc.
Signed-off-by: Daniel Drake dr...@endlessm.com
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 11
On Thu, Jul 10, 2014 at 5:15 PM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
On 08/07/14 11:15, Daniel Drake wrote:
Testing on ODROID-U2, v3 is not quite working for me, but v2 of the
patch was fine.
I boot up, run:
# speaker-test -c 2 -t wav
As soon as I hear the word front I press
Hi Bartlomiej,
On Wed, Jul 9, 2014 at 6:17 PM, Bartlomiej Zolnierkiewicz
b.zolnier...@samsung.com wrote:
This patch series adds support for AFTR idle mode on boards with
secure firmware enabled and allows EXYNOS cpuidle driver usage on
Exynos4x12 SoCs.
It has been tested on Trats2 board
Hi,
How can we move forward here?
On Thu, Jun 26, 2014 at 1:02 PM, Tomasz Figa t.f...@samsung.com wrote:
- basically Samsung UART already has its own namespace (ttySAC) and the
order inside it is well-defined - instance ID shall be the hardware
instance number as specified by documentation.
Hi Sylwester,
On Fri, Jul 4, 2014 at 2:13 PM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
This patch adds the sound subsystem driver for Odroid-X2 and
Odroid-U3 boards. The codec works in I2S master mode; there
are two separate audio routing paths defined, as there are
differences in the
Hi Sean,
While looking at the following commit I noticed something:
commit f041b257a8997c8472a1013e9f252c3e2a1d879e
Author: Sean Paul seanp...@chromium.org
Date: Thu Jan 30 16:19:15 2014 -0500
drm/exynos: Remove exynos_drm_hdmi shim
This commit changes how mixer_check_mode() is used. It
are
powered on and off.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Tested on ODROID-U2 with the internal LAN (which is a USB device), and
an external USB mouse connected via the internal USB hub.
Tested-by: Daniel Drake dr...@endlessm.com
--
To unsubscribe from this list: send the line
On Wed, Jun 25, 2014 at 12:43 PM, Tomasz Figa t.f...@samsung.com wrote:
Due to recently merged patches and previous merge conflicts, the Samsung
PM Debug functionality no longer can be enabled. This patch fixes
incorrect dependency of SAMSUNG_PM_DEBUG on an integer symbol and adds
missing
Hi Tomasz,
On Wed, Jun 25, 2014 at 5:18 PM, Tomasz Figa t.f...@samsung.com wrote:
On a numer of Exynos-based boards Linux kernel is running in non-secure
mode under a secure firmware. This means that certain operations need to
be handled in special way, with firmware assistance. System-wide
without power cycling
(it's nRESET pin is connected to P3V3).
I found that removing regulator-always-on from buck8_reg: BUCK8 in the
dts file fixes this problem.
Yes, that fixes the problem. Thanks!
Tested-by: Daniel Drake dr...@endlessm.com
--
To unsubscribe from this list: send the line
Hi,
On Tue, Jun 24, 2014 at 5:08 PM, Tomasz Figa t.f...@samsung.com wrote:
Tested on Odroid U3, with HSIC/USB hub using CLKOUT as reference clock,
with some additional patches.
for all the patches:
Tested-by: Daniel Drake dr...@endlessm.com
Tested on ODROID-U2 alongside
phy: phy-samsung
Hi Tomasz,
On Tue, Jun 24, 2014 at 2:57 PM, Tomasz Figa t.f...@samsung.com wrote:
ISP special clocks have dedicated gating registers and so MUX SRC_MASK
register should not be used. This patch fixes the problem of
Exynos4x12-based boards freezing on system suspend, because those
mux outputs
Hi Tomasz,
On Tue, Jun 24, 2014 at 2:57 PM, Tomasz Figa t.f...@samsung.com wrote:
Due to recently merged patches and previous merge conflicts, the Samsung
PM Debug functionality no longer can be enabled. This patch fixes
incorrect dependency of SAMSUNG_PM_DEBUG on an integer symbol and adds
On Mon, Jun 23, 2014 at 5:32 PM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
I could reproduce such behaviour on the U3 board, but only with u-boot
which sets the MPLL clock frequency (fout_mpll) to 880 MHz, rather
than 800 MHz, which was the case in my original environment.
All fout_mpll
sdhci_s3c_set_clock is called from sdhci_do_set_ios with interrupts
disabled, and this calls into sdhci_s3c_consider_clock().
The patch mmc: sdhci-s3c: Cache bus clock rates addressed some
scheduling while atomic in this function, but there are more issues
here, seen while testing 3.16-rc2 on
On Tue, Jun 24, 2014 at 1:54 PM, Kamil Debski k.deb...@samsung.com wrote:
The Exynos4412 USB 2.0 PHY hardware differs from the description provided
in the documentation. Some register bits have different function. This
patch fixes the defines of register bits and changes the way how phys are
On Wed, Jun 18, 2014 at 5:22 PM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
This series adds basic sound support for the Odroid X2/U3 boards.
It relies on specific Exynos Audio Subsystem clock parent and
frequencies being pre-configured.
My full testing git branch has been pushed to:
-by: Daniel Drake dr...@endlessm.com
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jun 17, 2014 at 10:25 AM, Marek Szyprowski
m.szyprow...@samsung.com wrote:
This patch adds support for common hardware modules available on all
Exynos4412-based Odroid boards, which already have complete support in
mainline kernel. This includes secure firmware calls, watchdog, g2d and
m.szyprow...@samsung.com
Checked that this conforms to the documented DT bindings.
Reviewed-by: Daniel Drake dr...@endlessm.com
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On Tue, Jun 17, 2014 at 10:25 AM, Marek Szyprowski
m.szyprow...@samsung.com wrote:
This patch moves some parts of exynos4412-odroidx.dts to common
exynos4412-odroid-common.dtsi file and adds support for Odroid X2 and
U2/U3 boards. X2 is same as X, but it has faster SoC module (1.7GHz
instead
Hi Tomasz,
On Tue, May 20, 2014 at 5:43 PM, Tomasz Figa t.f...@samsung.com wrote:
Since the block responsible for handling the pin is PMU, not CMU,
a separate driver, that binds to PMU node is required and acquires
all input clocks by standard DT clock look-up. This way we don't need
any
Hi Sean,
In your commit drm/exynos: hdmi: support extra resolutions using
drm_display_mode timings you added several more HDMI PHY configs to
exynos-drm. Thanks for that.
Can you explain where these magic numbers came from?
I'm interested in adding 85.5MHz for 1366x768 support.
Thanks,
Daniel
Hi,
linux-firmware git layout suggests that s5p-mfc firmware should be
installed to /lib/firmware/s5p-mfc and this is where distros seem to
be installing it.
However, the request_firmware calls in the s5p-mfc driver cause the
kernel to look for the firmware at /lib/firmware directly, and fail to
On Wed, Dec 18, 2013 at 2:43 AM, Daniel Vetter dan...@ffwll.ch wrote:
I think we can do it simpler. When you get a hpd interrupt you eventually
call drm_helper_hpd_irq_event which will update all the state and poke
connectors. I'd just create a delay_work which you launch from
hdmi_irq_thread
On Wed, Dec 18, 2013 at 1:58 PM, Daniel Kurtz djku...@chromium.org wrote:
+seanpaul
I think the problem is that the hdmi irq is really just an undebounced
gpio interrupt, and thus, it is firing way too soon.
The chromium kernel adds an excplicit 1.1 second timer to debounce hpd
between the
On Wed, Dec 18, 2013 at 2:18 PM, Daniel Drake dr...@endlessm.com wrote:
Yes, this looks very similar to the approach I tried earlier. I guess
the patch was written for the same reasons as well.
Sean, any objections to me taking your patch and sending it upstream?
http://git.chromium.org
On Mon, Dec 16, 2013 at 5:40 PM, Daniel Vetter dan...@ffwll.ch wrote:
Have a bit of logic in the exynos -detect function to re-try a 2nd
round of edid probing after each hdp interrupt if the first one
returns an -ENXIO. Only tricky part is to be careful with edge
detection so that userspace
On Thu, Dec 12, 2013 at 4:46 PM, Daniel Drake dr...@endlessm.com wrote:
What I feel we are missing here is an explanation for why the first
row of pixels is treated differently from the rest. Every value that I
tweak seems to have an effect on the first line (which was rendered
OK) as well
On Fri, Dec 13, 2013 at 9:46 AM, Daniel Drake dr...@endlessm.com wrote:
Lets just accept the fact that the first line of the output image is
rendered badly. Specifically, it has 257 black pixels added onto the
end of it. The following rows do not exhibit that problem.
To accept and ignore
Hi,
Thanks a lot for this exynos-drm commit:
commit 62747fe0ad5169a767987d9009e3398466555cde
Author: Sean Paul seanp...@chromium.org
Date: Tue Jan 15 08:11:08 2013 -0500
drm/exynos: hdmi: support extra resolutions using drm_display_mode timings
As you probably know, many people had
59 matches
Mail list logo