On Fri, Sep 19, 2014 at 01:20:18PM +0800, Xiubo Li-B47053 wrote:
> [...]
> > >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
[...]
> >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 devic
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.
> > > > L
Hi Catalin,
> --- Original Message ---
> Sender : Catalin Marinas
> 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:
>> From: Alim Akht
> > 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
> > poi
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
> -
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
On Wed, Sep 10, 2014 at 10:37 AM, Sylwester Nawrocki
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 needed these settings co
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-
&
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
er (ie,
>> not me) could submit one or more patches that implement Tomasz'
>> proposal.
>
> We're 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 famil
x27;
> proposal.
We're 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?
Thanks,
Paul Bolle
--
To unsubscribe from this list: send
Hi Sylwester,
On Wed, Sep 10, 2014 at 10:37 AM, Sylwester Nawrocki
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 needed th
On Fri, Sep 12, 2014 at 04:26:30PM +0100, Naveen Krishna Chatradhi wrote:
> From: Alim Akhtar
>
> This patch adds the necessary Kconfig entries to enable
> support for the ARMv8 based Exynos7 SoC.
>
> Signed-off-by: Alim Akhtar
> Signed-off-by: Naveen Krishna Chatradhi
> Cc: Rob Herring
> Cc:
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->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->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
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_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->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
exy
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 exynos5440_t
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 patc
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.
T
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 th
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
Cc: Amit Daniel Kachhap
Cc:
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 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
Cc: Amit Dani
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
meth
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
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
Cc: Amit Daniel Ka
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 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 K
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 de
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: N
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 type
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.
C
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 fun
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
Cc: A
Hello Lee,
On 09/18/2014 09:49 AM, Javier Martinez Canillas wrote:
>>> int cros_ec_register(struct cros_ec_device *ec_dev)
>>> {
>>> struct device *dev = ec_dev->dev;
>>> + struct device_node *node = dev->of_node;
>>> int err = 0;
>>>
>>> if (ec_dev->din_size) {
>>> @@ -140,12 +1
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
Cc: Amit Daniel Kachhap
Cc: Lukasz Majewski
Cc: Eduardo Valentin
C
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: Nav
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 sho
__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
Cc: Amit Daniel Kachhap
Cc: Lukasz Majewski
Cc: Eduardo Valentin
Cc: Zhang Rui
Signed-off-by: Bartlomiej Zoln
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 shoul
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
Cc: Amit Daniel Kachhap
Cc: Luk
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
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 imp
From: Derek Basehore
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
Reviewed-by: Doug Anderson
Acked-by
From: Andrew Bresticker
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 it across the differen
From: Andrew Bresticker
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 the EC while
it is work
From: Andrew Bresticker
Now that there's a central cros_ec_cmd_xfer(), move the locking
out of the SPI driver.
Signed-off-by: Andrew Bresticker
Reviewed-by: Simon Glass
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Doug Anderson
Acked-by: Lee Jones
---
Changes since v1:
- Remove me
From: Doug Anderson
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 command
sent, but EC
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 ar
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
On Thu, Sep 18, 2014 at 12:39 AM, Daniel Vetter wrote:
> On Wed, Sep 17, 2014 at 6:41 PM, Daniel Drake 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.
>>
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
---
Hi Inki,
I have tested this patch with trats board, it looks OK.
As
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, Sept
you could submit a patch to remove 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
Comm
mitted its fixup to Mark and I think he will take it for v3.17.
What ever happened to that fixup? There are still (pointless) references
to MACH_SMDKC100 in v3.17-rc5 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
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 P
an not be set anymore.
> >
> [...]
>
> 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 see if we can remove
the goni or aquila with wm8994 driver.
Done on
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 sens
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 +05
[...]
> > 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 w
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, Sep
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
>
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);
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-tun
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;
>> +
71 matches
Mail list logo
