Hi,
Adding CC to Xiubo Li, Geert Uytterhoeven and Stephen Warren.
On Thursday, September 18, 2014, Dong Aisheng wrote,
On Wed, Sep 17, 2014 at 04:50:50PM +0530, Pankaj Dubey wrote:
Hi,
On Wednesday, September 17, 2014, Dong Aisheng Wrote,
+ regmap = regmap_init_mmio(NULL,
On Wed, Sep 17, 2014 at 6:41 PM, Daniel Drake dr...@endlessm.com wrote:
However there is *another* fb reference taken in
omap_plane_mode_set(). And my patch is modelled to do the same in
exynos-drm.
This is because omapdrm does _everything_ asynchrously, even plain
modesets. Unfortunately that
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 reference in the process.
if (tmp-old_fb)
Hello Doug, Andreas,
On 09/17/2014 05:47 PM, Doug Anderson wrote:
rtc@101E {
status = okay;
+ clocks = clock CLK_RTC, max77686 MAX77686_CLK_AP;
+ clock-names = rtc, rtc_src;
Wait, seriously? Snow is still using the rtc@101E
Hello Lee,
Thanks a lot for your feedback.
On 09/17/2014 06:23 PM, Lee Jones wrote:
mutex_lock(ec_dev-lock);
ret = ec_dev-cmd_xfer(ec_dev, msg);
+if (msg-result == EC_RES_IN_PROGRESS) {
+int i;
+struct cros_ec_command status_msg;
+struct
Hello Lee,
On 09/17/2014 06:31 PM, Lee Jones wrote:
-static const struct mfd_cell cros_devs[] = {
-{
-.name = cros-ec-keyb,
-.id = 1,
-.of_compatible = google,cros-ec-keyb,
-},
-{
-.name = cros-ec-i2c-tunnel,
-.id
Hi Pankaj,
One more question:
For example:
regmap_read()
_regmap_read()
2112 #ifdef LOG_DEVICE
2113 if (strcmp(dev_name(map-dev), LOG_DEVICE)
== 0)
2114 dev_info(map-dev, %x = %x\n,
reg, *val);
Hi,
[...]
please see regmap_get_val_endian called in regmap_init function.
static enum regmap_endian regmap_get_val_endian(struct device *dev,
const struct regmap_bus *bus,
const struct regmap_config
*config)
On Thu, Sep 18, 2014 at 11:33:26AM +0530, Pankaj Dubey wrote:
Hi,
Adding CC to Xiubo Li, Geert Uytterhoeven and Stephen Warren.
On Thursday, September 18, 2014, Dong Aisheng wrote,
On Wed, Sep 17, 2014 at 04:50:50PM +0530, Pankaj Dubey wrote:
Hi,
On Wednesday, September 17,
[...]
I think there should have been a check for NULL on dev in
regmap_get_val_endian, so that if dev pointer exist then only it makes
sense to get
endianness property from DT.
I will suggest following fix in regmap.c for this. With following fix I
tested it and it works well
on
Hi,
On September 18, 2014 1:26, Dong Aisheng wrote
On Thu, Sep 18, 2014 at 11:33:26AM +0530, Pankaj Dubey wrote:
Hi,
Adding CC to Xiubo Li, Geert Uytterhoeven and Stephen Warren.
On Thursday, September 18, 2014, Dong Aisheng wrote,
On Wed, Sep 17, 2014 at 04:50:50PM +0530, Pankaj
Hi,
On September 18, 2014, Li.Xiubo wrote,
Subject: RE: [PATCH v3] mfd: syscon: Decouple syscon interface from
platform
devices
[...]
I think there should have been a check for NULL on dev in
regmap_get_val_endian, so that if dev pointer exist then only it
makes sense to get
it would be nice if you could submit a patch to remove the
drivers from ASoC, then we can see if anybody complains.
Same thing for v3.17-rc5 and next-20140918. Let's see if we can remove
the goni or aquila with wm8994 driver.
Done on top of next-20140918. Untested.
-8-
From: Paul
Hi Ajay,
On Wednesday 17 September 2014 15:43:04 Ajay kumar wrote:
Hi Laurent,
Please find the latest series here:
http://www.spinics.net/lists/dri-devel/msg66740.html
Thank you. My comment was meant to be general though, not just for your patch
series.
On Wed, Sep 17, 2014 at 3:23 PM,
and in next-20140918.
Paul Bolle
--
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
the
drivers from ASoC, then we can see if anybody complains.
Also the same thing for v3.17-rc5 and next-20140918. So let's see if we
can remove this driver too.
Done on top of next-20140918. Again untested.
8
From: Paul Bolle pebo...@tiscali.nl
Commit 28c8331d386a (ARM: S5PV210
On Thu, Sep 18, 2014 at 03:06:59PM +0530, Pankaj Dubey wrote:
Hi,
On September 18, 2014 1:26, Dong Aisheng wrote
On Thu, Sep 18, 2014 at 11:33:26AM +0530, Pankaj Dubey wrote:
Hi,
Adding CC to Xiubo Li, Geert Uytterhoeven and Stephen Warren.
On Thursday, September 18, 2014,
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.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
Hi Inki,
I have tested this patch with trats
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
On Thu, 18 Sep 2014, Vivek Gautam wrote:
Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.
We also defer the probe for
Hello,
This is a second batch of cleanups patches for the mfd cros_ec
driver and its subdevices drivers. The first batch of cleanups
was posted by Doug Anderson [0] and have already been merged.
The patches were picked from the ChromeOS 3.8 kernel and after
these no cleanups patches for cros_ec
From: Doug Anderson diand...@chromium.org
If someone sends a EC_CMD_REBOOT_EC to the EC, the EC will likely be
unresponsive for quite a while. Add a delay to the end of the command
to prevent random failures of future commands.
NOTES:
* This could be optimized a bit by simply delaying the next
From: Andrew Bresticker abres...@chromium.org
When an EC command returns EC_RES_IN_PROGRESS, we need to query
the state of the EC until it indicates that it is no longer busy.
Do this in cros_ec_cmd_xfer() under the EC's mutex so that other
commands (e.g. keyboard, I2C passtru) aren't issued to
From: Andrew Bresticker abres...@chromium.org
Now that there's a central cros_ec_cmd_xfer(), move the locking
out of the SPI driver.
Signed-off-by: Andrew Bresticker abres...@chromium.org
Reviewed-by: Simon Glass s...@chromium.org
Signed-off-by: Javier Martinez Canillas
From: Andrew Bresticker abres...@chromium.org
Instead of having users of the ChromeOS EC call the interface-specific
cmd_xfer() callback directly, introduce a central cros_ec_cmd_xfer()
to use instead. This will allow us to put all the locking and retry
logic in one place instead of duplicating
From: Derek Basehore dbaseh...@chromium.org
Since the i2c bus can get wedged on the EC sometimes, set the number of retries
to 3. Since we un-wedge the bus immediately after the wedge happens, this is the
correct fix since only one transfer will fail.
Signed-off-by: Derek Basehore
Hi,
This patch series replaces the hardware registers abstractions in
the Exynos thermal driver by the usage of per-SoC type operations.
Such solution provides simpler, easier to understand code and
allows removal of ~250 LOCs (~11% of the whole source code) from
the driver. Some other driver
reg-emul_time_shift is used only in exynos_tmu_set_emulation()
and accessed only if TMU_SUPPORT_EMUL_TIME flag is set. This
flag is not set for Exynos4210 and Exynos5440 (reg-emul_time_shift
field is not even assigned in exynos[4210,5440]_tmu_registers
and is assigned to identical value for all
Factor out code for preparing TMU_CONTROL register value from
exynos_tmu_control() into get_con_reg().
This is a preparation for introducing per-SoC type tmu_control
method.
There should be no functional changes caused by this patch.
Cc: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Amit
Add -tmu_control method to struct exynos_tmu_data and use it
in exynos_tmu_control(). Then add -tmu_control implementations
for Exynos4210+ and Exynos5440. Finally remove no longer needed
reg-tmu_[ctrl,inten], reg-inten_rise[0,1,2,3]_shift and
reg-inten_fall0_shift abstractions.
There should be
__EXYNOS5420_TMU_DATA macro is now identical to __EXYNOS5260_TMU_DATA
one and can be removed.
There should be no functional changes caused by this patch.
Cc: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Amit Daniel Kachhap amit.dan...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
Add -tmu_read method to struct exynos_tmu_data and use it
in exynos_tmu_control(). Then add -tmu_read implementations
for Exynos4210, Exynos4412+ and Exynos5440. Finally remove
no longer needed reg-tmu_cur_temp abstractions.
There should be no functional changes caused by this patch.
Cc:
There is no longer need to share defines between exynos_tmu.c
and exynos_tmu_data.c (as they are now only used by the former
file) so move them accordingly. Then move externs for struct
exynos_tmu_init_data instances to exynos_tmu.h and remove no
longer needed exynos_tmu_data.h include.
There
Remove unused TMU_SUPPORT_MULTI_INST flag, no longer
needed TMU_SUPPORTS() macro and features field from
struct exynos_tmu_platform_data.
There should be no functional changes caused by this patch.
Cc: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Amit Daniel Kachhap amit.dan...@samsung.com
Replace pdata-test_mux check in get_con_reg() by explicitly
checking for SoC type.
Also since the used pdata-test_mux value is always identical
use it directly and remove pdata-test_mux completely.
There should be no functional changes caused by this patch.
Cc: Naveen Krishna Chatradhi
Replace TMU_SUPPORT_EMUL_TIME flag check in get_emul_con_reg()
by an explicit check for a SoC type (all SoC types except
Exynos4210 and Exynos5440 have TMU_SUPPORT_EMUL_TIME flag set
in their struct exynos_tmu_init_data instances).
There should be no functional changes caused by this patch.
Cc:
Replace TMU_SUPPORT_ADDRESS_MULTIPLE flag check in exynos_map_dt_data()
by an explicit check for a SoC type (only Exynos5420 with TRIMINFO
quirk and Exynos5440 have TMU_SUPPORT_ADDRESS_MULTIPLE flag set in
their struct exynos_tmu_init_data instances).
Please note that this requires moving SoC
Replace TMU_SUPPORT_EMULATION flag check in exynos_tmu_set_emulation()
by an explicit check for a SoC type (all SoC types except Exynos4210
have TMU_SUPPORT_EMULATION flag set in their struct exynos_tmu_init_data
instances).
There should be no functional changes caused by this patch.
Cc: Naveen
Replace TMU_SUPPORT_FALLING_TRIP flag check in
exynos[4210,5440]_tmu_control() by an explicit check
for a SoC type (all SoC types except Exynos4210 have
TMU_SUPPORT_FALLING_TRIP flag set in their struct
exynos_tmu_init_data instances).
There should be no functional changes caused by this patch.
Maximum theoretical size saving (i.e. with only Exynos5410
SoC support enabled in kernel config so all SoC dependend
Exynos thermal driver code was dropped) is 4096 bytes so
there is no much sense in keeping these ifdefs (especially
given that they are useless once the driver gets updated to
use
Add -tmu_clear_irqs method to struct exynos_tmu_data and
use it in exynos_tmu_work(). Then add -tmu_clear_irqs
implementations for Exynos4210+ and Exynos5440. Finally
remove no longer needed reg-tmu_int[stat,clear] abstractions
and struct exynos_tmu_registers instances.
There should be no
Factor out code for preparing EMUL_CON register value from
exynos_tmu_set_emulation() into get_emul_con_reg().
This is a preparation for introducing per-SoC type
tmu_set_emulation method.
There should be no functional changes caused by this patch.
Cc: Naveen Krishna Chatradhi
Add -tmu_set_emulation method to struct exynos_tmu_data and
use it in exynos_tmu_set_emulation(). Then add -tmu_set_emulation
implementations for Exynos4412+ and Exynos5440. Finally remove
no longer needed reg-emul_con abstraction.
There should be no functional changes caused by this patch.
Replace pdata-threshold_falling check for non-zero value in
exynos_tmu_initialize() by an explicit check for a SoC type
(all SoC types except Exynos5440 have pdata-threshold_falling
assigned to non-zero value in their struct exynos_tmu_registers
instances).
This is a preparation for introducing
Replace TMU_SUPPORT_READY_STATUS flag check in
exynos_tmu_initialize() by an explicit check for a SoC type
(all SoC types except Exynos5440 have TMU_SUPPORT_READY_STATUS
flag set in their struct exynos_tmu_init_data instances).
This is a preparation for introducing per-SoC type tmu_initialize
Factor out code for initializing data-temp_error[1,2] values
from exynos_tmu_initialize() into sanitize_temp_error().
This is a preparation for introducing per-SoC type tmu_initialize
method.
There should be no functional changes caused by this patch.
Cc: Naveen Krishna Chatradhi
Replace TMU_SUPPORT_TRIM_RELOAD flag check in exynos_tmu_initialize()
by an explicit check for a SoC type (only Exynos3250, Exynos4412 and
Exynos5250 have TMU_SUPPORT_READY_STATUS flag set in their struct
exynos_tmu_init_data instances). Please note that this requires
adding separate SoC type for
Factor out code for preparing threshold register value from
exynos_tmu_initialize() into get_th_reg().
This is a preparation for introducing per-SoC type tmu_initialize
method.
There should be no functional changes caused by this patch.
Cc: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc:
Add -tmu_initialize method to struct exynos_tmu_data and
use it in exynos_tmu_initialize(). Then add -tmu_initialize
implementations for Exynos4210, Exynos4412+ and Exynos5440.
Finally remove no longer needed reg-threshold_th[0,1],
reg-intclr_[fall,rise]_shift and reg-intclr_[rise,fall]_mask
reg-therm_trip_en_shift is used only in exynos_tmu_initialize()
and not accessed on Exynos4210 (also reg-therm_trip_en_shift is
not even assigned in exynos4210_tmu_registers but it is assigned
to identical value for all other SoC types) so the register
abstraction is not needed and can be removed.
reg-emul_temp_shift is used only in exynos_tmu_set_emulation()
and accessed only if TMU_SUPPORT_EMULATION flag is set. This
flag is not set for Exynos4210 (reg-emul_temp_shift field is
not even assigned in exynos4210_tmu_registers and is assigned
to identical value for all other SoC types) so the
reg-tmu_irqstatus is set to non-zero value only for Exynos5440
so replace check for non-zero value of reg-tmu_irqstatus by
explicitly checking for Exynos5440 SoC type. Then remove no
longer needed reg-tmu_irqstatus register abstraction.
There should be no functional changes caused by this patch.
reg-test_mux_addr_shift is used only if pdata-test_mux is
non-zero. pdata-test_mux is defined only on Exynos3250 and
Exynos4412 (other SoC types don't even have pdata-test_mux
entry assigned in their struct exynos_tmu_registers instances)
so the abstraction is not needed and can be removed.
reg-therm_trip_mode_shift and reg-therm_trip_mode_mask are
used only in exynos_tmu_control() and accessed only if
pdata-noise_cancel_mode is non-zero. pdata-noise_cancel
field is not defined on Exynos4210 (also therm_trip_mode_shift
and therm_trip_mode_mask entries are not even assigned in
Simplify HW_TRIP level setting in exynos_tmu_initialize() (don't
pretend that the current code is hardware and configuration
independent and just do SoC type check explicitly). Then remove
no longer needed reg-threshold_[th2,th3_l0_shift] abstractions
(only assigned for Exynos5440 in
reg-tmu_pmin is set to non-zero value only for Exynos5440
so replace check for non-zero value of reg-tmu_pmin by
explicitly checking for Exynos5440 SoC type. Then remove no
longer needed reg-tmu_pmin register abstraction.
There should be no functional changes caused by this patch.
Cc: Naveen
reg-triminfo_data is used only in exynos_tmu_initialize() and
the code has already different paths for Exynos5440 and other
SoC types (on which TRIMINFO_DATA register offset is identical)
so the register abstraction is not needed and can be removed.
There should be no functional changes caused by
reg-tmu_status is used only in exynos_tmu_initialize() and it
is accessed only if TMU_SUPPORT_READY_STATUS flag is set. This
flag is not set for Exynos5440 and TMU_STATUS register offset
is identical for all other SoC types so the abstraction is not
needed and can be removed.
There should be no
reg-triminfo_ctrl[] is used in only exynos_tmu_initialize() and
accessed only if TMU_SUPPORT_TRIM_RELOAD flag is set. This flag
is set only on Exynos3250, Exynos4412 and Exynos5250 (other SoC
types don't even have triminfo_ctrl[] entries assigned in their
struct exynos_tmu_registers instances) so
reg-threshold_temp is used only in exynos_tmu_initialize() and
is accessed only on Exynos4210 (other SoC types don't even have
threshold_temp entry assigned in their struct exynos_tmu_registers
instances) so the register abstraction is not needed and can be
removed.
There should be no functional
On Fri, Sep 12, 2014 at 04:26:30PM +0100, Naveen Krishna Chatradhi wrote:
From: Alim Akhtar alim.akh...@samsung.com
This patch adds the necessary Kconfig entries to enable
support for the ARMv8 based Exynos7 SoC.
Signed-off-by: Alim Akhtar alim.akh...@samsung.com
Signed-off-by: Naveen
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
.
No one objected, as far as I know.
Exactly the same references are still to be found in v3.17-rc3 and
next-20140903. Perhaps someone actually familiar with this matter (ie,
not me) could submit one or more patches that implement Tomasz'
proposal.
We're now at v3.17-rc5 and next-20140918
now at v3.17-rc5 and next-20140918 and nothing has changed. I
raised this issue the day it hit linux-next. After two months it's still
not fixed. Could anyone familiar with ARCH_S5PV210 please jump in?
Basically, it turned out that no respin was necessary and I didn't post
those two patches. Now
On Thu, Sep 18, 2014 at 11:43:29AM +0200, Paul Bolle wrote:
On Thu, 2014-09-04 at 18:02 +0200, Arnd Bergmann wrote:
I think it would be nice if you could submit a patch to remove the
drivers from ASoC, then we can see if anybody complains.
Same thing for v3.17-rc5 and next-20140918. Let's
if anybody complains.
Same thing for v3.17-rc5 and next-20140918. Let's see if we can remove
the goni or aquila with wm8994 driver.
Done on top of next-20140918. Untested.
-8-
From: Paul Bolle pebo...@tiscali.nl
Please follow the patch submission process
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 Thu, 18 Sep 2014, Javier Martinez Canillas wrote:
Hello Lee,
On 09/17/2014 06:31 PM, Lee Jones wrote:
-static const struct mfd_cell cros_devs[] = {
- {
- .name = cros-ec-keyb,
- .id = 1,
- .of_compatible = google,cros-ec-keyb,
- },
- {
-
Hi Andrzej,
On 09/18/2014 10:17 PM, Andrzej Hajda 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.
Signed-off-by: Andrzej Hajda
Thanks for testing. In that case I will post this change, as I feel this
should be
fixed irrespective of my syscon patch.
But as Xiubo pointed in another mail, it may still cause other issues.
Looking at regmap.c, there're still some other places using the device
pointer, e.g.
Hi Catalin,
--- Original Message ---
Sender : Catalin Marinascatalin.mari...@arm.com
Date : Sep 19, 2014 01:18 (GMT+09:00)
Title : Re: [PATCH v4 6/8] arm64: exynos7: Enable ARMv8 based Exynos7 (SoC)
support
On Fri, Sep 12, 2014 at 04:26:30PM +0100, Naveen Krishna Chatradhi wrote:
On Fri, Sep 19, 2014 at 11:38:03AM +0800, Xiubo Li-B47053 wrote:
Thanks for testing. In that case I will post this change, as I feel this
should be
fixed irrespective of my syscon patch.
But as Xiubo pointed in another mail, it may still cause other issues.
Looking at regmap.c,
[...]
create child: /dcsr@2000/dcsr-atbrepl@3a8000
create child: /dcsr@2000/dcsr-tsgen-ctrl@3a9000
create child: /dcsr@2000/dcsr-tsgen-read@3aa000
create child: /regulators/regulator@0
...
As default the Linux will create all the platform device for each DT
73 matches
Mail list logo
