On Tue, 2015-05-19 at 14:17 +0200, Arnd Bergmann wrote:
Finally, the EXYNOS_VIDEO option is turned into tristate as well
for good measure, as all framebuffer drivers should be configurable
as modules.
EXYNOS_MIPI_DSI and EXYNOS_LCD_S6E8AX0 are made tristate too. And that
is, I think, what
On Wed, May 20, 2015 at 01:21:53PM +0200, Javier Martinez Canillas wrote:
The ChromeOS user-space just uses flashrom to send a raw stream of bytes
via spidev to the SPI NOR flash chip. There is drivers/mtd/spi-nor/spi-nor.c
but AFAIU there are some limitations when interfacing the flash
On Tue, May 19, 2015 at 03:34:11PM +0200, Javier Martinez Canillas wrote:
Google Chromebooks have a SPI flash that is used to store firmware and
different system parameters and data (i.e: Google Binary Block flags).
---
drivers/spi/spidev.c | 1 +
1 file changed, 1 insertion(+)
This is
On Wed, 20 May 2015, Javier Martinez Canillas wrote:
Hello Lee,
On 05/13/2015 01:37 PM, Javier Martinez Canillas wrote:
On 05/13/2015 01:10 PM, Lee Jones wrote:
On Sat, 09 May 2015, Javier Martinez Canillas wrote:
Commit 1b84f2a4cd4a (mfd: cros_ec: Use fixed size arrays to
On Wed, 20 May 2015, Jiang Liu wrote:
On 2015/5/20 23:28, Thomas Gleixner wrote:
On Wed, 20 May 2015, Jiang Liu wrote:
-static void locomo_handler(unsigned int irq, struct irq_desc *desc)
+static void locomo_handler(struct irq_desc *desc)
{
struct locomo *lchip =
On 2015-05-20 18:14, Daniel Stone wrote:
Hi,
On 20 May 2015 at 17:04, Tobias Jakobi tjak...@math.uni-bielefeld.de
wrote:
Hmm,
I wonder if that really 'fixes' anything, because now we get a WARN_ON
which
is immediately followed by a div-by-zero. Furthermore we then still
use the
result of
On 2015/5/20 23:28, Thomas Gleixner wrote:
On Wed, 20 May 2015, Jiang Liu wrote:
-static void locomo_handler(unsigned int irq, struct irq_desc *desc)
+static void locomo_handler(struct irq_desc *desc)
{
struct locomo *lchip = irq_desc_get_chip_data(desc);
+unsigned int irq;
On Wed, 20 May 2015, Jiang Liu wrote:
Now most IRQ flow handlers make no use of the first parameter 'irq'.
And for those who do make use of 'irq', we could easily get the irq
number through irq_desc-irq_data-irq. So kill the first parameter
'irq' of irq_flow_handler_t.
To ease review, I
Hmm,
I wonder if that really 'fixes' anything, because now we get a WARN_ON
which is immediately followed by a div-by-zero. Furthermore we then
still use the result of that operation as input for a hw register (bad
idea?)
I thought of something like this. Change fimd_calc_clkdiv() to return
On 2015-05-20 16:33, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
When mode's vrefresh is zero we should ask DRM core to calculate
vrefresh
for us so we can get the correct value instead of relying on fixed
value
defined in a macro.
Signed-off-by: Gustavo
Hi,
On 20 May 2015 at 17:58, Tobias Jakobi tjak...@math.uni-bielefeld.de wrote:
On 2015-05-20 16:33, Gustavo Padovan wrote:
When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
for us so we can get the correct value instead of relying on fixed value
defined in a macro.
Hi,
On 20 May 2015 at 17:31, Tobias Jakobi tjak...@math.uni-bielefeld.de wrote:
On 2015-05-20 18:14, Daniel Stone wrote:
On 20 May 2015 at 17:04, Tobias Jakobi tjak...@math.uni-bielefeld.de
wrote:
I wonder if that really 'fixes' anything, because now we get a WARN_ON
which
is immediately
On Wed, 20 May 2015, Jiang Liu wrote:
-static void locomo_handler(unsigned int irq, struct irq_desc *desc)
+static void locomo_handler(struct irq_desc *desc)
{
struct locomo *lchip = irq_desc_get_chip_data(desc);
+ unsigned int irq;
int req, i;
That leaves irq unitialized
Hi,
On 20 May 2015 at 17:04, Tobias Jakobi tjak...@math.uni-bielefeld.de wrote:
Hmm,
I wonder if that really 'fixes' anything, because now we get a WARN_ON which
is immediately followed by a div-by-zero. Furthermore we then still use the
result of that operation as input for a hw register
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
for us so we can get the correct value instead of relying on fixed value
defined in a macro. But if vrefresh is still zero we should fail the
update.
Suggested-by:
2015-05-20 Tobias Jakobi tjak...@math.uni-bielefeld.de:
Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
for us so we can get the correct value instead of relying on fixed value
Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
for us so we can get the correct value instead of relying on fixed value
defined in a macro. But if vrefresh is still zero we should fail the
Jiang Liu jiang@linux.intel.com writes:
diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
b/arch/arm/mach-pxa/pcm990-baseboard.c
index 2897da2a5df6..0d8331f8536e 100644
--- a/arch/arm/mach-pxa/pcm990-baseboard.c
+++ b/arch/arm/mach-pxa/pcm990-baseboard.c
@@ -287,6 +287,7 @@ static
Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
for us so we can get the correct value instead of relying on fixed value
defined in a macro. But if vrefresh is still zero we should fail the
Hi,
2015-05-20 Daniel Stone dan...@fooishbar.org:
Hi,
On 20 May 2015 at 17:58, Tobias Jakobi tjak...@math.uni-bielefeld.de wrote:
On 2015-05-20 16:33, Gustavo Padovan wrote:
When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
for us so we can get the correct value
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
for us so we can get the correct value instead of relying on fixed value
defined in a macro. But if vrefresh is still zero we should fail the
update.
Suggested-by:
On 20.05.2015 23:59, Anand Moon wrote:
On 20 May 2015 at 08:57, Dongjin Kim tobet...@gmail.com wrote:
Hello Kryzsztof,
Are you able to check if TMU is under VDDI power domain from Exynos5422
datasheet?
If it is, XU3 use BUCK3 for TMU and more internal blocks.
Thank you,
Dongjin.
On Tue,
On 20.05.2015 19:17, Javier Martinez Canillas wrote:
Hello Krzysztof,
On 05/20/2015 05:37 AM, Krzysztof Kozlowski wrote:
On 19.05.2015 22:34, Javier Martinez Canillas wrote:
From: Simon Glass s...@chromium.org
Peach Pit and Pi machines have a SPI flash memory that is used to
store
Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
for us so we can get the correct value instead of relying on fixed value
defined in a macro. But if vrefresh is still zero we should fail the
Hi Arnd, Olof, Kevin
Here is multi_v7_defconfig update and mostly including regarding exynos
stuff based on savedefconfig which could remove useless configs based on
checking of dependencies.
This series is based on v4.1-rc1 and I can provide resolution of
conflicts with arm-soc/next/defconfig.
2015-03-19 19:56 GMT+09:00 Beata Michalska b.michal...@samsung.com:
As a follow-up to recent changes to Exynos mipi video phy
driver, introducing support for PMU regmap in commit
e4b3d38088df6f3acd40 (phy: exynos-video-mipi: Fix regression
by adding support for PMU regmap) add a syscon phandle
On 05/20/15 09:12, Krzysztof Kozlowski wrote:
2015-02-07 19:49 GMT+09:00 Inki Dae inki@samsung.com:
This patch sets display clock correctly.
If Display clock isn't set correctly then you would find below messages
and Display controller doesn't work correctly since a patch[1]
2015-05-21 10:57 GMT+09:00 Krzysztof Kozlowski k.kozlow...@samsung.com:
2015-03-19 19:56 GMT+09:00 Beata Michalska b.michal...@samsung.com:
As a follow-up to recent changes to Exynos mipi video phy
driver, introducing support for PMU regmap in commit
e4b3d38088df6f3acd40 (phy:
Since e4b3d38088df (phy: exynos-video-mipi: Fix regression by adding
support for PMU regmap) the Exynos PMU driver provides regmap to access
the MIPI DPHY registers. The MIPI DPHY driver accesses this regmap
through syscon phandle.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
Since e4b3d38088df (phy: exynos-video-mipi: Fix regression by adding
support for PMU regmap) the Exynos PMU driver provides regmap to access
the MIPI DPHY registers. The MIPI DPHY node uses a phandle to syscon to
get this regmap. The 'reg' field is obsolete.
Signed-off-by: Krzysztof Kozlowski
On 05/19/15 15:21, Kukjin Kim wrote:
On 05/17/15 17:52, Krzysztof Kozlowski wrote:
2015-05-11 12:14 GMT+09:00 Krzysztof Kozlowski k.kozlow...@samsung.com:
Dear Kukjin,
Updated pull request, replacing also the usage of soc_is_exynos4()
with of_machine_is_compatible(). You requested this in
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
for us so we can get the correct value instead of relying on fixed value
defined in a macro.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
32 matches
Mail list logo
