On April 16, 2014 2:13:39 AM GMT+01:00, Chanwoo Choi cw00.c...@samsung.com
wrote:
Hi Jonathan,
Any comment of this patchset?
Best Regards,
Chanwoo Choi
Hi Chanwoo
Not got to it yet I'm afraid. May be sometime next week before I do.
Jonathan
On 04/14/2014 06:07 PM, Chanwoo Choi wrote:
This
Hi Rahul,
On 16.04.2014 05:58, Rahul Sharma wrote:
From: Pankaj Dubey pankaj.du...@samsung.com
This patch add basic arch side support for exynos5260 SoC.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Reviewed-by: Tomasz Figa
On April 16, 2014 5:55:17 AM GMT+01:00, Chanwoo Choi cw00.c...@samsung.com
wrote:
Hi Sachin,
On 04/16/2014 01:44 PM, Chanwoo Choi wrote:
Hi Sachin,
On 04/16/2014 12:48 PM, Sachin Kamat wrote:
Hi Chanwoo,
On 14 April 2014 14:37, Chanwoo Choi cw00.c...@samsung.com wrote:
This patch
Hi Tomasz,
On 16 April 2014 13:27, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Rahul,
On 16.04.2014 05:58, Rahul Sharma wrote:
From: Pankaj Dubey pankaj.du...@samsung.com
This patch add basic arch side support for exynos5260 SoC.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
On 16.04.2014 10:08, Sachin Kamat wrote:
Hi Tomasz,
On 16 April 2014 13:27, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Rahul,
On 16.04.2014 05:58, Rahul Sharma wrote:
From: Pankaj Dubey pankaj.du...@samsung.com
This patch add basic arch side support for exynos5260 SoC.
Signed-off-by:
Hi Jonathan,
On 04/16/2014 04:05 PM, Jonathan Cameron wrote:
On April 16, 2014 5:55:17 AM GMT+01:00, Chanwoo Choi cw00.c...@samsung.com
wrote:
Hi Sachin,
On 04/16/2014 01:44 PM, Chanwoo Choi wrote:
Hi Sachin,
On 04/16/2014 12:48 PM, Sachin Kamat wrote:
Hi Chanwoo,
On 14 April 2014
Am Dienstag, den 15.04.2014, 12:30 -0600 schrieb Bjorn Helgaas:
On Tue, Apr 15, 2014 at 12:07:34PM +0200, Lucas Stach wrote:
Hi Bjorn,
Am Freitag, den 04.04.2014, 10:55 -0600 schrieb Bjorn Helgaas:
On Wed, Mar 05, 2014 at 02:25:47PM +0100, Lucas Stach wrote:
This is the recommended
On wto, 2014-04-15 at 18:20 +0200, Thomas Gleixner wrote:
B1;3202;0cOn Tue, 15 Apr 2014, Krzysztof Kozlowski wrote:
On wto, 2014-04-15 at 17:20 +0200, Thomas Gleixner wrote:
On Tue, 15 Apr 2014, Krzysztof Kozlowski wrote:
On wto, 2014-04-15 at 14:28 +0200, Daniel Lezcano wrote:
On Wed, 16 Apr 2014, Krzysztof Kozlowski wrote:
On wto, 2014-04-15 at 18:20 +0200, Thomas Gleixner wrote:
Here is a complete solution to the problem. We really want the drivers
to be fast and clean and not work around such issues.
I'm quite happy that I kept the 'force' argument of
On the ARM Chromebook tps65090 has two masters: the AP (the main
processor running linux) and the EC (the embedded controller). The AP
is allowed to mess with FETs but the EC is in charge of charge control.
The tps65090 interupt line is routed to both the AP and the EC, which
can cause
Nearly all of the registers in tps65090 combine control bits and
status bits. Turn off caching of registers so that we can read status
bits reliably.
NOTE: the IRQnMASK and CG_CTRLn registers are the exception and could
be cached. If we find that we spend a lot of time reading those we
This patch control special clock for ADC in Exynos series's FSYS block.
If special clock of ADC is registerd on clock list of common clk framework,
Exynos ADC drvier have to control this clock.
Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
- 'adc' clock: bus clock for ADC
Exynos3250
This patchset support Exynos3250 ADC (Analog Digital Converter) because
Exynos3250 has additional special clock for ADC IP.
Changes from v2:
- Check return value of clock function to deal with error exception
- Fix minor coding style to improve readability
Changes from v1:
- Add new
This patch add DT binding documentation for Exynos3250 ADC IP. Exynos3250 has
special clock ('sclk_tsadc') for ADC which provide clock to internal ADC.
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell
On Wed, Apr 16, 2014 at 10:59:22AM +0100, Lee Jones wrote:
NOTE: the IRQnMASK and CG_CTRLn registers are the exception and could
be cached. If we find that we spend a lot of time reading those we
can turn on cache for just those registers.
-static bool is_volatile_reg(struct device
Hi Linus Walleij,
I sent this patch with minor modification.
Any comment of this patch?
Best Regards,
Chanwoo Choi
On 04/14/2014 10:45 AM, Chanwoo Choi wrote:
From: Tomasz Figa t.f...@samsung.com
This patch adds driver data (bank list and EINT layout) for Exynos3250
to pinctrl-exynos
Hi Chanwoo,
On 16.04.2014 12:11, Chanwoo Choi wrote:
This patch control special clock for ADC in Exynos series's FSYS block.
If special clock of ADC is registerd on clock list of common clk framework,
Exynos ADC drvier have to control this clock.
Exynos3250/Exynos4/Exynos5 has 'adc' clock as
Hi Sachin,
I want to use this patch to remove static SYSRAM memory mapping for Exynos3250.
But this patch has conflict on 3.15-rc1 base.
Do you have a plan to resend this patch?
Thanks,
Chanwoo Choi
On 03/19/2014 07:25 PM, Sachin Kamat wrote:
Instead of hardcoding the SYSRAM details for each
Hi Chanwoo,
On 16.04.2014 12:11, Chanwoo Choi wrote:
This patch add DT binding documentation for Exynos3250 ADC IP. Exynos3250 has
special clock ('sclk_tsadc') for ADC which provide clock to internal ADC.
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland
Instead of hardcoding the SYSRAM details for each SoC,
pass this information through device tree (DT) and make
the code SoC agnostic.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
Rebased on latest linux-next.
---
.../devicetree/bindings/arm/samsung-boards.txt | 11 +++
Hi Chanwoo,
On 16 April 2014 16:36, Chanwoo Choi cw00.c...@samsung.com wrote:
Hi Sachin,
I want to use this patch to remove static SYSRAM memory mapping for
Exynos3250.
But this patch has conflict on 3.15-rc1 base.
Do you have a plan to resend this patch?
Rebased and resent (CC'd you).
Hi Vikas,
On 16.04.2014 07:34, Vikas Sajjan wrote:
Hi Tomasz,
On Wed, Apr 16, 2014 at 12:04 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Vikas,
On 17.03.2014 14:09, Vikas Sajjan wrote:
Adds PMU support of PMU for Exynos5260. Suspend-to-RAM can be built on
top this.
Signed-off-by:
Hi,
On 04/16/2014 08:50 PM, Sachin Kamat wrote:
Instead of hardcoding the SYSRAM details for each SoC,
pass this information through device tree (DT) and make
the code SoC agnostic.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
Rebased on latest linux-next.
---
This patch adds missing pinctrls for I2C controllers 2-7.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
arch/arm/boot/dts/exynos4.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index
From: Pawel Osciak posc...@chromium.org
When a resolution change point is reached, queue an event to signal the
userspace that a new set of buffers is required before decoding can
continue.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Arun Kumar K arun...@samsung.com
---
From: Pawel Osciak posc...@chromium.org
This event indicates that the decoder has reached a point in the stream,
at which the resolution changes. The userspace is expected to provide a new
set of CAPTURE buffers for the new format before decoding can continue.
Signed-off-by: Pawel Osciak
Hi Tomasz,
On 16.04.2014 14:40, Tomasz Stanislawski wrote:
This patch adds missing pinctrls for I2C controllers 2-7.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
arch/arm/boot/dts/exynos4.dtsi | 12
1 file changed, 12 insertions(+)
diff --git
Hi Vivek,
2014-04-09 13:34 GMT+02:00 Vivek Gautam gautam.vi...@samsung.com:
Hi Tomasz,
'
On Wed, Apr 9, 2014 at 4:43 PM, Tomasz Figa t.f...@samsung.com wrote:
Hi Vivek,
Thanks for reviewing the patch series.
On 08.04.2014 16:36, Vivek Gautam wrote:
Removing this older USB 3.0 DRD
Hi Vivek,
On 15.04.2014 08:09, Vivek Gautam wrote:
Hi Tomasz,
On Thu, Apr 10, 2014 at 5:09 PM, Vivek Gautam gautamvivek1...@gmail.com wrote:
On Wed, Apr 9, 2014 at 7:03 PM, Tomasz Figa t.f...@samsung.com wrote:
On 09.04.2014 13:49, Vivek Gautam wrote:
Hi,
On Wed, Apr 9, 2014 at 4:36 PM,
Hi Sachin,
On 15.04.2014 11:28, Sachin Kamat wrote:
From: Arnd Bergmann a...@arndb.de
This makes it possible to enable the exynos platform as part of a
multiplatform kernel, in addition to keeping the single-platform
Exynos support.
sparsemem is currently not supported in multiplatform.
Is
Hi Sachin,
On 15.04.2014 11:28, Sachin Kamat wrote:
This series is based on latest linux-next and depends on the
following patch:
ARM: EXYNOS: Consolidate Kconfig entries
http://article.gmane.org/gmane.linux.kernel.samsung-soc/28642
Changes since v2:
Replaced patch 2, ARM: EXYNOS: Staticize
Hi Arun,
Thank you for the patch.
On Wednesday 16 April 2014 18:29:21 Arun Kumar K wrote:
From: Pawel Osciak posc...@chromium.org
This event indicates that the decoder has reached a point in the stream,
at which the resolution changes. The userspace is expected to provide a new
set of
Hi,
On Tue, Apr 15, 2014 at 06:24:11PM +0530, Vivek Gautam wrote:
I had seen your patches in the mailing list, but i don't see any
updated version of these patches.
Are you planning to work on this above mentioned patch-series any time soon ?
I'm sorry, I forgot this completely. I have not
On 04/16/2014 04:09 PM, Laurent Pinchart wrote:
Hi Arun,
Thank you for the patch.
On Wednesday 16 April 2014 18:29:21 Arun Kumar K wrote:
From: Pawel Osciak posc...@chromium.org
This event indicates that the decoder has reached a point in the stream,
at which the resolution changes. The
Hi Chanwoo,
On 15.04.2014 03:59, Chanwoo Choi wrote:
This patch fix the offset of CPU boot address and don't operate smc call
of SMC_CMD_CPU1BOOT command for Exynos3250.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
On Wednesday 16 April 2014 15:51:29 Tomasz Figa wrote:
On 15.04.2014 11:28, Sachin Kamat wrote:
From: Arnd Bergmann a...@arndb.de
This makes it possible to enable the exynos platform as part of a
multiplatform kernel, in addition to keeping the single-platform
Exynos support.
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 unit powerup/LCD_EN
-- video data on
-- LED unit
From: Andrew Bresticker abres...@chromium.org
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
the specified GPIO should be used for hotplug
From: Rahul Sharma rahul.sha...@samsung.com
Add DRM_CONNECTOR_POLL_HPD to the set of connector flags while
registering drm_connector for ptn3460.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/bridge/ptn3460.c | 1 +
1
Most of the panels need an init sequence as mentioned below:
-- poweron LCD unit/LCD_EN
-- start video data
-- poweron LED unit/BL_EN
With existing callbacks for drm panel, we cannot accomodate such
panels, since only one callback, i.e panel_enable is supported.
This patch
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 ajaykumar...@samsung.com
---
drivers/gpu/drm/exynos/Kconfig | 1 +
drivers/gpu/drm/exynos/exynos_dp_core.c | 19 +++
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 calls of_drm_find_panel().
Signed-off-by: Ajay Kumar
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 ajaykumar...@samsung.com
---
drivers/gpu/drm/bridge/Kconfig | 1 +
drivers/gpu/drm/bridge/ptn3460.c| 17 -
This series is based on exynos-drm-next-todo branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
This set of drm patches are needed to support bridge chips and
eDP/LVDS panels with exynos_dp.
For testing, I have used exynos5250-snow board along with
Hi Tomasz,
On Wed, Apr 16, 2014 at 11:35 PM, Tomasz Figa t.f...@samsung.com wrote:
Hi Chanwoo,
On 15.04.2014 03:59, Chanwoo Choi wrote:
This patch decide proper lowpower mode of either a15 or a9 according to
own ID
from Main ID register.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Hi Richard,
On Wed, Apr 16, 2014 at 7:03 PM, Richard Genoud
richard.gen...@gmail.com wrote:
Hi Vivek,
2014-04-09 13:34 GMT+02:00 Vivek Gautam gautam.vi...@samsung.com:
Hi Tomasz,
'
On Wed, Apr 9, 2014 at 4:43 PM, Tomasz Figa t.f...@samsung.com wrote:
Hi Vivek,
Thanks for reviewing the
On 16.04.2014 16:31, Arnd Bergmann wrote:
On Wednesday 16 April 2014 15:51:29 Tomasz Figa wrote:
On 15.04.2014 11:28, Sachin Kamat wrote:
From: Arnd Bergmann a...@arndb.de
This makes it possible to enable the exynos platform as part of a
multiplatform kernel, in addition to keeping the
Hi,
On Wed, Apr 16, 2014 at 7:14 PM, Tomasz Figa t.f...@samsung.com wrote:
Hi Vivek,
On 15.04.2014 08:09, Vivek Gautam wrote:
Hi Tomasz,
On Thu, Apr 10, 2014 at 5:09 PM, Vivek Gautam gautamvivek1...@gmail.com
wrote:
On Wed, Apr 9, 2014 at 7:03 PM, Tomasz Figa t.f...@samsung.com
Hi Laurent and Hans,
Thank you for the review.
On Wed, Apr 16, 2014 at 7:46 PM, Hans Verkuil hverk...@xs4all.nl wrote:
On 04/16/2014 04:09 PM, Laurent Pinchart wrote:
Hi Arun,
Thank you for the patch.
On Wednesday 16 April 2014 18:29:21 Arun Kumar K wrote:
From: Pawel Osciak
Hi Chanwoo,
On 15.04.2014 03:59, Chanwoo Choi wrote:
This patch decide proper lowpower mode of either a15 or a9 according to own ID
from Main ID register.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-exynos/hotplug.c |
On Wed, Apr 16, 2014 at 8:18 PM, Tomasz Figa t.f...@samsung.com wrote:
On 16.04.2014 16:31, Arnd Bergmann wrote:
On Wednesday 16 April 2014 15:51:29 Tomasz Figa wrote:
On 15.04.2014 11:28, Sachin Kamat wrote:
From: Arnd Bergmann a...@arndb.de
This makes it possible to enable the exynos
On Wednesday 16 April 2014 17:20:51 Sachin Kamat wrote:
Instead of hardcoding the SYSRAM details for each SoC,
pass this information through device tree (DT) and make
the code SoC agnostic.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
Rebased on latest linux-next.
Thanks for
Hi Thomas,
On 16.04.2014 16:55, Thomas Abraham wrote:
On Wed, Apr 16, 2014 at 8:18 PM, Tomasz Figa t.f...@samsung.com wrote:
On 16.04.2014 16:31, Arnd Bergmann wrote:
On Wednesday 16 April 2014 15:51:29 Tomasz Figa wrote:
On 15.04.2014 11:28, Sachin Kamat wrote:
From: Arnd Bergmann
This patch eliminates redundant checks while retrieving HPD gpio from DT during
HDMI's probe().
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
drivers/gpu/drm/exynos/exynos_hdmi.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git
Hi everyone,
This patchset adds 5 fixes/updates to EXYNOS DRM driver for
HDMI subsystem.
All comments are welcome.
Regards,
Tomasz Stanislawski
Changelog:
v3:
* remove usage of s5p_hdmi_platform_data
* return MODE_CLOCK_HIGH instead of MODE_CLOCK_BAD
v2:
* fix check with gpio_is_valid()
* use
This patch fixes calling usleep_range() after taking reg_slock
using spin_lock_irqsave(). The mdelay() is used instead.
Waiting in atomic context is not the best idea in general.
Hopefully, waiting occurs only when Video Processor fails
to reset correctly.
Signed-off-by: Tomasz Stanislawski
This patch continues shift of DRM EXYNOS to DT-only configuration.
The usage of the old structure for HDMI's platform data is
removed.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 30 --
1 file changed, 8
Adds support for limitation of maximal pixel clock of HDMI
signal. This feature is needed on boards that contains
lines or bridges with frequency limitations.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
.../devicetree/bindings/video/exynos_hdmi.txt |4
This patch add proper compatibles for Mixer and HDMI chip
available on exynos4210 SoCs.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
drivers/gpu/drm/exynos/exynos_hdmi.c |7 +++
drivers/gpu/drm/exynos/exynos_mixer.c |3 +++
2 files changed, 10 insertions(+)
diff
On Wed, Apr 16, 2014 at 6:50 AM, Sachin Kamat sachin.ka...@linaro.org wrote:
Instead of hardcoding the SYSRAM details for each SoC,
pass this information through device tree (DT) and make
the code SoC agnostic.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
Rebased on latest
On Tue, Apr 15, 2014 at 12:34 PM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
This patch makes the driver instantiating its child devices itself,
rather than relying on an OS to instantiate devices as children
of simple-bus. This removes an incorrect usage of simple-bus
compatible.
Good,
Lee
On Wed, Apr 16, 2014 at 2:52 AM, Lee Jones lee.jo...@linaro.org wrote:
On the ARM Chromebook tps65090 has two masters: the AP (the main
processor running linux) and the EC (the embedded controller). The AP
is allowed to mess with FETs but the EC is in charge of charge control.
The
Hi Chanwoo,
On 14.04.2014 07:13, Chanwoo Choi wrote:
On 04/11/2014 05:39 PM, Tomasz Figa wrote:
On 11.04.2014 08:32, Chanwoo Choi wrote:
On 04/11/2014 10:46 AM, Olof Johansson wrote:
On Thu, Apr 10, 2014 at 06:37:12PM +0900, Chanwoo Choi wrote:
diff --git
On the ARM Chromebook tps65090 has two masters: the AP (the main
processor running linux) and the EC (the embedded controller). The AP
is allowed to mess with FETs but the EC is in charge of charge control.
The tps65090 interupt line is routed to both the AP and the EC, which
can
On Wed, Apr 16, 2014 at 10:20:45AM +0200, Lucas Stach wrote:
Am Dienstag, den 15.04.2014, 12:30 -0600 schrieb Bjorn Helgaas:
On Tue, Apr 15, 2014 at 12:07:34PM +0200, Lucas Stach wrote:
Hi Bjorn,
Am Freitag, den 04.04.2014, 10:55 -0600 schrieb Bjorn Helgaas:
On Wed, Mar 05, 2014
Hi,
Am Mittwoch, 16. April 2014, 16:35:36 schrieb Arnd Bergmann:
On Wednesday 16 April 2014 17:20:51 Sachin Kamat wrote:
Instead of hardcoding the SYSRAM details for each SoC,
pass this information through device tree (DT) and make
the code SoC agnostic.
Signed-off-by: Sachin Kamat
Lee,
On Wed, Apr 16, 2014 at 9:26 AM, Lee Jones lee.jo...@linaro.org wrote:
On the ARM Chromebook tps65090 has two masters: the AP (the main
processor running linux) and the EC (the embedded controller). The AP
is allowed to mess with FETs but the EC is in charge of charge control.
The
On Wednesday 16 April 2014 16:58:43 Tomasz Figa wrote:
On 16.04.2014 16:55, Thomas Abraham wrote:
On Wed, Apr 16, 2014 at 8:18 PM, Tomasz Figa t.f...@samsung.com wrote:
On 16.04.2014 16:31, Arnd Bergmann wrote:
sparsemem is still not supported in multiplatform, but after I looked
at it
On the ARM Chromebook tps65090 has two masters: the AP (the main
processor running linux) and the EC (the embedded controller). The AP
is allowed to mess with FETs but the EC is in charge of charge control.
The tps65090 interupt line is routed to both the AP and the EC, which
can cause quite a
These five patches bring tps65090 up to speed with what's currently
in the Chromium OS kernel 3.8 tree and running on the Samsung ARM
Chromebook. Changes were tested atop the current linux tree
(v3.15-rc1). FET retries were tested on a machine with a known flaky
tps65090. Since display isn't
Nearly all of the registers in tps65090 combine control bits and
status bits. Turn off caching of all registers except the select few
that can be cached.
In order to avoid adding more duplicate #defines, we also move some
register offset definitions to the mfd driver (and resolve
inconsistent
Mark,
On Tue, Apr 15, 2014 at 3:52 PM, Mark Brown broo...@kernel.org wrote:
On Tue, Apr 15, 2014 at 01:14:36PM -0700, Doug Anderson wrote:
Mitigate the problem by:
* Allow setting the overcurrent wait time so devices with this problem
can set it to the max.
* Add retry logic on enables of
Mark,
On Wed, Apr 16, 2014 at 3:13 AM, Mark Brown broo...@kernel.org wrote:
On Wed, Apr 16, 2014 at 10:59:22AM +0100, Lee Jones wrote:
NOTE: the IRQnMASK and CG_CTRLn registers are the exception and could
be cached. If we find that we spend a lot of time reading those we
can turn on
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).
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
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
backlight on the Samsung ARM Chromebook (FET1). Problems were
especially prevalent when the device was
If we weren't given an interrupt we shouldn't tell child devices (like
the tps65090 charger) that they have an interrupt. This is needed so
that we can support polling mode in the tps65090 charger driver.
See also (charger: tps65090: Allow charger module to be used when no
irq).
Signed-off-by:
On the ARM Chromebook tps65090 has two masters: the AP (the main
processor running linux) and the EC (the embedded controller). The AP
is allowed to mess with FETs but the EC is in charge of charge control.
The tps65090 interupt line is routed to both the AP and the EC, which
On 04/16/2014 11:25 AM, Doug Anderson wrote:
diff --git a/drivers/regulator/tps65090-regulator.c
b/drivers/regulator/tps65090-regulator.c
index 2e92ef6..ca13a1a 100644
--- a/drivers/regulator/tps65090-regulator.c
+++ b/drivers/regulator/tps65090-regulator.c
@@ -28,15 +28,57 @@
+/**
+ *
Hi Doug, (take 2)
On 16 April 2014 12:25, Doug Anderson diand...@chromium.org 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
backlight on the
On Wed, Apr 16, 2014 at 11:25:24AM -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
Please don't send new patches as
On Wed, Apr 16, 2014 at 08:14:27PM +0200, Arnd Bergmann wrote:
This patch does a partial revert of 313367e7bfa by allowing these
drivers on all samsung platforms except EXYNOS, so we can proceed
with the multiplatform patches.
If support for these drivers is actually needed on EXYNOS
On Wednesday 16 April 2014 21:50:01 Mark Brown wrote:
On Wed, Apr 16, 2014 at 08:14:27PM +0200, Arnd Bergmann wrote:
This patch does a partial revert of 313367e7bfa by allowing these
drivers on all samsung platforms except EXYNOS, so we can proceed
with the multiplatform patches.
If
Simon,
On Wed, Apr 16, 2014 at 1:50 PM, Simon Glass s...@chromium.org wrote:
+#define MAX_CTRL_READ_TRIES5
+#define MAX_FET_ENABLE_TRIES 1000
Gosh that is a lot of tries - should we maybe give up sooner?
That's actually a squash of a recent patch. See
Hi YoungJun,
Thank you for the patch.
On Tuesday 15 April 2014 14:47:33 YoungJun Cho wrote:
In case of using CPU interface panel, the relevant registers should be set.
So this patch adds relevant dt bindings.
Signed-off-by: YoungJun Cho yj44@samsung.com
Signed-off-by: Inki Dae
Mark,
On Wed, Apr 16, 2014 at 1:51 PM, Mark Brown broo...@kernel.org wrote:
On Wed, Apr 16, 2014 at 11:25:24AM -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
Hi YoungJun,
Thank you for the patch.
On Wednesday 16 April 2014 13:38:57 YoungJun Cho wrote:
This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings, delays
and physical size.
Changelog v2:
- Adds unit address (commented by Sachin Kamat)
On Wed, Apr 16, 2014 at 02:34:47PM -0700, Doug Anderson wrote:
On Wed, Apr 16, 2014 at 1:51 PM, Mark Brown broo...@kernel.org wrote:
Please don't send new patches as replies in the middle of threads, it
makes it confusing trying to work out which versions of things should be
applied.
I'm
Mark,
On Wed, Apr 16, 2014 at 2:54 PM, Mark Brown broo...@kernel.org wrote:
On Wed, Apr 16, 2014 at 02:34:47PM -0700, Doug Anderson wrote:
On Wed, Apr 16, 2014 at 1:51 PM, Mark Brown broo...@kernel.org wrote:
Please don't send new patches as replies in the middle of threads, it
makes it
If we weren't given an interrupt we shouldn't tell child devices (like
the tps65090 charger) that they have an interrupt. This is needed so
that we can support polling mode in the tps65090 charger driver.
See also (charger: tps65090: Allow charger module to be used when no
irq).
Signed-off-by:
Randy,
On Wed, Apr 16, 2014 at 1:33 PM, Randy Dunlap rdun...@infradead.org wrote:
On 04/16/2014 11:25 AM, Doug Anderson wrote:
diff --git a/drivers/regulator/tps65090-regulator.c
b/drivers/regulator/tps65090-regulator.c
index 2e92ef6..ca13a1a 100644
---
These five patches bring tps65090 up to speed with what's currently
in the Chromium OS kernel 3.8 tree and running on the Samsung ARM
Chromebook. Changes were tested atop the current linux tree
(v3.15-rc1). FET retries were tested on a machine with a known flaky
tps65090. Since display isn't
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).
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
On the ARM Chromebook tps65090 has two masters: the AP (the main
processor running linux) and the EC (the embedded controller). The AP
is allowed to mess with FETs but the EC is in charge of charge control.
The tps65090 interupt line is routed to both the AP and the EC, which
can cause quite a
Nearly all of the registers in tps65090 combine control bits and
status bits. Turn off caching of all registers except the select few
that can be cached.
In order to avoid adding more duplicate #defines, we also move some
register offset definitions to the mfd driver (and resolve
inconsistent
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
backlight on the Samsung ARM Chromebook (FET1). Problems were
especially prevalent when the device was
Hi Doug,
On 16 April 2014 15:25, Doug Anderson diand...@chromium.org wrote:
Simon,
On Wed, Apr 16, 2014 at 1:50 PM, Simon Glass s...@chromium.org wrote:
+#define MAX_CTRL_READ_TRIES5
+#define MAX_FET_ENABLE_TRIES 1000
Gosh that is a lot of tries - should we maybe give up sooner?
Hi Tomasz,
On 04/17/2014 12:53 AM, Tomasz Figa wrote:
Hi Chanwoo,
On 14.04.2014 07:13, Chanwoo Choi wrote:
On 04/11/2014 05:39 PM, Tomasz Figa wrote:
On 11.04.2014 08:32, Chanwoo Choi wrote:
On 04/11/2014 10:46 AM, Olof Johansson wrote:
On Thu, Apr 10, 2014 at 06:37:12PM +0900, Chanwoo
Hi Tomasz,
On 04/17/2014 12:12 AM, Tomasz Stanislawski wrote:
This patch continues shift of DRM EXYNOS to DT-only configuration.
The usage of the old structure for HDMI's platform data is
removed.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
Hi Vikas,
As you comment, I found the history of this patch in mailing list.
It seems like that this patch stop the review.
Besides, Pankaj posted same patch to support PMU as following:
- https://lkml.org/lkml/2014/4/2/48
Do you have a plan to resend or not?
because I need this patch to remove
Hi Laurent
Thank you for the comment.
On 04/17/2014 06:26 AM, Laurent Pinchart wrote:
Hi YoungJun,
Thank you for the patch.
On Tuesday 15 April 2014 14:47:33 YoungJun Cho wrote:
In case of using CPU interface panel, the relevant registers should be set.
So this patch adds relevant dt
1 - 100 of 108 matches
Mail list logo
