Re: [PATCH 2/7] mfd: cros_ec: spi: Add mutex to cros_ec_spi

Hi Doug, On 18 April 2014 15:15, Doug Anderson wrote: > > Simon, > > On Fri, Apr 18, 2014 at 10:28 AM, Simon Glass wrote: > > Hi Doug, > > > > On 17 April 2014 11:59, Doug Anderson wrote: > >> The main transfer function for cros_ec_spi can be called by more than > >> one client at a time. Make

Re: [PATCH 2/7] mfd: cros_ec: spi: Add mutex to cros_ec_spi

Simon, On Fri, Apr 18, 2014 at 10:28 AM, Simon Glass wrote: > Hi Doug, > > On 17 April 2014 11:59, Doug Anderson wrote: >> The main transfer function for cros_ec_spi can be called by more than >> one client at a time. Make sure that those clients don't stomp on >> each other by locking the bus

Re: [PATCH v3 5/5] regulator: tps65090: Make FETs more reliable by adding retries

Mark, On Fri, Apr 18, 2014 at 10:43 AM, Mark Brown wrote: > On Wed, Apr 16, 2014 at 04:12:29PM -0700, Doug Anderson wrote: >> An issue was discovered with tps65090 where sometimes the FETs >> wouldn't actually turn on when requested (they would report >> overcurrent). The most problematic FET wa

Re: [PATCH v3 5/5] regulator: tps65090: Make FETs more reliable by adding retries

On Wed, Apr 16, 2014 at 04:12:29PM -0700, Doug Anderson wrote: > An issue was discovered with tps65090 where sometimes the FETs > wouldn't actually turn on when requested (they would report > overcurrent). The most problematic FET was the one used for the LCD This is basically fine but you said i

Re: [PATCH 4/7] mfd: cros_ec: spi: Increase cros_ec_spi deadline from 5ms to 100ms

Hi Doug, On 17 April 2014 11:59, Doug Anderson wrote: > We're adding i2c tunneling to the list of things that goes over > cros_ec. i2c tunneling can be slooow, so increase our deadline to > 100ms to account for that. > > Signed-off-by: Doug Anderson I believe the EC protocol should be chan

Re: [PATCH 5/7] mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources

