Re: [PATCH v5 00/18] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hi Marek, This is patch set against v3.19-rc4 plus 'Add HDMI support for Exynos5420 platform', right? No other dependencies? If there is, do you have a public git tree to be cloned? Thanks. On 23 January 2015 at 23:51, Marek Szyprowski m.szyprow...@samsung.com wrote: Hello Everyone, This is yet another attempt to get Exynos SYSMMU driver with integrated with IOMMU DMA-mapping subsystems. The main change from previous version is a rebase onto some more pending Exynos DTS patches and minor fixes of the reported issues. Merge plan for this patchset: 1. All iommu related patches (with 'iommu: exynos') can be merged to iommu tree. They don't have any direct dependencies on the DTS, DRM and power domain initialization change - without them the driver will simply not initialize, when no exynos,sysmmu nodes are provided in device tree. Joerg, could you merge those patches? 2. DTS and power domain patches should go to Samsung Exynos tree. Those patches depends on earlier DTS patches for Exynos SoCs, which make this patchset really complete: - 'ARM: DTS: Exynos: convert to generic power domain bindings' (http://www.spinics.net/lists/linux-samsung-soc/msg40584.html) - '[PATCH v4 0/7] Enable HDMI support on Exynos platforms' (http://www.spinics.net/lists/arm-kernel/msg391148.html) - '[PATCH 0/2] Add HDMI support for Exynos5420 platform' (http://www.spinics.net/lists/linux-samsung-soc/msg41364.html) Kukjin, could you merge those patches? 3. Exynos DRM fix. This patch in my opinion should go Exynos DRM tree. Inki, could you merge it? Best regards Marek Szyprowski Samsung RD Institute Poland Changelog: v5: - rebased onto 'Add HDMI support for Exynos5420 platform' patchset - fixed 'const' issue in 'iommu: exynos: init from dt-specific callback instead of initcall' patch, thanks to Tobias Jakobi for reporting it - fixed copy-paste typo in exynos5250 dts patch v4: http://www.spinics.net/lists/linux-samsung-soc/msg41177.html - rebased onto v3.19-rc4 and other Exynos DTS queued patches - added DTS patch for Exynos 5250 5420/5422/5800 v3: http://www.spinics.net/lists/linux-samsung-soc/msg39168.html - rebased onto [RFC PATCH v4 0/8] Introduce automatic DMA configuration for IOMMU masters - added some minor fixes for iommu and dma-mapping frameworks v2: http://thread.gmane.org/gmane.linux.kernel.iommu/6472/ - rebased onto [RFC PATCH v3 0/7] Introduce automatic DMA configuration for IOMMU masters patches: http://www.spinics.net/lists/arm-kernel/msg362076.html - changed initialization from bus notifiers to DT related callbacks - removed support for separate IO address spaces - this will be discussed separately after the basic support gets merged - removed support for power domain notifier-based runtime power management - this also will be discussed separately later v1: https://lkml.org/lkml/2014/8/5/183 - initial version, feature complete, completely rewrote integration approach Patch summary: Marek Szyprowski (18): drm: exynos: detach from default dma-mapping domain on init arm: exynos: pm_domains: add support for devices registered before arch_initcall ARM: dts: exynos4: add sysmmu nodes ARM: dts: exynos5250: add sysmmu nodes ARM: dts: exynos5420: add sysmmu nodes iommu: exynos: don't read version register on every tlb operation iommu: exynos: remove unused functions iommu: exynos: remove useless spinlock iommu: exynos: refactor function parameters to simplify code iommu: exynos: remove unused functions, part 2 iommu: exynos: remove useless device_add/remove callbacks iommu: exynos: add support for binding more than one sysmmu to master device iommu: exynos: add support for runtime_pm iommu: exynos: rename variables to reflect their purpose iommu: exynos: document internal structures iommu: exynos: remove excessive includes and sort others alphabetically iommu: exynos: init from dt-specific callback instead of initcall iommu: exynos: add callback for initializing devices from device tree arch/arm/boot/dts/exynos4.dtsi| 118 +++ arch/arm/boot/dts/exynos4210.dtsi | 23 ++ arch/arm/boot/dts/exynos4x12.dtsi | 82 + arch/arm/boot/dts/exynos5250.dtsi | 250 +++ arch/arm/boot/dts/exynos5420.dtsi | 181 +++ arch/arm/mach-exynos/pm_domains.c | 9 +- drivers/gpu/drm/exynos/exynos_drm_iommu.c | 3 + drivers/iommu/exynos-iommu.c | 492 ++ 8 files changed, 888 insertions(+), 270 deletions(-) -- 1.9.2 ___ iommu mailing list io...@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at
[PATCH v2 1/2] drm/exynos: fix DMA_ATTR_NO_KERNEL_MAPPING usage
The Exynos DRM driver doesn't follow the correct API when dealing with
dma_{alloc, mmap, free}_attrs functions and the
DMA_ATTR_NO_KERNEL_MAPPING attribute.
When a IOMMU is not available and the DMA_ATTR_NO_KERNEL_MAPPING is
used, the driver should use the pointer returned by dma_alloc_attr() as
a cookie.
The Exynos DRM driver directly uses the non-requested virtual kernel
address returned by the DMA mapping subsystem. This just works now
because the non-IOMMU codepath doesn't obey DMA_ATTR_NO_KERNEL_MAPPING
but we need to fix it before fixing the DMA layer.
Signed-off-by: Carlo Caione ca...@caione.org
Acked-by: Joonyoung Shim jy0922.s...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_buf.c | 6 +++---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 29 +
drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 ++
3 files changed, 14 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 9c80884..24994ba 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -63,11 +63,11 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
return -ENOMEM;
}
- buf-kvaddr = (void __iomem *)dma_alloc_attrs(dev-dev,
+ buf-cookie = dma_alloc_attrs(dev-dev,
buf-size,
buf-dma_addr, GFP_KERNEL,
buf-dma_attrs);
- if (!buf-kvaddr) {
+ if (!buf-cookie) {
DRM_ERROR(failed to allocate buffer.\n);
ret = -ENOMEM;
goto err_free;
@@ -132,7 +132,7 @@ static void lowlevel_buffer_deallocate(struct drm_device
*dev,
buf-sgt = NULL;
if (!is_drm_iommu_supported(dev)) {
- dma_free_attrs(dev-dev, buf-size, buf-kvaddr,
+ dma_free_attrs(dev-dev, buf-size, buf-cookie,
(dma_addr_t)buf-dma_addr, buf-dma_attrs);
drm_free_large(buf-pages);
} else
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index e12ea90..84f8dfe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -79,9 +79,9 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper
*helper,
struct drm_framebuffer *fb)
{
struct fb_info *fbi = helper-fbdev;
- struct drm_device *dev = helper-dev;
struct exynos_drm_gem_buf *buffer;
unsigned int size = fb-width * fb-height * (fb-bits_per_pixel 3);
+ unsigned int nr_pages;
unsigned long offset;
drm_fb_helper_fill_fix(fbi, fb-pitches[0], fb-depth);
@@ -94,25 +94,14 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper
*helper,
return -EFAULT;
}
- /* map pages with kernel virtual space. */
+ nr_pages = buffer-size PAGE_SHIFT;
+
+ buffer-kvaddr = (void __iomem *) vmap(buffer-pages,
+ nr_pages, VM_MAP,
+ pgprot_writecombine(PAGE_KERNEL));
if (!buffer-kvaddr) {
- if (is_drm_iommu_supported(dev)) {
- unsigned int nr_pages = buffer-size PAGE_SHIFT;
-
- buffer-kvaddr = (void __iomem *) vmap(buffer-pages,
- nr_pages, VM_MAP,
- pgprot_writecombine(PAGE_KERNEL));
- } else {
- phys_addr_t dma_addr = buffer-dma_addr;
- if (dma_addr)
- buffer-kvaddr = (void __iomem
*)phys_to_virt(dma_addr);
- else
- buffer-kvaddr = (void __iomem *)NULL;
- }
- if (!buffer-kvaddr) {
- DRM_ERROR(failed to map pages to kernel space.\n);
- return -EIO;
- }
+ DRM_ERROR(failed to map pages to kernel space.\n);
+ return -EIO;
}
/* buffer count to framebuffer always is 1 at booting time. */
@@ -313,7 +302,7 @@ static void exynos_drm_fbdev_destroy(struct drm_device *dev,
struct exynos_drm_gem_obj *exynos_gem_obj = exynos_fbd-exynos_gem_obj;
struct drm_framebuffer *fb;
- if (is_drm_iommu_supported(dev) exynos_gem_obj-buffer-kvaddr)
+ if (exynos_gem_obj-buffer-kvaddr)
vunmap(exynos_gem_obj-buffer-kvaddr);
/* release drm framebuffer and real buffer */
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index ec58fe9..308173c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -22,6 +22,7 @@
/*
* exynos drm
[PATCH v2 0/2] dma: fix DMA_ATTR_NO_KERNEL_MAPPING for no-IOMMU platforms
The DMA_ATTR_NO_KERNEL_MAPPING attribute is used to notify dma-mapping core that the driver will not use kernel mapping for the allocated buffer at all, so the core can skip creating it. Unfortunately at the moment this attribute is only valid for IOMMU setups. In non-IOMMU setups the codepath doesn't obey DMA_ATTR_NO_KERNEL_MAPPING so when the CMA region is in high-memory all the buffers created with this attribute that do not require a kernel virtual address space still put pressure on the vmalloc area (for reference see http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/279325.html) This patchset is composed by two patches. The first patch fixes the Exynos DRM driver so that it keeps working when the non-IOMMU DMA layer is fixed. The Exynos DRM driver doesn't follow the recommendations in DMA-attributes.txt so in the non-IOMMU case when DMA_ATTR_NO_KERNEL_MAPPING is used the driver directly uses the returned kernel virtual address which it explicitly requested not to be assigned. That must be fixed before the underlying DMA subsystem is improved to obey DMA_ATTR_NO_KERNEL_MAPPING. The second patch implements DMA_ATTR_NO_KERNEL_MAPPING for non-IOMMU capable platforms. Please note that: * The first patch must be applied before the second one to avoid breaking the Exynos DRM driver. This patch without the DMA layer fix works fine (we save git-bisect) but it's not fully correct (we have double mapping in kernel address space). * The second patch breaks the Exynos DRM driver unless the first patch is * applied first Changelog v2: * Return page instead of page as cookie so the caller can detect if __alloc_remap_buffer or __alloc_from_contiguous fails to allocate the buffer Carlo Caione (1): drm/exynos: fix DMA_ATTR_NO_KERNEL_MAPPING usage Jasper St. Pierre (1): arm/dma-mapping: Respect NO_KERNEL_MAPPING when we don't have an IOMMU arch/arm/mm/dma-mapping.c | 67 +++ drivers/gpu/drm/exynos/exynos_drm_buf.c | 6 +-- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 29 + drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 + 4 files changed, 55 insertions(+), 49 deletions(-) -- 2.2.2 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/exynos: hdmi: replace fb size with mode size from win commit
On 2015년 01월 30일 17:30, Seung-Woo Kim wrote:
For default graphic window, mixer_win_commit() sets display size
register as fb size. Calling setplane with smaller fb size than
mode size to default window causes distorted display result. So
this patch replaces fb size with mode size for display size from
the mixer_win_commit().
Applied.
Thanks,
Inki Dae
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
---
drivers/gpu/drm/exynos/exynos_mixer.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 6766271..086fe0e 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -584,8 +584,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
int win)
/* setup display size */
if (ctx-mxr_ver == MXR_VER_128_0_0_184
win == MIXER_DEFAULT_WIN) {
- val = MXR_MXR_RES_HEIGHT(win_data-fb_height);
- val |= MXR_MXR_RES_WIDTH(win_data-fb_width);
+ val = MXR_MXR_RES_HEIGHT(win_data-mode_height);
+ val |= MXR_MXR_RES_WIDTH(win_data-mode_width);
mixer_reg_write(res, MXR_RESOLUTION, val);
}
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] mmc: pwrseq: add driver for emmc hardware reset
On 3 February 2015 at 14:07, Marek Szyprowski m.szyprow...@samsung.com wrote:
This patch provides a simple mmc-pwrseq-emmc driver, which controls
single gpio line. It perform standard eMMC hw reset procedure, as
descibed by Jedec 4.4 specification. This procedure is performed just
after MMC core enabled power to the given mmc host (to fix possible
issues if bootloader has left eMMC card in initialized or unknown
state), and before performing complete system reboot (also in case of
emergency reboot call). The latter is needed on boards, which doesn't
have hardware reset logic connected to emmc card and (limited or broken)
ROM bootloaders are unable to read second stage from the emmc card if
the card is left in unknown or already initialized state.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Thanks! Applied for next, with a minor fix for a checkpatch warning. See below.
Kind regards
Uffe
---
Changelog:
v4:
- fixed minor issues reported by Ulf Hansson (comment adjustments,
removed .shutdown callback, reduced delay time)
v3: http://www.spinics.net/lists/linux-samsung-soc/msg41956.html
- removed optional support for reset-gpio, reported by Javier Martinez
Canillas
v2: http://www.spinics.net/lists/linux-mmc/msg30621.html
---
.../devicetree/bindings/mmc/mmc-pwrseq-emmc.txt| 25 +
drivers/mmc/core/Makefile | 2 +-
drivers/mmc/core/pwrseq.c | 3 +
drivers/mmc/core/pwrseq.h | 1 +
drivers/mmc/core/pwrseq_emmc.c | 101
+
5 files changed, 131 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.txt
create mode 100644 drivers/mmc/core/pwrseq_emmc.c
diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.txt
b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.txt
new file mode 100644
index 000..0cb827b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.txt
@@ -0,0 +1,25 @@
+* The simple eMMC hardware reset provider
+
+The purpose of this driver is to perform standard eMMC hw reset
+procedure, as descibed by Jedec 4.4 specification. This procedure is
+performed just after MMC core enabled power to the given mmc host (to
+fix possible issues if bootloader has left eMMC card in initialized or
+unknown state), and before performing complete system reboot (also in
+case of emergency reboot call). The latter is needed on boards, which
+doesn't have hardware reset logic connected to emmc card and (limited or
+broken) ROM bootloaders are unable to read second stage from the emmc
+card if the card is left in unknown or already initialized state.
+
+Required properties:
+- compatible : contains mmc-pwrseq-emmc.
+- reset-gpios : contains a GPIO specifier. The reset GPIO is asserted
+ and then deasserted to perform eMMC card reset. To perform
+ reset procedure as described in Jedec 4.4 specification, the
+ gpio line should be defined as GPIO_ACTIVE_LOW.
+
+Example:
+
+ sdhci0_pwrseq {
+ compatible = mmc-pwrseq-emmc;
+ reset-gpios = gpio1 12 GPIO_ACTIVE_LOW;
+ }
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index b39cbd2..2c25138 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -8,5 +8,5 @@ mmc_core-y := core.o bus.o host.o \
sdio.o sdio_ops.o sdio_bus.o \
sdio_cis.o sdio_io.o sdio_irq.o \
quirks.o slot-gpio.o
-mmc_core-$(CONFIG_OF) += pwrseq.o pwrseq_simple.o
+mmc_core-$(CONFIG_OF) += pwrseq.o pwrseq_simple.o pwrseq_emmc.o
mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
diff --git a/drivers/mmc/core/pwrseq.c b/drivers/mmc/core/pwrseq.c
index 2cea00e..8623561 100644
--- a/drivers/mmc/core/pwrseq.c
+++ b/drivers/mmc/core/pwrseq.c
@@ -26,6 +26,9 @@ static struct mmc_pwrseq_match pwrseq_match[] = {
{
.compatible = mmc-pwrseq-simple,
.alloc = mmc_pwrseq_simple_alloc,
+ }, {
+ .compatible = mmc-pwrseq-emmc,
+ .alloc = mmc_pwrseq_emmc_alloc,
},
};
diff --git a/drivers/mmc/core/pwrseq.h b/drivers/mmc/core/pwrseq.h
index bd860d8..aba3409 100644
--- a/drivers/mmc/core/pwrseq.h
+++ b/drivers/mmc/core/pwrseq.h
@@ -28,6 +28,7 @@ void mmc_pwrseq_power_off(struct mmc_host *host);
void mmc_pwrseq_free(struct mmc_host *host);
int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct device *dev);
+int mmc_pwrseq_emmc_alloc(struct mmc_host *host, struct device *dev);
#else
diff --git a/drivers/mmc/core/pwrseq_emmc.c b/drivers/mmc/core/pwrseq_emmc.c
new file mode 100644
index 000..8a434d7
--- /dev/null
+++ b/drivers/mmc/core/pwrseq_emmc.c
@@ -0,0 +1,101 @@
+/*
+ *
[PATCH v2 2/2] arm/dma-mapping: Respect NO_KERNEL_MAPPING when we don't have an IOMMU
From: Jasper St. Pierre jstpie...@mecheye.net
Even without an iommu, NO_KERNEL_MAPPING is still convenient to save on
kernel address space in places where we don't need a kernel mapping.
Implement support for it in the two places where we're creating an
expensive mapping.
__alloc_from_pool uses an internal pool from which we already have
virtual addresses, so it's not relevant, and __alloc_simple_buffer uses
alloc_pages, which will always return a lowmem page, which is already
mapped into kernel space, so we can't prevent a mapping for it in that
case.
Signed-off-by: Jasper St. Pierre jstpie...@mecheye.net
Signed-off-by: Carlo Caione ca...@caione.org
Reviewed-by: Rob Clark robdcl...@gmail.com
Reviewed-by: Daniel Drake d...@endlessm.com
---
arch/arm/mm/dma-mapping.c | 67 +--
1 file changed, 41 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index a673c7f..d767bba 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -289,11 +289,11 @@ static void __dma_free_buffer(struct page *page, size_t
size)
static void *__alloc_from_contiguous(struct device *dev, size_t size,
pgprot_t prot, struct page **ret_page,
-const void *caller);
+const void *caller, bool want_vaddr);
static void *__alloc_remap_buffer(struct device *dev, size_t size, gfp_t gfp,
pgprot_t prot, struct page **ret_page,
-const void *caller);
+const void *caller, bool want_vaddr);
static void *
__dma_alloc_remap(struct page *page, size_t size, gfp_t gfp, pgprot_t prot,
@@ -357,10 +357,10 @@ static int __init atomic_pool_init(void)
if (dev_get_cma_area(NULL))
ptr = __alloc_from_contiguous(NULL, atomic_pool_size, prot,
- page, atomic_pool_init);
+ page, atomic_pool_init, true);
else
ptr = __alloc_remap_buffer(NULL, atomic_pool_size, gfp, prot,
- page, atomic_pool_init);
+ page, atomic_pool_init, true);
if (ptr) {
int ret;
@@ -467,13 +467,15 @@ static void __dma_remap(struct page *page, size_t size,
pgprot_t prot)
static void *__alloc_remap_buffer(struct device *dev, size_t size, gfp_t gfp,
pgprot_t prot, struct page **ret_page,
-const void *caller)
+const void *caller, bool want_vaddr)
{
struct page *page;
- void *ptr;
+ void *ptr = NULL;
page = __dma_alloc_buffer(dev, size, gfp);
if (!page)
return NULL;
+ if (!want_vaddr)
+ goto out;
ptr = __dma_alloc_remap(page, size, gfp, prot, caller);
if (!ptr) {
@@ -481,6 +483,7 @@ static void *__alloc_remap_buffer(struct device *dev,
size_t size, gfp_t gfp,
return NULL;
}
+ out:
*ret_page = page;
return ptr;
}
@@ -523,12 +526,12 @@ static int __free_from_pool(void *start, size_t size)
static void *__alloc_from_contiguous(struct device *dev, size_t size,
pgprot_t prot, struct page **ret_page,
-const void *caller)
+const void *caller, bool want_vaddr)
{
unsigned long order = get_order(size);
size_t count = size PAGE_SHIFT;
struct page *page;
- void *ptr;
+ void *ptr = NULL;
page = dma_alloc_from_contiguous(dev, count, order);
if (!page)
@@ -536,6 +539,9 @@ static void *__alloc_from_contiguous(struct device *dev,
size_t size,
__dma_clear_buffer(page, size);
+ if (!want_vaddr)
+ goto out;
+
if (PageHighMem(page)) {
ptr = __dma_alloc_remap(page, size, GFP_KERNEL, prot, caller);
if (!ptr) {
@@ -546,17 +552,21 @@ static void *__alloc_from_contiguous(struct device *dev,
size_t size,
__dma_remap(page, size, prot);
ptr = page_address(page);
}
+
+ out:
*ret_page = page;
return ptr;
}
static void __free_from_contiguous(struct device *dev, struct page *page,
- void *cpu_addr, size_t size)
+ void *cpu_addr, size_t size, bool want_vaddr)
{
- if (PageHighMem(page))
- __dma_free_remap(cpu_addr, size);
- else
- __dma_remap(page, size, PAGE_KERNEL);
+ if (want_vaddr) {
+ if (PageHighMem(page))
+ __dma_free_remap(cpu_addr, size);
+ else
+
Re: [PATCH] exynos/drm: fix no hdmi output
Hi,
On 2015년 01월 30일 06:18, 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_drm_manager)
changed the call order of mixer_initialize with regards to
exynos_drm_crtc_create.
This changes breaks hdmi out on Odroid U2 (linux-next with added
Marek Szyprowski v4 hdmi patchset from linux-samsung-soc ML).
Restore the previous call ordering get hdmi to ouput proper pixels:
ie call mixer_initialize first then exynos_drm_crtc_create.
Applied. Please use prefix of subject correctly, drm/exynos because your
patch is filtered in my mail box.
Thanks,
Inki Dae
Fixes: 93bca243ec96 (drm/exynos: remove struct exynos_drm_manager)
Signed-off-by: Alban Browaeys pra...@yahoo.com
---
drivers/gpu/drm/exynos/exynos_mixer.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index d8fd8e1..188f90f 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1258,18 +1258,19 @@ static int mixer_bind(struct device *dev, struct
device *manager, void *data)
struct drm_device *drm_dev = data;
int ret;
+ ret = mixer_initialize(ctx, drm_dev);
+ if (ret)
+ return ret;
+
ctx-crtc = exynos_drm_crtc_create(drm_dev, ctx-pipe,
EXYNOS_DISPLAY_TYPE_HDMI,
mixer_crtc_ops, ctx);
if (IS_ERR(ctx-crtc)) {
+ mixer_ctx_remove(ctx);
ret = PTR_ERR(ctx-crtc);
goto free_ctx;
}
- ret = mixer_initialize(ctx, drm_dev);
- if (ret)
- goto free_ctx;
-
return 0;
free_ctx:
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cpufreq: exynos: Use simple approach to asses if cpu cooling can be used
Hi Eduardo,
On 26 January 2015 at 14:55, Lukasz Majewski l.majew...@samsung.com
wrote:
Commit: e725d26c4857e5e41975b5e74e64ce6ab09a7121 provided
possibility to use device tree to asses if cpu can be used as
cooling device. Since the code was somewhat awkward, simpler
approach has been proposed.
Test HW: Exynos 4412 - Odroid U3.
Suggested-by: Viresh Kumar viresh.ku...@linaro.org
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
drivers/cpufreq/exynos-cpufreq.c | 21 ++---
1 file changed, 6 insertions(+), 15 deletions(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c
b/drivers/cpufreq/exynos-cpufreq.c index 5e98c6b..b640da0 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -159,7 +159,7 @@ static struct cpufreq_driver exynos_driver = {
static int exynos_cpufreq_probe(struct platform_device *pdev)
{
- struct device_node *cpus, *np;
+ struct device_node *cpu0, *np;
int ret = -EINVAL;
exynos_info = kzalloc(sizeof(*exynos_info), GFP_KERNEL);
@@ -206,28 +206,19 @@ static int exynos_cpufreq_probe(struct
platform_device *pdev) if (ret)
goto err_cpufreq_reg;
- cpus = of_find_node_by_path(/cpus);
- if (!cpus) {
- pr_err(failed to find cpus node\n);
+ cpu0 = of_get_cpu_node(0, NULL);
+ if (!cpu0) {
+ pr_err(failed to find cpu0 node\n);
return 0;
}
- np = of_get_next_child(cpus, NULL);
- if (!np) {
- pr_err(failed to find cpus child node\n);
- of_node_put(cpus);
- return 0;
- }
-
- if (of_find_property(np, #cooling-cells, NULL)) {
- cdev = of_cpufreq_cooling_register(np,
+ if (of_find_property(cpu0, #cooling-cells, NULL)) {
+ cdev = of_cpufreq_cooling_register(cpu0,
cpu_present_mask);
if (IS_ERR(cdev))
pr_err(running cpufreq without cooling
device: %ld\n, PTR_ERR(cdev));
}
- of_node_put(np);
- of_node_put(cpus);
return 0;
Acked-by: Viresh Kumar viresh.ku...@linaro.org
Could you apply this patch to yours linux-soc-thermal tree?
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 02/13] clk: samsung: exynos5433: Add clocks using common clock framework
Hi Chanwoo,
On 02/02/15 15:23, Chanwoo Choi wrote:
+/*
+ * ATLAS_PLL APOLLO_PLL MEM0_PLL MEM1_PLL BUS_PLL MFC_PLL
+ * MPHY_PLL G3D_PLL DISP_PLL ISP_PLL
+ */
+static struct samsung_pll_rate_table exynos5443_pll_rates[] = {
+ PLL_35XX_RATE(25, 625, 6, 0),
+ PLL_35XX_RATE(24, 500, 5, 0),
+ PLL_35XX_RATE(23, 575, 6, 0),
+ PLL_35XX_RATE(22, 550, 6, 0),
+ PLL_35XX_RATE(21, 350, 4, 0),
+ PLL_35XX_RATE(20, 500, 6, 0),
+ PLL_35XX_RATE(19, 475, 6, 0),
+ PLL_35XX_RATE(18, 375, 5, 0),
+ PLL_35XX_RATE(17, 425, 6, 0),
+ PLL_35XX_RATE(16, 400, 6, 0),
+ PLL_35XX_RATE(15, 250, 4, 0),
+ PLL_35XX_RATE(14, 350, 6, 0),
+ PLL_35XX_RATE(133200, 222, 4, 0),
+ PLL_35XX_RATE(13, 325, 6, 0),
+ PLL_35XX_RATE(12, 500, 5, 1),
+ PLL_35XX_RATE(11, 550, 6, 1),
+ PLL_35XX_RATE(108600, 362, 4, 1),
+ PLL_35XX_RATE(106600, 533, 6, 1),
+ PLL_35XX_RATE(10, 500, 6, 1),
+ PLL_35XX_RATE(93300, 311, 4, 1),
+ PLL_35XX_RATE(92100, 307, 4, 1),
+ PLL_35XX_RATE(9, 375, 5, 1),
+ PLL_35XX_RATE(82500, 275, 4, 1),
+ PLL_35XX_RATE(8, 400, 6, 1),
+ PLL_35XX_RATE(73300, 733, 12, 1),
+ PLL_35XX_RATE(7, 360, 6, 1),
+ PLL_35XX_RATE(66700, 222, 4, 1),
+ PLL_35XX_RATE(63300, 211, 4, 1),
+ PLL_35XX_RATE(6, 500, 5, 2),
+ PLL_35XX_RATE(55200, 460, 5, 2),
+ PLL_35XX_RATE(55000, 550, 6, 2),
+ PLL_35XX_RATE(54300, 362, 4, 2),
+ PLL_35XX_RATE(53300, 533, 6, 2),
+ PLL_35XX_RATE(5, 500, 6, 2),
+ PLL_35XX_RATE(44400, 370, 5, 2),
+ PLL_35XX_RATE(42000, 350, 5, 2),
+ PLL_35XX_RATE(4, 400, 6, 2),
+ PLL_35XX_RATE(35000, 360, 6, 2),
+ PLL_35XX_RATE(33300, 222, 4, 2),
+ PLL_35XX_RATE(3, 500, 5, 3),
+ PLL_35XX_RATE(26600, 532, 6, 3),
+ PLL_35XX_RATE(2, 400, 6, 3),
+ PLL_35XX_RATE(16600, 332, 6, 3),
+ PLL_35XX_RATE(16000, 320, 6, 3),
+ PLL_35XX_RATE(13300, 552, 6, 4),
+ PLL_35XX_RATE(1, 400, 6, 4),
+ { /* sentinel */ }
+};
+
+/* AUD_PLL */
+static struct samsung_pll_rate_table exynos5443_aud_pll_rates[] = {
+ PLL_36XX_RATE(4, 200, 3, 2, 0),
+ PLL_36XX_RATE(393216000, 197, 3, 2, -25690),
+ PLL_36XX_RATE(38400, 128, 2, 2, 0),
+ PLL_36XX_RATE(36864, 246, 4, 2, -15729),
+ PLL_36XX_RATE(361507200, 181, 3, 2, -16148),
+ PLL_36XX_RATE(338688000, 113, 2, 2, -6816),
+ PLL_36XX_RATE(294912000, 98, 1, 3, 19923),
+ PLL_36XX_RATE(28800, 96, 1, 3, 0),
+ PLL_36XX_RATE(25200, 84, 1, 3, 0),
+ { /* sentinel */ }
+};
To avoid issues pointed out by these build warnings:
drivers/clk/samsung/clk-exynos5433.c:726:2: warning: this decimal constant is
unsigned only in ISO C90 [enabled by default]
drivers/clk/samsung/clk-exynos5433.c:727:2: warning: this decimal constant is
unsigned only in ISO C90 [enabled by default]
drivers/clk/samsung/clk-exynos5433.c:728:2: warning: this decimal constant is
unsigned only in ISO C90 [enabled by default]
drivers/clk/samsung/clk-exynos5433.c:729:2: warning: this decimal constant is
unsigned only in ISO C90 [enabled by default]
I have squashed following change to the $subject patch:
---8---
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index bdd4113..7a024cd 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -723,66 +723,66 @@ static struct samsung_gate_clock top_gate_clks[]
__initdata = {
* MPHY_PLL G3D_PLL DISP_PLL ISP_PLL
*/
static struct samsung_pll_rate_table exynos5443_pll_rates[] = {
- PLL_35XX_RATE(25, 625, 6, 0),
- PLL_35XX_RATE(24, 500, 5, 0),
- PLL_35XX_RATE(23, 575, 6, 0),
- PLL_35XX_RATE(22, 550, 6, 0),
- PLL_35XX_RATE(21, 350, 4, 0),
- PLL_35XX_RATE(20, 500, 6, 0),
- PLL_35XX_RATE(19, 475, 6, 0),
- PLL_35XX_RATE(18, 375, 5, 0),
- PLL_35XX_RATE(17, 425, 6, 0),
- PLL_35XX_RATE(16, 400, 6, 0),
- PLL_35XX_RATE(15, 250, 4, 0),
- PLL_35XX_RATE(14, 350, 6, 0),
- PLL_35XX_RATE(133200, 222, 4, 0),
- PLL_35XX_RATE(13, 325, 6, 0),
- PLL_35XX_RATE(12, 500, 5, 1),
- PLL_35XX_RATE(11, 550, 6, 1),
- PLL_35XX_RATE(108600, 362, 4, 1),
- PLL_35XX_RATE(106600, 533, 6, 1),
- PLL_35XX_RATE(10, 500, 6, 1),
- PLL_35XX_RATE(93300, 311, 4, 1),
- PLL_35XX_RATE(92100, 307, 4, 1),
-
Re: [PATCH] ARM: EXYNOS: cpuidle: Fix build breakage on !SMP
Hi,
On Wednesday, February 04, 2015 11:27:26 AM Krzysztof Kozlowski wrote:
The Exynos cpuidle driver has coupled cpuidle built-in so it cannot be
built without SMP:
arch/arm/mach-exynos/pm.c: In function ‘exynos_cpu0_enter_aftr’:
arch/arm/mach-exynos/pm.c:246:4: error: implicit declaration of function
‘arch_send_wakeup_ipi_mask’ [-Werror=implicit-function-declaration]
arch/arm/mach-exynos/built-in.o: In function `exynos_pre_enter_aftr':
../arch/arm/mach-exynos/pm.c:300: undefined reference to `cpu_boot_reg_base'
arch/arm/mach-exynos/built-in.o: In function `exynos_cpu1_powerdown':
../arch/arm/mach-exynos/pm.c:282: undefined reference to
`exynos_cpu_power_down'
Make the cpuidle driver depending on SMP because this will be the
fastest way to fix build break without adding a bunch of ifdefs in few
places.
There shouldn't be a lot of new ifdefs (please see below) and I would
very much prefer for cpuidle to stay supported also on UP kernels.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
arch/arm/mach-exynos/pm.c | 2 ++
drivers/cpuidle/Kconfig.arm | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index e6209dadc00d..17db00ff7f3a 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -181,6 +181,7 @@ void exynos_enter_aftr(void)
cpu_pm_exit();
}
+#ifdef CONFIG_ARM_EXYNOS_CPUIDLE
static atomic_t cpu1_wakeup = ATOMIC_INIT(0);
static int exynos_cpu0_enter_aftr(void)
@@ -302,3 +303,4 @@ struct cpuidle_exynos_data cpuidle_coupled_exynos_data = {
.pre_enter_aftr = exynos_pre_enter_aftr,
.post_enter_aftr= exynos_post_enter_aftr,
};
+#endif /* CONFIG_ARM_EXYNOS_CPUIDLE */
diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
index 8e07c9419153..5eb86a4f74d9 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -55,7 +55,8 @@ config ARM_AT91_CPUIDLE
config ARM_EXYNOS_CPUIDLE
bool Cpu Idle Driver for the Exynos processors
depends on ARCH_EXYNOS
- select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
+ depends on SMP
+ select ARCH_NEEDS_CPU_IDLE_COUPLED
help
Select this to enable cpuidle for Exynos processors
How's about the patch below instead? It builds fine for UP and SMP.
I will do more testing tomorrow (unfortunately it seems that something
else broke Origen4210 in -next).
From: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Subject: [PATCH] ARM: EXYNOS: cpuidle: Fix build breakage on !SMP
The Exynos cpuidle driver has coupled cpuidle built-in so it cannot be
built without SMP:
arch/arm/mach-exynos/pm.c: In function ‘exynos_cpu0_enter_aftr’:
arch/arm/mach-exynos/pm.c:246:4: error: implicit declaration of function
‘arch_send_wakeup_ipi_mask’ [-Werror=implicit-function-declaration]
arch/arm/mach-exynos/built-in.o: In function `exynos_pre_enter_aftr':
../arch/arm/mach-exynos/pm.c:300: undefined reference to `cpu_boot_reg_base'
arch/arm/mach-exynos/built-in.o: In function `exynos_cpu1_powerdown':
../arch/arm/mach-exynos/pm.c:282: undefined reference to `exynos_cpu_power_down'
Fix it by adding missing checks for SMP.
Reported-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
arch/arm/mach-exynos/exynos.c|2 +-
arch/arm/mach-exynos/pm.c|2 ++
drivers/cpuidle/cpuidle-exynos.c |3 ++-
3 files changed, 5 insertions(+), 2 deletions(-)
Index: b/arch/arm/mach-exynos/exynos.c
===
--- a/arch/arm/mach-exynos/exynos.c 2015-02-04 18:30:23.555819717 +0100
+++ b/arch/arm/mach-exynos/exynos.c 2015-02-04 18:43:23.539807815 +0100
@@ -211,7 +211,7 @@ static void __init exynos_dt_machine_ini
if (!IS_ENABLED(CONFIG_SMP))
exynos_sysram_init();
-#ifdef CONFIG_ARM_EXYNOS_CPUIDLE
+#if defined(CONFIG_SMP) defined(CONFIG_ARM_EXYNOS_CPUIDLE)
if (of_machine_is_compatible(samsung,exynos4210))
exynos_cpuidle.dev.platform_data = cpuidle_coupled_exynos_data;
#endif
Index: b/arch/arm/mach-exynos/pm.c
===
--- a/arch/arm/mach-exynos/pm.c 2015-02-04 18:30:23.563819719 +0100
+++ b/arch/arm/mach-exynos/pm.c 2015-02-04 18:47:32.951804008 +0100
@@ -181,6 +181,7 @@ void exynos_enter_aftr(void)
cpu_pm_exit();
}
+#if defined(CONFIG_SMP) defined(CONFIG_ARM_EXYNOS_CPUIDLE)
static atomic_t cpu1_wakeup = ATOMIC_INIT(0);
static int exynos_cpu0_enter_aftr(void)
@@ -302,3 +303,4 @@ struct cpuidle_exynos_data cpuidle_coupl
.pre_enter_aftr = exynos_pre_enter_aftr,
.post_enter_aftr= exynos_post_enter_aftr,
};
+#endif /* CONFIG_SMP CONFIG_ARM_EXYNOS_CPUIDLE */
Index: b/drivers/cpuidle/cpuidle-exynos.c
[PATCH] GPU-DRM-Exynos: Delete unnecessary checks before two function calls
From: Markus Elfring elfr...@users.sourceforge.net
Date: Wed, 4 Feb 2015 21:54:45 +0100
The functions phy_power_on() and vunmap() perform also input
parameter validation. Thus the test around their calls is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring elfr...@users.sourceforge.net
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 6 ++
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +-
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 34d46aa..306cf1d 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1057,14 +1057,12 @@ static int exynos_dp_create_connector(struct
exynos_drm_display *display,
static void exynos_dp_phy_init(struct exynos_dp_device *dp)
{
- if (dp-phy)
- phy_power_on(dp-phy);
+ phy_power_on(dp-phy);
}
static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
{
- if (dp-phy)
- phy_power_off(dp-phy);
+ phy_power_off(dp-phy);
}
static void exynos_dp_poweron(struct exynos_drm_display *display)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index e12ea90..0dd448a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -313,7 +313,7 @@ static void exynos_drm_fbdev_destroy(struct drm_device *dev,
struct exynos_drm_gem_obj *exynos_gem_obj = exynos_fbd-exynos_gem_obj;
struct drm_framebuffer *fb;
- if (is_drm_iommu_supported(dev) exynos_gem_obj-buffer-kvaddr)
+ if (is_drm_iommu_supported(dev))
vunmap(exynos_gem_obj-buffer-kvaddr);
/* release drm framebuffer and real buffer */
--
2.2.2
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/9] Enable HDMI support on Exynos platforms
On 02/04/15 09:09, Joonyoung Shim wrote: Hi, Hi, On 02/03/2015 12:58 PM, Kukjin Kim wrote: Marek Szyprowski wrote: Hi all, This is yet another update on patchset, which enables HDMI support for Exynos based platforms. Beside DTS changes, this patchset adds parent domain support for Exynos PM domains and add support for 'hdmi' clock directly to Exynos DRM mixer driver. The patchset is based on samsung/for-next branch and 'PM / Domains: Export of_genpd_get_from_provider function' patch merged as commit 7496fcbe8a643097efc061160e1c3b65ee2fa350 to v3.19-rc4. Regards Marek Szyprowski Changelog: v5: - fixed error value for clk_get() in mixer patch - rebased onto samsung/for-next branch v4: (http://www.spinics.net/lists/linux-samsung-soc/msg41375.html) - added patches, which add 'hdmi' clock handling to mixed block, this finally solves the initialization related issues, thanks for Tobias Jakobi for testing - added acks/reviewed/tested by tags v3: (http://www.spinics.net/lists/linux-samsung-soc/msg41020.html) - added a note on defining subdomains to generic PM domain binding documentation (requested by Ulf Hansson) v2: (http://www.spinics.net/lists/linux-samsung-soc/msg40980.html) - rewrote subdomains patch according to suggestions from Geert Uytterhoeven and Amit Daniel Kachhap. v1 resend: (http://www.spinics.net/lists/linux-samsung-soc/msg39428.html) - added handling of generic 'power-domains' binding in subdomains v1: (http://www.spinics.net/lists/linux-samsung-soc/msg38914.html) - resolved power domain on/off issue with 'clk: samsung: exynos4: set parent of mixer gate clock to hdmi' patch v0: (http://www.spinics.net/lists/linux-samsung-soc/msg33498.html) - first attempt, used 'always on' power domains hack Patch summary: *** BLURB HERE *** Andrzej Hajda (1): ARM: dts: exynos5250: add display power domain Marek Szyprowski (7): PM / Domains: Add a note about power domain subdomains ARM: Exynos: add support for sub-power domains ARM: dts: exynos4: add hdmi related nodes ARM: dts: exynos4: add dependency between TV and LCD0 power domains ARM: dts: exynos4412-odroid: enable hdmi support ARM: dts: Exynos: add 'hdmi' clock to mixer nodes drm/exynos: add support for 'hdmi' clock Tomasz Stanislawski (1): ARM: dts: exynos4210-universal_c210: enable hdmi support .../bindings/arm/exynos/power_domain.txt | 2 + .../devicetree/bindings/power/power_domain.txt | 29 +++ .../devicetree/bindings/video/exynos_mixer.txt | 1 + arch/arm/boot/dts/exynos4.dtsi | 41 arch/arm/boot/dts/exynos4210-universal_c210.dts| 57 ++ arch/arm/boot/dts/exynos4210.dtsi | 8 +++ arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 44 + arch/arm/boot/dts/exynos4x12.dtsi | 11 + arch/arm/boot/dts/exynos5250.dtsi | 15 +- arch/arm/boot/dts/exynos5420.dtsi | 5 +- arch/arm/mach-exynos/pm_domains.c | 28 +++ drivers/gpu/drm/exynos/exynos_mixer.c | 9 12 files changed, 246 insertions(+), 4 deletions(-) -- I have no objection on this series, but just wondering my tree should be fine without 9/9 drm patch and it will be handled for 3.20? I'll take 1 to 8 patches once drm patch is landed for 3.20. I also hope this patchset merged, Inki, could you follow up exynos drm part of this patchset? I checked and I'll apply 1 to 8 patches in samsung tree. Thanks, Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 02/13] clk: samsung: exynos5433: Add clocks using common clock framework
Hi Sylwester,
On 02/05/2015 03:08 AM, Sylwester Nawrocki wrote:
Hi Chanwoo,
On 02/02/15 15:23, Chanwoo Choi wrote:
+/*
+ * ATLAS_PLL APOLLO_PLL MEM0_PLL MEM1_PLL BUS_PLL MFC_PLL
+ * MPHY_PLL G3D_PLL DISP_PLL ISP_PLL
+ */
+static struct samsung_pll_rate_table exynos5443_pll_rates[] = {
+PLL_35XX_RATE(25, 625, 6, 0),
+PLL_35XX_RATE(24, 500, 5, 0),
+PLL_35XX_RATE(23, 575, 6, 0),
+PLL_35XX_RATE(22, 550, 6, 0),
+PLL_35XX_RATE(21, 350, 4, 0),
+PLL_35XX_RATE(20, 500, 6, 0),
+PLL_35XX_RATE(19, 475, 6, 0),
+PLL_35XX_RATE(18, 375, 5, 0),
+PLL_35XX_RATE(17, 425, 6, 0),
+PLL_35XX_RATE(16, 400, 6, 0),
+PLL_35XX_RATE(15, 250, 4, 0),
+PLL_35XX_RATE(14, 350, 6, 0),
+PLL_35XX_RATE(133200, 222, 4, 0),
+PLL_35XX_RATE(13, 325, 6, 0),
+PLL_35XX_RATE(12, 500, 5, 1),
+PLL_35XX_RATE(11, 550, 6, 1),
+PLL_35XX_RATE(108600, 362, 4, 1),
+PLL_35XX_RATE(106600, 533, 6, 1),
+PLL_35XX_RATE(10, 500, 6, 1),
+PLL_35XX_RATE(93300, 311, 4, 1),
+PLL_35XX_RATE(92100, 307, 4, 1),
+PLL_35XX_RATE(9, 375, 5, 1),
+PLL_35XX_RATE(82500, 275, 4, 1),
+PLL_35XX_RATE(8, 400, 6, 1),
+PLL_35XX_RATE(73300, 733, 12, 1),
+PLL_35XX_RATE(7, 360, 6, 1),
+PLL_35XX_RATE(66700, 222, 4, 1),
+PLL_35XX_RATE(63300, 211, 4, 1),
+PLL_35XX_RATE(6, 500, 5, 2),
+PLL_35XX_RATE(55200, 460, 5, 2),
+PLL_35XX_RATE(55000, 550, 6, 2),
+PLL_35XX_RATE(54300, 362, 4, 2),
+PLL_35XX_RATE(53300, 533, 6, 2),
+PLL_35XX_RATE(5, 500, 6, 2),
+PLL_35XX_RATE(44400, 370, 5, 2),
+PLL_35XX_RATE(42000, 350, 5, 2),
+PLL_35XX_RATE(4, 400, 6, 2),
+PLL_35XX_RATE(35000, 360, 6, 2),
+PLL_35XX_RATE(33300, 222, 4, 2),
+PLL_35XX_RATE(3, 500, 5, 3),
+PLL_35XX_RATE(26600, 532, 6, 3),
+PLL_35XX_RATE(2, 400, 6, 3),
+PLL_35XX_RATE(16600, 332, 6, 3),
+PLL_35XX_RATE(16000, 320, 6, 3),
+PLL_35XX_RATE(13300, 552, 6, 4),
+PLL_35XX_RATE(1, 400, 6, 4),
+{ /* sentinel */ }
+};
+
+/* AUD_PLL */
+static struct samsung_pll_rate_table exynos5443_aud_pll_rates[] = {
+PLL_36XX_RATE(4, 200, 3, 2, 0),
+PLL_36XX_RATE(393216000, 197, 3, 2, -25690),
+PLL_36XX_RATE(38400, 128, 2, 2, 0),
+PLL_36XX_RATE(36864, 246, 4, 2, -15729),
+PLL_36XX_RATE(361507200, 181, 3, 2, -16148),
+PLL_36XX_RATE(338688000, 113, 2, 2, -6816),
+PLL_36XX_RATE(294912000, 98, 1, 3, 19923),
+PLL_36XX_RATE(28800, 96, 1, 3, 0),
+PLL_36XX_RATE(25200, 84, 1, 3, 0),
+{ /* sentinel */ }
+};
To avoid issues pointed out by these build warnings:
drivers/clk/samsung/clk-exynos5433.c:726:2: warning: this decimal constant is
unsigned only in ISO C90 [enabled by default]
drivers/clk/samsung/clk-exynos5433.c:727:2: warning: this decimal constant is
unsigned only in ISO C90 [enabled by default]
drivers/clk/samsung/clk-exynos5433.c:728:2: warning: this decimal constant is
unsigned only in ISO C90 [enabled by default]
drivers/clk/samsung/clk-exynos5433.c:729:2: warning: this decimal constant is
unsigned only in ISO C90 [enabled by default]
I have squashed following change to the $subject patch:
Thanks for your fixup.
Best Regards,
Chanwoo Choi
---8---
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index bdd4113..7a024cd 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -723,66 +723,66 @@ static struct samsung_gate_clock top_gate_clks[]
__initdata = {
* MPHY_PLL G3D_PLL DISP_PLL ISP_PLL
*/
static struct samsung_pll_rate_table exynos5443_pll_rates[] = {
- PLL_35XX_RATE(25, 625, 6, 0),
- PLL_35XX_RATE(24, 500, 5, 0),
- PLL_35XX_RATE(23, 575, 6, 0),
- PLL_35XX_RATE(22, 550, 6, 0),
- PLL_35XX_RATE(21, 350, 4, 0),
- PLL_35XX_RATE(20, 500, 6, 0),
- PLL_35XX_RATE(19, 475, 6, 0),
- PLL_35XX_RATE(18, 375, 5, 0),
- PLL_35XX_RATE(17, 425, 6, 0),
- PLL_35XX_RATE(16, 400, 6, 0),
- PLL_35XX_RATE(15, 250, 4, 0),
- PLL_35XX_RATE(14, 350, 6, 0),
- PLL_35XX_RATE(133200, 222, 4, 0),
- PLL_35XX_RATE(13, 325, 6, 0),
- PLL_35XX_RATE(12, 500, 5, 1),
- PLL_35XX_RATE(11, 550, 6, 1),
- PLL_35XX_RATE(108600, 362, 4, 1),
- PLL_35XX_RATE(106600, 533, 6, 1),
- PLL_35XX_RATE(10, 500, 6, 1),
Re: [PATCH 04/14] drm/exynos: remove struct *_win_data abstraction on planes
Hi Daniel,
On 02/04/2015 11:28 PM, Daniel Vetter wrote:
On Wed, Feb 04, 2015 at 04:44:12PM +0900, Joonyoung Shim wrote:
Hi,
On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
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_mode_set() callback
that was only filling all *_win_data structs.
I commented already on prior patch.
I think you don't quite understand how this primary/overlay plane stuff
works in drm core. The entire point of the drm core primary plane is to
work _exactly_ like an overlay plane and allow userspace to mangle the
primary plane configuration through the overlay plane. The only reason we
have primary planes is so that old userspace keeps working.
Right, i misunderstood a bit because exynos hw drivers have dependency
of zpos(hw overlay position).
Current exynos drm driver has each primary plane of hw drivers and five
overlay planes. The primary plane is fixed on default hw overlay and all
overlay plane can map to all hw overlays using specific zpos property of
exynos drm plane.
Gustavo approach will include specific hw overlay data in overlay plane
and hw driver keeps overlay planes to array by zpos order. But current
zpos of overlay plane is 0 always if user doesn't modify it, so hw
driver will use only hw overlay data of primary plane always even if
user want to use overlay plane.
If user is modified zpos of overlay plane, hw driver can get wrong hw
overlay data from different overlay plane because hw driver keeps
overlay planes by zpos order.
Thanks.
When I've done the testconversion with exynos to validate my atomic
helpers I've noticed that exynos makes a mess here, and on a quick look
Padovan seems to fix this up here. Not a detailed review, but this has my
Ack.
-Daniel
Thanks.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 9 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 1 +
drivers/gpu/drm/exynos/exynos_drm_drv.c | 14 --
drivers/gpu/drm/exynos/exynos_drm_drv.h | 5 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 182 ++---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 20 +--
drivers/gpu/drm/exynos/exynos_drm_plane.h | 6 +-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 123 +
drivers/gpu/drm/exynos/exynos_mixer.c | 212
+++---
9 files changed, 183 insertions(+), 389 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index ad675fb..d504f0b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -296,13 +296,13 @@ static void
exynos_drm_crtc_attach_mode_property(struct drm_crtc *crtc)
}
struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
+ struct drm_plane *plane,
int pipe,
enum exynos_drm_output_type type,
struct exynos_drm_crtc_ops *ops,
void *ctx)
{
struct exynos_drm_crtc *exynos_crtc;
- struct drm_plane *plane;
struct exynos_drm_private *private = drm_dev-dev_private;
struct drm_crtc *crtc;
int ret;
@@ -318,12 +318,6 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct
drm_device *drm_dev,
exynos_crtc-type = type;
exynos_crtc-ops = ops;
exynos_crtc-ctx = ctx;
- plane = exynos_plane_init(drm_dev, 1 pipe,
- DRM_PLANE_TYPE_PRIMARY);
- if (IS_ERR(plane)) {
- ret = PTR_ERR(plane);
- goto err_plane;
- }
crtc = exynos_crtc-base;
@@ -342,7 +336,6 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct
drm_device *drm_dev,
err_crtc:
plane-funcs-destroy(plane);
-err_plane:
kfree(exynos_crtc);
return ERR_PTR(ret);
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index 628b787..0ecd8fc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -18,6 +18,7 @@
#include exynos_drm_drv.h
struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
+ struct drm_plane *plane,
int pipe,
enum exynos_drm_output_type type,
struct exynos_drm_crtc_ops *ops,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 737164d..778c91e 100644
---
Re: [PATCH 08/14] drm/exynos: atomic phase 1: add atomic_begin()/atomic_flush()
Hi Daniel,
On 02/04/2015 11:30 PM, Daniel Vetter wrote:
On Wed, Feb 04, 2015 at 04:49:25PM +0900, Joonyoung Shim wrote:
Hi,
On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Add CRTC callbacks .atomic_begin() .atomic_flush(). On exynos they
unprotect the windows before the commit and protects it after based on
a plane mask tha store which plane will be updated.
I don't think they need now.
This does exactly what I wanted to do in my atomic poc but couldn't
because of the massive layer hell that was still around in atomic. Haven't
looked into the patch in details, so no full r-b but good enough for an
I agree about its operation but i think it is unnecessary now. Because
it's exactly same operation with current codes.
Acked-by: Daniel Vetter daniel.vet...@ffwll.ch
Aside: If you think something doesn't need to be done please explain what
you mean or at least ask about what you don't understand in a patch. As-is
your review is pretty much unactionable.
Yes, my fault, thanks for advice.
Thanks.
Thanks.
For that we create two new exynos_crtc callbacks: .win_protect() and
.win_unprotect(). The only driver that implement those now is FIMD.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 34 ++
drivers/gpu/drm/exynos/exynos_drm_drv.h | 4 +++
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 57
++-
drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 +++
4 files changed, 82 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 09d4780..be36cca 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -147,6 +147,38 @@ static void exynos_drm_crtc_disable(struct drm_crtc
*crtc)
}
}
+static void exynos_crtc_atomic_begin(struct drm_crtc *crtc)
+{
+ struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
+ struct drm_plane *plane;
+ int index = 0;
+
+ list_for_each_entry(plane, crtc-dev-mode_config.plane_list, head) {
+ if (exynos_crtc-ops-win_protect
+ exynos_crtc-plane_mask (0x01 index))
+ exynos_crtc-ops-win_protect(exynos_crtc, index);
+
+ index++;
+ }
+}
+
+static void exynos_crtc_atomic_flush(struct drm_crtc *crtc)
+{
+ struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
+ struct drm_plane *plane;
+ int index = 0;
+
+ list_for_each_entry(plane, crtc-dev-mode_config.plane_list, head) {
+ if (exynos_crtc-ops-win_unprotect
+ exynos_crtc-plane_mask (0x01 index))
+ exynos_crtc-ops-win_unprotect(exynos_crtc, index);
+
+ index++;
+ }
+
+ exynos_crtc-plane_mask = 0;
+}
+
static struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = {
.dpms = exynos_drm_crtc_dpms,
.prepare= exynos_drm_crtc_prepare,
@@ -155,6 +187,8 @@ static struct drm_crtc_helper_funcs
exynos_crtc_helper_funcs = {
.mode_set = exynos_drm_crtc_mode_set,
.mode_set_base = exynos_drm_crtc_mode_set_base,
.disable= exynos_drm_crtc_disable,
+ .atomic_begin = exynos_crtc_atomic_begin,
+ .atomic_flush = exynos_crtc_atomic_flush,
};
static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index cad54e7..43efd9f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -194,6 +194,8 @@ struct exynos_drm_crtc_ops {
void (*win_enable)(struct exynos_drm_crtc *crtc, int zpos);
void (*win_disable)(struct exynos_drm_crtc *crtc, int zpos);
void (*te_handler)(struct exynos_drm_crtc *crtc);
+ void (*win_protect)(struct exynos_drm_crtc *crtc, int zpos);
+ void (*win_unprotect)(struct exynos_drm_crtc *crtc, int zpos);
};
enum exynos_crtc_mode {
@@ -214,6 +216,7 @@ enum exynos_crtc_mode {
* we can refer to the crtc to current hardware interrupt occurred through
* this pipe value.
* @dpms: store the crtc dpms value
+ * @plane_mask: store planes to be updated on atomic modesetting
* @mode: store the crtc mode value
* @event: vblank event that is currently queued for flip
* @ops: pointer to callbacks for exynos drm specific functionality
@@ -224,6 +227,7 @@ struct exynos_drm_crtc {
enum exynos_drm_output_type type;
unsigned intpipe;
unsigned intdpms;
+ unsigned intplane_mask;
enum exynos_crtc_mode mode;
wait_queue_head_t pending_flip_queue;
struct drm_pending_vblank_event *event;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
Re: [PATCH 02/14] drm/exynos: Remove exynos_plane_dpms() call with no effect
Hi Daniel, On 02/04/2015 11:16 PM, Daniel Vetter wrote: On Wed, Feb 04, 2015 at 04:42:57PM +0900, Joonyoung Shim wrote: Hi, On 02/04/2015 04:14 AM, Gustavo Padovan wrote: From: Gustavo Padovan gustavo.pado...@collabora.co.uk 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 exynos_plane_dpms() is pointless. Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index b2a4b84..ad675fb 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -65,8 +65,6 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc) if (exynos_crtc-ops-commit) exynos_crtc-ops-commit(exynos_crtc); - - exynos_plane_dpms(crtc-primary, DRM_MODE_DPMS_ON); As i said, this needs to keep pair enabled flag of struct exynos_drm_plane. The reason exynos needs that exynos_plane-enable is because it has its own per-plane dpms state. There's two problems with that: - It's highyl non-standard, the drm kms way is to just disable the plane and not have some additional knob on top. - The atomic helpers will not be able to handle this. They assume that there's only one dpms knob for the entire display pipeline, and per-plane enable/disable is handled by setting plane-state-crtc, which must be set iff plane-state-fb is set right now. I recommend we rip this all out if we can adjust existing userspace to stop using the mode property on planes and crtcs. And with that non-standard exynos plane mode thing gone we can indeed rip out exynos_plane_dpms and exynos_plane-enabled and just directly call manager-ops-win_enable/disble. And then rip out the win_enable since it's unused. But this cleanup on current codes doesn't care now current operation normally. First let's cleanup non-standard exynos plane dpms state as you said. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: EXYNOS: cpuidle: Fix build breakage on !SMP
On śro, 2015-02-04 at 19:07 +0100, Bartlomiej Zolnierkiewicz wrote:
Hi,
On Wednesday, February 04, 2015 11:27:26 AM Krzysztof Kozlowski wrote:
The Exynos cpuidle driver has coupled cpuidle built-in so it cannot be
built without SMP:
arch/arm/mach-exynos/pm.c: In function ‘exynos_cpu0_enter_aftr’:
arch/arm/mach-exynos/pm.c:246:4: error: implicit declaration of function
‘arch_send_wakeup_ipi_mask’ [-Werror=implicit-function-declaration]
arch/arm/mach-exynos/built-in.o: In function `exynos_pre_enter_aftr':
../arch/arm/mach-exynos/pm.c:300: undefined reference to `cpu_boot_reg_base'
arch/arm/mach-exynos/built-in.o: In function `exynos_cpu1_powerdown':
../arch/arm/mach-exynos/pm.c:282: undefined reference to
`exynos_cpu_power_down'
Make the cpuidle driver depending on SMP because this will be the
fastest way to fix build break without adding a bunch of ifdefs in few
places.
There shouldn't be a lot of new ifdefs (please see below) and I would
very much prefer for cpuidle to stay supported also on UP kernels.
Sure, I'm fine with your patch.
Best regards,
Krzysztof
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
arch/arm/mach-exynos/pm.c | 2 ++
drivers/cpuidle/Kconfig.arm | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index e6209dadc00d..17db00ff7f3a 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -181,6 +181,7 @@ void exynos_enter_aftr(void)
cpu_pm_exit();
}
+#ifdef CONFIG_ARM_EXYNOS_CPUIDLE
static atomic_t cpu1_wakeup = ATOMIC_INIT(0);
static int exynos_cpu0_enter_aftr(void)
@@ -302,3 +303,4 @@ struct cpuidle_exynos_data cpuidle_coupled_exynos_data
= {
.pre_enter_aftr = exynos_pre_enter_aftr,
.post_enter_aftr= exynos_post_enter_aftr,
};
+#endif /* CONFIG_ARM_EXYNOS_CPUIDLE */
diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
index 8e07c9419153..5eb86a4f74d9 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -55,7 +55,8 @@ config ARM_AT91_CPUIDLE
config ARM_EXYNOS_CPUIDLE
bool Cpu Idle Driver for the Exynos processors
depends on ARCH_EXYNOS
- select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
+ depends on SMP
+ select ARCH_NEEDS_CPU_IDLE_COUPLED
help
Select this to enable cpuidle for Exynos processors
How's about the patch below instead? It builds fine for UP and SMP.
I will do more testing tomorrow (unfortunately it seems that something
else broke Origen4210 in -next).
From: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Subject: [PATCH] ARM: EXYNOS: cpuidle: Fix build breakage on !SMP
The Exynos cpuidle driver has coupled cpuidle built-in so it cannot be
built without SMP:
arch/arm/mach-exynos/pm.c: In function ‘exynos_cpu0_enter_aftr’:
arch/arm/mach-exynos/pm.c:246:4: error: implicit declaration of function
‘arch_send_wakeup_ipi_mask’ [-Werror=implicit-function-declaration]
arch/arm/mach-exynos/built-in.o: In function `exynos_pre_enter_aftr':
../arch/arm/mach-exynos/pm.c:300: undefined reference to `cpu_boot_reg_base'
arch/arm/mach-exynos/built-in.o: In function `exynos_cpu1_powerdown':
../arch/arm/mach-exynos/pm.c:282: undefined reference to
`exynos_cpu_power_down'
Fix it by adding missing checks for SMP.
Reported-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
arch/arm/mach-exynos/exynos.c|2 +-
arch/arm/mach-exynos/pm.c|2 ++
drivers/cpuidle/cpuidle-exynos.c |3 ++-
3 files changed, 5 insertions(+), 2 deletions(-)
Index: b/arch/arm/mach-exynos/exynos.c
===
--- a/arch/arm/mach-exynos/exynos.c 2015-02-04 18:30:23.555819717 +0100
+++ b/arch/arm/mach-exynos/exynos.c 2015-02-04 18:43:23.539807815 +0100
@@ -211,7 +211,7 @@ static void __init exynos_dt_machine_ini
if (!IS_ENABLED(CONFIG_SMP))
exynos_sysram_init();
-#ifdef CONFIG_ARM_EXYNOS_CPUIDLE
+#if defined(CONFIG_SMP) defined(CONFIG_ARM_EXYNOS_CPUIDLE)
if (of_machine_is_compatible(samsung,exynos4210))
exynos_cpuidle.dev.platform_data = cpuidle_coupled_exynos_data;
#endif
Index: b/arch/arm/mach-exynos/pm.c
===
--- a/arch/arm/mach-exynos/pm.c 2015-02-04 18:30:23.563819719 +0100
+++ b/arch/arm/mach-exynos/pm.c 2015-02-04 18:47:32.951804008 +0100
@@ -181,6 +181,7 @@ void exynos_enter_aftr(void)
cpu_pm_exit();
}
+#if defined(CONFIG_SMP) defined(CONFIG_ARM_EXYNOS_CPUIDLE)
static atomic_t cpu1_wakeup = ATOMIC_INIT(0);
static int exynos_cpu0_enter_aftr(void)
@@ -302,3 +303,4 @@ struct cpuidle_exynos_data cpuidle_coupl
.pre_enter_aftr =
[PATCH v3 1/3] ARM: EXYNOS: Add missing static to file-scope declarations
The 'pm_data', 'exynos_release_ret_regs', 'exynos3250_release_ret_regs'
and 'exynos5420_release_ret_regs' are not exported nor used outside of
suspend.c file. Make them static.
This fixes following sparse warnings:
arch/arm/mach-exynos/suspend.c:83:23: warning: symbol 'pm_data' was not
declared. Should it be static?
arch/arm/mach-exynos/suspend.c:106:14: warning: symbol
'exynos_release_ret_regs' was not declared. Should it be static?
arch/arm/mach-exynos/suspend.c:117:14: warning: symbol
'exynos5420_release_ret_regs' was not declared. Should it be static?
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
Changes since v2:
None
Changes since v1:
1. Add static to 'exynos3250_release_ret_regs' (suggested by Kukjin).
---
arch/arm/mach-exynos/suspend.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index 82e6b6fba23f..77cc39bdad47 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -75,7 +75,7 @@ struct exynos_pm_data {
int (*cpu_suspend)(unsigned long);
};
-struct exynos_pm_data *pm_data;
+static struct exynos_pm_data *pm_data;
static int exynos5420_cpu_state;
static unsigned int exynos_pmu_spare3;
@@ -104,7 +104,7 @@ static const struct exynos_wkup_irq exynos5250_wkup_irq[] =
{
{ /* sentinel */ },
};
-unsigned int exynos_release_ret_regs[] = {
+static unsigned int exynos_release_ret_regs[] = {
S5P_PAD_RET_MAUDIO_OPTION,
S5P_PAD_RET_GPIO_OPTION,
S5P_PAD_RET_UART_OPTION,
@@ -115,7 +115,7 @@ unsigned int exynos_release_ret_regs[] = {
REG_TABLE_END,
};
-unsigned int exynos3250_release_ret_regs[] = {
+static unsigned int exynos3250_release_ret_regs[] = {
S5P_PAD_RET_MAUDIO_OPTION,
S5P_PAD_RET_GPIO_OPTION,
S5P_PAD_RET_UART_OPTION,
@@ -128,7 +128,7 @@ unsigned int exynos3250_release_ret_regs[] = {
REG_TABLE_END,
};
-unsigned int exynos5420_release_ret_regs[] = {
+static unsigned int exynos5420_release_ret_regs[] = {
EXYNOS_PAD_RET_DRAM_OPTION,
EXYNOS_PAD_RET_MAUDIO_OPTION,
EXYNOS_PAD_RET_JTAG_OPTION,
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/3] ARM: EXYNOS: Constify exynos_pm_data and of_device_id array
The 'exynos5420_pm_data' and of_device_id array are not modified and can
be made const.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Reviewed-by: Pankaj Dubey pankaj.du...@samsung.com
---
Changes since v2:
1. Add Pankaj's reviewed-by.
Changes since v1:
1. New patch.
---
arch/arm/mach-exynos/suspend.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index 77cc39bdad47..e6c961126087 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -572,7 +572,7 @@ static const struct exynos_pm_data exynos5250_pm_data = {
.cpu_suspend= exynos_cpu_suspend,
};
-static struct exynos_pm_data exynos5420_pm_data = {
+static const struct exynos_pm_data exynos5420_pm_data = {
.wkup_irq = exynos5250_wkup_irq,
.wake_disable_mask = (0x7F 7) | (0x1F 1),
.release_ret_regs = exynos5420_release_ret_regs,
@@ -583,7 +583,7 @@ static struct exynos_pm_data exynos5420_pm_data = {
.cpu_suspend= exynos5420_cpu_suspend,
};
-static struct of_device_id exynos_pmu_of_device_ids[] = {
+static const struct of_device_id exynos_pmu_of_device_ids[] = {
{
.compatible = samsung,exynos3250-pmu,
.data = exynos3250_pm_data,
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/3] ARM: EXYNOS: Remove left over 'extra_save'
Since 32b0aa9aaeb4 (ARM: EXYNOS: Remove i2c sys configuration related
code) the Exynos 5250 no longer saves additional registers under
'exynos_pm_data.extra_save' field.
No one else uses this code so get rid of it making also 'exynos_pm_data'
const everywhere.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
Changes since v2:
2. Remove also 'num_extra_save' field (suggested by Pankaj Dubey).
Changes since v1:
1. New patch.
---
arch/arm/mach-exynos/suspend.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index e6c961126087..71e2ba6dbc3d 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -63,8 +63,6 @@ static struct sleep_save exynos_core_save[] = {
struct exynos_pm_data {
const struct exynos_wkup_irq *wkup_irq;
- struct sleep_save *extra_save;
- int num_extra_save;
unsigned int wake_disable_mask;
unsigned int *release_ret_regs;
@@ -75,7 +73,7 @@ struct exynos_pm_data {
int (*cpu_suspend)(unsigned long);
};
-static struct exynos_pm_data *pm_data;
+static const struct exynos_pm_data *pm_data;
static int exynos5420_cpu_state;
static unsigned int exynos_pmu_spare3;
@@ -240,10 +238,6 @@ static void exynos_pm_prepare(void)
s3c_pm_do_save(exynos_core_save, ARRAY_SIZE(exynos_core_save));
-if (pm_data-extra_save)
- s3c_pm_do_save(pm_data-extra_save,
- pm_data-num_extra_save);
-
exynos_pm_enter_sleep_mode();
/* ensure at least INFORM0 has the resume address */
@@ -362,10 +356,6 @@ static void exynos_pm_resume(void)
/* For release retention */
exynos_pm_release_retention();
- if (pm_data-extra_save)
- s3c_pm_do_restore_core(pm_data-extra_save,
- pm_data-num_extra_save);
-
s3c_pm_do_restore_core(exynos_core_save, ARRAY_SIZE(exynos_core_save));
if (cpuid == ARM_CPU_PART_CORTEX_A9)
@@ -618,7 +608,7 @@ void __init exynos_pm_init(void)
pr_err(Failed to find PMU node\n);
return;
}
- pm_data = (struct exynos_pm_data *) match-data;
+ pm_data = (const struct exynos_pm_data *) match-data;
/* Platform-specific GIC callback */
gic_arch_extn.irq_set_wake = exynos_irq_set_wake;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2,3/3] ARM: EXYNOS: Remove left over 'extra_save'
On czw, 2015-02-05 at 10:19 +0530, Pankaj Dubey wrote:
Hi Krzysztof,
On Tuesday 03 February 2015 04:36 PM, Krzysztof Kozlowski wrote:
Since 32b0aa9aaeb4 (ARM: EXYNOS: Remove i2c sys configuration related
code) the Exynos 5250 no longer saves additional registers under
'exynos_pm_data.extra_save' field.
No one else uses this code so get rid of it making also 'exynos_pm_data'
const everywhere.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
Changes since v1:
1. New patch.
---
arch/arm/mach-exynos/suspend.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index e6c961126087..d56bd6ca5e86 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -63,7 +63,6 @@ static struct sleep_save exynos_core_save[] = {
struct exynos_pm_data {
const struct exynos_wkup_irq *wkup_irq;
- struct sleep_save *extra_save;
int num_extra_save;
'num_extra_save' can be removed at the same time.
Rest changes looks ok.
Right, thanks for pointing this out. I'll resend the patchset.
Best regards,
Krzysztof
Thanks,
Pankaj Dubey
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v3,1/9] clk: samsung: exynos5433: Add clocks for CMU_APOLLO domain
Hi Chanwoo,
On Tuesday 03 February 2015 05:43 AM, Chanwoo Choi wrote:
This patch adds the mux/divider/gate clocks for CMU_APOLLO domain which
generates the clocks for Cortex-A53 Quad-core processsor.
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Tomasz Figa tomasz.f...@gmail.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Inki Dae inki@samsung.com
---
.../devicetree/bindings/clock/exynos5433-clock.txt | 15 ++
drivers/clk/samsung/clk-exynos5433.c | 193 +
include/dt-bindings/clock/exynos5433.h | 37
3 files changed, 245 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
index 9e7ed2d..0a71468 100644
--- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
@@ -32,6 +32,8 @@ Required Properties:
which generates clocks for 3D Graphics Engine IP.
- samsung,exynos5433-cmu-gscl - clock controller compatible for CMU_GSCL
which generates clocks for GSCALER IPs.
+ - samsung,exynos5433-cmu-apollo- clock controller compatible for CMU_APOLLO
+which generates clocks for Cortex-A53 Quad-core processor.
- reg: physical base address of the controller and length of memory mapped
region.
@@ -105,6 +107,10 @@ Required Properties:
- aclk_gscl_111
- aclk_gscl_333
+ Input clocks for apollo clock controller:
+ - oscclk
+ - sclk_bus_pll_apollo
+
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume.
@@ -289,6 +295,15 @@ Example 2: Examples of clock controller nodes are listed
below.
cmu_top CLK_ACLK_GSCL_333;
};
+ cmu_apollo: clock-controller@1190 {
+ compatible = samsung,exynos5433-cmu-apollo;
+ reg = 0x1190 0x1088;
+ #clock-cells = 1;
+
+ clock-names = oscclk, sclk_bus_pll_apollo;
+ clocks = xxti, cmu_mif CLK_SCLK_BUS_PLL_APOLLO;
+ };
+
Example 3: UART controller node that consumes the clock generated by the clock
controller.
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index 8ae9c48..9a5d33c 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -3393,3 +3393,196 @@ static void __init exynos5433_cmu_gscl_init(struct
device_node *np)
}
CLK_OF_DECLARE(exynos5433_cmu_gscl, samsung,exynos5433-cmu-gscl,
exynos5433_cmu_gscl_init);
+
+/*
+ * Register offset definitions for CMU_APOLLO
+ */
+#define APOLLO_PLL_LOCK0x
+#define APOLLO_PLL_CON00x0100
+#define APOLLO_PLL_CON10x0104
+#define APOLLO_PLL_FREQ_DET0x010c
+#define MUX_SEL_APOLLO00x0200
+#define MUX_SEL_APOLLO10x0204
+#define MUX_SEL_APOLLO20x0208
+#define MUX_ENABLE_APOLLO0 0x0300
+#define MUX_ENABLE_APOLLO1 0x0304
+#define MUX_ENABLE_APOLLO2 0x0308
+#define MUX_STAT_APOLLO0 0x0400
+#define MUX_STAT_APOLLO1 0x0404
+#define MUX_STAT_APOLLO2 0x0408
+#define DIV_APOLLO00x0600
+#define DIV_APOLLO10x0604
+#define DIV_APOLLO_PLL_FREQ_DET0x0608
+#define DIV_STAT_APOLLO0 0x0700
+#define DIV_STAT_APOLLO1 0x0704
+#define DIV_STAT_APOLLO_PLL_FREQ_DET 0x0708
+#define ENABLE_ACLK_APOLLO 0x0800
+#define ENABLE_PCLK_APOLLO 0x0900
+#define ENABLE_SCLK_APOLLO 0x0a00
+#define ENABLE_IP_APOLLO0 0x0b00
+#define ENABLE_IP_APOLLO1 0x0b04
+#define CLKOUT_CMU_APOLLO 0x0c00
+#define CLKOUT_CMU_APOLLO_DIV_STAT 0x0c04
+#define ARMCLK_STOPCTRL0x1000
+#define APOLLO_PWR_CTRL0x1020
+#define APOLLO_PWR_CTRL2 0x1024
+#define APOLLO_INTR_SPREAD_ENABLE 0x1080
+#define APOLLO_INTR_SPREAD_USE_STANDBYWFI 0x1084
+#define APOLLO_INTR_SPREAD_BLOCKING_DURATION 0x1088
+
+static unsigned long apollo_clk_regs[] __initdata = {
+ APOLLO_PLL_LOCK,
+ APOLLO_PLL_CON0,
+ APOLLO_PLL_CON1,
+ APOLLO_PLL_FREQ_DET,
+ MUX_SEL_APOLLO0,
+ MUX_SEL_APOLLO1,
+ MUX_SEL_APOLLO2,
+ MUX_ENABLE_APOLLO0,
+ MUX_ENABLE_APOLLO1,
+ MUX_ENABLE_APOLLO2,
+ MUX_STAT_APOLLO0,
+ MUX_STAT_APOLLO1,
+
Re: [PATCH v2 2/2] arm/dma-mapping: Respect NO_KERNEL_MAPPING when we don't have an IOMMU
Hello,
On 2015-02-04 10:23, Carlo Caione wrote:
From: Jasper St. Pierre jstpie...@mecheye.net
Even without an iommu, NO_KERNEL_MAPPING is still convenient to save on
kernel address space in places where we don't need a kernel mapping.
Implement support for it in the two places where we're creating an
expensive mapping.
__alloc_from_pool uses an internal pool from which we already have
virtual addresses, so it's not relevant, and __alloc_simple_buffer uses
alloc_pages, which will always return a lowmem page, which is already
mapped into kernel space, so we can't prevent a mapping for it in that
case.
Signed-off-by: Jasper St. Pierre jstpie...@mecheye.net
Signed-off-by: Carlo Caione ca...@caione.org
Reviewed-by: Rob Clark robdcl...@gmail.com
Reviewed-by: Daniel Drake d...@endlessm.com
Acked-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/mm/dma-mapping.c | 67 +--
1 file changed, 41 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index a673c7f..d767bba 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -289,11 +289,11 @@ static void __dma_free_buffer(struct page *page, size_t
size)
static void *__alloc_from_contiguous(struct device *dev, size_t size,
pgprot_t prot, struct page **ret_page,
-const void *caller);
+const void *caller, bool want_vaddr);
static void *__alloc_remap_buffer(struct device *dev, size_t size, gfp_t gfp,
pgprot_t prot, struct page **ret_page,
-const void *caller);
+const void *caller, bool want_vaddr);
static void *
__dma_alloc_remap(struct page *page, size_t size, gfp_t gfp, pgprot_t prot,
@@ -357,10 +357,10 @@ static int __init atomic_pool_init(void)
if (dev_get_cma_area(NULL))
ptr = __alloc_from_contiguous(NULL, atomic_pool_size, prot,
- page, atomic_pool_init);
+ page, atomic_pool_init, true);
else
ptr = __alloc_remap_buffer(NULL, atomic_pool_size, gfp, prot,
- page, atomic_pool_init);
+ page, atomic_pool_init, true);
if (ptr) {
int ret;
@@ -467,13 +467,15 @@ static void __dma_remap(struct page *page, size_t size, pgprot_t prot)
static void *__alloc_remap_buffer(struct device *dev, size_t size, gfp_t gfp,
pgprot_t prot, struct page **ret_page,
-const void *caller)
+const void *caller, bool want_vaddr)
{
struct page *page;
- void *ptr;
+ void *ptr = NULL;
page = __dma_alloc_buffer(dev, size, gfp);
if (!page)
return NULL;
+ if (!want_vaddr)
+ goto out;
ptr = __dma_alloc_remap(page, size, gfp, prot, caller);
if (!ptr) {
@@ -481,6 +483,7 @@ static void *__alloc_remap_buffer(struct device *dev,
size_t size, gfp_t gfp,
return NULL;
}
+ out:
*ret_page = page;
return ptr;
}
@@ -523,12 +526,12 @@ static int __free_from_pool(void *start, size_t size)
static void *__alloc_from_contiguous(struct device *dev, size_t size,
pgprot_t prot, struct page **ret_page,
-const void *caller)
+const void *caller, bool want_vaddr)
{
unsigned long order = get_order(size);
size_t count = size PAGE_SHIFT;
struct page *page;
- void *ptr;
+ void *ptr = NULL;
page = dma_alloc_from_contiguous(dev, count, order);
if (!page)
@@ -536,6 +539,9 @@ static void *__alloc_from_contiguous(struct device *dev,
size_t size,
__dma_clear_buffer(page, size);
+ if (!want_vaddr)
+ goto out;
+
if (PageHighMem(page)) {
ptr = __dma_alloc_remap(page, size, GFP_KERNEL, prot, caller);
if (!ptr) {
@@ -546,17 +552,21 @@ static void *__alloc_from_contiguous(struct device *dev,
size_t size,
__dma_remap(page, size, prot);
ptr = page_address(page);
}
+
+ out:
*ret_page = page;
return ptr;
}
static void __free_from_contiguous(struct device *dev, struct page *page,
- void *cpu_addr, size_t size)
+ void *cpu_addr, size_t size, bool want_vaddr)
{
- if (PageHighMem(page))
- __dma_free_remap(cpu_addr, size);
- else
- __dma_remap(page, size, PAGE_KERNEL);
+ if (want_vaddr) {
+ if
Re: [PATCH v2 1/2] drm/exynos: fix DMA_ATTR_NO_KERNEL_MAPPING usage
Hello,
On 2015-02-04 10:23, Carlo Caione wrote:
The Exynos DRM driver doesn't follow the correct API when dealing with
dma_{alloc, mmap, free}_attrs functions and the
DMA_ATTR_NO_KERNEL_MAPPING attribute.
When a IOMMU is not available and the DMA_ATTR_NO_KERNEL_MAPPING is
used, the driver should use the pointer returned by dma_alloc_attr() as
a cookie.
The Exynos DRM driver directly uses the non-requested virtual kernel
address returned by the DMA mapping subsystem. This just works now
because the non-IOMMU codepath doesn't obey DMA_ATTR_NO_KERNEL_MAPPING
but we need to fix it before fixing the DMA layer.
Signed-off-by: Carlo Caione ca...@caione.org
Acked-by: Joonyoung Shim jy0922.s...@samsung.com
Acked-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_buf.c | 6 +++---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 29 +
drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 ++
3 files changed, 14 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 9c80884..24994ba 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -63,11 +63,11 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
return -ENOMEM;
}
- buf-kvaddr = (void __iomem *)dma_alloc_attrs(dev-dev,
+ buf-cookie = dma_alloc_attrs(dev-dev,
buf-size,
buf-dma_addr, GFP_KERNEL,
buf-dma_attrs);
- if (!buf-kvaddr) {
+ if (!buf-cookie) {
DRM_ERROR(failed to allocate buffer.\n);
ret = -ENOMEM;
goto err_free;
@@ -132,7 +132,7 @@ static void lowlevel_buffer_deallocate(struct drm_device
*dev,
buf-sgt = NULL;
if (!is_drm_iommu_supported(dev)) {
- dma_free_attrs(dev-dev, buf-size, buf-kvaddr,
+ dma_free_attrs(dev-dev, buf-size, buf-cookie,
(dma_addr_t)buf-dma_addr, buf-dma_attrs);
drm_free_large(buf-pages);
} else
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index e12ea90..84f8dfe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -79,9 +79,9 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper
*helper,
struct drm_framebuffer *fb)
{
struct fb_info *fbi = helper-fbdev;
- struct drm_device *dev = helper-dev;
struct exynos_drm_gem_buf *buffer;
unsigned int size = fb-width * fb-height * (fb-bits_per_pixel 3);
+ unsigned int nr_pages;
unsigned long offset;
drm_fb_helper_fill_fix(fbi, fb-pitches[0], fb-depth);
@@ -94,25 +94,14 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper
*helper,
return -EFAULT;
}
- /* map pages with kernel virtual space. */
+ nr_pages = buffer-size PAGE_SHIFT;
+
+ buffer-kvaddr = (void __iomem *) vmap(buffer-pages,
+ nr_pages, VM_MAP,
+ pgprot_writecombine(PAGE_KERNEL));
if (!buffer-kvaddr) {
- if (is_drm_iommu_supported(dev)) {
- unsigned int nr_pages = buffer-size PAGE_SHIFT;
-
- buffer-kvaddr = (void __iomem *) vmap(buffer-pages,
- nr_pages, VM_MAP,
- pgprot_writecombine(PAGE_KERNEL));
- } else {
- phys_addr_t dma_addr = buffer-dma_addr;
- if (dma_addr)
- buffer-kvaddr = (void __iomem
*)phys_to_virt(dma_addr);
- else
- buffer-kvaddr = (void __iomem *)NULL;
- }
- if (!buffer-kvaddr) {
- DRM_ERROR(failed to map pages to kernel space.\n);
- return -EIO;
- }
+ DRM_ERROR(failed to map pages to kernel space.\n);
+ return -EIO;
}
/* buffer count to framebuffer always is 1 at booting time. */
@@ -313,7 +302,7 @@ static void exynos_drm_fbdev_destroy(struct drm_device *dev,
struct exynos_drm_gem_obj *exynos_gem_obj = exynos_fbd-exynos_gem_obj;
struct drm_framebuffer *fb;
- if (is_drm_iommu_supported(dev) exynos_gem_obj-buffer-kvaddr)
+ if (exynos_gem_obj-buffer-kvaddr)
vunmap(exynos_gem_obj-buffer-kvaddr);
/* release drm framebuffer and real buffer */
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index ec58fe9..308173c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
Re: [PATCH 1/2] thermal: exynos: Reorder exynos_map_dt_data() function
Hi Lukasz,
On Wed, Feb 4, 2015 at 4:06 PM, Lukasz Majewski l.majew...@samsung.com wrote:
Hi Abhilash,
Hi Lukasz,
On Fri, Jan 30, 2015 at 8:36 PM, Abhilash Kesavan
kesavan.abhil...@gmail.com wrote:
Hi Lukasz,
On Fri, Jan 30, 2015 at 1:44 PM, Lukasz Majewski
l.majew...@samsung.com wrote:
Hi Eduardo, Abhilash,
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
l.majew...@samsung.com wrote:
Hi Abhilash,
Hi Lukasz,
On Mon, Jan 19, 2015 at 5:14 PM, Lukasz Majewski
l.majew...@samsung.com wrote:
The exynos_map_dt_data() function must be called before
thermal_zone_of_sensor_register(), and hence provide
tmu_read() function, before it is needed.
This change is driven by adding support for enabling
thermal_zoneX when it is properly initialized.
One can read the mode of operation
at /sys/class/thermal/thermal_zone0/mode Such
functionality was missing in the of-thermal.c code.
Reported-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c index
9d2d685..5d946ab 100644 ---
a/drivers/thermal/samsung/exynos_tmu.c +++
b/drivers/thermal/samsung/exynos_tmu.c @@ -975,15 +975,16
@@ static int exynos_tmu_probe(struct platform_device
*pdev) platform_set_drvdata(pdev, data);
mutex_init(data-lock);
+ ret = exynos_map_dt_data(pdev);
+ if (ret)
+ goto err_sensor;
+
data-tzd =
thermal_zone_of_sensor_register(pdev-dev, 0, data,
exynos_sensor_ops); if (IS_ERR(data-tzd)) {
pr_err(thermal: tz: %p ERROR\n,
data-tzd); return PTR_ERR(data-tzd);
}
- ret = exynos_map_dt_data(pdev);
- if (ret)
- goto err_sensor;
pdata = data-pdata;
I have been testing this along with your v5 patch set and am
seeing incorrect temperature being reported at boot-up on
exynos7.
Does it show a maximal temperature value (0x1FF)?
I did not print the current temperature register, but I
remember the message showing ~105C. Will give you the register
value when I test with more debug prints tomorrow.
It looks
like exynos_tmu_read gets called from
thermal_zone_of_device_update during boot-up, now that we
have it populated early. However, as the tmu initialization
function has not been called yet it returns a wrong value.
Does that sound correct ?
No, this is a mistake. However, I'm wondering why on Exynos4/5
this error didn't show up...
I have been lowering the software trip point temperature in the
exynos7 dts file (to 55C) for testing purposes. Hence, when the
temperature is read incorrectly as ~105C the board trips at
boot-up
this is a very unusual
value - I had problems with
reading 0xFF values with
similar symptom (but this
was caused by lack of vtmu).
itself. Maybe for exynos4/5 the incorrect value read during
boot-up is in the non-tripping range and once the tmu is
initialized later it continues to function properly thereafter ?
The reordering is needed to be able to call set_mode callback
at of-thermal.c to set the mode.
If this change causes problems, then another solution
(probably not so neat) must be found.
Please let me know if you need any further details.
Abhilash, could you provide more details (like relevant output from
dmesg) and point me a list of patches which shall I apply to test
this issue on Exynos4/5?
Sorry, I have not had the time to re-check this and provide you with
the current temperature register value. I will definitely do so on
Monday and also provide you the dmesg output. I applied the
following patches on linux-next:
bbf872d thermal: exynos: Add TMU support for Exynos7 SoC
b8190ac dts: Documentation: Add documentation for Exynos7 SoC
thermal bindings 9330ec1 thermal: exynos: Reorder
exynos_map_dt_data() function 4dd41c4 thermal: exynos: dts: Provide
device tree bindings identical to the one in exynos_tmu_data.c
a7b80b9 thermal: dts: exynos: Trip points and sensor configuration
data for Exynos5440
77d072e thermal: exynos: dts: Define default thermal-zones for
Exynos4 964dd36 thermal: dts: Default trip points definition for
Exynos5420 SoCs c1d2f97 thermal: exynos: dts: Add default
definition of the TMU sensor parameter 02a4496 arm: dts:
[PATCH] ARM: EXYNOS: cpuidle: Fix build breakage on !SMP
The Exynos cpuidle driver has coupled cpuidle built-in so it cannot be
built without SMP:
arch/arm/mach-exynos/pm.c: In function ‘exynos_cpu0_enter_aftr’:
arch/arm/mach-exynos/pm.c:246:4: error: implicit declaration of function
‘arch_send_wakeup_ipi_mask’ [-Werror=implicit-function-declaration]
arch/arm/mach-exynos/built-in.o: In function `exynos_pre_enter_aftr':
../arch/arm/mach-exynos/pm.c:300: undefined reference to `cpu_boot_reg_base'
arch/arm/mach-exynos/built-in.o: In function `exynos_cpu1_powerdown':
../arch/arm/mach-exynos/pm.c:282: undefined reference to `exynos_cpu_power_down'
Make the cpuidle driver depending on SMP because this will be the
fastest way to fix build break without adding a bunch of ifdefs in few
places.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
arch/arm/mach-exynos/pm.c | 2 ++
drivers/cpuidle/Kconfig.arm | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index e6209dadc00d..17db00ff7f3a 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -181,6 +181,7 @@ void exynos_enter_aftr(void)
cpu_pm_exit();
}
+#ifdef CONFIG_ARM_EXYNOS_CPUIDLE
static atomic_t cpu1_wakeup = ATOMIC_INIT(0);
static int exynos_cpu0_enter_aftr(void)
@@ -302,3 +303,4 @@ struct cpuidle_exynos_data cpuidle_coupled_exynos_data = {
.pre_enter_aftr = exynos_pre_enter_aftr,
.post_enter_aftr= exynos_post_enter_aftr,
};
+#endif /* CONFIG_ARM_EXYNOS_CPUIDLE */
diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
index 8e07c9419153..5eb86a4f74d9 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -55,7 +55,8 @@ config ARM_AT91_CPUIDLE
config ARM_EXYNOS_CPUIDLE
bool Cpu Idle Driver for the Exynos processors
depends on ARCH_EXYNOS
- select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
+ depends on SMP
+ select ARCH_NEEDS_CPU_IDLE_COUPLED
help
Select this to enable cpuidle for Exynos processors
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 10/13] clk: samsung: exynos5433: Add clocks for CMU_BUS{0|1|2} domains
Hi Chanwoo,
On 02/02/15 15:24, Chanwoo Choi wrote:
This patch adds the mux/divider/gate clocks for CMU_BUS{0|1|2} domains
which contain global data buses clocked at up the 400MHz. These blocks
transfer data between DRAM and various sub-blocks. These clock domains
also contain global peripheral buses clocked at 67/111/200/222/266/333/400
MHz and used for register accesses.
+/*
+ * Register offset definitions for CMU_BUS{0|1|2}
+ */
+#define DIV_BUS 0x0600
+#define DIV_STAT_BUS 0x0700
+#define ENABLE_ACLK_BUS 0x0800
+#define ENABLE_PCLK_BUS 0x0900
+#define ENABLE_IP_BUS0 0x0b00
+#define ENABLE_IP_BUS1 0x0b04
+
+#define MUX_SEL_BUS2 0x0200 /* Only for CMU_BUS2 */
+#define MUX_ENABLE_BUS2 0x0300 /* Only for CMU_BUS2 */
+#define MUX_STAT_BUS20x0400 /* Only for CMU_BUS2 */
+
+/* list of all parent clock list */
+PNAME(mout_aclk_bus2_400_p) = { oscclk, aclk_bus2_400, };
+
+#define CMU_BUS_COMMON_CLK_REGS \
+ DIV_BUS,\
+ DIV_STAT_BUS, \
+ ENABLE_ACLK_BUS,\
+ ENABLE_PCLK_BUS,\
+ ENABLE_IP_BUS0, \
+ ENABLE_IP_BUS1
+
+static unsigned long bus01_clk_regs[] __initdata = {
+ CMU_BUS_COMMON_CLK_REGS,
+};
+
+static unsigned long bus2_clk_regs[] __initdata = {
+ MUX_SEL_BUS2,
+ MUX_ENABLE_BUS2,
+ MUX_STAT_BUS2,
+ CMU_BUS_COMMON_CLK_REGS,
+};
+
+static struct samsung_div_clock bus0_div_clks[] __initdata = {
+ /* DIV_BUS0 */
+ DIV(CLK_DIV_PCLK_BUS_133, div_pclk_bus0_133, aclk_bus0_400,
+ DIV_BUS, 0, 3),
+};
+
+/* CMU_BUS0 clocks */
+static struct samsung_gate_clock bus0_gate_clks[] __initdata = {
+ /* ENABLE_ACLK_BUS0 */
+ GATE(CLK_ACLK_AHB2APB_BUSP, aclk_ahb2apb_bus0p, div_pclk_bus0_133,
+ ENABLE_ACLK_BUS, 4, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_BUSNP_133, aclk_bus0np_133, div_pclk_bus0_133,
+ ENABLE_ACLK_BUS, 2, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_BUSND_400, aclk_bus0nd_400, aclk_bus0_400,
+ ENABLE_ACLK_BUS, 0, CLK_IGNORE_UNUSED, 0),
+
+ /* ENABLE_PCLK_BUS0 */
+ GATE(CLK_PCLK_BUSSRVND_133, pclk_bus0srvnd_133, div_pclk_bus0_133,
+ ENABLE_PCLK_BUS, 2, 0, 0),
+ GATE(CLK_PCLK_PMU_BUS, pclk_pmu_bus0, div_pclk_bus0_133,
+ ENABLE_PCLK_BUS, 1, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_PCLK_SYSREG_BUS, pclk_sysreg_bus0, div_pclk_bus0_133,
+ ENABLE_PCLK_BUS, 0, CLK_IGNORE_UNUSED, 0),
+};
+
+/* CMU_BUS1 clocks */
+static struct samsung_div_clock bus1_div_clks[] __initdata = {
+ /* DIV_BUS1 */
+ DIV(CLK_DIV_PCLK_BUS_133, div_pclk_bus1_133, aclk_bus1_400,
+ DIV_BUS, 0, 3),
+};
+
+static struct samsung_gate_clock bus1_gate_clks[] __initdata = {
+ /* ENABLE_ACLK_BUS1 */
+ GATE(CLK_ACLK_AHB2APB_BUSP, aclk_ahb2apb_bus1p, div_pclk_bus1_133,
+ ENABLE_ACLK_BUS, 4, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_BUSNP_133, aclk_bus1np_133, div_pclk_bus1_133,
+ ENABLE_ACLK_BUS, 2, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_BUSND_400, aclk_bus1nd_400, aclk_bus1_400,
+ ENABLE_ACLK_BUS, 0, CLK_IGNORE_UNUSED, 0),
+
+ /* ENABLE_PCLK_BUS1 */
+ GATE(CLK_PCLK_BUSSRVND_133, pclk_bus1srvnd_133, div_pclk_bus1_133,
+ ENABLE_PCLK_BUS, 2, 0, 0),
+ GATE(CLK_PCLK_PMU_BUS, pclk_pmu_bus1, div_pclk_bus1_133,
+ ENABLE_PCLK_BUS, 1, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_PCLK_SYSREG_BUS, pclk_sysreg_bus1, div_pclk_bus1_133,
+ ENABLE_PCLK_BUS, 0, CLK_IGNORE_UNUSED, 0),
+};
+
+/* CMU_BUS2 clocks */
+static struct samsung_mux_clock bus2_mux_clks[] __initdata = {
+ /* MUX_SEL_BUS2 */
+ MUX(CLK_MOUT_ACLK_BUS2_400_USER, mout_aclk_bus2_400_user,
+ mout_aclk_bus2_400_p, MUX_SEL_BUS2, 0, 1),
+};
+
+static struct samsung_div_clock bus2_div_clks[] __initdata = {
+ /* DIV_BUS2 */
+ DIV(CLK_DIV_PCLK_BUS_133, div_pclk_bus2_133,
+ mout_aclk_bus2_400_user, DIV_BUS, 0, 3),
+};
+
+static struct samsung_gate_clock bus2_gate_clks[] __initdata = {
+ /* ENABLE_ACLK_BUS2 */
+ GATE(CLK_ACLK_AHB2APB_BUSP, aclk_ahb2apb_bus2p, div_pclk_bus2_133,
+ ENABLE_ACLK_BUS, 3, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_BUSNP_133, aclk_bus2np_133, div_pclk_bus2_133,
+ ENABLE_ACLK_BUS, 2, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_BUS2BEND_400, aclk_bus2bend_400,
+ mout_aclk_bus2_400_user, ENABLE_ACLK_BUS,
+ 1, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_BUS2RTND_400, aclk_bus2rtnd_400,
+
Re: [PATCH 1/3] exynos: config: Remove CONFIG_EXYNOS_THERMAL_CORE define (exynos_defconfig)
Hi Kukjin, 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 l.majew...@samsung.com I dont see problems with this patch: Acked-by: Eduardo Valentin edubez...@gmail.com This should go, obviously, via the correct platform tree. Could you apply this patch to -samsung tree? --- arch/arm/configs/exynos_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 3d0c5d6..3691a68 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -88,7 +88,6 @@ CONFIG_HWMON=y CONFIG_SENSORS_LM90=y CONFIG_THERMAL=y CONFIG_EXYNOS_THERMAL=y -CONFIG_EXYNOS_THERMAL_CORE=y CONFIG_WATCHDOG=y CONFIG_S3C2410_WATCHDOG=y CONFIG_MFD_CROS_EC=y -- 2.0.0.rc2 -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 00/18] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hello, On 2015-02-04 10:53, Hongbo Zhang wrote: This is patch set against v3.19-rc4 plus 'Add HDMI support for Exynos5420 platform', right? No other dependencies? If there is, do you have a public git tree to be cloned? I've just prepared public branch based on v3.19-rc7 with kgene/v3.20-next/dt-samsung-3 branch merged and exynos-hdmi patches applied. It is available here: http://git.linaro.org/git-ro/people/marek.szyprowski/linux-srpol.git v3.19-hdmi-iommu Tested with Exynos5422-based Odroid XU3 and Exynos4412-based Odroid U3. Best regards -- Marek Szyprowski, PhD Samsung RD Institute Poland -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3] drm/exynos: Add DECON driver
Hi Inki,
On Mon, Dec 8, 2014 at 7:09 PM, Inki Dae inki@samsung.com wrote:
On 2014년 12월 07일 21:04, Ajay Kumar wrote:
This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
DECON(Display and Enhancement Controller) is the new IP
in exynos7 SOC for generating video signals using pixel data.
DECON driver can be used to drive 2 different interfaces on Exynos7:
DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
The existing FIMD driver code was used as a template to create
DECON driver. Only DECON-INT is supported as of now, and
DECON-EXT support will be added later.
Signed-off-by: Akshu Agrawal aks...@gmail.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
Changes since V1:
-- Address comments from Pankaj and do few cleanups.
Changes since V2:
-- Address more comments from Pankaj and cleanup.
.../devicetree/bindings/video/exynos7-decon.txt| 67 ++
drivers/gpu/drm/exynos/Kconfig | 13 +-
drivers/gpu/drm/exynos/Makefile|1 +
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 1042
drivers/gpu/drm/exynos/exynos_drm_drv.c|4 +
drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
include/video/exynos7_decon.h | 346 +++
7 files changed, 1471 insertions(+), 3 deletions(-)
create mode 100644
Documentation/devicetree/bindings/video/exynos7-decon.txt
create mode 100644 drivers/gpu/drm/exynos/exynos7_drm_decon.c
create mode 100644 include/video/exynos7_decon.h
diff --git a/Documentation/devicetree/bindings/video/exynos7-decon.txt
b/Documentation/devicetree/bindings/video/exynos7-decon.txt
new file mode 100644
index 000..14db519
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos7-decon.txt
@@ -0,0 +1,67 @@
+Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
+
+DECON (Display and Enhancement Controller) is the Display Controller
for the
+Exynos7 series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be samsung,exynos7-decon;
+
+- reg: physical base address and length of the DECON registers set.
+
+- interrupt-parent: should be the phandle of the decon controller's
+ parent interrupt controller.
+
+- interrupts: should contain a list of all DECON IP block interrupts
in the
+ order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
+ format depends on the interrupt controller used.
+
+- interrupt-names: should contain the interrupt names: fifo, vsync,
+ lcd_sys, in the same order as they were listed in the interrupts
+property.
+
+- pinctrl-0: pin control group to be used for this controller.
+
+- pinctrl-names: must contain a default entry.
+
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+
+- clock-names: list of clock names sorted in the same order as the clocks
+ property. Must contain pclk_decon0, aclk_decon0,
+decon0_eclk, decon0_vclk.
Should the DECON driver really care about decon0_eclk and decon0_vclk?
If so then What is the purpose of these special clocks? I'm not sure
that these clocks should be cared by driver. Until now, Exynos driver
has cared about only video source and core source clocks.
Can you give me more details about the use of the special clocks?
All these 4 clocks are definitely needed for the DECON to function properly.
pclk_decon0 and aclk_decon0 are clocks needed for normal
operation of DECON.
decon0_eclk and decon0_vclk are like pixel clocks.
The clock diagram is present in the Exynos7 user manual in clock
generation chapter.
+
+Optional Properties:
+- samsung,power-domain: a phandle to DECON power domain node.
+- display-timings: timing settings for FIMD, as described in document
[1].
+ Can be used in case timings cannot be provided otherwise
+ or to override timings provided by the panel.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+
+Example:
+
+SoC specific DT entry:
+
+ decon@1393 {
+ compatible = samsung,exynos7-decon;
+ interrupt-parent = combiner;
+ reg = 0x1393 0x1000;
+ interrupt-names = lcd_sys, vsync, fifo;
+ interrupts = 0 188 0, 0 189 0, 0 190 0;
+ clocks = clock_disp PCLK_DECON_INT,
+ clock_disp ACLK_DECON_INT,
+ clock_disp SCLK_DECON_INT_ECLK,
+ clock_disp SCLK_DECON_INT_EXTCLKPLL;
+ clock-names = pclk_decon0, aclk_decon0, decon0_eclk,
+ decon0_vclk;
+ status = disabled;
+ };
+
+Board specific DT entry:
[PATCH v5 RESEND 3/9] ARM: dts: exynos4: add hdmi related nodes
This patch adds entries for HDMI, Mixer and i2c with hdmi-phy modules
found in Exynos 4210 and 4x12 SoCs.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
Resend reason: rebased onto latest kgene/v3.20-next/dt-samsung-4 branch
---
arch/arm/boot/dts/exynos4.dtsi| 40 +++
arch/arm/boot/dts/exynos4210.dtsi | 8
arch/arm/boot/dts/exynos4x12.dtsi | 11 +++
3 files changed, 59 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index d1759bf5202f..c6e72041cc55 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -38,6 +38,7 @@
i2c5 = i2c_5;
i2c6 = i2c_6;
i2c7 = i2c_7;
+ i2c8 = i2c_8;
csis0 = csis_0;
csis1 = csis_1;
fimc0 = fimc_0;
@@ -545,6 +546,22 @@
status = disabled;
};
+ i2c_8: i2c@138E {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = samsung,s3c2440-hdmiphy-i2c;
+ reg = 0x138E 0x100;
+ interrupts = 0 93 0;
+ clocks = clock CLK_I2C_HDMI;
+ clock-names = i2c;
+ status = disabled;
+
+ hdmi_i2c_phy: hdmiphy@38 {
+ compatible = exynos4210-hdmiphy;
+ reg = 0x38;
+ };
+ };
+
spi_0: spi@1392 {
compatible = samsung,exynos4210-spi;
reg = 0x1392 0x100;
@@ -654,6 +671,29 @@
status = disabled;
};
+ hdmi: hdmi@12D0 {
+ compatible = samsung,exynos4210-hdmi;
+ reg = 0x12D0 0x7;
+ interrupts = 0 92 0;
+ clock-names = hdmi, sclk_hdmi, sclk_pixel, sclk_hdmiphy,
+ mout_hdmi;
+ clocks = clock CLK_HDMI, clock CLK_SCLK_HDMI,
+ clock CLK_SCLK_PIXEL, clock CLK_SCLK_HDMIPHY,
+ clock CLK_MOUT_HDMI;
+ phy = hdmi_i2c_phy;
+ power-domains = pd_tv;
+ samsung,syscon-phandle = pmu_system_controller;
+ status = disabled;
+ };
+
+ mixer: mixer@12C1 {
+ compatible = samsung,exynos4210-mixer;
+ interrupts = 0 91 0;
+ reg = 0x12C1 0x2100, 0x12c0 0x300;
+ power-domains = pd_tv;
+ status = disabled;
+ };
+
ppmu_dmc0: ppmu_dmc0@106a {
compatible = samsung,exynos-ppmu;
reg = 0x106a 0x2000;
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 7c15880bc8ba..1ef40f6f6e08 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -194,6 +194,14 @@
};
};
+ mixer: mixer@12C1 {
+ clock-names = mixer, hdmi, sclk_hdmi, vp, mout_mixer,
+ sclk_mixer;
+ clocks = clock CLK_MIXER, clock CLK_HDMI,
+ clock CLK_SCLK_HDMI, clock CLK_VP,
+ clock CLK_MOUT_MIXER, clock CLK_SCLK_MIXER;
+ };
+
ppmu_lcd1: ppmu_lcd1@1224 {
compatible = samsung,exynos-ppmu;
reg = 0x1224 0x2000;
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index af59cab53bd9..2824a5c0e28d 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -283,4 +283,15 @@
clock-names = tmu_apbif;
status = disabled;
};
+
+ hdmi: hdmi@12D0 {
+ compatible = samsung,exynos4212-hdmi;
+ };
+
+ mixer: mixer@12C1 {
+ compatible = samsung,exynos4212-mixer;
+ clock-names = mixer, hdmi, sclk_hdmi, vp;
+ clocks = clock CLK_MIXER, clock CLK_HDMI,
+clock CLK_SCLK_HDMI, clock CLK_VP;
+ };
};
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] exynos: config: Enable thermal emulation for Exynos TMU (exynos_defconfig)
Hi Kukjin, 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 l.majew...@samsung.com I dont see problems with this patch: Acked-by: Eduardo Valentin edubez...@gmail.com Could you apply this patch to -samsung tree? --- arch/arm/configs/exynos_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 3691a68..376dbf4 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -88,6 +88,7 @@ CONFIG_HWMON=y CONFIG_SENSORS_LM90=y CONFIG_THERMAL=y CONFIG_EXYNOS_THERMAL=y +CONFIG_THERMAL_EMULATION=y CONFIG_WATCHDOG=y CONFIG_S3C2410_WATCHDOG=y CONFIG_MFD_CROS_EC=y -- 2.0.0.rc2 -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/14] drm/exynos: Remove exynos_plane_dpms() call with no effect
On Wed, Feb 04, 2015 at 04:42:57PM +0900, Joonyoung Shim wrote: Hi, On 02/04/2015 04:14 AM, Gustavo Padovan wrote: From: Gustavo Padovan gustavo.pado...@collabora.co.uk 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 exynos_plane_dpms() is pointless. Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index b2a4b84..ad675fb 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -65,8 +65,6 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc) if (exynos_crtc-ops-commit) exynos_crtc-ops-commit(exynos_crtc); - - exynos_plane_dpms(crtc-primary, DRM_MODE_DPMS_ON); As i said, this needs to keep pair enabled flag of struct exynos_drm_plane. The reason exynos needs that exynos_plane-enable is because it has its own per-plane dpms state. There's two problems with that: - It's highyl non-standard, the drm kms way is to just disable the plane and not have some additional knob on top. - The atomic helpers will not be able to handle this. They assume that there's only one dpms knob for the entire display pipeline, and per-plane enable/disable is handled by setting plane-state-crtc, which must be set iff plane-state-fb is set right now. I recommend we rip this all out if we can adjust existing userspace to stop using the mode property on planes and crtcs. And with that non-standard exynos plane mode thing gone we can indeed rip out exynos_plane_dpms and exynos_plane-enabled and just directly call manager-ops-win_enable/disble. And then rip out the win_enable since it's unused. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] PM / Domains: Re-structure code for adding/removing devices to genpd
On Tuesday, January 27, 2015 09:13:37 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_genpd_remove_device() deserved some attention. Patch 1 - 4, can be considered as more simple cleanups and should not impact the behavior for current clients using the APIs. Patch 5, eliminates a mutex for generic_pm_domain_data by re-order the initialization/cleanup of dev_pm_qos notifiers. Patch 6, move some code around to fix a potenial memory leakage of a struct pm_subsys_data. Patch 7, code restructuring which impacts locking behavior while adding/removing devices. Should improve code readability and decrease critical regions of holding locks. Patch 8, Adds error handling of genpd's -attach_dev() callback Ulf Hansson (8): PM / Domains: Rename __pm_genpd_alloc|free_dev_data() PM / Domains: Remove reference counting for the generic_pm_domain_data PM / Domains: Don't allow an existing generic_pm_domain_data PM / Domains: Don't check for an existing device when adding a new PM / Domains: Eliminate the mutex for the generic_pm_domain_data PM / Domains: Free pm_subsys_data in error path in __pm_genpd_add_device() PM / Domains: Re-order initialization of generic_pm_domain_data PM / Domains: Handle errors from genpd's -attach_dev() callback drivers/base/power/domain.c | 137 +--- include/linux/pm_domain.h | 2 - 2 files changed, 65 insertions(+), 74 deletions(-) Whole series queued up for 3.20, thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 00/18] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hi Marek, On Fri, Jan 23, 2015 at 04:51:10PM +0100, Marek Szyprowski wrote: 1. All iommu related patches (with 'iommu: exynos') can be merged to iommu tree. They don't have any direct dependencies on the DTS, DRM and power domain initialization change - without them the driver will simply not initialize, when no exynos,sysmmu nodes are provided in device tree. Joerg, could you merge those patches? Given the previous comments and tests on this patch set I am still waiting for some Acked-bys and/or Tested-bys on this. Can you collect these and resend then (probably after the v3.20 merge window)? Joerg -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] Add multiple GPIO and external clock to MMC pwrseq_simple
Hello Kukjin, On 01/30/2015 02:06 PM, Javier Martinez Canillas wrote: On 01/30/2015 12:13 PM, Ulf Hansson wrote: Patch #1 extends the simple MMC power sequence DT binding to support more than one GPIO and patch #2 adds the actual implementation. In the same way, patch #3 and #4 extend the simple MMC power sequence DT binding and pwrseq_simple driver to support an optional external clock. Finally as an example, patch #5 and patch #6 adds support for the wifi chip in the Exynos5250 Snow that needs all these resources. These two patches were added to the series only for completeness and should be picked by Kukjin through his linux-samsung tree. Best regards, Javier Thanks Javier! I have applied patch 1 - 4 for my next branch. I made some minor fix to patch4, I send a separate response to that patch so you know. Great, thanks a lot! Kukjin, Could you please pick patches #5 and #6 then now that Ulf picked the others? I noticed that you are applying patches to your Samsung tree, do you want me to re-send patches #5 and #6 or is OK for you to pick them from from this series? Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/14] drm/exynos: remove struct *_win_data abstraction on planes
On Wed, Feb 04, 2015 at 04:44:12PM +0900, Joonyoung Shim wrote:
Hi,
On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
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_mode_set() callback
that was only filling all *_win_data structs.
I commented already on prior patch.
I think you don't quite understand how this primary/overlay plane stuff
works in drm core. The entire point of the drm core primary plane is to
work _exactly_ like an overlay plane and allow userspace to mangle the
primary plane configuration through the overlay plane. The only reason we
have primary planes is so that old userspace keeps working.
When I've done the testconversion with exynos to validate my atomic
helpers I've noticed that exynos makes a mess here, and on a quick look
Padovan seems to fix this up here. Not a detailed review, but this has my
Ack.
-Daniel
Thanks.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 9 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 1 +
drivers/gpu/drm/exynos/exynos_drm_drv.c | 14 --
drivers/gpu/drm/exynos/exynos_drm_drv.h | 5 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 182 ++---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 20 +--
drivers/gpu/drm/exynos/exynos_drm_plane.h | 6 +-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 123 +
drivers/gpu/drm/exynos/exynos_mixer.c | 212
+++---
9 files changed, 183 insertions(+), 389 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index ad675fb..d504f0b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -296,13 +296,13 @@ static void
exynos_drm_crtc_attach_mode_property(struct drm_crtc *crtc)
}
struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
+ struct drm_plane *plane,
int pipe,
enum exynos_drm_output_type type,
struct exynos_drm_crtc_ops *ops,
void *ctx)
{
struct exynos_drm_crtc *exynos_crtc;
- struct drm_plane *plane;
struct exynos_drm_private *private = drm_dev-dev_private;
struct drm_crtc *crtc;
int ret;
@@ -318,12 +318,6 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct
drm_device *drm_dev,
exynos_crtc-type = type;
exynos_crtc-ops = ops;
exynos_crtc-ctx = ctx;
- plane = exynos_plane_init(drm_dev, 1 pipe,
- DRM_PLANE_TYPE_PRIMARY);
- if (IS_ERR(plane)) {
- ret = PTR_ERR(plane);
- goto err_plane;
- }
crtc = exynos_crtc-base;
@@ -342,7 +336,6 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct
drm_device *drm_dev,
err_crtc:
plane-funcs-destroy(plane);
-err_plane:
kfree(exynos_crtc);
return ERR_PTR(ret);
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index 628b787..0ecd8fc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -18,6 +18,7 @@
#include exynos_drm_drv.h
struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
+ struct drm_plane *plane,
int pipe,
enum exynos_drm_output_type type,
struct exynos_drm_crtc_ops *ops,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 737164d..778c91e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -55,7 +55,6 @@ static int exynos_drm_load(struct drm_device *dev,
unsigned long flags)
{
struct exynos_drm_private *private;
int ret;
- int nr;
private = kzalloc(sizeof(struct exynos_drm_private), GFP_KERNEL);
if (!private)
@@ -80,19 +79,6 @@ static int exynos_drm_load(struct drm_device *dev,
unsigned long flags)
exynos_drm_mode_config_init(dev);
- for (nr = 0; nr MAX_PLANE; nr++) {
- struct drm_plane *plane;
- unsigned long possible_crtcs = (1 MAX_CRTC) - 1;
-
- plane = exynos_plane_init(dev, possible_crtcs,
- DRM_PLANE_TYPE_OVERLAY);
- if (!IS_ERR(plane))
-
[GIT PULL 3/3] Samsung CPUIdle updates for v3.20
Hi, This is cpuidle update for v3.20. Please pull. Thanks, Kukjin The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-cpuidle for you to fetch changes up to 712eddf70225ab5ae65e946e22d2dfe6b93e8dd1: cpuidle: exynos: add coupled cpuidle support for exynos4210 (2015-01-30 08:39:15 +0900) Samsung CPUIdle updates for v3.20 - adds coupled cpuidle support for exynos4210 : fix for Exynos platform PM code preparing it for the coupled cpuidle support and adds coupled cpuidle AFTR mode on exynos4210 Note this is mostrly based on earlier cpuidle-exynos4210 driver from Daniel Lezcano and Bart updated. Bartlomiej Zolnierkiewicz (2): ARM: EXYNOS: apply S5P_CENTRAL_SEQ_OPTION fix only when necessary cpuidle: exynos: add coupled cpuidle support for exynos4210 arch/arm/mach-exynos/common.h| 4 + arch/arm/mach-exynos/exynos.c| 4 + arch/arm/mach-exynos/platsmp.c | 2 +- arch/arm/mach-exynos/pm.c| 133 ++- arch/arm/mach-exynos/suspend.c | 4 + drivers/cpuidle/Kconfig.arm | 1 + drivers/cpuidle/cpuidle-exynos.c | 76 ++- include/linux/platform_data/cpuidle-exynos.h | 20 8 files changed, 234 insertions(+), 10 deletions(-) create mode 100644 include/linux/platform_data/cpuidle-exynos.h -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 2/3] Samsung 4th DT updates for v3.20
Hi, Here is 4th DT updates for v3.20. Please pull. Note there are several dt updates in my tree which has a dependency with driver side for v3.20 and I hope it can be sent to upstream via arm-soc during late merge window. If it is OK to you guys, I'll send a pull request soon. (example tmu, asoc and devfreq) Thanks, Kukjin The following changes since commit ea08de16eb1ba2052ce2db4b58b62a2ec33357a3: ARM: dts: Add DISP1 power domain for exynos5420 (2015-01-29 08:52:23 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-dt-4 for you to fetch changes up to 7808cae3e97140781eb3f712084caf4e44c126c9: ARM: dts: Add PPMU node for exynos4412-trats2 (2015-02-04 08:11:52 +0900) Samsung 4th DT updates for v3.20 - For exynos4 SoCs : add PPMU node : add syscon phandle for video-phy node - For exynos4415 SoC : add mipi dsi and fimd device nodes - For exynos3250-monk and exynos3250-rinato boards : add PPMU node - For exynos4412-trats2 board : add maxim77693 fuel gauge and battery charger nodes : fix regarding CLK_MOUT_CAMn parent and CLK_UART_ISP_SCLK clocks : switch max77686 regulators to GPIO control : add suspend configuration for max77686 regulators : add PPMU node and sound nodes Chanwoo Choi (4): ARM: dts: Add PPMU dt node for exynos3250 ARM: dts: Add PPMU dt node for exynos4 and exynos4210 ARM: dts: Add PPMU node for exynos3250-monk and exynos3250-rinato ARM: dts: Add PPMU node for exynos4412-trats2 Inha Song (1): ARM: dts: Add sound nodes for exynos4412-trats2 Krzysztof Kozlowski (4): ARM: dts: Add Maxim 77693 fuel gauge node for exynos4412-trats2 ARM: dts: Add suspend configuration for max77686 regulators for exynos4412-trats2 ARM: dts: Switch max77686 regulators to GPIO control for exynos4412-trats2 ARM: dts: Add max77693 charger node for exynos4412-trats2 Sylwester Nawrocki (3): ARM: dts: Fix CLK_UART_ISP_SCLK clock assignment in exynos4x12.dtsi ARM: dts: Fix CLK_MOUT_CAMn parent clocks assignment for exynos4412-trats2 ARM: dts: Add syscon phandle to the video-phy node for Exynos4 YoungJun Cho (2): ARM: dts: add fimd device node for exynos4415 ARM: dts: add mipi dsi device node for exynos4415 arch/arm/boot/dts/exynos3250-monk.dts | 40 ++ arch/arm/boot/dts/exynos3250-rinato.dts | 40 ++ arch/arm/boot/dts/exynos3250.dtsi | 74 +++ arch/arm/boot/dts/exynos4.dtsi | 109 + arch/arm/boot/dts/exynos4210.dtsi | 8 ++ arch/arm/boot/dts/exynos4412-trats2.dts | 211 arch/arm/boot/dts/exynos4415.dtsi | 27 arch/arm/boot/dts/exynos4x12.dtsi | 2 +- 8 files changed, 458 insertions(+), 53 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 1/3] Samsung exynos_defconfig updates for v3.20
Hi Arnd, Olof, Kevin Here is late pull request for exynos_defconfig updates for v3.20 and if you're OK please pull. Note this is based on previous exynos_defconfig pull-request during v3.19-rc. Thanks, Kukjin The following changes since commit 842ebf60bbad6d6e5ebaa063409fefdd2a7eb992: ARM: exynos_defconfig: Enable LM90 driver (2014-12-23 00:20:44 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-defconfig for you to fetch changes up to 39ecb024e9727c9c29765ca233bdca91c8589d01: ARM: exynos_defconfig: Enable CONFIG_FHANDLE (2015-01-24 13:50:01 +0900) Samsung exynos_defconfig updates for v3.20 - Enable CONFIG_LOCKUP_DETECTOR : to detect hard lockup and soft lockup - Enable PMIC and MUIC : for battery charger, fuel-gauge, regulators - Enable CONFIG_FHANDLE : this is required by systemd Anand Moon (1): ARM: exynos_defconfig: Enable CONFIG_LOCKUP_DETECTOR Krzysztof Kozlowski (1): ARM: exynos_defconfig: Enable PMIC and MUIC drivers for Gears and Trats2 Sjoerd Simons (1): ARM: exynos_defconfig: Enable CONFIG_FHANDLE arch/arm/configs/exynos_defconfig | 11 +++ 1 file changed, 11 insertions(+) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] drm/exynos: atomic phase 2: keep track of framebuffer pointer
On Wed, Feb 04, 2015 at 04:53:12PM +0900, Joonyoung Shim wrote: Hi, On 02/04/2015 04:14 AM, Gustavo Padovan wrote: From: Gustavo Padovan gustavo.pado...@collabora.co.uk Use drm_atomic_set_fb_for_plane() in the legacy page_flip path to keep track of the framebuffer pointer and reference. Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index 660ad64..2edc73c 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -211,6 +211,9 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc, crtc_w, crtc_h, crtc-x, crtc-y, crtc_w, crtc_h); + if (crtc-primary-state) + drm_atomic_set_fb_for_plane(crtc-primary-state, fb); + I'm not sure whether this needs, how about go to drm_atomic_helper_page_flip? You can only do that once you have full async atomic commit support, which is done in phase 3. Until that's the case you need to keep this little bit of temporary fixup code around. I've had the same in my exynos branch, we have the same now in i915 (well it looks a bit different since we dont use all the helpers but roll some things ourselves). Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Thanks. ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] exynos: config: Remove CONFIG_EXYNOS_THERMAL_CORE define (exynos_defconfig)
On 02/04/15 22:49, Lukasz Majewski wrote: Hi Kukjin, Hi, 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 l.majew...@samsung.com I dont see problems with this patch: Acked-by: Eduardo Valentin edubez...@gmail.com This should go, obviously, via the correct platform tree. Could you apply this patch to -samsung tree? Sure, I'll queue this series into samsung tree. Thanks, Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] thermal: exynos: Reorder exynos_map_dt_data() function
Hi Abhilash,
Hi Lukasz,
On Fri, Jan 30, 2015 at 8:36 PM, Abhilash Kesavan
kesavan.abhil...@gmail.com wrote:
Hi Lukasz,
On Fri, Jan 30, 2015 at 1:44 PM, Lukasz Majewski
l.majew...@samsung.com wrote:
Hi Eduardo, Abhilash,
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
l.majew...@samsung.com wrote:
Hi Abhilash,
Hi Lukasz,
On Mon, Jan 19, 2015 at 5:14 PM, Lukasz Majewski
l.majew...@samsung.com wrote:
The exynos_map_dt_data() function must be called before
thermal_zone_of_sensor_register(), and hence provide
tmu_read() function, before it is needed.
This change is driven by adding support for enabling
thermal_zoneX when it is properly initialized.
One can read the mode of operation
at /sys/class/thermal/thermal_zone0/mode Such
functionality was missing in the of-thermal.c code.
Reported-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c index
9d2d685..5d946ab 100644 ---
a/drivers/thermal/samsung/exynos_tmu.c +++
b/drivers/thermal/samsung/exynos_tmu.c @@ -975,15 +975,16
@@ static int exynos_tmu_probe(struct platform_device
*pdev) platform_set_drvdata(pdev, data);
mutex_init(data-lock);
+ ret = exynos_map_dt_data(pdev);
+ if (ret)
+ goto err_sensor;
+
data-tzd =
thermal_zone_of_sensor_register(pdev-dev, 0, data,
exynos_sensor_ops); if (IS_ERR(data-tzd)) {
pr_err(thermal: tz: %p ERROR\n,
data-tzd); return PTR_ERR(data-tzd);
}
- ret = exynos_map_dt_data(pdev);
- if (ret)
- goto err_sensor;
pdata = data-pdata;
I have been testing this along with your v5 patch set and am
seeing incorrect temperature being reported at boot-up on
exynos7.
Does it show a maximal temperature value (0x1FF)?
I did not print the current temperature register, but I
remember the message showing ~105C. Will give you the register
value when I test with more debug prints tomorrow.
It looks
like exynos_tmu_read gets called from
thermal_zone_of_device_update during boot-up, now that we
have it populated early. However, as the tmu initialization
function has not been called yet it returns a wrong value.
Does that sound correct ?
No, this is a mistake. However, I'm wondering why on Exynos4/5
this error didn't show up...
I have been lowering the software trip point temperature in the
exynos7 dts file (to 55C) for testing purposes. Hence, when the
temperature is read incorrectly as ~105C the board trips at
boot-up
this is a very unusual
value - I had problems with
reading 0xFF values with
similar symptom (but this
was caused by lack of vtmu).
itself. Maybe for exynos4/5 the incorrect value read during
boot-up is in the non-tripping range and once the tmu is
initialized later it continues to function properly thereafter ?
The reordering is needed to be able to call set_mode callback
at of-thermal.c to set the mode.
If this change causes problems, then another solution
(probably not so neat) must be found.
Please let me know if you need any further details.
Abhilash, could you provide more details (like relevant output from
dmesg) and point me a list of patches which shall I apply to test
this issue on Exynos4/5?
Sorry, I have not had the time to re-check this and provide you with
the current temperature register value. I will definitely do so on
Monday and also provide you the dmesg output. I applied the
following patches on linux-next:
bbf872d thermal: exynos: Add TMU support for Exynos7 SoC
b8190ac dts: Documentation: Add documentation for Exynos7 SoC
thermal bindings 9330ec1 thermal: exynos: Reorder
exynos_map_dt_data() function 4dd41c4 thermal: exynos: dts: Provide
device tree bindings identical to the one in exynos_tmu_data.c
a7b80b9 thermal: dts: exynos: Trip points and sensor configuration
data for Exynos5440
77d072e thermal: exynos: dts: Define default thermal-zones for
Exynos4 964dd36 thermal: dts: Default trip points definition for
Exynos5420 SoCs c1d2f97 thermal: exynos: dts: Add default
definition of the TMU sensor parameter 02a4496 arm: dts: Adding CPU
cooling binding for Exynos SoCs bfadff0 arm: dts: odroid: Enable
TMU at
Re: [PATCH 08/14] drm/exynos: atomic phase 1: add atomic_begin()/atomic_flush()
On Wed, Feb 04, 2015 at 04:49:25PM +0900, Joonyoung Shim wrote:
Hi,
On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Add CRTC callbacks .atomic_begin() .atomic_flush(). On exynos they
unprotect the windows before the commit and protects it after based on
a plane mask tha store which plane will be updated.
I don't think they need now.
This does exactly what I wanted to do in my atomic poc but couldn't
because of the massive layer hell that was still around in atomic. Haven't
looked into the patch in details, so no full r-b but good enough for an
Acked-by: Daniel Vetter daniel.vet...@ffwll.ch
Aside: If you think something doesn't need to be done please explain what
you mean or at least ask about what you don't understand in a patch. As-is
your review is pretty much unactionable.
Cheers, Daniel
Thanks.
For that we create two new exynos_crtc callbacks: .win_protect() and
.win_unprotect(). The only driver that implement those now is FIMD.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 34 ++
drivers/gpu/drm/exynos/exynos_drm_drv.h | 4 +++
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 57
++-
drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 +++
4 files changed, 82 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 09d4780..be36cca 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -147,6 +147,38 @@ static void exynos_drm_crtc_disable(struct drm_crtc
*crtc)
}
}
+static void exynos_crtc_atomic_begin(struct drm_crtc *crtc)
+{
+ struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
+ struct drm_plane *plane;
+ int index = 0;
+
+ list_for_each_entry(plane, crtc-dev-mode_config.plane_list, head) {
+ if (exynos_crtc-ops-win_protect
+ exynos_crtc-plane_mask (0x01 index))
+ exynos_crtc-ops-win_protect(exynos_crtc, index);
+
+ index++;
+ }
+}
+
+static void exynos_crtc_atomic_flush(struct drm_crtc *crtc)
+{
+ struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
+ struct drm_plane *plane;
+ int index = 0;
+
+ list_for_each_entry(plane, crtc-dev-mode_config.plane_list, head) {
+ if (exynos_crtc-ops-win_unprotect
+ exynos_crtc-plane_mask (0x01 index))
+ exynos_crtc-ops-win_unprotect(exynos_crtc, index);
+
+ index++;
+ }
+
+ exynos_crtc-plane_mask = 0;
+}
+
static struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = {
.dpms = exynos_drm_crtc_dpms,
.prepare= exynos_drm_crtc_prepare,
@@ -155,6 +187,8 @@ static struct drm_crtc_helper_funcs
exynos_crtc_helper_funcs = {
.mode_set = exynos_drm_crtc_mode_set,
.mode_set_base = exynos_drm_crtc_mode_set_base,
.disable= exynos_drm_crtc_disable,
+ .atomic_begin = exynos_crtc_atomic_begin,
+ .atomic_flush = exynos_crtc_atomic_flush,
};
static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index cad54e7..43efd9f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -194,6 +194,8 @@ struct exynos_drm_crtc_ops {
void (*win_enable)(struct exynos_drm_crtc *crtc, int zpos);
void (*win_disable)(struct exynos_drm_crtc *crtc, int zpos);
void (*te_handler)(struct exynos_drm_crtc *crtc);
+ void (*win_protect)(struct exynos_drm_crtc *crtc, int zpos);
+ void (*win_unprotect)(struct exynos_drm_crtc *crtc, int zpos);
};
enum exynos_crtc_mode {
@@ -214,6 +216,7 @@ enum exynos_crtc_mode {
* we can refer to the crtc to current hardware interrupt occurred through
* this pipe value.
* @dpms: store the crtc dpms value
+ * @plane_mask: store planes to be updated on atomic modesetting
* @mode: store the crtc mode value
* @event: vblank event that is currently queued for flip
* @ops: pointer to callbacks for exynos drm specific functionality
@@ -224,6 +227,7 @@ struct exynos_drm_crtc {
enum exynos_drm_output_type type;
unsigned intpipe;
unsigned intdpms;
+ unsigned intplane_mask;
enum exynos_crtc_mode mode;
wait_queue_head_t pending_flip_queue;
struct drm_pending_vblank_event *event;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index ebb4cdc..f498d86 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++
Re: [PATCH 00/14] drm/exynos: cleanups + atomic phases 1 and 2
Hi all, I've gone through some of the contentions point in this patch review. With my community guy hat on I really want to make drm atomic a success, exynos atomic is important for that. On Wed, Feb 04, 2015 at 04:37:04PM +0900, Joonyoung Shim wrote: Hi, On 02/04/2015 04:14 AM, Gustavo Padovan wrote: From: Gustavo Padovan gustavo.pado...@collabora.co.uk Hi, This series clean ups a few more paths from exynos-drm with the most important being the removal of the global page flip queue and the removal in driver internal data (struct *_win_data) that was replicating plane data. Following these patches comes the first step torwards atomic modesetting support on exynos. It's better to split cleanup and atomic support, not one patchset. Imo the cleanups make perfect sense as prep work for atomic. They're definitely needed afaict from what I've seen reading exynos code and these patches here before we can implement atomic. Personally I'd have delayered even more aggressively before going into the atomic stuff. But in the end I guess Padovan wants to be able to ship exynos atomic preferrably sooner than later. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] drm/exynos: fix DMA_ATTR_NO_KERNEL_MAPPING usage
On Wed, Feb 04, 2015 at 11:20:19AM +0100, Marek Szyprowski wrote:
diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 9c80884..24994ba 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -63,11 +63,11 @@ static int lowlevel_buffer_allocate(struct drm_device
*dev,
return -ENOMEM;
}
-buf-kvaddr = (void __iomem *)dma_alloc_attrs(dev-dev,
+buf-cookie = dma_alloc_attrs(dev-dev,
buf-size,
buf-dma_addr, GFP_KERNEL,
buf-dma_attrs);
-if (!buf-kvaddr) {
+if (!buf-cookie) {
DRM_ERROR(failed to allocate buffer.\n);
ret = -ENOMEM;
goto err_free;
I wonder whether anyone has looked at what exynos is doing with this.
start_addr = buf-dma_addr;
while (i nr_pages) {
buf-pages[i] = phys_to_page(start_addr);
start_addr += PAGE_SIZE;
i++;
}
There is no guarantee that DMA addresses are the same as physical addresses
in the kernel, so this is a layering violation. If you want to do this,
then a better way to do this on ARM would be:
buf-pages[i] = pfn_to_page(dma_to_pfn(dev,
start_addr));
The difference here is that dma_to_pfn() knows how to convert a dma_addr_t
to a PFN which can then be converted to a struct page (provided it is
backed by kernel managed system memory.)
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] drm/exynos: fix DMA_ATTR_NO_KERNEL_MAPPING usage
On 2015년 02월 04일 18:23, Carlo Caione wrote:
The Exynos DRM driver doesn't follow the correct API when dealing with
dma_{alloc, mmap, free}_attrs functions and the
DMA_ATTR_NO_KERNEL_MAPPING attribute.
When a IOMMU is not available and the DMA_ATTR_NO_KERNEL_MAPPING is
used, the driver should use the pointer returned by dma_alloc_attr() as
a cookie.
The Exynos DRM driver directly uses the non-requested virtual kernel
address returned by the DMA mapping subsystem. This just works now
because the non-IOMMU codepath doesn't obey DMA_ATTR_NO_KERNEL_MAPPING
but we need to fix it before fixing the DMA layer.
Applied.
Thanks,
Inki Dae
Signed-off-by: Carlo Caione ca...@caione.org
Acked-by: Joonyoung Shim jy0922.s...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_buf.c | 6 +++---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 29 +
drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 ++
3 files changed, 14 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 9c80884..24994ba 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -63,11 +63,11 @@ static int lowlevel_buffer_allocate(struct drm_device
*dev,
return -ENOMEM;
}
- buf-kvaddr = (void __iomem *)dma_alloc_attrs(dev-dev,
+ buf-cookie = dma_alloc_attrs(dev-dev,
buf-size,
buf-dma_addr, GFP_KERNEL,
buf-dma_attrs);
- if (!buf-kvaddr) {
+ if (!buf-cookie) {
DRM_ERROR(failed to allocate buffer.\n);
ret = -ENOMEM;
goto err_free;
@@ -132,7 +132,7 @@ static void lowlevel_buffer_deallocate(struct drm_device
*dev,
buf-sgt = NULL;
if (!is_drm_iommu_supported(dev)) {
- dma_free_attrs(dev-dev, buf-size, buf-kvaddr,
+ dma_free_attrs(dev-dev, buf-size, buf-cookie,
(dma_addr_t)buf-dma_addr, buf-dma_attrs);
drm_free_large(buf-pages);
} else
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index e12ea90..84f8dfe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -79,9 +79,9 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper
*helper,
struct drm_framebuffer *fb)
{
struct fb_info *fbi = helper-fbdev;
- struct drm_device *dev = helper-dev;
struct exynos_drm_gem_buf *buffer;
unsigned int size = fb-width * fb-height * (fb-bits_per_pixel 3);
+ unsigned int nr_pages;
unsigned long offset;
drm_fb_helper_fill_fix(fbi, fb-pitches[0], fb-depth);
@@ -94,25 +94,14 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper
*helper,
return -EFAULT;
}
- /* map pages with kernel virtual space. */
+ nr_pages = buffer-size PAGE_SHIFT;
+
+ buffer-kvaddr = (void __iomem *) vmap(buffer-pages,
+ nr_pages, VM_MAP,
+ pgprot_writecombine(PAGE_KERNEL));
if (!buffer-kvaddr) {
- if (is_drm_iommu_supported(dev)) {
- unsigned int nr_pages = buffer-size PAGE_SHIFT;
-
- buffer-kvaddr = (void __iomem *) vmap(buffer-pages,
- nr_pages, VM_MAP,
- pgprot_writecombine(PAGE_KERNEL));
- } else {
- phys_addr_t dma_addr = buffer-dma_addr;
- if (dma_addr)
- buffer-kvaddr = (void __iomem
*)phys_to_virt(dma_addr);
- else
- buffer-kvaddr = (void __iomem *)NULL;
- }
- if (!buffer-kvaddr) {
- DRM_ERROR(failed to map pages to kernel space.\n);
- return -EIO;
- }
+ DRM_ERROR(failed to map pages to kernel space.\n);
+ return -EIO;
}
/* buffer count to framebuffer always is 1 at booting time. */
@@ -313,7 +302,7 @@ static void exynos_drm_fbdev_destroy(struct drm_device
*dev,
struct exynos_drm_gem_obj *exynos_gem_obj = exynos_fbd-exynos_gem_obj;
struct drm_framebuffer *fb;
- if (is_drm_iommu_supported(dev) exynos_gem_obj-buffer-kvaddr)
+ if (exynos_gem_obj-buffer-kvaddr)
vunmap(exynos_gem_obj-buffer-kvaddr);
/* release drm framebuffer and real buffer */
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index ec58fe9..308173c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++
Re: [PATCH v3 0/6] Add multiple GPIO and external clock to MMC pwrseq_simple
Hello Kukjin, On 02/04/2015 04:19 PM, Kukjin Kim wrote: On 02/05/15 00:06, Javier Martinez Canillas wrote: I noticed that you are applying patches to your Samsung tree, do you want me to re-send patches #5 and #6 or is OK for you to pick them from from this series? Oh, I've missed and it looks good to me. Applied, it means you don't need to re-send ;) Great, thanks! Thanks, Kukjin Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V9 10/14] Documentation: devicetree: Add vendor prefix for parade
On Tue, Jan 20, 2015 at 10:38 AM, Ajay Kumar ajaykumar...@samsung.com wrote: ps8622 eDP-LVDS converter bridge chip is from parade technologies Signed-off-by: Ajay Kumar ajaykumar...@samsung.com Acked-by: Inki Dae inki@samsung.com Tested-by: Rahul Sharma rahul.sha...@samsung.com Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk Acked-by: Rob Herring r...@kernel.org --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 4df1d78..eca48be 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -125,6 +125,7 @@ nxp NXP Semiconductors onnn ON Semiconductor Corp. opencores OpenCores.org panasonic Panasonic Corporation +parade Parade Technologies Inc. pericomPericom Technology Inc. phytec PHYTEC Messtechnik GmbH picochip Picochip Ltd -- 1.7.9.5 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] Add support for hardware reset of eMMC card on reboot
On 02/02/15 17:51, Javier Martinez Canillas wrote: Hello Marek, Hi Marek, On Mon, Feb 2, 2015 at 9:33 AM, Marek Szyprowski m.szyprow...@samsung.com wrote: Hello, This patchset adds new mmc power sequence driver, which performs eMMC card hardware reset. Such power sequence, involving resetting emmc card, is required on some boards to properly perform system reboot procedure. Patches looks good to me, I've only one comment on patch 1/3. Once that is addressed, feel free to add for all the series: Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Applied 2/3 and 3/3 DT updates. Thanks, Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] Add multiple GPIO and external clock to MMC pwrseq_simple
On 02/05/15 00:06, Javier Martinez Canillas wrote: Hello Kukjin, Hi, On 01/30/2015 02:06 PM, Javier Martinez Canillas wrote: On 01/30/2015 12:13 PM, Ulf Hansson wrote: Patch #1 extends the simple MMC power sequence DT binding to support more than one GPIO and patch #2 adds the actual implementation. In the same way, patch #3 and #4 extend the simple MMC power sequence DT binding and pwrseq_simple driver to support an optional external clock. Finally as an example, patch #5 and patch #6 adds support for the wifi chip in the Exynos5250 Snow that needs all these resources. These two patches were added to the series only for completeness and should be picked by Kukjin through his linux-samsung tree. Best regards, Javier Thanks Javier! I have applied patch 1 - 4 for my next branch. I made some minor fix to patch4, I send a separate response to that patch so you know. Great, thanks a lot! Kukjin, Could you please pick patches #5 and #6 then now that Ulf picked the others? I noticed that you are applying patches to your Samsung tree, do you want me to re-send patches #5 and #6 or is OK for you to pick them from from this series? Oh, I've missed and it looks good to me. Applied, it means you don't need to re-send ;) Thanks, Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 10/13] clk: samsung: exynos5433: Add clocks for CMU_BUS{0|1|2} domains
Hi Sylwester,
On 02/04/2015 10:02 PM, Sylwester Nawrocki wrote:
Hi Chanwoo,
On 02/02/15 15:24, Chanwoo Choi wrote:
This patch adds the mux/divider/gate clocks for CMU_BUS{0|1|2} domains
which contain global data buses clocked at up the 400MHz. These blocks
transfer data between DRAM and various sub-blocks. These clock domains
also contain global peripheral buses clocked at 67/111/200/222/266/333/400
MHz and used for register accesses.
+/*
+ * Register offset definitions for CMU_BUS{0|1|2}
+ */
+#define DIV_BUS 0x0600
+#define DIV_STAT_BUS0x0700
+#define ENABLE_ACLK_BUS 0x0800
+#define ENABLE_PCLK_BUS 0x0900
+#define ENABLE_IP_BUS0 0x0b00
+#define ENABLE_IP_BUS1 0x0b04
+
+#define MUX_SEL_BUS20x0200 /* Only for CMU_BUS2 */
+#define MUX_ENABLE_BUS2 0x0300 /* Only for CMU_BUS2 */
+#define MUX_STAT_BUS2 0x0400 /* Only for CMU_BUS2 */
+
+/* list of all parent clock list */
+PNAME(mout_aclk_bus2_400_p) = { oscclk, aclk_bus2_400, };
+
+#define CMU_BUS_COMMON_CLK_REGS \
+DIV_BUS,\
+DIV_STAT_BUS, \
+ENABLE_ACLK_BUS,\
+ENABLE_PCLK_BUS,\
+ENABLE_IP_BUS0, \
+ENABLE_IP_BUS1
+
+static unsigned long bus01_clk_regs[] __initdata = {
+CMU_BUS_COMMON_CLK_REGS,
+};
+
+static unsigned long bus2_clk_regs[] __initdata = {
+MUX_SEL_BUS2,
+MUX_ENABLE_BUS2,
+MUX_STAT_BUS2,
+CMU_BUS_COMMON_CLK_REGS,
+};
+
+static struct samsung_div_clock bus0_div_clks[] __initdata = {
+/* DIV_BUS0 */
+DIV(CLK_DIV_PCLK_BUS_133, div_pclk_bus0_133, aclk_bus0_400,
+DIV_BUS, 0, 3),
+};
+
+/* CMU_BUS0 clocks */
+static struct samsung_gate_clock bus0_gate_clks[] __initdata = {
+/* ENABLE_ACLK_BUS0 */
+GATE(CLK_ACLK_AHB2APB_BUSP, aclk_ahb2apb_bus0p, div_pclk_bus0_133,
+ENABLE_ACLK_BUS, 4, CLK_IGNORE_UNUSED, 0),
+GATE(CLK_ACLK_BUSNP_133, aclk_bus0np_133, div_pclk_bus0_133,
+ENABLE_ACLK_BUS, 2, CLK_IGNORE_UNUSED, 0),
+GATE(CLK_ACLK_BUSND_400, aclk_bus0nd_400, aclk_bus0_400,
+ENABLE_ACLK_BUS, 0, CLK_IGNORE_UNUSED, 0),
+
+/* ENABLE_PCLK_BUS0 */
+GATE(CLK_PCLK_BUSSRVND_133, pclk_bus0srvnd_133, div_pclk_bus0_133,
+ENABLE_PCLK_BUS, 2, 0, 0),
+GATE(CLK_PCLK_PMU_BUS, pclk_pmu_bus0, div_pclk_bus0_133,
+ENABLE_PCLK_BUS, 1, CLK_IGNORE_UNUSED, 0),
+GATE(CLK_PCLK_SYSREG_BUS, pclk_sysreg_bus0, div_pclk_bus0_133,
+ENABLE_PCLK_BUS, 0, CLK_IGNORE_UNUSED, 0),
+};
+
+/* CMU_BUS1 clocks */
+static struct samsung_div_clock bus1_div_clks[] __initdata = {
+/* DIV_BUS1 */
+DIV(CLK_DIV_PCLK_BUS_133, div_pclk_bus1_133, aclk_bus1_400,
+DIV_BUS, 0, 3),
+};
+
+static struct samsung_gate_clock bus1_gate_clks[] __initdata = {
+/* ENABLE_ACLK_BUS1 */
+GATE(CLK_ACLK_AHB2APB_BUSP, aclk_ahb2apb_bus1p, div_pclk_bus1_133,
+ENABLE_ACLK_BUS, 4, CLK_IGNORE_UNUSED, 0),
+GATE(CLK_ACLK_BUSNP_133, aclk_bus1np_133, div_pclk_bus1_133,
+ENABLE_ACLK_BUS, 2, CLK_IGNORE_UNUSED, 0),
+GATE(CLK_ACLK_BUSND_400, aclk_bus1nd_400, aclk_bus1_400,
+ENABLE_ACLK_BUS, 0, CLK_IGNORE_UNUSED, 0),
+
+/* ENABLE_PCLK_BUS1 */
+GATE(CLK_PCLK_BUSSRVND_133, pclk_bus1srvnd_133, div_pclk_bus1_133,
+ENABLE_PCLK_BUS, 2, 0, 0),
+GATE(CLK_PCLK_PMU_BUS, pclk_pmu_bus1, div_pclk_bus1_133,
+ENABLE_PCLK_BUS, 1, CLK_IGNORE_UNUSED, 0),
+GATE(CLK_PCLK_SYSREG_BUS, pclk_sysreg_bus1, div_pclk_bus1_133,
+ENABLE_PCLK_BUS, 0, CLK_IGNORE_UNUSED, 0),
+};
+
+/* CMU_BUS2 clocks */
+static struct samsung_mux_clock bus2_mux_clks[] __initdata = {
+/* MUX_SEL_BUS2 */
+MUX(CLK_MOUT_ACLK_BUS2_400_USER, mout_aclk_bus2_400_user,
+mout_aclk_bus2_400_p, MUX_SEL_BUS2, 0, 1),
+};
+
+static struct samsung_div_clock bus2_div_clks[] __initdata = {
+/* DIV_BUS2 */
+DIV(CLK_DIV_PCLK_BUS_133, div_pclk_bus2_133,
+mout_aclk_bus2_400_user, DIV_BUS, 0, 3),
+};
+
+static struct samsung_gate_clock bus2_gate_clks[] __initdata = {
+/* ENABLE_ACLK_BUS2 */
+GATE(CLK_ACLK_AHB2APB_BUSP, aclk_ahb2apb_bus2p, div_pclk_bus2_133,
+ENABLE_ACLK_BUS, 3, CLK_IGNORE_UNUSED, 0),
+GATE(CLK_ACLK_BUSNP_133, aclk_bus2np_133, div_pclk_bus2_133,
+ENABLE_ACLK_BUS, 2, CLK_IGNORE_UNUSED, 0),
+GATE(CLK_ACLK_BUS2BEND_400, aclk_bus2bend_400,
+mout_aclk_bus2_400_user, ENABLE_ACLK_BUS,
+1, CLK_IGNORE_UNUSED, 0),
+GATE(CLK_ACLK_BUS2RTND_400, aclk_bus2rtnd_400,
+
Re: [v2,3/3] ARM: EXYNOS: Remove left over 'extra_save'
Hi Krzysztof,
On Tuesday 03 February 2015 04:36 PM, Krzysztof Kozlowski wrote:
Since 32b0aa9aaeb4 (ARM: EXYNOS: Remove i2c sys configuration related
code) the Exynos 5250 no longer saves additional registers under
'exynos_pm_data.extra_save' field.
No one else uses this code so get rid of it making also 'exynos_pm_data'
const everywhere.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
Changes since v1:
1. New patch.
---
arch/arm/mach-exynos/suspend.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index e6c961126087..d56bd6ca5e86 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -63,7 +63,6 @@ static struct sleep_save exynos_core_save[] = {
struct exynos_pm_data {
const struct exynos_wkup_irq *wkup_irq;
- struct sleep_save *extra_save;
int num_extra_save;
'num_extra_save' can be removed at the same time.
Rest changes looks ok.
Thanks,
Pankaj Dubey
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2,2/3] ARM: EXYNOS: Constify exynos_pm_data and of_device_id array
Hi Krzysztof, On Tuesday 03 February 2015 04:36 PM, Krzysztof Kozlowski wrote: The 'exynos5420_pm_data' and of_device_id array are not modified and can be made const. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Reviewed-by: Pankaj Dubey pankaj.du...@samsung.com Thanks, Pankaj Dubey -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
