Thanks for comments.
On 2014년 08월 05일 20:12, Thierry Reding wrote:
On Mon, Jul 28, 2014 at 06:09:58PM +0200, Andrzej Hajda wrote:
On 07/28/2014 04:00 AM, Inki Dae wrote:
This patch adds below two flags for LPM transfer, and it attaches LPM flags
to a msg in accordance with master's
On Wed, Aug 06, 2014 at 04:11:54PM +0900, Inki Dae wrote:
On 2014년 08월 05일 20:12, Thierry Reding wrote:
[...]
I think that low power mode is more often used for command transmission
(in host-driven mode). I'm not sure how much sense it really makes to
transmit video data in low power mode.
Hi Tomasz,
On Wed, Aug 6, 2014 at 1:35 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Vikas,
Please see my comments inline.
On 25.07.2014 13:49, Vikas Sajjan wrote:
Refactoring the pm.c to avoid using soc_is_exynos checks,
instead use the DT based lookup.
While at it, consolidate the
On 06.08.2014 14:58, Vikas Sajjan wrote:
On Wed, Aug 6, 2014 at 1:35 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
On 25.07.2014 13:49, Vikas Sajjan wrote:
[snip]
+
+ /* Disable USE_RETENTION of JPEG_MEM_OPTION */
+ tmp = pmu_raw_readl(EXYNOS5_JPEG_MEM_OPTION);
+ tmp =
Hi Tomasz,
On Wed, Aug 6, 2014 at 6:57 PM, Tomasz Figa t.f...@samsung.com wrote:
On 06.08.2014 14:58, Vikas Sajjan wrote:
On Wed, Aug 6, 2014 at 1:35 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
On 25.07.2014 13:49, Vikas Sajjan wrote:
[snip]
+
+ /* Disable USE_RETENTION of
Punit Agrawal punit.agra...@arm.com writes:
Hi,
There's no reason why the exynos PPMU can't be built as a module
except you need -
- The first patch exports the functions that are needed to build
devfreq drivers as modules.
- The second patch then converts the exynos PPMU devfreq driver
2014-08-06 16:43 GMT+09:00 Thierry Reding thierry.red...@gmail.com:
On Wed, Aug 06, 2014 at 04:11:54PM +0900, Inki Dae wrote:
On 2014년 08월 05일 20:12, Thierry Reding wrote:
[...]
I think that low power mode is more often used for command transmission
(in host-driven mode). I'm not sure how
On Wed, Jul 30, 2014 at 11:29:27PM +0200, Andreas Färber wrote:
Specification and existing device trees use vsys-l{1,2}-supply,
not vsys_l{1,2}-supply. Fix the example to match the specification.
Applied. I've previously reminded you to use subject lines appropraite
for the subsystem, please
On Thursday, July 24, 2014 09:04:02 AM Lukasz Majewski wrote:
Hi Rafael,
On Monday, July 21, 2014 09:02:34 AM Lukasz Majewski wrote:
This commit adds first regression test cpufreq_freq_test.sh for
the cpufreq subsystem.
First of all, I'm not seeing any explanation why this script
The Atmel maXTouch driver assumed that the IRQ type flags will
always be passed using platform data but this is not true when
booting using Device Trees. In these setups the interrupt type
was ignored by the driver when requesting an IRQ.
This means that it will fail if a machine specified other
The Atmel maXTouch driver allows to dynamically define the
event keycodes set that the device is capable of. This may
not be evident when reading the DT binding document so add
an example to make it easier to understand how this works.
Also, the current documentation says that the array limit
is
From: Sjoerd Simons sjoerd.sim...@collabora.co.uk
The Peach Pit and Pi boards have an Atmel maXTouch device.
Add the needed Device Tree nodes to support it.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
[javier.martinez: added linux,gpio-keymap property and changed IRQ type]
Hi Javier,
On 07.08.2014 02:48, Javier Martinez Canillas wrote:
The Atmel maXTouch driver assumed that the IRQ type flags will
always be passed using platform data but this is not true when
booting using Device Trees. In these setups the interrupt type
was ignored by the driver when
On Wed, Aug 6, 2014 at 10:08 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
+hsi2c_8 {
+ status = okay;
+ clock-frequency = 333000;
Doesn't it work at the more standard 400kHz i2c frequency?
--
To unsubscribe from this list: send the line unsubscribe
Hello Tomasz,
Thanks a lot for your feedback.
On 08/07/2014 03:14 AM, Tomasz Figa wrote:
Hi Javier,
Have you observed an actual failure due to this? I believe that
Yes, I found this issue since the driver was not taking into account the value
defined in the edge/level type cells from the
Hello Fabio,
On 08/07/2014 03:35 AM, Fabio Estevam wrote:
On Wed, Aug 6, 2014 at 10:08 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
+hsi2c_8 {
+ status = okay;
+ clock-frequency = 333000;
Doesn't it work at the more standard 400kHz i2c frequency?
Fabio,
On Wed, Aug 6, 2014 at 6:35 PM, Fabio Estevam feste...@gmail.com wrote:
On Wed, Aug 6, 2014 at 10:08 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
+hsi2c_8 {
+ status = okay;
+ clock-frequency = 333000;
Doesn't it work at the more standard 400kHz
17 matches
Mail list logo