On 17 April 2014 11:59, Doug Anderson wrote: > From: Bill Richardson > > This just updates include/linux/mfd/cros_ec_commands.h to match the > latest EC version (which is the One True Source for such things). See > > > [dianders: took to

Re: [PATCH 2/7] mfd: cros_ec: spi: Add mutex to cros_ec_spi

Hi Doug, On 17 April 2014 11:59, Doug Anderson wrote: > The main transfer function for cros_ec_spi can be called by more than > one client at a time. Make sure that those clients don't stomp on > each other by locking the bus for the duration of the transfer > function. Is there no lock at the

Re: [PATCH 4/4] regulator: s5m8767: Use same binding for external control as in s2mps11

On Tue, Apr 15, 2014 at 10:55:45AM +0200, Krzysztof Kozlowski wrote: > Anyway more drivers seem to use this kind of binding (tps65090, max8952, > da9055, arizona) so maybe there is a point in making this generic? Yes. signature.asc Description: Digital signature

Re: [PATCH 1/7] mfd: cros_ec: spi: calculate delay between transfers correctly

On 17 April 2014 11:59, Doug Anderson wrote: > From: David Hendricks > > To avoid spamming the EC we calculate the time between the previous > transfer and the current transfer and force a delay if the time delta > is too small. > > However, a small miscalculation causes the delay period to be >

Re: [PATCH 3/7] mfd: cros_ec: spi: Make the cros_ec_spi timeout more reliable

On 17 April 2014 11:59, Doug Anderson wrote: > The cros_ec_spi transfer had two problems with its timeout code: > > 1. It looked at the timeout even in the case that it found valid data. > 2. If the cros_ec_spi code got switched out for a while, it's possible >it could get a timeout after a si

Re: [PATCH 1/2] dt-bindings: clock: Move at91.h to dt-bindigs/clock

On 06/03/2014 07:04, Tushar Behera : > Most of the clock related dt-binding header files are located in > dt-bindings/clock folder. It would be good to keep all the similar > header files at a single location. > > Signed-off-by: Tushar Behera > CC: Rob Landley > CC: Andrew Victor > CC: Jean-Chr

Re: [PATCH v3 4/5] regulator: tps65090: Allow setting the overcurrent wait time

On Wed, Apr 16, 2014 at 04:12:28PM -0700, Doug Anderson wrote: > The tps65090 regulator allows you to specify how long you want it to > wait before detecting an overcurrent condition. Allow specifying that > through the device tree (or through platform data). Applied, thanks. > +- ti,overcurrent

[PATCH 2/4] ARM: EXYNOS: Fix core ID used by platsmp and hotplug code

When CPU topology is specified in device tree, cpu_logical_map() does not return core ID anymore, but rather full MPIDR value. This breaks existing calculation of PMU register offsets on Exynos SoCs. This patch fixes the problem by adjusting the code to use only core ID bits of the value returned

[PATCH 0/4] Fixes for DT CPU topology specification on Exynos

Due to some parts of Exynos SoC support designed originally in a non-scalable way, relying on 1:1 mapping between value returned by cpu_logical_map() and CPU IDs as seen by PMU and GIC, trying to specify CPU topology in device tree caused various boot-up issues on Exynos SoCs, ranging from CPUs oth

[PATCH 1/4] ARM: EXYNOS: Fix definitions of S5P_ARM_CORE_* registers

On SoCs with more than 2 cores there are more than 2 S5P_ARM_CORE_* registers that can be addressed with fixed stride of 0x80. This patch renames the definitions of S5P_ARM_CORE1_* registers to be S5P_ARM_CORE_* and make them take physical core ID as argument to calculate register address. Signed-

[PATCH 4/4] ARM: dts: exynos4: Add CPU topology data

After fixing non-banked GIC support in GIC driver, CPU nodes can be safely added to Exynos4 device tree sources, along with appropriate gic-offset properties. Signed-off-by: Tomasz Figa --- arch/arm/boot/dts/exynos4210.dtsi | 19 +++ arch/arm/boot/dts/exynos4212.dtsi | 19 +++

[PATCH 3/4] irqchip: gic: Add support for per CPU bank offset specification in DT

On most platforms GIC registers are banked, so each CPU can access its registers at the same address. However there is a small number of SoCs on which the banking is not implemented and each CPU has its GIC register set at different offset from GIC base address. Originally the driver used simple m

Re: [PATCH] arm: exynos: generalize power register address calculation

Hi Chander, On 15.04.2014 09:38, Chander Kashyap wrote: Currently status/configuration power register values are hard-coded for cpu1. Make it generic so that it is useful for SoC's with more than two cpus. Signed-off-by: Chander Kashyap --- changes in v3: 1. Move cpunr calculation to

[PATCH] ARM: dts: disable MDMA1 node for smdk5420 board

This change is similar to commit 3da355c(ARM: dts: Disable MDMA1 node for arndale-octa board). If MDMA1 region is configured with secure mode, it makes the boot failure with the following. Unhandled fault: imprecise external abort (0x1406) at 0x Signed-off-by: Seungwon Jeon --- arch/arm

[PATCH v2 1/6] mfd/rtc: sec/s5m: Rename SEC* symbols to S5M

This patch prepares for adding support for S2MPS14 RTC device to the rtc-s5m driver: 1. Renames SEC* symbols to S5M. 2. Adds S5M prefix to some of defines which are different between S5M876X and S2MPS14. This is only a rename-like patch, new code is not added. Signed-off-by: Krzysztof Kozlowski

[PATCH v2 0/6] rtc: s5m: Add support for S2MPS14

Hi, This is second version of patches for S5M RTC driver adding support for S2MPS14 device. The patchset is rebased against current Linus' tree (v3.15-rc1-136-gd3e74dc8280c) and on my last patch for RTC regmap fixes: - mfd/rtc: s5m: Do not allocate RTC I2C dummy and regmap for unsupported chi

[PATCH v2 5/6] rtc: s5m: Add support for S2MPS14 RTC

Add support for S2MPS14 to the rtc-s5m driver. Differences in S2MPS14 (in comparison to S5M8767): - Layout of registers; - Lack of century support for time and alarms (7 registers used for storing time/alarm); - Two buffer control registers: WUDR and RUDR; - No register for enabling writing

[PATCH v2 3/6] rtc: s5m: Use shorter time of register update

Set the time needed for updating alarm and time registers to 0.45 ms. The default is 7.32 ms which is too long and leads to warnings when setting alarm or time: s5m-rtc: waiting for UDR update, reached max number of retries Signed-off-by: Krzysztof Kozlowski Cc: Kyungmin Park --- driver

[PATCH v2 4/6] rtc: s5m: Support different register layout

This patch prepares for adding support for S2MPS14 RTC device to the rtc-s5m driver: 1. Adds a map of registers used by the driver which differ between the chipsets (S5M876X and S2MPS14). 2. Moves code of checking for alarm pending to separate function. Signed-off-by: Krzysztof Kozlowski Cc: Kyun

[PATCH v2 2/6] rtc: s5m: Remove undocumented time init on first boot

This patch removes the code for initializing time if this is first boot. The code for detecting first boot uses undocumented field RTC_TCON in RTC_UDR_CON register. According to S5M8767's datasheet this field is reserved. On S2MPS14 it is not documented at all. On device first boot the registers w

[PATCH v2 6/6] rtc: s5m: Consolidate two device type switch statements

In probe the configuration of driver for different chipsets was done in two switch (pdata->device_type) statements. Consolidate them into one switch statement to increase code readability. Additionally check the return value of regmap_irq_get_virq and exit probe on error. Signed-off-by: Krzysztof

Re: [PATCH RFC 3/3] drm/exynos: use pending_components for components tracking

On Fri, Apr 18, 2014 at 02:02:37PM +0200, Andrzej Hajda wrote: > Separation of the interfaces exposed by the device from the device itself > seems to me a good thing. I would even consider it as a biggest > advantage of this solution :) > > The problem of re-initialization does not seems to be rel

