Hi,
On 01/30/2015 09:24 AM, Joonyoung Shim wrote:
> +Cc dri-devel ML.
>
> Hi Alban,
>
> On 01/30/2015 06:18 AM, Alban Browaeys wrote:
>> The hdmi outputs black screen only even though under the hood Xorg and
>> framebuffer console are fine : devices found and initialized, but
>> not a pixel out
Hi,
On 01/23/2015 09:43 PM, Gustavo Padovan wrote:
> From: Daniel Kurtz
>
> The 'mode' is the modeline information which specifies the ideal mode
> requested by the mode set initiator (usually userspace).
> The 'adjusted_mode' is the actual hardware mode after all the crtcs
> and encoders have h
+Cc Inki,
Hi,
On 01/23/2015 09:42 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> struct {fimd,mixer,vidi}_win_data was just keeping the same data
> as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
> directly.
>
> It changes how planes are created and remove .win_
+Cc Inki,
Hi,
On 01/23/2015 09:42 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> These functions were already removed by previous cleanup work, but these
> ones were left behind.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos_drm_crtc.h | 6 --
> 1 file
+Cc Inki,
Hi,
On 01/30/2015 02:10 AM, Gustavo Padovan wrote:
> From: Mandeep Singh Baines
>
> The goal of the change is to make sure we send the vblank event on the
> current vblank. My hope is to fix any races that might be causing flicker.
> After this change I only see a flicker in the trans
+Cc Inki,
Hi,
On 01/23/2015 09:42 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> The drm_file event_list hasn't been used anymore by exynos, so we don't
> need any code to clean it.
>
No, it is used from drm core e.g. drm_irq.c file.
Thanks.
> Signed-off-by: Gustavo Padovan
> ---
>
+Cc Inki,
Hi,
On 01/23/2015 09:42 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> exynos_plane_dpms(DRM_MODE_DPMS_ON) calls the win_enable()'s callback
> from the underlying layer. However neither one of these layers implement
> win_enable() - FIMD, Mixer and VIDI. Thus the call to exyno
+Cc Kukjin,
Hi,
On 01/29/2015 10:31 PM, Gustavo Padovan wrote:
> From: Prathyush K
>
> When VPLL clock of less than 140 MHz was used and all the three
> clocks - hdmiphy, hdmi, sclk_hdmi are disabled, the system hangs
> during S2R when HDMI is connected. Since we want to use a vpll
> clock of 7
Hi Sylwester,
On 01/29/2015 09:53 PM, Sylwester Nawrocki wrote:
> Hi Chanwoo,
>
> On 23/01/15 21:54, Chanwoo Choi wrote:
>> On Sat, Jan 24, 2015 at 2:40 AM, Sylwester Nawrocki
>> wrote:
>>> On 21/01/15 07:26, Chanwoo Choi wrote:
+/* list of all parent clock list */
>>>
+PNAME(mout_bus_
Dear Kukjin,
The patch(1-3) of this patchset is merged to linux-pm.git (Rafael J. Wysocki).
We can check it on following url:
-
https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=bleeding-edge&id=8bf997796bd9bc8e3f997f26cbac7dd2c6661a76
Could you please pick remaining pat
On Wednesday, January 28, 2015 02:16:52 PM Arnd Bergmann wrote:
> These came out of running randconfig build tests on ARM. The three
> patches are completely independent, so please apply what looks good.
>
> The two s3c patches are for old bugs and should go through the
> cpufreq tree.
>
> The ex
+Cc dri-devel ML.
Hi Alban,
On 01/30/2015 06:18 AM, Alban Browaeys wrote:
> The hdmi outputs black screen only even though under the hood Xorg and
> framebuffer console are fine : devices found and initialized, but
> not a pixel out.
>
> Commit 93bca243ec96 ("drm/exynos: remove struct exynos_dr
On 01/26/15 20:53, Krzysztof Kozlowski wrote:
> On pon, 2015-01-26 at 12:33 +0100, Bartlomiej Zolnierkiewicz wrote:
>> Hi,
>>
>> On Monday, January 26, 2015 09:16:48 AM Krzysztof Kozlowski wrote:
>>> On pią, 2015-01-23 at 17:24 +0100, Bartlomiej Zolnierkiewicz wrote:
The following patch adds c
On 01/25/15 06:49, Eduardo Valentin wrote:
> On Fri, Jan 23, 2015 at 01:09:53PM +0100, Lukasz Majewski wrote:
>> 1. Introduction
>>
>> Following patches aim to clean up the current implementation of the thermal
>> framework on Exynos devices.
>>
>> The main goal was to use a generic code for readin
On Thu, Jan 22, 2015 at 06:02:07PM +0530, Abhilash Kesavan wrote:
> Hi Lukasz,
>
> On Thu, Jan 22, 2015 at 2:31 PM, Lukasz Majewski
> wrote:
> > Hi Abhilash,
> >
> >> Hi Lukasz,
> >>
> >> On Mon, Jan 19, 2015 at 5:14 PM, Lukasz Majewski
> >> wrote:
> >> > The exynos_map_dt_data() function must
On Wed, Jan 28, 2015 at 04:28:40PM +0100, Lukasz Majewski wrote:
> This commit enables the cpufreq subsystem. Moreover, support for using
> CPU as a cooling device is provided.
>
> Signed-off-by: Lukasz Majewski
I dont see problems with this patch:
Acked-by: Eduardo Valentin
Again, it must g
On Wed, Jan 28, 2015 at 04:28:38PM +0100, Lukasz Majewski wrote:
> After Exynos TMU rework to use device tree for configuration this flag
> can be removed. It is not used anymore.
>
> Signed-off-by: Lukasz Majewski
I dont see problems with this patch:
Acked-by: Eduardo Valentin
This should go
On Wed, Jan 28, 2015 at 04:28:39PM +0100, Lukasz Majewski wrote:
> Enabling thermal emulation on Exynos SoCs. New sysfs attribute - emul_temp
> is created.
>
> Signed-off-by: Lukasz Majewski
I dont see problems with this patch:
Acked-by: Eduardo Valentin
> ---
> arch/arm/configs/exynos_defco
Hello Arnd and Viresh,
On Thu, Jan 29, 2015 at 01:42:32PM +0100, Arnd Bergmann wrote:
> On Thursday 29 January 2015 15:40:15 Viresh Kumar wrote:
> > obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o
> > obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
> > -obj-$(CONFIG_ARM_EX
On Thu, Jan 29, 2015 at 09:34:27AM +0900, Kukjin Kim wrote:
> Hi,
>
> This is another Samsung DT updates for v3.20. Since including a clock
> patch with Mike and Sylwester's acks so sending separate pull-request.
>
> Please pull and if any problems please let me know.
>
> Thanks,
> Kukjin
>
>
On Thu, Jan 29, 2015 at 09:34:14AM +0900, Kukjin Kim wrote:
> Hi,
>
> This is 2nd Samsung DT updates for v3.20, please pull.
>
> Thanks,
> Kukjin
>
>
> The following changes since commit 23c76dc666471dce5ce71b620839d2465723a7c9:
>
> ARM: dts: Configure regulators for suspend on exynos Peach
On Thu, Jan 29, 2015 at 09:33:52AM +0900, Kukjin Kim wrote:
> Hi,
>
> This is for updating of mach-exynos and plat-samsung.
> Please pull and if any problems, please let me know.
>
> Thanks,
> Kukjin
>
>
>
> The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:
>
> Li
On Thu, Jan 29, 2015 at 09:33:39AM +0900, Kukjin Kim wrote:
> Hi Arnd, Olof, Kevin
>
> Please pull Samsung cleanup for v3.20.
>
> This cleanup is very nice, Samsung SoCs no more use specific DMA and
> remove i2c sys from mach-exynos. Thanks to Arnd and all involved guys.
>
> - Kukjin
>
>
> The
The hdmi outputs black screen only even though under the hood Xorg and
framebuffer console are fine : devices found and initialized, but
not a pixel out.
Commit 93bca243ec96 ("drm/exynos: remove struct exynos_drm_manager")
changed the call order of mixer_initialize with regards to
exynos_drm_crt
Javier,
Trivial nits below.
On Thu, 2015-01-29 at 14:37 +0100, Javier Martinez Canillas wrote:
> From: Bill Richardson
>
> Chromebooks have an Embedded Controller (EC) that is used to
> implement various functions such as keyboard, power and battery.
>
> The AP can communicate with the EC thro
From: Mandeep Singh Baines
The goal of the change is to make sure we send the vblank event on the
current vblank. My hope is to fix any races that might be causing flicker.
After this change I only see a flicker in the transition plymouth and
X11.
Simplified the code by tracking vblank events on
Building the s5p-tv HDMI support when CONFIG_I2C is disabled
gives us this build error:
s5p-tv/hdmi_drv.c: In function 'hdmi_probe':
s5p-tv/hdmi_drv.c:947:2: error: implicit declaration of function
'i2c_get_adapter' [-Werror=implicit-function-declaration]
adapter = i2c_get_adapter(pdata->hdmiph
Many SDIO/MMC attached WLAN chips need more than one ping for their reset
sequence. Extend the pwrseq_simple binding to support more than one pin.
Signed-off-by: Javier Martinez Canillas
---
Changes since v2: None.
Changes since v1:
- Make the explanation clearer by adding an explicit "they".
Many WLAN attached to a SDIO/MMC interface, needs more than one pin for
their reset sequence. For example, is very common for chips to have two
pins: one for reset and one for power enable.
This patch adds support for more reset pins to the pwrseq_simple driver
and instead hardcoding a fixed numbe
Hi Lukasz,
On Thu, Jan 29, 2015 at 1:56 PM, Lukasz Majewski wrote:
> Hi Abhilash,
>
>> Add registers, bit fields and compatible strings for Exynos7 TMU
>> (Thermal Management Unit). Following are a few of the differences
>> in the Exynos7 TMU from earlier SoCs:
>> - 8 trigger levels
>>
Some WLAN chips attached to a SDIO interface, need an external clock
to be operational. Since this is very common, extend the simple MMC
power sequence DT binding to support an optional clock.
Signed-off-by: Javier Martinez Canillas
---
Changes since v2: None.
Changes since v1: None.
---
Docum
Some WLAN chips attached to a SDIO interface, need a reference clock.
Since this is very common, extend the prseq_simple driver to support
an optional clock that is enabled prior the card power up procedure.
Note: the external clock is optional. Thus an error is not returned
if the clock is not f
Hello Ulf,
Many WLAN chips attached to an SDIO interface needs more than one GPIO
for their reset sequence and also an external clock to be operational.
Since this is very common, this series extend the simple MMC power sequence
to support more than one reset GPIO and also an optional external cl
The Snow board has a MMC/SDIO wifi chip that is always powered but it
needs a power sequence involving a reset (active low) and an enable
(active high) pins. Both pins are marked as active low since the MMC
simple power sequence driver asserts the pins prior to the card power
up procedure and de-as
Enabling SDIO IRQ signalling for the wifi MMC/SDIO slot
doubles the transmission transfer rate.
Signed-off-by: Javier Martinez Canillas
---
Changes since v2: None.
Changes since v1: None, new patch.
---
arch/arm/boot/dts/exynos5250-snow.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/a
Hi Thierry,
I think you forgot to take this patch!
Can you check this?
Regards,
Ajay Kumar
On Tue, Jan 20, 2015 at 10:08 PM, Ajay Kumar wrote:
> From: Vincent Palatin
>
> This patch adds drm_bridge driver for parade DisplayPort
> to LVDS bridge chip.
>
> Signed-off-by: Vincent Palatin
> Sign
Hi Gustavo,
I think Thierry already fixed it. Check this.
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/bridge/Kconfig
Regards,
Ajay
On Thu, Jan 29, 2015 at 7:59 PM, Gustavo Padovan wrote:
> Hi Ajay,
>
> 2015-01-20 Ajay Kumar :
>
>> Use drm_bridge helpe
Hi Ajay,
2015-01-20 Ajay Kumar :
> Use drm_bridge helpers to modify the driver to support
> i2c driver model.
>
> Signed-off-by: Ajay Kumar
> Acked-by: Inki Dae
> Tested-by: Rahul Sharma
> Tested-by: Javier Martinez Canillas
> Tested-by: Gustavo Padovan
> Tested-by: Sjoerd Simons
> ---
>
On Thursday 29 January 2015 11:41:34 Mark Brown wrote:
> On Wed, Jan 28, 2015 at 10:28:55PM +0100, Arnd Bergmann wrote:
> > The SND_SOC_ARNDALE_RT5631_ALC5631 selects the rt5631 codec
> > that requires I2C to work, so we get a build error if I2C
> > is disabled:
>
> You rather buried the lead abou
On Thu, Jan 29, 2015 at 7:07 PM, Javier Martinez Canillas
wrote:
> From: Bill Richardson
>
> Chromebooks have an Embedded Controller (EC) that is used to
> implement various functions such as keyboard, power and battery.
>
> The AP can communicate with the EC through different bus types
> such as
Hello Ulf,
Thanks a lot for your feedback.
On 01/29/2015 02:05 PM, Ulf Hansson wrote:
>>
>> struct mmc_pwrseq_simple {
>> struct mmc_pwrseq pwrseq;
>> + struct clk *ext_clk;
>
> You need to add a bool, maybe call it clk_enabled; See why below.
>
Ok
>> int nr_gpios;
>>
The ChromeOS Embedded Controller has to be accessed by applications.
A virtual character device is used as an interface with user-space.
Extend the struct cros_ec_device with the fields needed by the driver
of this virtual character device.
Signed-off-by: Javier Martinez Canillas
Acked-by: Lee J
The struct cros_ec_command will be used as an ioctl() argument for the
API to control the ChromeOS EC from user-space. So the data structure
has to be 64-bit safe to make it compatible between 32 and 64 avoiding
the need for a compat ioctl interface. Since pointers are self-aligned
to different byt
From: Bill Richardson
This adds some sysfs entries to provide userspace control of the
four-element LED "lightbar" on the Chromebook Pixel. This only instantiates
the lightbar controls if the device actually exists.
To prevent DoS attacks, this interface is limited to 20 accesses/second,
althoug
From: Bill Richardson
This adds the first few sysfs attributes for the Chrome OS EC. These
controls are made available under /sys/devices/virtual/chromeos/cros_ec
flashinfo - display current flash info
reboot - tell the EC to reboot in various ways
version - information ab
From: Bill Richardson
This patch adds a device interface to access the
Chrome OS Embedded Controller from user-space.
Signed-off-by: Bill Richardson
Reviewed-by: Simon Glass
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Gwendal Grignou
---
Changes since v3: None.
Changes since v2:
From: Bill Richardson
Chromebooks have an Embedded Controller (EC) that is used to
implement various functions such as keyboard, power and battery.
The AP can communicate with the EC through different bus types
such as I2C, SPI or LPC.
The cros_ec mfd driver is then composed of a core driver th
Hello,
The mainline ChromeOS Embedded Controller (EC) driver is still missing some
features that are present in the downstream ChromiumOS tree. These are:
- Low Pin Count (LPC) interface
- User-space device interface
- Access to vboot context stored on a block device
- Access to vboot con
The ChromeOS EC character device is an user-space interface to
allow applications to access the Embedded Controller.
Add a cell for this device so it's spawned from the mfd driver.
Signed-off-by: Javier Martinez Canillas
Acked-by: Lee Jones
---
Changes since v3: None, added Acked-by tag from L
From: Prathyush K
When VPLL clock of less than 140 MHz was used and all the three
clocks - hdmiphy, hdmi, sclk_hdmi are disabled, the system hangs
during S2R when HDMI is connected. Since we want to use a vpll
clock of 70.5 MHz, we cannot disable these 3 clocks before suspending.
This patch moves
On 28 January 2015 at 19:15, Javier Martinez Canillas
wrote:
> Some WLAN chips attached to a SDIO interface, need a reference clock.
>
> Since this is very common, extend the prseq_simple driver to support
> an optional clock that is enabled prior the card power up procedure.
>
> Note: the externa
Hi Chanwoo,
On 23/01/15 21:54, Chanwoo Choi wrote:
> On Sat, Jan 24, 2015 at 2:40 AM, Sylwester Nawrocki
> wrote:
>> On 21/01/15 07:26, Chanwoo Choi wrote:
>>> +/* list of all parent clock list */
>>
>>> +PNAME(mout_bus_pll_user_p) = { "fin_pll", "sclk_bus_pll", };
>> ...
>>> +
>>> +static stru
On Thursday 29 January 2015 15:40:15 Viresh Kumar wrote:
> obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o
> obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
> -obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o
> -obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210
Hi Chanwoo,
On 29/01/15 00:38, Chanwoo Choi wrote:
...
Right. current samsung clock drivers cannot show the hierarchy among clock
domains in DT.
>> IOW, there is currently
>> no way to ensure proper registration order of the CMUs (clock domains).
>> This may be impo
On Wed, Jan 28, 2015 at 10:28:55PM +0100, Arnd Bergmann wrote:
> The SND_SOC_ARNDALE_RT5631_ALC5631 selects the rt5631 codec
> that requires I2C to work, so we get a build error if I2C
> is disabled:
You rather buried the lead about there being other drivers in this
changelog, makes the code a bit
Hello,
On 2015-01-29 11:56, Javier Martinez Canillas wrote:
On Thu, Jan 29, 2015 at 10:15 AM, Marek Szyprowski
wrote:
Also, I wonder whether we could extend the mmc-pwrseq to cover your
case? Did you consider that as an option?
I didn't consider mmc-pwrseq yet. For me it looked straightforwar
Hello Marek,
On Thu, Jan 29, 2015 at 10:15 AM, Marek Szyprowski
wrote:
>> Also, I wonder whether we could extend the mmc-pwrseq to cover your
>> case? Did you consider that as an option?
>
>
> I didn't consider mmc-pwrseq yet. For me it looked straightforward to
I agree with Ulf that using mmc-p
On Tue, Jan 27, 2015 at 9:13 PM, Ulf Hansson wrote:
> While adding error handling of genpd's ->attach_dev() callback, I realized
> that
> we also had a need to re-structure some of the code which deals with
> adding/removing devices to genpd. Especially the APIs, __pm_genpd_add_device()
> and pm_
On 29 January 2015 at 15:31, Arnd Bergmann wrote:
> That might be close enough to what we want. It would by default enable
> ARM_EXYNOS_CPUFREQ for exynos based machines that do not use this driver
> (e.g. 5440, which has a separate driver, or exynos3/exynos7), but that
> can probably just be deal
On Thursday 29 January 2015 09:09:03 Viresh Kumar wrote:
> On 29 January 2015 at 01:31, Arnd Bergmann wrote:
>
> >> config ARM_EXYNOS_CPUFREQ
> >> - bool
> >> + tristate "SAMSUNG EXYNOS CPUfreq Driver"
> >> + depends on THERMAL
> >> + default y
> >> + help
> >> + This a
On Wed, Jan 21, 2015 at 7:43 AM, Chanwoo Choi wrote:
> This patch adds driver data for Exynos5433 SoC. Exynos5433 includes 228 multi-
> functional input/output port pins and 135 memory port pins. There are 41
> general
> port groups and 2 memory port groups.
>
> Cc: Tomasz Figa
> Cc: Thomas Abr
On Mon, 26 Jan 2015, Russell King - ARM Linux wrote:
> On Tue, Jan 20, 2015 at 06:23:50AM +0100, Nicholas Mc Guire wrote:
> > if(!wait_for_completion_interruptible_timeout(...))
> > only handles the timeout case - this patch adds handling the
> > signal case the same as timeout and cleans up.
> >
Hello,
On 2015-01-28 15:24, Ulf Hansson wrote:
On 28 January 2015 at 14:59, Marek Szyprowski wrote:
There are boards (like Hardkernel's Odroid boards) on which eMMC card's
reset line is connected to GPIO line instead of the hardware reset
logic. In case of such boards, if first stage of bootlo
Hi Abhilash,
> Add registers, bit fields and compatible strings for Exynos7 TMU
> (Thermal Management Unit). Following are a few of the differences
> in the Exynos7 TMU from earlier SoCs:
> - 8 trigger levels
> - Different bit offsets and more registers for the rising
> and
64 matches
Mail list logo