Re: [PATCH RFC 3/3] drm/exynos: use pending_components for components tracking

On Fri, Apr 18, 2014 at 01:27:53PM +0200, Andrzej Hajda wrote: > Hi Russel, > > Thanks for comments. > > On 04/17/2014 11:47 PM, Russell King - ARM Linux wrote: > > On Thu, Apr 17, 2014 at 01:28:50PM +0200, Andrzej Hajda wrote: > >> +out: > >> + if (ret != -EPROBE_DEFER) > >> + exynos_d

Re: [RFC PATCH v2 05/14] ARM: dts: samsung-fimd: add I80 specific properties

Hi again, On 04/17/2014 01:53 PM, YoungJun Cho wrote: > In case of using CPU interface panel, the relevant registers should be set. > So this patch adds relevant dt bindings. > > Changelog v2: > - Changes "samsung,sysreg-phandle" to "samsung,sysreg" > > Signed-off-by: YoungJun Cho > Signed-off-by

Re: [RFC PATCH 02/14] drm/exynos: dsi: delay setting clocks after reset

Hi YoungJun, Thanks for the whole patchset. On 04/15/2014 07:47 AM, YoungJun Cho wrote: > Some phy control registers are not kept after software reset. > So this patch makes the clocks containing phy control to be set > after software reset. > > Signed-off-by: YoungJun Cho > Signed-off-by: Inki

Re: [PATCH RFC 3/3] drm/exynos: use pending_components for components tracking

On 04/18/2014 12:04 AM, Russell King - ARM Linux wrote: > On Thu, Apr 17, 2014 at 01:28:50PM +0200, Andrzej Hajda wrote: >> +static int exynos_drm_add_blocker(struct device *dev, void *data) >> +{ >> +struct device_driver *drv = data; >> + >> +if (!platform_bus_type.match(dev, drv)) >> +

[PATCH] net: sxgbe: Added phy_found error path

This patch adds phy_found error path when there is no phy device and changes bus_name. Signed-off-by: Byungho An --- drivers/net/ethernet/samsung/sxgbe/sxgbe_mdio.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_md

[PATCH] net: sxgbe: rearrange dma descriptor

This patch moves cksum_ctl to tx_rd_des23 from cksum_pktlen for correct checksum offloading and modifies size for Tx/Rx descriptor. Signed-off-by: Byungho An --- drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.c |4 +-- drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.h | 39 ++--

Re: [PATCH RFC 3/3] drm/exynos: use pending_components for components tracking

Hi Russel, Thanks for comments. On 04/17/2014 11:47 PM, Russell King - ARM Linux wrote: > On Thu, Apr 17, 2014 at 01:28:50PM +0200, Andrzej Hajda wrote: >> +out: >> +if (ret != -EPROBE_DEFER) >> +exynos_drm_dev_ready(&pdev->dev); > So we end up with everyone needing a "ready" call

Re: [PATCH 7/7] drm/bridge: ptn3460: add drm_panel controls

On Wednesday, April 16, 2014 11:33 PM, Ajay Kumar wrote: > > attach ptn3460 connector to drm_panel and support drm_panel routines, > if a valid drm_panel object is passed to ptn3460_init. > > Signed-off-by: Ajay Kumar > --- > drivers/gpu/drm/bridge/Kconfig | 1 + > drivers/gpu/drm/bri

RE: [PATCH 5/7] drm/exynos: dp: modify driver to support drm_panel

On Wednesday, April 16, 2014 11:33 PM, Ajay Kumar wrote: > > This patch attaches the dp connector to exynos_dp_panel, and adds > calls to drm_panel functions to control panel power sequence. > > Signed-off-by: Ajay Kumar > --- > drivers/gpu/drm/exynos/Kconfig | 1 + > drivers/gpu/drm/

Re: [PATCH 4/7] drm/exynos: add exynos_dp_panel driver registration to drm driver

On Wednesday, April 16, 2014 11:33 PM, Ajay Kumar wrote: > > Register exynos_dp_panel before the list of exynos crtcs and > connectors are probed. > > This is needed because exynos_dp_panel should be registered to > the drm_panel list via panel-exynos-dp probe, i.e much before > exynos_dp_bind ca

Re: [PATCH 3/7] drm/panel: Add driver for exynos_dp based panels

On Wednesday, April 16, 2014 11:33 PM, Ajay Kumar wrote: > > This patch adds a simple driver to handle all the LCD and LED > powerup/down routines needed to support eDP/eDP-LVDS panels > supported on exynos boards. > > Most of the eDP/LVDS panels need this sequence for powerup: > -- LCD uni

Re: [PATCH 1/7] drm/exynos: dp: support hotplug detection via GPIO

On Wednesday, April 16, 2014 11:33 PM, Ajay Kumar wrote: > > From: Andrew Bresticker > > Certain bridge chips use a GPIO to indicate the cable status instead > of the I_DP_HPD pin. This adds an optional device-tree property, > "samsung,hpd-gpio", to the exynos-dp controller which indicates that

Re: [PATCH 0/2] Support cpufreq driver for Exynos3250

Hi Chanwoo, On 18 April 2014 07:50, Chanwoo Choi wrote: > This patchset support cpufreq driver for Exynos3250 which uses the Cortex-A7 > dual cores and has a target speed of 1.0 GHz and code clean using dev_err/info > instead of pr_err/info function. Per SoC cpufreq driver which does not use CCF

[PATCH v3 0/7] Support 4 levels of translation tables for ARM64

Hi All, This the 3rd patchset supports 4 levels of tranlsation tables for ARM64. Firstly, The patchset decouples page size from level of translation tables as taking account into the comment from Catalin Marinas: http://www.spinics.net/linux/lists/arm-kernel/msg319552.html Then, it implements 4

[PATCH v3 4/7] arm64: Add a description on 48-bit address space with 4KB pages

This patch adds memory layout and translation lookup information about 48-bit address space with 4K pages. The description is based on 4 levels of translation tables. Signed-off-by: Jungseok Lee Reviewed-by: Sungjinn Chung --- Documentation/arm64/memory.txt | 59 ++

[PATCH v3 3/7] arm64: Introduce a kernel configuration option for VA_BITS

This patch adds a kernel configuration for VA_BITS. It helps to prevent unnecessary #ifdef statements insertions for VA_BITS when implementing different page sizes and level of translation tables. Signed-off-by: Jungseok Lee Reviewed-by: Sungjinn Chung --- arch/arm64/Kconfig |

[PATCH v3 1/7] arm64: Use pr_* instead of printk

This patch fixed the following checkpatch complaint as using pr_* instead of printk. WARNING: printk() should include KERN_ facility level Signed-off-by: Jungseok Lee Reviewed-by: Sungjinn Chung --- arch/arm64/kernel/traps.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-

[PATCH v3 6/7] arm64: mm: Implement 4 levels of translation tables

This patch implements 4 levels of translation tables since 3 levels of page tables with 4KB pages cannot support 40-bit physical address space described in [1] due to the following issue. It is a restriction that kernel logical memory map with 4KB + 3 levels (0xffc0-0x)

[PATCH v3 5/7] arm64: Add 4 levels of page tables definition with 4KB pages

This patch adds hardware definition and types for 4 levels of translation tables with 4KB pages. Signed-off-by: Jungseok Lee Reviewed-by: Sungjinn Chung --- arch/arm64/include/asm/pgtable-4level-hwdef.h | 50 + arch/arm64/include/asm/pgtable-4level-types.h | 71 +

[PATCH v3 7/7] arm64: KVM: Implement 4 levels of translation tables for HYP and stage2

This patch adds 4 levels of translation tables implementation for both HYP and stage2. Both symmetric and asymmetric configurations for page size and translation levels are are validated on Fast Models: 1) 4KB + 3 levels guest on 4KB + 3 levels host 2) 4KB + 4 levels guest on 4KB + 3 level

[PATCH v3 2/7] arm64: Decouple page size from level of translation tables

This patch separates page size from level of translation tables in configuration. It facilitates introduction of different options, such as 4KB + 4 levels, 16KB + 4 levels and 64KB + 3 levels, easily. Signed-off-by: Jungseok Lee Reviewed-by: Sungjinn Chung --- arch/arm64/Kconfig